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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://lists.maptools.org/mailman/listinfo/ka-map-users
+-----------------------------------------------------------------+
|Paul Spencer [EMAIL PROTECTED] |
+-----------------------------------------------------------------+
|Applications & Software Development |
|DM Solutions Group Inc http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+
_______________________________________________
ka-Map-users mailing list
[EMAIL PROTECTED]
http://lists.maptools.org/mailman/listinfo/ka-map-users
