<div dir="ltr"><div class="gmail_extra">Two semi-related things:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- It could be good for us to set up a COG format list? Does anyone have osgeo list creation powers? If not I can just make a google group. We've been playing with -stats in COG's to give hints to tile services about analytic data, would be good to discuss adding it as a cog 'recommendation', and indeed perhaps making more recommendations / possibly making 'tiers' of COG for some of the more extreme optimizations.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Anyone up for a cog 'birds of feather' session at foss4g? I'll try to sign up tomorrow, curious if anyone has preferences for monday vs tuesday.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 17, 2018 at 12:54 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I'd be interested in whether webp is believed to have good enough<br>
> performance that it would be a substantial improvement over the Deflate<br>
> support already available in libtiff.  I'm also interested in how it<br>
> compares to the new zstd support (<br>
> <a href="https://github.com/OSGeo/gdal/commit/1c60366a193e67ee90856e1008e3c17cb8524f6" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/<wbr>commit/<wbr>1c60366a193e67ee90856e1008e3c1<wbr>7cb8524f6</a><br>
</span>> 0#diff-<wbr>ce45424050585add924746240ffc27<wbr>61). I'm willing to support new codecs<br>
<span class="">> in libtiff if they add significant value, but I don't want to just add<br>
> every compression format known.<br>
<br>
</span>You can only compare webp vs deflate or zstd for its lossless profile.<br>
The WebP website provides this comparison against PNG:<br>
<a href="https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study" rel="noreferrer" target="_blank">https://developers.google.com/<wbr>speed/webp/docs/webp_lossless_<wbr>alpha_study</a><br>
so claiming a 42% size improvement over PNG<br>
<br>
For lossy support, if you believe Mozilla (pushing for MozJpeg)<br>
<a href="https://research.mozilla.org/2014/07/15/mozilla-advances-jpeg-encoding-with-mozjpeg-2-0/" rel="noreferrer" target="_blank">https://research.mozilla.org/<wbr>2014/07/15/mozilla-advances-<wbr>jpeg-encoding-with-mozjpeg-2-<wbr>0/</a><br>
rather than Google<br>
<a href="https://developers.google.com/speed/webp/docs/webp_study" rel="noreferrer" target="_blank">https://developers.google.com/<wbr>speed/webp/docs/webp_study</a><br>
"We consider this study to be inconclusive when it comes to the question of whether<br>
"WebP and/or JPEG XR outperform JPEG by any significant margin"<br>
<br>
One potential advantage of webp is that lossy webp for imagery with lossless alpha would<br>
be naturally supported (in comparison to the second point below).<br>
One drawback of webp is that it is really RGB[A] only (would likely be unwise to use<br>
it for 3 or 4 band image with other photometric interpretations)<br>
<span class=""><br>
> <br>
> > - Improve mask storing inside COG. For some technical reason, when you<br>
> > create a COG with internal masking, the mask is appended to the end of the<br>
> > IFD. Some of improvement could be to append mask TILE data just after the<br>
> > imagery tile data.<br>
<br>
> <br>
</span><span class="">> I assume you are suggesting a file with the "nodata" handled as a distinct<br>
> IFD like this (our internal serving format):<br>
<br>
</span>That was I understood from previous discussion with Vincent's team.<br>
<span class=""><br>
> That is interesting.  Even, can you comment on what it would take to ensure<br>
> extra mask IFDs are located near their corresponding imagery as part of<br>
> GDAL and the implications for COG?<br>
<br>
</span>Such a layout of blocks would apply only for Planar Configuration==single image plane<br>
That's certainly doable by the GDAL GTiff driver, but would require the copying<br>
of imagery to be done in a custom fashion, to properly interleave imagery blocks with<br>
mask blocks, instead of using GDALDatasetCopyWholeRaster() (for imagery) and<br>
GDALRasterBandCopyWholeRaster(<wbr>) (for masks). Actually, implementation wise,<br>
that could be a new option of GDALDatasetCopyWholeRaster (INTERLEAVE_MASK=YES).<br>
For very large images (dimensions > 100,000 pixels) where the size of the<br>
TileOffsets and TileByteCounts tags is big this constant back and forth between IFD<br>
could be rather costly, as they are reloaded/flushed each time you change the active<br>
IFD in libtiff.<br>
<br>
The COG definition would have to be updated for that use case (probably as an<br>
allowed extra optimization, rather than forcing people to use it), and the validation<br>
script as well.<br>
<br>
On the GDAL read side, the GTiff driver would also have to be updated to detect this<br>
layout and when reading a block of imagery, it should issue a GET range request that<br>
is big enough to fetch the imagery block and its mask block at once (the base logic to<br>
optimize GET requests for a given IRasterIO() request is already in place)<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Landsat-pds mailing list<br>
<a href="mailto:Landsat-pds@lists.osgeo.org">Landsat-pds@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/landsat-pds" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/landsat-pds</a><br>
</div></div></blockquote></div><br></div></div>