P: Save For Web, Convert to sRGB should be off by default for PNGs and GIFs

Thanks for the great discussion Ricky. For the record, I think you're smart :D

Here's a real life example of why Safari 6's new policy is bad: https://twitter.com/foresmac/status/2...

One more post and I'm done. :-)

Also, I think my frustration stems from Chris assuming I'm an idiot, and suggesting what I'm saying is incorrect.

In Chris's defense, when I first contacted you on Twitter, I'd bet you thought I was an idiot too! 😉 And it's really easy to assume that, given how esoteric a subject color management is, how hard it is to get right, and how much context you need in order to understand why somebody's workflow is done the way it is to achieve its goals.

See you around 🙂

Apple uses PNGs for many of their product photos when an alpha channel is necessary.

Surely the solution to that is to embed an ICC profile into the PNG and *not* convert? PNGs can have profiles... that's just not supported in Photoshop (as far as I'm aware). I wonder why this feature doesn't exist?

Remember what you set it to last time, but stay in the Save for Web dialog.

Thankfully, the setting is remembered.

Also, I think my frustration stems from Chris assuming I'm an idiot, and suggesting what I'm saying is incorrect. If anything, I've demonstrated that all browsers render the same, except Safari 6. I also think Adobe's skew towards photography misrepresents those using Photoshop for interface design. Maybe we're just using the wrong tool for the job.

For the record, I agree entirely with your setup, if you're trying to target Windows and Mac and are aiming for a generalised solution.

I think consistency within the same page is far more important that aiming for consistency across all devices, which is completely unachievable with the current browsers.

if anything it just proves that Convert to RGB isn't needed for your workflow and Adobe's preferred workflow.

I've addressed this in my previous post:

And there are cases where you would want to do this in PNG, too. This photo is used in an animation that is dependent upon the presence of an alpha channel, and this kind of thing will become more and more common as HTML5 adoption skyrockets.

This is just one example. Apple uses PNGs for many of their product photos when an alpha channel is necessary. I've also pushed photos through SfW as PNGs in an interactive demo I made for Intuit (view on an iPhone). And these photos could have started in Adobe RGB. If not converted to sRGB, the colors would look dull and washed-out on a normal monitor.

The Convert to sRGB checkbox being checked by default in Adobe's recommended workflow is meant to take anything that isn't translated to sRGB and make sure that it is. You may not agree with it, but it is consistent with the rest of their default settings, as well as the all-or-nothing mantra: it accounts for all sRGB workflow scenarios (see below for more on this, I do agree that it's broken in one respect).

---

I marked them yellow because they don't match the display and therefore the user isn't getting what they're seeing.

This is a need that you and I both address in our workflows in different ways (see below).

---

In your case, why wouldn't you just use Monitor RGB as the working space, set the documents to Don't Color Manage This Document and preview as sRGB?

Our workflows optimize for different results.

My display is very close to the Adobe RGB working space. For my Adobe RGB photos in Lightroom, it allows for a wider range of color reproduction. But it also means that purely saturated colors, at my default gamut, are fluorescent. For design in Photoshop, that is not quite representative of my target audience. I must target a wide range of LCDs, and sRGB is the recommended way of handling that. So, I want the default mode of operation to be sRGB.

Both of our workflows target idealized scenarios. Yours assumes that most Mac/iOS displays look much like yours. Adobe's/mine assumes that most monitors look much like sRGB. We are guilty of the same crime, as neither is the case (your blue boxes are spot on). However, your workflow can be more targeted, because you design on Apple displays, for Apple displays, and oh well if someone hooks up an Adobe RGB Dell monitor to their Mac like I did. And mine doesn't really solve for Adobe RGB monitors either. These people aren't in our target audience, and here's why.

I'm getting a little philosophical here, but it's fine to design both ways. In the end, our audiences don't know about the color management workflows we used. Their baseline is their monitor. If our #facade looks a little different from their #facade, it really doesn't matter in the end. It's all relative to what else is on their display, and their previous experiences on that display. All we can do is try our best to simulate what they're seeing, and we go about this in different ways, keenly aware of any tradeoffs we're making.

I think it should be abundantly clear by now that there's no common ground here, and I'm frankly tired of talking about it, so let's move on...

---

But you're not getting all. You're getting a destructive conversion and no tag on the file. At best, that's half. At worst, it's like closing your eyes randomly spraying bullets in the direction of the target. It's a hack that does more damage than good, and for you, it actually does nothing.

When I said, "this checkbox is integral to color workflow," I meant this in terms of color workflow in general. I agree that the current behavior is broken in that it doesn't remember your settings, as it is destructive to your workflow. I disagree that it does nothing for people using the recommended sRGB working space (see above).

Because this checkbox affects color and has no context to the designer's workflow, my proposal above was:

1. 
   
2. Move Convert to sRGB to where the other color management settings are, or
3. 
   
4. Remember what you set it to last time, but stay in the Save for Web dialog.
5. 
   

In either case, it would still be checked by default (for consistency with Adobe's sRGB workflow), however, it would remember what you want the setting to be.

Let's check your assumption that the sRGB -> sRGB conversion could introduce rounding errors.

I shouldn't have said that, because it doesn't. You're right. That's a minor point though... if anything it just proves that Convert to RGB isn't needed for your workflow and Adobe's preferred workflow.

So, who *does* need Convert to RGB? Photographers who are using a non-sRGB colourspace who want automatic destructive conversion to sRGB, because browser support for colour profiles is bad? Why are those people using PNG and GIF? PNG and GIF are typically user interface image formats. Photographers would be better served by using JPEG. And in that case, I'd probably recommending converting to sRGB *and* including an sRGB ICC profile.

Why would you want to convert to a profile, then not tag the image with that profile? To me, that's just adding to the problem. Not having a colour profile in an image should mean "I want this to be displayed without conversion". And I think that's where the Safari 6 team have made a huge mistake. At the very least they should be converting everything drawn to the page.

So those yellow boxes in your chart should be green.

I marked them yellow because they don't match the display and therefore the user isn't getting what they're seeing. In your case, why wouldn't you just use Monitor RGB as the working space, set the documents to Don't Color Manage This Document and preview as sRGB? Same end result.

Colour management does not work when only half the problem is solved. I think Photoshop's Convert to sRGB adds to the problem, and doesn't aid it.

Because this checkbox is integral to color workflow (again: all or nothing!)

But you're not getting all. You're getting a destructive conversion and no tag on the file. At best, that's half. At worst, it's like closing your eyes randomly spraying bullets in the direction of the target. It's a hack that does more damage than good, and for you, it actually does nothing.

---

Let's take a short recap on some of Chris' comments directed towards me.

In short: you're wrong on almost every point here.

Yes, accurate ON YOUR MACHINE, IN THAT ONE BROWSER.

But your final product will appear different in different browsers, and different versions of those browsers. That's the sad state of the web for now and the immediate future.

But if you're ignoring the variations between browsers and changes between versions of the browsers, it's possible you haven't noticed all the problems.

Chris, you're wrong on every single point here. Please refer to the tests I've done.

And just to preemptively reply: Remember that we are *only* talking about PNGs and GIFs that do not have colour profiles attached.

Thanks for doing that testing. So Safari 6 is translating PNGs to sRGB, but not HTML/CSS color? 😞 I agree. That's definitely a bug in Safari. Like you said, color management is all or nothing. People can come down on either side of the argument, however. Wanna file a Radar, keeping that in mind?

(converting from sRGB to sRGB will not change the values, unless there's a rounding error in the conversion).

Let's check your assumption that the sRGB -> sRGB conversion could introduce rounding errors.

I wrote a PHP script to create a 4096 × 4096 PNG with all 16,777,216 RGB8 color values in it. Let's run it and verify its output against itself real quick:

blitzwing:~ r$ cd /Users/r/Desktop/colors


blitzwing:colors r$ php 16777216.php


No path set.  Creating image...


Saving 16777216.png to current directory...


blitzwing:colors r$ php 16777216.php 16777216.png


Verifying image...


The images are identical.

Cool, now let's open the PNG up in Photoshop CS6. Edit > Convert to Profile. I'm just checking the Source Space here, to make sure it's in sRGB. Yep! Cancel.

File > Save for Web...: Convert to sRGB is left turned on. Holy crap, only 128K?! Either it's broken, or PNG rocks. 🙂 Saving as sRGB.png.

blitzwing:colors r$ php 16777216.php sRGB.png


Verifying image...


The images are identical.

Good. While we're here in Photoshop, let's also pick a color and pencil it somewhere else just to make sure my script is detecting differences correctly. Saved as sRGBdiff.png.

blitzwing:colors r$ php 16777216.php sRGBdiff.png


Verifying image...


Images differ at x:1990 y:2003.


Us:     r:198 g:55 b:125


Them:   r:197 g:55 b:125

So those yellow boxes in your chart should be green. All 16,777,216 colors tested, zero difference. This is a fact. It would make a very good regression test for future versions of Photoshop though. I would quibble with you on the use of a bright red box there, but we've already argued about this stuff at great length. :-)

Next, let's talk about the checkbox itself.

In Chris's recommended setup, Convert to sRGB does nothing. In almost any other setup, it will damage every exported file.

Please remind me again why the option is turned on by default?

This subtly implies that Chris and I in the minority with this sRGB nonsense, and there are an untold number of web color workflows, which, taken together, is much larger, so the default checkbox setting needs to change as such. In reality, our workflow is the majority; as Adobe assumes that you will be creating content for a wide range of computer displays, the default working space for Creative Suite is sRGB.

As I said previously, there is consensus that designers should use sRGB for web work. This is a Save for Web dialog box, therefore, the default setting makes sense. If you have a photo in ProPhoto RGB or Adobe RGB, it should be converted to sRGB so that the colors don't look washed out on an sRGB-style display. And there are cases where you would want to do this in PNG, too. This photo is used in an animation that is dependent upon the presence of an alpha channel, and this kind of thing will become more and more common as HTML5 adoption skyrockets.

Your workflow (and the workflow of the people following your advice) is specifically tailored to creating UI/web images for Mac/iOS displays that are reasonably consistent and high-quality. It is very specialized, and the only reason I can imagine that you are using Save for Web for your UI work is for the optimization benefits. I know you do some web work as well, but it's not specifically targeted at a general audience; just Mac/iOS users with nice displays.

However, the default setting for Save for Web is destructive for your specialized workflow, as you have said. This checkbox does not have any context of your color workflow. Its default behavior depends on your leaving the rest of the color settings alone, in sRGB. This is the root problem.

Because this checkbox is integral to color workflow (again: all or nothing!), my proposed solution is for it to remember your last setting and/or have it be part of the Color Settings dialog. Not to force a default that doesn't make sense for the majority of the people using this feature. I hope that makes sense. I'm getting tired of this (but at least it's not another Twitter argument). 🙂

Let's start with some facts:

1. Most developers and designers use Photoshop's Save for Web for web and app PNG and GIF images.
2. Photoshop's Save for Web can not save PNG and GIF images with a colour profile attached.
3. Most web interface images are PNGs and GIFs that do not contain a colour profile.
4. Practically all iOS and Mac app interface images are PNGs that do not contain a colour profile.

That is the reality.

** All the browsers I've tested display PNGs and GIFs according to the raw values contained within the files, with the exception of Safari 6 (just released a couple of days ago, more details below). **

–––––––––– Browser tests ––––––––––

Here's the browsers tested, using a PNG, PNG with gamma chunk of 2.2, GIF and CSS:
iOS 5.1.1 Safari
iOS 5.1.1 Safari - iPhone Simulator
OS X 10.7.4 Safari Version 5.1.7 (7534.57.2)
OS X 10.8 Chrome 20.0.1132.57
OS X 10.8 Firefox 7.0.1
OS X 10.8 Firefox 12.0
OS X 10.8 Firefox 14.0.1
OS X 10.8 Safari 6.0 (8536.22)
Ubuntu 10.10 Firefox 3
Windows XP-x64 Chrome 20
Windows XP-x64 Firefox 14
Windows XP-x64 IE 8
Windows XP-x64 Opera 11
Windows XP-x64 Safari 5

I also tested the same PNG in an iPhone app
iOS 5.1.1 app - iPhone Simulator

I don't have a grab of the iPhone app running on the device right now, but trust me when I say it's the same — I compare screen grabs from the device with my PSDs all day, every day and they always match perfectly.

Here's a composite of the important parts (all identical except Safari 6, which is at the bottom):



Here's the test web page, containing the colours as CSS, a PNG and a GIF image:
http://bjango.com/articles/colourtest/

And all the original screenshots:
https://www.dropbox.com/s/l35dbcrgu7i...

Except for Safari 6 (info below), every single browser rendered everything exactly according to the HEX values typed into the PSD initially. PNG, GIF, CSS across many browsers and versions are identical.

Safari 6's CSS did match the other browsers, but the PNG and GIF images did not.

I don't know his current opinion, but in 2006 Dave Hyatt thought it was a bad idea to treat images with no profiles as sRGB:

First of all, if you correct unprofiled images to sRGB, you have to correct all drawing to sRGB. This includes everything drawn by CSS (borders, backgrounds, text). This is not difficult to do under the hood, although it is difficult to do it with no performance regression in our benchmarks at all. In fact we even tried this during the Tiger development cycle (just correcting everything drawn to sRGB), but it slowed us down.

The big hurdle that we ran into, though, was with the drawing we did not control, namely the Flash plug-in. The problem is that designers specify colors in Flash and colors in CSS in the Web page, and they expect those colors to match. Because Flash’s drawing isn’t correcting to sRGB, if we did it in Safari, there would be color mismatches all over the place. These mismatches look far worse than if we just don’t correct at all.

If the Safari/WebKit team have chosen to assume images with no profile are sRGB in Safari 6, then I think that was a big mistake, and I bet the web community will be upset that CSS and images no longer match.

Apart from the brand spanking new Safari 6, I have never, ever seen a modern browser behave differently. If you believe this is the case, please provide evidence.

–––––––––– No RGB management vs sRGB all the way ––––––––––

There's two setups that are being advocated in this discussion.

I recommend:
Working Space / Proof: Monitor RGB / Off.
Document profile: Don't Color Manage This Document.
Convert to sRGB: Off.

Chris and Ricky recommend:
Working Space / Proof: sRGB.
Document profile: sRGB.
Convert to sRGB: On.

Here's how colour values are tracked throughout those workflows. Please note (again!) that we're talking about PNGs and GIFs saved using Save for Web, so they *can not* have profiles.



The numbers in the red box will change depending on your monitor profile.

If your document is tagged sRGB and you're exporting with Convert to sRGB turned on, your values are being exported unchanged (converting from sRGB to sRGB will not change the values, unless there's a rounding error in the conversion).

Colour management is all or nothing. You can't make some blind conversion when you're saving an image that doesn't contain a profile. And remember, for user interface design colours in images MUST match colours in code. That's essential.

–––––––––– The important conclusion ––––––––––

In Chris's recommended setup, Convert to sRGB does nothing. In almost any other setup, it will damage every exported file.

Please remind me again why the option is turned on by default?

When accounting for the color cast from the white balance differences, it's a couple hundred meters off, not miles off. 🙂 My cones automatically filter those white balance differences out when not looking at them right next to each other, and the same thing happens for your users. It's all relative. This automatic correction doesn't happen with a camera, thus the color cast. That's why it looks much, much closer in person when looking back and forth at each. If you have a colorimeter, I used the X-Rite i1 with i1Match and VNC Viewer to profile my iPhone's display (making sure that the colors weren't being changed over the VNC connection first). Try it yourself, I think you'll see it actually works pretty well for quickly estimating color output (if your display is also properly calibrated).

Besides, I *do* consistently test on-device using your (very nice) software, which works fine, and it *is* my default mode. I'm just illustrating that you can work in sRGB and use color proofing for some interesting things, including checking what it looks like in your own display's profile. I also don't just look at on my iPhone; I also check in sRGB to make sure I'm mindful of that generic standard.

And this isn't even the main focal point of my color workflow. Not everyone has a high-quality Mac display. How do you test on a wide range of consumer-level LCDs? You can't, so you target the average that the manufacturers build to, which is sRGB. It's what's recommended, and by choosing a different working space, this is why you're having problems with Save for Web. My workflow isn't perfect either. Working in sRGB means I see posterization in subtle gradients, but never in the final image (and besides, it's a good reminder to dither!).

Mind the blood pressure! 🙂 This is just what works for me. And as I've mentioned below, there's a less hacky way to achieve your current workflow which doesn't exhibit this Save for Web problem.

The color temperature of my display is different from my iPhone, which the camera accentuates, but it looks much closer in person.

This is why I *only* rely on device testing, done with Skala Preview (software we developed). Nothing trumps seeing the actual results in situ. You simply can't argue with that... it's the final result in place, with everything taken into consideration.

Also, in your iPhone example, both your proof and sRGB examples are miles off the iPhone.

Sorry, forgot to mention: Use sRGB as your main working profile, then set your Proof Setup to Monitor RGB. Then there will be no color translation in any direction.

Again, however, the recommended workflow for web is to work in sRGB throughout.