[COG] Fwd: Cloud optimized GeoTIFF configuration specifics [SEC=UNOFFICIAL]

[Kirill Kouzoubov]

I thought that would be problematic, thank you Even for succinctly
explaining current state of the art.

A cleaner solution, that was discussed some time ago on the libtiff mailing
> list,
> https://www.asmail.be/msg0054912161.html, would be to use the TIFF Tree /
> SubIFD mechanism
> that was added per TIFF Tech Note 1:
> https://www.awaresystems.be/imaging/tiff/specification/TIFFPM6.pdf
> where you can define parent and child IFD
>
> So the layout would become:
>
> Image1FullResolution (NewSubFileType = 2 =single page of a multi-page
> image, SubIFDS = offset of the 2 below overviews, NextIFD = offset of
> Image2FullResolution)
>         Image1OverviewFactor2 (NewSubFileType = 1 =  reduced-resolution,
> NextIFD = offset of Image1OverviewFactor4)
>         Image1OverviewFactor4 (NewSubFileType = 1, NextIFD = 0)
> Image2FullResolution  (NewSubFileType = 2, SubIFDS = offset of the 2 below
> overviews, NextIFD = 0)
>         Image2OverviewFactor2 (NewSubFileType = 1, NextIFD = offset of
> Image2OverviewFactor4)
>         Image2OverviewFactor4 (NewSubFileType = 1, NextIFD = 0)
>

 This looks to me like the most reasonable approach, and fits well with the
intent of the Tech Note you linked (example they use, thumbnails, is
essentially the same as overviews, and potential nesting of SubIFDS fits
well with masks for each overview level)


> The libtiff disccussion thread I mentionned also pointed that few TIFF
> readers (beyond Photoshop)
> are able to deal with SubIFDs.
>

I read through that thread, and it looks like the usual sad story:
"optional feature of a spec that fits well the requirements, is not well
supported by existing implementations, so people implement domain-specific
workarounds with some embedded xml".


> So, beyond having a single file, the advantages of putting all those
> "bands" in the same TIFF files aren't
> obvious.
>

It is a big advantage though, but at some point you have to ask are we
re-implementing zip file, or hdf5 or some other filesystem in a file
format. The simplicity is gone, and you are probably stuck with just one
implementation that understands that exact interpretation of the standard +
implementation specific conventions.

At least for now it looks like the choices are:

1. Multiple files for related image data, but with overviews and masks in
each file
2. Single file containing all related image data, but without any good
story for overviews or masks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/cog/attachments/20180617/3931ea88/attachment.html>