Support full color png as rgb (no alpha)

[springmeyer]

In cases where the overhead of color reduction (png8) is not desirable, but full color rgba png's are too large, we can save some space by writing no-alpha rgb images.

We already support a flag for png8 encoding that allows the user to force the transparency level: 0 for no transparency, 1 for binary transparency, and 2 for partial transparency.

Therefore we can allow png:t=0 to be able to write true color rgb images.

[springmeyer]

miniz setup for this in cd3cc31

[cquest]

Images are really different: on my quick test, png:t=0 reduces image size by 7%, but the time to generate t
he same 1024x1024 pixel image increases by... 33% :(

[springmeyer]

@cquest - can you also try png8:t=0?

[cquest]

@springmeyer with "png8:t=0" I get the same timing as "png"

[springmeyer]

@cquest so you are comparing to png8 then?

[cquest]

Here are the best timing I got:

png8 > 29, 30 and 29s
png8:t=0 > 33, 34 and 35s

I rechecked with "png" and "png:t=0", I now get the same timings... (around 30s, 3 tests each).

[springmeyer]

png8:t=0 should be faster than png8, but clearly it is not and I'm not sure why. If you want to work around this issue and these speeds are not acceptable, then I recommend trying a few things:

1. Record timings for rendering without actually encoding (e.g. in python just call im.tostring() without the png argument) so you can get a sense of how long rendering is taking vs image encoding.

2. Consider using mapnik image views to encode the image in parts and then stitching back together. This might be slower, but could also be faster since the memory needed to handle smaller chunks of images in the png encoder might be less.