SGI: Development

png squeezing

Maybe this should go in /software but oh well ... Not worth a tardist but sometimes we use png's ... I notice some other people here do also. The only drawback they have is they get huge. For web pages and emails and stuff, not so good. So there is this :

http://sourceforge.net/projects/pngnqs9/

It seems to work well, I have a hard time distinguishing between a 2 megabyte full png and the same photo squshed to 800k

Irix 6.5 version attached, not worth a tardist. Both will respond to their names --help. It's not fast but the results are good.

Attachment:
png-crusher.zip [72.12 KiB]
Downloaded 8 times
Code:
Like pngnq, pngnq-s9 takes a full 32 bit RGBA png image, selects a palette of up to 256 colours, and then redraws the image in 8 bit indexed mode. The resulting image can be up to 70% smaller than the original.


Eek. Sounds like a great idea for vector graphics etc, but not ideal for actual pictures :D

_________________
while (!asleep()) sheep++;
Alver wrote:
Eek. Sounds like a great idea for vector graphics etc, but not ideal for actual pictures :D

You would think so, but I did a size-reduction on a few photos and looked at them with a magnifying glass side-by side and it seems pretty good.

Normally we try to work with png's so we don't get the quality reduction every time we save. And we save a lot :)

Tiffs are cumbersome, png's seem okay. But when you go to email or put on the web, a bunch of 2 meg files is rude. And slow. This seems to do a good job.

Give 'er a try and see what you think. If you want to do it in h-pucks, it compiles easy.

edit :

Did some more testing and comparisons. The png-squishing does come out better than you would think. However, a jpeg from a png looks to be smaller and slightly more accurate. So this is an okay tool and I'm sure has some uses but for now, we'll stick to jpegging at the end of a process.
There are already 2 similar tools in /beta, pngq and pngnq (both in one tardist, with drag-and-drop support for both), and while the examples on the pngnq webpage are rather convincing, I've found the results of pngq to look superior to me in every single case I've tried so far.
canavan wrote:
There are already 2 similar tools in /beta,

That's what made me go looking for info :D

Quote:
...while the examples on the pngnq webpage are rather convincing, I've found the results of pngq to look superior to me in every single case I've tried so far.

The pngnqs9 page claims it's better too. I was surprised that the results were as good as they are - as Alver pointed out, the description of the process is not encouraging !

But in the end, comparing a full png, a crushed png, and a jpg, the jpeg was smaller and more accurate, I think.

So I'm not sure what the value is ?

Anyway, anyone who wants to take a look, the binary above works and it's simple to use. Maybe the tardists give a better result but for a quick look, feel free ...
I looove PNG. :)

_________________
覇気元
Eroteme.org
thank you hamei

_________________
:Onyx2:
You might also be interested in pngcrush (already in Nekoware). It doesn't do anything fancy like pngnqs9, but you can use it to make smaller PNGs in a mostly lossless way:
Code:
pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text -brute in.png out.png

This will remove various unnecessary parts (e.g. comments and colorspace profiles left by image editors) from the PNG and recompress it using over 100 different methods and keep the one which results in the smallest file size.

It also has options for removing the alpha channel ("-c 2") and reducing color depth ("-bit_depth 8", but it can't go lower than that).

I use it on screenshots and such, works well enough :)
Okay le, edumacate me :

Jpegs lose info every time they are saved, that's not good.

Png's do not, but they are much bigger. Not as big as a tiff but definitely not small


So we try to work with tiffs but in many cases they are huge and cumbersome. PNG's are better to work with and don't have the disadvantage of losing info as you work with them. They seem to be pretty accurate. Good compromise.

So the png squishing seemed like a good idea. Not big and not lossy.


However, we tried several real-life tests of various photos turned to jpeg versus squished with various png-compressors.

In every case, the jpeg was both smaller and more accurate. Readng the description of what the compressor did, I was surprised the png-squished photos were as good as they are but still ... if you work with the png then restrict yourself to jpegging at the end, it seems that you get a smaller more accurate photo.

So what would be the advantage of compressed png's ?
thanks for the addition hamei.
and not totally on-topic, if you wanna get rid of metadata and stuff imagemagik comes with a tool called mogrify. it's like jhead but can strip clean all kinds of image types.

_________________
r-a-c.de
hamei wrote:
So what would be the advantage of compressed png's ?

PNGs load faster and can sometimes be smaller than JPEGs (e.g. on icons, pixel art, black&white drawings, anything with lots of sharp lines ...), also, if you need transparency, PNG is the best option (in theory, JPEG actually supports transparency, but in practice almost nobody implements that, so you're much better off with PNGs if you need an alpha channel).

But for photos, JPEG is better, as you found out :)

The reason for this is that it uses different algorithms for compression. The one used by PNG is lossless (it's basically the same as used by ZIP, except it does pre-filtering to improve compression rate), while JPEG uses lossy compression (it throws away color information, splits the image into blocks and performs fancy math which then enables the compressor to throw away information which the human eye won't detect, finally, it compresses the resulting data in a similar way to PNG).

So, pngnqs9 is actually lossy, since it throws away color information, but doesn't do any fancy math like JPEG does, which is why its image sizes are between standard PNG and JPEG :)

pngcrush, on the other hand, just tweaks the parameters of the lossless compression to produce smaller files.

If you're sending an intermediate image to somebody over email (or uploading it somewhere), it would make sense to recompress it with pngcrush ("pngcrush -rem text -brute in.png out.png"), but for final images, stick to JPEG.
I see no problem here.

Just keep your image in some lossless format when you are working with it and when you are finished, then save it in any format you like that is suitable for the intended purpose.