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

Even Rouault even.rouault at mines-paris.org
Mon Mar 11 12:12:58 PDT 2013


Le lundi 11 mars 2013 18:55:55, Paul Norman a écrit :
> I am generating a geotiff from a WMS source. I can do so from either PNG
> requests or JPEG requests. The PNG requests have better contrast but are
> 4x-5x as slow.
> 
> I would like to compare the PNG and JPEG request results for a
> representative area and develop a contrast correction which I can apply to
> the JPEG request result to make it look like the PNG request result, but I
> am not certain how to do this. I can get histograms and stats with
> gdalinfo. I was thinking perhaps developing a LUT correction which I could
> then apply, but I'm not sure how to match the images or apply the
> correction.

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.

> 
> Other potentially relevant information
> 
> - The total image size is going to be 350GB-500GB, in a few slices
> 
> - The WMS server owners are okay with me scraping this, but won't give me
> the original imagery file
> 
> - I will be eventually compressing the imagery as JPEG in TIFF

Well, then there's very little interest in trying to "correct" the JPEG tiles, 
since you'll again have a lossy transformation when you will transform in 
JPEG-in-TIFF that should cause the same kind of loss as introduced by the JPEG 
output of the WMS server.

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.

> 
> - The result will be used by mapserver, then sliced and served as TMS
> images by mapproxy. If all else fails I can apply a LUT in mapserver.
> 
> - Screenshots of the jpeg request results vs. png request results are at
> http://took.paulnorman.ca/images/databc_differences.png. The differences
> are minimal, but I'd like to do this right

Honestly, I can't detect the differences with normal zooming. But my eyes are 
perhaps not the best ones.

> 
> I'm after any suggestions for how to derive the adjustments needed as well
> as how to apply them.
> 
> Thanks,
> 
> Paul Norman
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list