Hello Ian,
Thanks for the reply. I found your example code to work (without adding
any headers, so it worked nicely, thanks!). So I changed just one thing
in my own code, and that took away my problem. This is what I did:
BEFORE:
void Tracker::ProcessFrame( vil_image_view<vxl_byte> &image )
{
vil_image_view<vxl_byte> TempImage( image.ni(), image.nj(),
image.nplanes() );
TempImage = image;
....
}
NOW:
void Tracker::ProcessFrame( vil_image_view<vxl_byte> &image )
{
vil_image_view<vxl_byte> TempImage = image;
....
}
That seemed to have fixed it (verified using the debugger and at runtime).
I still have a problem with accessing the underlying vxl_byte buffer,
but that's something I haven't investigated in depth yet. Could you
please tell me what I was doing wrong with my earlier approach?
Thanks a lot.
Cheers,
-J-
Ian Scott wrote:
> Junaed Sattar wrote:
>> Hi there,
>> I have a question about vil_image_view, and copying one view to the
>> other in particular.
>>
>> I have an image that I read from file or grab from camera. If read
>> from a camera (firewire or v4l device) I grab the image in an
>> unsigned char buffer first, then use set_to_memory to create a
>> vil_image_view<vxl_byte> using in-memory image data. Here's the snippet:
>>
>> vil_image_view<vxl_byte> image;
>> image.set_to_memory( ( const vxl_byte * ) buffer, image_width,
>> image_height, 3,
>> 3, 3 *
>> image_width, 1 );
>>
>> Otherwise, I use vil_load to read the image directly into 'image'.
>>
>> 'buffer' is guaranteed to have valid image data from a camera
>> (verified elsewhere). I use RGB images only, so my guess (and which
>> works when i display using a gdkpixbuf object) is there are 3 bytes
>> per pixel, with istep being 3, jstep being 3*width, and planestep
>> being 1. Indeed, that is what I observe when I debug my program.
>>
>> That said, elsewhere in my code, I copy this 'image' to another
>> vil_image_view<vxl_byte> object called TempImage. I 'copy' by using a
>> simple assignment, which, according to the vxl manual, would make the
>> views point to the same memory space. When I observe TempImage in a
>> debugger, I see that while the width and height and nplanes are the
>> same as 'image', istep is 1, jstep is equal to the image width, and
>> planestep is equal to height*width bytes. This ruins my attempts to
>> access the underlying image bytes.
>
> Something isn't correct here. The code should not behave like this -
> and according to the example below - it doesn't behave as I understand
> your description.
>
> //Note I actually tested this code inside another program.
> // so there may be a few #includes or other niceties missing
> // from this example.
> #include <vxl_config.h>
> #include <vil/vil_image_view.h>
> #include <vil/io/vil_io_image_view.h>
>
> int main()
> {
>
> const unsigned width=5, height=7;
> vxl_byte buffer[3*width*height];
> vil_image_view<vxl_byte> image;
> image.set_to_memory( buffer, width, height, 3,
> 3, 3 * width, 1 );
>
>
> // Simple assignment
> vil_image_view<vxl_byte> image2 = image;
>
> vcl_cout << "image: "; vsl_print_summary(vcl_cout, image);
> vcl_cout << ", istep: " << image.istep() << ", jstep: " <<
> image.jstep()
> << ", planestep: " << image.planestep() << vcl_endl;
>
> vcl_cout << "image2: "; vsl_print_summary(vcl_cout, image2);
> vcl_cout << ", istep: " << image2.istep() << ", jstep: " <<
> image2.jstep()
> << ", planestep: " << image2.planestep() << vcl_endl;
>
> return 0;
> }
>
> OUTPUT:
> image: 3 planes, each 5 x 7, istep: 3, jstep: 15, planestep: 1
> image2: 3 planes, each 5 x 7, istep: 3, jstep: 15, planestep: 1
>
> All seems to work for me.
>
> I looked into the forums and am trying to use
>> Ian Scott's method 3 listed here
>> (http://sourceforge.net/mailarchive/message.php?msg_id=8723774) to
>> convert the image such that top_left_ptr() points to a contiguous
>> series of bytes (like an unsigned char array of bytes). I need this
>> to work since I need the underlying bytes to display them in a
>> gdkpixbuf after processing using my algorithms.
>>
>> I was hoping if anyone can tell me why the step sizes change when I
>> copy like that? I tried a deep copy, with the same results. I may
>> very well be doing it wrong; in that case a (short) lesson on proper
>> vil_image_view-ing would be greatly appreciated! :)
>
> Your understanding of the correct behaviour of vil appears fine so far.
> The behaviour you describe appears to be that of a deep copy, which
> can normalise the image towards a multi-planar form. I would guess
> that you are actually doing a deep copy on the image, somewhere other
> than your simple assignment.
> I suggest that you try to find the simplest version of your code that
> exhibits the problem, and post that if it still doesn't behave as you
> would expect.
>
> Regards,
> Ian.
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Vxl-users mailing list
> Vxl-users@...
> https://lists.sourceforge.net/lists/listinfo/vxl-users
|