|
From: | Fabrizio Dini |
Subject: | Re: [Rapp-users] Possible bugs in RAPP v. 0.7 |
Date: | Mon, 1 Jul 2013 16:17:40 +0200 |
> From: Fabrizio Dini <address@hidden>
> Date: Fri, 28 Jun 2013 18:04:16 +0200
> Hi everybody!
Welcome!We have users now? :D
> Am I really the first user to write to this mailing list! WOW!
> :D (I checked the archive before writing...)
This has been fixed for a while on the git master. ...Wow,
> What these lines do is obviously to match the open curly brace
> in the extern "C" clause at the top of the file.
that's indeed quite a while ago. I guess a new release is due.
I'll try and make that happen this fall; there are a couple of
things to take care about.
Just a quick response to rule out the usual suspects: is
> 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.
mask_data (and sensor_data) allocated with rapp_malloc? That's
a prerequisite (you copy the image from another buffer with
rapp_bitblt_copy_bin). I'm just a bit suspicious seeing
8-byte-alignment and not 16-byte-alignment; absent other
information I'm guessing you use the SSE2 backend where RAPP
images would be 16-byte-aligned.
You could very well be right. Could you please enter a bug in
> 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.
the bug tracker <https://savannah.nongnu.org/bugs/?group=rapp>
(link on the RAPP project front page), best with code that shows
the bad behavior? Don't forget the details of your system and
configuration options. If I can repeat your observation a
solution will be ready so much faster.
Unfortunately your timing is bad: figuring this out will take a
little while (not having all RAPP details at the top of my head)
and I just started my vacation, so it'll be until August before
I'll be able to look closer at this. :/
brgds, H-P
Hi Hans-Peter!comments below...On Sat, Jun 29, 2013 at 12:43 AM, Hans-Peter Nilsson <address@hidden> wrote:
> From: Fabrizio Dini <address@hidden>
> Date: Fri, 28 Jun 2013 18:04:16 +0200
> Hi everybody!
Welcome!
We have users now? :D
> Am I really the first user to write to this mailing list! WOW!
> :D (I checked the archive before writing...)
You have at least one user since a long time ago... :) I started using RAPP when I discovered that Axis allowed users to write applications for their ACAP-enabled cameras, so it is about... 2007? maybe later...This has been fixed for a while on the git master. ...Wow,
> What these lines do is obviously to match the open curly brace
> in the extern "C" clause at the top of the file.
that's indeed quite a while ago. I guess a new release is due.
I'll try and make that happen this fall; there are a couple of
things to take care about.Good. It is very easy to fix, but the thing is that I tend to forget it, so when I try a new version of RAPP, I usually spend 1-2 days trying to figure out why my code stop working :DJust a quick response to rule out the usual suspects: is
> 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.
mask_data (and sensor_data) allocated with rapp_malloc? That's
a prerequisite (you copy the image from another buffer with
rapp_bitblt_copy_bin). I'm just a bit suspicious seeing
8-byte-alignment and not 16-byte-alignment; absent other
information I'm guessing you use the SSE2 backend where RAPP
images would be 16-byte-aligned.Yes, they are both allocated with rapp_malloc(). The actual code is quite complicated, so I can't write it here. It is part of an ACAP application we published on the Axis website. So far, the application worked well. I came to this problem because one of our user had problems on a new ARTPEC4 based camera. Incidentally, that camera also has RAPP 0.7 installed, so in the beginning we had to discover if the issue was related to the rapp library or to the new artpec4 platform. But then I installed the new Axis SDK (1.3) which come with rapp 0.7 and reproduced the problem.Regarding the alignment, please note that these values refers to laptop which has a rapp_alignment value of 4 bytes. However, as far as I know this value is also used on the axis cameras (at least on those based on artpec3).You could very well be right. Could you please enter a bug in
> 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.
the bug tracker <https://savannah.nongnu.org/bugs/?group=rapp>
(link on the RAPP project front page), best with code that shows
the bad behavior? Don't forget the details of your system and
configuration options. If I can repeat your observation a
solution will be ready so much faster.Ok, I will enter a bug and provide you some code...
Unfortunately your timing is bad: figuring this out will take a
little while (not having all RAPP details at the top of my head)
and I just started my vacation, so it'll be until August before
I'll be able to look closer at this. :/
brgds, H-P
Have a nice holiday! :)regards,Fabrizio
[Prev in Thread] | Current Thread | [Next in Thread] |