Re: [Vxl-users] some vil_image_view questions

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

Thread view

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. 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! :)
Cheers,
Junaed

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.

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

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details