Wide Gamut Monitors and Untagged Images

[hjulenissen]

I'd say it's harder.  It's one thing to alter scaling, colour I think is more complicated, as there's no single answer, like "scale everything up by a factor 2" or whatever.  

Yes, but how would you know what was a legacy application?  If an application developer is concerned enough to set a colour legacy bit, they probably already do colour management.

The assumption with Apples high-dpi stuff seems to be that legacy applications are hard-wired for a given moderate dpi (say, 96 dpi), and when the OS knows that the display is actually a lot more (>200dpi), it will present a low-resolution virtual display to applications so that they can render into a frame where one pixel is of a traditional size, then scale this buffer to fit the physical panel. Applications that wants to access the true capabilities of the display will have to take active steps (raise a flag, choose a new API, whatever). Old applications that happened to do well with high-dpi displays but are not updated by the developer are out of luck.

I am suggesting the same thing for color management. Make a clean start. The OS does color management such that as a default, all applications are rendering to sRGB (or some approximation of it). Those applications that wants to access the true display capabilities will have to take active steps in order to be able to do so. This means that users clinging on to Photoshop CS3 will be out of luck (they may have the possibility to do some manual white-listing).

My reasoning is that the majority of computer users don't care much about colors. They are used to semi-predictable sRGB, and accept it. You really don't want to do anything to upset 95% of your customers (see what happened to Microsoft when they figured that mouse-and-keyboard users did not matter to Windows 8 ). The remaining 5% is still a substantial (and vocal) set of users, and you want to make them happy as well. So try to make stuff work for them. Some subset of the subset (e.g. 5% of the 5%) care a lot about colors, but for some reason won't update their applications. They are the ones who will have to suffer some inconvenience in order to make the bulk of users happy.

But some applications will do colour management internally without using WCS, and there's probably no way Windows can tell that.  Applying a "sandbox sRGB assumption" would be completely wrong in that case.  

And why is this such a bad thing? If you write applications for an OS, you either follow the rules or suffer the consequences. The OS makes no warranty that backwards compability will be maintained forever. In fact, Apple seems to be quite aggressive in breaking whatever the feel is needed in order to make their product more stable, tested and user-friendly. MS seems to be more conservative in maintaining basic backwards compability for a long time (applications is king).

By the way, EDID colour space values read from a monitor are often wholly incorrect.  Some monitors return the values of the sRGB primaries in the EDID - even for wide-gamut monitors.  

This is a real problem. How do you know the response of a device if it lies to you, and the user can not be expected to purchase a $150 colorimeter and operate it correctly? I do know that MS (perhaps Apple as well) does certification testing. So one possibility would be that a "MS/Apple"-certified display would have an EDID that (within some accuracy spec) described the measured response. A simpler (and perhaps more short-sighted) solution would be that displays offered an AdobeRGB (or some other pre-defined response) that would be sufficiently accurate for many displays and users. Like how Adobe & friends measure and maintains a database of camera responses (due to unfriendly camera manufacturers), MS/Apple _could_ do something similar to displays, but it would be cumbersome and at the very least, the OS would have to have access to the display "raw" mode. I have often thought that X-rite should be very happy that they have a significant number of users purchasing expensive colorimeters when many would perhaps be well-served by a global, high-quality measurement.

I am guessing that in many cases, and for many years, the middle layer would essentially be a no-op. The application would be deemed as "legacy" and the display would be deemed as "untrustworthy", falling back to assuming sRGB/nontagged source, sRGB/nontagged destination and safer to do nothing than to do anything. It would, however, present the opportunity for display manufacturers to get their act together and sell wide-gamut display that caused less frustration with (occasionally) casual users, such as myself.

While waiting for this development, my family continue watching video on either:
1) The 27" Dell screen with horrible colors
2) The 20" 9:16 (portrait) sRGB screen where 16:9 videos are reduce to postage-stamp size

-h

[D Fosse]

I am suggesting the same thing for color management. Make a clean start. The OS does color management such that as a default, all applications are rendering to sRGB (or some approximation of it). Those applications that wants to access the true display capabilities will have to take active steps in order to be able to do so.

