Hi, I already found your great tool a year ago and I'm really impressed. Often it can dramatically decrease file size, even when you set to best compression for saving the original png it can make it a little smaller. But there a very few pngs where pngout has increased filesize (but yust some bytes, mainly when they very small and where created by "The GIMP" with max. compression). It would be great could automaticcaly compare the file size of the old and the new file and an option not to create the new one if its bigger. Also for gifs that would be great, because sometimes, mainly on very small images/icons gif performs better than png. I found out that pngout reduces filesize sometimes not optimal. Something pngout could (sometimes) do to compress pngs even more (lossless): I had a 13KB png-background. Compressed with pngout: 11KB. I compressed the file again with The GIMP: 9KB! How could this tool achieve so much more over pngout? Very simple: the original image contained 7 indexed colors, bitdepth 8. For 7 colors 4 bits are more than enough, so GIMP automaticaly reduced bitdepth. Would be a nice feature in pngout as well. Of course pngout made a 7KB file out of this 9KB one. Also, for bigger images (for example banners) to help modem users enjoy browsing the web, there is interlacing in png, that the entire picture can already be displayed in lower quality before it is completly downloaded. I found out, that pngout seems to destroy this interlacing-information in png. Is there a way compressing them without destroying interlacing-informatiom in pngout? Finally, somekind of version numbering on your website would be great, it's impossible to see if pngout has been updated until you have downloaded it and looked at the date when it has been compiled.
And of course, thank you very much for creating such a great tool, to reduce traffic costs and make web-browsing a bit more comfortable (especially for non-broadband users).
Awesoken at
But there a very few pngs where pngout has increased filesize...
Have you played around with the /b# option? Usually you can beat other files if you're willing to try a few different values. I know it's inconvenient, and you'll be happy to know that automating trials is on my 'todo' list.
It would be great could automaticcaly compare the file size of the old and the new file and an option not to create the new one if its bigger.
This is already on my 'todo' list. I've been too lazy to implement such features.
Also for gifs that would be great, because sometimes, mainly on very small images/icons gif performs better than png.
You mean not write the PNG at all if it's bigger than the GIF? I think that's a bad idea because PNGOUT has another use: file converter / patent avoider :P
Something pngout could (sometimes) do to compress pngs even more (lossless)
Sorry, I will not be adding lossy compression to PNGOUT. That's what JPEG is for. I designed PNGOUT to be a very good "lossless" compressor, and that's the way it's going to stay. If you want to do lossy palette tricks, then you'll have to use another program for that.
the original image contained 7 indexed colors, bitdepth 8. For 7 colors 4 bits are more than enough, so GIMP automaticaly reduced bitdepth.
Ok, but some images with <= 16 indexed colors actually compress better with a bitdepth of 8. Currently, PNGOUT takes the bitdepth of the input PNG file. I am thinking of adding bitdepth as a selectable option from the command line... perhaps something like: /d1, /d2, /d4, /d8.
Is there a way compressing them without destroying interlacing-informatiom in pngout?
It's not a matter of destroying information. Interlacing is just a big headache to implement. Also, it usually results in larger overall file size. I can understand why it's important to modem users, but I just don't see it as a high priority right now.
somekind of version numbering on your website would be great, it's impossible to see if pngout has been updated until you have downloaded it and looked at the date when it has been compiled.
I edit my website in notepad - completely manually. Usually this results in lower file size : P, although the real reason I do it is to have complete control. It's a pain to change things though. Since I've been updating file sizes religiously, I suppose I can start doing the same for file dates. I will start doing this in the future.
Chokster37 at
I've always been a fan of compression utilities, I find them pretty fascinating (exe, ogg, png, internal game compression files eg. maps and sprite compression, etc.). I've just started using PNG for everything a few months ago, and it's a nice trip from the lossiness of jpg, the size of bmp, and the colour depth of gif. I'll have to try this program out; seems interesting. :)
S_O at
Have you played around with the /b# option? Usually you can beat other files if you're willing to try a few different values. I know it's inconvenient, and you'll be happy to know that automating trials is on my 'todo' list.
Now I haven't, I thought it uses best possible compression by default.
You mean not write the PNG at all if it's bigger than the GIF? I think that's a bad idea because PNGOUT has another use: file converter / patent avoider :P
Since the patent has become invalid at the beginning of this year in most contries, this isn't really a problem anymore. But I prefer using png. Unfortuantely mmg is not yet ready for use in daily life, so for animations (like emoticons in this forum :roll: ) you have to use gif. But if you don't like to have such an option in pngout, I don't think it's a big problem for me writing a little tool to check that (maybe it's even possible in a batch-file).
Sorry, I will not be adding lossy compression to PNGOUT. That's what JPEG is for. I designed PNGOUT to be a very good "lossless" compressor, and that's the way it's going to stay. If you want to do lossy palette tricks, then you'll have to use another program for that.
I only meant lossless palette tricks, what I said, only very few colors used but color space is 256 colors or even RGB24. pngout could try to optimze this if it's possible lossless. Maybe an additionaly switch (/oc - Optimize color or something similar), because sometimes you want to have RGB24, also image is monochrom, but with this switch it checks what's the best color-space for the actually used colors.
It's not a matter of destroying information. Interlacing is just a big headache to implement. Also, it usually results in larger overall file size. I can understand why it's important to modem users, but I just don't see it as a high priority right now.
Yes, for me it mostly results in 10% up to 15% bigger files. But either the people have a really slow connection and it's really usefull, or a really fast one and some kilobytes more doesn't matter. But if it's a headache to implement.. It's also not possible not to delete the interlacing informaton while recompression of an interlaced image?
I edit my website in notepad - completely manually. Usually this results in lower file size : P, although the real reason I do it is to have complete control. It's a pain to change things though. Since I've been updating file sizes religiously, I suppose I can start doing the same for file dates. I will start doing this in the future.
I understand that. I write my website also only in a plain text-editor (ok it's a better one, which is able to color html/php code like for example Visual C++ does with c++ code, that makes things much more easy and you notice a missing " or > much faster, but you still have full control). I really dislike programs like FrontPage or DreamWeaver. If you have php on your website you could easily implement automatically filesize scanning and you could edit your version numbers online with yust a few clicks, it could be that easy, after uploading new pngout you call for example http://advsys.net/ken/admin/update.php?tool=pngout (htaccess protected) and date/filesize of pngout is updated.
Awesoken at
I only meant lossless palette tricks, what I said, only very few colors used but color space is 256 colors or even RGB24.
Good point. My plan (for some future version) would be to make it auto-detect the best fit /c# option when you omit the /c# option on the command line.
It's also not possible not to delete the interlacing informaton while recompression of an interlaced image?
That question doesn't make much sense. My decompressor supports interlaced images, but my compressor doesn't. They are 2 completely seperate pieces of code.
If you have php on your website you could easily implement automatically filesize scanning ...
That's good to know, but I'm not familiar with PHP. I'm a dinosaur when it comes to this type of stuff. There's a reason why my forum isn't on my own website : P
S_O at
That question doesn't make much sense. My decompressor supports interlaced images, but my compressor doesn't. They are 2 completely seperate pieces of code.
That means it's completly different type of compression. I thought just the data ordering is different.
That's good to know, but I'm not familiar with PHP. I'm a dinosaur when it comes to this type of stuff. There's a reason why my forum isn't on my own website : P
PHP is very simple. If you can code C++, you'll be able to code php (more or less) within 15 minutes, syntax is nearly identical. If you like I can code you such a script. It should be very easy for you to understand (php is always in sourcecode on the server, it will be "compiled" when it's loaded). But you have to ensure you have php on your server. If you want to find out create a text-file with this content "<?php phpinfo(); ?>", save it as a .php-file and upload it. If you call the file and see the source or you get a download dialog, php is probably not installed otherwise you'll see lot's of information about the installed version etc. The best thing about php is, you don't need to use it, you can start within normal html at any place. Means you have your old utils.html file, rename it to utils.php and everything is still valid. But now somewhere you can insert in the file <?php echo filesize("util/pngout.exe"); ?>. It will output the filesize at the place it stands.
Awesoken at
That means it's completly different type of compression. I thought just the data ordering is different.
Argh, nevermind. Like most things, it's just a matter of me finding the motivation and development time.
If you can code C++, you'll be able to code php ...
Actually, I code in C, not C++... : ) I tried your PHP test on my server and I got a download dialog. So it looks like I don't have it. Thanks for the mini-tutorial - I may refer to it in the future.
The thing that bothers me about the PHP method is: won't the server have to access lots of files when somebody looks at an HTML? I guess it would be cached after the 1st time, but it still eats more RAM than before.
I think I know another way to do it, which would be to write my own "updater" utility. It would basically be something I run manually on my local machine which would parse my hand-written HTML files just before uploading to the server. It's an extra step for me, but it should lower the load on the server.
JonoF at
According to http://uptime.netcraft.com/up/graph/?host=www.advsys.net, advsys.net runs MS-IIS 6 on Windows Server 2003, so ASP is likely to be available moreso than PHP.
Awesoken said
The thing that bothers me about the PHP method is: won't the server have to access lots of files when somebody looks at an HTML? I guess it would be cached after the 1st time, but it still eats more RAM than before.
You're correct. PHP will have to stat() the file every time someone loads the page. Indeed it's dynamic but probably not the best solution.
Jonathon
Parkotron at
I think this bitdepth switch is a promising idea. I'd like to see it implemented.
Awesoken at
I added the bitdepth option (/d#) to PNGOUT a few days ago. I didn't bother to post any news about it because I didn't think it was that big of a deal. As always, you can download the latest version here.
Mr. Anderson at
Hello, I'm using pngout since some weeks and I think it's great. I supposed, that pngout will try compressing until there's no more compression possible. But today I tried to compress a file a second time and the output was again 4 Bytes reduced. Even the third time it was reduced by 1 Byte. Ok, 5 Bytes is not much, but I think this might be a bug, so I write it to you.
I'm using Linux, kernel 2.6.10 and compressed the file http://upload.wikimedia.org/wikipedia/commons/archive/a/af/20050118002223!Tux.png
And there are even more strange phenomens. After compressing a file, and compressing a second time, the output may be slightly larger. But when compressing a third time, it's smaller again.
Awesoken at
This is not a bug. The behavior you're talking about only happens on 8-bit palette files, when you use no filter (/f0) and not use /c3 or /kp. These are the default options for palette mode, so it's not too uncommon. In this mode, PNGOUT starts with the palette order from the input file. Then between each pass, it sorts the palette indices according to their Huffman symbol size. Doing this can sometimes allow the Huffman table to be stored in fewer bytes.
If you want a consistent palette order, then specify /c3 explicity at the command line. In /c3 mode, PNGOUT discards the input palette and generates it from scratch. If you want to preserve palette order completely, use /kp. No method is always better than the other. Each image has different results. If you want the best results, there's no getting around trial & error.
Martin at
Hi,
I have some suggestions for this great program :D
1. A parameter with which the process priority can be controlled
2. Don't convert animated GIFs.
3. An option to delete the source file if the PNG is smaller
4. Try the lowest bitdepth possible and compare it with 8 bit (if it's not true color), then choose the one which results in the lowest file size automatically
KillerQ13 at
Martin said
Hi,
1. A parameter with which the process priority can be controlled
2. Don't convert animated GIFs.
3. An option to delete the source file if the PNG is smaller
4. Try the lowest bitdepth possible and compare it with 8 bit (if it's not true color), then choose the one which results in the lowest file size automatically
I like all those ideas. Especially the process priority boost. That would be good for especially large batch jobs to have more attention from the CPU.
On animated GIFs: Ken, have you looked into the MNG format?
Awesoken at
A parameter with which the process priority can be controlled
Use the start command for this. For example: "start /low pngout ..."
Don't convert animated GIFs.
Why? Because it's theoretically lossy? Sorry, I'm happy with it the way it is.
An option to delete the source file if the PNG is smaller
I already do this for PNG files. I don't see the purpose in doing this for other formats - seems like feature creep to me.
Try the lowest bitdepth possible and compare it with 8 bit (if it's not true color), then choose the one which results in the lowest file size automatically
It would be wrong to do this automatically because it could mean much longer running time for /c0 or /c3 modes. If I ever get around to implementing lots of trials like in pngcrush/optipng, this will be included as part of it.
On animated GIFs: Ken, have you looked into the MNG format?
No, I haven't.
Martin at
Awesoken said
A parameter with which the process priority can be controlled
Use the start command for this. For example: "start /low pngout ..."
I've put PNGOUT into the context menu of the supported image types, but I don't get it to work with the start command.
asks me to choose an application to open the file :roll:
Awesoken said
Don't convert animated GIFs.
Why? Because it's theoretically lossy? Sorry, I'm happy with it the way it is.
I still have a lot of GIFs (animated and non-animated) which I want to convert, but I don't want to lose the animations.
Awesoken said
An option to delete the source file if the PNG is smaller
I already do this for PNG files. I don't see the purpose in doing this for other formats - seems like feature creep to me.
This would help to get rid of those GIFs without having to do further scripting :)
Awesoken said
Try the lowest bitdepth possible and compare it with 8 bit (if it's not true color), then choose the one which results in the lowest file size automatically
It would be wrong to do this automatically because it could mean much longer running time for /c0 or /c3 modes. If I ever get around to implementing lots of trials like in pngcrush/optipng, this will be included as part of it.
Okay ... but for converting/optimizing a bunch of images in the background one wouldn't really notice it ^^
counting_pine at
Martin said
I've put PNGOUT into the context menu of the supported image types, but I don't get it to work with the start command.
This isn't ideal, but it's the best I can come up with:
Make a batch file called 'c:\pngoutlow.bat' or something:
@echo off
start /low /b /wait c:\pngout.exe %1
pause
The pause is just there so you can see the result without the window immediately disappearing.
The /b switch keeps pngout running in the same window as the batch file, and /wait stops pause running before pngout finishes.
Note that, because of the /b switch, if you want to terminate pngout you have to use Ctrl-Break instead of Ctrl-C
The batch file has %1 (one) instead of %l (el).
Then for the context menu, put:
c:\pngoutlow.bat "%L"
Change paths to suit.
Awesoken said
Try the lowest bitdepth possible and compare it with 8 bit (if it's not true color), then choose the one which results in the lowest file size automatically
It would be wrong to do this automatically because it could mean much longer running time for /c0 or /c3 modes. If I ever get around to implementing lots of trials like in pngcrush/optipng, this will be included as part of it.
Perhaps it would be better to have an option switch (e.g /dl, /d0, /l) that automatically tries the lowest bit depth. It doesn't try two optimisations, and people who want to try both can just run the program twice with the appropriate options.
Btw, with greyscale images, I find low bit depths tend to compress better with filter type 0. Have you thought about changing the default? Or perhaps it would complicate the heuristics too much?
Edited at
Awesoken at
Perhaps it would be better to have an option switch (e.g /dl, /d0, /l) that automatically tries the lowest bit depth.
Good idea. I implemented this feature just now. You can use /d0 to select the lowest possible bitdepth. /dl will also work because atol returns 0 for non-value strings : P
I still have a lot of GIFs (animated and non-animated) which I want to convert, but I don't want to lose the animations.
...
This would help to get rid of those GIFs without having to do further scripting
Hmm... those are good reasons. Still, I think very few people would use these features. Because of this and the fact that it can be implemented via external script, I'm going to have to pass on this one.
counting_pine at
Re animated gifs:
Have you tried gif2png?
I haven't used it, but apparently with multiple-image gifs it extracts each frame to a separate PNG file. Alternatively, you should be able to get it to abort on them. I think you can do it with the -f switch. Read http://www.catb.org/~esr/gif2png/gif2png.html for details.
Edit: The Win32 binary link seems to be down, you could try here instead.