rapp-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Johan Almbladh
Subject: Re: [Rapp-users] Possible bugs in RAPP v. 0.7
Date: Wed, 3 Jul 2013 10:28:38 +0200

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

Attachment: fix-overlap-checks-in-thresh.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]