Bug: Additional tiling defects

[rleigh]

This is a followup ticket for ​https://trac.openmicroscopy.org/ome/ticket/12596
While expanding the coverage of the C++ test cases, I've identified some additional variants which aren't properly handled.

Tile height greater than image height:
int8/data-layout-int8-32x32planar-pi1-tile-32x48-ordered-optimal.tiff
int8/data-layout-int8-32x32planar-pi1-tile-32x64-ordered-optimal.tiff
int8/data-layout-int8-32x32planar-pi2-tile-32x48-ordered-optimal.tiff
int8/data-layout-int8-32x32planar-pi2-tile-32x64-ordered-optimal.tiff
int8/data-layout-int8-32x37planar-pi1-tile-32x48-ordered-optimal.tiff
int8/data-layout-int8-32x37planar-pi1-tile-32x64-ordered-optimal.tiff
int8/data-layout-int8-64x32planar-pi1-tile-64x48-ordered-optimal.tiff
int8/data-layout-int8-64x32planar-pi1-tile-64x64-ordered-optimal.tiff

BitsPerSample?=1 BIT pixel type with padding for strip scanlines:
bit/data-layout-bit-43x32chunky-pi1-strip-14-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi1-strip-2-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi1-strip-32-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi1-strip-5-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi1-tile-16x16-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi1-tile-16x32-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi1-tile-32x64-ordered-optimal.tiff
bit/data-layout-bit-43x32chunky-pi2-tile-16x32-ordered-optimal.tiff

For the bit data, it looks like it's mainly restricted to chunky rather than planar data, though there are several hundred failing cases; I've just included a small selection here. The attached archive has a fairly comprehensive test set of many variants, which can be e.g. imported into OMERO in bulk to view.

For the bit data, I'm also not 100% sure if the samples here are correct. They might be, but I can't confirm it definitively without some other software capable of reading them, since the C++ unit tests only check if that the data round-trips and compares with a PNG reference image; it can't objectively test whether the packing is correct if it is writing and reading it using an incorrect assumption. All of the other software I tested with mishandles chunky bitmasks.

[rleigh]

Test data files

[mlinkert]

To clarify, is this a problem in both Java and C++?

[rleigh]

This is for Java. Sorry for being unclear. For C++, it's handling everything *I think*. The images indicated in the description, and others with similar tiling patterns, are garbled when viewed with the Java code or OMERO. While the C++ code should be correct, I can't rule out that the TIFF files themselves were incorrectly written in the absence of any other software which can read them. However, I think it's more likely that the Java TIFF reader is mishandling these cases. For example, it looks like when given planar data where the y tile size is greater than the image size, that it's not advancing to the next tile start, which leads to the shift of the following planes by the difference between the tile size and the image size. Likewise for the handling of chunky bitmasks.

[rleigh]

I should add that this is working for all pixel types and all image sizes where the image size and tile size are reasonable numbers. I've deliberately added test cases here which are using "unusual" image sizes and tile sizes, with the intent of testing all the odd edge cases and flushing out any misbehaviour. For the C++ code, the only problem I found was with the padding for bit masks when the image size is not a multiple of 8; libtiff seems to be handling all of the strips and tiles correctly with all the odd sizes.