This is a bug that sorely needed to be fixed. I was originally planning to go for the 2.4 final release after RC2, but now I'm considering a 3rd RC just to get this patch in with a good round of testing.
Many thanks for this patch. I'm definitely gonna give this a workout.
The proper solution to the bug is to preserve exactly the color that
has been chosen in map layers if their number is below the 256 entries
in the palette.
A sort of color quantization with some centroid color fixed.
Otherwise even a small pan may discover a part of the map with
different colors w.r.t. the rest and color quantization may lead to
different palette entries.
This is quite visible where you have large filled polygons, which
colors drift significantly or in cases when colors are prescribed and
should not be modified.
It also affects map readability since colors drift from their legend entries.
I'm willing to test your patch since it may be a good mapguide enhancement.
I like to look at this from a macro-level perspective.
Yes, there may still be the aforementioned bugs w.r.t. palette preservation, but the fact that I can finally have transparent PNG8 tiles means this patch is still a net gain over what we had previously (opaque tiles when tile image format is PNG8)
It is possible to add some fixed palette color in this.
But i really would like to see how it reacts on a big tiled map full of colors.
The mapserver quantization looks pretty good. It is possible that we dont need it.
I've taken a stab at this. Turns out that the new PNG8 code path in Bruno's patch does nothing with the computed baseColorPalette parameter that gets handed down.
So my changes now tell msQuantizeRasterBuffer() to compute a palette of (256 - baseColorPalette.size()) colors, and fill the remainder of the palette with the colors from the baseColorPalette parameter, which is only done if baseColorPalette is not NULL and has < 256 colors.
New MgRenderers.dll for MGOS 2.4 RC2 attached to the same ticket.
I've tried this also. And i have not see much difference on the resulting images.
The msquantization seem pretty smart, it compute a color histogram first. For each color theres the amout of pixels used. Then it is sorted. So color that are used mostly in the image will be in the palette.
When passing a predefined palette,we may reserve a color that is not use in the images.
Then loosing some color accuracy
I've tested some tiled maps here, and they are all super nice.
I really would like to see other tileds maps, or having some feedback from other users before applying this type of modification.
We could also replace the s_useColorMap memory flags by a serverconfig.ini switch
Unless I got this PNG8 quantization business all wrong, if the resulting image would use < 256 colors then there shouldn't be a need for the quantizer to compute a palette is there? Just take this list of colors that we've extracted out of all the Layer/Symbol Definitions and let the PNG8 quantizer "fill in the blanks" up to the 256 colors.
If we have defined these colors in our Layer/Symbol definitions, I think they should be respected if the total number of colors used < 256.
One of the issues is that with subpixel rendering using AGG, a map using
60 base colours will actually use more than 60 colours for fine edges
(so I believe)
The reason why we use a predefined palette for tiles is that for
we were having heaps of problems with the colour of ocean changing
obviously this is less of a problem with a single image dynamic map.
Perhaps the ultimate solution would be to feed to predefined palette into the
the quantization routines as a hint, with any used predefined colours being
discarded. Perhaps this could be triggered when a certain threshold is reached,
i.e. a full palette. An obvious example would be a map using a raster background
> Unless I got this PNG8 quantization business all wrong, if the resulting
> image would use < 256 colors then there shouldn't be a need for the
> quantizer to compute a palette is there? Just take this list of colors that
> we've extracted out of all the Layer/Symbol Definitions and let the PNG8
> quantizer "fill in the blanks" up to the 256 colors.
> If we have defined these colors in our Layer/Symbol definitions, I think
> they should be respected if the total number of colors used < 256.
> - Jackie
> View this message in context: http://osgeo-org.1560.n6.nabble.com/patch-for-Ticket-743-png8-transparency-tp5003596p5004724.html > Sent from the MapGuide Users mailing list archive at Nabble.com.
> mapguide-users mailing list
> [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-users
I've put up a 3rd version of this patch (with matching MgRenderers.dll).
I screwed up the color preservation logic in the previous version. Turns out if you ask for (256 - baseColorPalette.size()) colors in msQuantizeRasterBuffer, it may not exactly fill up to that number of colors that your requested (it could be less), resulting in potential overruns of the baseColorPalette, when appending them to the computed palette.
The maps where I tested Bruno's original patch did some unwanted color shifting for some symbols, but those colors are retained in this patch.