Tiff stored the IJ2 way don't open correctly in IJ/Fiji

Usage & Issues
, , , ,
#1

You want to experience the problem yourself? Please download this tiff file and do the following:

  1. Drag and drop the downloaded file into Fiji (or IJ).
  2. In Fiji go to ‘Edit - Options - ImageJ2’ and turn on SCIFIO.
  3. Drag and drop the downloaded file into Fiji (or IJ) again.

Putting the two files next to each other they look like this:

812×316 33.5 KB

This should convince you that we have a problem.

Now a bit more in depth: how did I create the tiff file in the first place?

I am not sure if this is the best way to do it (certainly it is not very compact), but it is the only way I know at the moment and a few weeks ago it seemed the only way to do it:

final DatasetService datasetService = context.getService( DatasetService.class );
final Dataset dataset = datasetService.create( rai );
final DatasetIOService service = context.getService( DatasetIOService.class );
try {
	service.save( dataset, filename );
} catch ( final IOException exc ) {
	exc.printStackTrace();
}

Does anybody have an idea what is going on? The problem started occurring somewhere within the last few weeks…

Thanks for your help,
Florian
:slight_smile:

PS: there is more problems… check out this file: flow.tif
Opened with Fiji without SCIFIO it is a stack with 50 slices. Using SCIFIO it is a single slice!!! My tools are all broken at the moment…

PPS: yet another issue regarding image saving (very different behavior with IJ vs. IJ2)
The following code creates a flattened stack [512,256,50]…

try {
	new ImgSaver().saveImg( filename, ImgView.wrap( rai, null ) );
} catch ( ImgIOException | IncompatibleTypeException e ) {
	e.printStackTrace();
}

… while the following IJ1 alternative…

final ImagePlus ip = ImageJFunctions.wrap( flow, "flow" );
IJ.save( ip.duplicate(), fileFlow.getAbsolutePath() );

does what I expected both snippets to do and stores a HyperStack [512,256,2,25].

2 Likes
#2

Hi @fjug,

final Dataset dataset = datasetService.create( rai );

will create a Dataset from a RandomAccessibleInterval (in your case, I guess). Depending on the type, and thus the “information content”, this Dataset will barely contain any meta data (like scaling).

Best,
Stefan

#3

Hi Stefan,

that is ok, but the issue obviously is not a metadata problem, is it?
Above I show slice 8, some others look almost fine, yet others are half image half black with white speckles.

Something is way more broken here then only the metadata… :frowning:

Florian

#4

Looking at the images again, you might be right. I’ll have to finish something else first and then I’ll get back to you :slight_smile:

#5

You can always import the images that you have saved with SCIFIO via File > Import > Image…

I can, however, reproduce the issue with your uploaded files. There is a difference between how the TIFFs are structured but I had hoped that SCIFIO can handle ImageJ TIFFs (which as far as I can remember, it did up until recently).

#6

Thanks a lot for looking into this.

#7

Hi @all,
any news regarding this matter?
Florian

#8

Hi @fjug,

I haven’t had time to talk to @ctrueden about this properly. Sorry about that!

The issue here is the way ImageJ1 stores TIFF files. From my investigations, a three-slice TIFF files produced by ImageJ1 have the following structure

IDF
Pixels
Pixels
Pixels
IDF
IDF

while SCIFIO expects

IDF
Pixels
IDF
Pixels
IDF
Pixels

(and, naturally, the other way around).

Best,
Stefan

#9

Thanks for your reply and efforts to investigate.

#10

@stelfrich and I took a closer look. So far, signs point to a bug in IJ1’s TIFF reader, which is known to take shortcuts for that sake of performance that can potentially compromise the correctness of TIFF reading. I will be debugging in more detail today, to see whether it is possible to fix the IJ1 TIFF reader to handle such TIFFs correctly, without compromising the performance.

For flow.tif, I think there is a bug in the SCIFIO reader. At a glance, the metadata looks OK:

axes=X,Y,Unknown,Unknown
lengths=512,256,2,25

Although because the two non-planar axes are not assigned, ImageJ 1.x just reads it as 50 planes and loses the 2x25 division. The way to fix this is to make sure you are writing an ImgPlus (or Dataset wrapping an ImgPlus) with properly assigned axis types—see below. But even then, without checking more closely I am not certain whether SCIFIO currently writes the TIFF in a way that ImageJ 1.x will parse correctly as a hyperstack—I suspect not.

I will debug this issue after investigating the first problem with input_scaled.tif.

Yes, because you use ImgView.wrap, which produces an Img with no axis metadata. You need to say e.g. new ImgPlus(ImgView.wrap(...), "My image", new AxisType[] {Axes.X, Axes.Y, Axes.CHANNEL, Axes.Z}) to indicate that the image is XYCZ data.

The reason ImageJFunctions.wrap works is because it assumes ImageJ 1.x’s one canonical order XYCZT, mapping your 3rd dimension to C and 4th to Z. ImageJ 1.x then saves the 4-dimensional ImagePlus as you desire.

Axis metadata is something very important, but currently very tricky in ImageJ2 because you need to make sure the object is always a net.imagej.ImgPlus with the right axes. Any time you do anything with lower-level ImgLib2 calls such as Views, or even ImageJ Ops right now for that matter, the metadata is lost. Of course there are plans :wink: to improve this: the so-called “rich image” work which is currently 5th on my list of priorities.

1 Like
#11

Indeed, ImageJ1 assumes TIFFs to only have one strip per plane unless they are compressed (see https://github.com/imagej/ImageJA/blob/v1.51h/src/main/java/ij/io/ImageReader.java#L201-L202), which @fjug’s first test file isn’t.

1 Like
#12

According to the history, this change was made in May of 2014:

Thanks to Tara Ficken, fixed bugs that caused some float and int32 TIFFS to be read incorrectly.

@Wayne Do you recall the rationale? Do you still have a test TIFF? From my naive perspective, the TIFF reader should not be attempting to decode compressed data unless the compression scheme is actually set. The input_scaled.tif file (same link as the original post above) provides an example of this bug in action.

#13

This bug is fixed in the latest ImageJ daily build (1.51k7). The TiffDecoder was incorrectly assuming that TIFF files with image description tags containing “images=n” were created by ImageJ.

2 Likes
#14

Thank you, Wayne!

This bug was an issue with imagej-common, which is now fixed. Will upload the fix after NEUBIAS2020.

2 Likes
#15

All of you: thank you for your efforts. You are all amazing and I love you!

3 Likes