24-bit image is rendered in greyscale when using CLASS in LAYER

[tbonfort]

Reporter: hjulien@nrcan.gc.ca Date: 2006/02/27 - 21:27

Hi,
When I add a class item to my mapfile's raster layer my 24bit RGB tif is
rendered in greyscale. I need the class item in order to generate a legend item
in my ogc wms capabilities. In the following bugzilla report a similar problem
is flagged as fixed however I am using mapserver 4.5 and 4.8.1 and both versions
have the same bug. 

http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=270

When I resample my tif raster to 8bit everything works fine. Anyone has an idea
of what is going on?

Example:

LAYER
  NAME "d1_1960_et_ws"
  DEBUG ON
  STATUS ON
  GROUP "Evapotranspiration"
  DATA "d1_1960_et_ws.tif"
  TYPE RASTER
  PROJECTION
   "init=epsg:42304"
  END
  DUMP TRUE
  TEMPLATE "tmpl"
  MINSCALE 1000000
  MAXSCALE 1000000000
  TOLERANCE 30
  METADATA
   "ows_title" "Annual land evapotranspiration estimate for Canada 1960"
   "ows_group_title" "Annual land evapotranspiration estimate for Canada"
   "ows_group_abstract" "Annual land evapotranspiration estimate for Canada"
   "ows_abstract" "to do…"
   "ows_keywordlist"  "water, evaporation, evapotranspiration, transpiration"
   "wms_opaque" "1"
#   "ows_extent" "-101.0542 18.4369 -80.5434 31.5619"
   "ows_metadataurl_type" "FGDC"
   "wms_metadataurl_format" "text/html"
   "ows_metadataurl_href" "http://adaptation.nrcan.gc.ca/"
   "wms_dataurl_format" "text/plain"
   "wms_dataurl_href" "http://adaptation.nrcan.gc.ca/"
   "gml_include_items" "all"
  END
  CLASS
   NAME "Scale"
   KEYIMAGE "../geo/ResEau/d1_1960_et_wsleg.tif"
  END
 END

Cheers 
Héryk Julien
NRCan

[tbonfort]

Author: fwarmerdam Date: 2006/02/27 - 21:49

Héryk,

This isn't really a complete demonstration of the problem. 
I would appreciate a mapfile that works with shp2img, and
the demonstration should include a modest sized data file. 

Imagine that I am really lazy and just want to unzip a file, and type
"shp2img -m test.map -o out.png" to see the problem. 

What I hate is spending a bunch of time fooling around initially
just trying to reproduce the problem.  I never know if I am 
assuming something different than the submitter or what. 

[tbonfort]

Author: fwarmerdam Date: 2006/02/28 - 00:13

Heryk,

I commented out the PROJECTION blocks, and modified the KEYIMAGE 
declaration to point to the local keyimage file.  I then ran the command:

  shp2img -m reseau_short.map -o out.png

The resulting out.png had a color output image.  

For completeness I also tried enabling the IMAGETYPE to be JPEG, and
still got a color image though it had greyscale edges on the left and right
where the image data was missing.

I tested with MapServer built from the 4.8.1 release tag in CVS on Linux.

Just how sure are you that you were really using MapServer 4.8.1 when
you were getting the problem?  Have you tried reproducing with shp2img?

Perhaps you could try with the MS4W 1.4.0 shp2img.  That way we would
have a "known" binary to we can both test against.  

[tbonfort]

Author: hjulien@nrcan.gc.ca Date: 2006/02/28 - 19:57

Hi Frank,
I tested the wms service in Mapserver 4.5 and 4.8.1 with Gaia 2.0.4 to make
quick wms calls.

“Imagine that I am really lazy and just want” to make rapid calls to the server. ;-)

Both servers kept on giving me a greyscale image. Then I tried calling Mapserver
4.5 and 4.8.1 directly in Firefox with a getmap request. The 4.5 version gave me
a greyscale image but the 4.8.1 version gave me a correct coloured image!

I think I was encountering 2 bugs. The first bug is with Mapserver's 4.5 class
object and 24bit images. That was fixed in version 4.8.1. The second bug is with
Gaia's capacity to display 24bit images. The good news is that this bug is not
related to Mapserver.

Thanks for the help.
I hope I haven't wasted too much of your time.
Cheers
Héryk

FYI: Gaia http://www.thecarbonproject.com/products/gaia.html

[tbonfort]

Author: fwarmerdam Date: 2006/02/28 - 20:09

Héryk,

Luckily my lazyness saved me from spending too much time on initial 
error reproduction. :-)