Ad
Ad
Ad
Pages: « 1 ... 3 4 [5]   Bottom of Page
Print
Author Topic: What's the point of using color spaces exceeding the visible spectrum?  (Read 12249 times)
Coloreason
Jr. Member
**
Offline Offline

Posts: 58


« Reply #80 on: October 10, 2011, 11:44:25 AM »
ReplyReply

...
Not necessarily...
Yep, I know that. The question was "is it possible", in the context we were talking. So, it is, and I never thought otherwise but just wanted to confirm.
The thing that is confusing me is why this can work but not the other way around. If a monitor profile is telling only part of the truth how come it can tell the complete truth in this situation.

Or my confusion said in other words:
because of this: "You are on system A using display A. Display profile from System B is useless in showing you what the user saw on that system (B)."
then I don't understand why the monitor profile attached to an image can work in another situation when that vcgt tag is always disregarded.
« Last Edit: October 10, 2011, 11:57:28 AM by Coloreason » Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9192



WWW
« Reply #81 on: October 10, 2011, 01:25:51 PM »
ReplyReply

Lets try it this way. You are on a machine with a display that is calibrated and has a profile that defines that condition. You work in a non color managed app. The numbers are sent directly to the display (there is no understanding in this app of the color space, defined by a profile. There is no understanding of the display profile, its a non color managed app). This is how Photoshop worked prior to version 5. Your display was your editing space. What you see is what you get in this app, on this display (numbers sent to the display).

You move this document into Photoshop or other ICC aware application. Those applications need to understand two things. One is the color space of the numbers. Numbers without a color space are ambiguous. The appearance is based on the description of the numbers. That's why when you Assign a profile, you see the color appearance change but the numbers do not. The ICC aware application also needs to understand the display profile. With the working space (color space of associated numbers), and display profile, you can view the numbers correctly.

You have an untagged document from the 3D app. You assign the display profile in Photoshop to maintain the color appearance. Why? Because Photoshop now knows the scale of the numbers (display profile) AND uses the display profile to properly those numbers.

If you are on a system, with a calibrated display, that profile is unique to that system. It can't be transferred to another system, that system has its own display, graphic system, and profile. By assigning the display profile on the original system, the color appearance is maintained and then it be wise to convert to a well behaved working space like sRGB. You can provide that document to other ICC aware apps, on differing systems, those systems have their own display profile (not the original). The original display profile is only useful on the machine that made the document in the non color managed app.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Tim Lookingbill
Sr. Member
****
Offline Offline

Posts: 1210



WWW
« Reply #82 on: October 10, 2011, 01:34:25 PM »
ReplyReply

Quote
...then I don't understand why the monitor profile attached to an image can work in another situation when that vcgt tag is always disregarded.

By attached do you mean embedded, assign or converted to and embedded in the image? All of that can happen to an image regardless if it's sRGB/AdobeRGB/ProPhotoRGB and Monitor profile.

When you assign a display profile with vcgt curves to an image...(not sure if Windows systems yet attach vcgt to display profiles, it loads it at system startup, Macs do)...it changes the preview of the image to reflect all the bumps, hills and valleys seen in the RGB curves demonstrated above that corrects for the nonlinearity/nonuniform appearance of the display at the time of calibration/profiling of the other display. The current display proofing the image by assigning this other display profile to the image doesn't have the same bumps, hills and valleys in its RGB curves.

Some vcgt curves can be quite different display to display. See below:

http://photo.net/bboard-uploads//00HMf8-31289584.jpg

Logged
MarkM
Sr. Member
****
Offline Offline

Posts: 335



WWW
« Reply #83 on: October 10, 2011, 09:18:40 PM »
ReplyReply

When you assign a display profile with vcgt curves to an image...it changes the preview of the image to reflect all the bumps, hills and valleys seen in the RGB curves demonstrated above that corrects for the nonlinearity/nonuniform appearance of the display at the time of calibration/profiling of the other display.

I don't think that's true. The vcgt curves can be embedded in a profile, but they are not part of the icc spec and they are generally disregarded in icc workflows. The only time I see them used is when I set a new profile for a monitor on the system level (Mac OSX). In that case the system reads the vcgt data from the profile and uploads it to the video card. After that they're forgotten about and I think photoshop rightly ignores them.

