Right way to make a multi-resolution pyramid

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Right way to make a multi-resolution pyramid

Kemp Watson-2
Hi all:

What is the “correct” or canonical way to make a (tiled) multi-resolution pyramid in TIFF?

Most implementations I’ve seen simply chain top-level IFDs together, starting with the base or full-res layer, and going smaller from there to the apex. this seems wrong to me.

The description of the SubIFD tag indicates it should be used for reduced-resolution images. To make matters more complex, the NewSubfileType tag, which appears to be a different “sub-file” type than a SubIFD, since it can be used for top-level pages/images, also indicates a value for a reduced-resolution image.

And, if a SubIFD is used, should it point to a chain of IFDs at the second level, or to an image with a SubIFD pointing to an image, ongoing recursively (which appears to me most correct, but most complex)?

W. Kemp Watson


Objective Pathology Services Limited
www.objectivepathology.com
tel. +1 (416) 970-7284


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Kemp Watson-2
Oh, and one more option: Base image has a single Sub-IFD tag, pointing to an array of all the reduced-resolution images.

I can’t seem to find a full explanation of the right way to make a pyramid.

W. Kemp Watson


Objective Pathology Services Limited
www.objectivepathology.com
tel. +1 (416) 970-7284


From: Watson Kemp <[hidden email]>
Date: Monday, November 14, 2016 at 1:16 PM
To: <[hidden email]>
Subject: Right way to make a multi-resolution pyramid

Hi all:

What is the “correct” or canonical way to make a (tiled) multi-resolution pyramid in TIFF?

Most implementations I’ve seen simply chain top-level IFDs together, starting with the base or full-res layer, and going smaller from there to the apex. this seems wrong to me.

The description of the SubIFD tag indicates it should be used for reduced-resolution images. To make matters more complex, the NewSubfileType tag, which appears to be a different “sub-file” type than a SubIFD, since it can be used for top-level pages/images, also indicates a value for a reduced-resolution image.

And, if a SubIFD is used, should it point to a chain of IFDs at the second level, or to an image with a SubIFD pointing to an image, ongoing recursively (which appears to me most correct, but most complex)?

W. Kemp Watson


Objective Pathology Services Limited
www.objectivepathology.com
tel. +1 (416) 970-7284


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Dmitry Fedorov-2
In reply to this post by Kemp Watson-2
Hi Kemp,

I personally prefer the Photoshop way using SUBIFD with properly set SUBFILETYPE within the reduced resolution subifd. This way normal ifds will be interpreted well by readers not understanding the pyramid and one could store Z or T slices without worries. At the same time most readers that do understand pyramids and tiles (OpenSlide or Photoshop for example) will read those sub-ifds.

-dmitry


On Mon, Nov 14, 2016 at 11:16 AM, Kemp Watson <[hidden email]> wrote:
Hi all:

What is the “correct” or canonical way to make a (tiled) multi-resolution pyramid in TIFF?

Most implementations I’ve seen simply chain top-level IFDs together, starting with the base or full-res layer, and going smaller from there to the apex. this seems wrong to me.

The description of the SubIFD tag indicates it should be used for reduced-resolution images. To make matters more complex, the NewSubfileType tag, which appears to be a different “sub-file” type than a SubIFD, since it can be used for top-level pages/images, also indicates a value for a reduced-resolution image.

And, if a SubIFD is used, should it point to a chain of IFDs at the second level, or to an image with a SubIFD pointing to an image, ongoing recursively (which appears to me most correct, but most complex)?

W. Kemp Watson


Objective Pathology Services Limited
www.objectivepathology.com
tel. <a href="tel:%2B1%20%28416%29%20970-7284" value="+14169707284" target="_blank">+1 (416) 970-7284


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/



--
__________________________________

Dmitry Fedorov Levit <[hidden email]>
Web: http://www.dimin.net/
__________________________________

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Even Rouault-2
In reply to this post by Kemp Watson-2
On lundi 14 novembre 2016 13:16:25 CET Kemp Watson wrote:
> Hi all:
>
> What is the ³correct² or canonical way to make a (tiled) multi-resolution
> pyramid in TIFF?
>
> Most implementations I¹ve seen simply chain top-level IFDs together,
> starting with the base or full-res layer, and going smaller from there to
> the apex. this seems wrong to me.