I really don't think this is a good idea, it would complicate things no end. The application-CM model Microsoft follows today is a smart one because it keeps things simple and reliable. Already today Apple users get occasional problems with bugs in ColorSync, like a recent one in Mavericks where low gray values were clipped to black in the monitor profile. Bug reports were filed with Apple, but I don't know if it's fixed by now. This was exposed and well documented in the Adobe Lightroom forum. 

Instead I think what Microsoft should do is implement CM in all the native Windows applications, starting with Internet Explorer and Windows Explorer (the browser). That would go a long way. They already did it in the Photo Viewer, so it's not as if they can't do it. Office can probably wait.

I don't do video except as an occasional sidetrack, so I don't really know what the general CM status is there.

But at the end of the day the user still has some responsibility. If you buy a wide gamut monitor that's what you get, there's no need for the manufacturer to apologize for that. What they should do is inform the customer, which they are not doing today. I'm not talking about Eizo and NEC, their customers already know, but Dell, as a high-volume mainstream vendor, has a responsibility here.

[Simon Garrett]

But some applications will do colour management internally without using WCS, and there's probably no way Windows can tell that.  Applying a "sandbox sRGB assumption" would be completely wrong in that case.  

And why is this such a bad thing? If you write applications for an OS, you either follow the rules or suffer the consequences. The OS makes no warranty that backwards compability will be maintained forever.

For most applications, colour accuracy doesn't matter.  For those applications, whether or not Windows makes assumptions about colour space is largely irrelevant.  What does matter is that the application looks the way the designer wants, even without accuracy in colour.  So the sorts of colour discontinuities that would be introduced by Windows doing colour management where it can (i.e. not on everything such as Flash, or where the code bypasses high-level APIs) would be a real problem.  

For applications where colour does matter, generally they already do their own colour management, and introducing Windows colour management would in many cases result in double-mapping, breaking colour management.  

It would be great if Windows did operating system colour management, but the window of opportunity to do so closed 20 years ago, IMHO.  It would "solve" a problem for apps that don't need it solving while creating other problems for them, and break colour management for apps that do see colour accuracy as a problem, but have already solved it.

I don't think it won't happen, anyway, as Microsoft doesn't give a fig for colour accuracy.  As evidence of this: Microsoft added colour management to Internet Explorer in IE8, 7 years ago, but got it wrong.  They map from image colour space, but didn't get round to looking up monitor colour space.  This is a trivial omission in coding terms - probably less than dozen lines of code - but they haven't got round to correcting it in seven years.

Edited to add: the lack of OS colour management forces a different sort of standardisation.  That is, it puts a strong incentive on monitor makers to make monitors fairly close to sRGB.  Photographers might like a wider gamut, but they can cope with the resulting colour-management issues.  For everyone else, it's no bad thing.  It's another reason why I don't think lack of OS colour management is seen as a "problem" that needs solving. 

[D Fosse]

Edited to add: the lack of OS colour management forces a different sort of standardisation.  That is, it puts a strong incentive on monitor makers to make monitors fairly close to sRGB.  Photographers might like a wider gamut, but they can cope with the resulting colour-management issues.  For everyone else, it's no bad thing.  It's another reason why I don't think lack of OS colour management is seen as a "problem" that needs solving.  

Yes, I think that sums it up nicely. A solution in search of a problem.

