[gdal-dev] Applying colour/contrast corrections to geotiffs
even.rouault at mines-paris.org
Mon Mar 11 13:54:33 PDT 2013
> Is there a way to verify if it is using this optimization?
$ gdal_translate byte.jpg byte.tif -co compress=jpeg --debug GTiff -q
GTiff: Using special copy mode from a JPEG dataset
GTiff: Setting JPEGCOLORMODE_RGB
> I'm not actually
> feeding it a JPEG in the command line at any point, but the WMS driver is
> downloading JPEGs as I am using a WMS source with
> <ImageFormat>image/png</ImageFormat>, which might be similar to a VRT. I
> don't know how this is treated internally.
It won't likely trigger the optimization. As I said, it is currently only
implemented in the specific case of JPEG --> JPEG-in-TIFF CreateCopy(). Well,
it actually also works in
> My recollection is that it is theoretically possible to merge multiple jpeg
> images without decompressing and recompressing, provided the images all lie
> on the same block boundaries, where I believe a block is 8x8 pixels. I used
> to have some image editing software that would crop JPEGs without
> recompression if the cropping lied on the right lines.
Yes, this is indeed theoretically possible.
> If you run nearblack to go from one JPEG in TIFF to another JPEG in TIFF,
> does it use this optimization for the RGB bands?
I don't see the interest of doing nearblack from JPEG-in-TIFF to JPEG-in-TIFF.
Nearblack can be interesting from JPEG-in-TIFF to lossless-TIFF to eliminate
near zero values at the edge of the imagery due to JPEG compression. But once
you get again to JPEG-in-TIFF, the artifacts will come again.
And no, the above mentionned optimization could not work since nearblack
changes imagery, and doesn't use the CreateCopy() API.
More information about the gdal-dev