<div dir="ltr">This would be very useful, reducing storage costs while simultaneously allowing faster preview functionality. One issue to consider is `dtype` support/conversion. My understanding is that JPEG is best supported at 8 bit, and can not go beyond 12, while many sensors have more than 8 bits worth of data per band, and even more than 12. So one would need bit-depth reduction as well. To complicated things further, one might have 14-bit data stored in 16-bit image, so bit-depth reduction is not a trivial operation. Also `nodata` comes into play as well.<div><br></div><div><br></div><div>Kirill </div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 10:39 AM Vincent Sarago <<a href="mailto:vincent.sarago@gmail.com">vincent.sarago@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What do I mean about `mixed` compression ? <br>
JPEG (or WEBP) compression are great for storage saving (and also for small http request) but they are `bad` because they are not lossless (WEBP can be set to be lossless but compression is then not as great) so my idea is to package both lossless and non-lossless in one COG. e.g keeping high resolution data to a ZSTD/DEFLATE compression but the overview in JPEG.<br>
<br>
Why ? <br>
For web application we mostly want fast tile serving while for processing we will mostly want to read full resolution lossless data, a file with mixed compression could make both world happy ? <br>
<br>
The gain won’t be astonishing but might be worth a try ? <br>
<br>
Vincent <br>
_______________________________________________<br>
COG mailing list<br>
<a href="mailto:COG@lists.osgeo.org" target="_blank">COG@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/cog" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/cog</a><br>
</blockquote></div>