[mapserver-users] mapserver/gdal

[Frank Warmerdam]

Ed McNierney wrote:

> Peter -
> 
> *IF* I'm reading the code right, it appears that MapServer will read a
> GDAL single-band data set as 8-bit values by asking GDAL to provide the
> data in 8-bit format.  GDAL will convert .bil data that's signed 16-bit
> (Int16) to 8-bit by:
> 
> 1. Returning 0 if the source pixel is <= 0.0
> 2. Returning 255 if the source pixel is >= 255.0
> 3. Returning the source pixel value in all other cases
> 
> In short, just clamping all values outside the range to either 0 or 255.
> 
> If you just want to do a quick hack, it would be REALLY easy to change
> this behavior (or behaviour) to handle the pixel differently.  The
> code's in the GDAL source in core/rasterio.cpp - look for the
> GDALCopyWords function about 2/3rds of the way down the file.  You'll
> have to figure out the proper conversion for your data, which would
> depend on the range of input values and how you want to represent them.
> 
> Please remember that this message started with an *IF*, and if someone
> could either confirm or correct what I'm saying I'd appreciate it.
> Thanks!


Ed / Peter,

Ed's assumptions about what drawGDAL() is currently doing for 16bit data is
correct.  However, rather than trying to change the behaviour in GDAL, I
would think it better to change the behaviour in drawGDAL().

In Peter's case he apparently has a classification scheme he would like to
apply to the raw 16bit values.  The problem is that drawGDAL() (for
efficiency and simplicity) currently utilizes the classification scheme
to classify values between 0-255 and asumes that this is all that is
necessary.  Then the GDALRasterIO() call ensures that all values are
clipped into this range.

A few options exist.

  1) perform the getClass() call for every pixel value.  That would mean
     deferring it into the loop after the GDALRasterIO(), and using it in
     place of the cmap[] lookup.  This approach would work well for all sorts
     of values, including floating point values, but would be relatively
     slow.  getClass() is likely too slow to want to call it for every
     processed pixel in web mapping application.

  2) For 16bit data, a 16bit lookup table could be created.  Much like it is
     now getClass() would be called for each entry in the loopup table, but now
     instead of 256 entries it would be 65536 entries.  This might be a bit
     expensive and wouldn't scale up to floating point values or Int32 values.

  3) Perhaps case 2) could be modified to recognise the upper and lower bounds
     of the classification information, and produce an appropriately reduced
     lookup table.

In any of these cases, the GDALRasterIO() call would need to be altered to
read the data without clamping to 256 entries.  The third last argument is
the datatype to read the data as.  This can be changed to GDT_Int16,
GDT_UInt16, GDT_Int32 or GDT_Float32 for instance.


I had been intending to implement some sort of upgrade to drawGDAL() in 

mapraster.c along the lines of 1) at some point but haven't gotten around
to it yet.


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    | Geospatial Programmer for Rent