[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