I've thought a bit about this over the last couple days and think I was wrong in my previous post (with some caveats) and think that colorreason's idea is not as far off the mark as we may think.

Consider this:

1. You have a sRGB image that is tagged and you are working in a profiled/calibrated environment. You send it to me, also in a calibrated environment. We can be pretty confident that we are seeing the same color appearance. Right? That's the point of color management—everyone is calibrated to a known standard and the image is tagged. We're good—this is the way it's supposed to work.

2. You convert that sRGB image to your monitor profile and send it to me. This is the same scenario as no. 1. The monitor profile might be different, but it is still a color profile built around a know standard. I can still convert from it to PCS, sRGB, or anything else. We'll still agree on a color framework.

3. You convert the sRGB image to your monitor profile and send it to me untagged, but with a copy of the monitor profile. I then apply the monitor profile and we are identical to No. 2.

4. You have untagged RGB data from a non-color-managed application on your profiled system. You can apply your monitor profile in a color managed app like photoshop without changing the color. You send this to me with your monitor profile. I also can apply your profile and we are back at No.3, which is the same as No. 2. Assuming your monitor profile accurately describes your monitor, I can apply the profile and we'll be speaking about the same color. This means that I can get a decent idea about what color looks like on your monitor in your non-color-aware apps with the caveats given below.

5. What you can't do: unplug your monitor and plug it into m video card using your profile. Unless my system behaves identically, we'll need to recalibrate and built a new profile.

Caveat: There will be some differences. We might have gamut issues—you might have a wide gamut monit that I clearly can't simulate on a normal monitor. I might be calibrated to a different white point and luminosity so the absolute colorimetric date may be different. Monitors next to each other may look different and may give different readings to a measurement device. But assuming that we account for what out eyes do with chromatic adaptation and such, we can be confident that the color appearance will be in the ballpark. Just because you are at 6500K and I'm at 5500K doesn't mean we can't agree on color.

The video card, vcgt problem is not as much of an issues as we might think because the profiles for the monitor are created after the vcgt has been uploaded to the card. We can think of the video card/monitor as one thing that we are profiling so long as we don't change them.

I've attached an unusual profile for an unusual monitor. You should be able to apply it to images and see what I'm seeing on this non-standard monitor.
« Last Edit: October 10, 2011, 09:40:09 PM by MarkM » Logged

Tim Lookingbill
Sr. Member
****
Offline Offline

Posts: 1210



WWW
« Reply #84 on: October 11, 2011, 03:27:34 AM »
ReplyReply

Quote
I don't think that's true. The vcgt curves can be embedded in a profile, but they are not part of the icc spec and they are generally disregarded in icc workflows. The only time I see them used is when I set a new profile for a monitor on the system level (Mac OSX). In that case the system reads the vcgt data from the profile and uploads it to the video card. After that they're forgotten about and I think photoshop rightly ignores them.

You're right, Mark. Brain fart!

I got all turned around trying to understand exactly Coloreason's points. This has been brought up several times I've been in discussions on this subject going back years and it never works.

I was cross remembering what happens when you load a custom display profile with vcgt curves from another display into the system not meant for that display which YOU DO see how off those vcgt curves makes the display.

There's still the issue with gamut shape matrice differences between the display your emulating by assigning that profile to the image and the color space the image is written and saved in such as  sRGB, AdobeRGB, etc. You'ld have to convert the image to the actual display being emulated but then you now can't assign that display in a Soft Proofing session.

I assigned your profile to the PDI color target and it turns it B&W. Neat trick. I understand your points but it seems to defeat the purpose of color management from an efficiency aspect. IOW it's too much of a PITA.
« Last Edit: October 11, 2011, 03:39:54 AM by tlooknbill » Logged
Coloreason
Jr. Member
**
Offline Offline

Posts: 58


« Reply #85 on: October 13, 2011, 09:32:14 AM »
ReplyReply

