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

JPEG 2000 is, I believe, not well suited to DP, despite the larger DP companies pushing it quite heavily. Codecs are getting _slightly_ faster, to the point where they are only 6-10x slower than JPEG; but to pay $11K a pop for the _real_ performant decoder? JP2 as an open standard is a sham.

Suitable for use on big, large-hospital dedicated hardware with native decoders and networks that can handle the abysmally slow JP2 streaming. But what about over the web? Even with a lossless codec there will be _substantial_ loss on any browsers other than Safari - and the promise of digital pathology is not just intra-institution, but out over the web, too.

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 6:02 PM, Aaron Boxer <boxerab@gmail.com> wrote:

Don't mean to hijack the thread, but why not lossless JPEG 2000 for digital pathology?

Yes, it is a lot slower, but lately the open source codecs have matured and performance is improving.

Also, storage size would be a lot lower: 2:1 compression, and pyramid is built into the format.

Pathology images are quite large, but JPEG 2000 supports decoding a small sub-region.

> On Sat, 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 Watson wrote:

>> > As far as I can see, absolutely EVERYONE violates the TIFF standard, or at

least it¹s intent, when it come to zoomable images.

Everyone seems to be storing resolution levels in pages (top-level IFDs), as opposed to SubIFDs, when SubIFDs exist to represent alternative views of the SAME image, which is what a resolution level is. Also, most everyone still names their files with a .tif extension, a non-no per the spec. My take, apparently alone.

We¹re attempting to address the standardization of a common subset, 3-channel 8-bit zoomable images, for web viewing, via ZIF (a BigTIFF-derived format, not TIFF), but this won¹t help you with

>> > multispectral imagesŠ even for our use case, we¹re stuck with doing it the

³wrong² way as a less-favoured option.

If you¹re dealing with