Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #13188 (new)

Opened 8 years ago

Last modified 8 years ago

Bug: Additional tiling defects

Reported by: rleigh Owned by:
Priority: minor Milestone: Pyramids
Component: Bio-Formats Version: Bio-Formats-5.1.8
Keywords: n.a. Cc:
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description (last modified by 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:

BitsPerSample?=1 BIT pixel type with padding for strip scanlines:

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.

Attachments (1)

test-data.tar.xz (3.7 MB) - added by rleigh 8 years ago.
Test data files

Change History (6)

Changed 8 years ago by rleigh

Test data files

comment:1 Changed 8 years ago by rleigh

  • Description modified (diff)

comment:2 Changed 8 years ago by mlinkert

  • Owner mlinkert deleted

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

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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.

comment:5 Changed 8 years ago by sbesson

  • Milestone changed from Unscheduled to Pyramids
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.89028 sec.)

We're Hiring!