... the profiles for the monitor are created after the vcgt has been uploaded to the card. ...
That's the key here. This is how I always thought it works until people here started to mention the vcgt tag in relation to my workflow which made me think that this is not how it works. I thought that people mentioning vcgt tag are telling me that the profile is created before the calibration contribution of the video card (if talking about something else, I still have no idea what they were trying to tell me). If a monitor profile assigned to an image describes how colors will be displayed after adding a particular video card effect to a display (and not simply describing how a monitor displays colors)  then sending untagged image and a monitor profile to be assigned using another system should not work but I know for sure that this does work and everyone also agreed that works. Then if that works this means that the monitor profiles are created after the video card contribution to the calibration. And if this is the case then assigning the monitor profile to any image using a different system should show how the monitor for which the profile was created for will display the colors provided a wider gamut is used for the simulation.
...
Caveat: There will be some differences. We might have gamut issues—you might have a wide gamut monit that I clearly can't simulate on a normal monitor. I might be calibrated to a different white point and luminosity so the absolute colorimetric date may be different. Monitors next to each other may look different and may give different readings to a measurement device. But assuming that we account for what out eyes do with chromatic adaptation and such, we can be confident that the color appearance will be in the ballpark. Just because you are at 6500K and I'm at 5500K doesn't mean we can't agree on color...
The white point and luminosity will be taken into account and translated properly in the monitor simulation with assigning the profile to an image. If these are not translated properly then again, assigning a received monitor profile to received untagged image will not simulate the intended colors properly too and that's not the case as everyone agrees.
The practical limitation to this workflow is that because you want to soft proof the assignment (preserve RGB numbers) and not the conversion to the simulated monitor, the proofing monitor must be with wider gamut, otherwise this won't work - we tried that in our studio with soft proofing a standard gamut monitor using another standard gamut monitor and the result wasn't good.
Logged
MarkM
Sr. Member
****
Offline Offline

Posts: 335



WWW
« Reply #86 on: October 13, 2011, 01:27:48 PM »
ReplyReply

The white point and luminosity will be taken into account and translated properly in the monitor simulation with assigning the profile to an image. If these are not translated properly then again, assigning a received monitor profile to received untagged image will not simulate the intended colors properly too and that's not the case as everyone agrees.

You should test this on two monitors with different white points.

This is how I understand it.

The white point should be all primaries at 100% -> [255, 255, 255]. If I send this to the monitor it should produce a color that corresponds to the the monitor's white point. If I assign a different monitor profile, even one with a different white point, the numbers are still [255, 255, 255]. When sent to the display, this color is then converted to my display via a relative colorimetric conversion, which means the white point is converted to the white point of the displaying monitor. Hence even if I assign a 5000K profile on my 6500K monitor, I will still see a 6500K white point. This is how is should be—color appearances are preserved even though absolute colorimetric data is not. If you are looking at both monitors at the same time you will see different whites. But in most other cases, because your eyes will adapt to the different white point, it should look the same.

If it didn't work this way, you would see a white point shift when assigning a ProPhotoRGB(D50) profile to an AdobeRGB(D65) image, but you don't. The only way I know of to get a white point shift is to convert using absolute colorimetric intent and Apple's CMM engine.
Logged

Coloreason
Jr. Member
**
Offline Offline

Posts: 58


« Reply #87 on: October 14, 2011, 01:18:51 AM »
ReplyReply

MarkM, I made some test by creating creating custom profiles with very different color temperature and primaries and what you said is completely correct, the different white points are mapped to the same appearance but it doesn't seem to be a big problem which initially made me think it is actually simulating the different white points.
I'm on Windows system which works similar to Adobe's and can't use Apple's engine.
Out of curiosity I tried assigning some of the others available RGB profiles that come with Photoshop and some of them like Fujifilm  3510 (RDI) Theater Preview (by Adobe) did change the white point. I guess it is some instructions in the profile that make absolute matching.

Thank you for your input, very much appreciated.
Logged
Sheldon8
Newbie
*
Offline Offline

Posts: 1


« Reply #88 on: October 14, 2011, 02:57:51 AM »
ReplyReply

i would say to hold the colors.
Logged
Pages: « 1 ... 3 4 [5]   Top of Page
Print
Jump to:  

Ad
Ad
Ad