[ome-users] Bug with czi files / loci.formats.gui.Index16ColorModel

Melissa Linkert melissa at glencoesoftware.com
Mon Apr 8 19:11:21 BST 2013


Hi Sekhar,

> I have some czi files I need to read and process. I'm reading these with BioFormats (4.4.6), but I am finding some odd behavior. I need to extract the intensity values for each channel — red, green, and blue — from the image. For some czi files, this works fine, but for others I get bizarre results. Calls to image.getRGB(x, y) return 0 for the red, green, and blue channels. However, when I open the files using ImageJ/BioFormats, I see something: so the images are not all black.
> 
> The problem seems to be connected to the color model. Images that use color models from the java.awt.image package work correctly; images that use the loci.formats.gui.Index16ColorModel do not. In fact, if I dig into the image's raster object, I find non-zero values at certain coordinates, but when I ask the color model for the red or blue at this coordinate, I get zero, and when I ask the color model for green, e.g., colorModel.getGreen(image.getRaster().getDataElements(x, y, null)), I get the raster value at that coordinate, but byte swapped. I can construct an image using the values from the raster at each coordinate and I see the same thing I see when I open the file with ImageJ.
> 
> I've put together a zip containing two example images, one that behaves correctly with my code and one that does not, along with a small example program that extracts the information from the image to demonstrate the problem.

Thank you for reporting this, and providing detailed information on how
to reproduce the problem.  This is specific to usage of
Index16ColorModel, and is not a problem with .czi files in general.

Index16ColorModel does indeed byte swap values when it should not; that
should be fixed with this change:

https://github.com/openmicroscopy/bioformats/pull/451

...which we're reviewing for inclusion in the official Bio-Formats
repository.

However, note that calling getRGB, getRed, getGreen, and getBlue will
still often give you 0 for a non-zero pixel in the raster.  This is
because the source pixels use 16 bits, but getRed/getGreen/etc. by definition
return values that are normalized to 0-255 (i.e. 8 bits).  That effectively
means that any values in the raster smaller than 256 will map to an RGB value
of (0, 0, 0).

Regards,
-Melissa

On Wed, Apr 03, 2013 at 09:19:52AM +0000, Ramakrishnan  Chandrasekhar wrote:
> Hello,
> 
> I have some czi files I need to read and process. I'm reading these with BioFormats (4.4.6), but I am finding some odd behavior. I need to extract the intensity values for each channel — red, green, and blue — from the image. For some czi files, this works fine, but for others I get bizarre results. Calls to image.getRGB(x, y) return 0 for the red, green, and blue channels. However, when I open the files using ImageJ/BioFormats, I see something: so the images are not all black.
> 
> The problem seems to be connected to the color model. Images that use color models from the java.awt.image package work correctly; images that use the loci.formats.gui.Index16ColorModel do not. In fact, if I dig into the image's raster object, I find non-zero values at certain coordinates, but when I ask the color model for the red or blue at this coordinate, I get zero, and when I ask the color model for green, e.g., colorModel.getGreen(image.getRaster().getDataElements(x, y, null)), I get the raster value at that coordinate, but byte swapped. I can construct an image using the values from the raster at each coordinate and I see the same thing I see when I open the file with ImageJ.
> 
> I've put together a zip containing two example images, one that behaves correctly with my code and one that does not, along with a small example program that extracts the information from the image to demonstrate the problem.
> 
> http://www.illposed.com/czi-bug-report.zip
> 
> I would appreciate it if you could take a look. Let me know if you need any additional information or example files.
> 
> Thanks,
> 
> Sekhar
> 
> --
> Chandrasekhar Ramakrishnan
> chandrasekhar.ramakrishnan at bsse.ethz.ch<mailto:chandrasekhar.ramakrishnan at bsse.ethz.ch>
> 
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



More information about the ome-users mailing list