Status of AGG support?
Stephen Woodbridge
woodbri at SWOODBRIDGE.COM
Sat Jul 7 22:13:33 EDT 2007
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