blobs.gif opens as 3-channel image

[haesleinhuepf]

Dear all,

I just tried opening blobs.gif using scifio in imagej environment. The code looks like this:

File file = new File("src/main/resources/blobs.gif");
final Dataset dataset = ij.scifio().datasetIO().open(file.getPath());

// show the image
ij.ui().show(dataset);
System.out.println("Number of channels: " + dataset.getChannels());

The image opens as three channel image even though it was saved as single channel gif.

Is there a way to open it correctly or is this a bug?

Thanks!

Cheers,
Robert

[imagejan]

I also observed this, but thought it is intentional: the GIF format defines a palette with a subset of 256 colors (out of the 24-bit RGB colors) for each image. As such, gif images are always color images.

My understanding was that ImageJ1 takes a shortcut here and displays the image as 8-bit if it detects that the R, G and B channel values are the same at each pixel position (i.e. if the image is grayscale).
If you open blobs.gif with a different application, e.g. Preview on Mac OS, it reports RGB correctly, so why shouldn't SCIFIO also open it as RGB?

If we want a true 8-bit sample image, we shouldn't use GIF.

[ctrueden]

ImageJ1 takes a shortcut here

I would call it a hack, not a shortcut. It might be highly unexpected for the user to receive a single-channel uint8 image even though the file on disk is stored as RGB.

If we want a true 8-bit sample image, we shouldn't use GIF.

Yes, PNG is better for that.

[frauzufall]

@imagejan @ctrueden I just came across this and find it highly irritable that it has 3 channels in IJ2, especially since it's often used as an example image in workshops etc.. So this might also be weird for anyone working with Macros / Scripts in ImageJ in the past. I would have expected the indexed palette to be loaded as a LUT and not as RGB channels, but I also don't know anything about how LUTs are implemented.

[ctrueden]

@frauzufall There are three kinds of indexed color images:

1. False color images - where the indices are the data (e.g. intensity values), and the LUTs are just for decoration to aid the human eye.
2. Non-false color images - where the indexed color storage was used as a sort of compression, such that the lookup table values are the actual data.
3. Images where we don't know the intent.

The Bio-Formats library provides the boolean IFormatReader#isFalseColor() method to report this on a file-by-file basis, although in nearly all cases, it's just a characteristic of the file format itself—i.e., I don't know of any formats where some files in that format are false color, and others are non-false color.

Format	False color
APNG	no
AVI	no
BMP	no
Dicom	no
EPS	no
Fake	sometimes
Fits	no
GIF	no
ICS	no
ImageIO	no
LegacyQT	no
MNG	no
Micromanager	no
NRRD	no
NativeQT	no
OMETiff	yes
OMEXML	yes
PGM	no
Pict	no
TiffJAI	no
Alicona	no
BaseZeiss	yes
BioRad	yes
CellSens	no
Deltavision	no
FV1000	yes
Gatan	no
IPLab	no
Imaris	no
IonpathMIBITiff	no
JPK	no
Khoros	no
LIF	yes
LIM	no
LegacyND2	no
Leica	yes
LeicaSCN	no
LiFlim	no
LiFlim	no
MRC	no
NDPI	no
NativeND2	yes
OIR	yes
OpenlabRaw	no
Openlab	no
PCI	no
PQBin	no
PSD	no
PerkinElmer	no
Prairie	no
PyramidTiff	no
SDT	no
SPC	no
SVS	no
Slidebook	no
TCS	yes
Targa	no
Trestle	no
Vectra	no
Visitech	no

I extracted this information from the Bio-Formats source code using this invocation:

git grep 'falseColor ='|sed 's_.*loci/formats/in/\([A-Za-z0-9]*\)Reader\.java:.*\.falseColor = \(.*\);_\| \1 \| \2 \|_' | grep '|' | sed 's/| false |/| no |/' | sed 's/| true |/| yes |/' | pbcopy

Note that Bio-Formats has no capacity for (3) above—for every data source, it makes either false color or non-false color judgment, according to the table above.

As you can see, GIF files are treated as non-false color, meaning their data is assumed to be the lookup table values rather than the indices of the table. This is vital for cases where the LUT is not just a trivial grayscale map, but actually representing the actual color values of e.g. an image acquired by a typical camera. Treating the indices as the values would be wrong here.

So, I know it's annoying that the Blobs image is reported as RGB, but the fact is that GIF files do have three channels like that. The fact that the values are encoded using 8-bit indexed color is an internal implementation detail that should not be exposed by Bio-Formats or SCIFIO (which has analogous logic here).

The solution here is not to change ImageJ, but to stop using blobs.gif for demos.

[frauzufall]

@ctrueden Thank you for the detailed explanation! Since I am working on some examples which use the blob image (also https://imagej.nih.gov/ij/images/t1-head.gif) I would like to switch appropriately - I could save the blob and the head as TIF and request an upload to https://samples.fiji.sc/? Is there a better place?

[ctrueden]

Even setting aside the GIF format issue, I suggest caution with the Blobs image, because:

1. It is a 5-bit image upsampled to 8-bit. So there are gaps in the histogram, which make the analysis a bit weird.
2. It has an inverted LUT, meaning low values are bright, and high values are dark. Although converting it to something else addresses this.

That said, if you really want to continue using it, I think posting a converted version of it to https://samples.fiji.sc would be OK. I tested conversion to a couple different formats:

$ bfconvert -separate -nolookup -channel 0 blobs.gif blobs.tif
$ bfconvert -compression LZW -separate -nolookup -channel 0 blobs.gif blobs-lzw.tif
$ bfconvert -separate -nolookup -channel 0 blobs.gif blobs.png
$ for f in blobs*; wc -c "$f"
   47166 blobs-lzw.tif
   25765 blobs.gif
   21230 blobs.png
   67365 blobs.tif

So PNG is the winner here. Therefore may I present... https://samples.fiji.sc/blobs.png !

[frauzufall]

Thank you! I would also use a different picture as long as it is a motivating example for Biologists and easy to show blur / segmentation / cell counting.

[haesleinhuepf]

Hey @ctrueden, hey @frauzufall ,

I just observed an issue on computers of students and I think it's related to this issue here. After running "Cache sample images" in Fiji, opening blobs.gif from the samples opens a bioformats dialog. An error message later, blobs opens properly. Thus, it is no longer possible to open blobs from a macro, because it opens a bioformats window instead of opening the image.

To reproduce this issue:

• Execute File > Samples > Cache Sample Images
• Afterwards, run this macro:

run("Blobs (25K)");

These windows pop up:

Are you sure that there is everything alright with the cached blobs.gif image?

Thanks!

Cheers,
Robert

[ctrueden]

Are you sure that there is everything alright with the cached blobs.gif image?

I don't know. This is an ImageJ1 feature, implemented here. The fact that it tries to use Bio-Formats is odd. Possible culprits:

• Was the image misdownloaded/miscached, and thus misdetected? Check in the samples folder to make sure it opens outside ImageJ as normal.
• Is the "Use SCIFIO" checkbox under Edit > Options > ImageJ2 checked? I'd be surprised if this is the cause, but worth checking anyway.

Do you have time to research this further yourself? I am juggling too many other things right now: updating from maven.imagej.net to maven.scijava.org; completing the SCIFIO release; releasing other ImageJ & Fiji components in general.

[haesleinhuepf]

Do you have time to research this further yourself?
This has no high priority, as only the people are affected who cached the images. But it's reproducibly between different machines.

I can dig deeper in approx 4-5 weeks. Thanks for the hints so far!

Cheers,
Robert