[gdal-dev] gdal_translate crash

[Frank Warmerdam]

Markus Neteler wrote:
>>I have checked in an update gdal_translate.c with the -scale option. If the
>>destination min/max values are omitted 0 and 256 are assumed. If the
>>src min/max are omitted they will be computed from the source data (the
>>same as gdalinfo -mm would report as min/max).
>>
> 
> Only one question here: Omitting src min/max is convenient (gdal_translate
> should find out itself), and destination min/max will be used more
> frequently. However, at time it is not possible to only specify the
> destination min/max and leave src min/max to gdal_translate, right?
> 
> -scale [src_min src_max [dst_min dst_max]]]
> 
> This would only be possible with
> -scale [dst_min dst_max [src_min src_max]]]
> 
> But probably I am missing something.
> 
> Anyway, thanks for the quick fix!

Markus,

Under the assumption that things would normally be scaled to eight bit,
I thought the destination min/max would more often be defaulted than the
source min/max - thus the ordering. You are right that currently there is
no way to default the source, but not the destination. However, it is fairly
easy to get the real min/max from the dataset with gdalinfo, so it doesn't
seem like an insurmountable issue.

I would also note that the use of absolute min/max for linear scaling is
often not that great. OpenEV has lots of logic built in about scaling rules
based percent tail trim from the histogram, or min/max being based on some
number of standard deviations. It would be nice to have a batch tool that
can apply these OpenEV algorithms, but there are no plans to do that for now.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent