Status of AGG support?
Paul Spencer
pspencer at DMSOLUTIONS.CA
Sun Jul 8 12:30:28 EDT 2007
I don't think you have to do anything, I think it just works that way
if you put in less than 256 colours. But if commenting those out
produces the same result, then something else is going wrong I think.
Paul
On 7-Jul-07, at 10:13 PM, 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.co
>>>>>>>>>>>> m>,
>>>>>>>>>>>> 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/ |
>> +-----------------------------------------------------------------+
+-----------------------------------------------------------------+
|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