bfconvert use wrong tile size during pyramid creation

[iwbh15]

Under specific condition bfconvert uses a wrong tile size for one of the planes during pyramid creation.
('Specific' condition means that the problem does not occur always.
The exact conditions could not be found.
It seems as if the image size has an influence.)

The problem can be reproduced e.g. by converting an 8bit single channel tif file with the command:
bfconvert -tilex 256 -tiley 256 -pyramid-resolutions 8 -pyramid-scale 2 ..\test_1chn_8bit.tif ..\bf_out_1chn_8bit_jpeg_pyr.ome.tif
or
bfconvert -compression JPEG -tilex 256 -tiley 256 -pyramid-resolutions 8 -pyramid-scale 2 ..\test_1chn_8bit.tif ..\bf_out_1chn_8bit_jpeg_pyr.ome.tif

The test image was created with the following ImageJ macro:
newImage("Untitled", "8-bit black", 6400, 6400, 1);
path= "C:/tmp/test_1chn_8bit.tif";
saveAs("Tiff", path);

This problem seems to occur when pyramid tiles are created smaller than the defined tilex/tiley size.
It occurs with other image sizes (<> 6400x6400) but not all.

The windows console output of bfconvert is:

C:\tmp\bftools>bfconvert -no-upgrade -compression JPEG -tilex 256 -tiley 256 -pyramid-resolutions 8 -pyramid-scale 2 ..\test_1chn_8bit.tif ..\bf_out_1chn_8bit_jpeg_pyr.ome.tif
..\test_1chn_8bit.tif
TiffDelegateReader initializing ..\test_1chn_8bit.tif
Reading IFDs
Populating metadata
Checking comment style
Populating OME metadata
[Tagged Image File Format] -> ..\bf_out_1chn_8bit_jpeg_pyr.ome.tif [OME-TIFF]
Tile size = 256 x 256
Converted 1/1 planes (100%)
Tile size = 256 x 256
Converted 1/1 planes (100%)
Tile size = 256 x 256
Converted 1/1 planes (100%)
Tile size = 256 x 256
Converted 1/1 planes (100%)
Tile size = 256 x 256
Converted 1/1 planes (100%)
Tile size = 200 x 163
Converted 1/1 planes (100%)
Tile size = 100 x 100
Converted 1/1 planes (100%)
Tile size = 50 x 50
Converted 1/1 planes (100%)
[done]
10.263s elapsed (74.25+1113.0ms per plane, 719ms overhead)

Plane 6 has a tile size of 200 x 163 instead of 200 x 200.
This information can be found in the image metadata as well.

Because of this wrong tile size (in the image metadata) the correct display of the image can fail (e.g. in Avivator).

Interestingly, the image planes can be opened in ImageJ/FIJI via Bioformats Import correctly.

(Test system: Win10 pro)

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/bfconvert-size-of-smallest-pyramid-level/46282/2

[dgault]

Hi @iwbh15, thank you for raising the issue and providing clear steps to reproduce. The tile sizes themselves are not always guaranteed to be as set, depending on the particular, compression, image size etc there are many factors taken into account when trying to calculate the correct size to be set.

The unusual tile size here is a result of the below decisions being made in the ImageConverter:

• Read the optimal tile width and height from the particular format reader, in this case (6400 x 163) as no tile sizes are present on the original image
• If the requested tile size (256 x256) is less than the width to be saved, then use the requested tile size
• if the tile size is greater than the width/height (as in the case of 200 x 200) then try to use the optimal tile size
• If the optimal tile size is greater than the width/height then use the width/height (which covers the 100 x 100 and 50 x 50 resolutions)

The tile size itself is valid and written correctly, so the image plane should be able to be read as normal. However the ImageConverter should probably take into account the resolution sizes when considering the optimalTileHeight/optimalTileWidth and as such I will leave this issue open.

[ilan-gold]

* if the tile size is greater than the width/height (as in the case of 200 x 200) then try to use the optimal tile size

@dgault How is this optimal tile size determined? You mentioned "6400 x 163" early on in your response but I'm wondering where tis comes from. I think we will try to handle this in Avivator but I am just curious. Also, I want to clarify - the only set of situations where the CLI arguments for tile size are not respected are a subset of the times when the requested tile size is greater than the size of current resolution level?