Opened 19 years ago

Closed 14 years ago

#1318 closed defect (wontfix)

SCALE can cause maxvalues to be transparent.

Reported by: kruland@… Owned by: warmerdam
Priority: high Milestone:
Component: GDAL Support Version: 4.4
Severity: normal Keywords:
Cc:

Description (last modified by warmerdam)

In mapdrawgdal.c, the computation for dfScaleRatio on line 1147 can cause pixels
with values of "dfScaleMax" to be mapped to 256.  If NoDataValue is -1, this
causes the pixels to be transparent.

Change to dfScaleRatio = 255.0/(dfScaleMax - dfScaleMin);

Attachments (3)

input.tif.gz (185.1 KB ) - added by kruland@… 19 years ago.
Original tif image
mapfile (1.2 KB ) - added by kruland@… 19 years ago.
Mapfile
samplemap.gif (20.6 KB ) - added by kruland@… 19 years ago.
Output gif image

Download all attachments as: .zip

Change History (6)

comment:1 by fwarmerdam, 19 years ago

Status: newassigned
Kevin,

I assume the code segment in question is this:

    dfScaleRatio = 256.0 / (dfScaleMax - dfScaleMin);

    for( i = 0; i < nPixelCount; i++ )
    {
        float fScaledValue = (float) ((pafRawData[i]-dfScaleMin)*dfScaleRatio);

        if( fScaledValue < 0.0 )
            pabyBuffer[i] = 0;
        else if( fScaledValue > 255.0 )
            pabyBuffer[i] = 255;
        else
            pabyBuffer[i] = (int) fScaledValue;
    }

As you can see as values are applied to pabyBuffer[] any values
larger than 255.0 are assigned the value 255, so I don't see that 
improper scaling could result in a value being mapped to 256 and 
wrapped to 0 (or treated as -1?). 

But I am confident that the current logic is appropriate. 

For instance, imagine a case where we have an input range of
0 to 65535 (full 16bit).  Using your logic the calculation
for output values would be (input) * 255 / 65535.  In this
case the value 65535 would be mapped to 255, but 65534 would
be mapped to 254.  So, essentially only the most extreme value
would be mapped to the top "bucket".  But really there should
be 256 (or perhaps 255) of the top values of the 0-65535 range
that would get mapped to 255 to be symmetric. 

Where is your nodata value coming from?  A value of -1 assigned
to an unsigned char will wrap to 255 - so it may well be that 
the nodata is being applied improperly.  

by kruland@…, 19 years ago

Attachment: input.tif.gz added

Original tif image

by kruland@…, 19 years ago

Attachment: mapfile added

Mapfile

by kruland@…, 19 years ago

Attachment: samplemap.gif added

Output gif image

comment:2 by kruland@…, 19 years ago

Frank.

I've attached files which demonstrate the problem.  The original tif image
(gzipped) has NoVal =-1, and Float64 data values in the range of [0.0,1.0]. 
After using SCALE = 0,1 the data with value of 1.0 become transparent which
confuses them with those pixels with NoVal.

Please note, I'm using the python bindings to produce the image and inserted a
mapObj.save() method call to produce the mapfile.  I'm a rookie and don't really
know if this mapfile can be used to replicate the problem.

If you change the SCALE to 0,1.1 then the white values come out "white enough".
 I believe they are actually valued 253 or so.

Kevin

comment:3 by warmerdam, 14 years ago

Description: modified (diff)
Resolution: wontfix
Status: assignedclosed

Oddly the mapfile does not include a layer definition so it is not to clear how to reproduce the problem.

However, it is clear that scaling of end values is not very dependable. So a "SCALE=0,1" should not be trusted to treat 0 or 1 as being in the range. Where this is important, a small epsilon value should be added/subtracted to ensure end values are in range.

Note: See TracTickets for help on using tickets.