Re: [Rapp-users] Possible bugs in RAPP v. 0.7

[Fabrizio Dini]

Hi Johan,

thank for your reply. And don't worry, patch files are ok. I have not tried that yet, but let me comment your answer anyway.

I find your explanation correct. That is also what I expected from RAPP. However, the formula you wrote for the stride equals to size = stride * height. Starting from what you wrote:

size = stride * (height - 1) + align(width)

but given that align(width) = stride, we have:

size = stride * (height - 1) + stride = stride * height.

And the same is true for binary image, though the calculus may seem a little more complicated.

I checked the RAPP code and I saw that the macros that verify the buffer's overlap use your formula to compute the buffer size. The problem is that in my opinion the formula for 8bpp images is being used also for binary images, that is the point. If I am right, this is why binary image size is over-estimated.

My solution, for now, is to ignore the the error code -9 from rapp_thresh_gt_u8(), since I know the buffers are not overlapped. But I am curious to see how you fixed that. I'll check your solution and then get back to you.

Regards,

Fabrizio

On Wed, Jul 3, 2013 at 10:28 AM, Johan Almbladh <address@hidden> wrote:

Hi Fabrizio,

Welcome! It's great to get feedback from people using the RAPP in other applications. :)

Let me just briefly comment on the binary image format. In RAPP all binary images are stored in a bit-packed fashion which means that each byte holds 8 pixels. I think this is one if the key points were RAPP differs from other image processing libraries. The bit-packed representation allows for much more efficient implementations binary image operations since the CPU can process blocks of 32 pixels in parallel. This is one of the reasons why morphological operations in RAPP are so fast, even with large structuring elements.

All RAPP functions validate their input arguments before proceeding. For the overlap detection we must compute the total length of each input buffer. The first height - 1 lines occupy stride * (height - 1) bytes. However, the last line may be shorter than the row stride (consider for example the case of processing a sub region of a larger image). The last row occupies the image width in bytes, rounded up to the nearest rapp_alignment boundary. Therefore, we get

size = stride * (height - 1) + align(width_in_bytes)

For a binary image each byte contains 8 pixels so we must divide the image width by 8 and round up to get the width in bytes:

size = stride * (height - 1) + align((width + 7) / 8)

When I look into rapp_thresh functions there seem to be an error in the overlap validation. All threshold functions uses an error checking macro that takes only one width-in-bytes argument. However, it must take two width arguments since the two images have different pixel depths (binary and u8). The function rapp_type_u8_to_bin() does this properly (type conversion from u8 to binary is only a special case of thresholding with a value of 128). 

I have attached a patch that fixes the validation checks for the rapp_thresh functions. 

As a temporary workaround you can allocate the binary image with a longer last row so that the bad validation check will not trigger:

mask_data = rapp_malloc(sensor_height * mask_stride + rapp_align(8 * sensor_width))

H-P: Sorry for the attachment if you prefer patches inline in emails. I just couldn't make Gmail stop mangling it :/ The fix should be very straight forward, but just drop me a line if you want to discuss anything. Have a good vacation!

Best regards,

Johan

--

Fabrizio Dini

Magenta srl - Via Pasquini 6, 50127 Firenze - Italy
+39 393 5672224 (mobile)
+39 055 286 856
address@hidden
Company web page: www.magentalab.it
Personal web page: http://www.micc.unifi.it/dini/