[gdal-dev] JPEG in GeoTIFF + Masks

[Robert Coup]

Hi folks,

After a bit of advice...

JPEG compression is fast and pretty space-efficient for raster imagery. But
it's RGB-only.
JPEG2000 supports RGBA, has built-in overviews, but it can be slow &
CPU-hungry.
TIFF with deflate/lzw supports RGBA but is big for imagery.

For simple RGB originals where imagery is later reprojected, all the alpha
band in the reprojected version ends up being is a boolean mask with a 0
(nodata) or 255 (data) value.

Ideally I want something that is JPEG compressed images, has an alpha band
mask, and where I can create overviews.

http://www.gdal.org/frmt_gtiff.html talks about internal nodata masks,
which sounds relevant, but doesn't really explain how to create them or how
they work? I'm guessing here, but there's a normal tiled JPEG image in the
TIFF file, and a tiled mask band with 1bpp, which could presumably be
compressed further with deflate/etc too. And at read-time they could come
out as RGBA?

For mosaicing ... are they supported by overviews and VRTs in a sensible
way? For VRTs - the internal nodata value (no data in this pixel) would
need to match the VRT nodata (no tile in this area). Last time I tried
creating overviews for JPEG-in-TIFF alpha/nodata was handled bizarrely, but
that could be all fixed by now.

Is there a way to convert a masked TIFF to a vanilla RGBA TIFF image for
previewing in eg. image editing software?

Talking more about JPEG-in-TIFF, the docs say:

> When translating a RGB image to JPEG-In-TIFF, using PHOTOMETRIC=YCBCR can
make the size of the image typically 2 to 3 times smaller than the default
photometric value (RGB). When using PHOTOMETRIC=YCBCR, the INTERLEAVE
option must be kept to its default value (PIXEL), otherwise libtiff will
fail to compress the data.

Does interleave=pixel affect read performance cf =band for a RGB JPEG? It's
within a tiled tiff and JPEG compression is both 3-band & tiled, so I'm not
really sure where the interleaving fits in?

Thanks,

Rob :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140825/4258184c/attachment.html>