Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Very good, but looking at the examples, the smooth gradients look awful.

They would benefit from some noise to hide the transitions, but then the compression would suffer.

Maybe some more palette entries for large smooth areas.



PNG is practically made for gradients. I can't find the file, but there's an image of every single color that PNG can support in the full opacity range, and the whole file was like 32k after pngcrush.

If I understand correctly, this tool is basically intelligently selecting a palette (which was a historically supported feature of the PNG format) and then using that on the image. Has anyone tested to see if pngcrush can shrink the filesize even further?

To the creator: have you considered supporting more than an 8-bit palette? Like, a 2-bit palette or other that happens to be better for this particular image?


> To the creator: have you considered supporting more than an 8-bit palette? Like, a 2-bit palette or other that happens to be better for this particular image?

the plan was to stick with a native, supported and easy to understand format. it was never about absolute filesize. filesize crunching should be handled afterwards via RLE, deflate or other output-format specific encoding trickery, etc.


if you jack the minHueCols param up to 4096 or 8192, it does much better in many cases of gradients but also much slower. it's certainly not a complete hands-off quantizer. the best results i've found for 0-config quantizarion is Wu's Color Quantizer v2 [1] implementation [2]

[1] http://www.ece.mcmaster.ca/~xwu/cq.c

[2] http://nquant.codeplex.com/


There is a version of pngquant that uses Wu's algorithm:

https://github.com/pornel/pngquant/tree/wucut

However, Wu's algorithm requires preprocessing R * G * B * A * int array, which is 16GB of RAM if done at full RGBA quality, so in practice all implementations have to drop alpha and/or heavily posterize colors.

pngquant the same goal — subdivides RGBA (hyper)cube to minimize variance in each section — but does it with much less memory and can do it at full quality.

Posterization of input is my pet peeve, as it gives images slightly banded and grainy look that we associate with "256-color" images (since VGA only ever supported 6-bit per gun), and presume 256 colors are never enough for photorealistic look — but it often is, and people who use e.g. TinyPNG service think it's magic.


yeah, i discovered how much space it needed when porting it via emscripten to asm.js


It'd be awesome to port pngquant to JS, especially that JS is getting parallelization and SIMD now.

Unfortunately I never got emscripten to work on my machine. Could you give it a try and compile http://pngquant.org/lib?


sure i can give it a go. though i'm currently stuck in an airport going on 14h. i'll ping you when i get around to it but could be a few days


IMO the best quantisation tools are bright183 (proprietary, by Epic for Unreal shared palettes) and neuquant. Wu unfortunately suffers from banding artifacts very badly for a low amount of colours with dithering off, the banding after applying bright looks much more acceptable.

More code to research: http://web.archive.org/web/20041010190217/http://www.geociti...


neuquant is quite good for photos but does strange stuff with graphics and low color counts. in fact, the pool table example that's used to show how good it performs, RgbQuant does better on the details and with fewer artifacts at the expense of bsckground smoothness/banding. compare for yourself http://members.ozemail.com.au/~dekker/NEUQUANT.HTML

i'll check out bright183




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: