2017.11.11 23:44 "Re: [Tiff] Right way to make a multi-resolution pyramid", by Kemp Watson

As a side point regarding following official specifications, I think it's important to be clear that TIFF has a clear specification, but is owned not by something like ISO, but by a private commercial entity. Not that that is necessarily bad in itself, but the specification is now basically a dinosaur, and is nowhere near up to date with modern imaging needs and uses.

Also important to note that although BigTIFF smells like TIFF, it is _no way_ TIFF. There is _no_ formally adopted BigTIFF spec, especially from Adobe where you would think such a spec would reside. There are Adobe people on this list, I would be very interested to hear about their commitment to maintaining TIFF and BigTIFF as viable standards.

The real utility nowdays of libtiff (for new non-legacy apps) is not to write TIFF files per se, but as a library to easily manage TIFF-derived containers of data, with the added bonus of doing the same with BigTIFF.

That's my take anyway. To handle such a simple issue as supporting PNG tiles, like, 2000-ish, I had to register a private TIFF tag because Adobe never answered my requests for a common tag. How many private PNG tags are there?

W. Kemp Watson
Objective Pathology Services Limited
Halton Data Center
8250 Lawson Road
Milton, Ontario
Canada L9T 5C6

http://www.objectivepathology.com

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

> On Nov 11, 2017, at 4:43 PM, Damir Sudar <dsudar@lbl.gov> wrote:

Indeed unfortunate that there is no proper and spec-compliant approach and also that Adobe as the owner of the spec hasn't stepped up to define the compliant way. While I agree that TIFF itself has many problems for digital pathology, especially multi-channel digital pathology, in its various improper and incompatible varieties, it IS the most commonly used base file format. E.g. Aperio's (now Leica) SVS format is just a BigTIFF with a .svs extension, Hamamatsu's NDPI is mostly a TIFF with a non-compliant header and some other nastiness, and Philips, Ventana, and others use TIFF (or BigTIFF) with a variety of non-standard header info. There is at least a fair bit of support for such files in e.g. Bio-Formats and OpenSlide so I would like to stick as close as possible to such an approach.

And so to avoid inventing yet another image file format, I'm planning, just as you did, to accept the "wrong way" and use BigTIFF and use all top-level IFDs for the resolution levels. May I ask how you encode how many sub-resolution levels (and thus top-level IFDs) there are in the file? I haven't yet figured out how those other vendor-specific TIFF-formats do it.

For much of our software we rely on work by the Open Microscopy Environment's (www.openmicroscopy.org) and via their forum I'm asking them what their plans for supporting pyramids in their OME-TIFF format. Hopefully that can move the needle towards something more compliant or at least standardized.

Cheers,
- Damir

>> On 11/10/2017 18:38, Kemp Wa