mapnik png256 support for opacity

[artemp]

In my application I am rendering several imagery layers which are divided into separate geotiffs. While using tilecache to seed the cache which is rendered by the openlayers javascript lib, the bounding box of each layer exceeds the raster data boundary at zoomed out levels and fills it black. With normal png the nodata is transparent so there is no conflict with other layers. If the same behavior could be replicated for png256 that would be great!

Simple example would just be to render a raster with a bounding box outside the raster data set using png256.

[artemp]

[artem] This would be a great feature to have. I'm moving this ticket to 0.7.0

[artemp]

[mar_rud] Attatched patch adding support to binary transparency using 128 as threshold for transparent/nontransparent classification. It also fixes bug in palette generation (++ mixed somehow with -- ).

In this way, edges can be sharper then with truecolor png. Adding support for more transparency levels then this would need some more changes (computing best subpalettes for each opacity level).

[artemp]

[springmeyer] Marcin! great stuff, tests look great, sharpness is nice, and the files are even smaller.

Thanks!

applied in r1111

[artemp]

[rullzer] In the two attachments (smooth.png and jagged.png (sorry typo there)) you can see that rendering with png256 results in ragged lines. The smooth.png displays the result with png. So reopening as requested.

[artemp]

[mar_rud] Yep, I mentioned this. I added only binary transparency. For simple case, described in ticket, where there are rectangular rasters its enough. For fully antialiased images using 256 palette it is insufficient.

Adding more transparency level is possible. There are 256 colours in palette, any number of that can have assigned transparency level. However, more transparent colours means less normal colours to represent image. Also some older ie version can't handle more then binary transparency.

I generated such images in development process using slightly modified png_io.h, that I patched, but most graphic tools can only open it. Converting image to smoothly transparent 256 colour png in gimp isn't possible, only error diffusion approximation. I'm not sure about imagemagick (maybe after reading all available documentation ;) ). I know only Fireworks that can actually create such files. So I assumed, that for start this was already big improvement for mapnik.

Computing palette could be implemented using hextree (4d rgba colour space) instead of octree(3d rgb colour space), but this would increase memory storage for structures and processing time.
In simplified solution, we could choose i.e. few alfa levels to represent smoothness and search so many palettes using octree. How many colours for each level (and which and how many levels) can be computed using histogram of alfa values. I guess 1-3 different alfa levels besides full transparency and full opacity could be enough.

I don't promise, I'll write in this matter more then this comment in near future, but who knows ;)

[artemp]

[springmeyer] As applied this is currently going to be part of the 0.6.1 release in 8 days.

Anyone have further thoughts on this implementation? Is is sufficient as is, or should we revert and push discussion to 0.6.2/0.7.0?

[artemp]

[mar_rud] It is improvement over previous behaviour (no transparency, only black background), so I would suggest, to leave it for 0.6.1. As for mentioned sharpness issue (support for semitransparency), I would suggest opening new ticket or leaving this open for future releases.

I have patch, but it isn't good enough for commit. I have some doubts about switching between different behaviours. i.e. if someone want only binary transparency (ie6 png problems?) or other cases. I have some idea, to pass options like transparency support or number of colors in format string, i.e. "png256:colors=16:transparency=full" or "jpg:quality=95", but It would probably need separate ticket.

On the other hand, if someone needs some special format or options, he can use external libraries (i.e. imagemagick++).

[artemp]

[artem] moving further discussion to 0.6.2

[artemp]

[springmeyer] mar_rud,

I fully agree that this is an improvement over previous behavior, so I'm closing this ticket.

If you have a patch for semi-tranparency, please post it to a new ticket. Until then we have at least two tickets that note some behaviors due to lacking semi-transparency, so that users who encounter them will get referenced back to this ticket explaining the implementation issues.

These tickets are #445 and #447

Also, perhaps of interest, though not specifically an issue with png256, is this additional problem with alpha transparency: #444 (noticed with raster datasources and when alpha transparency is used with photographs as the images for PointSymbolizer)

[artemp]

[mar_rud] For mentioned problems with semitransparency I've posted new ticket: #477 with some proposed implementation.