MapServer 5.0 Agg Support: Disappointing
The MapServer 5.0 beta is out. For a while, people had been mentioning the AGG support, and I even saw a pretty great demo put together by DM Solutions that demonstrated the functionality, and I had been impressed.
I was disappointed to learn recently that the fonts are still going to continue to be rendered by GD for the 5.0 release: really, the biggest case where I care about smooth lines is in fonts, because it makes the difference between the ability to use an 8px font, and the corresponding increase in number of labels, and being forced to use a 10px/11px font. (Small fonts become less and less readable at smaller sizes without sub-pixel rendering.) However, I was hoping that the rest of the support would be sufficient that I would be happy with switching the Boston Freemap over to using AGG instead of GD as the renderer.
This morning, I grabbed MapServer, and figured out how to build it after some stumbling. MapServer’s default of “Don’t include anything” is probably a great idea for most people, but for me, it definitely was at stumbling block. Just an example: I was trying to set up –with-agg. I knew I had installed it, and files were in /usr/include/agg2 and /usr/lib/libagg.a. But there’s only one directory! So I tried just pointing to /usr/lib, and got:
error: “could not find agg_rendering_buffer.h or libagg.a in /usr/lib.”
Well, obviously agg_rendering_buffer.h wasn’t there, but libagg.a was! I got there eventually by reading the configure script. It actually wants you to point to /usr, which would have been clearer if it asked for ‘AGG *prefix*’ instead of just ‘AGG directory’. I’m sure this stuff is obvious to people who roll their own, but I love my debian, damnit! 😉
I then ran into an error in building mapagg.cpp, #2188, which I was able to fix by commenting out the offending lines, and an error in building php_mapscript, which I solved by removing that from the build.
I eventually got it built, and bumped into what I eventually filed as a bug: #2187: WMS Request for DRIVER AGG/PNG claims ‘invalid output format’. FrankW was kind enough to help me fix mapwms.c so I could continue to play.
I now have an agg demo of the Boston Freemap. However, I find it very disappointing. The lines actually look *more* jagged in some cases, and for fonts without an outlinecolor, the text is almost unreadable. Additionally, it seems that the blue of my water has changed to be a weird grey color. You can compare against 5.0’s GD rendering and 4.10’s GD rendering — the two differ only by what likely amounts to rounding errors.
The agg rendering is simply not up to snuff. I’ll admit I’ve put more than my fair share of work into getting the Boston Freemap to look good with previous versions of MapServer, but this definitely seems like a step backwards.
I’d love to be told that I’m missing some obvious “Make Output Pretty” option, but if there is one, the AGG RFC doesn’t mention it.
I’d hoped to have a brilliant demo of the power of MapServer. Instead, I’ve got disappointment and pain. It’s a shame that it has to end this way… 😉
The mapfile for the Boston Freemap is, of course, available, if someone feels like trying to understand better why the problems exist. The data is also available, though it’s likely easier to just get it direct from MassGIS.
July 29th, 2007 at 9:43 pm
Well, it is pre-release software 🙂
If you look closely at your output you’ll see that the ‘jaggies’ are only present in areas where agg features overlay the gd-rendered background map colour. The lines drawn over the grey water are very nicely antialiased. There are workarounds for this, but a very recent patch by Thomas Bonfort may have fixed this – I haven’t tested it yet. See http://trac.osgeo.org/mapserver/ticket/2173
“Make Output Pretty” hasn’t been implemented yet, but you can fix your colour problems by either using 24 bit output or by adding
FORMATOPTION “PALETTE_FORCE=TRUE”
FORMATOPTION “PALETTE=”
to the AGG OUTPUTFORMAT block. The palette file is a text file with one line for each colour you want to reserve in the output image’s 8-bit index. (e.g. 0,0,255 would reserve blue). The problem you’re seeing is that there are too many colours in your output due to the pretty antialiasing so the water colour from the mapfile won’t fit in the palette.
I agree that the lack of improvement to text rendering is a disappointment, but I think it’s safe to say this will be remedied in the future.
Zak
July 29th, 2007 at 9:45 pm
Hmm, the comment system ate my angle brackets but FORMATOPTION “PALETTE=” needs to reference the text file of reserved colours.
July 29th, 2007 at 11:20 pm
I don’t call something ‘pre-release’ until I’d be happy with it shipping, assuming no one reported any bugs. It’s possible that MapServer is more lenient with names, in which case I’m being overly harsh.
Updated to SVN trunk, and added that as a layer to the agg-demo.html file. As you can see, it’s actually less impressive, though it does fix the label rendering, which is good.
I’m already using “IMAGEMODE RGB” — does that not make 24 bit pngs? `identify` says ‘PNG 1024×1024 DirectClass 817kb 0.230u 0:01’, which I think means ‘not 8 bit’. Am I wrong?
July 30th, 2007 at 9:02 am
You should make a comment about the degraded output in the bug so the developer can take a look at your maps.
I’m not sure about the colour problem since you’re definitely rendering in 24 bit. I suspect that the gd antialiasing and transparency is interfering with agg. Can you try commenting
transparency alpha
and
antialias true
out of your water layer?
The term ‘Pre-release’ was my poor attempt at humour. I’m not sure of the official status of the release.
July 30th, 2007 at 2:55 pm
Appreciate the tests and the great test case. Would be nice to get feedback through the normal project channels (mapserver-dev or trac) rather than having to track down blog entries…
Steve
July 30th, 2007 at 3:28 pm
BTW Need access to the symbolset and fontset files to recreate things exactly.
Steve
July 30th, 2007 at 5:35 pm
Try removing all your TRANSPARENCY ALPHA lines. They seem to be causing at least part of the problem. They aren’t needed with AGG and should be ignored, but all the recent testing has been without them so this problem was missed. In my tests with your data the improvement is markedly better.
Polygon fills are still showing as grey but I bet that’s a cut and paste error.
Check out http://maps.dnr.state.mn.us/mapserver_demos/boston/boston.html for examples. I’ll add a toggle AGG/GD switch when I get the chance.
This is why you have betas, pre-release or whatever you want to call them.
Steve