From: Cyrille B. <cyr...@la...> - 2006-07-20 12:20:28
|
Hello, I would like to know if it is possible to demosaic bayer image with VXL ? And if it is possible, how ? Thanks in advance. -- Cyrille Berger |
From: Junaed S. <ju...@ci...> - 2006-07-22 19:37:47
|
Hi there, I have an application in Gtk, where I display images using a GtkImagePane widget, and to do that I need to create a GdkPixBuf object from memory data. Without going into too much detail, the GdkPixBuf objects only support RGB color, so there's no way to directly use a gray scale image to show in the display. The workaround is to replicate the intensity data on all three RGB channels of an image data. Here's where VXL comes in. I have a single plane vil_image_view<vxl_byte> image that stores a gray scale image, and to get it into the GdkPixBuf, I have to convert it into a 3 plane RGB image with the same values for planes 0, 1 and 2. I don't know if there's a direct way to do that in VXL, so I create a function to do the conversion like this: vil_image_view<vxl_byte> input, output; // // input gets the data here // unsigned ni = input.ni(), nj = input.nj(); output.set_size( ni, nj, 3 ); for( unsigned i = 0; i < ni; i++ ) for( unsigned j = 0; j < nj; j++ ) { output(i,j,0) = input(i,j); output(i,j,1) = input(i,j); output(i,j,2) = input(i,j); } The object output, as can be seen, is the target 3-plane image. After the method terminates, with the right data in place, the plane step values are now wrong. My understanding is that an RGB image has pixels stored consecutively like (RGB)(RGB)(RGB)....(RGB) for each row. This amounts to an istep of 3, and jstep of 3*ni, and a planestep of 1. But after debugging the code, I find out that istep is 1, jstep is ni, and planestep is nj*ni. This throws off the data pointer and as a result the GdkPixBuf does not work, crashing the application completely. I have previously used vil_image_view::top_left_ptr() method to point to the start of the data buffer, but it seems that in this case its not working. So my questions are: 1) Is there a better way (or the right way) of doing this sort of conversion? 2) Is there a better way to get a handle to the underlying image buffer? 3) Is there any way to explicitly change the step sizes for a vil_image_view? Thanks a lot! -J- |
From: Ian S. <ian...@st...> - 2006-07-24 13:53:36
|
Junaed Sattar wrote: > Hi there, > I have an application in Gtk, where I display images using a > GtkImagePane widget, and to do that I need to create a GdkPixBuf object > from memory data. Without going into too much detail, the GdkPixBuf > objects only support RGB color, so there's no way to directly use a gray > scale image to show in the display. The workaround is to replicate the > intensity data on all three RGB channels of an image data. > > Here's where VXL comes in. I have a single plane > vil_image_view<vxl_byte> image that stores a gray scale image, and to > get it into the GdkPixBuf, I have to convert it into a 3 plane RGB image > with the same values for planes 0, 1 and 2. I don't know if there's a > direct way to do that in VXL, so I create a function to do the > conversion like this: > > vil_image_view<vxl_byte> input, output; > > // > // input gets the data here > // > > unsigned ni = input.ni(), nj = input.nj(); > > output.set_size( ni, nj, 3 ); > for( unsigned i = 0; i < ni; i++ ) > for( unsigned j = 0; j < nj; j++ ) > { > output(i,j,0) = input(i,j); > output(i,j,1) = input(i,j); > output(i,j,2) = input(i,j); > } > > The object output, as can be seen, is the target 3-plane image. After > the method terminates, with the right data in place, the plane step > values are now wrong. My understanding is that an RGB image has pixels > stored consecutively like (RGB)(RGB)(RGB)....(RGB) for each row. This > amounts to an istep of 3, and jstep of 3*ni, and a planestep of 1. But > after debugging the code, I find out that istep is 1, jstep is ni, and > planestep is nj*ni. This throws off the data pointer and as a result the > GdkPixBuf does not work, crashing the application completely. I have > previously used vil_image_view::top_left_ptr() method to point to the > start of the data buffer, but it seems that in this case its not > working. The top_left_ptr() points to the pixel at position (0,0,0). The start of the data block in memory is pointed to by image.memory_chunk().data(). They are not necessarily identical. > > So my questions are: 1) Is there a better way (or the right way) of > doing this sort of conversion? the vil_convert_to_n_planes() or another vil_convert function or combination of vil_convert functions might be useful. 2) Is there a better way to get a handle > to the underlying image buffer? You can construct an image with the pixels arranged anyway you want using the various constructors of vil_image_view<> 3) Is there any way to explicitly change > the step sizes for a vil_image_view? Use the constructor to produce interleaved planes (otherwise known as components). vil_image_view<vxl_byte> output(ni, nj, 1, 3); Ian. |
From: Peter V. <pet...@ya...> - 2006-07-29 16:08:08
|
> vil_image_view<vxl_byte> image that stores a gray scale image, and to > get it into the GdkPixBuf, I have to convert it into a 3 plane RGB image > with the same values for planes 0, 1 and 2 Wouldn't it be possible to create an RGB image view with a planestep of 0 to accomplish this? I don't see anywhere in the source code a test for planestep_ to be > 0, so my guess is that this should work with the existing framework. Correct me if I'm wrong... Of course, changing a pixel value in any of the 3 views will automatically change the other two as well. Which is exactly how one wants it to behave. -- Peter. |
From: Amitha P. <pe...@cs...> - 2006-07-31 14:02:59
|
On Sat 29 Jul 2006, Peter Vanroose wrote: > > vil_image_view<vxl_byte> image that stores a gray scale image, and to > > get it into the GdkPixBuf, I have to convert it into a 3 plane RGB image > > with the same values for planes 0, 1 and 2 > > Wouldn't it be possible to create an RGB image view with a planestep > of 0 to accomplish this? I think that'd work for VxL apps (i.e., those that when through vil_image_view); however, passing top_left_ptr() to GdkPixBuf would probably fail, since I'd guess that it requires a "full" image. Amitha. |