Re: [Vxl-users] some vil_image_view questions

[Junaed S. <ju...@ci...>]

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...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-users