[ros-users] image_proc crop and decimate (binning) nodelet and bayer

Joan Pau Beltran joanpau.beltran at uib.cat
Thu Sep 29 17:05:54 UTC 2011

Hi everyone,

Electric Emy includes a nodelet to perform crop and binning of images.
In our research group we find this very useful and were wondering why it 
was missing.
So very good news to see it there. Congratulations! We hope to see this 
node documented in the image_proc wiki soon.

If the input image encoding is bayer, this nodelet performs crop/binning 
and debayering.
We would like to discuss with the ROS community if it would be more 
convenient perform only the crop/binning, and do NOT perform the 
debayering. That debayering process, with possibly other image_proc 
tasks, could be performed by another image_proc node in the subsampled 
image topic namespace. From our point of view, it will have two main 

   1. It will allow more complex debayering methods to be aplied  to the
      scaled images by image_proc, with zero mantainment cost of the
      crop/binning nodelet.
   2. It will allow subsampling bayer images to reduce its size and send
      them through the network without losing the color information (if
      sended in mono) nor triplicating the required bandwith (if sended
      in color)

The subsampling is quite easy to implement. It just changes depending on 
the encoding. Subsampling of mono and color encoded images is quite 
intuitive. In Bayer encodings, the idea is to consider each set of 2x2 
pixels as a color cell, and these color cells are the subsampling units. 
The resulting image has the same encoding than the original one.

What do you think of it?

The attached file crop_decimate.cpp includes the needed modifications to 
implement the explained functionality, also solving some issues and 
todo's in the current implementation:

   1. It should handle correctly 16 bit encodings (and any other bit
      depth), since in that implementation different bit depths do no
      need specific methods. I say it should because I could not test
      it. I do not have any camera or bagfile with 16 bit images.
   2. Offsets are checked to be smaller than image size, and an error is
      reported if it is not the case. In contrast, if the demanded ROI
      is bigger than the image (with or height too large for the given
      the offset and image size), it is SILENTLY adjusted. Should this
      adjustment be warned?
   3. On Bayer images, not only the offsets are checked to be even, but
      also the resulting image size. This is needed to end up with a
      well formed Bayer image with full color cells.

The file crop_decimate2.cpp is a slightly different implementation of 
the same idea, but performing the subsampling in just one function for 
all the encodings (given the right parameters). The function takes as 
targuments the cell size (2x2 for Bayer, 1x1 for other encodings, but 
any other size could be used).
Probably the code is a little more elegant, but it may have a little 
overhead because of the inner loop (probably insignificant). A part from 
that, and to present an alternative approach, it also solves the 
inconsistent image - ROI offsets/size in a different way. The output 
image size is always the same than the given ROI once subsampled, and 
the region that falls out of the image is zeroed. This is similar to 
what happens to the rectified image when a zero alpha value is set in 
the calibration.

It should be said that this subsampling is the crudest one, and it can 
introduce artifacts in the resulting image. Another completely different 
approach will be to use OpenCV resizing functions to do the job. In that 
case, as in the debayering process, a set of methods could be supported 
with an extra dynamic_reconfigure parameter. I think that last OpenCV 
versions only understand images as bgr8 encoded cv::Mat's (even mono 
images), so the approach will be:

   1. subscribe to the color image
   2. subsample it to a color scaled image
   3. from this color scaled image build the mono scaled image if necessary

And it won't be possible to scale a bayer image, debayer it first will 
be mandatory. Is there any OpenCV expert that can confirm or refutate 
these statements? Any information about the resizing functions will be 
appreciated, since the documentation is quite poor.

That's all, folks. Sorry for the long mail. If the attached code could 
be useful, please feel free to merge it into the ROS image_proc branch, 
with any convenient modifications.
Other comments, advice or suggestions will also be appreciated.


P.D: BTW, the connectCb in the code has no argument, but in the 
NodeHandle API it has a SingleSubscriberPublisher as unique argument. 
Does anybody know what is this argument? I asked the same question to 
answer.ros.org, so probably the best place to answer would be there:

Joan Pau Beltran
Grup de Sistemes, Robòtica i Visió - DMI
Universitat de les Illes Balears
Ctra. Valldemossa, km 7.5 07122 Palma
Campus Universitari, edifici Anselm Turmeda
Telf (+34) 971 17 28 13
Fax (+34) 971 17 30 03

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20110929/74156a92/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crop_decimate2.cpp
Type: text/x-c++src
Size: 7908 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20110929/74156a92/attachment-0006.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crop_decimate.cpp
Type: text/x-c++src
Size: 7778 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20110929/74156a92/attachment-0007.cpp>

More information about the ros-users mailing list