Status of AGG support?
Yewondwossen Assefa
assefa at DMSOLUTIONS.CA
Mon Jul 9 12:13:56 EDT 2007
Stephen Woodbridge wrote:
> Assefa,
>
> Thanks.
>
> 1) Can you confirm that the code you explained below is what is
> currently in SVN?
Yes
> 2) What does your OUTPUTFORMAT look like?
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=c:/msapps/fbs-navteq/map/palette.txt"
END
> 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.
Defining the palette in the formatoption should be enough.
> 4) Did you try LABEL ALIGN FOLLOW? and did you get labels that looked
> better than the comparison that I showed below?
>
From the tests we did the labels using LABEL ALIGN FOLLOW seem to be
comparable to the gd output. I will send you directly a screen grab
that was done a couple of weeks ago on a test map.
Later,
> 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