16-bit bitmaps

[jennBakal]

hi,

we have code using loci_tools.jar to convert 3 channel images and information from PSLID to an OME-TIFF file. it works for the older images which are 8-bit. however, when we try to convert the newer 16-bit images, we're getting things that look like 2 channels each with 3 slices with no data.

should BMPImageReader be able to handle 16-bit bitmaps? i'm not sure what version of loci_tools.jar we're using, but when i unpack the jar file, the loci directory is dated 2010-07-09

thanks,
jenn

[mlinkert]

Hi Jenn,

we have code using loci_tools.jar to convert 3 channel images and information from PSLID to an OME-TIFF file. it works for the older images which are 8-bit. however, when we try to convert the newer 16-bit images, we're getting things that look like 2 channels each with 3 slices with no data.

should BMPImageReader be able to handle 16-bit bitmaps?

Yes, it should, though I don't believe that we have any 3 channel 16-bit BMP images, so it is possible that this has never been tested before.

i'm not sure what version of loci_tools.jar we're using, but when i unpack the jar file, the loci directory is dated 2010-07-09

That suggests that you have a quite old version of loci_tools.jar. To find out for sure, can you please send the output of:

Code: Select all

java -cp /path/to/loci_tools.jar loci.formats.tools.ImageInfo -version

If the output is something to the effect of "unknown command flag: -version", then you definitely have an old version, and should upgrade to either the latest stable release (4.2.2, very soon to be 4.3.0) or a trunk build. All versions of loci_tools.jar are available here: http://loci.wisc.edu/bio-formats/downloads.

Regards,
-Melissa

[bhcho]

Hi Mellisa,

I updated the loci_tools.jar (4.3.0) and tried to convert a sample 16-bit image from our microscope into ome-tiff, using ImageConverter.java from http://www.loci.wisc.edu/bio-formats/bio-formats-java-library

But the converted image looks like a 2x2-tiled image, in which upper 2 tiles are 25% sized of the original image and lower 2 tyles are just black. Can I give you a sample image so that you can try by yourself?

I'm not sure if this is because our image is simply very unique type of image or not.

Best,
BK

[mlinkert]

Hi BK,

I updated the loci_tools.jar (4.3.0) and tried to convert a sample 16-bit image from our microscope into ome-tiff, using ImageConverter.java from http://www.loci.wisc.edu/bio-formats/bi ... va-library

But the converted image looks like a 2x2-tiled image, in which upper 2 tiles are 25% sized of the original image and lower 2 tyles are just black.

That sounds like a problem with the interleaving of the 2 channels; either they are stored non-interleaved (all of the samples for channel #0 first, then all of the samples for channel #1) and Bio-Formats is detecting that they are interleaved (one sample for channel #0, then one sample for channel #1, etc.), or the opposite.

Can I give you a sample image so that you can try by yourself?

Yes, please. I think I have already sent you our SFTP server information, but if you need it again let me know and I will send it privately.

Regards,
-Melissa

[bhcho]

I don't have any clue about the interleaving from our original image.
I just tried to convert one channel image without changing any other options, and the result was as I said above.

anyway, could you please tell me again privately?
bhcho at cmu dot edu

best,
BK

[mlinkert]

Hi BK,

Thanks for sending an example file.

If you update to the latest trunk build of Bio-Formats, then the file should open correctly. If you continue to notice problems, though, please let us know.

Regards,
-Melissa

[bhcho]

Thanks Melissa,

1.
when I converted a one-channel 16 bit image using the new bio-format, it looks like one channel greyscale image from ImageJ. But when I import the converted image into OMERO, It looks like it became RGB (3ch) image.
moreover, the filesize became bigger (from 2.62MB to 3.94MB).

1.1.
when I tried to look at the original image header using bio-formats,
the global meta info was (using ImageReader().getGlobalMetadata())

Global meta info: {Color planes=1, Indexed color=false, Magic identifier=BM, Y resolution=0, X resolution=0, Image height=1024, Compression type=None, File size (in bytes)=2752570, Bits per pixel=16, Image width=1344}

but when I tried to use other Bioformat APIs, such as

Code: Select all

reader.getCoreMetadata()[0].littleEndian
reader.getDimensionOrder()
reader.getPixelType()
reader.getBitsPerPixel()
reader.getSizeX()
reader.getSizeY()
reader.getSizeZ()
reader.getSizeC()
reader.getSizeT()

the results are

Endian: false
Dimension Order: XYCTZ
Pixel Type: uint8
Bit Per Pixel: 8
SizeX: 1344
SizeY: 1024
SizeC: 1
SizeZ: 3
SizeT: 1

- I was expecting the image's pixel type is something like uint16 and bitperpixel is 16, but it was uint8 and 8 bit per pixel. is this related to the problem that I'm having?
- the sizeZ is 3. This image is just one channel and one slice bmp image. what does this sizeZ mean? is this related to becoming RGB image when converted?

2.
Similarly, when I converted 3 bmp images into one (3-channel) ome-tiff image, the file size becomes bigger than 3 times the each file's size. (3*2.62MB should be 7.86MB, but it became 11.8MB when converted).

2.1.
I could open the 3 channel ome-tiff image from ImageJ, but when I tried to import it into OMERO server, it gave the following error.

2011-06-27 14:30:06,506 712203 [2-thread-1] ERROR ome.formats.importer.gui.ImportHandler - Generic error while importing image.
java.lang.IllegalArgumentException: Invalid C index: -1/1
at loci.formats.FormatTools.getIndex(FormatTools.java:296)
at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:449)
at loci.formats.FormatReader.setId(FormatReader.java:1058)
at loci.formats.ImageReader.setId(ImageReader.java:650)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:480)
at loci.formats.ChannelFiller.setId(ChannelFiller.java:244)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:480)
at loci.formats.ChannelSeparator.setId(ChannelSeparator.java:238)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:480)
at ome.formats.importer.ImportLibrary.open(ImportLibrary.java:245)
at ome.formats.importer.ImportLibrary.importImage(ImportLibrary.java:483)
at ome.formats.importer.ImportLibrary.importImage(ImportLibrary.java:433)
at ome.formats.importer.ImportLibrary.importImage(ImportLibrary.java:376)
at ome.formats.importer.gui.ImportHandler.importImages(ImportHandler.java:216)
at ome.formats.importer.gui.ImportHandler.access$100(ImportHandler.java:59)
at ome.formats.importer.gui.ImportHandler$2.run(ImportHandler.java:134)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

