[ka-Map-users] Color shifts using QUANTIZE_COLORS=256

Steve Lime Steve.Lime at dnr.state.mn.us
Wed Aug 9 20:25:37 EDT 2006

You know what's funny is that old versions of MapServer used to reserve
by computing a palette when looking at the mapfile. That way the vector
always was consistent.

I think a PALETTE option within the IMAGE block might be a way to go.
That way
you could define a set of colors to pre-allocate when setting up 8-bit
imagery. Something

  PALETTE 'colors.txt'

Where colors.txt would contain:

r g b
r g b


Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
>>> Stephen Woodbridge <woodbri at swoodbridge.com> 08/09/06 4:56 PM >>>
Paul Spencer wrote:
> Steve,
> I concluded the same thing you did (that the colours are mangled).  
> FrankW had an explanation for this that I didn't really understand. 
> suggested that providing a mechanism to specify a fixed colour table 
> would be the real answer.
> Tile sizes in my experiments were 50% smaller in most cases (using 
> quantization).
> Dithering had no observable effect on the colour problem, but did
> in crappy looking images in most cases (hence I suggested turning it
> ImageMagick is able to produce outstanding 8bit pngs from 24bit 
> antialiased images, so it is possible.

So have you guys done anything along the line of integrating ImageMagick

  with mapserver? How did you do your testing with ImageMagick? It seems

that most of my tiles are close enough in color that it is not 
noticeable, but every now and then there is a very noticeable

> I would love to see something in mapserver that kept track of all the 
> colours that were allocated in the various styles and rendering
> and from the headers of the raster symbols, and used that as the
> table when doing quantization or whatever is needed.
> As a minimum, it should be possible to specify a COLORS block or 
> something at the MAP level that would force those colours into the 
> output image.  This would actually solve a long standing issue with 8 
> bit images and raster symbols where antialiased text uses all the 
> colours and then the raster symbol colours get mangled.

Yeah, it seems we should do something like this. We have been struggling

with color shift issues for a few years now. We fix one and another pops

Do you have any thoughts on using ImageMagick vs AGG? It seems that AGG 
would produce better images in general. I wonder if it does antialiasing

directly into an 8-bit image which I would think would give you much 
better control.


> My 2c
> Paul
> On 9-Aug-06, at 1:56 PM, Stephen Woodbridge wrote:
>> Hi all,
>> Sorry for the cross-post, but this seems valid for both groups.
>> I have mapserver configured to work with ka-map and things are
>> fine except we have noticed color shifts in tiles. We are using:
>>     NAME PNG8
>>     DRIVER "GD/PNG"
>>     EXTENSION "png"
>>     MIMETYPE "image/png"
>>   END
>> in our mapfile and my hypotheses is that the GD QUANTIZE process is
>> selecting different colors based on the colors available in the
>> meta-tiles. The mapserver source code calls the following function
>> this process and from the GD manual:
>>> void gdImageTrueColorToPalette(gdImagePtr im, int ditherFlag, int
>>> colorsWanted) gdImagePtr
>>> im, int ditherFlag, int colorsWanted) (FUNCTION)
>>> gdImageCreatePaletteFromTrueColor returns a new image.
>>> gdImageTrueColorToPalette permanently converts the existing image.
>>> The two functions are otherwise identical.
>>> The function converts a truecolor image to a palette-based image,
>>> using a high-quality two-pass quantization routine. If ditherFlag is
>>> set, the image will be dithered to approximate colors better, at the
>>> expense of some obvious "speckling." colorsWanted can be anything up
>>> to 256. If the original source image includes photographic
>>> information or anything that came out of a JPEG, 256 is strongly
>>> recommended. 100% transparency of a single transparent color in the
>>> original truecolor image will be preserved. There is no other
>>> for preservation of alpha channel or transparency in the destination
>>> image.
>>> For best results, don't use this function -- write real truecolor
>>> PNGs and JPEGs. The disk space gain of conversion to palette is not
>>> great (for small images it can be negative) and the quality loss is
>>> ugly. However, the version of this function included in version
>>> 2.0.12 and later does do a better job than the version included
>>> to 2.0.12.
>> So, a few questions:
>> 1) Has anyone looked into the impact of using PNG24 images on
>>   a) image sizes
>>   b) ka-map tile-cache sizing
>>   c) compatibility with browsers
>>   d) impact on browser memory usage or performance
>> 2) I thought Paul Spencer said to use DITHERED=OFF, is this correct
>> 3) Has anyone looked at the GD routine? Would it be possible to add a

>> palette of say 32 colors that would be "sticky" and priority over 
>> other colors?
>> -SteveW
>> _______________________________________________
>> ka-Map-users mailing list
>> ka-Map-users at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/ka-map-users
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> +-----------------------------------------------------------------+

ka-Map-users mailing list
ka-Map-users at lists.maptools.org

More information about the ka-Map-users mailing list