Hextree PNG quant too aggressive

[springmeyer]

Take this 24bit png:

And run it through Mapnik using hextree quant:

python -c "import mapnik as m;m.Image.open('input.png').save('out.png','png8:m=h')"

and the small blue line in the upper right drops out:

Leading to an artifact between tiles like:

Another testcase is from #1987

[Andrey-VI]

This bug previously reported here.

[artemp]

@springmeyer

mapnik/include/mapnik/hextree.hpp

Line 488 in 5dee576

(((cur_node->reduce_cost / cur_node->pixel_count + 1) * std::log(double(cur_node->pixel_count))) > 15)

- this is the test that cuts off colours. Try changing 15 to 10 and blue line will re-appear but with doubling file size from 103b to 282b.

[springmeyer]

okay, let's hold on this for further thought.

[springmeyer]

refs #1990 (comment)

[springmeyer]

noting this is not fixed by #2671 since it is a slightly different problem as @artemp mentions (#2292 (comment))

[springmeyer]

@rcoup - pinging you here as I'm curious whether you are also aiming to fix this or not? I'm recalling now that we held off on this change specifically due to filesize bloat so I'm not sure if it is viable. But I'd welcome attention if you think it is viable.

[rcoup]

I'd like to fix it - issues like this tend to trip up our safety asserts like "you shouldn't have rendered a blank image here but you somehow did".

Feels like if you have fewer unique colours before hextree-encoding maybe we should throttle back the quantizing aggressiveness? Since PNG compression should work well if there's mostly solid colours in a tile.

Though from a quick read of the code I'm not 100% on why my test image from #2599 (with 2 colours and 1px per colour) doesn't disappear yet the test image from here does - implies maybe the tree creation or cost reduction functions have some edge cases?

/cc @sarametz

[springmeyer]

Feels like if you have fewer unique colours before hextree-encoding maybe we should throttle back the quantizing aggressiveness? Since PNG compression should work well if there's mostly solid colours in a tile.

Definitely agree - I think putting effort into better detecting how to optimally encode/quantize (whether hextree or octree, etc) would be useful.