Changes between Version 8 and Version 9 of MapGuideRfc60
- Timestamp:
- 03/25/09 04:20:52 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc60
v8 v9 38 38 39 39 By providing the base colors of the map in a palette file and using an improved color quantification algorithm which adds a forced palette to the image the resulting map can be significantly improved. 40 This can be done by using the median-cut algorithm as used in the mapserver code base in the function ` msImageCopyForcePaletteGD`.40 This can be done by using the median-cut algorithm as used in the mapserver code base in the function `ImageCopyForcePaletteGD`. 41 41 42 42 {{{ … … 49 49 * -1 is a memory conservative method, that uses very little caching but is much slower 50 50 * -2 is a memory hungry caching method (allocates 32MB on the heap) but is the fastest for large images 51 *52 51 * see bug #2422 for some benchmark timings of these methods 53 52 */ 54 static int msImageCopyForcePaletteGD(gdImagePtr src, gdImagePtr dst, int method);53 int ImageCopyForcePaletteGD(gdImagePtr src, gdImagePtr dst, int method); 55 54 /// create an empty paletted gdImage of size (x,y) using the base colors provided in the baseColorPalette 56 55 /// the original truecolor image img24 is used to fill up the remaining slots of the palette if needed … … 68 67 The RenderingService reads the color list from the map object, sorts and uniquifies it, and converts it into a more appropriate Colortype. 69 68 This color palette is then passed down via the AGGRenderer to the AGGImageIO objects Save method. Here the png color quantification 70 algorithm is included to force the provided palette into the rendered image - this way making sure that the correct base colors survive the compression and/or color quantization. 69 algorithm is included to force the provided palette into the rendered image - this way making sure that the correct base colors survive the compression and/or color quantization. 70 see also the sequence [http://trac.osgeo.org/mapguide/attachment/wiki/MapGuideRfc60/GetTile2.png] 71 71 72 72 == Implications == 73 73 74 No Implications are intended as this behaviour is desired by default. We just get better looking maps. The cost of extracting the colors from the in-memory representation of the XML data describing the map are presumed to be negligable. 74 75 … … 95 96 == open Issues == 96 97 97 1. The quantization algorithm uses quite some memory. 3 different memory allocation schemes have been provided. Selecting those is supposedly too specific to warrant a server option entry. 98 1. The quantization algorithm uses quite some memory. 3 different memory allocation schemes have been provided. Selecting those is supposedly too specific to warrant a server option entry. [[BR]] 98 99 However, the correct approach needs to be decided by a system architect with deeper insight into the MapGuide server architecture. 100 99 101 2. Is it sufficient to scan the colors from only the VectorLayerDefinitions and in there the Area, Line, and Point Symbolizations ? 100 3. How do we deal with color expressions? Are there some specs for this? 101 The current code is based on the existing XML schemas only (and the color definitions I could find in them) 102 103 3. How do we deal with color expressions? Are there some specs for this? [[BR]] 104 The current code is based on the existing XML schemas only (and the color definitions I could find in them) 105 102 106 4. Following ResourceId references is also not implemented. Is this crucial? 103 5. Memory issues: I think the current approach follows an easy producer consumer style regarding the color tables. 104 Again, my insight into the server architecture is limited and I am not 100% sure if all possible memory leaks have been avoided. 107 108 5. Possible memory issues: I think the current approach follows an easy producer consumer style regarding the color tables. [[BR]] 109 My insight into the server architecture is limited and I am not 100% sure if all possible memory leaks have been avoided.