(EDIT: I should add that even though I have largely talked about a standard gamut NEC P232 these last days, I also have a wide gamut Eizo. So I'm intimately familiar with the implications).

[WombatHorror]

I really don't think this is a good idea, it would complicate things no end. The application-CM model Microsoft follows today is a smart one because it keeps things simple and reliable. Already today Apple users get occasional problems with bugs in ColorSync, like a recent one in Mavericks where low gray values were clipped to black in the monitor profile. Bug reports were filed with Apple, but I don't know if it's fixed by now. This was exposed and well documented in the Adobe Lightroom forum. 

Instead I think what Microsoft should do is implement CM in all the native Windows applications, starting with Internet Explorer and Windows Explorer (the browser). That would go a long way. They already did it in the Photo Viewer, so it's not as if they can't do it. Office can probably wait.

I don't do video except as an occasional sidetrack, so I don't really know what the general CM status is there.

But at the end of the day the user still has some responsibility. If you buy a wide gamut monitor that's what you get, there's no need for the manufacturer to apologize for that. What they should do is inform the customer, which they are not doing today. I'm not talking about Eizo and NEC, their customers already know, but Dell, as a high-volume mainstream vendor, has a responsibility here.

agree

plus there is more than one way to do gamut re-mapping and if the OS is responsible for everything then you are stuck with whatever it does

[hjulenissen]

agree

plus there is more than one way to do gamut re-mapping and if the OS is responsible for everything then you are stuck with whatever it does

Not anymore than OSX applications are stuck with the image scaling of HiDpi: if the application developers can be bothered to use the new API and hit recompile, they get native access to the display and can do whatever they want with it.

At least, that is my understanding (and how I am suggesting a mainstream adoptation of wide-gamut).

-h

[Simon Garrett]

Not anymore than OSX applications are stuck with the image scaling of HiDpi: if the application developers can be bothered to use the new API and hit recompile, they get native access to the display and can do whatever they want with it.

At least, that is my understanding (and how I am suggesting a mainstream adoptation of wide-gamut).

-h

I'm sure that's right, but for colour management, it's not a simple matter of whether developers can be bothered to do something or other. 

When a new feature is added to an OS, many people will carry on using old applications for ever.  If Windows added automatic colour management, it would break the existing colour management in Photoshop CC, CS6, CS5, CS4, CS3... and Lightroom 5, 4, 3, 2... and all older versions of...  well, everything that does colour management.  Clearly, the latest versions could be updated to take account of a new Windows feature, but older ones won't be. 

Windows can't do colour management for any legacy programs, as it usually has no idea whether or not they are doing their own colour management (unless they're using WCS, in which case they don't need Windows to do colour management). 

Windows already has an API (WCS) to provde colour manage for programs that want it, though it's not trivial to add it to existing code.  Windows could do the auto colour management for newly-built apps that include some sort of "Yep, I'm OK with Windows doing colour management for me" flag.  But programs that are bothered enough about colour to set any sort of flag like that are probably already doing colour management themselves. 

[hjulenissen]

I'm sure that's right, but for colour management, it's not a simple matter of whether developers can be bothered to do something or other. 

When a new feature is added to an OS, many people will carry on using old applications for ever.  If Windows added automatic colour management, it would break the existing colour management in Photoshop CC, CS6, CS5, CS4, CS3... and Lightroom 5, 4, 3, 2... and all older versions of...  well, everything that does colour management.  Clearly, the latest versions could be updated to take account of a new Windows feature, but older ones won't be.

Lets say that "my" feature would result in legacy applications running on latest OS releases to be presented with an sRGB environment.How is that any different from older software not being able to benefit from retina displays without a recompile?

I do believe that it would be possible to make a manual "whitelist" where users could give individual applications special treatment (i.e. "allow my old photoshop to work just like before - I know what I am doing").

Windows can't do colour management for any legacy programs, as it usually has no idea whether or not they are doing their own colour management (unless they're using WCS, in which case they don't need Windows to do colour management). 

Well, it could make an sRGB sandbox for them. And for most applications, this should provide just what the user wants.

Windows could do the auto colour management for newly-built apps that include some sort of "Yep, I'm OK with Windows doing colour management for me" flag.  But programs that are bothered enough about colour to set any sort of flag like that are probably already doing colour management themselves. 

Since neither me or you seems to think that is a good idea (having applications actively flag that they are legacy), lets not discuss it.

So we (hopefully) agree that there is a trade-off: the OS vendors wants to keep the legacy/special-interest users happy _while_ improving their product for new customers/mainstream. That is a hard choice, and MS have historically chosen differently from Apple. I agree that the current situation works ok for the cases of:
1) Mainstream user. Don't care particulary about color. Purchase cheap sRGB display
2) Image professional. Have the hardware, skills and patience to setup and maintain a properly calibrated/profiled imaging chain. Use her computer for only color-aware applications.

My view is that many more people could be made more happy by changing stuff around. Perhaps the necessary incentive will come with UHD/4k/BT2020. Once regular enthusiasts stream wide-gamut Hollywood movies on their laptop/tablet/... she will be annoyed if mediaplayers and displays reproduce poor colors.

-h