BUG: Import 8kx8k.tif

[ajpatterson]

If you select the file 8kx8k.tif and hit [+] you get a Processing Files dialog that keeps going for a long time, at least 30 mins on my Vistual WinXP machine.

[ajpatterson]

After cancelling the dialog any further adds get "No importable found in this selection"

[ajpatterson]

After discussion with Chris these file have been moved out of the test-image-good/tif folder to a tiff-big-images folder as the very slow response is expected.

Leaving ticket open as cancelling the Processing Files should not cause "No importable found in this selection" problem

[jburel]

Following discussion with Andrew, the fact that it takes a long time is something we cannot address now.
The import UI indicates that it is possible to cancel, The "processing" box is no longer displayed but actually the "processing" is still on-going. Nothing we can do at the moment.

[mlinkert]

Re-assigning to Chris, as this looks to be a bug in the importer. Let me know if I need to investigate anything in Bio-Formats (or if you want help with testing etc.).

[cxallan]

With default memory sizes being what they are and the image in question being just one large 8K by 8K block without tiling the Bio-Formats setId() time is incredibly slow with the reader stack we are using. What happens during "processing" is that the file is evaluated for its "candidates", for which metadata must be parsed. Especially on a machine with limited resources this can be a huge problem.

As we are using the ChannelFiller and ChannelSeparator wrapper classes (for which we may be able to avoid for the purposes of the above checks) we incur at least one full plane read for the above use case as ChannelFiller has in its setId() implementation:

...
265     // NB: For some formats, LUTs are plane-specific and will
266     // only be available after opening a particular image plane.
267     reader.openBytes(0, 0, 0, 1, 1); // read a single pixel, for performance
...

[cxallan]

Original commit where the openBytes() call was added: [59284f3840d9ad7c7824bf69f60b5b9edd218f7a/bioformats.git].

[cxallan]

Replying to jburel:

Following discussion with Andrew, the fact that it takes a long time is something we cannot address now.
The import UI indicates that it is possible to cancel, The "processing" box is no longer displayed but actually the "processing" is still on-going. Nothing we can do at the moment.

The Importer actions, with respect to cancellation, will be handled as part of #7206.

[Melissa Linkert <melissa@…>]

(In [5e343246191e8cdee25e43993115bb9bf347277d/bioformats.git]) Ensure that a LUT is available once setId returns.

Previously, some readers for formats which stored one LUT per plane
would return null on calls to get*LookupTable?() that occurred prior to a
call to openBytes(...). Now, get*LookupTable?() will return the LUT of
the 0th plane when called immediately after setId(...).

Most importantly, this means that we can eliminate the call to openBytes
in ChannelFiller?.setId(...), the sole purpose of which was to ensure
that the LUT for plane #0 was available immediately.

Closes #7009.

[Melissa Linkert <melissa@…>]

(In [5e343246191e8cdee25e43993115bb9bf347277d/bioformats.git]) Ensure that a LUT is available once setId returns.

Previously, some readers for formats which stored one LUT per plane
would return null on calls to get*LookupTable?() that occurred prior to a
call to openBytes(...). Now, get*LookupTable?() will return the LUT of
the 0th plane when called immediately after setId(...).

Most importantly, this means that we can eliminate the call to openBytes
in ChannelFiller?.setId(...), the sole purpose of which was to ensure
that the LUT for plane #0 was available immediately.

Closes #7009.