<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 16, 2018 at 12:14 PM, Vincent Sarago <span dir="ltr"><<a href="mailto:vincent.sarago@gmail.com" target="_blank">vincent.sarago@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry for hijacking this mailing list but as Landsat dataset is one of the biggest open COG dataset, discussion about the evolution of the format here made sense to us.<br>
<br>
Couple weeks ago we started a discussion internally about COGEO format. It’s great to see how many people are using and implementing COG right now (e.g planet, digitalglobe…) that’s say we think there is still place for improvement. <br>
<br>
Here are some of our ideas:<br>
- add webp compression to libtiff. Even if webp wasn’t a big success in term of adoption, the format is still a good option in comparison to JPEG and PNG. <br></blockquote><div><br></div><div>Vincent, and other folks,</div><div><br></div><div>I'd be interested in whether webp is believed to have good enough performance that it would be a substantial improvement over the Deflate support already available in libtiff.  I'm also interested in how it compares to the new zstd support (<a href="https://github.com/OSGeo/gdal/commit/1c60366a193e67ee90856e1008e3c17cb8524f60#diff-ce45424050585add924746240ffc2761">https://github.com/OSGeo/gdal/commit/1c60366a193e67ee90856e1008e3c17cb8524f60#diff-ce45424050585add924746240ffc2761</a>).  I'm willing to support new codecs in libtiff if they add significant value, but I don't want to just add every compression format known.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Improve mask storing inside COG. For some technical reason, when you create a COG with internal masking, the mask is appended to the end of the IFD. Some of improvement could be to append mask TILE data just after the imagery tile data.<br></blockquote><div><br></div><div>That is interesting.  Even, can you comment on what it would take to ensure extra mask IFDs are located near their corresponding imagery as part of GDAL and the implications for COG?   </div><div><br></div><div>I assume you are suggesting a file with the "nodata" handled as a distinct IFD like this (our internal serving format):</div><div><br></div><div><a href="http://download.osgeo.org/gdal/data/gtiff/20160929_023611_0e0f_Browse.tif">http://download.osgeo.org/gdal/data/gtiff/20160929_023611_0e0f_Browse.tif</a><br></div><div><br></div><div>...</div><div><div>TIFF Directory at offset 0x2070 (8304)</div><div>  Subfile Type: reduced-resolution image (1 = 0x1)</div><div>  Image Width: 857 Image Length: 438</div><div>  Tile Width: 128 Tile Length: 128</div><div>  Bits/Sample: 8</div><div>  Sample Format: unsigned integer</div><div>  Compression Scheme: JPEG</div><div>  Photometric Interpretation: YCbCr</div><div>  YCbCr Subsampling: 2, 2</div><div>  Samples/Pixel: 3</div><div>  Planar Configuration: single image plane</div><div>  Reference Black/White:</div><div>     0:     0   255</div><div>     1:   128   255</div><div>     2:   128   255</div><div>  JPEG Tables: (142 bytes)</div></div><div>...</div><div><div>TIFF Directory at offset 0x2a0e (10766)</div><div>  Subfile Type: reduced-resolution image/transparency mask (5 = 0x5)</div><div>  Image Width: 857 Image Length: 438</div><div>  Tile Width: 128 Tile Length: 128</div><div>  Bits/Sample: 1</div><div>  Sample Format: unsigned integer</div><div>  Compression Scheme: AdobeDeflate</div><div>  Photometric Interpretation: transparency mask</div><div>  Samples/Pixel: 1</div><div>  Planar Configuration: single image plane</div><div>  Predictor: none 1 (0x1)</div></div><div>...</div><div><br></div><div>I consider this format very useful (lossy compression for the imagery, but losslessly compress nodata masks) for some purposes and I'd be interested in methods to optimize it for COG use even though it is pretty rare for applications to properly support it.</div><div><br></div><div>Best regards,</div><div>Frank</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
we’d love to hear story or comments from people about the format and how they see it moving in the future.<br>
<br>
______________________________<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | <br>and watch the world go round - Rush    | Geospatial Software Developer</div>
</div></div>