Photoshop: SaveForWeb could have more optimizations for PNG

  • 4
  • Problem
  • Updated 6 years ago
  • Acknowledged
  • (Edited)
As of CS6, JPG and PNG files produced by "File>Save for Web" are still able to be highly and losslessly reduced by Imageoptim running on a mac:

http://imageoptim.com/

Some of ImageOptim's techniques are fairly complicated, but some of them are just basic things, like stripping metadata. Again, they are not lossy.

What's the holdup? Is this a compatibility issue? Or a legal rights issue?

Given the intensely performance-minded bent of current web development, it would be great to see illustrator and photoshop's save-for-web export files that didn't need this kind of extra tinkering to achieve maximum compression. Adobe, please eliminate the need for this extra step, and make imagOptim obsolete. Photoshop does everything I want, except this. Front-burner, please!
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like

Posted 6 years ago

  • 4
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 813 Reply Likes
SFW saves what you tell it to save. If you tell it to save metadata, it does.

SFW can't save some PNG specific tweaks at this time, so there are possible optimizations available that SFW doesn't do yet.

In general, SaveForWeb files don't need any additional tinkering to get minimal file size -- if you chose to save them with minimal file size and no extra metadata. But some users want the extra metadata (like their copyright) in the file.
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like
Thanks Chris. I have to say your response seems somewhat contradictory to me. First you say there are optimizations PS hasn't implemented yet. Then you say that "in general" file sizes are absolutely minimal. Huh? okay...

Imageoptim proves that PS's optimizations aren't optimal, full stop. Every day, I save for web with metadata set to none, and no color profile, and imageoptim still reduces things slightly.

Also not that it's not just PNG files we're talking about-- a quick glance at the Imageoptim's optimization algorithm names shows that: "PNGOUT, AdvPNG, Pngcrush, extended OptiPNG, JpegOptim, jpegrescan, jpegtran, and Gifsicle".

(For web development JPG and PNG are obviously the two biggies.)

If this is already on the to-do list somewhere, it would be great if the PM could prioritize it higher. It's core functionality.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 794 Reply Likes
In 95% of cases, there is not additional optimization needed. In maybe 5% of cases, there are a few PNG specific tricks that SFW doesn't do yet, an more optimization that might be done.

The Imageoptim author exaggerates quite a bit, and mostly shows examples based on removing metadata that the user chose to embed. That doesn't prove much other than the user chose metadata over file size.

Also, just because he includes a lot of code (and a lot of redundant code at that) doesn't prove anything other than he threw together lots of open source code.

In many cases it is also throwing away quite a lot of (visible!) image quality in the pursuit of smaller files.

Also, the imageoptim author has no idea how to use color profiles, or why they should be included with web images. And he has an amazing misunderstanding of gamma (which should be removed from PNG files, but not for the reasons he lists).

If you want SFW to add more optimizations -- just say so.

If you have an example where SFW could do better - show us the example, and we'll investigate.
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like
I don't want to get into the profiling can of worms. :) And I agree his demos stack the deck somewhat, but I'm not going to dwell on that. Let's maybe sidestep that and just look at a couple of PNGs:

Save For Web 24bit PNG from Illustrator. 1.58Kb.



Save For Web 24bit PNG from Illustrator, then Imageoptim. 796 bytes.



I see no visual difference between these files. And I'll be the first to admit I don't know what the under-the-hood differences are. But the file size difference is marked. Can you illuminate what's going on here? Thanks!
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 794 Reply Likes
The image have very few colors (17 to be exact) but you chose to save it as PNG24 for some reason.

You could have saved it as PNG8 with 16 colors for a file size of 845 bytes.

Also, your first example is only 2007 bytes, and the second is 1970 bytes.
And both have some unnecessary metadata (which you chose to save).
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like
Well, I actually chose to save as PNG-24 because the edges of transparent backgrounds are much smoother that way. It's not simply a question of number of colors, in my experience. I see a visual difference with PNG8 versus PNG24 where transparency is involved. Here's a PNG8 of the same basic image. The edges are more jagged. You'd see it even more dramatically with a background involved:



About metadata: I doublechecked everything, and I didn't choose any metadata in illustrator that I can see. There's no such menu option in Illustrator's SFW, even! So I'm not sure what you're referring to there. Can you show me what you're talking about? Where did I "choose to save" the metadata in illlustrator? Maybe there's some metadata always baked in by illustrator. That's... the problem.

Now, about file size: as a sanity check, here's a live page of these same files not using Adobe servers:

http://bit.ly/TRhkBW

When I check the filesizes in Chrome Dev Tools I see exactly what I wrote in my last post: 1.58kb and 796 bytes, respectively. To spell it out for all, here are screen grabs of the dev tools inspector:





But weirdly, when I inspect this very page we're typing on right now, i get different file size numbers! Your server is monkeying with the files on upload! Ach!

Here are Inspector grabs from the "Adobe" versions of the PNG24 files on the cloudfront server :





Just to spell it out, these show 1.96 Kb and 1.92 Kb, not the 2007 byte and 1970 byte figures you're quoting. Or is Chrome dev tools wrong?

