[Gdal-dev] gdal_translate and Dynamic Range

[Frank Warmerdam]

Scott D. Elko wrote:
> I’ve several 16-bit NITF images. In using OpenEV 1.2.2, I’m able to 
> utilize the “Export” function, select “Advanced Options”, use “Draw ROI 
> Mode”, select “Window Input File” and “Scale to View Settings” to 
> produce a beautiful 8-bit geoTiff chipped out image who’s dynamic range 
> is spot on.
> 
> However, no matter what I do, I can’t seem to reproduce the same results 
> using gdal_translate. In short, the dynamic range of the gdla_translate 
> produced image is not even close (ie., much, much darker) than that of 
> the OpenEV image. In addition to specifying –srcwin, the gdal_translate 
> parameters, I’m using are:
> 
> -scale (w/o any scale factors since it’s suppose to calculate the proper 
> min and max for src and dst)
> -ot Byte
> 
> The only way I’ve been able to get halfway decent results is to specify 
> “–scale 0 600” but this seems to be a hack. I’ve even experiment with 
> other gdal_tranlsate options to produce exactly the same informational 
> results yielded by gdla_info on the OpenEV produced image but have come 
> up empty handed.

Scott,

OpenEV has a substantially smarter set of scaling logic than the
gdal_translate -scale defaults.  In particular I believe OpenEV
computes a histogram and then does tail trimming to pick end scaling
points.  You can open the layer dialog (right click on the layer in
the layers list), and then select the "Raster Source" tab to see what
scaling min/max was selected by OpenEV.  If you use those values with
gdal_translate -scale you should get similar results.

> The funny thing is that if I use gdla_translate to produce a geoTiff 
> image then apply gdal_translate on that resultant image, as expected, 
> the second image is somewhat better but not even close to that of the 
> OpenEV produced.

This is presumably because gdal_translate will scale based on the
computed min/max of the whole image, not the area you are chipping out
with the -srcwin flags.  By cutting it down first, you correct for this
issue.

> Can anybody share any ideas in how to get gdla_translate to produce the 
> same result as that of OpenEV? Or is it an impossible feat that I’m 
> trying to accomplish?

gdal_translate isn't going to have the same logic as OpenEV.  So you
either have to compute the scaling min/max by some other means (perhaps
inspecting it in OpenEV or a script) and use those with gdal_translate,
or you are going to have to emulate the logic of OpenEV in a script of
some sort.  In fact, depending on the circumstances you might be able
to write a Python script that imports the OpenEV core, and use it to
do the operation, but does not actually create any user interface
components.  This could be tricky though.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org