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

[Steve Lime]

Palettes, as computed in the MapServer 3.x series, were used to
initialize 8-bit
images. That was pre-24-bit support and I don't think would be helpful
in the
24-bit to 8-bit conversion.

If you were to use a pre-computed palette then you wouldn't need to
quantitize 
since a color map is the output of that process. You would just need to
filter the
24-bit data through the map (with gdImageColorClosest or whatever) to
arrive
at an 8-bit image. 

I have used ImageMagick to do something like that years ago. I took a
representative
24-bit image and used ImageMagick to convert to 8-bit (which it does
nicely) then
use that color map with the convert command (the -map option) to
process the rest
of the files. At the end they all had the same color map.

So my idea would be to support a PALETTE like that (instead of
quantitizing)...

Steve


>>> Paul Spencer <pspencer at dmsolutions.ca> 08/10/06 7:33 AM >>>
Steve and Steve :)

what would it take to get the PALETTE option implemented (perhaps for 

5.0?) and supported in the quantization code?

ImageMagick does do this very well.  I would assume that AGG could do 

the same, and likely much faster than ImageMagick (which appears to  
be 2-5 times slower).

Cheers

Paul

On 9-Aug-06, at 8:55 PM, Stephen Woodbridge wrote:

> Steve Lime wrote:
>> You know what's funny is that old versions of MapServer used to  
>> reserve
>> colors
>> by computing a palette when looking at the mapfile. That way the  
>> vector
>> data
>> always was consistent.
>
> I think there is has been code added to do this again in the  
> current version of code.
>
>> 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
>> like:
>>   PALETTE 'colors.txt'
>> Where colors.txt would contain:
>> r g b
>> r g b
>> ...
>
> The other way to do this that I have been doing for some time now  
> is to create an image in photoshop and set single pixels to the  
> colors that are important to me and insert is as the first LAYER in 

> the mapfile which causes its colors to be added to the map image  
> before any antialiasing is done.
>
> BUT, this does not solve the problem of PNG24 RGBA images required  
> for AA brushes and squashing images to PNG8 with the  
> gdCreateColorPaletteFromTrueColor() (or whatever it is called)  
> function because we do not have direct control of the color palette 

> in this case, unless we clone and modify the algorithm by somehow  
> making the colors "sticky" in the palette.
>
> Steve I would be interested in knowing what you think about the  
> later approach.
>
> Since I only have limited experience with ImageMagick, it is really 

> hard for me to say if it would solve these particular problems or  
> not. Than again, if we want really pretty images AGG seems to be  
> the way to go :)
>
> -SteveW
>
>> Steve
>> Stephen Lime
>> Data & Applications Manager
>> Minnesota DNR
>> 500 Lafayette Road
>> St. Paul, MN 55155
>> 651-259-5473
>>>>> 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.
>> He
>>> 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
>> result
>>> in crappy looking images in most cases (hence I suggested turning
it
>> off).
>>> 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
>> difference.
>>> I would love to see something in mapserver that kept track of all 

>>> the colours that were allocated in the various styles and
rendering
>> stages,
>>> and from the headers of the raster symbols, and used that as the
>> colour
>>> 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
>> up.
>> 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.
>> -Steve
>>> 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
>> working
>>>> fine except we have noticed color shifts in tiles. We are using:
>>>>
>>>>   OUTPUTFORMAT
>>>>     NAME PNG8
>>>>     DRIVER "GD/PNG"
>>>>     EXTENSION "png"
>>>>     MIMETYPE "image/png"
>>>>     IMAGEMODE RGBA
>>>>     TRANSPARENT OFF
>>>>     FORMATOPTION "QUANTIZE_FORCE=ON"
>>>>     FORMATOPTION "QUANTIZE_DITHER=OFF"
>>>>     FORMATOPTION "QUANTIZE_COLORS=256"
>>>>   END
>>>>
>>>> in our mapfile and my hypotheses is that the GD QUANTIZE process
is
>>>> selecting different colors based on the colors available in the
>> various
>>>> meta-tiles. The mapserver source code calls the following
function
>> for
>>>> this process and from the GD manual:
>>>>
>>>>> void gdImageTrueColorToPalette(gdImagePtr im, int ditherFlag,
int
>>>>> colorsWanted) gdImagePtr
>> gdImageCreatePaletteFromTrueColor(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
>> support
>>>>> 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
>> prior
>>>>> 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 
>> 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 
http://lists.maptools.org/mailman/listinfo/ka-map-users