Opened 18 years ago
Closed 14 years ago
#1594 closed defect (fixed)
24-bit RGB KEYIMAGE is displayed wrong when output image is 8-bit
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | MapServer C Library | Version: | 4.8 |
Severity: | normal | Keywords: | legend keyimage |
Cc: |
Description (last modified by )
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
Attachments (2)
Change History (7)
by , 18 years ago
Attachment: | msgSSTcolor.png added |
---|
comment:2 by , 14 years ago
Description: | modified (diff) |
---|---|
Keywords: | legend keyimage added |
Status: | new → assigned |
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 (r10094). But these are unrelated to the reported problem.
comment:3 by , 14 years ago
Component: | WMS Server → MapServer C Library |
---|
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.
comment:4 by , 14 years ago
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.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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 (r10096).
The 24-bit keymap