[gdal-dev] COG w/JPEG YCbCr mask

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] COG w/JPEG YCbCr mask

Lucian Plesea-2
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?
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.

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: COG w/JPEG YCbCr mask

Even Rouault-2
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
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: COG w/JPEG YCbCr mask

davidmck
In reply to this post by Lucian Plesea-2
Please remove this address for David McKenzie from your mailing list.
He passed away December 2016.
Thank you,
M.H. McKenzie
May 2019
 
Sent: Friday, May 17, 2019 4:14 PM
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?
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.

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev