From: Michael R. <mi...@re...> - 2011-02-04 21:31:23
|
Dear vxl-users, I have 3 questions, which are somewhat of a follow-up to a previous thread I started ( http://sourceforge.net/mailarchive/forum.php?thread_name=4D08F0C5.9010600%40imorphics.com&forum_name=vxl-users). I was temporarily occupied with other responsibilities, but have now returned to the problem I was having, and can't seem to find a solution. With Ian's help, I've made some progress. As mentioned in my last post, I have many types of (huge) images (e.g., 1x8, 1x16, 3x16, 4x16 not RGBA), so I start with an image resource: vil_image_resource_sptr pResource = vil_load_image_resource(name); Then, as Ian suggested, I use pResource->pixel_format() to determine what I will call my "native" view: vil_image_view<vxl_uint_16> nativeView = pResource[0]->get_view(i, ni, j, nj); But now I need to know what the different planes are, so I can know which ones to use when I need to display the image or combine information across planes. But according to this post ( http://sourceforge.net/mailarchive/message.php?msg_id=8353305), VXL can't tell me what each plane is. So my first question (1): in the three years since that post, is that still true? I know the information is in the image file header, so if VXL has a was a way to query that, I could use that. If so, please give an example. Thanks! If not, then let's assume I can get that information from somewhere else. Question (2): how can I create a view from nativeView that looks at only the (e.g.) second plane. I tried using the vil_image_view constructor referred to in the above post: vil_image_view<vxl_byte> singlePlaneView(nativeView.memory_chunk(), nativeView.top_left_ptr(), nativeView.ni(), nativeView.nj(), 1, nativeView.istep(), nativeView.jstep(), 2*nativeView.planestep()); But singlePlaneView.top_left_ptr() doesn't seem to point to contiguous memory corresponding to just the second plane. So I must be doing something wrong. And question (3), if I'd like to reorder the representation in memory of (a possible subset of) the planes, say from BGRA to RGB, what do I have to do so that (e.g.) myRgbView.top_left_ptr() will point to contiguous memory? With this problem, I'm not even sure where to start, since I can't get a single plane, let alone combine them back together in arbitrary order. Examples would be especially appreciated, as I have a difficult time figuring out what to do from the VXL reference docs alone. Thank you very much for any help! :) Michael |
From: Peter V. <pet...@ya...> - 2011-02-05 17:50:35
|
[...] I start with an image resource: vil_image_resource_sptr pResource = vil_load_image_resource(name); Then, as Ian suggested, I use pResource->pixel_format() to determine what I will call my "native" view: vil_image_view<vxl_uint_16> nativeView = pResource[0]->get_view(i, ni, j, nj); But now I need to know what the different planes are [...] If I understand it correctly: your plane info can be derived from int di = nativeView.istep(); int dj = nativeView.jstep(); int dp = nativeView.planestep(); E.g., if di=6 and dp=2 (and assuming 3 planes), you would have your 3x2 bytes per pixel contiguously, while with di=2 you have the 16-bit values for one plane and one image row physically next to each other. -- Peter. |
From: Ian S. <sc...@im...> - 2011-02-07 15:39:48
|
On 05/02/2011 17:50, Peter Vanroose wrote: > [...] I start with an image resource: > vil_image_resource_sptr pResource = vil_load_image_resource(name); > > Then, as Ian suggested, I use pResource->pixel_format() to determine > what I will call my "native" view: > > vil_image_view<vxl_uint_16> nativeView = pResource[0]->get_view(i, > ni, j, nj); > > But now I need to know what the different planes are [...] > > If I understand it correctly: your plane info can be derived from > int di = nativeView.istep(); > int dj = nativeView.jstep(); > int dp = nativeView.planestep(); > > E.g., if di=6 and dp=2 (and assuming 3 planes), you would have your 3x2 > bytes per pixel contiguously, > while with di=2 you have the 16-bit values for one plane and one image > row physically next to each other. Unless I have misunderstood you Peter, this isn't right. The step values are for use with pointer arithmetic, so if you have two similarly laid out images, but one had byte pixels and one floats, the istep jstep and planestep values would be identical in the two images. Ian. |
From: Amitha P. <ami...@us...> - 2011-02-06 08:11:44
|
On 02/04/2011 04:30 PM, Michael Repucci wrote: > But now I need to know what the different planes are, so I can know > which ones to use when I need to display the image or combine > information across planes. [...] vxl does not have a way to attach semantic labels to the plane indices. > If not, then let's assume I can get that information from somewhere > else. Question (2): how can I create a view from nativeView that looks > at only the (e.g.) second plane. [...] To get an image of a single plane: vil_image_view<X> pl = vil_plane( im, plane_index ); Note that pl will share memory with image, and the pixels of pl may not be contiguous. Certainly will not be contiguous if im stores the planes/channels in an interleaved fashion. (I.e., RGBRGB instead of RRGGBB.) > And question (3), if I'd like to reorder the representation in memory of > (a possible subset of) the planes, say from BGRA to RGB, what do I have > to do so that (e.g.) myRgbView.top_left_ptr() will point to contiguous > memory? [...] To get a contiguous memory subset of the planes, you will have to deep copy. You can use vil_plane to make your life easier: vil_image_view<X> tgt(ni,nj,np,1); // for interleaved store // vil_image_view<X> tgt(ni,nj,1,np ); // for planar store for i = 1 to num planes to copy { vil_plane(tgt,i).deep_copy( vil_plane( src, map[i] ) ); } None of the snippets above have been compiler tested, let alone run, but it should get you started. Hope this helps. Amitha. |
From: Ian S. <sc...@im...> - 2011-02-07 16:11:10
|
On 04/02/2011 21:30, Michael Repucci wrote: > Dear vxl-users, > > I have 3 questions, which are somewhat of a follow-up to a previous > thread I started > (http://sourceforge.net/mailarchive/forum.php?thread_name=4D08F0C5.9010600%40imorphics.com&forum_name=vxl-users > > <http://sourceforge.net/mailarchive/forum.php?thread_name=4D08F0C5.9010600%40imorphics.com&forum_name=vxl-users>). > I was temporarily occupied with other responsibilities, but have now > returned to the problem I was having, and can't seem to find a > solution. With Ian's help, I've made some progress. As mentioned in > my last post, I have many types of (huge) images (e.g., 1x8, 1x16, > 3x16, 4x16 not RGBA), so I start with an image resource: > > vil_image_resource_sptr pResource = vil_load_image_resource(name); > > Then, as Ian suggested, I use pResource->pixel_format() to determine > what I will call my "native" view: > > vil_image_view<vxl_uint_16> nativeView = pResource[0]->get_view(i, > ni, j, nj); > > But now I need to know what the different planes are, so I can know > which ones to use when I need to display the image or combine > information across planes. But according to this post > (http://sourceforge.net/mailarchive/message.php?msg_id=8353305), VXL > can't tell me what each plane is. So my first question (1): in the > three years since that post, is that still true? I know the > information is in the image file header, so if VXL has a was a way to > query that, I could use that. If so, please give an example. Thanks! Which image format are you using? I'm not aware of any consistent way of describing each channel under all reasonable use-cases. eg, varying frequency response curves, or spatial or time-derivative channels. This would make it difficult to put such a thing in the image-resource properties API. However, if your particular file format has a standard way of describing the channels then you could expose that as a class-specific attribute on the particular file-format image-resource class. for RGB images, irrespective of the underlying memory layout, all files should be loaded as plane 0 - Red, plane 1 - Green, plane 2 - Blue. > If not, then let's assume I can get that information from somewhere > else. Question (2): how can I create a view from nativeView that > looks at only the (e.g.) second plane. I tried using the > vil_image_view constructor referred to in the above post: > > vil_image_view<vxl_byte> singlePlaneView(nativeView.memory_chunk(), > nativeView.top_left_ptr(), nativeView.ni(), nativeView.nj(), 1, > nativeView.istep(), nativeView.jstep(), 2*nativeView.planestep()); you want to move the top-left ptr to the start of the plane you are interested in. So that should be vil_image_view<vxl_byte> singlePlaneView(nativeView.memory_chunk(), nativeView.top_left_ptr()+nativeView.planestep(), nativeView.ni(), nativeView.nj(), 1, nativeView.istep(), nativeView.jstep(), nativeView.planestep()); (the last parameter is largely irrelevant for a single plane image.) Or you could just use vil_plane() > > But singlePlaneView.top_left_ptr() doesn't seem to point to > contiguous memory corresponding to just the second plane. So I must > be doing something wrong. If you original image is laid out RGBRGBRGB..., then your single-plane view of the underlying data will not be contiguous. > And question (3), if I'd like to reorder the representation in memory > of (a possible subset of) the planes, say from BGRA to RGB, what do I > have to do so that (e.g.) myRgbView.top_left_ptr() will point to > contiguous memory? With this problem, I'm not even sure where to > start, since I can't get a single plane, let alone combine them back > together in arbitrary order. > Minor point: by calling it myRgbView you are implying that its is just a view on the same underlying memory. you really want a brand new underlying image. // I assume here that, irrespective of the underlying memory, // plane 0 is R, and plane 2 is B. vil_image_view<vxl_byte> myRgbView(ni, nj, 3); myRgbView.deep_copy(vil_planes(nativeView, 0, 1, 3)); > Examples would be especially appreciated, as I have a difficult time > figuring out what to do from the VXL reference docs alone. Thank you > very much for any help! try the vxl book, or core\vil\examples\* for some more examples. Ian |