24-bit RGB KEYIMAGE is displayed wrong when output image is 8-bit

[tbonfort]

Reporter: jorn@spacetec.no Date: 2006/01/04 - 17:48

This only happens when KEYSIZE in not default ("20 10").

Sample map file:

MAP
NAME DEMO
STATUS ON
SIZE 600 600
UNITS METERS
SHAPEPATH "data"
FONTSET "fonts.txt"
EXTENT -72493.34 5453045.5 100000 8922059.5
IMAGECOLOR 255 255 255
IMAGETYPE png

   PROJECTION
     "init=epsg:32633"
   END

   WEB
     HEADER demo_header.html
     TEMPLATE demo.html
     FOOTER demo_footer.html
     IMAGEPATH "/usr/local/apache/htdocs/tmp/"
     IMAGEURL "/tmp/"
   END

   LEGEND
        STATUS EMBED
        POSITION UR
        KEYSIZE 49 139
   END

   LAYER
        NAME "msgSST"
        DATA "SST.tif"
        TYPE RASTER
        STATUS default
        DEBUG ON
        OFFSITE 255 255 255
        PROJECTION
                "proj=stere"
                "lat_0=40"
                "lon_0=0"
        END
        CLASS
                NAME ""
                KEYIMAGE 'data/msgSSTcolor.png'
        END
   END
END

[tbonfort]

Author: jorn@spacetec.no Date: 2006/01/04 - 17:55

The layers's TIFF file is to huge (4MB) for upload.

[tbonfort]

Author: warmerdam Date: 2010/04/11 - 04:25 In attempting to reproduce this problem I found that MapServer trunk crashed if the keyimage was not found. After a fix to that, I found the error about the keyimage was still not being reported properly. I have applied fixes for both of these issues in trunk (36d5aad31a84e808ccd03ef824ec9058ae9216ea (r10094)). But these are unrelated to the reported problem.

[tbonfort]

Author: warmerdam Date: 2010/04/11 - 04:48 OK, there is definitely something funky here. If I render the image at the default keysize of 20 10 it seems like a photometrically accurate severe downsampling. But as the size grows more and more of the bottom ends up being greyscale. If rendered at full resolution everything is greyscale.

I would note that there even seems to be some problem if the 8bit keyimage is rendered at full size with part of the image being forced to greyscale.

My suposition is that there is a problem with "color table exhaustion" being encountered and it is more severe with big images with many individual colors in them.

[tbonfort]

Author: warmerdam Date: 2010/04/11 - 04:57 Diagnosis confirmed. msDrawMarkerSymbolGD() is used to draw the key image, and it just calls gdImageCopy() or gdImageCopyResampled() which adds every color copied to the destination image until color exhaustion takes place.

I'll investigate pre-stratefying the source image if it is 24bit and the target is 8bit.

[tbonfort]

Author: warmerdam Date: 2010/04/11 - 05:43 OK, I have applied the color stratification approach fairly narrowly to the 24bit -> 8bit case in msDrawMarkerSymbolGD(). It seems likely there are several other places a similar technique could be profitably used in mapgd.c.

However, with the given "color noisy" image this still only partly solves the problem. For a better behaved source image think it would have been sufficient.

I think this is about all that can be profitably done.

The changes are only in trunk (4d5ecf0a25f3969ea0b4ccb40c475849af93681d (r10096)).