[mapguide-internals] RFC60 - PNG8 color palette improvements thoughts about user palette

[Bruce Dechant]

UV,

Just to clarify. The changes required to support this should consist of:

1) A NEW resource type - ColorPalette. This hold the palette information.
2) A change to the Map Definition resource that references the NEW ColorPalette resource above.

With the above changes I don't see a need for any server configuration settings. Perhaps you could clarify why you still think there needs to be one.

The above could be expanded at a future date to support different color palettes per scale range. I would add this comment to your RFC to clarify the future direction.

I would be more than happy to help you with the changes needed for the Map definition resource schema and for what the ColorPalette resource schema looks like. These changes need to be documented in the RFC.

Note: I used the name ColorPalette above, as a suggested name only.

Thanks,
Bruce

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Wednesday, March 04, 2009 10:49 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 - PNG8 color palette improvements thoughts about user palette

Thanks Bruce.

The main coding challenge for me now is to find the code to access and 
store the resources.......

About the user palette...
I think this discussion might be misguided by the misconception that by 
changing the palette we could drastically change the looks.
As much as this is desireable there is a major problem... The Renderer 
uses the base colors of the map to create truecolor images.
The current algorithm only affects the color quantization to an 8bit 
(gif/png whatever) image.
Thus, if we apply a random palette to this quantization step we only 
create funny looking images.
_The base colors from the map definition and layer definitions are still 
used to compute the truecolor image from the map!!!!_

(e.g. I supplied a palette in my test setup which was missing one 
important base color.  The result was a map which had the original 
problem of differing base colors in adjoining tiles. )

So the only application for providing an external colormap to this 
algorithm is to include _additional _colors which are not the base colors.
For the map itself the color quantization which is achieved by including 
the base colors from the map and layer definition and force those
into the quantization algorithm does the right thing IMHO.
So the user can provide a UserColorPalette with /additional/ base colors 
which will be merged with the computed ones.

_So my suggestion for a closure of RFC60:_

Create a resource for the ComputedBaseColorPalette. This should be part 
of the MapDefinition.
The GetTile function looks for the MapDefinion.ComputedBaseColorPalette.
If this is not available a new one is created by Parsing all 
LayerDefinitons and the MapDefinitions to compute a new Palette from 
those colors and then stored.

Any change to the MapDefintion  removes this ComputedBaseColorPalette. 
(ClearTileCache hook maybe??)

In addition a UserProvidedColorPalette can be referenced or included in 
the MapDefinition.
If it exists it will be added to the ComputedBaseColorPalette _before 
_doing the 8bit color quantization.
This can be useful to include colors for symbols etc. (unless there is 
an easy way to parse the symbol library for color definitions)

------------
To extend the scope later we can add UserProvidedColorPalette also to 
LayerDefinitions and a Method which parses the Map with a given zoom level
to add up all colors found. Just for the base colors this seems an 
overkill.


Everyone happy with this?


Bruce Dechant wrote:
> Uv,
>
> This is a great idea for improving the quality of the base maps.
>
> As Jason suggested having the color palette information defined in the map definition is nice. Ideally, a NEW ColorPalette resource could be added and then referenced by the Map Definition resource. This would allow them to be reused across multiple maps if needed and allow for quick editing/modifying by only having to adjust one palette that may apply to several maps. 
>
> As for which memory caching strategy to use I would suggest you make this configurable as it is very easy to add one and access it:
>
> You could add a NEW property to the serverconfig.ini file under the [TileServiceProperties] section, ex: ColorPaletteCachingStrategy
>
> The code below is some sample code for reading this setting from the ini file.
>
>             MgConfiguration* configuration = MgConfiguration::GetInstance();
>
>             configuration->GetIntValue(
>                 MgConfigProperties::TileServicePropertiesSection,
>                 MgConfigProperties::TileServicePropertyColorPaletteCachingStrategy,
>                 colorPaletteCachingStrategy,
>                 MgConfigProperties::DefaultTileServicePropertyColorPaletteCachingStrategy);
>
> The above would give the most flexibility in fine tuning the caching for the color palettes without actually requiring much more coding effort.
>
> Thanks,
> Bruce
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
> Sent: Sunday, March 01, 2009 6:59 PM
> To: MapGuide Internals Mail List
> Subject: [mapguide-internals] RFC60 - PNG8 color palette improvements please comment
>
> Hello,
>
> there is RFC60 place in the list and needs some commenting.
> Currently, we are looking into a serverconfig.ini parameter
> UseColorPalette in the TileServiceSection.
> upon init of the tile cache this parses the map definition and produces
> a palette with the map colors.
> Those are then used in some 100 extra line of C code in AGGImageIo.cpp
> to force those colors in
> the map used for the PNG8 created from the truecolor tile passed in by
> the rendering service.
>
> 1- which memory strategy is recommended for the color quantization? (3
> options in the RFC (stack, fast heap, efficient heap))
> 2 - is the ServerTileService the right place to put the code to collect
> the map colors?
> 3 - any suggestions regarding the naming and location of the color
> palette within the map definition?
>
> Comments are welcome!
> Also a few guiding remarks concerning the integration of the
> configuration code would make extremely helpful
> as just knowing where to start looking saves day of wasted code studies.
> These things are missing in the architecture
> docs so far.
>
> This is work in progress as there is a sponsor for it.
> Thanks for your support.
> UV
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>   

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals