<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I’m interested in joining this BOF if it happens!<br class="">
<div class=""></div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On May 13, 2018, at 11:05 PM, Chris Holmes <<a href="mailto:cholmes@planet.com" class="">cholmes@planet.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">Two semi-related things:</div>
<div class="gmail_extra"><br class="">
</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 class="">
</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 class="">
</div>
<div class="gmail_extra"><br class="">
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Tue, Apr 17, 2018 at 12:54 AM, Even Rouault <span dir="ltr" class="">
<<a href="mailto:even.rouault@spatialys.com" target="_blank" class="">even.rouault@spatialys.com</a>></span> wrote:<br class="">
<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 class="">
> performance that it would be a substantial improvement over the Deflate<br class="">
> support already available in libtiff. I'm also interested in how it<br class="">
> compares to the new zstd support (<br class="">
> <a href="https://github.com/OSGeo/gdal/commit/1c60366a193e67ee90856e1008e3c17cb8524f6" rel="noreferrer" target="_blank" class="">
https://github.com/OSGeo/gdal/<wbr class="">commit/<wbr class="">1c60366a193e67ee90856e1008e3c1<wbr class="">7cb8524f6</a><br class="">
</span>> 0#diff-<wbr class="">ce45424050585add924746240ffc27<wbr class="">61). I'm willing to support new codecs<br class="">
<span class="">> in libtiff if they add significant value, but I don't want to just add<br class="">
> every compression format known.<br class="">
<br class="">
</span>You can only compare webp vs deflate or zstd for its lossless profile.<br class="">
The WebP website provides this comparison against PNG:<br class="">
<a href="https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study" rel="noreferrer" target="_blank" class="">https://developers.google.com/<wbr class="">speed/webp/docs/webp_lossless_<wbr class="">alpha_study</a><br class="">
so claiming a 42% size improvement over PNG<br class="">
<br class="">
For lossy support, if you believe Mozilla (pushing for MozJpeg)<br class="">
<a href="https://research.mozilla.org/2014/07/15/mozilla-advances-jpeg-encoding-with-mozjpeg-2-0/" rel="noreferrer" target="_blank" class="">https://research.mozilla.org/<wbr class="">2014/07/15/mozilla-advances-<wbr class="">jpeg-encoding-with-mozjpeg-2-<wbr class="">0/</a><br class="">
rather than Google<br class="">
<a href="https://developers.google.com/speed/webp/docs/webp_study" rel="noreferrer" target="_blank" class="">https://developers.google.com/<wbr class="">speed/webp/docs/webp_study</a><br class="">
"We consider this study to be inconclusive when it comes to the question of whether<br class="">
"WebP and/or JPEG XR outperform JPEG by any significant margin"<br class="">
<br class="">
One potential advantage of webp is that lossy webp for imagery with lossless alpha would<br class="">
be naturally supported (in comparison to the second point below).<br class="">
One drawback of webp is that it is really RGB[A] only (would likely be unwise to use<br class="">
it for 3 or 4 band image with other photometric interpretations)<br class="">
<span class=""><br class="">
> <br class="">
> > - Improve mask storing inside COG. For some technical reason, when you<br class="">
> > create a COG with internal masking, the mask is appended to the end of the<br class="">
> > IFD. Some of improvement could be to append mask TILE data just after the<br class="">
> > imagery tile data.<br class="">
<br class="">
> <br class="">
</span><span class="">> I assume you are suggesting a file with the "nodata" handled as a distinct<br class="">
> IFD like this (our internal serving format):<br class="">
<br class="">
</span>That was I understood from previous discussion with Vincent's team.<br class="">
<span class=""><br class="">
> That is interesting. Even, can you comment on what it would take to ensure<br class="">
> extra mask IFDs are located near their corresponding imagery as part of<br class="">
> GDAL and the implications for COG?<br class="">
<br class="">
</span>Such a layout of blocks would apply only for Planar Configuration==single image plane<br class="">
That's certainly doable by the GDAL GTiff driver, but would require the copying<br class="">
of imagery to be done in a custom fashion, to properly interleave imagery blocks with<br class="">
mask blocks, instead of using GDALDatasetCopyWholeRaster() (for imagery) and<br class="">
GDALRasterBandCopyWholeRaster(<wbr class="">) (for masks). Actually, implementation wise,<br class="">
that could be a new option of GDALDatasetCopyWholeRaster (INTERLEAVE_MASK=YES).<br class="">
For very large images (dimensions > 100,000 pixels) where the size of the<br class="">
TileOffsets and TileByteCounts tags is big this constant back and forth between IFD<br class="">
could be rather costly, as they are reloaded/flushed each time you change the active<br class="">
IFD in libtiff.<br class="">
<br class="">
The COG definition would have to be updated for that use case (probably as an<br class="">
allowed extra optimization, rather than forcing people to use it), and the validation<br class="">
script as well.<br class="">
<br class="">
On the GDAL read side, the GTiff driver would also have to be updated to detect this<br class="">
layout and when reading a block of imagery, it should issue a GET range request that<br class="">
is big enough to fetch the imagery block and its mask block at once (the base logic to<br class="">
optimize GET requests for a given IRasterIO() request is already in place)<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
Even<br class="">
<br class="">
<br class="">
-- <br class="">
Spatialys - Geospatial professional services<br class="">
<a href="http://www.spatialys.com/" rel="noreferrer" target="_blank" class="">http://www.spatialys.com</a><br class="">
</font></span>
<div class="HOEnZb">
<div class="h5">______________________________<wbr class="">_________________<br class="">
Landsat-pds mailing list<br class="">
<a href="mailto:Landsat-pds@lists.osgeo.org" class="">Landsat-pds@lists.osgeo.org</a><br class="">
<a href="https://lists.osgeo.org/mailman/listinfo/landsat-pds" rel="noreferrer" target="_blank" class="">https://lists.osgeo.org/<wbr class="">mailman/listinfo/landsat-pds</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
Landsat-pds mailing list<br class="">
<a href="mailto:Landsat-pds@lists.osgeo.org" class="">Landsat-pds@lists.osgeo.org</a><br class="">
https://lists.osgeo.org/mailman/listinfo/landsat-pds<br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>