[mapguide-internals] RFC60 - PNG8color paletteimprovementspleasecomment

[Jason Birch]

I think I should have stayed away from the word user :)  By user-defined, I meant that the system administrator could upload a palette based on the computed palette but which includes additional colours.  For instance, if there are some transparency blends that occur over large areas and you want to have them look consistent.  I don't think that this is a big deal though.  I like the approach that you are taking, and just being able to count on the colours that are explicitly defined in the map will be a great improvement.  And I guess if it's stored as resource data, it could be manually tweaked if desired.
 
By other 8bit outputs, I didn't mean other image formats.  I meant that rather than only applying the computed palette to GetTile calls, that it would be useful to apply it to any method that renders PNG8 (or GIF, JPG).  For instance the methods that return a map image (GetMapImage?) or dynamic map overlay (GetDynamicMapOverlay?) should have the palette applied to them as well.
 
Jason

________________________________

From: mapguide-internals-bounces at lists.osgeo.org on behalf of UV
Sent: Wed 2009-03-04 10:14 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 - PNG8color paletteimprovementspleasecomment



I think to use the palettes for other 8bit images is not a problem.. (in
the moment the only other format is GIF) (at least in the AGG Renderer)

I agree, ideally we need some code that parses the Map with a given zoom
level and collects colors..... base colors and provided Colors.
however, I don't think this is in the scope of this work....

As the computedPalette and the ProvidedPalette will be stored as a
Resource I think it can be already accessed with  a GetResource API call.
Is this important enough to change the mapagent API? I am not sure.
Actually the term UserProvidedPalette from earlier messages is a
misnomer as this concept does not make a lot of sense on a per user basis
This is not a base color map which can _replace _the base colors of the 
map definition!
Having different user palettes for different users viewing the same map
does not make sense to me.

Furthermore I think instead of a configuration value this process can
easily be controlled by the existence of the AdditionalColorPalette.
If its there its used (always in addition to the base color algorithm)
If its not wanted the resource reference can be simply removed.

I think parsing some XML to collect the base colors is cheap enough to
not worry too much about computational costs. (Please correct me if I am
wrong.)
As this is very closely connected with the map (until it changes) a
resource within the map is a good place keep it.

So the idea for another RFC...
A way to define a bijective mapping from  the color definitions of a map
to a color palette such we can replace the base colors of the map by
providing a color palette.
Very nice one. Also on a per user basis. But not in the scope of RFC60.