static color Palette support for gd output

[assefa]

The gd format has currently the possiblity to draw a 24 bits image and output an 8 bits image using the QUANTIZE_COLORS functionality. When using this method in Mapserver and generating tiled maps (eg with kaMap), there was an issue since the colors were "random" between tiles and may cause 2 adjacent tiles to use a different color for the same feature. The idea here is to be able to add a static color palette that can be used when tranforming 24bits to 8 bits.

[assefa]

The initial implementation has been done and tests ar on going. The functionality is accessed by defining a the following in the outputformat :

OUTPUTFORMAT

NAME "agg/png24" MIMETYPE "image/png; mode=24bit" DRIVER "AGG/PNG" EXTENSION "png" IMAGEMODE "RGBA"

FORMATOPTION "PALETTE=c:/msapps/fbs-navteq/map/palette.txt" FORMATOPTION "FULL_RESOLUTION=TRUE"

END

The path to the palette is for now a full path to a test file conating r,g,b values on each line :

242,236,230 150,150,150 0,0,0 ...

the current implemenation allocates the colors found in the palette into the 8 bit image and also uses the gdImageCreatePaletteFromTrueColor to allocate the rest of the available colors.

[sdlime]

Leaving this ticket open but changing component to documentation to make sure that happens.

Steve

[assefa]

We are running into some performance issues with images of 6000/6000 (kaMap Tiles). The performance hit seems to come from the msImageCopyForcePaletteGD when goinf through each pixel and using gdImageColorClosest to find the closest color. There may be ways to optimize this (maybe some sort of caching or hashing). Looking into this but Steve if you have suggestions let me know.

[assefa]

We looked a bit in the performance issue reported earlier with large images.

One possible solutions we tried was to cache few colors in msImageCopyForcePaletteGD so we do not call gdImageColorClosest for those that are in the cache.

Just caching the last color made a dramatic drop in time with our test tiles of 6000/6000. Tried diffrent size of cache (keeping 10, 20, 50 colors) and we had the best result with 10 colors although the diffrence between them was not significant.

Steve, I would like to add this cahing if it is ok with you.

As a comparative, results here are the numbers that Zak got:

Here is the timing information, just for the record. Image is 6144*6144 navteq road data of wisconsin.

AGG before patch: 111.855 AGG after patch: 27.520 GD-PNG 8: 19.526 GD24: 19.731

[sdlime]

By all means, add the caching. Are there any threading issues with the color cache?

Steve

[assefa]

Caching is done locally in the function and should not have any threading issues. Commited in r6335.

[hobu]

Has this work been completed and this bug can be closed? If so, we should update HISTORY.TXT also.

[assefa]

Work is completed with the exception of full path requirement for the palette file. Once docs are done on it, this bug should be moved to a Future or 5.2 to be able to adress the full path issue.

Adding missing entry in HISTORY.txt r6502

[dmorissette]

I'd suggest using two bugs (creating a new bug for the 5.2 enhancements) to avoid having the confusion of bugs spanning over multiple versions.

[sdlime]

There is a full path bug already for 5.2.

Steve

[assefa]

my mistake : only the doc part is remaining for this bug; there was already a seperate bug on the path issues (#2115)

[assefa]

Note : just found a bug in msImageCopyForcePaletteGD, fix commited in r6525.

[tbonfort]

this is documented now