Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: David Eichler on March 19, 2014, 09:23:54 pm
-
A lot of websites seem to strip the tagged color profiles from images. This didn't matter quite as much in the past because it was very unlikely that the average viewer had a wide gamut monitor (not that some color and contrast distortion can't be seen with an sRGB only monitor). However, the current Apple Cinema monitor has a wide gamut, and while probably not mainstream in most areas at this point, it may be getting more common in more well heeled areas. I am wondering how common wide gamut monitors are at this point. Other than the Cinema display, are there any other wide gamut monitors currently being marketed to mainstream consumers? At least some of the current Dell Ultrasharp monitors are now wide gamut, but are average consumers even considering these?
-
Cinema displays are wide gamut?
NEC and Eizo among a few other's have a number of wide gamut displays.
-
Cinema displays are wide gamut?
NEC and Eizo among a few other's have a number of wide gamut displays.
Oops. No, the Apple Cinema display is not wide gamut. However, some of the new Dell Ultrasharps
are. Wonder how many people are buying these just for general use.
-
Oops. No, the Apple Cinema display is not wide gamut. However, some of the new Dell Ultrasharps
are. Wonder how many people are buying these just for general use.
My personal Dell 2711 is wide-gamut. As it was one of the least expensive 27" at the time, I am guessing that a fair amount of general users got it (those with $900 to spare, some room on their desktop and an interest in large "2.5k").
I am using the sRGB Dell 2713HM for work. I'd say for non-photographic work it is just as good. I am guessing that casual photography customers will buy it instead of the wide-gamut 2713HM.
I think that you are raising an interesting question. One cannot assume (and the industry should not assume) that general people have colorimeters, or that they care to press display buttons in order to select "sRGB emulation" when needed. So the current solution seems to be to ship these displays with sRGB emulation selected as default, relying on the sRGB assumption that is deeply embedded in all of our software and hardware. Problem is, why should the user then purchase a more expensive (less energy efficient?) wide-gamut display?
My family prefer to watch videos on the 10 year old 20" sRGB LCD that I have flipped into portrait. The reason is simple: colors look horrible on my wide-gamut display unless you do something active about it.
The solution seems to be that:
1. Dell & friends should work to automatically document the native color response of their displays (via EDID, a CD in the box, or downloadable driver). I am not talking about the (hopefully) moderate changes as the backlight wears, or across batches of displays, I am talking about the bulk difference that makes watching sRGB content painful.
2. Microsoft/Apple/friends should work to make their OS look good for both color-aware and color-unaware software/hardware/users. If a video player application cannot interpret color information, then the OS should try to switch the monitor into sRGB emulation mode, or inject a color-management layer between the application rendering and the display.
-h
-
If they just put a sticker on the screen it would go a long way:
Warning: This unit must be used with fully color managed software to operate as intended. Full calibration and profiling is required.
But then they would have to remove all the "High Definition" and "10 000 : 1 Dynamic Contrast Ratio" stickers, and they might not want to do that...
For web the solution is very simple: Firefox with color management set to mode 1. This works pretty much like the working space in Photoshop, so that the color management chain is always on. There's nothing stopping Microsoft and Apple from doing something similar across the board, but for some strange reason they just won't.
-
For web the solution is very simple: Firefox with color management set to mode 1.
Agreed. But even in Firefox, it's not the default - you have to set explicitly Gfx.color_management.mode to 1.
On the web, most graphic elements do not have embedded profiles. That's reasonable: apart from photos most graphic elements are tiny, and an embedded profile of a few kb would be a significant size overhead. But probably at least 99.99% of web graphics are sRGB (or intended to be displayed as sRGB). So why don't browsers all take a wild guess and assume untagged, unprofiled graphic elements are sRGB?
But all browsers (even Firefox by default) refuse even to guess the colour space might sRGB (which would virtually always be right), and simply turn off colour management for images or graphic elements with no profiles. It's completely insane.
Why do people smart enough to implement colour management make such a bizarrely stupid decision? The only credible reason I've heard is that older Flash is not colour managed, and there might be a colour discontinuity between some Flash elements and surrounding html elements. That's like saying "because some small proportion of colour is wrong, I want it all to be wrong."
All browsers should assume graphic elements without profiles are sRGB, with perhaps an option to turn that behaviour off for people with a particular fascination for seeing the wrong colour (e.g. those that like all colours to be as bad as Flash colours).
-
2. Microsoft/Apple/friends should work to make their OS look good for both color-aware and color-unaware software/hardware/users. If a video player application cannot interpret color information, then the OS should try to switch the monitor into sRGB emulation mode, or inject a color-management layer between the application rendering and the display.
While that's possible, it goes against the whole Microsoft color management policy, which is to leave CM strictly to the application. Windows never gets in the way of application CM.
Personally I think that's a very healthy policy in terms of overall reliability, low bug risk, easy troubleshooting and so on. But it obviously prevents OS-level management.
Apple could probably do it through ColorSync, I'm not really familiar with its under-the-hood workings.
-
While that's possible [OS-level colour management], it goes against the whole Microsoft color management policy, which is to leave CM strictly to the application. Windows never gets in the way of application CM.
Personally I think that's a very healthy policy in terms of overall reliability, low bug risk, easy troubleshooting and so on. But it obviously prevents OS-level management.
I agree. I think it would be difficult for the OS to work out how to do colour management on existing screen-writing APIs. For example, the OS can find out the profile of the monitor (if there is one) but usually doesn't know the colour space of the data being written to the monitor. It could guess sRGB, but that would screw colour-managed applications (or those that don't use WCS, anyway). There would be all sorts of circumstances where the OS might wrongly guess what to do. I think it would probably be impossible to do without causing all sorts of problems.
Apple could probably do it through ColorSync, I'm not really familiar with its under-the-hood workings.
Nor me!
-
I agree. I think it would be difficult for the OS to work out how to do colour management on existing screen-writing APIs. For example, the OS can find out the profile of the monitor (if there is one) but usually doesn't know the colour space of the data being written to the monitor. It could guess sRGB, but that would screw colour-managed applications (or those that don't use WCS, anyway). There would be all sorts of circumstances where the OS might wrongly guess what to do. I think it would probably be impossible to do without causing all sorts of problems.
Is it any harder than Apples approach to retina displays? Legacy APIs are hard-wired to a virtual low-rez display, and the OS will silently upscale content to the physical resolution. A new API is offered to those interested in accessing the full capabilities of the monitor.
Adobe & Co would have to make some adjustements (best-case: flip a bit "declaring that they know what they do", then recompile). All legacy applications would be sandboxed in the sRGB assumption (that is pretty much the standard outside of pro/enthusiast photography anyways).
There might be some problems with applications that access display hardware at a really low level (below what the OS is willing to mess with). So applications that are color-unaware and write directly to GPU buffers might be rendered (erroneously) at full native display gamut.
There is a question of what the OS ought to to if there is a color-unaware video player showing e.g. youtube content in one window, a color-aware photo editing application in another window, and the display is reporting two calibrated presets: 1)sRGB, 2)Wide-gamut. Should it inject sRGB->Wide-gamut conversion for the video window, use the accurate sRGB-mode of the display, or what? The easiest way out of such issues may be to only change behaviour for fullscreen applications.
I myself would probably be happy if display presets could be selected from the OS (using USB, EDID, whatever), and the OS allowed me to select which display preset should be selected depending on what application was highlighted. Then I could ensure that native wide-gamut was always used when I was using Lightroom, and sRGB emulation always otherwise. My family members would probably rejoice.
-h
-
One would hope, a consumer looking for a wide gamut display and willing to pay for it would have a clue about color management. Same is true for people buying non wide gamut displays. And these better units have an sRGB emulation that works pretty darn well. And as pointed out, the issue isn't the wide gamut displays, it's the lack of color management. And, suppose that indeed 90% of the world switches to wide gamut displays today, we simply remove the silly "sRGB is the answer" for non color managed work and substitute Adobe RGB (1998). Not a great solution but it does illustrate how sRGB become what it is today and how it may go the way of the dodo bird in the future. My PA272 isn't producing Adobe RGB (1998) but an untagged image in that color space in a non ICC aware app looks OK. Just as an sRGB image would look OK on an sRGB like device. Not a match to an ICC aware app, this kind of viewing has always been a bit iffy at best. Hopefully the growth of wide gamut displays will encourage the right fix here, produce products that handle images to understand ICC color management, allow the user to select what the system does when it finds untagged data (we had that back on OS9, why Apple removed it I'll never understand). If not OS level, application level (mainly browsers).
-
"...the issue isn't the wide gamut displays, it's the lack of color management." The issue isn't going to go away it seems. Many websites strip the tagged profiles from photos. Also, Adobe Flash is still very prevalent for displaying photos, and no one activates color management with that, if it is really even possible.
-
"...the issue isn't the wide gamut displays, it's the lack of color management." The issue isn't going to go away it seems. Many websites strip the tagged profiles from photos. Also, Adobe Flash is still very prevalent for displaying photos, and no one activates color management with that, if it is really even possible.
That's why there is an sRGB emulation mode. Flash IS a mess. Some versions apparently do support some color management but best to just stay away from Flash if color is important. Even if a site strips a profile, there is still EXIF data that defines the color space, why can't that be detected and used?
-
One would hope, a consumer looking for a wide gamut display and willing to pay for it would have a clue about color management. Same is true for people buying non wide gamut displays. And these better units have an sRGB emulation that works pretty darn well. And as pointed out, the issue isn't the wide gamut displays, it's the lack of color management.
Well I'm one of those who spent the money for a wide gamut, photo-edit centered monitor PA242W along with a Spectraview II calibrator. You've helped explain some things to me about color management. I'm still very confused but slowly learning.
Sometimes you buy a better product, whatever it is, hoping to get the most from it. But that takes time. How many people actually read the 400 pages of instructions that comes with some digital cameras today? Don't give up on us. :) Then again some people never figured how to get rid of the flashing 12:00 time display on the front of their VHS video recorders.
-
That's why there is an sRGB emulation mode. Flash IS a mess. Some versions apparently do support some color management but best to just stay away from Flash if color is important. Even if a site strips a profile, there is still EXIF data that defines the color space, why can't that be detected and used?
Actually, it is my understanding that many sites strip all exif data too, even though that is technically illegal if it contains a copyright notice.
-
Actually, it is my understanding that many sites strip all exif data too, even though that is technically illegal if it contains a copyright notice.
Such a site clearly doesn't care how it's audience views the images. And that's their right.
-
the issue isn't the wide gamut displays, it's the lack of color management.
I think this is a very important and very undercommunicated point. People complain all over that color management is "a mess". In reality, color management is the solution to all these problems. The mess starts when color management stops.
An academic point you might say, but perception is everything. The perceived unpredictability is what drives people up against the wall. Once you see that it is in fact entirely predictable - if you just turn around and look at it from the opposite angle - it stops being a "problem" and becomes something you can deal with.
Color management isn't complicated or difficult at all, as long as it's there. The complexities of it is just a myth that should be put to death the sooner the better.
-
I think this is a very important and very undercommunicated point. People complain all over that color management is "a mess". In reality, color management is the solution to all these problems. The mess starts when color management stops.
An academic point you might say, but perception is everything. The perceived unpredictability is what drives people up against the wall. Once you see that it is in fact entirely predictable - if you just turn around and look at it from the opposite angle - it stops being a "problem" and becomes something you can deal with.
Color management isn't complicated or difficult at all, as long as it's there. The complexities of it is just a myth that should be put to death the sooner the better.
There is a lot of wisdom in this.
Tony Jay
-
Is it any harder than Apples approach to retina displays? Legacy APIs are hard-wired to a virtual low-rez display, and the OS will silently upscale content to the physical resolution. A new API is offered to those interested in accessing the full capabilities of the monitor.
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.
Adobe & Co would have to make some adjustements (best-case: flip a bit "declaring that they know what they do", then recompile). All legacy applications would be sandboxed in the sRGB assumption (that is pretty much the standard outside of pro/enthusiast photography anyways).
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.
And "All legacy applications would be sandboxed in the sRGB assumption" probably wouldn't work for several reasons. The most important: you can't assume that "legacy" applications don't do colour management. Some will be using WCS (Windows Color System); Windows could probably detect that and not do any further mapping. 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.
The issue is: for "legacy" applications (i.e. all applications up to now), there's usually no way Windows can know the colour space of graphic information, or even whether it's a photo.
There might be some problems with applications that access display hardware at a really low level (below what the OS is willing to mess with). So applications that are color-unaware and write directly to GPU buffers might be rendered (erroneously) at full native display gamut.
And that's another problem: typically games and video players may bypass Windows - but not necessarily for all display material. So you'd have information where Windows is trying to second-guess the colour, and mapping it, side-by-side with information that it can't map. For example, what should look like a continuous red bar might be two different shades of red, part re-mapped by Windows and part not.
There is a question of what the OS ought to to if there is a color-unaware video player showing e.g. youtube content in one window, a color-aware photo editing application in another window, and the display is reporting two calibrated presets: 1)sRGB, 2)Wide-gamut. Should it inject sRGB->Wide-gamut conversion for the video window, use the accurate sRGB-mode of the display, or what? The easiest way out of such issues may be to only change behaviour for fullscreen applications.
I myself would probably be happy if display presets could be selected from the OS (using USB, EDID, whatever), and the OS allowed me to select which display preset should be selected depending on what application was highlighted. Then I could ensure that native wide-gamut was always used when I was using Lightroom, and sRGB emulation always otherwise. My family members would probably rejoice.
-h
The problem is that Windows just doesn't know what's colour managed and what isn't, and doesn't know the colour space of information being written to the screen.
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.
Edited to add: The problem is simpler for browsers, as untagged elements (without an embedded profile) are nearly always sRGB. Anything that isn't sRGB will almost invariably have an embedded profile. Windows, however, usually has no idea of the colour space of stuff written to the monitor.
-
A lot of websites seem to strip the tagged color profiles from images. This didn't matter quite as much in the past because it was very unlikely that the average viewer had a wide gamut monitor (not that some color and contrast distortion can't be seen with an sRGB only monitor). However, the current Apple Cinema monitor has a wide gamut, and while probably not mainstream in most areas at this point, it may be getting more common in more well heeled areas. I am wondering how common wide gamut monitors are at this point. Other than the Cinema display, are there any other wide gamut monitors currently being marketed to mainstream consumers?
If you use Firefox you can tell it to apply sRGB profile to any untagged images or elements. Or if you must use a different browser, then you pop the display into sRGB emulation mode (most wide gamut screens that are not really old have these and on the best wide gamut monitors they actually deliver sRGB better than 99% of regular gamut monitors do).
I don't believe any Apple displays offer wide gamut.
At least some of the current Dell Ultrasharp monitors are now wide gamut, but are average consumers even considering these?
I think they are for sure. For a while almost any good IPS gamut monitor had been wide gamut. Although there are some good regular gamut ones again.
-
All browsers should assume graphic elements without profiles are sRGB, with perhaps an option to turn that behaviour off for people with a particular fascination for seeing the wrong colour (e.g. those that like all colours to be as bad as Flash colours).
exactly, i mean what else would an untagged image be but sRGB?? and if it's not it can't be displayed correctly anyway (at least not without a lot of trial and error) since you have no clue what gamut it is and what the tone response are, it's basically just a mistake)
-
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
-
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.
-
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.
-
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).
-
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
-
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
-
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.
-
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