Another alternative is GINA's
(http://www.gina.alaska.edu/projects/gina-tools/) gdal_contrast_stretch:
Usage: gdal_contrast_stretch.exe <src.tif> <dst.tif>
{ { -linear-stretch <target_avg> <target_stddev> } |
{ -percentile-range <from: 0.0-1.0> <to: 0.0-1.0> } |
{ -histeq <target_stddev> } }
[ -ndv <no_data_val> ]
Input must be either 8-bit or 16-bit. Output is 8-bit.
I think the input can be any GDAL supported raster type.
Best Regards,
Brent Fraser
On 4/24/2012 2:53 AM, jr.morre...@enoreth.net wrote:
On Tue, 24 Apr 2012 09:38:44 +0200, Even Rouault wrote:
thanks for the reply, I did try with NBITS=8 and 12 with osgeo4w's gdal
and tamas' nightly build but the output results are incorrect
Here is a sample file (93Mo) :
http://dl.free.fr/iFT4hH3Yj
I'll try to rebuild gdal on my linux box with the internal libs
I haven't looked at your result image, but you cannot just specify
NBITS=8 or
12, if the range of the values in the original file is full 16 bits.
You need to rescale the values, otherwise they will get clamped to
[0, 255] or
[0, 4096].
So you can look for the min/max reported by gdalinfo -mm
uncompressed_original.tif
and then try :
gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif
compressed.tif
-scale min max 0 255 -ot Byte
or
gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif
compressed.tif
-scale min max 0 4095 -co NBITS=12
Thanks, I didn't knew that !
The man says that you can omit the input min max scale so gdal
computes it for each source, however I can't find how to write that
correctly
_______________________________________________
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
