- 2016.09.19 18:47 "Re: [Tiff] Accuracy of TIFF Field metadata (COLORMAP)", by
-
2016.11.14 22:49 "Re: [Tiff] Right way to make a multi-resolution pyramid", by Kemp Watson
-
2016.11.14 18:16 "[Tiff] Right way to make a multi-resolution pyramid", by Kemp Watson
- 2016.11.14 18:40 "Re: [Tiff] Right way to make a multi-resolution pyramid", by Kemp Watson
- 2016.11.14 18:55 "Re: [Tiff] Right way to make a multi-resolution pyramid", by Dmitry Fedorov
-
2016.11.14 18:16 "[Tiff] Right way to make a multi-resolution pyramid", by Kemp Watson
2016.11.14 22:49 "Re: [Tiff] Right way to make a multi-resolution pyramid", by Kemp Watson
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
kemp@objectivepathology.com
Objective Pathology Services Limited
www.objectivepathology.com
tel. +1 (416) 970-7284
On 2016-11-14, 5:02 PM, "Roger Leigh" <tiff-bounces@lists.maptools.org on behalf of rleigh@codelibre.net> 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.
Roger