Views
773
Replies
14
Status
Closed
Just used a "Spyder2" on my monitor. At the end of the guided process, it shows the "PDI Test Image" and lets you toggle between "color managed" and "not color managed". In "color managed" some yellows and reds are dramatically more intense. They don’t explain why, but it makes you think you’ve accomplished something.
The Microsoft Color Control Panel Applet for Windows XP says the profile the Spyder made contains a gamut table. By using its Devices tab, selecting Displays, and highlighting either the new profile or the display vendor’s default profile (or sRGB), then clicking Set As Default and then Apply, I can switch between them "on the fly". Very little changes. The gamut viewer shows the new profile with a bit less green and blue range, but about the same shape as the default.
(I found several web sources saying one couldn’t do this, at least not without restarting Windows, but try it with a radical profile and you will easily see that the video LUT is changed when you click Apply, and displays from both color managed and non color managed applications are affected identically.)
So the dramatic boost in reds and yellows was not due to the graphics lookup table. Displaying the PDI Test Image side-by-side in (non-color managed viewer) ImageEye and in Photoshop, if I choose to soft proof to "Monitor RGB" the colors are identical. Turn off the Proof Colors option and the Photoshop yellows jump up like they did in the Spyder app. I was never clear what the "Monitor RGB" soft proof was supposed to do – looks like it simply shows you what your image will look like in non color managed apps on your system.
I can also toggle the reds and yellows up and down by viewing the image without proofing in Photoshop, choosing to assign the new monitor profile to the image, and toggling Preview on and off. With the monitor profile assigned to the image, it shows the pale, non-color managed yellows. With Preview off, the yellows jump up. If "Proof Colors" (to "Monitor RGB") is selected, assigning the monitor profile to the image makes no difference.
Apparently the issue here is that Spyder’s PDI Test Image is tagged with AdobeRGB, and looks pale when viewed in Windows’ default sRGB unless it is properly color managed. By using a test image that is not in the native color space, the Spyder2 program shows you the benefit of interpreting the image in its proper color space, not particularly the benefit you just gained by using the spyder hardware.
If I open a completely untagged version of the familiar test image "parrots" into my AdobeRGB default space, and tell Photoshop "don’t color manage", what should be bright yellows (and reds!) match ImageEye with RGB#/Monitor proofing on, and jump way up with Proof Colors disabled.
Aha! Assigning my default AdobeRGB profile while opening parrots gives me the same results as "don’t color manage"! Bright reds and yellows with Proof Colors off. So the same file values interpreted as AdobeRGB _are_ a brighter red/yellow than if they are taken as sRGB…
Assigning sRGB (to numbers that presumably are already sRGB) while opening gives me reds that match ImageEye with Proof Colors on, and very slightly less saturated reds (215 vs 219) with RGB*/Monitor proofing off. I see no difference in "parrots" when swapping between the Spyder profile and stock sRGB at the Windows color control panel, so I wonder what Photoshop is trying to soft proof for me here? Is that maybe the difference between my particular Monitor RGB and the "Windows RGB" choice?
There is one more option – assign sRGB and then convert to AdobeRGB. Now the images match with Proof Colors off, and the RGB/Monitor proofed reds are dramatically darker than ImageEye’s. I understand the images matching – both programs took the image numbers as sRGB values, and Photoshop converted them to look the same as that in its working AdobeRGB space. When I save the parrots with the AdobeRGB tag, ImageEye shows that file with the same darker reds as the Photoshop soft proof.
Of all the questions I was going to ask when I started writing this, only two remain. One is asked above. If I tell PS that sRGB numbers already are AdobeRGB, the reds get dramatically brighter. If I tell it to convert the sRGB to AdobeRGB, and then proof it as it would be shown by an app that assumed sRGB, the reds get dramatically darker. Makes sense. But if I tell PS that sRGB numbers _are_ sRGB, they only match non-color managed sRGB with proofing to Monitor RGB on. Why are they slightly darker or less saturated with proofing off? Not nearly the difference of interpreting them in the wrong color space, but still different.
The other question is why would they call an option "Don’t color manage" when it seems like it should be called "Pretend what you open is already in your PS default space"? When saving an image, the obvious "Don’t color manage" behavior is "don’t add a profile", which leaves the image in the system default space. On opening a file I originally expected "Don’t color manage" would do the reverse – assume all files are in the Windows default sRGB space. Does Photoshop’s behavior maybe make more sense on Macs?
Hoping I’ve begun to understand all this,
Loren
The Microsoft Color Control Panel Applet for Windows XP says the profile the Spyder made contains a gamut table. By using its Devices tab, selecting Displays, and highlighting either the new profile or the display vendor’s default profile (or sRGB), then clicking Set As Default and then Apply, I can switch between them "on the fly". Very little changes. The gamut viewer shows the new profile with a bit less green and blue range, but about the same shape as the default.
(I found several web sources saying one couldn’t do this, at least not without restarting Windows, but try it with a radical profile and you will easily see that the video LUT is changed when you click Apply, and displays from both color managed and non color managed applications are affected identically.)
So the dramatic boost in reds and yellows was not due to the graphics lookup table. Displaying the PDI Test Image side-by-side in (non-color managed viewer) ImageEye and in Photoshop, if I choose to soft proof to "Monitor RGB" the colors are identical. Turn off the Proof Colors option and the Photoshop yellows jump up like they did in the Spyder app. I was never clear what the "Monitor RGB" soft proof was supposed to do – looks like it simply shows you what your image will look like in non color managed apps on your system.
I can also toggle the reds and yellows up and down by viewing the image without proofing in Photoshop, choosing to assign the new monitor profile to the image, and toggling Preview on and off. With the monitor profile assigned to the image, it shows the pale, non-color managed yellows. With Preview off, the yellows jump up. If "Proof Colors" (to "Monitor RGB") is selected, assigning the monitor profile to the image makes no difference.
Apparently the issue here is that Spyder’s PDI Test Image is tagged with AdobeRGB, and looks pale when viewed in Windows’ default sRGB unless it is properly color managed. By using a test image that is not in the native color space, the Spyder2 program shows you the benefit of interpreting the image in its proper color space, not particularly the benefit you just gained by using the spyder hardware.
If I open a completely untagged version of the familiar test image "parrots" into my AdobeRGB default space, and tell Photoshop "don’t color manage", what should be bright yellows (and reds!) match ImageEye with RGB#/Monitor proofing on, and jump way up with Proof Colors disabled.
Aha! Assigning my default AdobeRGB profile while opening parrots gives me the same results as "don’t color manage"! Bright reds and yellows with Proof Colors off. So the same file values interpreted as AdobeRGB _are_ a brighter red/yellow than if they are taken as sRGB…
Assigning sRGB (to numbers that presumably are already sRGB) while opening gives me reds that match ImageEye with Proof Colors on, and very slightly less saturated reds (215 vs 219) with RGB*/Monitor proofing off. I see no difference in "parrots" when swapping between the Spyder profile and stock sRGB at the Windows color control panel, so I wonder what Photoshop is trying to soft proof for me here? Is that maybe the difference between my particular Monitor RGB and the "Windows RGB" choice?
There is one more option – assign sRGB and then convert to AdobeRGB. Now the images match with Proof Colors off, and the RGB/Monitor proofed reds are dramatically darker than ImageEye’s. I understand the images matching – both programs took the image numbers as sRGB values, and Photoshop converted them to look the same as that in its working AdobeRGB space. When I save the parrots with the AdobeRGB tag, ImageEye shows that file with the same darker reds as the Photoshop soft proof.
Of all the questions I was going to ask when I started writing this, only two remain. One is asked above. If I tell PS that sRGB numbers already are AdobeRGB, the reds get dramatically brighter. If I tell it to convert the sRGB to AdobeRGB, and then proof it as it would be shown by an app that assumed sRGB, the reds get dramatically darker. Makes sense. But if I tell PS that sRGB numbers _are_ sRGB, they only match non-color managed sRGB with proofing to Monitor RGB on. Why are they slightly darker or less saturated with proofing off? Not nearly the difference of interpreting them in the wrong color space, but still different.
The other question is why would they call an option "Don’t color manage" when it seems like it should be called "Pretend what you open is already in your PS default space"? When saving an image, the obvious "Don’t color manage" behavior is "don’t add a profile", which leaves the image in the system default space. On opening a file I originally expected "Don’t color manage" would do the reverse – assume all files are in the Windows default sRGB space. Does Photoshop’s behavior maybe make more sense on Macs?
Hoping I’ve begun to understand all this,
Loren
MacBook Pro 16” Mockups 🔥
– in 4 materials (clay versions included)
– 12 scenes
– 48 MacBook Pro 16″ mockups
– 6000 x 4500 px