could you give me any clue on this?

Best,
BK

[mlinkert]

Hi BK,

1.
when I converted a one-channel 16 bit image using the new bio-format, it looks like one channel greyscale image from ImageJ. But when I import the converted image into OMERO, It looks like it became RGB (3ch) image.
moreover, the filesize became bigger (from 2.62MB to 3.94MB).

Is this the same file that you sent a few days ago? If so, the correct behavior is for there to be 3 channels. There are 16 bits per pixel, but 3 channels are packed into those 16 bits (5 bits per channel, with the highest bit unused).

1.1.
when I tried to look at the original image header using bio-formats,
the global meta info was (using ImageReader().getGlobalMetadata())

Global meta info: {Color planes=1, Indexed color=false, Magic identifier=BM, Y resolution=0, X resolution=0, Image height=1024, Compression type=None, File size (in bytes)=2752570, Bits per pixel=16, Image width=1344}


but when I tried to use other Bioformat APIs, such as

Code: Select all

    reader.getCoreMetadata()[0].littleEndian
    reader.getDimensionOrder()
    reader.getPixelType()
    reader.getBitsPerPixel()
    reader.getSizeX()
    reader.getSizeY()
    reader.getSizeZ()
    reader.getSizeC()
    reader.getSizeT()


the results are

Endian: false
Dimension Order: XYCTZ
Pixel Type: uint8
Bit Per Pixel: 8
SizeX: 1344
SizeY: 1024
SizeC: 1
SizeZ: 3
SizeT: 1


- I was expecting the image's pixel type is something like uint16 and bitperpixel is 16, but it was uint8 and 8 bit per pixel. is this related to the problem that I'm having?

As mentioned above, if this is the same file as before then that is the correct behavior. Since only 5 of the 16 bits per pixel are used for any given channel, the pixel type is set to uint8.

- the sizeZ is 3. This image is just one channel and one slice bmp image. what does this sizeZ mean? is this related to becoming RGB image when converted?

In your example above, the method calls are in X, Y, Z, C, T order, but the labels on the output are in X, Y, C, Z, T order. Could you please just verify that this is not a problem with the labels? I would expect there to be 3 channels, and it is quite simply not possible for BMP files to have 3 Z sections.

2.
Similarly, when I converted 3 bmp images into one (3-channel) ome-tiff image, the file size becomes bigger than 3 times the each file's size. (3*2.62MB should be 7.86MB, but it became 11.8MB when converted).

In this case, that makes some sense. Each image is 1344 x 1024, and stored as 2 bytes per pixel. However, Bio-Formats must expand the 2 bytes into 3 bytes (one byte per channel), so the total size of each image becomes 4,128,768 bytes - multiplied by 3, that's roughly 11.8 MB.

2.1.
I could open the 3 channel ome-tiff image from ImageJ, but when I tried to import it into OMERO server, it gave the following error.

