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

Patrick Mihelich mihelich at willowgarage.com
Wed Oct 12 05:39:36 UTC 2011


On Fri, Sep 30, 2011 at 2:47 AM, Joan Pau Beltran
<joanpau.beltran at uib.cat>wrote:

> 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.
>

Now that I really think about it, that's not the correct behavior... more on
that below.

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.
>

Camera subscribers are strongly encouraged to use the PinholeCameraModel
class from image_geometry to wrap up the details of using the CameraInfo for
tasks like rectification and projecting 3d points to image coordinates (and
vice versa). In that case their code will behave correctly in the presence
of binning/ROI without any extra effort. ROI in particular requires tricky
tweaks to the camera matrix, which PinholeCameraModel does for you.

Does anybody know the exact meaning of that parameter? If so, an example of
> its use will be very appreciated.
>

Basically, ROI makes rectification a nasty business, as the REP describes.
You define the ROI as a rectangle in raw image coordinates (since that's
what the camera driver understands), but when you rectify, that rectangle
gets stretched into some wavy shape in the rectified image plane. So you
have to choose some new rectangle (the rectified ROI) to slap over it, and
call that your rectified image.

Without ROI, this is no big deal, as you actually choose that new rectangle
at calibration time. For convenience we make it the same size as the raw
image, and the alpha parameter controls how much of that wavy shape the
rectangle covers.

do_rectify selects between these two behaviors. If do_rectify is
 * True: compute the rectified ROI from the raw ROI as described in REP 104.
 * False: just reuse the raw ROI, because we've chosen our calibration so
that they match up nicely.

I agree that usage of binning/ROI with CameraInfo is under-documented. I've
been meaning to write a tutorial that uses ROI/binning, and an informational
REP that better explains the ROS camera model, but these sorts of things are
very time-consuming.

To be honest, nobody's been breathing down my neck wanting to make serious
use of ROI. I needed it a couple years ago for one specialized application,
later added binning and standardized the behavior in REP 104, and since then
it's mostly gathered cobwebs. Is this a feature that's important to you?
What sort of use cases do you have in mind? Having actual users would do a
lot to bump this up on my priority list :).

How should it be handled in the crop/binning nodelet?
>

Since crop_decimate potentially mucks around with the ROI fields, it does
need to care about do_rectify.

If no ROI is specified, crop_decimate should leave do_rectify as-is. If an
ROI is specified, crop_decimate should set do_rectify = true.

Cheers,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20111011/b7ab4d13/attachment-0004.html>


More information about the ros-users mailing list