Original tile size from the source is not used

[fedorov]

It appears that despite the statement documenting the convert() function, which to me anyway appear to claim that original tile size can be requested

wsidicomizer/wsidicomizer/wsidicomizer.py

Lines 85 to 86 in 3a67076

	tile_size: Optional[int] = 512
	Tile size to use if not defined by file.

the actual tile size used by the converter when tile_size is set to None is populated from defailt_tile_size in the package settings:

wsidicomizer/wsidicomizer/sources/openslide_like/openslide_like_image_data.py

Lines 227 to 228 in 3a67076

	if tile_size is None:
	tile_size = settings.default_tile_size

wsidicomizer/wsidicomizer/extras/bioformats/bioformats_image_data.py

Lines 43 to 44 in 3a67076

	if tile_size is None:
	tile_size = settings.default_tile_size

Is this a bug in the implementation, or in describing the parameter? It is most definitely highly desirable to be able to use the original tiles, as is, from the source image while converting.

[erikogabrielsson]

Hi @fedorov
The indented behavior is to always use the original tile size for formats that can be read tile-by-tile. Specifying a tile size should thus only have any effect for images opened by the openslide, tiffslide, czifile, and bioformats-based sources and not for opentile and pyisyntax-based sources.

(However, for NDPI files with opentile the tile size parameter can be used to select the multiple that the stripes are divided into, e.g. if the stripes are 8096 one can get 256, 512, 1024 etc tile size)

If this is not the observed behavior it is a bug. If it is unclear from the documentation it is also a bug.

[fedorov]

The indented behavior is to always use the original tile size for formats that can be read tile-by-tile.

My input file is OME-TIFF, and I would think that it can be read tile-by-tile, but what I observe, as described in the original issue, is that the original tile size is not preserved. I am using TiffSlideSource, because OpenTileSource is failing for the input with a runtime error.

Please let me know if you would like me to share the test image.

[erikogabrielsson]

Hi @fedorov,

If possible please share the test image. I have very few OME-TIFF images in my test data.

[fedorov]

Erik, I am working with the file WD-76845-096.ome.tif from HTAN. To download it, please go to the HTAN Portal https://humantumoratlas.org/explore, navigate to the "Files" tab, and use the search box to locate the file. You will see download instructions. I downloaded it using Gen3 client. The file size is about 11 GB.

[erikogabrielsson]

@fedorov I can´t figure out how to create the credentials.json needed for the download. Do I need an eRA account or similar?

[fedorov]

Erik, don't waste time on this - I will upload to dropbox and share a link with you in a bit.

[fedorov]

@erikogabrielsson you can access a copy of that file from my dropbox here.

[erikogabrielsson]

From tifffile I get that this file contains 7 levels, and each level has one TIffPage and two TiffFrame, like:
TiffPage 0 @11384582655 52303x52470 uint8 minisblack tiled ome
TiffFrame 1 @11384583051 52303x52470 uint8
TiffFrame 2 @11384583407 52303x52470 uint8

I assume these three different fluorescent channels? I have never seen a file with TiffFrame before, but they seam to be convertible to an ordinary TiffPage that opentile does understand how to use (but this might not be the most efficient way).

Another issue is that the image data for the base layer is to big to fit uncompressed in a single instance. I could however successfully convert using compression.

And yet another issue is that the ome-tiff support in OpenTile did not now how to handle multiple optical paths. Instead, all of them are labeled as "0". I got a quick fix but will do more testing.

[fedorov]

I assume these three different fluorescent channels?

Oh no! That file that I shared with you - that is an H&E, with RGB encoded as separate channels! I was able to convert it, and experimented with both uncompressed and J2K, and I was able to open the result both in QuPath and Slim - I didn't complete that, since it looked promising, and so I moved on to the multichannel file (the one I mention in #143). I thought I was able to encode the base layer, but maybe I missed something. I need to revisit.

[fedorov]

You can see it is RGB from the OME-TIFF header from tiffinfo:

=== TIFF directory 0 ===
TIFF Directory at offset 0x2a692f1ff (11384582655)
  Subfile Type: (0 = 0x0)
  Image Width: 52470 Image Length: 52303
  Tile Width: 1024 Tile Length: 1024
  Resolution: 30769, 30769 pixels/cm
  Bits/Sample: 8
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Samples/Pixel: 1
  Planar Configuration: single image plane
  SubIFD Offsets: 11384577543 11384577819 11384578095 11384578371 11384578647 11384578923
  ImageDescription: <?xml version='1.0' encoding='utf-8'?>
<OME xmlns="http://www.openmicroscopy.org/Schemas/OME/2016-06" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" UUID="urn:uuid:f577de44-60f2-4f56-8e9b-d3a9d9f6b404" xsi:schemaLocation="http://www.openmicroscopy.org/Schemas/OME/2016-06 http://www.openmicroscopy.org/Schemas/OME/2016-06/ome.xsd"><Image ID="Image:0"><Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:0" PhysicalSizeX="0.32499998807907104" PhysicalSizeXUnit="µm" PhysicalSizeY="0.32499998807907104" PhysicalSizeYUnit="µm" SizeC="3" SizeT="1" SizeX="52470" SizeY="52303" SizeZ="1" Type="uint8"><Channel ID="Channel:0:0" Name="Red" SamplesPerPixel="1"><LightPath /></Channel><Channel ID="Channel:0:1" Name="Green" SamplesPerPixel="1"><LightPath /></Channel><Channel ID="Channel:0:2" Name="Blue" SamplesPerPixel="1"><LightPath /></Channel><TiffData IFD="0" PlaneCount="3" /><Plane TheC="0" TheT="0" TheZ="0" /><Plane TheC="1" TheT="0" TheZ="0" /><Plane TheC="2" TheT="0" TheZ="0" /></Pixels></Image></OME>
  Software: pyramid_upgrade.py (was Ashlar v1.11.0+1.g93fd92a (Glencoe/F*a*a*s pyramid output))
  DateTime: 1970:01:01 00:00:00
--- SubIFD image descriptor tag within TIFF directory 0 with array of 6 SubIFD chains ---

[erikogabrielsson]

Ok. Now that makes sense.

Cool that tiffslide can properly read the multipage levels as RGB. Good job @ap--.
opentile is primary designed to allow reading raw tiles from compressed images to avoid re-compression. For slides like this (uncompressed) it does not offer any advantage compared to tiffslide.

For this issue, I think what is needed is better documentation of what the tile_size parameter does for different source image types.