Status of AGG support?
Yewondwossen Assefa
assefa at DMSOLUTIONS.CA
Mon Jul 16 16:16:48 EDT 2007
Stephen Woodbridge wrote:
> 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?
>
Sorry for the delay. I was able to reproduce it. I guess the only
difference that I see that with the map file that we used here was that
the style was using an outline color and that might have 'hidden' the
issues that you are seeing.
> -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/ |
>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>
>>
>>
>
>
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa at dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
More information about the mapserver-dev
mailing list