rapp-users
[Top][All Lists]
Advanced

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

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


From: Fabrizio Dini
Subject: [Rapp-users] Possible bugs in RAPP v. 0.7
Date: Fri, 28 Jun 2013 18:04:16 +0200

Hi everybody!

Am I really the first user to write to this mailing list! WOW! :D (I checked the archive before writing...)

Well, I think I found two bugs in the RAPP library, and I wish to report them but I am unused to this platform, so please forgive me if this is not the right place.

The first bug is a missing closed curly brace in the header file rapp_main.h, which prevents any C++ application to compile correctly. The fix is straightforward and it worked for me. The following three lines of code must be added right after the declarations of rapp_initialize() and rapp_terminate() functions (but before the #endif directive that closes the #ifndef RAPP_MAIN_H include guard):

#ifdef __cplusplus
}
#endif

What these lines do is obviously to match the open curly brace in the extern "C" clause at the top of the file.

The second bug is still not confirmed, and it is the main reason why I am writing here. I have to say I occasionally used RAPP since its 0.5 version, and it seems it appeared in ver. 0.6 (just checked the git repository), though I am using version 0.7.

The (candidate) bug should be in the definition of RAPP_VALIDATE_RESTRICT_OFFSET macro in the rapp_util.h file. The reason I say this implementation is bugged is that it wrongly computes the pixel buffer size when one of the two images is a binary image. I traced the control flow from a call to the function rapp_thresh_gt_u8() that looks like this:

rapp_thresh_gt_u8(mask_data, mask_stride, sensor_data, sensor_stride, sensor_width, sensor_height, threshold);

This call gives a return code of -9 (pixel buffer overlap) with the following values of the parameters:

mask_data: 0x081FBBA8
mask_stride: 16
sensor_data: 0x081FBE00
sensor_stride: 108
sensor_width: 108
sensor_height: 34

mask_data is a pointer to a binary image, while sensor_data points to 8 bit-per-pixel gray level image. Both images are 108x34 pixels.

According to the macro (which gets called at the beginning of rapp_thresh_gt_u8()) the binary images mask_data occupies 636 bytes (0x27C) instead of 478 bytes (the true pixel buffer size). I think the error is in the first part of the macro definition (line 150 of rapp_util.h):

(((uint8_t *) (p1) + (d1) * ((h) - 1) + (of1) <=        \

The _expression_  (d1) * ((h) - 1) + (of1) is supposed to compute the pixel buffer size, but with the given value of the parameters, it evaluates to 16 * 33 + 108, which is wrong (it should be just 16*34).

Am I wrong? Maybe I did not understand exactly what the code is supposed to do, but in this case I probably need some explanation about how binary images work.

I look forward to hear from you guys!

Regards,
Fabrizio


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

reply via email to

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