[Mapnik-devel] png256: transparency support + passing user options

[Marcin Rudowski]

Hi,

In http://trac.mapnik.org/ticket/477 few months ago I presented fixes
adding basic semi alpha support, that are already included in 0.7.0.

Today I attached patch adding full support using hextree instead of
octree (same idea as with RGB, but extended to 4 dimensions: RGBA). Also
I used some new approaches with tree reduction and color quantization,
to limit negative effects: time and file size increase.

As proposed in mentioned ticket, I also added support for user control
over some parameters of quantization algorithm using image type string.
Parsed options are separated with ':' and based on existing discussion I
added support for those in png256:

- c=256 - limit number of colors (default 256), works with octree and
hextree

- t=2 - select transparency mode: 0-no alfa, 1-binary alfa(0 or 255),
2-full alfa range, default is 2, works with octree and hextree

- m=o - choose quantization method, available options: o-existing
octree, h-new hextree with optimizations, default is octree

- g=2.0 - kind of gamma correction for pixel arithmetic in hextree
method, default value 2.0 worked best with most of my test images, value
1.0 means no gamma correction.

So tu use new format i.e. in python:
  view.save("test.png",'png256:m=h')
or other example in c++:
  save_to_file(vw, "test.png", "png256:t=1:c=128");


What I'm asking now is what do You thing about such parameters and what
about names: full or one letter like above? I have also some doubts
about name of m parameter(method?) but q as for quantization could be
mistaken for quality.


As for hextree, new method should give more smooth images in case of
transparent maps i.e. hybrid like overlayed on some satellite images.
Also used optimization should help with maps using hillshading or any
form of rasters with gradients. Actually was my biggest motivation for
changes: to improve tiles like that:
  http://marcom.homeip.net/ump-www/mapnik/png256/5605_o.png
and now it looks:
  http://marcom.homeip.net/ump-www/mapnik/png256/5605_h.png
Difference in transparency support is less noticeable in common maps
(look at edge of red line):
  http://marcom.homeip.net/ump-www/mapnik/png256/smooth_o.png
after changes:
  http://marcom.homeip.net/ump-www/mapnik/png256/smooth_h.png

Time and file size increase or decrease depends on content and image
size, but shouldn't be much in common situation. However I decided to
make old behaviour default, because for most maps without transparent
background or elevation colored/shaded rasters, existing method should
give acceptable and little bit smaller files.

Using less than 64-94 colors is not recommended, because returned
palette isn't optimal then. Using 96-128 should give acceptable quality
with some file size reduction, but probably not more then 10%-20%.


If mentioned changes are acceptable, especially proposed parameters, I
will apply it to 0.7.1 and soon port to trunk code. Also some testing
and feedback would be nice. I did my test with different cases, but they
were rather corner cases.

Best regards,
Marcin Rudowski