[gdal-dev] Applying colour/contrast corrections to geotiffs

[Even Rouault]

> 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 
VRT_made_of_a_single_JPEG_without_any_fancy_transform_other_than_metadata_or_gereferencing_additions 
--> JPEG-in-TIFF.

> 
> 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.