Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#3663 closed defect (fixed)

Classified non 8bit rasters not displaying

Reported by: msmitherdc Owned by: warmerdam
Priority: normal Milestone: 6.0 release
Component: GDAL Support Version: svn-trunk (development)
Severity: normal Keywords:
Cc: dmorissette, sdlime

Description (last modified by warmerdam)

Raster info:

Band 1 Block=480x4 Type=Float32, ColorInterp=Gray
  Min=18.645 Max=22.925 
  Minimum=18.645, Maximum=22.925, Mean=19.321, StdDev=1.002
  NoData Value=-3.4028234663852886e+38
  Metadata:
    LAYER_TYPE=athematic
    STATISTICS_MINIMUM=18.644718170166
    STATISTICS_MAXIMUM=22.925430297852
    STATISTICS_MEAN=19.320643792494
    STATISTICS_STDDEV=1.001758947595
  PROCESSING "SCALE=0, 255"
  PROCESSING "SCALE_BUCKETS=255"
  CLASS
    NAME "red"
    EXPRESSION ([pixel] > 0)
    STYLE
      COLOR 255 0 0
    END
  END

This displays a red raster in 5.6.5 but displays empty with trunk (r10920)

Attachments (1)

dem3_final_layer.map (1.1 KB ) - added by msmitherdc 13 years ago.
layer section showing >16bit data classification problem

Download all attachments as: .zip

Change History (11)

comment:1 by msmitherdc, 13 years ago

Cc: dmorissette added; dmorisette removed

comment:2 by warmerdam, 13 years ago

Description: modified (diff)
Status: newassigned

comment:3 by warmerdam, 13 years ago

Mike,

I have a similar test in the regression test suite (msautotest/gdal/class16_oddscale.map) and it seems to working ok. I think I will need a minimal map file and test data file I can use to reproduce this problem to go further.

by msmitherdc, 13 years ago

Attachment: dem3_final_layer.map added

layer section showing >16bit data classification problem

comment:5 by msmitherdc, 13 years ago

Hmm. I tried the autotest map, class16_oddscale.map, and it displayed fine in mapserver 5.6.5 but not in trunk (i got a blank image)

Both are linked dynamically to trunk gdal.

comment:6 by warmerdam, 13 years ago

It turns out I have the same problem here, I just didn't know because perceptualdiff was telling me the results matched the test image. perceptualdiff does not understand color tables and was thus of limited use for this comparison.

I am pursuing the bug...

comment:7 by warmerdam, 13 years ago

This relates to the following code in msGetClass_FloatRGB():

          case(MS_EXPRESSION):
            /*
            ** Big, fat TODO!
            **  
            ** See msEvalExpression() in maputil.c for an example of how to do this. Basically need to define some raster bind 
            ** variables: namely [red], [green], [blue] and [pixel]. Need to update the lexer and msTokenizeExpression() to 
            ** recognize them...
            */

            return(-1);

comment:8 by warmerdam, 13 years ago

Cc: sdlime added
Resolution: fixed
Status: assignedclosed

So it turns out that raster classification was never implemented when the expression parser was upgraded. I have done so now in trunk (r10976).

comment:9 by sdlime, 13 years ago

Oh crap, sorry. I did make the big fat TODO note at least. Thanks for covering my big, fat... I'll take a look at your implementation.

There should be massive speed increases with rasters, I'd be very interested to know if that's actually true.

Steve

comment:10 by warmerdam, 13 years ago

Steve,

The TODO was very helpful when I stepped through the code. :-)

I haven't tried any performance comparison - perhaps I can construct a test case.

Note: See TracTickets for help on using tickets.