Status of AGG support?
Paul Spencer
pspencer at DMSOLUTIONS.CA
Sat Jul 7 10:06:18 EDT 2007
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