[gdal-dev] COG w/JPEG YCbCr mask

[Even Rouault]

Hi Lucian,

thanks for sharing your thoughts about this. I considered initially something 
pretty much identical to your proposal. The GDAL JPEG driver has actually a 
probably not so known feature where a zlib-compressed transparency mask can be 
appended after the JPEG payload (it is not nicer as using a JFIF marker as you 
suggest). But as TIFF has an official way of encoding a transparency mask, I 
think it is better for interoperability to use that mechanism. What I proposed 
should achieve pretty much the same performance level as what you suggest, 
except that it requires to write an additional IFD and its TileOffsets & 
TileByteCounts arrays that a smart reader can avoid reading.

Even

> 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.cppIt
> inserts an RLE encoded bit mask in theJPEG itself as an application
> specific chunk (Zen) instead of having it as aseparate entity.  I usesthe
> 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=c1c4c750
> a2154842ae523c984cc14fa5
> 
> The Zen chunk could be exposed as a mask, but then you have the headache of
> getting themask and the normal bands read and written together, which is
> not trivial asfar 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


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com