Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
overflow/image corruption in octree with png256 + large pixel output #522
see the large image here:
fixed with advice from artem:
Although with this patch white background + png256 output (image/png8 mime) turns same color as processed_p.shp
[mar_rud] Yes, in this case there were so many pixels of similar color, that unsigned type overflowed. In worse case it could happened with more than 16M pixels of near white color, that have assigned single palette index. For square image it is 4000x4000 image with mostly near white background.
As for color deformation with 64bit type, png256 is rather fast and mostly enough, then perfect in all cases. In this case changing
I'm going to look into octree.h to find some ways of improvement, maybe considering color variance when searching for node to reduce, but with better palette, image size will increase, not mentioning cpu time.
I just did simple test with converting 1312x1136 image to png256. "convert" from imagemagick got 208kB file in 2.2s, and simple program using mapniks functions got 152kB file in 0.4s. Smaller file is because less optimized palette, but in this case there weren't any visible differences.
On some faster machine and mentioned 12000x10000, 28MB png file imagemagick got: 14MB (45s, 1.3GB RAM), mapniks octree: 6.4MB (13s, 590MB RAM), but visible color difference and 9MB with MIN_LEVELS=2.
[mar_rud] Attached patch includes mentioned fix from artem and some improvements in octree.h to first reduce nodes that introduce smallest color error, instead of ones with least pixels.
I checked it with my test images I often use for png256 and it generally produces slightly better image (closer colors to original) with only <5% file size increase. Also for mentioned extreme 120MPix image it produces correct colors (image size: 9.2MB instead of 6.4MB), so I've committed to 0.7.1-dev and trunk (r1661, r1662).