This is indeed the accepted practice in the geospatial field for example. I've
never seen use of SubIFD mechanism.
Normal chaining + use of NewSubfileType = FILETYPE_REDUCEDIMAGE is sufficient
if you have only one full-res layer.

>
> The description of the SubIFD tag indicates it should be used for
> reduced-resolution images. To make matters more complex, the NewSubfileType
> tag, which appears to be a different ³sub-file² type than a SubIFD, since it
> can be used for top-level pages/images, also indicates a value for a
> reduced-resolution image.
>
> And, if a SubIFD is used, should it point to a chain of IFDs at the second
> level, or to an image with a SubIFD pointing to an image, ongoing
> recursively (which appears to me most correct, but most complex)?

From what I can see in libtiff code
( https://github.com/vadz/libtiff/blob/master/libtiff/tif_dir.c#L430) ,  
attaching a SubIFD to a SubIFD insn't supoprted on the write side.

>
> W. Kemp Watson
> [hidden email]
>
>
> Objective Pathology Services Limited
> www.objectivepathology.com
> tel. +1 (416) 970-7284


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Olivier Paquet-2
In reply to this post by Kemp Watson-2

2016-11-14 13:16 GMT-05:00 Kemp Watson <[hidden email]>:
What is the “correct” or canonical way to make a (tiled) multi-resolution pyramid in TIFF?
 
Hard to say for sure given that the TIFF specification is not very well maintained. But I would lean toward your suggestion of:

Oh, and one more option: Base image has a single Sub-IFD tag, pointing to an array of all the reduced-resolution images.

However I've never tried it so there might be reasons it is not practical.

Most implementations I’ve seen simply chain top-level IFDs together, starting with the base or full-res layer, and going smaller from there to the apex. this seems wrong to me.
 
I don't know which implementations you're looking at but that's what is done in our domain. We did it that way to be compatible with others. And when they decided to do it that way, it's likely that the sub-IFD tag wasn't around yet. It causes some problems but not enough to bother change the format (for us anyway).

Olivier 

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Kemp Watson-2
In reply to this post by Even Rouault-2
Thanks for all the various opinions. I take it this means there is NO
prescribed “right way” to make image pyramids within the TIFF
specification; especially since a subresolution subimage of a
subresolution subimage is unimplemented in libtiff (which, though not the
TIFF spec, appears to be the defacto go-to implementation), and that’s the
very definition of an image pyramid :(

W. Kemp Watson

[hidden email]




On 2016-11-14, 2:02 PM, "Even Rouault" <[hidden email]> wrote:

>On lundi 14 novembre 2016 13:16:25 CET Kemp Watson wrote:
>> Hi all:
>>
>> What is the ³correct² or canonical way to make a (tiled)
>>multi-resolution
>> pyramid in TIFF?
>>
>> Most implementations I¹ve seen simply chain top-level IFDs together,
>> starting with the base or full-res layer, and going smaller from there
>>to
>> the apex. this seems wrong to me.
>
>This is indeed the accepted practice in the geospatial field for example.
>I've
>never seen use of SubIFD mechanism.
>Normal chaining + use of NewSubfileType = FILETYPE_REDUCEDIMAGE is
>sufficient
>if you have only one full-res layer.
>
>>
>> The description of the SubIFD tag indicates it should be used for
>> reduced-resolution images. To make matters more complex, the
>>NewSubfileType
>> tag, which appears to be a different ³sub-file² type than a SubIFD,
>>since it
>> can be used for top-level pages/images, also indicates a value for a
>> reduced-resolution image.
>>
>> And, if a SubIFD is used, should it point to a chain of IFDs at the
>>second
>> level, or to an image with a SubIFD pointing to an image, ongoing
>> recursively (which appears to me most correct, but most complex)?
>
>From what I can see in libtiff code
>( https://github.com/vadz/libtiff/blob/master/libtiff/tif_dir.c#L430) ,
>attaching a SubIFD to a SubIFD insn't supoprted on the write side.
>
>>
>> W. Kemp Watson
>> [hidden email]
>>
>>
>> Objective Pathology Services Limited
>> www.objectivepathology.com
>> tel. +1 (416) 970-7284
>
>
>--
>Spatialys - Geospatial professional services
>http://www.spatialys.com


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Paavo Helde
In reply to this post by Kemp Watson-2

On 14.11.2016 20:16, Kemp Watson wrote:
> Hi all:
>
> What is the “correct” or canonical way to make a (tiled)
> multi-resolution pyramid in TIFF?
>
> Most implementations I’ve seen simply chain top-level IFDs together,
> starting with the base or full-res layer, and going smaller from there
> to the apex. this seems wrong to me.

You are right, sub-IFDs would be more appropriate. However, sub-IFDs are
not so well supported by various TIFF readers. That was the reason why
in my company when they were working out the pyramidal TIFF schema a
couple of years ago they still went with top-level IFD-s.

Cheers
Paavo

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Roger Leigh
On 14/11/2016 21:16, Paavo Helde wrote:

>
> On 14.11.2016 20:16, Kemp Watson wrote:
>> Hi all:
>>
>> What is the “correct” or canonical way to make a (tiled)
>> multi-resolution pyramid in TIFF?
>>
>> Most implementations I’ve seen simply chain top-level IFDs together,
>> starting with the base or full-res layer, and going smaller from there
>> to the apex. this seems wrong to me.
>
> You are right, sub-IFDs would be more appropriate. However, sub-IFDs are
> not so well supported by various TIFF readers. That was the reason why
> in my company when they were working out the pyramidal TIFF schema a
> couple of years ago they still went with top-level IFD-s.

That's the way one of the Bio-Formats readers handles it as well:

https://github.com/openmicroscopy/bioformats/blob/develop/components/formats-gpl/src/loci/formats/in/PyramidTiffReader.java 
(loop at line 129 just iterates over the IFDs to find the subresolutions)

The software vendor is "Faas", which is from
http://jcb.rupress.org/content/198/3/457
http://jcb.rupress.org/content/198/3/271
(wow, can't believe that was four years ago now).  This is a 921600 x
380928 pixel image using this format, all from a single tiled BigTIFF
with pyramid levels.

Online viewer here:
http://v.jcb-dataviewer.glencoesoftware.com/webclient/img_detail/201/ -
it's quite fun to look around and the number of pyramid levels is
ridiculous (12 power of two reductions).

That's a sort-of standard format in that it's supported by a lot of
biological image analysis and visualisation tools using Bio-Formats for
file I/O.

[Incidentally, my work on libtiff stuff like CMake is for its sister
project OME Files C++ which is a conversion of the core Bio-Formats APIs
and functionality for C++, and libtiff is a core part of that
functionality.]

This use of multiple IFDs doesn't work with multi-dimensional images
though, for that I can see SUBIFDs would work much better.  This is one
thing I've been unsure of how to make use of with the libtiff API
though.  How to you create the subifd to be able to add it to the tag,
without it being in the main list of IFDs?  And can you write them out
from largest to smallest?  Or do you need to write the smaller images
first so you can reference them in the larger ones?

Doing this is on my TODO list, and so it's quite nice this came up on
the list in the meantime.


Regards,
Roger
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

jcupitt
In reply to this post by Kemp Watson-2
Hi Kemp,

On 14 November 2016 at 18:16, Kemp Watson <[hidden email]> wrote:
> What is the “correct” or canonical way to make a (tiled) multi-resolution pyramid in TIFF?
>
> Most implementations I’ve seen simply chain top-level IFDs together, starting with the base or full-res layer, and going smaller from there to the apex. this seems wrong to me.

Yes, that what vips has done since the mid 90s, and imagemagick as
well. It's also the layout used by things like iipimage and most of
the virtual microscopy people. The only other thing they do is set
FILETYPE_REDUCEDIMAGE.

I remember experimenting with nested images, which does look cleaner,
but compatibility problems made it difficult to work with. TIFF is
complicated enough already, and really very few readers will be happy
with something like that. As Even says, I think there were problems
getting libtiff itself to write them, making the easy route even more
appealing.

John
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Kemp Watson-2
In reply to this post by Roger Leigh
Thanks Roger. That¹s _exactly_ the type of data we¹re dealing withŠ tens
of thousands of 1GB to even 1TB BigTIFF pathology images.

You might want to stay in touch, we¹re actively working on the formats
issue; I¹ve spoken with Jason S. several times.

W. Kemp Watson

[hidden email]

Objective Pathology Services Limited
www.objectivepathology.com
tel. +1 (416) 970-7284








On 2016-11-14, 5:02 PM, "Roger Leigh" <[hidden email] on
behalf of [hidden email]> wrote:

>On 14/11/2016 21:16, Paavo Helde wrote:
>>
>> On 14.11.2016 20:16, Kemp Watson wrote:
>>> Hi all:
>>>
>>> What is the ³correct² or canonical way to make a (tiled)
>>> multi-resolution pyramid in TIFF?
>>>
>>> Most implementations I¹ve seen simply chain top-level IFDs together,
>>> starting with the base or full-res layer, and going smaller from there
>>> to the apex. this seems wrong to me.
>>
>> You are right, sub-IFDs would be more appropriate. However, sub-IFDs are
>> not so well supported by various TIFF readers. That was the reason why
>> in my company when they were working out the pyramidal TIFF schema a
>> couple of years ago they still went with top-level IFD-s.
>
>That's the way one of the Bio-Formats readers handles it as well:
>
>https://github.com/openmicroscopy/bioformats/blob/develop/components/forma
>ts-gpl/src/loci/formats/in/PyramidTiffReader.java
>(loop at line 129 just iterates over the IFDs to find the subresolutions)
>
>The software vendor is "Faas", which is from
>http://jcb.rupress.org/content/198/3/457
>http://jcb.rupress.org/content/198/3/271
>(wow, can't believe that was four years ago now).  This is a 921600 x
>380928 pixel image using this format, all from a single tiled BigTIFF
>with pyramid levels.
>
>Online viewer here:
>http://v.jcb-dataviewer.glencoesoftware.com/webclient/img_detail/201/ -
>it's quite fun to look around and the number of pyramid levels is
>ridiculous (12 power of two reductions).
>
>That's a sort-of standard format in that it's supported by a lot of
>biological image analysis and visualisation tools using Bio-Formats for
>file I/O.
>
>[Incidentally, my work on libtiff stuff like CMake is for its sister
>project OME Files C++ which is a conversion of the core Bio-Formats APIs
>and functionality for C++, and libtiff is a core part of that
>functionality.]
>
>This use of multiple IFDs doesn't work with multi-dimensional images
>though, for that I can see SUBIFDs would work much better.  This is one
>thing I've been unsure of how to make use of with the libtiff API
>though.  How to you create the subifd to be able to add it to the tag,
>without it being in the main list of IFDs?  And can you write them out
>from largest to smallest?  Or do you need to write the smaller images
>first so you can reference them in the larger ones?
>
>Doing this is on my TODO list, and so it's quite nice this came up on
>the list in the meantime.
>
>
>Regards,
>Roger
>_______________________________________________
>Tiff mailing list: [hidden email]
>http://lists.maptools.org/mailman/listinfo/tiff
>http://www.remotesensing.org/libtiff/


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Paavo Helde
In reply to this post by Roger Leigh

On 15.11.2016 0:02, Roger Leigh wrote:
> This use of multiple IFDs doesn't work with multi-dimensional images
> though, for that I can see SUBIFDs would work much better. This is one
> thing I've been unsure of how to make use of with the libtiff API
> though. How to you create the subifd to be able to add it to the tag,
> without it being in the main list of IFDs? And can you write them out
> from largest to smallest? Or do you need to write the smaller images
> first so you can reference them in the larger ones?

In my experience there is often an XML string stored in the first frame
of the TIFF which provides more detailed information and auxiliary data
for the TIFF frames, in a cumbersome proprietary format of course. The
XML would describe for example that N first frames are full-res images,
taken with such-and-such laser wavelengths etc, the next N frames are 2x
reduced duplicates, etc.

As a bonus, this trick will make the data look much more professional!
Anything which does not contain an embedded 800 MB XML is probably not
deemed to be enterprisy enough ;-)

Cheers
Paavo

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

dsudar
I've started looking at this same issue for our large number of channels TIFF
images from multiplex immunofluorescent staining of tissue on slides. Has a
consensus been reached how the pyramid of resolution levels should be
stored? There seem to be many different and incompatible approaches in use
now and I would like to stick to an agreed standard. This appears to be the
forum that would know.
Thanks,
- Damir



--
Sent from: http://maptools-org.996276.n3.nabble.com/Tiff-LibTIFF-f3.html
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Kemp Watson-2
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 digital pathology slides, TIFF is likely not a
practical option, in any case.

W. Kemp Watson

[hidden email]




Objective Pathology Services Limited

8250 Lawson Road
Milton, Ontario
Canada  L9T 5C6

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








On 2017-11-10, 2:23 PM, "dsudar" <[hidden email] on
behalf of [hidden email]> wrote:

>I've started looking at this same issue for our large number of channels
>TIFF
>images from multiplex immunofluorescent staining of tissue on slides. Has
>a
>consensus been reached how the pyramid of resolution levels should be
>stored? There seem to be many different and incompatible approaches in use
>now and I would like to stick to an agreed standard. This appears to be
>the
>forum that would know.
>Thanks,
>- Damir
>
>
>
>--
>Sent from: http://maptools-org.996276.n3.nabble.com/Tiff-LibTIFF-f3.html
>_______________________________________________
>Tiff mailing list: [hidden email]
>http://lists.maptools.org/mailman/listinfo/tiff
>http://www.remotesensing.org/libtiff/


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

dsudar
Hi Kemp,

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 digital pathology slides, TIFF is likely not a
> practical option, in any case.
>
> W. Kemp Watson
>
> [hidden email]
>
>
>
>
> Objective Pathology Services Limited
>
> 8250 Lawson Road
> Milton, Ontario
> Canada  L9T 5C6
>
> www.objectivepathology.com
> tel. +1 (416) 970-7284
>
>
>
>
>
>
>
>
> On 2017-11-10, 2:23 PM, "dsudar" <[hidden email] on
> behalf of [hidden email]> wrote:
>
>> I've started looking at this same issue for our large number of channels
>> TIFF
>> images from multiplex immunofluorescent staining of tissue on slides. Has
>> a
>> consensus been reached how the pyramid of resolution levels should be
>> stored? There seem to be many different and incompatible approaches in use
>> now and I would like to stick to an agreed standard. This appears to be
>> the
>> forum that would know.
>> Thanks,
>> - Damir
>>
>>
>>
>> --
>> Sent from: http://maptools-org.996276.n3.nabble.com/Tiff-LibTIFF-f3.html
>> _______________________________________________
>> Tiff mailing list: [hidden email]
>> http://lists.maptools.org/mailman/listinfo/tiff
>> http://www.remotesensing.org/libtiff/
>

--
Damir Sudar - Affiliate Scientist
Lawrence Berkeley Natl Laboratory / MBIB
One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
T: 510/486-5346 - F: 510/486-5586 - E: [hidden email]
http://biosciences.lbl.gov/profiles/damir-sudar-2/

Visiting Scientist, Oregon Health & Science University

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Aaron Boxer
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.

Aaron




On Sat, Nov 11, 2017 at 4:43 PM, Damir Sudar <[hidden email]> wrote:
Hi Kemp,

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 digital pathology slides, TIFF is likely not a
> practical option, in any case.
>
> W. Kemp Watson
>
> [hidden email]
>
>
>
>
> Objective Pathology Services Limited
>
> 8250 Lawson Road
> Milton, Ontario
> Canada  L9T 5C6
>
> www.objectivepathology.com
> tel. <a href="tel:%2B1%20%28416%29%20970-7284" value="+14169707284">+1 (416) 970-7284
>
>
>
>
>
>
>
>
> On 2017-11-10, 2:23 PM, "dsudar" <[hidden email] on
> behalf of [hidden email]> wrote:
>
>> I've started looking at this same issue for our large number of channels
>> TIFF
>> images from multiplex immunofluorescent staining of tissue on slides. Has
>> a
>> consensus been reached how the pyramid of resolution levels should be
>> stored? There seem to be many different and incompatible approaches in use
>> now and I would like to stick to an agreed standard. This appears to be
>> the
>> forum that would know.
>> Thanks,
>> - Damir
>>
>>
>>
>> --
>> Sent from: http://maptools-org.996276.n3.nabble.com/Tiff-LibTIFF-f3.html
>> _______________________________________________
>> Tiff mailing list: [hidden email]
>> http://lists.maptools.org/mailman/listinfo/tiff
>> http://www.remotesensing.org/libtiff/
>

--
Damir Sudar - Affiliate Scientist
Lawrence Berkeley Natl Laboratory / MBIB
One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
T: <a href="tel:510%2F486-5346" value="+15104865346">510/486-5346 - F: <a href="tel:510%2F486-5586" value="+15104865586">510/486-5586 - E: [hidden email]
http://biosciences.lbl.gov/profiles/damir-sudar-2/

Visiting Scientist, Oregon Health & Science University

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Kemp Watson-2
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


tel. +1 (416) 970-7284

On Nov 11, 2017, at 6:02 PM, Aaron Boxer <[hidden email]> 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.

Aaron




On Sat, Nov 11, 2017 at 4:43 PM, Damir Sudar <[hidden email]> wrote:
Hi Kemp,

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 digital pathology slides, TIFF is likely not a
> practical option, in any case.
>
> W. Kemp Watson
>
> [hidden email]
>
>
>
>
> Objective Pathology Services Limited
>
> 8250 Lawson Road
> Milton, Ontario
> Canada  L9T 5C6
>
> www.objectivepathology.com
> tel. <a href="tel:%2B1%20%28416%29%20970-7284" value="+14169707284">+1 (416) 970-7284
>
>
>
>
>
>
>
>
> On 2017-11-10, 2:23 PM, "dsudar" <[hidden email] on
> behalf of [hidden email]> wrote:
>
>> I've started looking at this same issue for our large number of channels
>> TIFF
>> images from multiplex immunofluorescent staining of tissue on slides. Has
>> a
>> consensus been reached how the pyramid of resolution levels should be
>> stored? There seem to be many different and incompatible approaches in use
>> now and I would like to stick to an agreed standard. This appears to be
>> the
>> forum that would know.
>> Thanks,
>> - Damir
>>
>>
>>
>> --
>> Sent from: http://maptools-org.996276.n3.nabble.com/Tiff-LibTIFF-f3.html
>> _______________________________________________
>> Tiff mailing list: [hidden email]
>> http://lists.maptools.org/mailman/listinfo/tiff
>> http://www.remotesensing.org/libtiff/
>

--
Damir Sudar - Affiliate Scientist
Lawrence Berkeley Natl Laboratory / MBIB
One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
T: <a href="tel:510%2F486-5346" value="+15104865346">510/486-5346 - F: <a href="tel:510%2F486-5586" value="+15104865586">510/486-5586 - E: [hidden email]
http://biosciences.lbl.gov/profiles/damir-sudar-2/

Visiting Scientist, Oregon Health & Science University

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: Right way to make a multi-resolution pyramid

Kemp Watson-2
In reply to this post by dsudar
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

[hidden email]
tel. +1 (416) 970-7284

> On Nov 11, 2017, at 4:43 PM, Damir Sudar <[hidden email]> wrote:
>
> Hi Kemp,
>
> 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 digital pathology slides, TIFF is likely not a
>> practical option, in any case.
>>
>> W. Kemp Watson
>>
>> [hidden email]
>>
>>
>>
>>
>> Objective Pathology Services Limited
>>
>> 8250 Lawson Road
>> Milton, Ontario
>> Canada  L9T 5C6
>>
>> www.objectivepathology.com
>> tel. +1 (416) 970-7284
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2017-11-10, 2:23 PM, "dsudar" <[hidden email] on
>> behalf of [hidden email]> wrote:
>>
>>> I've started looking at this same issue for our large number of channels
>>> TIFF
>>> images from multiplex immunofluorescent staining of tissue on slides. Has
>>> a
>>> consensus been reached how the pyramid of resolution levels should be
>>> stored? There seem to be many different and incompatible approaches in use
>>> now and I would like to stick to an agreed standard. This appears to be
>>> the
>>> forum that would know.
>>> Thanks,
>>> - Damir
>>>
>>>
>>>
>>> --
>>> Sent from: http://maptools-org.996276.n3.nabble.com/Tiff-LibTIFF-f3.html
>>> _______________________________________________
>>> Tiff mailing list: [hidden email]
>>> http://lists.maptools.org/mailman/listinfo/tiff
>>> http://www.remotesensing.org/libtiff/
>>
>
> --
> Damir Sudar - Affiliate Scientist
> Lawrence Berkeley Natl Laboratory / MBIB
> One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
> T: 510/486-5346 - F: 510/486-5586 - E: [hidden email]
> http://biosciences.lbl.gov/profiles/damir-sudar-2/
>
> Visiting Scientist, Oregon Health & Science University
>
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/