2017.05.22 15:31 "Re: [Tiff] JPEG compressed RGB tiled TIFF with chroma subsampling", by Kemp Watson

JPEG-in-TIFF is not a TIFF 6.0 compliant file. Many readers/writers out there understand TIFF 6.0, but not TechNote #2. TIFF is a container format, there is no way any reader or writer can know the entire spectrum of items that could potentially be put in a TIFF file.

Similarly, the newer BigTIFF is also not TIFF 6.0 compliant, and many applications have no clue about it.

Tiles/strips is a critical difference to many applications. If it was abstracted away, entire businesses would cease to exist - not a pesky detail in the least for geospatial, astronomy, or microscopy applications.

W. Kemp Watson
kemp@objectivepathology.com

Objective Pathology Services Limited

8250 Lawson Road
Milton, Ontario
Canada L9T 5C6

www.objectivepathology.com
tel. +1 (416) 970-7284

From: <tiff-bounces@lists.maptools.org> on behalf of Yakov Galka <ybungalobill@gmail.com>

On Thu, May 11, 2017 at 11:48 PM, <jcupitt@gmail.com> wrote:

I don't think I've come across a reader which doesn't handle this case. Almost all jpeg-in-tiff files use this mode, so you really have to.

I take my words back. The only viewers that worked were mspaint and the windows photo viewer. IIPImage seems to have tried to support it but has a bug and fails. OpenCV imread fails. Pretty much every code that does not expect to handle this case *specifically* fails. Which I expect to be the majority of TIFF reading code in the wild.

It's arguably a basic misdesign with tiff: writers are simple (you can describe almost any pixel layout with a tiff header), but readers are hard (you have to be able to read almost any pixel layout),

I expect libTIFF to abstract those differences. It is not the only thing that libTIFF chooses to shift the responsibility onto the user of the library even though it could just as cheaply hide those pesky details. Another example would be the tile/strip discrepancy.