Hi again,
I forgot to mention that in the current implementation and in the
code attached in the first post, the do_rectify member of the
camera_info ROI is not modified. After reading REP 104 in
http://www.ros.org/reps/rep-0104.html
where the meaning of the operational parameters is explained, I
don't really understand who is supposed to check the do_rectify
parameter and what does it mean.
In the REP is explained how it should be SET, but not how it should
be USED by camera subscribers. Does anybody know the exact meaning
of that parameter? If so, an example of its use will be very
appreciated.
How should it be handled in the crop/binning nodelet?
Thanks again!
P.D.: Some archives do not show the text of the first post as the
mail body, I don't know why. However the text may be found as
attached message. The nabble archives display it correctly, link:
http://ros-users.122217.n3.nabble.com/image-proc-crop-and-decimate-binning-nodelet-and-bayer-tt3379897.html
Al 29/09/11 19:05, En/na Joan Pau Beltran ha escrit:
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 advantages:
- 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.
- 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:
- 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.
- 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?
- 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:
- subscribe to the color image
- subsample it to a color scaled image
- 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.
Thanks!
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:
http://answers.ros.org/question/2288/argument-for-subscriberstatuscallback-in-advertise
--
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
--
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