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

[Paul Norman]

> From: Even Rouault [mailto:even.rouault at mines-paris.org]
> Sent: Monday, March 11, 2013 12:13 PM
> Subject: Re: [gdal-dev] Applying colour/contrast corrections to geotiffs
> 
> Le lundi 11 mars 2013 18:55:55, Paul Norman a écrit :
> 
> I doubt that any correction/transformation can recover the lost
> information.
> JPEG is a lossy compression format. You basically loose the high
> frequencies of the image. I can't see how you can recover them, unless
> perhaps some specialized transformation like edge enhancing to remove
> the bluring effect of JPEG. I would expect the histogram and stats of
> JPEG and PNG to be fairly similar. The differences should be much subtle
> and shown by more advanced indicators.

I'm not speaking of the blurring of the JPEG request results. That is
unrecoverable, although mostly insignificant compared to the film grain in
this imagery.

If I plot the difference between the green histograms of the two images, I
see that there is a systematic shift of dark shades from about 40 to 52.
I've put the two histograms and the difference up at
http://took.paulnorman.ca/images/databc.pdf.

The difference is small enough (except at 0 and 255) that I may decide to
ignore it because of the optimizations you mentioned below. The differences
at 0 and 255 are likely artifacts off the edges of the imagery from JPEG
compression.

If I were forced to guess, I'd guess that somewhere a gamma setting is
getting misprocessed or dropped, but if this is the cause I bet it's in ESRI
mapserver, which I have no control over.

> Note: in GDAL 1.10, I've introduced in the GeoTIFF driver an
> optimization that will take the JPEG coefficients of a JPEG dataset and
> put them as a JPEG-in-TIFF without doing any
> decompression/decompression, so preserving exactly the quality of the
> source JPEG (and being much faster)
> 
> This is accomplished by : gdal_translate my.jpeg my.tif -co
> COMPRESS=JPEG (if you add -co QUALITY=xxx , or some other options, then
> the optimization will not be triggered)
> 
> Note that it currently only works with a single JPEG image, not a VRT of
> several JPEG for example.

Is there a way to verify if it is using this optimization? 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.

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.

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?