2011-06-27 14:30:06,506 712203 [2-thread-1] ERROR ome.formats.importer.gui.ImportHandler - Generic error while importing image.
java.lang.IllegalArgumentException: Invalid C index: -1/1
at loci.formats.FormatTools.getIndex(FormatTools.java:296)
at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:449)
at loci.formats.FormatReader.setId(FormatReader.java:1058)
at loci.formats.ImageReader.setId(ImageReader.java:650)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:480)
at loci.formats.ChannelFiller.setId(ChannelFiller.java:244)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:480)
at loci.formats.ChannelSeparator.setId(ChannelSeparator.java:238)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:480)
at ome.formats.importer.ImportLibrary.open(ImportLibrary.java:245)
at ome.formats.importer.ImportLibrary.importImage(ImportLibrary.java:483)
at ome.formats.importer.ImportLibrary.importImage(ImportLibrary.java:433)
at ome.formats.importer.ImportLibrary.importImage(ImportLibrary.java:376)
at ome.formats.importer.gui.ImportHandler.importImages(ImportHandler.java:216)
at ome.formats.importer.gui.ImportHandler.access$100(ImportHandler.java:59)
at ome.formats.importer.gui.ImportHandler$2.run(ImportHandler.java:134)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I assume this is an older (4.1.x or 4.2.x) server? I seem to recall fixing a similar problem a while back, but it might be that the fix is only in 4.3.0. If you can send the OME-TIFF file, I can take a closer look.

Regards,
-Melissa

[bhcho]

Hi Melissa,

Is this the same file that you sent a few days ago?

Yes.

If so, the correct behavior is for there to be 3 channels. There are 16 bits per pixel, but 3 channels are packed into those 16 bits (5 bits per channel, with the highest bit unused).

Are you saying that file originally has 3 channels? (5 bits per channel?). I need to talk to the one who acquired that image, but as far as I know, each pixel was quantized by 12 bits and stored in 2 bytes (16 bits) in one channel.

How did you recognize that the original file has 3 channels?

In your example above, the method calls are in X, Y, Z, C, T order, but the labels on the output are in X, Y, C, Z, T order. Could you please just verify that this is not a problem with the labels? I would expect there to be 3 channels, and it is quite simply not possible for BMP files to have 3 Z sections.

this is my bad. it was C that has 3.

However, Bio-Formats must expand the 2 bytes into 3 bytes (one byte per channel), so the total size of each image becomes 4,128,768 bytes - multiplied by 3, that's roughly 11.8 MB.

Does this mean that the current Bio-Formats does not support 2 bytes per channel (or per pixel) ? Like my case, I have an image, which is quantized by 12 bits. In this case, do I need to downsample it to 8 bit?
I hope I'm misunderstanding something, but If this is the case, I highly recommend you to update the Bio-Formats to handle 2-byte pixel per channel.

I assume this is an older (4.1.x or 4.2.x) server? I seem to recall fixing a similar problem a while back, but it might be that the fix is only in 4.3.0. If you can send the OME-TIFF file, I can take a closer look.

Yes we are using 4.2.1. I upload the converted 3 channel ome-tif file onto your server.
please check it and let me know.

best,
bk

[mlinkert]

Hi BK,

Are you saying that file originally has 3 channels? (5 bits per channel?). I need to talk to the one who acquired that image, but as far as I know, each pixel was quantized by 12 bits and stored in 2 bytes (16 bits) in one channel.

How did you recognize that the original file has 3 channels?

Sorry, this is my mistake. Upon closer investigation, the file does look like it should have 1 channel and 16 bits per channel. What confused me was that all other software that I tried opened this file as 3 channels with 5 bits per channel; in fact, the BMP file format documentation suggests that having a single 16-bit channel is not valid.

In any case, the latest trunk build should open the file as a single channel 16-bit image.

Does this mean that the current Bio-Formats does not support 2 bytes per channel (or per pixel) ? Like my case, I have an image, which is quantized by 12 bits. In this case, do I need to downsample it to 8 bit?
I hope I'm misunderstanding something, but If this is the case, I highly recommend you to update the Bio-Formats to handle 2-byte pixel per channel.

No, not at all. Images with 16 bits per channel are definitely supported, but in the special case where 3 channels are packed into 16 bits some manipulation must occur.

I assume this is an older (4.1.x or 4.2.x) server? I seem to recall fixing a similar problem a while back, but it might be that the fix is only in 4.3.0. If you can send the OME-TIFF file, I can take a closer look.

Yes we are using 4.2.1. I upload the converted 3 channel ome-tif file onto your server.
please check it and let me know.

This file should also open correctly with the latest trunk build.

Regards,
-Melissa