[gdal-dev] COG w/JPEG YCbCr mask

David McKenzie davidmck at austin.rr.com
Fri May 17 21:43:54 PDT 2019


Please remove this address for David McKenzie from your mailing list.
He passed away December 2016.
Thank you,
M.H. McKenzie
May 2019

From: Lucian Plesea 
Sent: Friday, May 17, 2019 4:14 PM
To: gdal-dev at lists.osgeo.org ; Even Rouault 
Subject: [gdal-dev] COG w/JPEG YCbCr mask

Hi Even,

I just read your COG notice from May 3rd.  Are you aware of the approach I've used to achieve the same outcome in MRF JPEG?

Most of the code is in https://github.com/OSGeo/gdal/blob/master/gdal/frmts/mrf/JPEG_band.cpp
It inserts an RLE encoded bit mask in the JPEG itself as an application specific chunk (Zen) instead of having it as a separate entity.  I uses the mask to only keep the locations with zero fixed (thus the Zen name), instead of exposing the mask to GDAL.  Then the zero value can be declared as NoData, eliminating the noisy JPEG edge issue.
This service uses it: http://www.arcgis.com/home/webmap/viewer.html?useExisting=1&layers=c1c4c750a2154842ae523c984cc14fa5



The Zen chunk could be exposed as a mask, but then you have the headache of getting the mask and the normal bands read and written together, which is not trivial as far as I can tell.  It could also be exposed as a full alpha band.  As far as I can tell, the NoData approach has significantly less overhead, no extra band blocks to handle.  The Zen chunk in JPEG is ignored by older decoders, so it is backwards compatible.


Lucian



--------------------------------------------------------------------------------
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190517/00627551/attachment.html>


More information about the gdal-dev mailing list