Status of AGG support?
Stephen Woodbridge
woodbri at SWOODBRIDGE.COM
Sat Jul 14 16:37:46 EDT 2007
Hi Assefa,
Were you able to reproduce the problem I have? Steve Lime did. I am
wondering how you generated your images using AGG and if you can change
my test mapfile to make it work like yours?
-Steve
Yewondwossen Assefa wrote:
> I have downloaded the zip and will give it a try later today.
>
> Best Regards
>
> Stephen Woodbridge wrote:
>> Assefa,
>>
>> I created and ran this test last night, based on the current svn
>> source. Can you reproduce the black ugly text that follows the spiral.
>> Can anyone else reproduce the image below on their local builds? If
>> not, then I might have a .configure or build issue with my system:
>>
>> woodbri at carto:/u/data$ uname -a
>> Linux carto 2.6.15-1-em64t-p4-smp #2 SMP Tue Mar 7 08:19:39 UTC 2006
>> x86_64 GNU/Linux
>>
>> You can download a zip file with everything you need to reproduce this
>> test locally. http://imaptools.com/downloads/spiral-test.zip
>>
>> http://imaptools.com/cgi-bin/mapserv-4.99?mode=map&map=/u/data/test/spiral.map
>>
>> http://imaptools.com/cgi-bin/mapserv-4.99?mode=map&map=/u/data/test/spiral.map&map_imagetype=PNG8
>>
>>
>> MAP
>> NAME "spiral test map"
>> EXTENT -26 -26 26 26
>> SIZE 700 700
>> FONTSET "fontset.txt"
>> IMAGECOLOR 153 179 204
>> UNITS DD
>> IMAGETYPE "agg/png24"
>>
>> OUTPUTFORMAT
>> NAME "agg/png24"
>> MIMETYPE "image/png; mode=24bit"
>> DRIVER "AGG/PNG"
>> EXTENSION "png"
>> IMAGEMODE "RGB"
>> FORMATOPTION "PALETTE_FORCE=TRUE"
>> FORMATOPTION "PALETTE=/u/data/maps/palette-google-agg.txt"
>> END
>>
>> OUTPUTFORMAT
>> NAME PNG8
>> DRIVER "GD/PNG"
>> EXTENSION "png"
>> MIMETYPE "image/png"
>> IMAGEMODE RGBA
>> TRANSPARENT OFF
>> FORMATOPTION "QUANTIZE_FORCE=ON"
>> FORMATOPTION "QUANTIZE_DITHER=OFF"
>> FORMATOPTION "QUANTIZE_COLORS=256"
>> END
>>
>> LAYER
>> NAME "Annotation"
>> STATUS DEFAULT
>> TYPE ANNOTATION
>> FEATURE
>> POINTS -25 -25 END
>> TEXT "Simple Label"
>> END
>> LABELCACHE OFF
>> CLASS
>> COLOR 0 0 0
>> LABEL
>> FONT "arial"
>> TYPE TRUETYPE
>> POSITION ur
>> SIZE 14
>> BUFFER 4
>> COLOR 50 50 50
>> OUTLINECOLOR 238 238 238
>> ANTIALIAS TRUE
>> PARTIALS FALSE
>> MINDISTANCE 250
>> MINFEATURESIZE 10
>> END
>> END
>> END
>>
>> LAYER
>> NAME "Spiral"
>> STATUS DEFAULT
>> DATA "spiral"
>> TYPE LINE
>> TRANSPARENCY ALPHA
>> LABELITEM "NAME"
>> CLASS
>> STYLE
>> COLOR 170 153 136
>> WIDTH 20
>> ANTIALIAS TRUE
>> END
>> STYLE
>> COLOR 255 255 255
>> WIDTH 17
>> ANTIALIAS TRUE
>> END
>> LABEL
>> ANGLE FOLLOW
>> FONT "arial"
>> TYPE TRUETYPE
>> POSITION CC
>> SIZE 14
>> BUFFER 4
>> COLOR 0 0 0
>> ANTIALIAS TRUE
>> PARTIALS FALSE
>> END
>> END
>> END
>>
>> END
>>
>>
>> -Steve
>>
>>
>> Yewondwossen Assefa wrote:
>>> screen grab for label ALIGN FOLLOW
>>>
>>>
>>> Stephen Woodbridge wrote:
>>>> Assefa,
>>>>
>>>> Thanks.
>>>>
>>>> 1) Can you confirm that the code you explained below is what is
>>>> currently in SVN?
>>>> 2) What does your OUTPUTFORMAT look like?
>>>> 3) Is there anything special that I need to do to reproduce this?
>>>> Does not scheme for generating the palette.txt file meet the
>>>> requirements of the implemented algorithm.
>>>> 4) Did you try LABEL ALIGN FOLLOW? and did you get labels that
>>>> looked better than the comparison that I showed below?
>>>>
>>>> Best regards,
>>>> -Steve
>>>>
>>>>
>>>> Yewondwossen Assefa wrote:
>>>>> Steve,
>>>>>
>>>>> We tried different ways to allocate an appropriate color palette
>>>>> for 24-8 bit conversion and at the end the following seems to give
>>>>> a good results from the tests we did (function in mapgd.c
>>>>> msImageCreateWithPaletteGD):
>>>>>
>>>>> - use gd function gdImageCreatePaletteFromTrueColor to create an
>>>>> image with a number of colors 256 - number of colors from the
>>>>> static palette file
>>>>> - final image would use the generated colors + the ones that are
>>>>> defined in the palette color.
>>>>>
>>>>> It adds an additional step/time to do it and there could probably
>>>>> be some optimizing but It seems to work ok specially for maps
>>>>> generated for tiled environment like kaMap.
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> Stephen Woodbridge wrote:
>>>>>> Paul, Assefa,
>>>>>>
>>>>>> How would I use that?
>>>>>>
>>>>>> Also, I commented out the
>>>>>>
>>>>>> #FORMATOPTION "PALETTE_FORCE=TRUE"
>>>>>> #FORMATOPTION "PALETTE=/u/data/maps/palette-google-agg.txt"
>>>>>>
>>>>>> but the label follows test still looks the same.
>>>>>>
>>>>>> -Steve
>>>>>>
>>>>>> Paul Spencer wrote:
>>>>>>> Steve (and Steve),
>>>>>>>
>>>>>>> I believe Assefa committed a change that allows you to specify a
>>>>>>> fixed partial palette and GD interpolates the remaining colours.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> On 7-Jul-07, at 12:53 AM, Stephen Woodbridge wrote:
>>>>>>>
>>>>>>>> Steve Lime wrote:
>>>>>>>>> Thanks, that's why the output blows. The forced palette has no
>>>>>>>>> room
>>>>>>>>> for interpretation those are the only colors allocated in the
>>>>>>>>> output
>>>>>>>>> image and all colors are mapped to that palette. That is done
>>>>>>>>> after
>>>>>>>>> all rendering is complete. It works this way to support tiling to
>>>>>>>>> that colors are absolutely consistent from tile to tile. The
>>>>>>>>> option
>>>>>>>>> really isn't useful beyond offline mass tiling.
>>>>>>>>
>>>>>>>> OK, well then have we tried an alternative approach to handling
>>>>>>>> the palette. That would be to take the approach that I thought
>>>>>>>> it was doing :)
>>>>>>>>
>>>>>>>> If you define the palette using the method that I described that
>>>>>>>> would freeze the primary colors used in the mapfile. All other
>>>>>>>> palette colors would be allowed to be generated dynamically as
>>>>>>>> needed. When the color reduction process runs it would have to
>>>>>>>> honor those colors in the palette, but could also add additional
>>>>>>>> colors as needed in the additional slots. This would fix the big
>>>>>>>> color shifts that we were seeing in the tiling and any shifting
>>>>>>>> in the anti-aliasing between meta-tiles would probably not be
>>>>>>>> noticeable.
>>>>>>>>
>>>>>>>> I think the current approach it way to rigid and absolute, but
>>>>>>>> it might be useful for some situations.
>>>>>>>>
>>>>>>>> If the above is relatively easy to implement, I would be happy
>>>>>>>> to run some tests on it.
>>>>>>>>
>>>>>>>> -Steve W
>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 07/05/07 11:28 PM
>>>>>>>>>>>> >>>
>>>>>>>>> Steve Lime wrote:
>>>>>>>>>> For comparison purposes I would use 24-bit png regardless.
>>>>>>>>>> My question would be how is the palette being constructed?
>>>>>>>>>> Ideally
>>>>>>>>> I take a very simple approach to the palette.txt file and that is:
>>>>>>>>> grep -i color mapfile.map > a.txt #edit a.txt a bunch sort -u
>>>>>>>>> a.txt >
>>>>>>>>> palette.txt
>>>>>>>>> wc -l palette.txt 36
>>>>>>>>> so the rest of the colors can be allocated for anti-alias colors.
>>>>>>>>> -Steve W
>>>>>>>>>> you would create a representative image with lot's of linework
>>>>>>>>>> and annotation and then use Gimp, Imagemagick or Photoshop to
>>>>>>>>>> reduce colors to a 8-bit palette and use that. Otherwise the
>>>>>>>>>> palette force
>>>>>>>>>> option will do a distance computation and the results could get
>>>>>>>>>> ugly (and these images are proof)...
>>>>>>>>>> Steve
>>>>>>>>>>>>> Paul Spencer <pspencer at DMSOLUTIONS.CA> 07/05/07 9:32 PM >>>
>>>>>>>>>> PHP? Steve, I'm shocked its not a perl page ;)
>>>>>>>>>> I have noticed that the text gets 'bolder' when reducing the
>>>>>>>>>> palette, but not like this.
>>>>>>>>>> Have you tried without the formatoption for reducing the image?
>>>>>>>>>> One thing that may happen is that the antialiasing colours are
>>>>>>>>>> getting mapped to black because there isn't room in the
>>>>>>>>>> palette to
>>>>>>>>>> allocate the needed colours. That does seem unlikely, though.
>>>>>>>>>> Cheers
>>>>>>>>>> Paul
>>>>>>>>>> On 5-Jul-07, at 4:56 PM, Stephen Woodbridge wrote:
>>>>>>>>>>> Steve,
>>>>>>>>>>> http://imaptools.com/maps/compare-maps2.php?loc=2&ll=41.85
>>>>>>>>>>> +-87.65&address=&city=&state=&zipcode=&country=&asrv=1&amf=%2Fu%
>>>>>>>>>>> 2Fdata%2Fmaps%2Fgoogle-aa2.map&msa=mapserv-4.10&bsrv=1&bmf=%2Fu%
>>>>>>>>>>>
>>>>>>>>>>> 2Fdata%2Fmaps%2Fgoogle-agg.map&msb=mapserv-4.99&submit=Show
>>>>>>>>>>> Here is a side by side comparison.
>>>>>>>>>>> google-aa2 is using "PNG8" google-agg is using "agg/png24"
>>>>>>>>>>> OUTPUTFORMAT NAME "agg/png24" MIMETYPE "image/png;
>>>>>>>>>>> mode=24bit" DRIVER "AGG/PNG" EXTENSION "png" IMAGEMODE "RGB"
>>>>>>>>>>> FORMATOPTION "PALETTE_FORCE=TRUE" FORMATOPTION
>>>>>>>>>>> "PALETTE=/u/data/maps/palette-google-agg.txt" END
>>>>>>>>>>> ONE of the differences is mapserver-4.10 vs mapserv-4.99 and the
>>>>>>>>>>> fact that 4.99 has broken support for:
>>>>>>>>>>> OUTPUTFORMAT NAME PNG8 DRIVER "GD/PNG" EXTENSION "png"
>>>>>>>>>>> MIMETYPE "image/png" IMAGEMODE RGBA TRANSPARENT OFF
>>>>>>>>>>> FORMATOPTION "QUANTIZE_FORCE=ON" FORMATOPTION
>>>>>>>>>>> "QUANTIZE_DITHER=OFF"
>>>>>>>>>>> FORMATOPTION "QUANTIZE_COLORS=256" END
>>>>>>>>>>> as none of the roads render.
>>>>>>>>>>> -Steve
>>>>>>>>>>> Steve Lime wrote:
>>>>>>>>>>>> Would be nice to have a non-tiled, side-by-side browser to do
>>>>>>>>>>>> the comparison with... ;-) It doesn't look to me like identical
>>>>>>>>>>>> mapfiles. For example, I'm looking at Chicago and there look
>>>>>>>>>>>> to be some differences in scale settings. For example, the
>>>>>>>>>>>> shape of Lake Michigan changes dramatically, see:
>>>>>>>>>>>> http://maps.dnr.state.mn.us/~stlime/chicago_gd.gif
>>>>>>>>>>>> http://maps.dnr.state.mn.us/~stlime/chicago_agg.gif I'll wait
>>>>>>>>>>>> on other comments until that can be confirmed. Steve
>>>>>>>>>>>>>>> On 7/4/2007 at 10:47 AM, in message <468BC11E.
>>>>>>>>>>>>>>> 2050101 at swoodbridge.com>, Stephen
>>>>>>>>>>>> Woodbridge <woodbri at SWOODBRIDGE.COM> wrote:
>>>>>>>>>>>>> Hi Zak,
>>>>>>>>>>>>> Thank you and the others for all the responses. I got it
>>>>>>>>>>>>> working this morning:
>>>>>>>>>>>>> http://imaptools.com/agg-test.html I have a few questions and
>>>>>>>>>>>>> observations:
>>>>>>>>>>>>> The OL app above has two base layers. Both use the same
>>>>>>>>>>>>> mapfile, except one supports AGG and is using 5.0 and the
>>>>>>>>>>>>> other is using 4.10.
>>>>>>>>>>>>> 1) Notice the white lines in the water boarding some of the
>>>>>>>>>>>>> polygons. What is causing that? How do you get rid of these?
>>>>>>>>>>>>> 2) If you switch between 4.10 and 5.0 AGG base layers
>>>>>>>>>>>>> notice that the road widths change. What is causing this? I
>>>>>>>>>>>>> assume this is the same issue as the polygons above.
>>>>>>>>>>>>> 3) If you zoom in to 15K scale of closer so street names are
>>>>>>>>>>>>> displayed the text looks really bad on text ALIGN FOLLOW
>>>>>>>>>>>>> labels. And the text is much bolder and blacker than the 4.10
>>>>>>>>>>>>> example.
>>>>>>>>>>>>> more below ...
>>>>>>>>>>>>> Zak James wrote:
>>>>>>>>>>>>>> Steve,
>>>>>>>>>>>>>> In our testing, the AGG renderer is about 10% faster than
>>>>>>>>>>>>>> GD over a variety of conditions. One caveat is that the
>>>>>>>>>>>>>> sub-pixel positioning of vertices (which greatly improves
>>>>>>>>>>>>>> the appearance of features) can cause far longer rendering
>>>>>>>>>>>>>> times if suitable overview data aren't available for a
>>>>>>>>>>>>>> given scale. We discussed but did not implement strategies
>>>>>>>>>>>>>> for mitigating this problem.
>>>>>>>>>>>>> I think that discussion should get added to the RFC. If I
>>>>>>>>>>>>> wanted to provide my own overview data what are we talking
>>>>>>>>>>>>> about. Just having generalized data? Any rule of thumb on
>>>>>>>>>>>>> when you need to provide this?
>>>>>>>>>>>>>> Another issue is that the antialiasing tends to cause
>>>>>>>>>>>>>> larger image file sizes.
>>>>>>>>>>>>> There really is not much that you can do about this. It will
>>>>>>>>>>>>> impact on bandwidth and tile repository sizes.
>>>>>>>>>>>>> -Steve
>>>>>>>>>>>>>> zak
>>>>>>>>>>>>>> On 7/3/07, Stephen Woodbridge <woodbri at swoodbridge.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Paul, Steve,
>>>>>>>>>>>>>>> A few questions:
>>>>>>>>>>>>>>> 1) could one of you do a short post on what if anything
>>>>>>>>>>>>>>> needs to be done to use AGG other than install the libs
>>>>>>>>>>>>>>> and select some ./ configure options.
>>>>>>>>>>>>>>> 2) Any sense on how this compares speed wise to the GD
>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>> 3) is what is in the trunk all that 5.0 will see or is
>>>>>>>>>>>>>>> there some additional work that is planed to be implemented.
>>>>>>>>>>>>>>> I would like to give it a try.
>>>>>>>>>>>>>>> -Steve W
>>>>>>>>>>>>>>> Paul Spencer wrote:
>>>>>>>>>>>>>>>> The other thing that I am very keen to have is text
>>>>>>>>>>>>>>>> rendered/ placed using AGG. Not sure if it will be
>>>>>>>>>>>>>>>> done for 5.0 though.
>>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>> On 3-Jul-07, at 1:25 PM, Steve Lime wrote:
>>>>>>>>>>>>>>>>> Hi Tom: AGG support is in the codebase for 5.0. I
>>>>>>>>>>>>>>>>> still owe an RFC to explain what was done although
>>>>>>>>>>>>>>>>> the addition of AGG doesn't affect any other portions
>>>>>>>>>>>>>>>>> of MapServer. It's a big user feature though. I
>>>>>>>>>>>>>>>>> recently got a big time sink off my plate and will
>>>>>>>>>>>>>>>>> work that up ASAP.
>>>>>>>>>>>>>>>>> The support is relatively complete. The guys from DM
>>>>>>>>>>>>>>>>> Solutions can probably comment further as they've
>>>>>>>>>>>>>>>>> been using it the most. The AGG vs. GD images DM has
>>>>>>>>>>>>>>>>> supplied are very nice. The quality difference is
>>>>>>>>>>>>>>>>> noticeable with roads in
>>>>>>>>>>>>>>> particular.
>>>>>>>>>>>>>>>>> The only missing capability that I am aware of has to
>>>>>>>>>>>>>>>>> do with PIXMAP symbols that contain an alpha
>>>>>>>>>>>>>>>>> channel. There is a fundamental difference in how AGG
>>>>>>>>>>>>>>>>> and GD handle alpha blending (GD is flat out
>>>>>>>>>>>>>>>>> backwards). We use GD to manage the pixel buffer
>>>>>>>>>>>>>>>>> that AGG is rendering into so that becomes a problem.
>>>>>>>>>>>>>>>>> I'll go into options in the RFC.
>>>>>>>>>>>>>>>>> Anyway, other than that the support seems to be
>>>>>>>>>>>>>>>>> working nicely is worth trying.
>>>>>>>>>>>>>>>>> Steve
>>>>>>>>>>>>>>>>>>>> On 7/1/2007 at 10:08 PM, in message
>>>>>>>>>>>>>>>>> <7b5b710d0707012008i59c41e8bq8e0ef4d8022f40f8 at mail.gmail.com>,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> T om
>>>>>>>>>>>>>>> Beard
>>>>>>>>>>>>>>>>> <tom at PROJECTX.CO.NZ> wrote:
>>>>>>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>>>>>> This is my first time posting here, and I hope this
>>>>>>>>>>>>>>>>>> is the right forum to ask this question.
>>>>>>>>>>>>>>>>>> I was wondering what the status of AGG support was for
>>>>>>>>>>>>>>>>>> the 5.0 release. On searching the archives, the
>>>>>>>>>>>>>>>>>> most recent reference I could find was
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> minutes from the May 22 IRC meeting that said that
>>>>>>>>>>>>>>>>>> there would be
>>>>>>>>>>>>>>> an RFC
>>>>>>>>>>>>>>>>>> freeze on June 15, and that an RFC for AGG was
>>>>>>>>>>>>>>>>>> "forthcoming". Did AGG support make it into that
>>>>>>>>>>>>>>>>>> freeze? Is it listed somewhere online?
>>>>>>>>>>>>>>>>>> I'd also be interested to know if there is a
>>>>>>>>>>>>>>>>>> version currently in Subversion that includes AGG
>>>>>>>>>>>>>>>>>> sub-pixel rendering and that works well enough to
>>>>>>>>>>>>>>>>>> have a go at compiling on Windows.
>>>>>>>>>>>>>>>>>> Regards, Tom Beard
>>>>>>>>>>>>>>>> +----------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -+ |Paul Spencer pspencer at dmsolutions.ca |
>>>>>>>>>>>>>>>> +----------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -+ |Chief Technology Officer | |DM Solutions Group Inc
>>>>>>>>>>>>>>>> http:// www.dmsolutions.ca/ |
>>>>>>>>>>>>>>>> +----------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -+
>>>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>>>>
>>>>>>>>>> |Paul Spencer pspencer at dmsolutions.ca
>>>>>>>>>> |
>>>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>>>>
>>>>>>>>>> |Chief Technology Officer
>>>>>>>>>> | |DM Solutions Group Inc
>>>>>>>>>> http://www.dmsolutions.ca/
>>>>>>>>>> |
>>>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>>>>
>>>>>>>
>>>>>>> +-----------------------------------------------------------------+
>>>>>>> |Paul Spencer pspencer at dmsolutions.ca |
>>>>>>> +-----------------------------------------------------------------+
>>>>>>> |Chief Technology Officer |
>>>>>>> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
>>>>>>> +-----------------------------------------------------------------+
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>
>
>
More information about the mapserver-dev
mailing list