When you need full color, but don’t need transparency, use JPEG instead.
implies that pixel-perfect results (non-lossy compression) is never desirable for images with full color, which I find to be a very provocative simplification.
On the other hand, on the web in general, perhaps it is good advice as a "rule of thumb" for people who aren't likely to deal with images where each pixel really matters.
There are actually two lossless JPEG modes even ignoring JPEG-2000: JPEG-LS and LJPEG. I don't know how widespread support for either is, but ffmpeg can encode to both. It confused the crap out of me a few months ago when I was trying to fix a bug and realized that the two were actually totally different formats.
The latter seems to be older and part of the original spec, while the former seems to be newer and a lot less bad.
Did he mean it literally, or just that you can fiddle with compression until you don't notice any artefacts? At that point, it's as good as lossless for most uses, IMHO.
When saving and closing an image, only to realize you need need to change something, thus necessitating a second save, which compounds loss. Granted, if you keep a lossless file around to edit, your problem is gone. But does everyone really do that with every file?
That's the only one I could imagine encountering, and if I've not saved the original, serves me right AFAIC.
But then, if I save the second with a higher-than-otherwise-optimal setting, then I can reduce the compounding of effects. It's cost me filesize to limit loss to the imperceptible, but it's still possible.
Indeed, PNG is very good at losslessly compressing artificial images which have large uniform (or gradient) areas, such as diagrams, drawings and so on.
SVG(.gz) could be even more compact (and just as important, resolution independent), but alas we'll have to wait a bit before support in browsers is common.
The point about Photoshop not supporting paletted transparent PNGs was new to me.
I only use Photoshop, so I actually believed that alpha channels were only available for 24-bit PNGs.
I wonder if Photoshop has planned future support for paletted, 8-bit alpha channel PNGs?
I wouldn't expect it too much. Photoshop also had a generally dreadful support for PNG (it would compress them very, very badly, sometimes to twice or thrice the size needed) before ~CS3.
It's definitely not time to stop fussing over Photoshop; that's not going away anytime soon.
It depends on who you are. I have never in my life used Photoshop. So if it disappeared from the planet, my life would change in no way, except that The GIMP would have more contributors.
PNG recompressors perform different optimization and try at different levels of hard, so the improvements coming from one compressor may be different (and combinable with) another's.
Furthermore, depending on agressivity they may change some encoding property of the PNG and make them easier (or harder) to recompress via other compressors.
The benefit of using both is that it often allows you to squeeze a few extra percentage point of compression. Ideally you should test all combinations of compressors (presence and sequence) but that tends to be a bit expensive, especially when you involve PNGOut as it takes a pretty long time to run.
FWIW, I just tried the following on a screen capture:
* OptiPNG alone
* PNGCrush then OptiPNG
* OptiPNG then PNGCrush
* Squash (which runs a sequence of PNGrush, OptiPNG and AdvPNG, it can also run PNGOut but I didn't install it)
The source file was 250K, the files that went through OptiPNG, PNGCrush+OptiPNG and OptiPNG+PNGCrush were compressed to 159K (with a slight edge for the one compressed via PNGCrush first: both Optis are 162997 bytes, while PNGCrush + OptiPNG is 162978) and the file compressed via PNGSquash is 144K (147249 bytes).
I've gotten the best results by far by first doing pngout, then optipng, then advpng - in that order!!
On some images each step cuts the file size by 10-15%.
Change the order and you'll get worse results.
Also pngout (and optipng) will convert 24bit PNGs to paletized PNGs if there are not a lot of colors. The often makes the file smaller - but not always. So I also suggest using the -c4 -c2 or -c6 options to pngout (as appropriate for the file) and checking if the file got smaller. But sure to pass -nc to optipng in that case.
Note that for small images under 1k, sometimes gif will be smaller than png because of the header size if you only need 1bit transparency. But you should be using sprites anyway.
I wish that ImageAlpha GUI was available for windows.
How did you make that image? If I had to, I'd create an awful custom profile for my monitor and work with that in Photoshop et al, but that's kind of a kludge. Did you use a tool to change the ICC profile behind it?
When you need full color, but don’t need transparency, use JPEG instead.
implies that pixel-perfect results (non-lossy compression) is never desirable for images with full color, which I find to be a very provocative simplification.
On the other hand, on the web in general, perhaps it is good advice as a "rule of thumb" for people who aren't likely to deal with images where each pixel really matters.