Lastly, just to round things out, a PNG8 of this file from illustrator SFW is 903 bytes, not 845 as you claim. Close, but not the same. the PNG8 (903)is still bigger than the PNG24 with imageoptim (768)! And the quality is worse!

I want to be able to save PNG24 files at the smaller, post-imageoptim (nearly half the SFW only!) file size, without using imageOptim, and without bumping down to PNG8 and getting the quality loss. I think this discussion so far only reinforces the legitimacy of that request.

Lastly, I truly appreciate any insights that you might have, but please refrain from snarkiness about "operator error" when it is your system that has created the error. I'm sure you have to deal with a lot of jerks here on this forum, but I'm not one of them! I'm here to learn.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 813 Reply Likes
I checked the size of the files you actually uploaded, and downloaded them for myself (not the inline previews). The inline files are also about 2KB.

Yes, this simple file might benefit from some PNG specific tricks (index+alpha or indexed transparency) that SFW does not currently support.

But also this example is not visually different from just saving indexed (PNG8).

You would still have to save as indexed color to get the file size you're after: 24 bit color just won't be that small.

Photoshop's SFW has the metadata choices, I haven't used Illustrator's in quite some time (but they're *supposed* to keep up with Photoshop's source). And when I save your file as PNG8, the resulting file is 845 bytes.

Sorry about the "operator error" comment - I removed that a minute after I posted it.
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like
Thanks, Chris.

I work with a lot of simple files like this, flat UI elements, and I'm surely not the only one :) A halving of file size would be significant for me, especially for mobile use cases. Glad we're on the same page here. Please pass the word along!

Three points:

1) The PNG24+imageoptim is visually different from the PNG8, full stop. Here is the ironclad proof: I flattened both files onto white, stacked them with the blending mode set to difference, and then inverted the image to make the faint outline more apparent:





In my mind, the smattering of pixels you see there is similar to the difference between good antialiasing and bad. For the record, I see the same difference in the two images above. Look especially at the ragged, chunky textures at the tip of the breast and on the top of the beak. I ain't crazy here. Nor am I climbing up on some high horse. The edges of the the smaller PNG24+imageoptim file look better than the larger PNG8 file. That's why my workflow is the way it is. And that's why I'm asking for better built-in PS optimizations that will save me a step.

2) I'm a little hazy on how Photoshop is referencing "Indexed" here. When I open a PNG8 into PS and look at Image>Mode, it of course shows "Indexed color". But when I open a PNG24+imageoptim file and look at Image>Mode, it continues to show "RGB," not "Indexed Color". What's going on here? You insist that "You would still have to save as indexed color to get the file size you're after: 24 bit color just won't be that small." but that's not what the PS UI is showing. Is PS misrepresenting the file somehow? That doesn't seem likely, but it's possible. Or is there other compression trickery at work here that PS isn't reporting? Can you clarify on this, ideally with documentation?

3) Imageoptim is well regarded in the progressive web community. It's part of http://yeoman.io/ and it's widely hailed as part of a modern toolset. I'm not defending it per se, because I have no stake in it personally--but it is popular. So when you write that "In many cases it is also throwing away quite a lot of (visible!) image quality in the pursuit of smaller files." it would be really helpful to see documented, proven examples. Got any? I really think the web developer community would be really interested to see a public image roundup of side-by-side comparisons (similar to what I've tried to do here) if such a thing exists.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 794 Reply Likes
PNG8 with indexed transparency is opened as a full RGB file - because Photoshop cannot support indexed transparency (or all the odd modes of the PNG file format). So you are still confusing file mode and document mode.
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like
Ah, okay--that makes sense. So Image>Mode is showing the "document mode" then and not the "image mode"? Okay. But what about 1&3? Having gone this far, I'd like to know that my points have been heard somewhere...
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 794 Reply Likes
Your points are being heard, even if you started with the wrong approach.
Photo of bellnwhistle

bellnwhistle

  • 12 Posts
  • 1 Reply Like
Wow, dude. So unnecessarily rude! It's you who "started with the wrong approach."

You began this thread by hurling a bunch of off-topic, pointless personal attacks against the imageoptim author (?!)

Then you sniped at me for "operator error" when the error was demonstrably in your system's.

Then you insisted two files were identical when they demonstrably aren't.

Then you can't provide any evidence for your assertion that imageoptim visually damages files.

I'm trying to be constructive and nice at every turn, not gloating at anybody else's mistakes, not flaming you in the least, helping your company improve its product, and giving pretty specific feedback, and you're just being a total jerk. I've seen this happen in several other threads and tried to give you the benefit of the doubt, assuming you were having a bad day. But now it seems like that's just who you are full-time. Honestly, it just isn't worth it at this price. Try to have a nice day, okay? Goodbye.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 794 Reply Likes
I'm sorry, but I am not going to take the time to verify the obvious. (ok, maybe it's more obvious to me because I know what the programs imageoptim ties together are actually doing)

You started off by claiming things that were patently false, and comparing to a program that does things you don't fully understand (written by someone who doesn't understand them himself). You filed it as a problem report, when really you want features added. Then you keep attacking and accusing instead of providing useful feedback or asking for improvements.

In short: you're going about this all wrong.

Next time, provide examples and ask.