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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev