Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: gongtrip on December 30, 2010, 10:53:30 pm
-
Ok so I understand the fundamental differences of srgb, adobe rgb and prophoto rgb and I understand that working in adobe rgb or prophoto rgb theoretically gives you a wider color gamut to work with or in the case of prophoto also a greater bit depth, but what I don't understand is why would you do this if your monitor can only display the srgb gamut? If you can't see the wider spectrum of these color spaces what is the point of using them. Frankly, making adjustments to an image that I can't necessarily see would make me a little nervous. What am I missing here?
I guess the one situation I can undersand is if you are doing extremely intensive effects work and want to use the greater bit depth of prophoto to minimize possible color artifacts but beyond that are these color spaces really a benefit?
Say a printer can print the entire adobe rgb gamut, again what is the point of working in this space unless you own a specialized monitor that can display the entire rgb gamut? In effect, wouldn't your srgb monitor just be clipping the most saturated colors such that you don't really know how colors beyond the srgb gamut limit will look in the final print?
Another thought, since adobe rgb is also an 8 bit space like srgb, but has a wider gamut, the discreet steps between color values would be less discreet would they not? So it seems to me that working in this space would gain you a greater range of super saturated colors but would be at the expense of losing some amount of subtlety in the overall tonal values. Am I envisioning this correctly?
-
Answered you on the Adobe Forums...as did other people. You might want to ask a question on one forum and wait for an answer before broadcasting your question to multiple forums. And no, you DON'T "understand the fundamental differences of srgb, adobe rgb and prophoto rgb"...read up and get back to us.
-
Indeed, I posted this question in a couple of other forums--I like to adopt strategies geared towards absorbing information as quickly as possible...
Thanks, to yours an others' responses the threads contain some very useful insights. I've included hyper-links below for posterity's sake.
http://forums.adobe.com/thread/771605 (http://forums.adobe.com/thread/771605)
http://forums.dpreview.com/forums/readflat.asp?forum=1006&message=37331953 (http://forums.dpreview.com/forums/readflat.asp?forum=1006&message=37331953)
-
Indeed, I posted this question in a couple of other forums--I like to adopt strategies geared towards absorbing information as quickly as possible...
I suppose that's nice for you, but have you considered reasons why many people can't be bothered answering forum posts?
Allow me to tell you what rubbed me the wrong way with your post:
"Re: attention color whizes: xxxxxxxxxx"
a. Gratuitous and misspelled.
b. That which you claimed to know you didn't.
c. Your response portrays you as entirely thoughtless and self-serving.
Google is where one finds information to absorb. "People" are real live humans taking the time to answer your questions. They deserve respect and consideration. Their time is valuable.
I won't answer a forum post if:
a. The OP has a history of not doing a reasonable amount of research prior to posting. Often this 'history' can be determined in a single post.
b. If I get even a hint that instead of trying to understand, they're 'polling' as if taking a vote.
c. I'm not fond of gratuitous salutations, especially if not spelled correctly.
I could understand posting on multiple forums all at once if looking for a rare something or the other, or even trying to sell something. But to gather a bulk of information to 'absorb' when its apparent they haven't searched and read past threads, Googled the topic, or maybe even read their owners manuals.. is a tad boorish no?
-
Ok so I understand the fundamental differences of srgb, adobe rgb and prophoto rgb and I understand that working in adobe rgb or prophoto rgb theoretically gives you a wider color gamut to work with or in the case of prophoto also a greater bit depth, but what I don't understand is why would you do this if your monitor can only display the srgb gamut?
ProPhoto by itself does not have a greater bit depth (you want to be working in a wider depth as a working space gamut becomes larger). See:http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf
-
It does not seem like that Prophoto RGB is always wider than Adobe RGB. It seems that saturated colors around blue Adobe primary might clip in Prophoto RGB in standard specification of these spaces. For more information please see:
http://forums.dpreview.com/forums/read.asp?forum=1018&message=37330104
Joofa
-
You wrote: "It appears that when the third dimension is taken into account it is seen that the area near the saturated unit stimulus blue region of Adobe RGB requires more than unity stimulus from blue ProPhoto RGB primary, i.e., there might be colors that clip for unit stimulus blue primary of ProPhoto RGB but are within the unit stimulus of Adobe RGB."
Aside from the terminology being a bit, odd, the fact is you are talking about theoretical colors in the extreme blue region which prolly don't exist on earth and certainly won't be able to be captured on a digital camera...there ARE however plenty of REAL colors that a camera can capture that can't be contained in Adobe RGB and some like yellow and ocher can actually be printed on an Epson 9900 (and even the 3880).
The irony is that the opening illustration of the 2D plots is actually an image I created for an Adobe white paper. I see it's been appropriated and is now on Wikipedia? BTW, the gamut of the 2200 is WAY below the gamut of the Ultrachrome K3 with vivid magenta or the 10 color HDR ink set. Maybe I should update that...
-
Aside from the terminology being a bit, odd, the fact is you are talking about theoretical colors in the extreme blue region which prolly don't exist on earth and certainly won't be able to be captured on a digital camera...there ARE however plenty of REAL colors that a camera can capture that can't be contained in Adobe RGB and some like yellow and ocher can actually be printed on an Epson 9900 (and even the 3880).
The irony is that the opening illustration of the 2D plots is actually an image I created for an Adobe white paper. I see it's been appropriated and is now on Wikipedia? BTW, the gamut of the 2200 is WAY below the gamut of the Ultrachrome K3 with vivid magenta or the 10 color HDR ink set. Maybe I should update that...
Sorry for the terminology being a little confusing. It is certainly a pleasant surprise that the Wikipedia image was created by you actually.
You are right about Adobe RGB gamut falling short of some useful colors. My article is not claiming otherwise. It just points out that it appears with the standard specification of white points for Prophoto RGB and Adobe RGB some saturated Adobe blues might not have exact representation in Prophoto space. But, you do have a point that these blue color shades may not be practically observable after all. You have a vast experience in color science so I can buy that statement.
Sincerely,
Joofa
-
It does not seem like that Prophoto RGB is always wider than Adobe RGB. It seems that saturated colors around blue Adobe primary might clip in Prophoto RGB in standard specification of these spaces. For more information please see:
http://forums.dpreview.com/forums/read.asp?forum=1018&message=37330104
Joofa
Joofa,
I don't quite understand how you are applying chromatic adaption in your calculations. ?Bradford
For a concrete example, please give the extreme blue in aRGB that clips in ProPhotoRGB. Then we can use Bruce Lindbloom's CIE color calculator to check the results.
Regards,
Bill
-
Joofa,
I don't quite understand how you are applying chromatic adaption in your calculations. ?Bradford
For a concrete example, please give the extreme blue in aRGB that clips in ProPhotoRGB. Then we can use Bruce Lindbloom's CIE color calculator to check the results.
Regards,
Bill
Hi Bill,
Yes, it is Bradford in concept. I checked out the calculator on Bruce Lindbloom's site and played around a little. The Adobe blue primary with standard D65 white point has the XYZ coordinates, [0.188185 0.075274 0.991108], which using Lindbloom's calculator for conversion from D65 to D50 white point with Bradford transformation results in [0.149224 0.063220 0.744839]. You can use one of the matrices in Lindbloom's arsenal to convert this tristimulus value to Prophoto RGB with D50 white point and that results in [0.146617 0.029374 0.902605]. This situation corresponds to following case in my note:
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
The value of 0.902605 is close to 0.88 that I mentioned, and may be attributed to the fact that a direct calculation of Adobe RGB blue primary with D50 white point results in XYZ tristimulus of [0.137826 0.055130 0.725885] (compare Lindblom's [0.149224 0.063220 0.744839]).
EDIT: For the case (1) in my note you have to do some matrix manipulation. But the starting point will be the same Adobe D65 primary of XYZ = [0.188185 0.075274 0.991108].
Sincerely,
Joofa
-
Hi Bill,
Yes, it is Bradford in concept. I checked out the calculator on Bruce Lindbloom's site and played around a little. The Adobe blue primary with standard D65 white point has the XYZ coordinates, [0.188185 0.075274 0.991108], which using Lindbloom's calculator for conversion from D65 to D50 white point with Bradford transformation results in [0.149224 0.063220 0.744839]. You can use one of the matrices in Lindbloom's arsenal to convert this tristimulus value to Prophoto RGB with D50 white point and that results in [0.146617 0.029374 0.902605]. This situation corresponds to following case in my note:
The value of 0.902605 is close to 0.88 that I mentioned, and may be attributed to the fact that a direct calculation of Adobe RGB blue primary with D50 white point results in XYZ tristimulus of [0.137826 0.055130 0.725885] (compare Lindblom's [0.149224 0.063220 0.744839]).
EDIT: For the case (1) in my note you have to do some matrix manipulation. But the starting point will be the same Adobe D65 primary of XYZ = [0.188185 0.075274 0.991108].
Joofa,
Calculation of the primaries for various color spaces is an interesting exercise, but that was not the point of my original question. For simplicity and since I am not that familiar with color calculations, I prefer to do all the calculations within Lindbloom's calculator. One can start out with with a blank entry and select Adobe RGB with the most saturated possible blue (0, 0, 255) as shown in panel 1. One then calculate the XYZ values for this color as in Panel 2, change the RGB to ProPhotoRGB and calculate the Prophoto values for this XYZ.
0,0,255 in aRGB is 88.8, 35.9, 240.9 in ProPhotoRGB. My challenge is to find a saturated blue in aRGB which can not be represented in ProPhotoRGB. My intuition is that there is no such color.
Regards,
Bill
-
Joofa,
Calculation of the primaries for various color spaces is an interesting exercise, but that was not the point of my original question. For simplicity and since I am not that familiar with color calculations, I prefer to do all the calculations within Lindbloom's calculator. One can start out with with a blank entry and select Adobe RGB with the most saturated possible blue (0, 0, 255) as shown in panel 1. One then calculate the XYZ values for this color as in Panel 2, change the RGB to ProPhotoRGB and calculate the Prophoto values for this XYZ.
0,0,255 in aRGB is 88.8, 35.9, 240.9 in ProPhotoRGB. My challenge is to find a saturated blue in aRGB which can not be represented in ProPhotoRGB. My intuition is that there is no such color.
Regards,
Bill
Hi Bill,
I think you selected the D50 white point for Adobe RGB, where as the standard says to use D65. I used Lindbloom's calculator with [0 0 255] for Adobe RGB with D65 white point and got the XYZ = [0.188186 0.075274 0.991109]. Now I converted that to ProPhoto RGB with D50 white point on the calculator and it gave me [99.3813 37.2770 282.3180] for gamma = 1.8, or if you use gamma = 1.0 you get [46.76 8 306.2649]. The value of blue in both, i.e., 282 and 306 is greater than 255, and so will clip for 8 bit numbers. Incidently, 306/255=1.2 for linear calculation, and that is what I reported as case 1 in my note as shown below:
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
Sincerely,
Joofa
-
Hi Bill,
I think you selected the D50 white point for Adobe RGB, where as the standard says to use D65.
Sincerely,
Joofa
Joffa,
I don't think that I selected a D50 white point for Adobe RGB, since the calculator automatically and correctly uses a D65 white point for Adobe RGB. The D50 on the calculator refers to the white point of the reference (XYZ) space. When the RGB values of 0,0,255 in Adobe RGB are converted to ProPhotoRGB with the calculator, I get RGB values of 88.76, 35.93 and 240.89. As a check, I filled an AdobeRGB image with blue (0,0,255) in Photoshop and then converted to ProPhotoRGB and got 88, 36, 241.
I'm hardly a color expert and hope that Eric Chan or some other expert will clarify the issue. I just can't believe that a saturated blue in AdobeRGB can not be contained in ProPhotoRGB. I don't understand your calculations, but do note that the blue primary of ProPhotoRGB is imaginary--it lies outside the CIE L*a*b space.
Regards,
Bill
-
Joffa,
I don't think that I selected a D50 white point for Adobe RGB,
The gif attachment in your earlier message shows that you picked D50 for Adobe RGB. Please change that to D65 and you will get the numbers that I'm getting.
I get RGB values of 88.76, 35.93 and 240.89. As a check, I filled an AdobeRGB image with blue (0,0,255) in Photoshop and then converted to ProPhotoRGB and got 88, 36, 241.
The notion of "blue" in the Adobe RGB with D50 and D65 are different. Probably Photoshop is also doing the same track of calculation as you did above.
I just can't believe that a saturated blue in AdobeRGB can not be contained in ProPhotoRGB.
You can represent saturated Adobe RGB blues if the white point is D50 and you then go to ProPhoto with D50 white point. However, with the standard specification of D65 white point for Adobe RGB the resulting saturated blue is different than with D50 white point. And that blue color cannot be contained in ProPhoto primaries with standard D50 white point without using more than unity stimulus from blue Prophoto RGB. Incidently you can still represent that blue in the same ProPhoto primaries (same x,y chromacity numbers) if you change the ProPhoto white point from D50 to D65.
I don't understand your calculations,
This time I used Bruce Lindbloom's calculator in my calculations as shown in the above message.
but do note that the blue primary of ProPhotoRGB is imaginary--it lies outside the CIE L*a*b space.
Its okay to have imaginary primaries. All three XYZ primaries are imaginary as far as human vision is concerned.
Sincerely,
Joofa
-
The gif attachment in your earlier message shows that you picked D50 for Adobe RGB. Please change that to D65 and you will get the numbers that I'm getting.
Joofa
I don't think so. See the attached image with the spaces circled in yellow. Does Photoshop also make the same mistake? I've gone as far as my current knowledge permits in this discussion and will leave further comment to others. Anyway, it has been an interesting learning experience.
Regards,
Bill
-
I don't think so. See the attached image with the spaces circled in yellow. Does Photoshop also make the same mistake? I've gone as far as my current knowledge permits in this discussion and will leave further comment to others. Anyway, it has been an interesting learning experience.
Regards,
Bill
You have highlighted the incorrect parameter. See the drop-down above where you have circled. It clearly says D50. Please change that to D65 for this Adobe RGB. However, when you go to ProPhoto calculation change that back to D50.
Joofa
-
I don't think so.
Neither do I.
The WP of Adobe RGB (1998) is D65. Its as simple as that. If you try to define the space using D50, it ain’t Adobe RGB (1998) anymore. Go ahead and call it joofaRGB. <G>
-
Neither do I.
The WP of Adobe RGB (1998) is D65. Its as simple as that. If you try to define the space using D50, it ain’t Adobe RGB (1998) anymore. Go ahead and call it joofaRGB. <G>
Yeah, but Bill is using the D50 white point when he thought he used the D65 white point. Please see my message above.
Joofa
-
Yeah, but Bill is using the D50 white point when he thought he used the D65 white point. Please see my message above.
I think its still correct as you can see, he circled D65, which the calculator places automatically based on the correct WP for the working space selected. Notice it is again correct when he selected ProPhoto, the WP is now D50. The PCS WP should be set to D50, again as he’s selected (and on by default).
-
I think its still correct as you can see, he circled D65, which the calculator places automatically based on the correct WP for the working space selected. Notice it is again correct when he selected ProPhoto, the WP is now D50. The PCS WP should be set to D50, again as he’s selected (and on by default).
I don't think that what you are saying is correct. In the equations sections of Bruce Lindbloom's website he has clearly listed the following matrix for transformation from Adobe RGB (D65) to XYZ
0.5767309 0.1855540 0.1881852
0.2973769 0.6273491 0.0752741
0.0270343 0.0706872 0.9911085
See the last column, which is [0.1881852 0.0752741 0.9911085], and which are the XYZ for a saturated blue in Adobe RGB with D65 white point, and this is the same set of numbers which I have mentioned above you will get by selecting the D65 in the drop down menu, which Bill did not do in his calculation. Even if you ignore the calculator, this matrix, which Lindbloom has himself provided on the same website, clearly establishes that saturated blue in this system is [0.1881852 0.0752741 0.9911085] and not [0.149224 0.063220 0.744839] as Bill has mistakenly used in his calculation.
Joofa
-
In the equations sections of Bruce Lindbloom's website he has clearly listed the following matrix for transformation from Adobe RGB (D65) to XYZ
Yes, D65 WP to XYZ. Just as he shows ProPhoto and ColorMatch RGB as D50 to XYZ.
See the last column, which is [0.1881852 0.0752741 0.9911085], and which are the XYZ for a saturated blue in Adobe RGB with D65 white point, and this is the same set of numbers which I have mentioned above you will get by selecting the D65 in the drop down menu, which Bill did not do in his calculation.
I’m confused. Why would these values have anything to do with a saturated blue?
I’d send Bruce a email, go right to the source. He is quite accessible and will easily clear this up.
-
I’m confused. Why would these values have anything to do with a saturated blue?
Because, these are the numbers you would get by muliplying that matrix with [0, 0, 1], which is the vector for saturated blue (in any RGB system); [0,0,255] is just a scaling of this basic tristimulus value.
Joofa
-
Well again, I’d talk with Bruce, at least in terms of the use of the calculator you are using. The bottom line as far as I can see using any existing set of tools (ColorThink, ColorSync Utility, Gamut Works etc) that allows one to take the existing working space profiles that define ProPhoto RGB and Adobe RGB (1998) do not confirm the idea that It does not seem like that Prophoto RGB is always wider than Adobe RGB. Just the opposite shows true. Do you have any such set of graphing utilities that allow you to map in 2D or ideally in 3D the two profiles?
-
Do you have any such set of graphing utilities that allow you to map in 2D or ideally in 3D the two profiles?
Well, first you can guage the length of Adobe and Prophoto blue primaries from my diagram below.
(http://djjoofa.com/data/images/adobe_prophoto_rgb.gif)
Secondly, I don't know how tho_mas produced the following diagram, but isn't that saying the same thing? Though he thoght otherwise. He said that it is showing profiles. But it seems like blue is projecting out of the mesh. I am no expert in such programs and some of the associated terminology, so may be it is showing something else.
verify what? These things are also available as real profiles in real applications.
This is the shape of the profiles (abscol to D50; Adobe = white)... but this is just the shape of the profiles, totally independed from any real application:
(http://www6.pic-upload.de/30.12.10/1zwpmhoq7zii.jpg)
This is what happens in color conversions:
(http://www6.pic-upload.de/30.12.10/3ozvthhv8ia6.jpg)
Joofa
-
I don't know how tho_mas produced the following diagram, but isn't that saying the same thing? Though he thoght otherwise. He said that it is showing profiles. But it seems like blue is projecting out of the mesh. I am no expert in such programs and some of the associated terminology, so may be it is showing something else.
The are unlabeled so I’m not sure what is what here but yes, the blue primaries would fall outside the CIE chromaticity diagram as its are outside human vision. Yes, it appears these are indeed plots of two profiles (again which profiles are what, I don’t know). But using such a utility and plotting Adobe RGB (1998) and ProPhoto RGB, there is zero question that Adobe RGB (1998) fully fits inside of ProPhoto RGB and that the idea that It does not seem like that Prophoto RGB is always wider than Adobe RGB is not true. Its always a wider gamut working space in all directions.
-
Well, first you can guage the length of Adobe and Prophoto blue primaries from my diagram below.
Just to be perfectly clear, there's nothing sacred about Adobe RGB's "numbers". The funny thing is that it was Mark Hamburg who came up with the numbers while trying to find "RGB Color Spaces" to consider when originally working on the color management of Photoshop 5 (that's PS 5 not CS5 back in 1996/7 I think). He found a color space proposal for I believe an editing space for HDTV that was called SMPTE-240M. Back in Photoshop 5, he included that color space. Only problem is the original proposal that Mark found on the net had a typo on 2 of 3 color coordinates (can't remember which ones). Adobe was contacted after the release of PS 5 and told that A) the color space SMPTE-240M was a "proposed" color space and not yet ratified and B) the original proposal had been amended to correct the two typos and so quit calling it "SMPTE" anything. Adobe chose to rename SMPTE-240M to Adobe RGB (1998).
So, the color coordinates are actually based on typos and it's merely happenstance that the coordinates are those particular numbers.
Kodak had already worked on this problem of developing an RGB working space for digital imaging. They originally released a color space called ROMM-RGB which actually ended up being renamed ProPhoto RGB. ProPhoto RGB predates Adobe RGB (SMPTE-240M) by several years.
In the grand scheme of things, it's mildly interesting to talk about this stuff but the bottom line is that for the purposes of digital imaging for photography, ProPhoto RGB again is the ONLY color space that can contain ALL the colors a camera can captures and ALL the colors recent high-end inkjet printers can print.
Don't let the side discussions confuse the issues...and realize Adobe RGB (1998) is actually an accidental color space brought into being...
I also can tell you a history of sRGB originally developed by Michael Stokes while he worked for HP (I believe). Mike later went to MSFT where sRGB was promoted as the "default" color space for Windows (back in 1997/8). While the color space has always sucked for photography, sRGB was pushed by MSFT because from their point of view, the only color than mattered was the color shown on a computer running Windows. Unfortunately the photographic industry drank MSFT's Kool-Aid and a lot of companies fell for it. Which is one reason a lot of photo labs unfortunately try to tell customers to use sRGB and avoid the whole issue of custom output profiles...
Originally, the 's' in sRGB was thought to mean 'standard' (note the small s). When MSFT started pushing it the 's' seemed to represent 'satanic' RGB...now unfortunately it seems to represent 'stupid' RGB...some people may also consider it to represent 'shitty' RGB but I tend to think of it as interchangeable with 'satanic' and 'stupid' RGB.
-
but the bottom line is that for the purposes of digital imaging for photography, ProPhoto RGB again is the ONLY color space that can contain ALL the colors a camera can captures and ALL the colors recent high-end inkjet printers can print.
Jeff, is there not any color space that totally contains the gamut of my Epson 4900, but is smaller than ProPhoto RGB? I just got my new 4900 and was about to look for such a working color space. Indeed, I do see where the gamut of my 4900 is clipped in the blue green area by BetaRGB.
Thanks,
Jeff
-
The are unlabeled so I’m not sure what is what here but yes, the blue primaries would fall outside the CIE chromaticity diagram as its are outside human vision. Yes, it appears these are indeed plots of two profiles (again which profiles are what, I don’t know).
My guess is that thomas' top image showing blue ripping through mesh corresponds to the case that I have labelled as (1) in my note on dpreview (Adobe=D65, Prophoto=D50). And, his bottom image corresponds to my cases (2) or (3), i.e., (Adobe=D65, Prophoto=D65) and (Adobe=D50, Prophoto=D50), respectively. But, I'm no expert in such prsentations so don't count on me.
But using such a utility and plotting Adobe RGB (1998) and ProPhoto RGB, there is zero question that Adobe RGB (1998) fully fits inside of ProPhoto RGB and that the idea that It does not seem like that Prophoto RGB is always wider than Adobe RGB is not true. Its always a wider gamut working space in all directions.
After presenting all the numbers, diagrams and discussion, I dont' know how to convince you.
Joofa
-
In the grand scheme of things, it's mildly interesting to talk about this stuff but the bottom line is that for the purposes of digital imaging for photography, ProPhoto RGB again is the ONLY color space that can contain ALL the colors a camera can captures and ALL the colors recent high-end inkjet printers can print.
Firstly, thanks for the historical perspective in your insightful note. It was instructive.
I have said before that I can agree with you that it might be a little academic arguing about some blues that can't be observed. However, based upon the numbers Bill produced, I have an unsettling feeling that it might appear that Adobe has implemented their own space, Adobe RGB, with D50, instead of the standard specification of D65 white point, in Photoshop! I think it is a blasphemy to mention that. But, can that happen? ??? ??? ??? ???
Joofa
-
My guess is that thomas' top image showing blue ripping through mesh corresponds to the case that I have labelled as (1) in my note on dpreview (Adobe=D65, Prophoto=D50). And, his bottom image corresponds to my cases (2) or (3), i.e., (Adobe=D65, Prophoto=D65) and (Adobe=D50, Prophoto=D50), respectively.
There is NO such thing as ProPhoto RGB working space with a D65 WP. There is no such thing as Adobe RGB (1998) working space with D50 WP. An RGB working space is by its very definition and design, specific values that define its WP, chromaticity values and gamma (TRC). Open Photoshop, go into the Color Settings. Select the RGB working space (like ProPhoto RGB), then toggle to Custom RGB... in the popup menu. See the resulting dialog? Its the DNA of the working space. Alter any value, its not that working space any more.
After presenting all the numbers, diagrams and discussion, I dont' know how to convince you.
After viewing the 3D gamuts of each, I’d agree.
-
There is NO such thing as ProPhoto RGB working space with a D65 WP. An RGB working space is by its very definition and design, specific values that define its WP, chromaticity values and gamma (TRC).
You got to be kidding. A 3D color space has already three independent vectors, R, G, and B. The standard definition of dimensionality of a finite dimension space is that any 4th vector is linearily dependent on the three. Then why is a white point (4th vector) specified? Think about it.
It is perfectly feasible to conceive an Adobe RGB space with D50 white point instead of the standarized D65 and Prophoto RGB space with a white point of D65 instead of standarized D50.
After viewing the 3D gamuts of each, I’d agree.
The graph in one of previous messages that I quote above, which shows Adobe and ProPhoto RGB primaries, gives an indication of the gamut. Just that it is not presented in the way you are used to seeing in other programs. But trust me it shows that information if you want to have a ball-park estimate of it. On my computer I can rotate it around and have a better view of certain axis. But I selected that view because it shows the angular relationship of the 6 primaries in addition to their magnitudes. You can connect the endpoints of the vectors displayed and have a triangle and project the spectral colors that I have also drawn, and hey, you have your chromacity diagram for the Adobe and ProPhoto Systems.
Joofa
-
I have said before that I can agree with you that it might be a little academic arguing about some blues that can't be observed. However, based upon the numbers Bill produced, I have an unsettling feeling that it might appear that Adobe has implemented their own space, Adobe RGB, with D50, instead of the standard specification of D65 white point, in Photoshop! I think it is a blasphemy to mention that. But, can that happen? ??? ??? ??? ???
Joofa
Joofa,
Not quite so academic, since there is no RGB value in the AdobeRGB gamut that can not be seen by the human eye, since the AdobeRGB coding efficiency (as determined by Bruce Lindbloom) is 100%. On the other-hand, only 50% of colors (the CIE L*a*b gamut) are encoded by AdobeRGB. The critical gamut for most photography is that of real world surface colors: colors that exist in nature and are seen via reflected light. Gernot Hoffman has some plots showing its gamut, which is larger than AdobeRGB but less than ProPhotoRGB. Neon lights and other emissive sources exceed this gamut. I think that Bruce Lindbloom tried to approximate the real world surface colors in his BetaRGB.
Regards,
Bill
-
Joofa,
Your XYZ graph doesn't show the relative gamuts of the two spaces. Just because one blue vector has a higher magnitude than the other isn't enough. The direction is important too. You have only proven that the ARGB blue primary is further from the origin than the prophoto RGB primary. That doesn't mean what you think it means.
Bruce has a 3D gamut utility on the his website here: http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html (scroll down)
It will show the AdobeRGB space completely surrounded by the prophoto space. For me this is definitive, but it doesn't seem to convince you so lets try a little math.
Let's compare pure blue in both spaces. Take your AdobeRGB blue [0, 0, 1.0] and convert it to XYZ you also have to account for the chromatic adaptation since we have two different white points. Bruce makes it easy to do by providing a adobeRGB matrix with an adaptation to d50 built in:
[0.6097559 0.2052401 0.1492240]
[0.3111242 0.6256560 0.0632197] x [0 0 1.0] = [ 0.149224 0.0632197 0.7448387]
[0.0194811 0.0608902 0.7448387]
This is AdobeRGB's pure blue converted to XYZ and D50.
Now lets convert it to ProPhotoRGB:
[ 1.34594337 -0.25560752 -0.05111183]
[-0.54459882 1.5081673 0.02053511] x [0.149224 0.0632197 0.7448387] = [ 0.14661755 0.02937401 0.90260503]
[ 0.000 0.000 1.21181275]
Apply gamma correction:
[ 0.14661755 0.02937401 0.90260503] ^ (1/1.8) = [ 0.3441676 0.14088621 0.94466218]
[ 0.3441676 0.14088621 0.94466218] is how you represent adobeRGB's pure blue in prophotoRGB with room to spare.
If you multiply by 255 you'll get:
[ 87.76273719 35.92598274 240.88885588] which is pretty much what photoshop will tell you if you do the profile conversion there.
Now try to do the opposite. Start with ProPhotoRGB's [0, 0, 1] convert to XYZ and then try going to AdobeRGB. You will get negative RGB numbers showing that this color is out of gamut.
Of course this could all be proven wrong if you show me an AdobeRGB color that can't be represented in prophoto space.
-
Jeff, is there not any color space that totally contains the gamut of my Epson 4900, but is smaller than ProPhoto RGB?
I don't know...all I know for a fact is there is no color space (that I know of) that can contain ALL the colors my cameras can capture and my printer can print other than ProPhoto RGB...pretty sure Beta RGB and Ekta RGB (from Joe Homes) can't say that.
So, in the grand scheme of things, I really don't care.
To the best of my knowledge I've NEVER had any image quality issues caused by using ProPhoto RGB in 16 bit/channel. Yes, it's a huge color space but I've never seen any real problems from using that space. I HAVE seen real problems using Adobe RGB and sRGB. Since these three color spaces are the only color spaces I've used on a regular basis and are one of 4 offered in Camera Raw, the only choice for me is ProPhoto RGB. And I've talked at length to the likes of Thomas Knoll, Mark Hamburg, Michael Stokes and Karl Lang (to name a few) and they all pretty much point to ProPhoto RGB as being the best large gamut color space to using for digital imaging. Which is why ProPhoto RGB with a linear gamma is the internal working space of both Camera Raw and Lightroom.
I used to use ColorMatch RGB which was originally developed by Karl Lang when he worked for Radius and did the original PressMatch displays but it suffers from a deficient in cyan when converting to CMYK.
I know some people advocate using the largest, most efficient color space that can handle input and output but the only one that I've seen that never clips any colors is Pro Photo RGB.
And I simply don't care about the fact that theoretically, Pro Photo RGB is "inefficient". I've never had any problems because Pro Photo RGB is inefficient and "too big". Yes, it's a large color space and that means that the massive separation of levels due to the color coordinates "could" cause efficiency problems-it's just I've never seen any actual proof of that and I've never seen any problems with my own work.
Use whatever color space makes you happy...I use only ProPhoto RGB for my own work, I use sRGB for the web and I use Adobe RGB when sending images to anybody who I don't know for an absolute fact know what they are doing which includes most all magazines, ad agencies, photo labs and designers...(which basically means everybody else in the world).
:~)
-
Joofa,
Your XYZ graph doesn't show the relative gamuts of the two spaces. Just because one blue vector has a higher magnitude than the other isn't enough. The direction is important too. You have only proven that the ARGB blue primary is further from the origin than the prophoto RGB primary. That doesn't mean what you think it means.
Please don't assume that what I think I mean. Do you really think that I plotted the angles between various primaries just arbitrarily?
Bruce has a 3D gamut utility on the his website here: http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html (scroll down)
It will show the AdobeRGB space completely surrounded by the prophoto space. For me this is definitive, but it doesn't seem to convince you so lets try a little math.
Let's compare pure blue in both spaces. Take your AdobeRGB blue [0, 0, 1.0] and convert it to XYZ you also have to account for the chromatic adaptation since we have two different white points. Bruce makes it easy to do by providing a adobeRGB matrix with an adaptation to d50 built in:
[0.6097559 0.2052401 0.1492240]
[0.3111242 0.6256560 0.0632197] x [0 0 1.0] = [ 0.149224 0.0632197 0.7448387]
[0.0194811 0.0608902 0.7448387]
I believe this is the incorrect matrix for this situation. This is for conversion from Adobe RGB with D50 white point to XYZ. I mentioned before that the Bruce has also provided the matrix for Adobe RGB with D65 white point conversion to XYZ, and I repeat it again here:
0.5767309 0.1855540 0.1881852
0.2973769 0.6273491 0.0752741
0.0270343 0.0706872 0.9911085
[Rest of calculation snipped.]
This is AdobeRGB's pure blue converted to XYZ and D50.
What pure blue? The "pure" blue in Adobe RGB with D65 is [0.1881852 0.0752741 0.9911085] and its representation in Adobe RGB with D50 white point is *not* [0 0 1]! The representation of [0 0 1] in Adobe RGB with D50 white point with exact calculation is [0.137826 0.055130 0.725885], but you can use the one you used in your matrix of [0.149224 0.0632197 0.7448387] also as it is close enough.
I mentioned before and I repeat it again here the colors represented by [0 0 1] in Adobe RGB with D65 and D50 are different. The one with D50 can be represented in Prophoto RGB with D50 white point, but not the one with D65.
Joofa
-
This is for conversion from Adobe RGB with D50 white point to XYZ
No, it's not. As others keep pointing out, there is no Adobe RGB with a D50 white point.
If you want to compare spaces with different white points, you need to convert to a common white point. To go from AdobeRGB to ProPhotoRGB you need to account for the different white points. The AdobeRGB D50 matrix is just a convenience to remove that step from the calculations. You can do the same thing using the D65 matrix, but then you need to explicitly perform the chromatic adaptation yourself.
Like this:
AdobeRGB -> XYZ using the D50 matrix (what I originally did):
[0.6097559 0.2052401 0.1492240]
[0.3111242 0.6256560 0.0632197] x [0 0 1.0] = [ 0.149224 0.0632197 0.7448387]
[0.0194811 0.0608902 0.7448387]
or like this:
AdobeRGB -> XYZ using the D65 matrix:
[0.5767309 0.1855540 0.1881852]
[0.2973769 0.6273491 0.0752741] x [0 0 1.0] = [ 0.1881852 0.0752741 0.9911085]
[0.0270343 0.0706872 0.9911085]
But now you need to explicitly account for D50 if you want to move to a D50 space or compare to a D50 space (using Bradford):
[1.0478112 0.0228866 -0.0501270]
[0.0295424 0.9904844 -0.0170491] x [ 0.1881852 0.0752741 0.9911085] = [ 0.14922403 0.06321976 0.74483862]
[-0.0092345 0.0150436 0.7521316]
See, same result. This is all the AdobeRGB D50 matrix is doing. Again there is no AdobeRGB D50. Making a statement like "[0 0 1] in Adobe RGB with D50" doesn't make any sense. You can convert to XYZ and then to d50 which is what I did above, but if you want to get back to Adobe RGB you need to convert back to D65.
-
You got to be kidding. A 3D color space has already three independent vectors, R, G, and B. The standard definition of dimensionality of a finite dimension space is that any 4th vector is linearily dependent on the three. Then why is a white point (4th vector) specified? Think about it.
The point is, white point isn't a vector. It's a point. ;D
But in all seriousness, Andrew is entirely correct. This discussion is the color space equivalent of "if my aunt was a man, she'd be my uncle". ProPhoto is a D50 color space. You can construct a infinite number of possible alternate color spaces, e.g., one with a D65 white point and ProPhoto primaries. But to suggest that the ProPhoto color space doesn't contain a specific color because your new alternate color space with ProPhoto primaries doesn't contain that point is incorrect. The new space that you invented may have the same primaries as ProPhoto, but it isn't ProPhoto. Color space definitions have white points for a reason.
Sandy
-
No, it's not.
Yes it is.
As others keep pointing out, there is no Adobe RGB with a D50 white point.
Selection of a white point is independent of the selection of the primaries. Adobe RGB primaries with the same chromacity coordinates can be used with either D65 white point or D50 white point. It is a vector space. You are given three basis vectors (RGB) directions (chromacity coordinates) but you don't know how long is a "unit vector". The white point sets the units. This concept is an important one and apparently is being missed by you and others.
With this understanding Adobe RGB with D65 and D50 are two different coordinate systems in the same 3D space.
If you want to compare spaces with different white points, you need to convert to a common white point.
To go from AdobeRGB to ProPhotoRGB you need to account for the different white points. The AdobeRGB D50 matrix is just a convenience to remove that step from the calculations. You can do the same thing using the D65 matrix, but then you need to explicitly perform the chromatic adaptation yourself.
Like this:
AdobeRGB -> XYZ using the D50 matrix (what I originally did):
[0.6097559 0.2052401 0.1492240]
[0.3111242 0.6256560 0.0632197] x [0 0 1.0] = [ 0.149224 0.0632197 0.7448387]
[0.0194811 0.0608902 0.7448387]
AdobeRGB -> XYZ using the D65 matrix:
[0.5767309 0.1855540 0.1881852]
[0.2973769 0.6273491 0.0752741] x [0 0 1.0] = [ 0.1881852 0.0752741 0.9911085]
[0.0270343 0.0706872 0.9911085]
But now you need to explicitly account for D50 if you want to move to a D50 space or compare to a D50 space (using Bradford):
[1.0478112 0.0228866 -0.0501270]
[0.0295424 0.9904844 -0.0170491] x [ 0.1881852 0.0752741 0.9911085] = [ 0.14922403 0.06321976 0.74483862]
[-0.0092345 0.0150436 0.7521316]
See, same result. This is all the AdobeRGB D50 matrix is doing.
What all the above calculation is doing is that showing that for e.g., if you take a 100% reflector and shine D65 light on it and measure the XYZ tristimulus of blue in an rgb mixture to match D65, you will get blue = [0.1881852 0.0752741 0.9911085]. If instead of D65 you have shone D50 on the same reflector you would have measured [0.14922403 0.06321976 0.74483862]. But these two colors are different in absolute terms. What Bradford transformation says is that you don't need to shine a D50 light and measure the XYZ. If you have D65 tristimulus then you can convert from D65 to D50 with certain human assumptions in mind regarding neutral/gray colors consistency.
And this is what you have shown. But this is not what I'm after.
Instead of a reflector, suppose there is a source that emits two colors A = [0.1881852 0.0752741 0.9911085] and B= [0.14922403 0.06321976 0.74483862] in XYZ, which are, in absolute terms, two different colors. If you measure A with Adobe RGB primaries scaled to D65 white point you get [0, 0, 1]. If you measure B with Adobe RGB primaries scaled to D50 white points you get [0, 0, 1]. But what if you measure A with D50 and B with D65. You, of course, don't get [0, 0, 1], but some other numbers, which can be calculated, but not important right now.
Now lets try to measure A and B in Prophoto RGB scaled to D50 white point. You will find that A needs more than unit amount of blue Prophoto RGB while B needs less. Which means that A can't be represented but B can be in Prophoto (D50). But A can be represented in Adobe RGB (D65) as [0,0,1]. So this is a color which has representation in Adobe RGB (D65) but not in Prophoto RGB (D50) without clipping.
There is no need for a Bradford transformation here as we are doing a direct measurement of two different colors A and B in a measurement system using ProPhoto RGB scaled to D50 white point.
Again there is no AdobeRGB D50.
I hope by now you know that one can be constructed as easily as one with D65!
Making a statement like "[0 0 1] in Adobe RGB with D50" doesn't make any sense.
Again, I hope by now you understand.
Sincerely,
Joofa
-
The point is, white point isn't a vector. It's a point. ;D
Yeah right. You have a good grasp of colorimetry!
But to suggest that the ProPhoto color space doesn't contain a specific color because your new alternate color space with ProPhoto primaries doesn't contain that point is incorrect. The new space that you invented may have the same primaries as ProPhoto, but it isn't ProPhoto. Color space definitions have white points for a reason.
I don't think you have understood what I'm saying here. I'm not inventing new color spaces. The basic premise of my note is the standard Adobe RGB (D65) and standard ProPhoto RGB (D50). Other spaces with the same primaries but different white points were to illustrate what is going on here.
Joofa
-
Selection of a white point is independent of the selection of the primaries
Right, and you can select the blue primary independently from the red. When you do that you create a new colorspace.
With this understanding Adobe RGB with D65 and D50 are two different coordinate systems in the same 3D space
If they are two different coordinate systems, they are two different color spaces. One, the one with the D65 white point is called AdobeRGB 1998, you can read it's spec here: http://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf
In that document you will learn the chromatically coordinates of the primaries and the white point (x=0.3127, y=0.3290, which corresponds to D65).
The other space you describe whose primaries have the same chromaticity coordinates as AdobeRGB but with a different white point, let's call it joofaSpace, is something else. I don't know much about joofaSpace, but I do know that by definition it is not AdobeRGB. If you still insist this is not true, you need to find a spec for adobe RGB that doesn't include a d65 white point.
Another thing, in all this discussion we have not seen a transformation matrix from joofaSpace to XYZ. The matrix you would like to use—the D50 matrix we've been using above, does not actually share the primaries from AdobeRGB. You can very easily calculate the chromaticity coordinate of the primaries from the matrix. If you do this for the AdobeRGB D65 matrix you get these coordinates (exactly what they should be):
Red: 0.6400 0.3300
Green: 0.2100 0.7100
Blue: 0.1500 0.0600
If you do it for the D50 matrix you get:
Red: 0.6484 0.3309
Green: 0.2301 0.7016
Blue: 0.1559 0.0660
They're significantly different. So if your goal is to use a transformation matrix with the same primaries as AdobeRGB but with a different white point, you're using the wrong one. Like I posted above, that isn't what that matrix does.
If you'd like a matrix for joofaSpace, I've calculated one for you:
[.645 .181 .138]
[.333 .612 .055]
[.030 .069 .726]
I did it by hand so I only calculated three digits, but if you run the numbers you'll find that it delivers a white point that corresponds to D50 and the primaries match those of AdobeRGB. Just don't call it AdobeRGB 1998.
-
Right, and you can select the blue primary independently from the red. When you do that you create a new colorspace.
No new color space at all. Repeat: no new color space at all. Just a new co-ordinate system in the same space. I don't think you have looked at my diagram where I show Adobe RGB and ProPhoto RGB primaries. There are two cooridanate systems shown there, viz., Adobe and Prophoto, but the space is the same.
If they are two different coordinate systems, they are two different color spaces.
Again you are repeating what I just answered above. Color space is the same. There are more than one coordinates systems in the same space. Oh come on, in computer graphics they do it all of time with rotation of the axis. Does that give a different space. Not at all. Just a different frame of reference for coordinate system. If you don't understand this fundamental fact then you are not following the inherent principles of colorimetry.
Another thing, in all this discussion we have not seen a transformation matrix from joofaSpace to XYZ. The matrix you would like to use—the D50 matrix we've been using above, does not actually share the primaries from AdobeRGB. You can very easily calculate the chromaticity coordinate of the primaries from the matrix. If you do this for the AdobeRGB D65 matrix you get these coordinates (exactly what they should be):
Red: 0.6400 0.3300
Green: 0.2100 0.7100
Blue: 0.1500 0.0600
If you do it for the D50 matrix you get:
Red: 0.6484 0.3309
Green: 0.2301 0.7016
Blue: 0.1559 0.0660
They're significantly different. So if your goal is to use a transformation matrix with the same primaries as AdobeRGB but with a different white point, you're using the wrong one. Like I posted above, that isn't what that matrix does.
Remember, didn't I inform you that you are using an approximate matrix for transformation in an Adobe RGB (D50), because you multiplied a Adobe RGB (D65) matrix with Bradform transform, which is not exact. You can calculate the exact matrix directly. I will give you the coordinates of the blue primary in Adobe RGB (D50), and they are [0.137826 0.055130 0.725885] (compare to yours of [0.14922403 0.06321976 0.74483862]), where as the coordinates of the Adobe RGB (D65) blue primary are [0.188185 0.075274 0.991108]. And see below:
x,y chromacity coordinates for Adobe RGB (D65) blue primary
[0.188185 0.075274 0.991108]/sum([[0.188185 0.075274 0.991108]] = [0.150000 0.060000 0.790000]
x,y chromacity coordinates for Adobe RGB (D50) blue primary
[0.137826 0.055130 0.725885]/sum([0.137826 0.055130 0.725885]) = [0.150000 0.059999 0.790001]
They look the same to me!
Just don't call it AdobeRGB 1998.
I don't think that you are reading carefully. I have tried not to use the words "Adobe RGB" alone. I have always tried to use with a white point, say "Adobe RGB (D65)" or "Adobe RGB (D50)" to emphasize that both use the same primaries but the white points are different. I hope you understand it now. Incidently, Adobe RGB (D65) is the standardized notion, but it is no different in conception than Adobe RGB (D50).
Sincerely,
Joofa
-
It is perfectly feasible to conceive an Adobe RGB space with D50 white point instead of the standarized D65 and Prophoto RGB space with a white point of D65 instead of standarized D50.
Look, you can conceive it anyway you wish, but altering the white point changes the color space definition and as I said earlier, call it JoffaRGB. You seem to want to imply that the color space known as Adobe RGB (1998), a space that is defined using three sets of values can be larger than the space we call ProPhoto RGB, again specified with existing, known and specific values. You do this by altering one set of its definitions to prove your point. But doing so changes the definition. Its no longer Adobe RGB (1998). If you want to alter values to produce a new working space that is bigger or smaller, fine. But don’t try passing it off as Adobe RGB (1998), cause its not that color space any longer.
I have two color spaces represented as Adobe RGB (1998) and ProPhoto RGB as ICC profiles. I load them in ColorThink and view the in 3D. ProPhoto RGB fully exceeds Adobe RGB (1998) in every direction and by a large margin. Further, ColorThink reports the Gamut Volume of Adobe RGB (1998) as 1,207,520 and ProPhoto RGB as 2,548,220. These are the very ICC working space profiles installed by Photoshop. Are you suggesting that ColorThink is incorrectly providing either the 3D gamut maps, the gamut volume numbers or that Adobe has provided us two profiles that don’t represent what their WP, chromaticity values and TRC Gamma, shown within Photoshop and other utilities are incorrect?
-
This discussion is the color space equivalent of "if my aunt was a man, she'd be my uncle".
That’s wonderful and I just have to paste that into my collection of great quotes. OT but I heard one the other day on a forum which is similar:
Keke Rosberg (a Finnish Formula 1 race driver) had a great quote regarding such things: "if mother had balls she'd be the dad."
-
Look, you can conceive it anyway you wish, but altering the white point changes the color space definition and as I said earlier, call it JoffaRGB. You seem to want to imply that the color space known as Adobe RGB (1998), a space that is defined using three sets of values can be larger than the space we call ProPhoto RGB, again specified with existing, known and specific values. You do this by altering one set of its definitions to prove your point. But doing so changes the definition. Its no longer Adobe RGB (1998). If you want to alter values to produce a new working space that is bigger or smaller, fine. But don’t try passing it off as Adobe RGB (1998), cause its not that color space any longer.
Do you have reading comprehension problem? No I am not joking. Seriously? Have you not understood that the basic premise of my argument is to find color(s) that are represented in standardized Adobe RGB (D65) but not in standardized Prophoto (D50). Where is JoofaSpace coming in these? Are these not the standard color specification of these color spaces. I only ventured into using Adobe RGB primaries with non-standard D50 to illustrate what is the notion of a "unit vector" associated with a color space. Apparently it is lost on you.
I have two color spaces represented as Adobe RGB (1998) and ProPhoto RGB as ICC profiles. I load them in ColorThink and view the in 3D. ProPhoto RGB fully exceeds Adobe RGB (1998) in every direction and by a large margin. Further, ColorThink reports the Gamut Volume of Adobe RGB (1998) as 1,207,520 and ProPhoto RGB as 2,548,220. These are the very ICC working space profiles installed by Photoshop. Are you suggesting that ColorThink is incorrectly providing either the 3D gamut maps, the gamut volume numbers or that Adobe has provided us two profiles that don’t represent what their WP, chromaticity values and TRC Gamma, shown within Photoshop and other utilities are incorrect?
I have already given you an example of color that is representable in standard (if that makes you happy) Adobe RGB (D65) but not in standard Prophoto RGB (D50). Please read the following:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412251#msg412251
Sincerely,
Joofa
-
Do you have reading comprehension problem? No I am not joking. Seriously? Have you not understood that the basic premise of my argument is to find color(s) that are represented in standardized Adobe RGB (D65) but not in standardized Prophoto (D50).
It is you sir that has a reading comprehension problem. I’m sorry you feel that by altering a specific color space’s metrics, that you don’t understand its no longer that color space. Or that others have told you, as I have this is the case (see: But in all seriousness, Andrew is entirely correct. This discussion is the color space equivalent of "if my aunt was a man, she'd be my uncle". ProPhoto is a D50 color space.).
Further, I’ve suggested you contact Bruce about this calculator which I will again suggest you do. Ask him about your gamut theories and about altering working space metrics.
Where is JoofaSpace coming in these? Are these not the standard color specification of these color spaces.
Again, for the 3rd time, they are standard until you alter their DNA (their three specific sets of metrics that define them). In a quest to prove that Adobe RGB (1998) has a larger gamut than ProPhoto RGB, you resort to altering one of those specifications. Go ahead and do this using the Photoshop Custom RGB dialog after selecting Adobe RGB (1998). Change the WP. Do you see the new name? Its no longer Adobe RGB (1998). Do you wish to call it JoofaRGB? By all means do so. But you can’t call it Adobe RGB (1998) because its not Adobe RGB (1998) any more. I’m not sure why this simple point is lost on you.
I only ventured into using Adobe RGB primaries with non-standard D50 to illustrate what is the notion of a "unit vector" associated with a color space. Apparently it is lost on you.
What’s lost on you is, its no longer Adobe RGB (1998)! Call it JoffaRGB and then tell people its bigger than ProPhoto RGB if you wish.
Further, you seem to refuse to look at what every 2D and 3D gamut mapping utility proves in terms of the gamut of the two, known, standard, specifically defined working spaces represent. If you want to argue one can edit an existing color space (working space) and make its gamut larger, no one here is disagreeing with you. If you want to call this edited space the same name as the original, big argument. Its this simple fact you don’t seem to expect which is fine. There’s no reason to continue, especially if you continue to get so pissy about it.
Bruce has made this easy for you! Go here:
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html
Go to the Gamut Viewer. Load the Adobe RGB (1998) and ProPhoto RGB. Click Update the View. Spin them. Where do you see Adobe RGB (1998) exceed ProPhoto? Note too that no where does Bruce allow you to screw around with the specifics that define these two spaces (because again, if you do, they are no longer those color spaces). Email Bruce. Ask him why he doesn’t allow you to alter Adobe RGB to make it look bigger than ProPhoto RGB. Answer, because you can’t.
-
What’s lost on you is, its no longer Adobe RGB (1998)! Call it JoffaRGB and then tell people its bigger than ProPhoto RGB if you wish.
Digitaldog,
Are you trying to joke? How many times I have told you that I am giving you an example of color(s) that are representable in STANDARD Adobe RGB (D65) but not in STANDARD Prophoto RGB (D50). Can I get any clearer than that. Go back and read the link I provided above.
Further, you seem to refuse to look at what every 2D and 3D gamut mapping utility proves in terms of the gamut of the two, known, standard, specifically defined working spaces represent. If you want to argue one can edit an existing color space (working space) and make its gamut larger, no one here is disagreeing with you. If you want to call this edited space the same name as the original, big argument. Its this simple fact you don’t seem to expect which is fine. There’s no reason to continue, especially if you continue to get so pissy about it.
It is pretty ironic that you don't understand some basic concepts. I am not claiming that the volume of Adobe RGB is bigger than Propphoto RGB. Just that Adobe RGB does not seem to be fully contained in Prophoto, while still apparently being smaller than ProPhoto RGB in volume.
Hope you understand that.
Joofa
-
I am not claiming that the volume of Adobe RGB is bigger than Propphoto RGB. Just that Adobe RGB does not seem to be fully contained in Prophoto, while still apparently being smaller than ProPhoto RGB in volume.
Where do you see that fact within the 3D gamut map that Bruce plots on his page?
-
Where do you see that fact within the 3D gamut map that Bruce plots on his page?
I shall check out what Bruce is doing? But, he is not here. So lets stick to this question that I ask you directly:
What is the representation of the color XYZ=[0.188185 0.075274 0.991108] in standard Prophoto (D50) color space?
I shall wait for an answer from you.
Joofa
-
That’s wonderful and I just have to paste that into my collection of great quotes. OT but I heard one the other day on a forum which is similar:
Keke Rosberg (a Finnish Formula 1 race driver) had a great quote regarding such things: "if mother had balls she'd be the dad."
Andrew,
Actually, that's exactly the one I was thinking of - I decided to use the "family friendly" version!!!
Regards,
Sandy
-
Representation of what, calculated how? Standard Prophoto (D50) color space?
-
Representation of what,
Tristimulus values.
calculated how?
Ha ha, you asking me? I thought you were the color expert. You have full information available to work out this problem. Clock is ticking. ;)
Standard Prophoto (D50) color space?
Yes, standard Prophoto (D50) color space, and not JoofaSpace ;D
Sincerely,
Joofa
-
What is the representation of the color XYZ=[0.188185 0.075274 0.991108] in standard Prophoto (D50) color space?
the question is: where or when is the absolute chromaticity relevant?
Is there any real world application where the highest saturated blue of AdobeRGB doesn't fit into ProPhotoRGB?
Hey, you could create 2 color spaces, one in "D01" and one in "D95" so that there is no overlapping of the 2 gamuts in absolute terms. But integrated in a color mangement workflow the different white points would be mapped to each other anyway.
So, your high saturated blue of AdobeRGB is not covered by ProPhotoRGB due to the specs. But in a color management workflow ProPhotoRGB will always include all colors of AdobeRGB.
So what's the hassle about? It really doesn't help anyone...
-
Ha ha, you asking me? I thought you were the color expert. You have full information available to work out this problem. Clock is ticking. ;)
Let it tick, I have zero idea where you are going with this, we’ve been through far too many posts where you’ve been vague, insulting and dismissive. How about this, the clock is ticking on you getting clarification from Bruce about all this. Or to show us where Adobe RGB (1998) falls outside ProPhoto RGB gamut. This isn’t a problem in search of a solution, its not even a solution in search of a problem.
Yes, standard Prophoto (D50) color space, and not JoofaSpace ;D
JoofaSpace is (was, is supposed to be) based on Adobe RGB primaries with some update you feel is necessary to alter its white point. Now you bring ProPhoto RGB into the mix and using the term “standard” when for the last time, there is no non standard ProPhoto RGB, there is only one ProPhoto RGB. And the fact you can’t show us using simple 2D or 3D graphing tools, one that is available to you on Bruce’s web site, how and where Adobe RGB exceeds ProPhoto anywhere in color space, makes me think you are simply here to waste our time.
Is there a reason you can’t or will not show us visually using either Bruce’s gamut mapping on his site, or using tools already mentioned, where Adobe RGB falls outside ProPhoto gamut? The tools are broken, the profiles are invalid, the graph on Bruce’s site is faulty?
-
the question is: where or when is the absolute chromaticity relevant?
Is there any real world application where the highest saturated blue of AdobeRGB doesn't fit into ProPhotoRGB?
Hey, you could create 2 color spaces, one in "D01" and one in "D95" so that there is no overlapping of the 2 gamuts in absolute terms. But integrated in a color mangement workflow the different white points would be mapped to each other anyway.
So, your high saturated blue of AdobeRGB is not covered by ProPhotoRGB due to the specs. But in a color management workflow ProPhotoRGB will always include all colors of AdobeRGB.
So what's the hassle about? It really doesn't help anyone...
Hi tho_mas, Nice to see you here. You are right there is some unnecessary arguing on. But that is the silly nature of online debates. However, we need your help. Can you please help us and identify how you drew the following graph:
verify what? These things are also available as real profiles in real applications.
This is the shape of the profiles (abscol to D50; Adobe = white)... but this is just the shape of the profiles, totally independed from any real application:
(http://www6.pic-upload.de/30.12.10/1zwpmhoq7zii.jpg)
Sincerely,
Joofa
-
Can you please help us and identify how you drew the following graph:
as said in the respective post: ProPhoto (wireframe) and AdobeRGB white - both unaltered - in relation to D50.
That's the grapher of Chromix Color Think ...
So in absolute terms this is the correct visual representation. But it's useless... as it shows something that will never happen.
In a (real) color managed workflow the above mentioned visual representation of Bruce Lindbloom's grapher is relevant.
That's why I don't understand what you try to achieve.
Andrew is right.
IMO.
IMHO ...
-
Let it tick, I have zero idea where you are going with this,
I knew that. BTW, this is a color that is not representable in Prophoto (D50) (yes your standard space) without unity stimulus from the blue primary. If you read the link to my message that I provided above you would have known that.
we’ve been through far too many posts where you’ve been vague, insulting and dismissive.
Oh come on. I have provided graphs that I drew showing the Adobe and Prophoto primaries, written detailed and long messages on how to interpret white points, how to generate other coordinate systems in the same 3D color space. I don't think you are being fair here.
How about this, the clock is ticking on you getting clarification from Bruce about all this.
We can keep it between you and me.
Or to show us where Adobe RGB (1998) falls outside ProPhoto RGB gamut.
For the nth time see the image below and let me know if you can interpret it:
http://djjoofa.com/data/images/adobe_prophoto_rgb.gif
Is there a reason you can’t or will not show us visually using either Bruce’s gamut mapping on his site, or using tools already mentioned, where Adobe RGB falls outside ProPhoto gamut? The tools are broken, the profiles are invalid, the graph on Bruce’s site is faulty?
I have not seen what Bruce's gamut is showing. I tried it on my Mac but it was not loading with my firefox browser. I don't know why.
Listen: I don't think you are in a mood to learn this stuff. I can make an error and everybody including Bruce also can make a mistake. So making a mistake is not the point. The point is that you are not showing any indication to learn what I have been trying to tell you. I can only do so much effort. I don't think it is going forward. It is up to you if you want to take it forward.
Best regards,
Joofa
-
as said in the respective post: ProPhoto (wireframe) and AdobeRGB white - both unaltered - in relation to D50.
That's the grapher of Chromix Color Think ...
So in absolute terms this is the correct visual representation. But it's useless...
Hi,
I don't think it is useless. I think it shows what I am trying to say that the Adobe RGB (D65) blue region is not representable in Prophoto (D50).
as it shows something that will never happen.
Why not. I just gave an example of a color of XYZ=[0.188185 0.075274 0.991108]
In a (real) color managed workflow the above mentioned visual representation of Bruce Lindbloom's grapher is relevant.
That's why I don't understand what you try to achieve.
Andrew is right.
IMO.
IMHO ...
Since, so many people are talking about Bruce's graph which are not loading on my computer, I suspect that he might have done what MarkM has done above with his calculation. I.e., to normalize white points from Adobe (D65) to Adobe (D50), and this is how I think your second graph was generated that shows the gamut enclosed within and not extending out the mesh as in your first graph. If that is the case, then I don't think that it is right to apply Bradford here without taking necessary precaution, because that will convert the coordinate system of Adobe (D65), which we want to retain, to Adobe (D50) and then XYZ=[0.188185 0.075274 0.991108] does not have the representation [0,0,1], which it has in Adobe (D65).
I think that is the basic error. Of course, I could be wrong. But I see that as an error. Repeat: After Bradford transformation the representation of [0,0,1] changes because one has changed the coordinate system.
EDIT: One can still apply the Bradford, but since the representation of [0,0,1] has changed, one has to figure out what is the right representation of that in the new coordinate system after the application of Bradford. I suspect that is what is going on here and perhaps in Bruce Lindbloom's graph (though I have yet to see them.)
Thanks,
Sincerely,
Joofa
-
I don't think it is useless. I think it shows what I am trying to say that the Adobe RGB (D65) blue region is not representable Prophoto (D50).
(...)
I just gave an example of a color of XYZ=[0.188185 0.075274 0.991108]
no. not your beloved numbers.
A real workflow example: under which conditions (which tools?) is the highest saturated blue of AdobeRGB not represented in ProPhoto?
Why don't you see any color shift when you convert a pure white from ProPhotoRGB to AdobeRGB and vice versa?
-
no. not your beloved numbers.
A real workflow example: under which conditions (which tools?) is the highest saturated blue of AdobeRGB not represented in ProPhoto?
Why don't you see any color shift when you convert a pure white from ProPhotoRGB to AdobeRGB and vice versa?
Tho_mas, XYZ=[0.188185 0.075274 0.991108] is the highest saturated blue of Adobe RGB (D65).
Sincerely,
Joofa
-
Tho_mas, XYZ=[0.188185 0.075274 0.991108] is the highest saturated blue of Adobe RGB (D65).
Lab 30|69|-114 is also the highest saturated blue of AdobeRGB.
-
Listen: I don't think you are in a mood to learn this stuff. I can make an error and everybody including Bruce also can make a mistake. So making a mistake is not the point. The point is that you are not showing any indication to learn what I have been trying to tell you. I can only do so much effort. I don't think it is going forward. It is up to you if you want to take it forward.
Look, I’m going to start here and go backwards, then I’m bowing out because your attitude, language and efforts here have progressively convinced me you are wasting my time and others. If your idea of educating us is dismissing what we suggest, ignoring questions posed and acting like a bonehead, yes, I’d prefer not to learn from you. Lets start with this:
How about this, the clock is ticking on you getting clarification from Bruce about all this.
We can keep it between you and me.
Now why would we want to do that? What are you afraid of hearing from Bruce that shouldn’t be shared in this post? That attitude leaves me suspicious of your motives, example 1.
Oh come on. I have provided graphs that I drew showing the Adobe and Prophoto primaries, written detailed and long messages on how to interpret white points, how to generate other coordinate systems in the same 3D color space. I don't think you are being fair here.
Why should I take your one drawing as fact when the half a dozen other utilities I have, that plot the gamuts disagree with your concept? Why are you making no effort to use the utilities and actual profiles that define the gamuts? Example 2.
I have not seen what Bruce's gamut is showing. I tried it on my Mac but it was not loading with my firefox browser. I don't know why.
So you are on a Mac, and you can’t even launch the browser that does work and shipped with your Mac, Safari? Nor can you also launch the ColorSync utility, also part of the Mac utilities that would again allow you to plot the gamuts of the two color spaces. You are making zero effort to see what multiple utilities built for theses tasks all agree upon. Example 3.
I suspect that is what is going on here and perhaps in Bruce Lindbloom's graph (though I have yet to see them.) I suspect that he might have done what MarkM has done above with his calculation.
So in addition to (presumably) all the various gamut mapping utilities being wrong, myself and others in agreement about the gamut of the two spaces, Mark being wrong, Sandy being wrong, now Bruce is wrong too? Example 4.
But you are correct and we are to take the illustration you built as proof of concept?
You can use a different browser and view Bruce’s plots and again, take up his “errors” with him which you don’t see to want to do. You can view the gamuts in the Colorsync Utility. You can download a demo of ColorThink which in that mode WILL plot the 3D gamuts of the two spaces discussed. At such a point, can you tell us, yes or no, where you see Adobe RGB (1998) exceeding the gamut of ProPhoto RGB anywhere in color space? If not, as the rest of us can clearly see, are you suggesting that Adobe, the profiles, the gamut viewers, the color scientist and his site are wrong, but the illustration you built, IS correct? Otherwise, this is just an exercise in you expressing verbal diarrhea, a process I no longer wish to be part of.
-
Lab 30|69|-114 is also the highest saturated blue of AdobeRGB.
Hi,
XYZ=[0.188185 0.075274 0.991108] is the highest saturated blue in Adobe RGB (D65). Its representation in Propho (D50) is RGB = [0.183388 0.031393 1.201037].
You double check that using Bruce Lindbloom' matrix for conversion from Prophoto RGB to XYZ:
0.79767 0.13519 0.03135
0.28804 0.71187 0.00009 * [0.183388 0.031393 1.201037]' = [0.188185 0.075274 0.991108].
0.00000 0.00000 0.82521
You see that 1.20, which means that 1.20 times the unit stimuls of Prophoto blue primary will be required to match it so it is clipped in Prophoto (D50). I hope you see it now. And, it would appear this is what your first image shows.
Joofa
-
Why don't you see any color shift when you convert a pure white from ProPhotoRGB to AdobeRGB and vice versa?
If I am understanding correctly,
1. 'pure white' in one, with its native illuminant, does not have the same XYZ coordinates as 'pure white' in the other, in its native illuminant; at least when, as in this case, the native illuminants used to specify the two color spaces differ.
2. Part of the point of chromatic adaptation is to map whites from different illuminants to one another (providing three constraints on the nine components of a 3x3 adaptation matrix).
3. Part of color space conversion must involve chromatic adaptation, otherwise there will be a color shift.
4. I would presume that Photoshop works internally with colors already adapted to a common illuminant, as Joofa is doing. Otherwise, in the short integer representation they use, white in some color spaces might be out of the 16-bit data range, resulting in white not being representable in some color spaces. It would make much more sense to adapt everything to say D50. If I am understanding correctly, this is what Joofa is calling AdobeRGB (D50). It is not the same as the AdobeRGB (1998) spec, it will be as close as the chromatic adaptation allows. Does anyone know if this is how Adobe does things (and can tell)?
-
XYZ=[0.188185 0.075274 0.991108] is the highest saturated blue in Adobe RGB (D65).
Lab 30|69|-114 is also the highest saturated blue of AdobeRGB.
-
Does anyone know if this is how Adobe does things (and can tell)?
According to Chis Cox there:
Which Illuminant type does Adobe use to define their LAB color space data?
D50 / 2 degree --- same as the ICC V2 CIE LAB PCS definition.
-
Lab 30|69|-114 is also the highest saturated blue of AdobeRGB.
What is that supposed to mean?
-
Does anyone know if this is how Adobe does things (and can tell)?
The internal space is Prophoto primaries, D50, linear light (aka gamma =1). Readouts e.g., on Lightroom, however have an sRGB gamma curve.
Sandy
-
If I am understanding correctly,
Hi Emil,
Nice to see you here. Well you always understand correctly. :D
1. 'pure white' in one, with its native illuminant, does not have the same XYZ coordinates as 'pure white' in the other, in its native illuminant; at least when, as in this case, the native illuminants used to specify the two color spaces differ.
Yes, because in their native spaces, both have tristimulus [1,1,1], but in absolute terms (XYZ) they represent different colors.
2. Part of the point of chromatic adaptation is to map whites from different illuminants to one another (providing three constraints on the nine components of a 3x3 adaptation matrix).
Yes, say so D65 white [0.95, 1, 1.08] goes to D50 white [0.96, 1, 0.83]. In their respective spaces both have representation [1,1,1]. But they differ in XYZ, of course, i.e.,
(a) [0.95, 1, 1.08] in D65 space has tristimuls [1,1,1].
(b) [0.96, 1, 0.86] in D50 space has tristimuls [1,1,1].
(c) [0.95, 1, 1.08] in D50 does not have tristimuls [1,1,1] <------------ This causes confusion for some.
(d) [0.96, 1, 0.86] in D65 does not have tristimls [1,1,1] <------------ This causes confusion for some.
3. Part of color space conversion must involve chromatic adaptation, otherwise there will be a color shift.
Color spaces are related by an affine transformation (okay linear). That is all that is needed. What many don't realize is that if the color space primaries are kept the same but the white point is moved, then that affine transformation is identified by a fancy name - Bradford/von Kries/etc- like chromatic adaption.
A color space is just a vector space. Given any 3 linearly independent bases (RGB) one cay figure out the coordinates in a different set of RGB basis. White point is only used to set the length of "unit vector" as I explained here:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412251#msg412251
4. I would presume that Photoshop works internally with colors already adapted to a common illuminant, as Joofa is doing. Otherwise, in the short integer representation they use, white in some color spaces might be out of the 16-bit data range, resulting in white not being representable in some color spaces. It would make much more sense to adapt everything to say D50. If I am understanding correctly, this is what Joofa is calling AdobeRGB (D50). It is not the same as the AdobeRGB (1998) spec, it will be as close as the chromatic adaptation allows. Does anyone know if this is how Adobe does things (and can tell)?
Digital Dog has mentioned that Adobe is using D50 space in Photoshop. So, I think that will correspond to the following situation in my original note:
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
This is the same mode for which I think MarkM did is calculation after Bradford transformation. So you won't see the clipping in this mode, unless the Adobe RGB (D65) blue primary is correctly figured out after Bradford, and which is no longer [0,0,1].
Sincerely,
Joofa
-
Color spaces are related by an affine transformation (okay linear). That is all that is needed. What many don't realize is that if the color space primaries are kept the same but the white point is moved, then that affine transformation is identified by a fancy name - Bradford/von Kries/etc- like chromatic adaption.
I would have thought the primaries are also shifted by the chromatic adaptation transformation; after all it is a linear map.
The R,G,B primaries define a parallelepiped in linear XYZ space with the white point W at its tip, and R,G,B defining other corners of the parallelepiped; in terms of their vector coordinates, W=R+G+B. If W changes, then the R,G,B primaries do as well. Could the whole issue here be that the XYZ parallelepipeds differ for AdobeRGB (natively D65) and its adaptation to D50, and that the native B primary for AdobeRGB, as a point in linear XYZ space, lies outside Prophoto (natively D50), while the adapted B primary for AdobeRGB (ie mapped to D50) lies within Prophoto? That would be consistent with what I've read so far of this thread (admittedly not a lot), where you are claiming that it does lie outside, while others are looking at gamut viewers like the one on Bruce Lindbloom's site and seeing that Prophoto contains AdobeRGB. But the disclaimer on Lindbloom's site is that all the gamuts shown in the viewer have been adapted to D50.
-
What is the representation of the color XYZ=[0.188185 0.075274 0.991108] in standard Prophoto (D50) color space?
This seems to be the crux of the question, so I will try again.
Your numbers [0.188185 0.075274 0.991108] in XYZ space are going to look different depending on the chromatic adaptation of the viewer. Those numbers are assuming a white point that corresponds to D65. If you want to preserve the color appearance when viewed under D50 you need to account for chromatic adaptation. Using Bradford you get a new set of XYZ numbers: [ 0.14922403 0.06321976 0.74483862].
So now you can say [0.188185 0.075274 0.991108] under D65 will appear the same as [ 0.14922403 0.06321976 0.74483862] under D50. Now you are free to translate to ProPhoto space and preserve appearance. You will get (as I explained above) [ 88 36 241 ].
So the answer to you question quoted above is: [88 36 241]
This matches exactly what you get from photoshop. Consider that before you tell me I'm wrong. You seem to be prepared to say Andrew is wrong, I'm wrong, Adobe is wrong, ColorThink is wrong, etc. and in all this time YOU are the only one who has noticed.
This is really very simple: you are going from one space with one white point to a different space with a different white point. There is no problem here.
-
I would have thought the primaries are also shifted by the chromatic adaptation transformation; after all it is a linear map.
The R,G,B primaries define a parallelepiped in linear XYZ space with the white point W at its tip, and R,G,B defining other corners of the parallelepiped; in terms of their vector coordinates, W=R+G+B. If W changes, then the R,G,B primaries do as well.
Hi Emil,
The case I'm mentioned in that particular message above is where the primaries are kept the same in chrmacity coordinates. Which means that the direction of primaries in 3D are the same. Now if the white point changes, each primary is scaled by a different number so that they become the new "unit stimulus" primary. Think of it like a diagonal matrix multiplication with the matrix of original primaries - direction remain the same, but magnitudes get scaled.
Could the whole issue here be that the XYZ parallelepipeds differ for AdobeRGB (natively D65) and its adaptation to D50, and that the native B primary for AdobeRGB, as a point in linear XYZ space, lies outside Prophoto (natively D50),
Yes.
while the adapted B primary for AdobeRGB (ie mapped to D50) lies within Prophoto? T
Exactly. Glad you are a sane voice here :D
hat would be consistent with what I've read so far of this thread (admittedly not a lot), where you are claiming that it does lie outside, while others are looking at gamut viewers like the one on Bruce Lindbloom's site and seeing that Prophoto contains AdobeRGB. But the disclaimer on Lindbloom's site is that all the gamuts shown in the viewer have been adapted to D50.
I think the situation is becoming clearer now they are adpated to D50 gamuts that is why they don't show the clippings in Prophoto RGB (D50).
Thanks,
Joofa
-
Consider that before you tell me I'm wrong. You seem to be prepared to say Andrew is wrong, I'm wrong, Adobe is wrong, ColorThink is wrong, etc. and in all this time YOU are the only one who has noticed.
Is there any issues with you guys here? Do you have a bad day today. First digital dog went berserk and now you are putting words in my mouth (when did I say Andrew/ColorThink/ etc. are wrong with the wording you seem to suggest.
Look, I'm here to get educated and also contribute my bit. I can make mistakes. Anybody can. Please be patient.
Joofa
-
Hi Emil,
The case I'm mentioned in that particular message above is where the primaries are kept the same in chrmacity coordinates. Which means that the direction of primaries in 3D are the same. Now if the white point changes, each primary is scaled by a different number so that they become the new "unit stimulus" primary. Think of it like a diagonal matrix multiplication with the matrix of original primaries - direction remain the same, but magnitudes get scaled.
From what I understand reading Lindbloom's site, this is true for one form of chromatic adaptation (what he calls XYZ scaling). The other transformations (eg Bradford, which he uses for his considerations) involve a more non-trivial linear transformation on the coordinates.
I think the situation is becoming clearer now they are adpated to D50 gamuts that is why they don't show the clippings in Prophoto RGB (D50).
Which begs the question, why would one be interested in comparing the primaries for two gamuts under different illuminants, without adaptation? It's a little like saying that the blues can be clipped when using a too low value of the color temp in an image. Well, yes, but so what?
-
Joofa, the mistake you are making is very simple: when you are using the RGB -> XYZ matrices you are not accounting for the different reference white points. Bruce Lindbloom is explicit about this in the implementation notes. (read note number 2 here: http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html )
You are plotting converted RGB values on the same XYZ graph without accounting for the different white points. If you account for the different white points, your problems go away. If you don't, you are comparing apples and oranges.
In case you don't feel like clicking on the link, here is Bruce's implementation note for using the matrices:
"Be careful that reference whites are used consistently. For example, sRGB is defined relative to a D65 reference white and ICC profiles are defined relative to a D50 reference white. Mismatched reference whites must be accounted for elsewhere, typically by using a chromatic adaptation algorithm."
-
From what I understand reading Lindbloom's site, this is true for one form of chromatic adaptation (what he calls XYZ scaling). The other transformations (eg Bradford, which he uses for his considerations) involve a more non-trivial linear transformation on the coordinates.
No, no not at all. The situation I described is not XYZ scaling. That is the wrong transform!
Which begs the question, why would one be interested in comparing the primaries for two gamuts under different illuminants, without adaptation? It's a little like saying that the blues can be clipped when using a too low value of the color temp in an image. Well, yes, but so what?
Emil, if you keep the same chromacity coordinates but change the white point, the diagonal scaling I talked about is not XYZ scaling. Please write the equations for these transformations it will be clear to you.
Joofa
-
Joofa, the mistake you are making is very simple: when you are using the RGB -> XYZ matrices you are not accounting for the different reference white points.
Mark, trust me I have taken white point into accounts. Please see one of my responses to Emil above. The original Adobe RGB (D65) blue primary falls outside the Adobe (D50) space (I like Emil's word parallelepiped here) you get after color adaptation.
Joofa
-
Joofa, you keep trying to show that the color [0, 0, 1] in Adobe1998 clips in the ProPhoto space.
I, and others, and photoshop say it doesn't. I even showed you the math. In ProPhoto that color is [88 36 241]. It doesn't clip.
So a simple question: are we wrong?
-
I must say I'm quite intrigued as to the outcome here. I'm no color scientist, far from it, but I'd like to know why, in the Apple Color Synch Utility, Adobe(1998) is depicted as entirely within ProPhotoRGB (as i'd expect) and yet if I view the same profiles in ColorThink 2.2 there is a clear difference, the Adobe(1998) blue primary is outside the ProPhotoRGB space. I don't have ColorThink V3Pro to compare with.
-
Nick, I don't have 2.2 to compare, but I've attached the graph from ColorThink 3 showing the Adobe98 (red wireframe) with the ProPhoto (colored wireframe) in xyY Obviously a little hard to see when you can't spin it, but adobe98 is completely inside the prophoto space.
-
Joofa,
This can basically be illustrated in Photoshop as well:
with a Granger Rainbow in Adobe RGB, and a customized Proof setup to ProPhoto RGB while using the Absolute Colorimetric rendering intent, the Gamut Warning will indicate massive clipping of blue hues as well as of close-to-white colors. Right the way as given in 3D below. Of course, the out-of-gamut marks disappear when changing the Proof setup to RelCol rendering.
In case it doesn't work - which may depend on the Photoshop version used - go to Color Settings and change the Color Engine from Adobe ACE to Microsoft ICM [which is offered when running Photoshop on a Windows platform; no idea about Macs].
Peter
Secondly, I don't know how tho_mas produced the following diagram, but isn't that saying the same thing? Though he thoght otherwise. He said that it is showing profiles. But it seems like blue is projecting out of the mesh. I am no expert in such programs and some of the associated terminology, so may be it is showing something else.
This is the shape of the profiles (abscol to D50; Adobe = white)... but this is just the shape of the profiles, totally independed from any real application:
(http://www6.pic-upload.de/30.12.10/1zwpmhoq7zii.jpg)
-
I must say I'm quite intrigued as to the outcome here. I'm no color scientist, far from it, but I'd like to know why, in the Apple Color Synch Utility, Adobe(1998) is depicted as entirely within ProPhotoRGB (as i'd expect) and yet if I view the same profiles in ColorThink 2.2 there is a clear difference, the Adobe(1998) blue primary is outside the ProPhotoRGB space. I don't have ColorThink V3Pro to compare with.
I think this post from the ColorSync list explains this and some of the misunderstandings below:
At 1:02 AM -0700 6/27/06, Marco Ugolini wrote:
When people refer to ProPhoto RGB as a wide-gamut space, one tends to think
that since it's purported to be "larger than AdobeRGB", it must *encompass*
it all the way around. That assumption is incorrect: there is a relatively
small but noticeable range of cyans and purples in AdobeRGB that falls
outside the gamut of ProPhoto RGB.
Marco, that's an artifact of some but not all 3D graphers. Adobe RGB is D65, ProPhoto is D50, and ColorThink, for example, shows some Adobe RGB (and even some sRGB) colors as being outside ProPhoto because the neutral axis is skewed.
In fact, ProPhoto does encompass Adobe RGB. I'm about to board a plane for foreign parts so I probably won't be able to discuss this at length, but check with reliable sources (Steve Upton, for example). I'm sure they'll tell you the same thing.
Bruce Fraser
-
Joofa, you keep trying to show that the color [0, 0, 1] in Adobe1998 clips in the ProPhoto space.
I, and others, and photoshop say it doesn't. I even showed you the math. In ProPhoto that color is [88 36 241]. It doesn't clip.
So a simple question: are we wrong?
Seriously, this issue is less complicated then it has been made out to be. Chromatic adaption is not even an issue here. You will see below.
Lets deal this issue in two stages:
(A) There is a color with XYZ=[0.188185 0.075274 0.991108]; is that representable in Adobe RGB (D65) and PropPhoto RGB (D50)?. By representable we shall mean if the tristimuls values required to match these colors are in [0,1] range.
Both matrices from Bruce Lindbloom's website below:
Adobe RGB (D65):
===========
0.5767309 0.1855540 0.1881852
0.2973769 0.6273491 0.0752741 * [0,0,1]' = [0.188185 0.075274 0.991108];
0.0270343 0.0706872 0.9911085
Since the trisimulus is [0,0,1], this color is representable in Adobe RGB (D65).
Prophoto RGB (D50):
=============
0.79767 0.13519 0.03135
0.28804 0.71187 0.00009 * [0.183388 0.031393 1.201037]' = [0.188185 0.075274 0.991108].
0.00000 0.00000 0.82521
Since tristimulus value is [0.183388 0.031393 1.201037], where the blue component 1.2 exceeds one, so the color is not representable in Prophoto RGB (D50).
That is why in tho_mas' top figure it shows Adobe RGB (D65) ripping out through Prophoto RGB (D50).
(B) Why doesn't Bruce Lindbloom and some others show Adobe RGB gamut ripping out through ProphotoRGB?
Because, after the chromatic adaption multiplication the gamut is changed from Adobe RGB (D65) to Adobe RGB (D50). In the parallelepiped of Adobe RGB (D50), the color XYZ=[0.188185 0.075274 0.991108] is outside the gamut, so in all likelihood Bruce and others strip that and don't show it. So they only show the legal colors inside this new gamut which gets nice transformed to Prophhoto RGB (D50) gamut.
This situation is the second image of tho_mas. If you line both of them vertically you will notice that Prophoto RGB gamut volume visually looks the same but the Adobe RGB gamut has visibly shrunk in the blue area.
Regarding your calculation that XYZ=[0.188185 0.075274 0.991108] in Adobe RGB (D65) gets mapped to XYZ=[ 0.14922403 0.06321976 0.74483862] in Adobe RGB (D50) after Bradford color transformation, that has nothing to do with it. Because the color XYZ=[0.188185 0.075274 0.991108] has not ceased to exist in the universe! It is still there but it is out of Adobe RGB (50) gamut, so does not get shown in conversion of Adobe RGB (D50) to Prophoto RGB (D50) which you have done essentially.
Hope that helps.
Joofa
-
Joofa,
This can basically be illustrated in Photoshop as well:
with a Granger Rainbow in Adobe RGB, and a customized Proof setup to ProPhoto RGB while using the Absolute Colorimetric rendering intent, the Gamut Warning will indicate massive clipping of blue hues as well as of close-to-white colors. Right the way as given in 3D below. Of course, the out-of-gamut marks disappear when changing the Proof setup to RelCol rendering.
In case it doesn't work - which may depend on the Photoshop version used - go to Color Settings and change the Color Engine from Adobe ACE to Microsoft ICM [which is offered when running Photoshop on a Windows platform; no idea about Macs].
Peter
So glad to hear that Peter you are saying that blue will clip!. I was feeling very lonely here.
Thanks,
Joofa
-
I don't have ColorThink V3Pro to compare with.
Adobe RGB is fully contained within ProPhoto RGB in V3.
-
Joofa, I'm not making it complicated. I asked a very simple question and you replied with a bunch of stuff that did not answer it.
So I'll ask again: I asset that the color [0, 0, 255] in AdobeRGB correctly converts to [88 36 241] in ProphotoRGB without clipping. So does Photoshop. Are we wrong?
It's a yes or no question.
-
Adobe RGB is fully contained within ProPhoto RGB in V3.
Thanks Andrew, I thought this might be the case. V2.2 seems to have some significant flaws, maybe it's time to upgrade.
-
Joofa, I'm not making it complicated. I asked a very simple question and you replied with a bunch of stuff that did not answer it.
So I'll ask again: I asset that the color [0, 0, 255] in AdobeRGB correctly converts to [88 36 241] in ProphotoRGB without clipping. So does Photoshop. Are we wrong?
It's a yes or no question.
Mark, I am so surprised that you are still asking this question after multiple demonstrations. You and Photoshop are not wrong but I have said nth number of times that [0,0,255] in Adobe RGB(D65) and after conversion of this color space via bradford (essentially transferring it to Adobe RGB (D50)) are not the same colors anymore. You guys are tranferring [0,0,255] in Adobe RGB (D50) to ProPhoto RGB (D50). And, I am asking you to tranfer [0,0,255] in Adobe RGB (D65) to Prophoto RGB (D50). Whether these two different representations of [0,0,255] are related by bradford has nothing to do with it. They are two different colors, plain and simple.
Joofa
-
So I'll ask again: I asset that the color [0, 0, 255] in AdobeRGB correctly converts to [88 36 241] in ProphotoRGB without clipping. So does Photoshop. Are we wrong?
This is RelCol right, but AbsCol wrong.
On an absolute scale Adobe RGB 0, 0, 255 = ProPhoto RGB 99, 37, 282
- which means that it is out of ProPhoto RGB's gamut.
Numbers calculated with Bruce Lindbloom's CIE Calculator with (white-point-)-Adaptation set to None.
Cheers! Peter
--
-
On http://www.brucelindbloom.com/iPhone/ColorConv.html
Set AdobeRGB 1998, gamma=2.2, reference white D65, and enter 0-0-255
Press RGB button
Set ProPhoto RGB, gamma=1.8, reference white D50, and press XYZ button
Now you see B>255. That is where the confusion is.
-
This is RelCol right, but AbsCol wrong.
On an absolute scale Adobe RGB 0, 0, 255 = ProPhoto RGB 99, 37, 282
- which means that it is out of ProPhoto RGB's gamut.
Numbers calculated with Bruce Lindbloom's CIE Calculator with (white-point-)-Adaptation set to None.
I’m a bit confused by the post. Where on Bruce’s calculator do you have the ability to alter the rendering intent? Why is adoption set to none? And the RelCol and Absolute intent should produce the same results expect for mapping white.
-
On http://www.brucelindbloom.com/iPhone/ColorConv.html
Set AdobeRGB 1998, gamma=2.2, reference white D65, and enter 0-0-255
Press RGB button
Set ProPhoto RGB, gamma=1.8, reference white D50, and press XYZ button
Now you see B>255. That is where the confusion is.
Thank you Iliah so much for this calculation, which shows that Blue > 255, and so will clip. I must point out though that while Prophoto RGB gamma is 1.8, the value displayed by Bruce before conversion is linear (XYZ=[0.188185 0.075274 0.991108]). So the actual coordinates are even worse in blue, being [46.76, 8, 306.2649], which you can get by selecting gamma=1.0 in the last step. Incidently, 306/255=1.2 for linear calculation, and that is what I reported as case 1 in my note as shown below:
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
Best regards,
Joofa
-
Chromatic adaptation is one of the most abused things in colour management. Sometimes it is forgotten to be applied; sometimes it is applied twice. Gamma is second abused.
-
Joofa, I understand what you are saying. But again, you need to account for the different reference white points when you go between these spaces.
This is what you are trying to do as far as I can tell:
AdobeRGB -> XYZ -> ProPhotoRGB
This is what you need to do:
AdobeRGB -> XYZ -> Account for Chromatic Adaption to D50 ->ProPhotoRGB
This is what Bruce Lindbloom is telling you to do in his implementation notes.
Since you like math, here's a good exercise to drive the point home:
Take your XYZ values [0.188185 0.075274 0.991108] and convert them to LAB space. Before you can make that calculation, you will need to have a reference white point—the calculations require it. What are you going to use as a white point? D65 or D50?
Here's another way to think about it. Take your XYZ values [0.188185 0.075274 0.991108] and imagine you are seeing that color with eyes that are adapted to a white corresponding to D65. Now imagine looking at the color created by the those XYZ numbers with eyes adapted to D50. The color will look different. If you want the color under D50 that looks like the original color (which is the point of color management), a chromatic adaptation calculation will give it to you with reasonable precession: [ 0.14922403 0.06321976 0.74483862]. These two points in XYZ represent the same color appearance under different chromatic adaptations. Adobe 1998 assumes you are looking at colors with eye adapted for D65, ProPhoto assumes you are under D50. If you want to go back and forth you need to account for that.
And yet another way to think about it. Convert White Points
Take white in AdobeRGB [1,1,1]. What should that convert to in ProPhoto RGB? Common sense should tell you: [1, 1, 1]
Use your method of conversion:
(AdobeRGB D65->XYZ Matrix) x [1, 1, 1] = [ 0.9504701 1.0000001 1.08883 ]
This is the XYZ white point of adobeRGB in XYZ. You can convert to chromaticity coordinates an see that is corresponds to D65: 0.3127, 0.3290
Now, using your method with no adaptation, we convert to ProPhotoRGB by directly multiplying it with the transform matrix:
(XYZ -> ProPhoto matrix) x [ 0.9504701 1.0000001 1.08883 ] = [ 0.96801929 1.01290179 1.31945808] (without gamma correction, but it doesn't help)
Think about that result for a minute: we've just used your method to show that white in adobeRGB is out of gamut in PhotoPhotoRGB. This, of course, is absurd.
If you put the chromatic adaptation calculation back in where it belongs you will get a transform that correctly takes AdobeRGB white to ProPhotoRGB white. (along with all the other colors).
-
Mark, I think Iliah has settled this question by showing that blue required > 255 and so will clip. Please see the attachment in his message done using Bruce Lindbloom's calculator.
Thanks,
Joofa
-
And yet another way to think about it. Convert White Points
Take white in AdobeRGB [1,1,1]. What should that convert to in ProPhoto RGB? Common sense should tell you: [1, 1, 1]
Use your method of conversion:
(AdobeRGB D65->XYZ Matrix) x [1, 1, 1] = [ 0.9504701 1.0000001 1.08883 ]
This is the XYZ white point of adobeRGB in XYZ. You can convert to chromaticity coordinates an see that is corresponds to D65: 0.3127, 0.3290
Now, using your method with no adaptation, we convert to ProPhotoRGB by directly multiplying it with the transform matrix:
(XYZ -> ProPhoto matrix) x [ 0.9504701 1.0000001 1.08883 ] = [ 0.96801929 1.01290179 1.31945808] (without gamma correction, but it doesn't help)
Think about that result for a minute: we've just used your method to show that white in adobeRGB is out of gamut in PhotoPhotoRGB. This, of course, is absurd.
Why absurd?. Didn't peter say that:
Joofa,
This can basically be illustrated in Photoshop as well:
with a Granger Rainbow in Adobe RGB, and a customized Proof setup to ProPhoto RGB while using the Absolute Colorimetric rendering intent, the Gamut Warning will indicate massive clipping of blue hues as well as of close-to-white colors. Right the way as given in 3D below. Of course, the out-of-gamut marks disappear when changing the Proof setup to RelCol rendering.
In case it doesn't work - which may depend on the Photoshop version used - go to Color Settings and change the Color Engine from Adobe ACE to Microsoft ICM [which is offered when running Photoshop on a Windows platform; no idea about Macs].
Sincerely,
Joofa
-
Mark, I think Iliah has settled this question by showing that blue required > 255 and so will clip. Please see the attachment in his message done using Bruce Lindbloom's calculator.
Actually he didn't. Sorry Iliah. You need to keep the reference white point set to D65. That's the reference white point for those XYZ numbers.
Nope, you have used the wrong white point here for Prophoto RGB
So do this for me and I think we'll have it cleared up. Show me you math, like you did earlier, including the matrices you're using to get from AdobeRGB[1, 1, 1] to ProPhotoRGB[1, 1, 1]
-
Read closely screenshots and my next post. Also, if chromaticity coordinates are already in XYZ, do they need to be adapted to white point?
-
Also, if chromaticity coordinates are already in XYZ, do they need to be adapted to white point?
It depends on what you are trying to do. If you are moving between color spaces with the intent of preserving color appearance, then yes you need to be mindful of the reference white when working with XYZ numbers. For instance if you are dealing with a small D65 white light, it looks white under D65 (obviously.) If you view it adapted for tungsten, it will look blue. But it's still the same XYZ point. So if you want to preserve color appearance you need to keep in mind the reference white of the source and destination and do the transformation. (That's why I suggested that Joofa try converting to lab—it explicitly requires you keep track of white). If you do it correctly, white in one space, should still be white in the other space even though the white points will have different XYZ numbers. That's what you see when you convert between spaces in photoshop.
-
Yes Cap. We use adaptation to preserve colour appearance, that is while converting. We do not use adaptation when we assign - to see how the numbers will look at a different colour space. Took 5 pages.
-
So if you want to preserve color appearance you need to keep in mind the reference white of the source and destination and do the transformation. (That's why I suggested that Joofa try converting to lab—it explicitly requires you keep track of white). If you do it correctly, white in one space, should still be white in the other space even though the white points will have different XYZ numbers. That's what you see when you convert between spaces in photoshop.
that's why I also suggested to refer to Lab some posts above.
Abscol. even parts of sRGB fall outside of ProPhoto. So what. There is no such thing as abscol when the target profile is matrix based (at least not in conjunction with current CMMs). When the target profile is matrix based the only RI available is always relcol.
So... in abscol terms the highest saturated blue of AdobeRGB falls outside of ProPhoto, sure. And of course also the white of AdobeRGB falls outside of ProPhoto.
But this is something that simply does not happen in a color managed workflow. It only happens when you look at the numbers alone.
When you convert from AdobeRGB to ProPhoto the entire gamut of AdobeRGB is shifted towards the white point of ProPhoto. The shifted color space has still the same shape and likewise the relation of the colors to each other within the gamut are still the same - AdobeRGB is simply shifted to another "location" (plus some chrom. adaption to preserve the appearance).
This is why the entire discussion is so pointless...
edit: just to reiterate the initial post...
This is AdobeRGB (white) and ProPhoto each abscol to D50 (so apples to oranges):
(http://www6.pic-upload.de/30.12.10/1zwpmhoq7zii.jpg)
this is what happens in real color conversions (AdobeRGB and ProPhoto relcol to eachother):
(http://www6.pic-upload.de/30.12.10/3ozvthhv8ia6.jpg)
or referring to Bruce Lindbloom:
(http://www5.pic-upload.de/03.01.11/k12ynvdhqb4c.jpg)
or to iccview.de:
(http://www5.pic-upload.de/03.01.11/v1xox4zsjp8x.jpg)
-
> There is no such thing as abscol when the target profile is matrix based
Just a couple of things. We start in raw and it is assigning colour profile operation, typical for input devices. Only after that comes conversion. On top of that not all converters use "current CMMs".
-
> There is no such thing as abscol when the target profile is matrix based
Just a couple of things. We start in raw and it is assigning colour profile operation, typical for input devices. Only after that comes conversion. On top of that not all converters use "current CMMs".
Sure, but the color space initially assigned to the RAW file is a large color space the respctive RAW converter is based on, then a "camera profile" (or correction matrix) is assigned and first then it is converted to a working space like AdobeRGB or ProPhotoRGB.
Some converters have a built in CMM... but please tell me one converter that can convert from the input profile to a matrix based working space with any other RI than relcol. Talking about the relation of AdobeRGB and ProPhoto in color conversions we always talk about relcol.
-
> the color space initially assigned to the RAW file is a large color space
It is not a good idea to assign a profile to a raw file. RGGB raw is not RGB in the meaning only one component per pixel is known, and G1 is not always filtered the same way as G2. I think saying "large" one should somehow quantify it, at least by comparison to some other known colour space.
> the respctive RAW converter is based on
I'm not sure what you mean saying a raw converter is "based" on some colour space.
> then a "camera profile" (or correction matrix) is assigned and first then it is converted to a working space like AdobeRGB or ProPhotoRGB.
Not sure I understand the above - at least one of the steps you are describing is unnecessary.
> Some converters have a built in CMM... but please tell me one converter that can convert from the input profile to a matrix based working space with any other RI than relcol.
I know a couple.
> Talking about the relation of AdobeRGB and ProPhoto in color conversions we always talk about relcol.
No.
-
> the color space initially assigned to the RAW file is a large color space
It is not a good idea to assign a profile to a raw file. RGGB raw is not RGB in the meaning only one component per pixel is known, and G1 is not always filtered the same way as G2. I think saying "large" one should somehow quantify it, at least by comparison to some other known colour space.
or converted. Not essential here as the target is in any case not a working space.
> the respctive RAW converter is based on
I'm not sure what you mean saying a raw converter is "based" on some colour space.
for instance ACR/LR are based on ProPhoto primaries with a linear Gamma.
> then a "camera profile" (or correction matrix) is assigned and first then it is converted to a working space like AdobeRGB or ProPhotoRGB.
Not sure I understand the above - at least one of the steps you are describing is unnecessary.
re ACR/LR: RAW->ProPhoto linear->"camera profile" (internal with "floating" white point)-> 1 of 4 possible working spaces (output spaces)
re Capture One: RAW->internal color space-> camera profile based on characterization data and tweaked to provide a gamma 1.8 TRC and to provide a certain look (think of tablebased "camera working spaces")-> output color space
(as C1's "camera profiles" are ICC based you can also embed the "camera profile" on output).
> Some converters have a built in CMM... but please tell me one converter that can convert from the input profile to a matrix based working space with any other RI than relcol.
I know a couple.
oh, that's nice for you. thanks for the valuable contribution. I've learnt a lot!
> Talking about the relation of AdobeRGB and ProPhoto in color conversions we always talk about relcol.
No.
thanks again for the comprehensive reply
_______________________________
edit: I stand corrected re abscol.
With Adobe's CMM (i.e. ACE) the only RI available is relcol.
Apple CMM does take the different white points into account as does C1's and RAW Developper's CMM.
I had this article (#21) in mind... but it doesn't refer to abscol -> http://www.colorwiki.com/wiki/Color_Management_Myths_21-25
Sorry!
-
edit: I stand corrected re abscol.
With Adobe's CMM (i.e. ACE) the only RI available is relcol.
Apple CMM does take the different white points into account as does C1's and RAW Developper's CMM.
AbsCol between matrix spaces was definitively possible with Adobe’s color engine in former Photoshop CS.
It does not seem to be possible anymore with Adobe’s color engine in CS 4. As suggested above, changing to Microsoft’s ICM does the trick– for the purpose of testing.
Re. > We start in raw and it is assigning colour profile operation, typical for input devices. Only after that comes conversion.
... but please tell me one converter that can convert from the input profile to a matrix based working space with any other RI than relcol.
Following details on ACR’s matrix profiles were given by Thomas Knoll (Feb. 2004, Rob Galbraith Forum).
It predates the more complex dng profiles which we have now.
Anyway, I’d be surprised if the initial conversion of demosaiced "RAW" RGB data to linear gamma ProPhoto RGB (via such matrices) would include a RelCol-type chromatic adaptation of the white point. It would seem to counteract the sense of the Temp. and Tint slider. Of course, I can’t know.
Peter
----
Quote: >> Camera Raw has 3 by 3 matrix values built in for all its supported cameras (actually two sets, one for 2850K and one for D65, and uses interpolation between them). But these values are measured from one camera (or at most a few averaged). So the 3 by 3 matrix is unlikely to exactly match any given user's camera. Non-standard lightling can also require a different 3 by 3 matrix. So Camera Raw provides a way to tweak this matrix via its controls. A 3 by 3 matrix has 9 degrees of freedom, since it has nine numbers. If you want to tweak 9 degrees of freedom using slider controls, you need nine sliders.
The first degree of freedom is overall scale. This is controlled by the "Exposure" slider. The next two degrees of freedom are the white balance, which are controled by the "Temperature" and "Tint" sliders.
That leaves six degrees of freedom. The usual way these are represented graphically is as a triangle plotted in xy space. The corners of the triangle are the xy coordinates of the red, green and blue primaries of the camera's color space, and define the camera's gamut. What Camera Raw's six hue/sat sliders in the calibration pane are doing is moving the xy coordinates of the triangle corners. <<
-
joofa, I suppose you are making a wrong use of Lindbloom calculator.
As you said, [0.1881852 0.0752741 0.9911085]are the XYZ for a saturated blue in Adobe RGB with D65 white point
For going to ProPhoto D50 :
change the color model to Prophoto and click to the "XYZ" button.
You get [88 36 241].
You have not to change the white reference to D50, as your XYZ values are computed with D65.
The same values you can get using a CMM.
In ICC profiles the transform to PCS is "adapted" to D50, as PCS white reference is fixed from ICC to D50 so XYZ values computed from a CMM are different, but the final RGB ProPhoto values are the same you get from Lindbloom.
Adobe 1998 blue is contained in Prophoto. End of story.
Jacopo
-
joofa, I suppose you are making a wrong use of Lindbloom calculator.
As you said, [0.1881852 0.0752741 0.9911085]are the XYZ for a saturated blue in Adobe RGB with D65 white point
For going to ProPhoto D50 :
change the color model to Prophoto and click to the "XYZ" button.
You get [88 36 241].
You have not to change the white reference to D50, as your XYZ values are computed with D65.
The same values you can get using a CMM.
In ICC profiles the transform to PCS is "adapted" to D50, as PCS white reference is fixed from ICC to D50 so XYZ values computed from a CMM are different, but the final RGB ProPhoto values are the same you get from Lindbloom.
Adobe 1998 blue is contained in Prophoto. End of story.
Jacopo
I thought this would be a settled issue by now.
Please have a look at the attachment to Iliah Borg's first message in this thread where he works the calculation using Bruce Lindbloom's calculator to show that blue required > 255 and so will clip.
Joofa
-
joofa, I suppose you are making a wrong use of Lindbloom calculator.
My suspicions too, and the reason why he might refuse to look at tools he has on his system today that others have used to illustrate the gamut of the two spaces (in 3D no less)!
You have not to change the white reference to D50, as your XYZ values are computed with D65.
Yup, again, its user error. And Mark tried to explain this in post #29, it was ignored.
In ICC profiles the transform to PCS is "adapted" to D50, as PCS white reference is fixed from ICC to D50 so XYZ values computed from a CMM are different, but the final RGB ProPhoto values are the same you get from Lindbloom.
Adobe 1998 blue is contained in Prophoto. End of story.
Agreed on both points!
This is why the entire discussion is so pointless...
Amen to that.
What would be useful is starting a new post about the raw processing, the assignment of profiles, the assumed color space. For example, we know the ACR engine uses ProPhoto RGB in a linear TRC for processing. But I don’t believe Adobe assumes this is the color space (if we can use that term loosely at this point) as the mapping from the assumed spectral sensitivities of the chip to XYZ to get to ProPhoto.
-
What would be useful is starting a new post about the raw processing, the assignment of profiles, the assumed color space. For example, we know the ACR engine uses ProPhoto RGB in a linear TRC for processing. But I don’t believe Adobe assumes this is the color space (if we can use that term loosely at this point) as the mapping from the assumed spectral sensitivities of the chip to XYZ to get to ProPhoto.
Andrew,
The ACR mapping is camera to XYZ D50 referred, then from that to RIMM space (ProPhoto gamma 1). The camera to XYZ D50 conversion includes the color temperature transform - according to Eric Chan (if I understood him correctly anyway), a color temp adjustment in ACR/LR reaches all the back up the processing pipeline to the raw data.
The process is laid out in section 6 of the DNG spec: "Mapping Camera Color Space to CIE XYZ Space"
Regards,
Sandy
-
My suspicions too, and the reason why he might refuse to look at tools he has on his system today that others have used to illustrate the gamut of the two spaces (in 3D no less)!
Ha ha, Digital Dog you are funny. Why have you chosen to ignore Ilaih Borg's calculation. He is participating in this discussion. Why don't you ask him?
Joofa
-
Please have a look at the attachment to Iliah Borg's first message in this thread where he works the calculation using Bruce Lindbloom's calculator to show that blue required > 255 and so will clip.
This is Iliah's use of the calculatorr:
Set AdobeRGB 1998, gamma=2.2, reference white D65, and enter 0-0-255
Press RGB button
Set ProPhoto RGB, gamma=1.8, reference white D50, and press XYZ button
Now you see B>255.
It is wrong.
After getting XYZ from Adobe1998 (using D65 white reference), you get XYZ D65.
You have not to change the white reference to go to ProPhoto.
If you change the white reference from D65 to D50, the calculator assumes that the XYZ values are D50 not D65.
The result is wrong.
If you want to follows the ICC profile way:
Set AdobeRGB 1998, gamma=2.2, reference white D50, and enter 0-0-255
Press RGB button
(you get XYZ D50)
Set ProPhoto RGB, gamma=1.8, reference white unchanged (D50), and press XYZ button
You get same values for ProPhoto [88 36 241].
Jacopo
-
It is not wrong, I forced "assign", which explains what is happening.
-
If you want to follows the ICC profile way:
Set AdobeRGB 1998, gamma=2.2, reference white D50, and enter 0-0-255
Press RGB button
(you get XYZ D50)
Set ProPhoto RGB, gamma=1.8, reference white unchanged (D50), and press XYZ button
You get same values for ProPhoto [88 36 241].
Results are different when Adaptation is set to None,
which is what AbsCol does, as opposed to RelCol - afaik.
Peter
--
-
Why have you chosen to ignore Ilaih Borg's calculation.
Why are you ignoring at least three ways to view the gamut of the two, in 3D based on at least two software products on that Mac you say you have? The third product is simply a download away.
-
It is not wrong, I forced "assign", which explains what is happening.
What do you mean?
It is wrong as you said to calculator that the XYZ values are D50 and they are D65.
Results are different when Adaptation is set to None, which is what AbsCol does, as opposed to RelCol
Of course, but if you use asbsolute you are going to a destination color space with the same white of the source color space.
This is not the way for verifying if a source color is in the destination gamut.
Jacopo
-
It is not wrong, I forced "assign", which explains what is happening.
Yes. Try doing it with 50% grey and you will see that you introduce a nasty color cast. Keeping the ref. white at D65 gives you [0.428622, 0.428622, 0.428622]. Grey stays grey which is what one should expect between these spaces. It also agrees with Photoshop.
This is not the same as converting vs. assigning a profile. If you wanted to just assign ProPhoto, you would just keep the original rgb numbers the same. (Makes the math pretty simple). In the case of assigning you would still expect neutral grey to map to neutral grey in two well behaved working spaces.
which is what AbsCol does, as opposed to RelCol - afaik
I'll be the first to admit that I have trouble parsing the ICC specs especially concerning V.2 rendering intent, but I'm pretty sure you need to account for chromatic adaptation when moving into the connecting space regardless of rendering intent. Once there you can choose to scale to your media white point (which also needs to be in D50 by now) or not depending on you intent. Of course I'm prepared to be wrong on this point if there's someone here with a good understanding of calculating rendering intent.
[Edit: the version 4 spec is more explicit:
"6.2 Rendering intents: The colorimetric rendering intents operate on measurement-based colorimetric values as chromatically adapted to the PCS illuminant D50."]
-
Seems to me, there are two processes here for analyzing and viewing the gamut of the two spaces. One group is using a toolset on Bruce Lindbloom’s site to produce values they say prove that colors in Adobe RGB (1998) exceed ProPhoto. But there are a lot of options to select in the calculator, arguments (or misunderstandings?) about what options to pick etc. I really think those that feel this tool provies their point contact Bruce and have him settle this method of analysis. Clearly, one can select (or not select) something on his site to make the values “prove” their point. Too much wiggle room here!
Then on Bruce’s site, he has his own 3D Gamut mapper. Now at least one person here is unable, or unwilling to use the browser that his OS installed to view the two gamuts in question. That alone provides clues to whether or not this discussion is at all worthwhile! Others here have similar tools that agree with Bruce's own grapher in terms of the gamut of the two spaces in question. The proponents of the “Adobe RGB (1998) has colors outside ProPhoto gamut” would serve their arguments better by telling us why at the very least, 4 different such tools that simply require one to specify two color spaces (most often based on existing ICC profiles we use), doesn’t agree with their ideas about Adobe RGB (1998)’s gamut limitation compared to ProPhoto RGB. No need to mess with rendering intents, white point adaptation, these are tools for mapping color space gamut we’ve had for years. Are they wrong? Does the one calculator with all the options prove they are wrong? Or that the gamut plots shown are wrong based on some settings (but not all) of a web based color calculator of which only the designer (Bruce) can confirm or deny.
This doesn’t have to be rocket (or color) science. Its really easy to plot the gamuts of the two spaces 3 dimensionally.
-
This doesn’t have to be rocket (or color) science. Its really easy to plot the gamuts of the two spaces 3 dimensionally.
Amen. And for what it's worth, the color science doesn't have to be rocket science either.
-
Andrew,
The ACR mapping is camera to XYZ D50 referred, then from that to RIMM space (ProPhoto gamma 1). The camera to XYZ D50 conversion includes the color temperature transform - according to Eric Chan (if I understood him correctly anyway), a color temp adjustment in ACR/LR reaches all the back up the processing pipeline to the raw data.
The process is laid out in section 6 of the DNG spec: "Mapping Camera Color Space to CIE XYZ Space"
Regards,
Sandy
I'm not a color scientist, but will bring up the following for discussion:
As I recall from a previous post by Thomas Knoll on one of the Adobe forums, XYZ does not have a white point. The original color matching experiments were done with emissive monochromatic sources that were roughly red, green, and blue projected on a white screen. The actual wavelengths were chosen for convenience. According to Wikipedia (http://en.wikipedia.org/wiki/CIE_1931_color_space#Construction_of_the_CIE_XYZ_color_space_from_the_Wright.E2.80.93Guild_data), " The primaries with wavelengths 546.1 nm and 435.8 nm were chosen because they are easily reproducible monochromatic lines of a mercury vapor discharge. The 700 nm wavelength, which in 1931 was difficult to reproduce as a monochromatic beam, was chosen because the eye's perception of color is rather unchanging at this wavelength." The subjects in the experiments matched a given color that was projected on by screen by adjusting the intensities of the three sources that were projected on the screen adjacent to the color to be analyzed. Negative values were need to match some colors as explained in the Wikipedia article. The actual XYZ values were derived mathematically. The subjects in the Wright and Guild experiments presumably were adapted to some color of light, but that is not stated in the article. In any event, the XYZ stimulus values can be related to actual wavelengths of light. The primaries for the various color spaces such as AdobeRGB and ProPhotoRGB can be expressed in an absolute manner in terms of the related CIE xyY values. In CIE L*a*b and the various RGB spaces one must include a white point in order to define a color.
D50 is usually used for this purpose. The articles talk about Illuminant E, which is not a spectrum of a black body radiator, but has equal XYZ tri-stimulus values.
With these considerations, what exactly is XYZ D50 or D65?
Regards,
Bill
-
XYZ does not have a white point.
Hi Bill,
The natural white point in XYZ space is [1,1,1].
With these considerations, what exactly is XYZ D50 or D65?
There is no XYZ (D50) or XYZ (D65). There can be only stuff such as RGB (D65) or RGB (D50), etc. Because, the fundamental rule is not to mess with either the state of Texas, or the XYZ coordinate system. Technically, one could have done, say XYZ (D50), and there is nothing stopping that as there is no special difference between XYZ or any RGB in that both are just coordinate systems, but that would mess up the structure of colorimetry. You need one canonical reference coordinate system. And, XYZ ([1,1,1]) is that.
Sincerely,
Joofa
-
> Try doing it with 50% grey
It is a known fact, and I already said it 2 times. Assign does not preserve colour appearance. I do not see what to argue about. Tools are just tools, one needs to know how to use those properly and how to interpret results. By the way, XYZ is also an RGB space - sort of. So, yes - one can use assign here too, ignoring adaptation.
-
..., but I'm pretty sure you need to account for chromatic adaptation when moving into the connecting space regardless of rendering intent.
Look, any plain 2D CIE xy plot will show us two different points for D65 white and D50 white.
Simply two different points with different CIE xy coordinates.
/> Adobe RGB per definition is D65.
/> CIE xy / XYZ / Lab is often referred as D50 but it is finally irrelevant here
/> ProPhoto RGB per definition is D50
When we map Adobe RGB's D65 white via CIE xy / XYZ / Lab to ProPhoto RGB there two different options:
1.) RelCol will move the D65 white onto D50 white. Chromatic adaptation is assumed and needed to do so.
2.) Whereas with AbsCol, Adobe’s D65 white should be kept right where it is on the D65 point. At least some CMMs still do so, and it seems to me intuitively correct according to the term "absolute colorimetric". No chromatic adaptation desired or needed here. Without chromatic adaptation, D65 white is a non-neutral color in the D50 target space (actually it is even clipped).
What 3D adds to party it to illustrate that in case 2.) i.e. without chromatic adaptation from D65 to D50 white
Adobe RGB’s blue primary is out of ProPhoto RGB.
Peter
--
-
As I recall from a previous post by Thomas Knoll on one of the Adobe forums, XYZ does not have a white point. The original color matching experiments were done with emissive monochromatic sources that were roughly red, green, and blue projected on a white screen. The actual wavelengths were chosen for convenience. According to Wikipedia (http://en.wikipedia.org/wiki/CIE_1931_color_space#Construction_of_the_CIE_XYZ_color_space_from_the_Wright.E2.80.93Guild_data), " The primaries with wavelengths 546.1 nm and 435.8 nm were chosen because they are easily reproducible monochromatic lines of a mercury vapor discharge. The 700 nm wavelength, which in 1931 was difficult to reproduce as a monochromatic beam, was chosen because the eye's perception of color is rather unchanging at this wavelength." The subjects in the experiments matched a given color that was projected on by screen by adjusting the intensities of the three sources that were projected on the screen adjacent to the color to be analyzed. Negative values were need to match some colors as explained in the Wikipedia article. The actual XYZ values were derived mathematically. The subjects in the Wright and Guild experiments presumably were adapted to some color of light, but that is not stated in the article. In any event, the XYZ stimulus values can be related to actual wavelengths of light. The primaries for the various color spaces such as AdobeRGB and ProPhotoRGB can be expressed in an absolute manner in terms of the related CIE xyY values. In CIE L*a*b and the various RGB spaces one must include a white point in order to define a color.
D50 is usually used for this purpose. The articles talk about Illuminant E, which is not a spectrum of a black body radiator, but has equal XYZ tri-stimulus values.
XYZ is indeed an absolute measure of color. In other words, you can relate a XYZ color to the wavelength of a radiating body one-to-one. the problem is, our eyes don't see absolute color, they see relative to the general ambient surroundings. The best known aspect of this adaption is the well known "red shift" or scoptic effect. Which is why we have the whole color temperature adventure. So, a color patch radiating a particular XYZ combination will appear different in color depending on what our eyes are adapted to at the time.
Now I don't like Adobe's terminology here, but as best as I can translate it in non-mathematical form, what they are saying when they talk about XYZ D50 is that the output color rendering will show a D50 XYZ color as white. So the matrixes in the raw to XYZ computation are built such that the appropriate XYZ for any given color temperature will become white in RIMM space. Put in alternate form, what it says is that when translating into an output referred space, the white reference is D50.
Sandy
-
Tools are just tools, one needs to know how to use those properly and how to interpret results.
True, you don't understand how to use Lindbloom calculator and get a wrong result (Adobe1998 blue is outside of ProPhoto gamut).
By the way, XYZ is also an RGB space - sort of.
I don't agree. Do you know how you can define a RGB color space?
So, yes - one can use assign here too, ignoring adaptation.
You can do everythink you like, this doesn't mean that your conclusions make sense.
Jacopo
-
With these considerations, what exactly is XYZ D50 or D65?
It's probably not quite correct to refer to the space as XYZ. It would be more precise to speak of PCS = profile connection space. It's essentially XYZ with a standard illuminant of D50 and defined by ICC.
-
The ACR mapping is camera to XYZ D50 referred
I was trying to go back even a bit farther in the evolution of the transform so to speak. When one says ACR mapping is camera to XYZ, what is “camera”? Is some assumption made, are known spectral sensitivities of the camera being used? If the later, are the “colors” imaginary to us excluded?
-
Disclaimer: I'm not a color scientist, just someone who wants to learn.
I went to Bruce Lindbloom page, and find this info interesting:
Conversion from XYZ to RGB:
The explanation of the algorithm starts with this assumption:
Given an XYZ color whose components are in the nominal range [0.0, 1.0] and whose reference white is the same as that of the RGB system, the conversion to RGB is as follows...
Then in the implementation notes:
If the input XYZ color is not relative to the same reference white as the RGB system, you must first apply a chromatic adaptation transform to the XYZ color to convert it from its own reference white to the reference white of the RGB system
Bruce provides a link to a chromatic adaptation algorithm to convert from XYZ coordinates using a reference white to another set of XYZ coordinates corresponding to another reference white
So in the case of a RGB 0,0,255 in Adobe1998 RGB, D65, we get XYZ 0.1888186; 0.075274; 0.991109 as stated by previous posters
Now if I take those values to the chromatic adaptation calculator and put those values with D65 to obtain a XYZ referred to D50 I get
XYZ 0.149225; 0.063220; 0.744839 as shown in the attached screen capture
If I go back to the color calculator and input those values in the XYZ fields and set ProphotoRGB, D50, I get RGB 87.763290; 35.925802; 240.888952; (shown in the second attachment) which are the same results that you'll get if you leave the D65 reference white with the XYZ coordinates obtained from the blue primary in AdobeRGB, just as Jacopo said.
So, following Bruce instruction on his tools, you should perform a chromatic adaptation and the result is that the blue primary of AdobeRGB 1998 is inside ProphotoRGB
-
So, following Bruce instruction on his tools, you should perform a chromatic adaptation and the result is that the blue primary of AdobeRGB 1998 is inside ProphotoRGB
I believe if you do a chromatic adaption you are comparing the gamuts of Adobe RGB (D50) and Prophoto RGB (D50). The original intent was to compare Adobe RGB (D65) and Prophoto RGB (D50). This is the mistake MarkM, Digital Dog, and you are making.
There is no need of chromatic adaption here, because the Adobe RGB (D65) blue primary is not the blue primary of of Adobe RGB (D50), which you get after chromatic adaption transformation. The new blue primary of Adobe RGB (D50) can be contained within Prophoto RGB (D50), but not the original blue primary of Adobe RGB (D65).
Joofa
-
Why is there no need of chromatic adaptation? It's like saying that you don't need to white balance. Different illuminants yield different XYZ coordinates, and trying to compare color spaces under different illuminants is as pointless as trying to compare the same color space under different illuminants. As someone mentioned earlier, one or the other of the white points of Adobe(D65) and Adobe(50), to use your terminology, is outside the gamut of the other. But so what? When does it ever have an impact on color managed workflow?
-
Why is there no need of chromatic adaptation? It's like saying that you don't need to white balance. Different illuminants yield different XYZ coordinates, and trying to compare color spaces under different illuminants is as pointless as trying to compare the same color space under different illuminants. As someone mentioned earlier, one or the other of the white points of Adobe(D65) and Adobe(50), to use your terminology, is outside the gamut of the other. But so what? When does it ever have an impact on color managed workflow?
Because to do a representation of a color with tristimulus XYZ=[0.188185 0.075274 0.991108], which incidently happens to be the blue primary of Adobe RGB (D65), in Prophoto RGB (D50), you don't need chromatic adaption. Chromatic adaption is done when there is a question of "what would have been the XYZ values if I had shone D50 on my target surface instead of D65, while having D65 tristimulus values?" That is not at all an issue here.
Sincerely,
Joofa
-
> you don't understand how to use Lindbloom calculator
You don't understand that I do. Read some books instead of spending time reading online.
But if you like on-line, "in the CIE XYZ color space, the tristimulus values are not the S, M, and L responses of the human eye, but rather a set of tristimulus values called X, Y, and Z, which are roughly red, green and blue, respectively (note that the X,Y,Z values are not physically observed red, green, blue colors. Rather, they may be thought of as 'derived' parameters from the red, green, blue colors)."
> and get a wrong result
No. The result is correct given certain pre-requisites.
-
I believe if you do a chromatic adaption you are comparing the gamuts of Adobe RGB (D50) and Prophoto RGB (D50). The original intent was to compare Adobe RGB (D65) and Prophoto RGB (D50). This is the mistake MarkM, Digital Dog, and you are making.
I may be making a mistake, I was just following the instructions on the tools in the Bruce Lindbloom site.
When does it ever have an impact on color managed workflow?
I'd like to know if I could lose some deep saturated visible blues while in ProphotoRGB that I could have achieved in AdobeRGB 1998
-
This is the mistake MarkM, Digital Dog, and you are making.
Don't stop there Joofa. It's also the mistake Bruce Lindbloom is making in his implementation notes and the mistake ICC is making in their specification.
there is a question of "what would have been the XYZ values if I had shone D50 on my target surface instead of D65, while having D65 tristimulus values?"
This is wrong too, but in a kind of subtle way. Chromatic Adaptations are NOT correcting for differences in the XYZ numbers arising from different spectral power distributions reflecting off a surface. They are account for the change in retinal response that happens when our eyes adapt to color changes. If you want the gory details I'll refer you to Wyszecki and Stiles, 5.12 ( starting on page 429 in the 2nd edition). This is why you make the round trip trough cone response (ρ, γ, β).
-
> It's also the mistake Bruce Lindbloom is making in his implementation notes and the mistake ICC is making in their specification.
The important thing to note is that XYZ as a PCS is often perceived differently from an absolute, device-independent XYZ.
> I'll refer you to Wyszecki and Stiles
Yes. Absolutely yes. But it is far from being enough.
-
Why is there no need of chromatic adaptation?
Because it provides the results he wishes despite the fact that no one would use such a transformation, as so many here have pointed out.
Don't stop there Joofa. It's also the mistake Bruce Lindbloom is making in his implementation notes and the mistake ICC is making in their specification.
Exactly, but again, using the tools properly when they don’t produce the results you wish to express is moot here. It explains why so many simple gamut viewers tell us the correct answers (and why Joofa refused to even look at them). If you are provided buttons or options in a tool, use them incorrectly but they produce the results you wish, that’s all that counts apparently. I’m actually surprised so many of us are still trying to explain this to him.
-
> and get a wrong result
No. The result is correct given certain pre-requisites.
I would agree that the results based on the tool setting is correct (assuming Bruce has done all his math correctly which is pretty darn likely). But the results in this case are far from real world and are totally theoretical based on settings that make little sense.
-
Don't stop there Joofa. It's also the mistake Bruce Lindbloom is making in his implementation notes and the mistake ICC is making in their specification.
Please don't be melodramatic.
Joofa
-
That's fine Joofa but it doesn't prove you point. Unless your point is that you can plot in 3D. I'm sure a lot of people here can do that. ( I can too, see: Blog post (http://www.photo-mark.com/notes/2010/nov/19/plancks-despair/) and and another (http://www.photo-mark.com/notes/2010/nov/19/plancks-despair/))
CIE XYZ space only guarantees that colors with the same coordinates will match when viewed under the same conditions. When you plot various XYZ values in that space taken under different assumptions, like illuminant, you can't expect to be able to compare them. Plotting them on the same graph becomes meaningless.
-
That's fine Joofa but it doesn't prove you point. Unless your point is that you can plot in 3D. I'm sure a lot of people here can do that. ( I can too, see: Blog post (http://www.photo-mark.com/notes/2010/nov/19/plancks-despair/) and and another (http://www.photo-mark.com/notes/2010/nov/19/plancks-despair/))
Are we in some sort of plotting competition here?
CIE XYZ space only guarantees that colors with the same coordinates will match when viewed under the same conditions. When you plot various XYZ values in that space taken under different assumptions, like illuminant, you can't expect to be able to compare them. Plotting them on the same graph becomes meaningless.
I mentioned before also and I repeat it again. XYZ space does not have a varying notion of white point, because you purposely restrict it. Other RGB spaces, which are schematically no different than RGB, are allowed to have varying white points.
Joofa
-
When you plot various XYZ values in that space taken under different assumptions, like illuminant, you can't expect to be able to compare them. Plotting them on the same graph becomes meaningless.
Nope. Not at all.
Joofa
-
XYZ space does not have a varying notion of white point
Which is why the spec tells you to use PCS. Which is also why your plot doesn't prove anything and isn't relevant.
Look at it this way. Suppose you have a color patch that you would like to measure and you want to determine the coordinates of the color in XYZ space. One way to do this is measure the color with a photospectrometer. The spectrometer will generate a spectral power distribution of the light reflecting off the patch. You can combine the SPD with the 1931 observer data and get the XYZ coordinates. It's not very hard. But here's a very important question: what color light are you going to shine on that patch to build your SPD? This is very relevant if you want to share the XYZ number with someone else and have them be able to reproduce your color, which is why presumably we are doing all this. Depending on the illuminant you will get very different XYZ numbers, Which one will you use to represent the color of your patch?
-
Which is why the spec tells you to use PCS. Which is also why your plot doesn't prove anything and isn't relevant.
You sure about it? I don't think that you have even realized what the plot is telling you.
Look at it this way. Suppose you have a color patch that you would like to measure and you want to determine the coordinates of the color in XYZ space. One way to do this is measure the color with a photospectrometer. The spectrometer will generate a spectral power distribution of the light reflecting off the patch. You can combine the SPD with the 1931 observer data and get the XYZ coordinates. It's not very hard. But here's a very important question: what color light are you going to shine on that patch to build your SPD? This is very relevant if you want to share the XYZ number with someone else and have them be able to reproduce your color, which is why presumably we are doing all this. Depending on the illuminant you will get very different XYZ numbers, Which one will you use to represent the color of your patch?
The reflected color off a patch is a product of spectral illuminant and patch's reflectivity. The product is not a good way to determine the "color" of an object/patch, because as you said, it depends upon illuminant. One way to have (kind of) an invariant specification is if you can figure out the patch's reflectivity coefficient.
Joofa
-
One way to have (kind of) an invariant specification is if you can figure out the patch's reflectivity coefficient
OK. Show me how to get from a reflectivity coefficient to XYZ without an illuminant.
-
Because to do a representation of a color with tristimulus XYZ=[0.188185 0.075274 0.991108], which incidently happens to be the blue primary of Adobe RGB (D65), in Prophoto RGB (D50), you don't need chromatic adaption. Chromatic adaption is done when there is a question of "what would have been the XYZ values if I had shone D50 on my target surface instead of D65, while having D65 tristimulus values?" That is not at all an issue here.
Sincerely,
Joofa
So it's a purely theoretical question, rather than something one need worry about in an image processing context...
-
So it's a purely theoretical question, rather than something one need worry about in an image processing context...
Nope. I think Iliah Borg summed it very nicely when he said something to the effect of chromatic adaptation being abused, sometimes not applied when needed, and sometimes applied twice. I am quite surprised to see a confusion on this topic among some of those people who sign their names as "color experts" here (not you of course, ;D).
Joofa
-
As long as there are all these "color whizes" here ;D, I have a question: Why when going between illuminants of different color temperature (D65 to D50 for example) one does chromatic adaptation; yet when one does white balance in a raw converter to adjust to the color temp of the illuminant, one multiplies the CFA raw data by some scalar multipliers. They are not the same thing, if I understand correctly.
-
Nope. I think Iliah Borg summed it very nicely when he said something to the effect of chromatic adaptation being abused, sometimes not applied when needed, and sometimes applied twice.
I don’t think anyone would disagree that when chromatic adaptation is needed and isn’t applied (or applied twice) its being abused. That’s not the same as saying chromatic adaptation isn’t necessary nor in this context, should not be applied.
I am quite surprised to see a confusion on this topic...
There’s nothing confusing about applying the use (or lack of in this case) of chromatic adaptation when called for to prove a result you desire.
-
Wait. People are surprised that when you shine a blue light on something it looks different to when you shine a red light on it? That's essentially what is being done here. Change from D65 to D50 - might as well be changing from blue to red.
Adobe RGB (1998) is what it is. If you change it then it's no longer Adobe RGB (1998), which means it's incorrect to compare "it" (the variation) with something to counter a comparison made with the "original" version.
You might as well move both spaces to D75 or D41 or whatever, and then compare - your findings will be as pointless.
For anyone worried about "real world" application, I suggest that you do this. Find the most saturated blue thing you can and photograph it. Process the photo using ProPhoto and then using Adobe RGB (1998). Print the results of each (or display or project or whatever). See if you get clipping more or less in one or the other.
-
That multiplication is often referred to as a form of chromatic adaptation. Things are much more complicated however - still this form of chromatic adaptation results in acceptable balance around midtones.
Under certain types of lighting one does not want to apply full adaptation to the scene, and a mix of relative and absolute is used. For some scenes adaptation is applied differently to different parts of scene, like to shadows and highlights it is applied not in the same manner as to midtones - the "mix" is different.
-
2.) Whereas with AbsCol, Adobe’s D65 white should be kept right where it is on the D65 point. At least some CMMs still do so, and it seems to me intuitively correct according to the term "absolute colorimetric". No chromatic adaptation desired or needed here. Without chromatic adaptation, D65 white is a non-neutral color in the D50 target space (actually it is even clipped).
Peter, this has been bugging me all day, but I've only now had a chance to look at the spec and figure out why. First, here's why it bugs me:
This is the ICC spec, where they define relative and absolute intents:
A.3.1.2 Media-Relative Colorimetric Intent
This intent rescales the in-gamut, chromatically adapted tristimulus values such that the white point of the actual medium is mapped to the white point of the reference medium (for either input or output).
A.3.1.3 ICC-Absolute Colorimetric Intent
For this intent, the chromatically adapted tristimulus values of the in-gamut colors are unchanged.
In the context of this thread this is confusing and I just realized that it's because we are talking about working spaces where the white point happens to also be the white point of the illuminant. This isn't always the case, in fact for something like a printer profile it would almost never be the case.
For example my epson 3880 profile for one of the papers has a white point of [.909, .943, .793]. The profile also has a Chromatic adaptation matrix to use when moving into PCS. (It is just diagonal 1.0 so it does nothing because the profile illuminant happens to be D50.) So when we are in PCS space if we want relative colorimetric, we scale the media white point to our output white. If we want absolute we leave it and everything else where it is which means on a monitor or proof the whites will look yellow which is what we want for proofing in situations where we want to preserve paper color.
Now this is where it starts to get a little confusing. The illuminant in the printer profile doesn't have to be D50 (although in practice the mostly are). If my profile had a D65 illuminant instead, it should also have a chromatic adaptation matrix that tells us how to get to D50. (The version 2 ICC spec doesn't require this which has been a problem, in version 4 it's required.) The spec tells us that we need to chromatically adapt our tristimulus values and the media white point to PCS (D50). This doesn't mean the white point of my paper will now equal the white point of D50, it just means that the white point has been adjusted for a different chromatic adaptation state—it will still be warm. The new XYZ numbers just represent how the paper would look under D50 light with eyes adjusted for D50 instead of how it looked under D65 light with eyes adjusted for D65—which is to say the same. If we don't do this step we are working with XYZ numbers representing how the paper looks under D65 light with eyes adjusted for D50. We still have our paper white and it is accurately represented in PCS. Now we can either use it to scale a relative intent or not if we want absolute.
Things get screwy when we talk about working spaces because the white point is the same as the illuminant white point. When we perform the chromatic adaptation per the spec the white points of the two illuminants align and relative and absolute colorimetric rendering are the same. They become meaningless. I'm not sure how other CMMs handle this, but Adobe's CMM seems to confirm this.
This doesn't seem as screwy when you think about what should happen with two papers, A and B, that are identical but you've profiled one with a D65 illuminant and one with D50. The paper whites look the same when they are viewed together and they should look more or less the same when viewed separately under D50 and D65 assuming your eyes have adjust to the illuminant. Now if you make two proofs using each profile and absolute colorimetric rendering, one should expect the proofs to look the same. It seems a little counter-intuitive, but the reason is that the profile is not trying to proof the white point of the illuminant in the profile, it is trying to proof the white color of the paper which is by definition is the same in this case. This works if you follow the ICC specification because the white point in the D65 profile goes through the chromatic adaptation on its way to PCS. In PCS space we can see that regardless of the illuminant used to build the profile, the papers are the same color—they'll have the same XYZ numbers for the same viewing conditions.
That's kind of the long explanation, but I think it ties up some loose ends.
-
Obviously I am not expert on any of these issues, but it does seem to me that this thread has become an argument about how many angels are on the head of pin.
-
One way to do this is measure the color with a photospectrometer. The spectrometer will generate a spectral power distribution of the light reflecting off the patch. You can combine the SPD with the 1931 observer data and get the XYZ coordinates. It's not very hard. But here's a very important question: what color light are you going to shine on that patch to build your SPD?
It would seem to me that one should compare the SPD of the illuminant with the SPD of the reflected light. If the illuminant is a continuous function (such as a black body radiator), one could then construct the appearance for any illuminant, including the XYZ wavelengths. This would involve integration across the visible spectrum.
Regards,
Bill
-
Is gamut of Adobe RGB Fully Enclosed by ProPhoto? Interesting tropic!
I am here to learn and followings are my observation.
Gamut Edge Data
From a different perspective, I examine it with a set of self generated test points. I use the gamut tool in PatchTool to build a RGB edge list, with a pitch of 5 between RGB value. This pitch is sufficiently small to ensure that generated data points are close enough for showing clearly the gamut boundary for both aRGB and ProPhoto RGB.
The generated RGB data (DS0) consists of total 15,608 points which span across the whole RGB gamut boundary. By assigning the data to aRGB and ProPhoto respectively, 3 sets of data were derived. The data were output to xyz and read into CTP3.
Data set 1 (DS1): ProPhoto with illuminant D50 (= ProPhoto)
Data set 2 (DS2): aRGB with illuminant D50 (= Adobe RGB 1998 but shift illuminant from D65 to D50)
Data set 3 (DS3): aRGB with illuminant D65 (= Adobe RGB 1998)
The 3 sets of data were read with CTP3. Followings illustrate their data points in Lab co-ordinate.
(http://2.bp.blogspot.com/_KXuoZvFANPo/TSKFLHbiRII/AAAAAAAAAJM/aS5cclL1weA/s320/322+-+)
(http://4.bp.blogspot.com/_KXuoZvFANPo/TSKFNkeLhsI/AAAAAAAAAJQ/5TaZgLE6Vao/s400/322+-+DS2.png)
Is my data sets tally with the Gamut Plots?
For ProPhoto, the edged data matched nicely with the standard Prophoto gamut, as both are normalised to D50 illuminant.
(http://1.bp.blogspot.com/_KXuoZvFANPo/TSKI-P7LrFI/AAAAAAAAAJU/ZVs1A58BqGo/s320/322+-+ProPhoto%252BDS1.png)
When displaying with CTP3 (ColorThink Pro 3), the gamut (vector) plot for Adobe RGB 1998 was normalised to D50 illuminant. I got email exchange with Danny Pascale @ BabelColor, and he assured me there is nothing wrong with the PatchTool output. I was convinced.
(http://2.bp.blogspot.com/_KXuoZvFANPo/TSKJCBKMDSI/AAAAAAAAAJY/blqRILUWgeo/s400/322+-+aRGB%252BDS2%25263.png)
The Verdict
Let the data speak for itself.
(http://2.bp.blogspot.com/_KXuoZvFANPo/TSKPobc2xWI/AAAAAAAAAJc/KO7bOBnopfw/s1600/323+-+argb%2526prophoto1.png)
(http://1.bp.blogspot.com/_KXuoZvFANPo/TSKRkAD5eVI/AAAAAAAAAJg/pvEjllQ4_yk/s1600/323+-+argb%2526prophoto2.png)
sincerely,
jc1
-
Here's my attempt to construct a true aRGB (1998) profile, based upon 5832 data points and my earlier thought. It was built with a printer profiler, for the seek of displaying the gamut of a True Adobe RGB (1998) @D65 illuminant.
(http://3.bp.blogspot.com/_KXuoZvFANPo/TSK3xACgGYI/AAAAAAAAAJ4/Oifv0QhZt38/s1600/324+-+true+argb+D65+vs+official.png)
(http://3.bp.blogspot.com/_KXuoZvFANPo/TSKtm1MzR7I/AAAAAAAAAJo/GPhDW4eWFxM/s400/324+-+true+argb+D65+gamuts.png)
regards
-
Thanks Jc1 for the interesting plots. It does seem like that Adobe RGB (D65) is going outside Prophoto RGB (D50) gamut in a section from saturated blues to white. Right?
Sincerely,
Joofa
-
Thanks Jc1 for the interesting plots. It does seem like that Adobe RGB (D65) is going outside Prophoto RGB (D50) gamut in a section from saturated blues to white. Right?
Sincerely,
Joofa
Unless someone else prove it otherwise. :)
with regards,
jc1
-
I was trying to go back even a bit farther in the evolution of the transform so to speak. When one says ACR mapping is camera to XYZ, what is “camera”? Is some assumption made, are known spectral sensitivities of the camera being used? If the later, are the “colors” imaginary to us excluded?
Andrew,
The known spectral sensitivities are used; Adobe create matrixes for every camera that's supported by ACR/Lightroom. Colors are clipped to the ProPhoto gamut, but given the size of ProPhoto, in practical terms any color that a real visible light camera can record is captured.
Sandy
-
Why when going between illuminants of different color temperature (D65 to D50 for example) one does chromatic adaptation; yet when one does white balance in a raw converter to adjust to the color temp of the illuminant, one multiplies the CFA raw data by some scalar multipliers. They are not the same thing, if I understand correctly.
I don't know about other raw converters, but with ACR the entire 3x3 conversion matrix changes.
Sandy
-
jc1, you did a nice job on the the graphs, they're cool looking. The conclusion you draw suffers from the same problem Joofa has been having the whole time, though. If I understand what you've done, you are drawing conclusions about points on the same XYZ plot representing two different viewing conditions.
Nobody has had any luck explaining this to Joofa, but I'll try to start from the very beginning and see if it makes sense to you.
The beginning:
1. XYZ space comes from color matching experiments. XYZ by itself doesn't specify a white point or make any assumptions about the viewing conditions. All it really says is that if you have two points in XYZ that are the same, viewed under the same conditions, the colors will match. Lets call that rule number one. That seems obvious, but it's important because you can have colors that have different spectral components that end up being the same XYZ point (metamers). The converse is true too: if two points are different, they don't match under the same viewing conditions.
I don't think anyone disagrees with the above paragraph.
2. So what about when the viewing conditions are different? Specifically when your eyes are adapted to different light sources. Will the color represented by this XYZ point [.75, .5, .30] look the same when your eyes are adapted to a D65 source as it will when your eyes are adapted ti D50? The answer is no, that color under these two different conditions does not match because you are breaking rule number one. You see this all the time in real life life when you view a tungsten-lit window standing outside at dusk. To you, with eyes adapted to the blue evening light, the light looks very yellow. To people inside, it looks white. You'd get the same XYZ point for it, but it's a different color under different chromatic adaptations.
I don't think anyone disagrees with the above either
3. So what about two different XYZ values each viewed under different conditions? Take our original color [.75, .5, .30] viewed with eyes adapted for D65 and this color [0.78, 0.51, 0.23] viewed under D50. Do they match? You can't tell just by looking at the numbers. If you plot them on a 3D chart they are in different spots in the space and you will be tempted to say they don't match. But they do. Color 1 under D65 matches color 2 under D50.
I don't think anyone disagrees with the above either
4. So now suppose you want to compare two colors, under two viewing conditions on the same graph in a way that makes it clear whether the colors match and not. This is what chromatic adaptation is for. You can take you D65 XYZ values, run them through a chromatic adaptation matrix and get a new value that allows you to compare it to the the D50 value to see if it matches or not. Now when you plot them on the same graph you can see real color relationships, you can make judgments about them. If you don't do this you can't—you can't even tell by looking if two XYZ points match or not if you don't account for different viewing conditions.
So when you plot your AdobeRGB gamut assuming chromatic adaptation to D65 on the same chart as ProPhoto adapted to D50 you can't make any judgments about the relationship between the two sets of colors. You've forgot rule number one. Consider the colors in ARGB that look like they are out of gamut—you can't tell that by looking if they match colors in the proPhoto space or not and hence you can't tell if they are out of gamut or not in the same way that you couldn't tell if the colors in no. 3. above matched.
The point of comparing gamuts is to answer the question: if you give me a color from AdobeRGB can I give you a color from ProPhoto that matches it? Can I do that for all colors in AdobeRGB? In order to answer this and tell if the colors match we need to remember rule number one.
If you want to compare these spaces in a meaningful way you need to account for the difference in chromatic adaptation. If you do, all the problems go away and your results will match the established results. To do otherwise is like me standing outside your house insisting that your lights are yellow and you insisting that the are white. If you want to really talk about the color of the light, either I need to go inside, or you need to come outside.
-
Hi joofa,
But ...just to clear my stand.
MarkM has made his point loud and clear which I am aware and agree with. 8)
CIE XYZ space only guarantees that colors with the same coordinates will match when viewed under the same conditions. When you plot various XYZ values in that space taken under different assumptions, like illuminant, you can't expect to be able to compare them. Plotting them on the same graph becomes meaningless.
regards,
jc1
-
jc1, you did a nice job on the the graphs, they're cool looking. The conclusion you draw suffers from the same problem Joofa has been having the whole time, though. If I understand what you've done, you are drawing conclusions about points on the same XYZ plot representing two different viewing conditions.
To MarkM,
Thank you for your times. It's a good learning experience.
Yes, the comparison under different illuminants/viewing conditions is meaningless.
regards,
jc1
-
> the comparison under different illuminants/viewing conditions is meaningless.
It is not, depending on what one is trying to achieve. Is it so difficult to realize that full chromatic adaptation is not something a photographer always needs? Or that chromatic adaption methods in use are often based on pretty rough models?
-
It is not, depending on what one is trying to achieve. Is it so difficult to realize that full chromatic adaptation is not something a photographer always needs? Or that chromatic adaption methods in use are often based on pretty rough models?
Comparison of gamut plots is meaningful unless they are under same viewing conditions. Hope we are on same frequency.
Practically, if 2 similar objects are illuminated each with light source of different colors, it doesn't make sense to compute or compare their color differences. Most of the mathematically functions in color science are well defined and established. An interesting subject. I'm from a different discipline.
regards.
-
If only those mathematical functions you are referring to always surve the purpose and serve it well. Colour science is not "frozen". Fairchild, anybody?
-
To MarkM,
Thank you for your times. It's a good learning experience.
Ditto! A beautifully well composed, clear explanation. A keeper.
-
Comparison of gamut plots is meaningful unless they are under same viewing conditions. Hope we are on same frequency.
Practically, if 2 similar objects are illuminated each with light source of different colors, it doesn't make sense to compute or compare their color differences. Most of the mathematically functions in color science are well defined and established. An interesting subject. I'm from a different discipline.
regards.
Nope, not at all. Consider this. I take a 100% reflective surface and shine D65 on it measure its XYZ, call it A, and then I shine D50 on it measure its XYZ, and call it B. And A is not the same as B! These two different sets of XYZ are related by a color adaption model say, Bradford, but that is all it is about. Now suppose I decide to measure A and B in a system which has Adobe RGB primaries. I have selected my primaries (chromacity coordinates). However, there is still a very important step here that MarkM is not realizing. While I have picked my primaries I have not defined that while measuring A and B which what is my white point. I have two natural choices, either pick D65 or D50, or I can even pick a third unrelated color. But we shall only concentrate on the first two. Adobe RGB (D65) is set to produce a tristimulus value of [1,1,1] for A, but something else for B. What MarkM seems unappreciative of the fact is that when he throws in the Bradford transformation it internally restructures the Adobe coordinate system, so that Adobe RGBs are now set to produce the tristimulus [1,1,1] for B, effectively becoming Adobe RGB (D50). At this stage he forgets about color A, which still exists. And if we measure A in the new system then it will be out of gamut.
Hope that helps.
Sincerely,
Joofa
-
Ditto! A beautifully well composed, clear explanation. A keeper.
+1
@joofa: I suspect Mark understands perfectly well, but prefers to concentrate on the fact that what is relevant for rendering is the color space adapted to the illuminant under which the image was captured. I suspect from the answer given above to my question, that ACR's adjusting of the 3x3 matrix according to color temp is implicitly jiggering the gamut boundaries to contain the relevant set of colors for the measured illuminant. The only way I can see comparing colors under different illuminants to be relevant, is if the scene captured has multiple illuminants (eg, Mark's window example). Then without special treatment, one has to choose an overall illuminant for the scene and its associated adapted gamut, and colors from the other illuminant in the scene might fall outside that gamut even though they can be within the gamut adapted to that other illuminant.
-
The only way I can see comparing colors under different illuminants to be relevant, is if the scene captured has multiple illuminants (eg, Mark's window example). Then without special treatment, one has to choose an overall illuminant for the scene and its associated adapted gamut, and colors from the other illuminant in the scene might fall outside that gamut even though they can be within the gamut adapted to that other illuminant.
Emil, thank you for saying that. Isn't that point of whole exercise that legal colors within a gamut get mapped to out of gamut in another system? Please think about it.
Joofa
-
Hi joofa,
But ...just to clear my stand.
MarkM has made his point loud and clear which I am aware and agree with. 8)
CIE XYZ space only guarantees that colors with the same coordinates will match when viewed under the same conditions. When you plot various XYZ values in that space taken under different assumptions, like illuminant, you can't expect to be able to compare them. Plotting them on the same graph becomes meaningless.
regards,
jc1
Nope, it is not meaningless. MarkM seems unappreciative of the fact there is not a single XYZ coordinate system in this scenario. There are three in the same 3D space! One is the canonical XYZ system whose "unit vector" length is fixed (what I have been "harping" (Emil's word from a distant time ;D) all along and seems to be unacknowledged). The other two are, say Adobe RGB primaries adjusted for (1) white point being D65, and (2) white point being D50. Now you are moving between these three different coordinate systems in the same space.
MarkM takes the simplistic view that two points that are different on XYZ coordinate system can't be meaningfully realized on the same plot since they were derived from two different white points. That is why I provided the 3D plot of CIE XYZ and RGB in relative relationship to each other to help illustrate what is going on here.
Joofa
-
How it all came to the discussion of inertial frame of reference?
-
How it all came to the discussion of inertial frame of reference?
Hi,
If your comment is directed to me then here is my understanding. Assuming linearity of transformations, including chromatic adaption as exemplified by using a linear Bradford matrix, the mechanics of the movement between three coordinate axis in the same 3D space, which I mentioned above, are approximately described by the Bradford transformation.
Sincerely,
Joofa
-
Emil, isn't that point of whole exercise that legal colors within a gamut get mapped to out of gamut in another system. Please think about it.
Joofa
There are several points:
1) A color space A is defined wrt a particular illuminant I. The gamut of allowed colors in that color space (call it G(A,I)) and implicitly referred to that illuminant, is a paralellepiped in XYZ space, three of whose corners are the R,G,B primaries for that color space.
2) Chromatic adaptation maps the parallelepiped of colors in the gamut defined for the reference illuminant, to another parallelepiped G(A',I') of colors referred to another illuminant I'. There are adapted primaries R',G',B'.
3) The adaptation map can be such that the XYZ coordinates of eg the blue primary of A lie outside the parallelepiped G(A',I'). We note this fact and continue.
4) The color 'white' does not have unique XYZ coordinates; it depends on the illuminant, W=W(I). Part of the map G(A,I)->G(A',I') is W(I)->W(I'). W(I) can also lie outside G(A',I').
5) A second color space B' might be defined wrt a different illuminant I', and determine a gamut parallelepiped G(B',I').
6) If we are to discuss a given image being formed by a particular illuminant I", each pixel should have a set of X,Y,Z coordinates determined by the spectral power distribution (SPD) of the illuminant and the surface reflectivities of the objects in the scene.
7) Then to compare the recording of that image in different color spaces A and B', we should be looking at the coordinatization of the colors represented by X,Y,Z as linear combinations of the respective primaries adapted to I" and which may or may not lie within G(A",I") and/or G(B",I"). One can if one wishes then transform the XYZ values to ones determined in the reference color spaces G(A,I) and/or G(B',I') by inverting the chromatic adaptation transform.
8 ) If a viewer wishes to render the image, to be viewed under yet another illuminant I''', then the XYZ values should be mapped by chromatic adaptation to that illuminant. I'''=I and I'''=I' are special cases.
9) There is no point in the above discussion of points (6-8) where it is necessary to discuss either point (3), or whether eg the blue primary of G(A,I) lies outside G(B',I'). The only issue of possible relevance is whether it lies outside of G(B,I). In the case of AdobeRGB and Prophoto, the answer is no, the blue primary of Adobe, properly adapted to the illuminant, lies within Prophoto. This is why I commented that it was a purely theoretical question, without practical import.
At least, this is my current understanding. I am happy to be further illuminated ;) by the experts.
-
There are several points:
Emil, it appears now you are backtracking from your previous comment that "colors from the other illuminant in the scene might fall outside that gamut even though they can be within the gamut adapted to that other illuminant." :D
[snipped a lot of stuff as I got lost. Sorry]
In the case of AdobeRGB and Prophoto, the answer is no, the blue primary of Adobe, properly adapted to the illuminant, lies within Prophoto. This is why I commented that it was a purely theoretical question, without practical import.
Your "blue primary of Adobe, properly adapted to the illuminant" is what I have been calling the blue primary of Adobe RGB (D50). If you go to the back of this thread and start reading my messages again you will see that I have said that blue primary of Adobe RGB (D50) is contained within Prophoto RGB (D50), this is my case (3) presented below, which is copied from the very first note I wrote on this topic, but not the blue primary of Adobe RGB (D65), my case (1) below. Why don't you realize that the issue is the representation of blue primary of Adobe RGB (D65), which is a valid color in its measurement system, to the measurement system of Prophoto RGB (D50)? And, again, please don't let chromatic adaption confuse you.
Iliah Borg has also demonstrated that using Bruce Lindbloom's calculator.
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, PropPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, PropPhoto RGB white point=D65, Fraction needed=0.67
You can choose to say what is of practical significance or not. But that has no relevance to this discussion.
Sincerely,
Joofa
-
Emil, it appears now you are backtracking from your previous comment that "colors from the other illuminant in the scene might fall outside that gamut even though they can be within the gamut adapted to that other illuminant." :D
Not at all. If the dominant scene illuminant is I and we record it as a set of RGB values wrt a color space adapted to it, G(A,I) (even though the definition of that color space may refer to some other illuminant), then a set of XYZ responses from a second illuminant I' may lie outside of G(A,I). It may lie outside it even though, had the entire scene been illuminated with I', those responses would lie within G(A',I').
-
You can choose to say what is of practical significance or not. But that has no relevance to this discussion.
Maybe you could tell us, based on the usage of the two working spaces, what relevance altering the values to produce a result you wish to illustrate (in terms of the two gamuts) brings to the party. I’ve got the two profiles in question that are used in dozens upon dozens of color managed app’s. Aside from using Bruce’s color calculator to insert a specification to produce the results you want to show us, just what is the practical relevance? Just how or why would I find this of any practical usage with the profiles and products available that utilize these profiles/working spaces/and their gamuts? How or why would I attempt to produce the results your theory presumably illustrates outside of Bruce’s calculator? That’s the $64K question.
Or is this just a theoretical “if a tree falls in the forest” exercise that is long due to finish its course here?
Lastly, the sentence “But that has no relevance to this discussion“ is of course just your opinion. I suspect many here wonder if there is any relevance to a great deal of the discussion this late in the game. Certainly if it has no real world usage. Does it?
Lets not forget the target audience of the LuLa site. You might find your ideas better received on the ColorSync list. Or as mentioned below, do we drag this theoretical verbal diarrhea into the “how many ICC profiles can dance on the head of a pin” debates.
-
The only way I can see comparing colors under different illuminants to be relevant, is if the scene captured has multiple illuminants (eg, Mark's window example). Then without special treatment, one has to choose an overall illuminant for the scene and its associated adapted gamut, and colors from the other illuminant in the scene might fall outside that gamut even though they can be within the gamut adapted to that other illuminant.
Another example:
at sunset condition we are chromatically adapted to the extent that we still recognize a white T-shirt as being white. But would we click-balance it in the Raw converter (?). This could certainly help to avoid too saturated red hues in the sky, thus taming the colors inside our working space (whatever it is). However, if the capture is more focused on the landscape rather than the T-shirt, we would probably desist from doing such click-whitebalance - it would most likely destroy the mood of scene i.e. image appearance on screen (unless of course our monitor would be calibrated to an idiosyncratic warm white).
So it seems that chromatic adaptation has its limitations
… as does ProPhoto RGB.
Peter
--
Screenshot of a Granger Rainbow in Adobe RGB
Customized Proof Setup to ProPhoto RGB, AbsCol rendering
Gamut warning enabled, Conversion Engine: Microsoft ICM
Photoshop CS4 on Windows (should work with Apple’s CMM as well, and was also given with Adobe’s ACE in former Photoshop CS).
Corresponds to some of the 3D plots at least which we have seen here...
-
Photoshop CS4 on Windows (should work with Apple’s CMM as well, and was also given with Adobe’s ACE in former Photoshop CS).
Try ACE, at least on this end, very different results! The rendering intent (well Perceptual and Saturation don’t exist anyway) make no differences.
-
Not at all. If the dominant scene illuminant is I and we record it as a set of RGB values wrt a color space adapted to it, G(A,I) (even though the definition of that color space may refer to some other illuminant), then a set of XYZ responses from a second illuminant I' may lie outside of G(A,I). It may lie outside it even though, had the entire scene been illuminated with I', those responses would lie within G(A',I').
Emil, please work out my case (1) presented above, as I have done several times on this list, and kindly let me know how do you contain Adobe RGB (D65) primary without more than unity stimulus from blue Prophoto RGB (D50)? And, please don't work out my case (3) above when you think you are working case (1). Please show some numbers.
Sincerely,
Joofa
-
Digital dog you are free not to participate. No body is forcing you to. And, please develop a better understanding of the theory of color science.
Joofa
-
Try ACE, at least on this end, very different results! The rendering intent (well Perceptual and Saturation don’t exist anyway) make no differences.
verifying clipping with abscol RI is the same trap I fell in some pages above...
ACE doesn't show clipping as it converts recol. If you switch to Apple CMM you'll see the clipping.
-
Colour science is not "frozen". Fairchild, anybody
Your point is well taken. I have Mark Fairchild's Color Appearance Models and it is excellent. Color science is still changing and the work he and others are doing on advanced color models is really cool.
I take a 100% reflective surface and shine D65 on it measure its XYZ, call it A, and then I shine D50 on it measure its XYZ, and call it B. And A is not the same as B! These two different sets of XYZ
OK good, we agree on this; these are two sets of XYZ numbers. They are different XYZ numbers. Unanimous agreement. But the crux of the the problem is this question: are they two different colors? Colorimetry can only answer that and other questions if we assume the same viewing conditions. XYZ coordinates are absolute, but can't really be described as colors without more information. It they could, all our problems would be solved—we would just use XYZ coordinates anytime we wanted to communicate color.
Lets look at our people with the house again: person A inside with a tungsten light and person B outside at dusk. Now ask them this question: does the color of the lightbulb fit inside a greyscale gamut? Person A is going to say, "sure it obviously does, the color of the lightbulb is white, In our greyscale space that is around [255]." Person B is going to say, "Not so fast, that lightbulb is yellow. It lies outside the gamut greyscale." But it's the same XYZ coordinate.
If only the people could communicate the color of the lightbulb rather than the XYZ coordinates.
They can. And this is why we have colorspaces. Both people can convert the coordinates to LAB space. To get to LAB they need to figure out a white point. Person A will use one that corresponds roughly to the 3200K tungsten and will get a LAB value like [95, 0, 0]. Person B will use a white point to something like 12000K and get a lab value [95, 0, 40].
NOW we can talk about color. Person A and B can pull up their LAB values on computer. Person A will recognize the white color as theirs and person B will identify the yellow as theirs. If they want to understand the difference between these colors they can go back to their LAB calculations where they'll see the cause of their different perceptions. They'll also see that if they want to know if it fits into a greyscale gamut, they'll also have to define that gamut in LAB or a similar space.
This is how I read your argument: There is person A inside in a well defined D50 environment. They have just decided that color A defined under D50 fits in a greyscale gamut also defined under D50. You are person B outside in the dusk screaming that color A obviously doesn't fit in a greyscale gamut. And you're right, from the point of view of person B it doesn't. But it doesn't matter. There are infinite different viewing conditions where that D50 light is not going to look white.
-
ACE doesn't show clipping as it converts recol.
How can you confirm this?
-
Hi Mark,
I think you are still not getting what I am trying to say. It is not complicated. Please think how the original experiments were done to determine color matching functions. In this case your measurement system is Prophoto RGB (D50), and I shine a color, which incidently happens to be the blue primary of Adobe RGB (D65). Just like the original experimenters, your job is to match this color using Prophoto RGB (D50) using linear methods. You will find you are unable to match this unless you raise your blue saturation to more than "unit stimulus" saturation.
That is what I have been saying all along.
Best regards,
Joofa
-
verifying clipping with abscol RI is the same trap I fell in some pages above...
ACE doesn't show clipping as it converts recol. If you switch to Apple CMM you'll see the clipping.
There is zero difference using either RelCol or ABS (as I’d expect) with ACE. The Apple CMM shows far less and different clipping than the illustration from MS.
One of these CMM’s isn’t kosher, so which?
-
ACE doesn't show clipping as it converts recol.
How can you confirm this?
convert from Adobe to ProPhoto first relcol and secondly abscol. Assemble the two files on a layer and set the layer mode to "difference". View the histogram ... no difference.
edit:
BTW: "AdobeCMM" does take the white point into account (see attachments - source: "ECI-RGB", D50 | target: AdobeRGB)
-
I think you are still not getting what I am trying to say. It is not complicated. Please think how the original experiments were done to determine color matching functions. In this case your measurement system is Prophoto RGB (D50), and I shine a color, which incidently happens to be the blue primary of Adobe RGB (D65). Just like the original experimenters, your job is to match this color using Prophoto RGB (D50) using linear methods. You will find you are unable to match this unless you raise your blue saturation to more than "unit stimulus" saturation.
I understand what are saying. But the point of moving from one color space to another is to have the colors match. If a color in one space can't produce a match in another it's out of gamut, right. I'm pretty sure we agree on that.
So let's do your experiment. Let's say we are under D50 (knowing that already we doing the experiment differently that the original which didn't specify). You shine a light of your D65 Adobe RGB primary. We know its XYZ value: [ 0.1881852 0.0752741 0.9911085]. So I'm under D50 and seeing this color.
Here is the question: is this color that I am seeing, the color we mean when we say [0, 0, 255] in AdobeRGB? The answer is no. The color we mean when we say [0, 0, 255] in ARGB is a different set of XYZ numbers under D50.
There are ways to look at this experimentally using haploscopic tests which allow us to see colors with each eye under different adaptation. It works like this:
Your left eye is adapted to D65 and we show you the XYZ numbers above and ask, is this the color you are trying to achieve with adobRGB [0, 0, 255]? You would say yes! There is it.
Your right eye is adapted to D50 and we show you the same XYZ numbers and ask the same question. The answer in this case is no. You would say you are seeing a different color in each eye. Only one of them can accurately be called [0, 0, 255] adobeRGB.
Now we let you adjust the color in your right eye until they match. After fiddling with some dials you would arrive on a number that corresponds to XYZ [ 0.149224 0.0632197 0.7448387]. Now you are seeing a match between the two eyes. Your right eye is now seeing what your left eye confirmed was adobeRGB [0, 0, 255]. Convert this number into ProPhoto space and you will see that is easily fits.
The problem you are bumping into is that you are talking about XYZ numbers like they are color perceptions, but they're not.
-
I emailed Bruce Lindbloom about this issue,
He kindly answered me, even read the thread, an allowed me to quote his answer in the forum (I put bold on what I consider key issues):
The resolution of the issues boils down to agreement of the premises. If one takes the position that AdobeRGB blue lies outside the gamut of ProPhotoRGB, then one must also agree that the AdobeRGB grayscale (R=G=B) is not neutral. This is the case where chromatic adaptation is not used (absolute colorimetric). AdobeRGB and ProPhotoRGB whites are outside of each other’s gamuts.
I believe that all of the reference RGB color systems share the basic premise that R=G=B is neutral. Of course, neutral is relative to the color system’s reference white. When considering two RGB systems having different reference whites, the only way to reconcile the neutrality of the grayscales is to use chromatic adaptation (relative colorimetric). In most real-world applications and workflows, this is the only thing that makes practical sense. It is what ICC, Photoshop, Lightroom, etc. are based on. Although AdobeRGB is specified relative to D65, its ICC profile contains the primaries adapted from D65 to D50 using the Bradford chromatic adaptation method (use a profile inspector to examine the rXYZ, gXYZ and bXYZ tag contents). So any ICC-aware app that uses this profile is transforming colors in the D50 world, not D65. R=G=B is a D50 neutral, no matter what the native reference white of the color space.
If one agrees that R=G=B is neutral for both profiles, regardless of the reference whites, then chromatic adaptation must be used to bring them both to the same reference. In that context, AdobeRGB blue lies inside the gamut of ProPhotoRGB.
Regards,
Bruce
--
Bruce J. Lindbloom
So, as I understand it, both sides of the discussion can be right, it depends on the premises you choose to follow
For my regular work, I take the practical approach of adobeRGB being contained in ProPhotoRGB using illuminant D50
-
So, as I understand it, both sides of the discussion can be right, it depends on the premises you choose to follow
Thanks a kind way of putting it <g>.
So the idea is, we can bastardize one of these well defined working spaces, working spaces that otherwise function properly and as designed, being well behaved where R=G=B (a big advantage of such editing spaces) to illustrate a pretty useless theoretical construct where some colors fall outside the gamut of the spaces seems like a lot of mental masturbation. And as I asked, for what purpose? That was never answered, I suspect it never will be (much like my query as to why the flat earth proponent here is unwilling to view the gamuts as oh so many utilities properly map them as they are intended to be used). Its a bit like those who say bumblebees can’t fly. Why anyone would spend so much time and effort to make a point that has no useful basis in the real world will probably never be answered.
In most real-world applications and workflows, this is the only thing that makes practical sense.
For my regular work, I take the practical approach of adobeRGB being contained in ProPhotoRGB using illuminant D50
Indeed! How nice to get back to planet earth.
-
I emailed Bruce Lindbloom about this issue,
He kindly answered me, even read the thread, an allowed me to quote his answer in the forum (I put bold on what I consider key issues):
So, as I understand it, both sides of the discussion can be right, it depends on the premises you choose to follow
For my regular work, I take the practical approach of adobeRGB being contained in ProPhotoRGB using illuminant D50
Hi Francisco,
Thanks for the message and the kind effort to get clarification from Bruce Lindbloom. What Bruce said was already present in my first message in my note and I copy it below, see cases (1) and (3), below. While, I also worked out two additional cases, (2) and (4) below.
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, PropPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, PropPhoto RGB white point=D65, Fraction needed=0.67
Thanks again.
Sincerely,
Joofa
-
The problem here is misuse of the Bruce color calculator. From Page 1 post 15...
You have highlighted the incorrect parameter. See the drop-down above where you have circled. It clearly says D50. Please change that to D65 for this Adobe RGB. However, when you go to ProPhoto calculation change that back to D50.
This is your first problem. Bjanes correctly pointed out, three posts prior to the post quoted above, that the “Ref White” value is the desired illuminant for the CIE spaces...it is not an override of the white point for the selected RGB space.
The D50 on the calculator refers to the white point of the reference (XYZ) space.
You have misinterpreted the meaning of that Ref White value. Once you select an illuminant for the CIE spaces, you can’t change it because that assigns a completely different color to the current CIE values.
So you calculated one color under one illuminant, then before translating that color to Pro Photo, you selected a different illuminant...thereby changing the color that your CIE values represent.
Here is your second problem with using the calculator...
There is no need for a Bradford transformation here as we are doing a direct measurement of two visually different colors A and B in a measurement system using ProPhoto RGB scaled to D50 white point.
In the help for his calculator, Bruce LindBloom notes that when the selected CIE illuminant is different from the white point of the color space, then an adaptation is necessary.
All this was already explained by jbrembat in post 110.
Well, I’m solidly convinced that Adobe RGB blues (and sRGB blues, which are also out of gamut if you use joofa’s method) are within the Pro Photo space.
-
The problem here is misuse of the Bruce color calculator. From Page 1 post 15...
Here comes another contender ;D. Please see the attachment to Iliah Borg's first message in this thread to figure out how to use Bruce Lindbloom's calculator. BTW, I personally did not use his calculator. Do you think his calculator would have let me make all those 3D graphs that I presented?
Sincerely,
Joofa
-
Here comes another contender ;D. Please see the attachment to Iliah Borg's first message in this thread to figure out how to use Bruce Lindbloom's calculator.
He made the same exact mistake. He even admits it...
It is not wrong, I forced "assign", which explains what is happening.
There’s no assigning of white points. The “Ref White” field is the illuminant for the CIE spaces. That's his mistake. Every space has its white point...Adobe RGB has D65, Pro Photo has D50, and CIE has whatever is set in “Ref White.” The calculator doesn’t allow you to change the white point of the RGB color spaces.
Once you choose an illuminant for the CIE spaces, you don’t change it during your conversions. That’s like trying to calculate how many miles you drove at 50 MPH for 37 minutes, and then somewhere in the middle of your calculations labeling your miles as kilometers…that doesn’t work.
-
It's pretty simple, it seems.
Joofa, you're right, so long as we create a premise that allows you to be right, which has no apparent impact or utility on real-world application as relates to this place (ie photography).
In all useful and practical cases, you're wrong, because the initial premise doesn't meet your criteria.
As an intellectual exercise, it has merit. As a practical instruction or guide, it does not.
-
It's pretty simple, it seems.
Joofa, you're right, so long as we create a premise that allows you to be right, which has no apparent impact or utility on real-world application as relates to this place (ie photography).
In all useful and practical cases, you're wrong, because the initial premise doesn't meet your criteria.
As an intellectual exercise, it has merit. As a practical instruction or guide, it does not.
Farmer, I don't think you are being fair here. If I had listed only case (1) in my note and insisted that is the only option then it would have been something. I clearly provided 4 different cases so that people can understand what is going on here.
BTW, I note with mild amusement that people who were accusing me of creating a new space ("JoofaSpace"), still don't realize that Adobe RGB (D50) is, if anything, a Joofaspace, because it has been changed from the standardized definition of Adobe RGB (D65) to conform to D50 white point! So ironic. :D And, now they are clinging on to the Adobe RGB (D50) as if their life depended on it.
Regards,
Joofa
-
He made the same exact mistake. He even admits it...
I notice the tag below your username says "newbie".
Joofa
-
I notice the tag below your username says "newbie".
I notice that's the kind of thing said by people who finally realize they're wrong.
-
BTW, I note with mild amusement that people who were accusing me of creating a new space ("JoofaSpace"), still don't realize that Adobe RGB (D50) is, if anything, a Joofaspace, because it has been changed from the standardized definition of Adobe RGB (D65) to conform to D50 white point! So ironic. :D And, now they are clinging on to the Adobe RGB (D50) as if their life depended on it.
Well, congratulations...you now have a color space named after you. You are in rare company such as Bruce (Fraser) RGB (a variant also from Adobe RGB) as well as Melissa RGB. The "s" of sRGB doesn't really stand for Stokes RGB (but it does in my mind).
But while you may have won a battle, you've lost the war. ProPhoto RGB is STILL the ONLY color space I know of that can contain ALL the colors a camera can capture and ALL the colors modern inkjets can print. And if Bruce L. says all of Adobe RGB can fit within ProPhoto RGB than I don't think I can accept your contention that any color in Adobe RGB will be clipped in ProPhoto RGB. That's what the last several pages of posts were about, right?
Wow, I'm worn out :~)
-
BTW, I note with mild amusement that people who were accusing me of creating a new space ("JoofaSpace"), still don't realize that Adobe RGB (D50) is, if anything, a Joofaspace, because it has been changed from the standardized definition of Adobe RGB (D65) to conform to D50 white point! So ironic. :D And, now they are clinging on to the Adobe RGB (D50) as if their life depended on it.
As long as you are amused... If you would simply go back to post #16, you’ll clearly see:
The WP of Adobe RGB (1998) is D65. Its as simple as that. If you try to define the space using D50, it ain’t Adobe RGB (1998) anymore. Go ahead and call it joofaRGB. <G>
The same items were pointed out to you in post 36, 42, 68, 151,159 etc.
So yes, we absolutely realized that “Adobe RGB“ (D50) as written above, could be called joffaRGB, that Adobe RGB (1998) (D65) is Adobe RGB (1998)!
-
Well, congratulations...you now have a color space named after you. You are in rare company such as Bruce (Fraser) RGB (a variant also from Adobe RGB) as well as Melissa RGB. The "s" of sRGB doesn't really stand for Stokes RGB (but it does in my mind).
But while you may have won a battle, you've lost the war. ProPhoto RGB is STILL the ONLY color space I know of that can contain ALL the colors a camera can capture and ALL the colors modern inkjets can print. And if Bruce L. says all of Adobe RGB can fit within ProPhoto RGB than I don't think I can accept your contention that any color in Adobe RGB will be clipped in ProPhoto RGB. That's what the last several pages of posts were about, right?
Wow, I'm worn out :~)
Hi,
No, Bruce L. has said what is my case (3), only Adobe RGB (D50) can be contained within ProPhoto RGB (D50). If you read his note he clearly says that the case (1) can't be contained, i.e., Adobe RGB (D65) can't be contained within Prophoto RGB (D50).
This is what Bruce says:
"If one takes the position that AdobeRGB blue lies outside the gamut of ProPhotoRGB, then one must also agree that the AdobeRGB grayscale (R=G=B) is not neutral. This is the case where chromatic adaptation is not used (absolute colorimetric). AdobeRGB and ProPhotoRGB whites are outside of each other’s gamuts."
The reason Adobe RGB (50) can be contained is that because it has been chormatic-adaptation-transformed from Adobe RGB (D65), and this process has already stripped that offending blue Adobe RGB (D65) primary. After Bradford transformation Adobe RGB (D50) gets a new blue primary.
Best regards,
Joofa
-
As long as you are amused... If you would simply go back to post #16, you’ll clearly see:
The same items were pointed out to you in post 36, 42, 68, 151,159 etc.
So yes, we absolutely realized that “Adobe RGB“ (D50) as written above, could be called joffaRGB, that Adobe RGB (1998) (D65) is Adobe RGB (1998)!
Ha ha, Digital Dog, you have still not realized that the gamuts of Adobe RGB you saw that you claimed were within Prophoto RGB were of Adobe RGB (D50) = JoofaSpace, and not Adobe RGB (D65). You really need to study color science.
Joofa
-
Joofa, can your point be summarized like this?
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment are out of gamut in ProPhotoRGB?
Mark, you get the trophy. What took you so long to realize that? ??? ??? ??? ??? ???
Joofa
-
Mark, you get the trophy. What took you so long to realize that? ??? ??? ??? ??? ???
Joofa
Great! We agree! We can stop now.
There is one little problem, however:
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment are also out of gamut of Adobe1998 RGB.
-
Did you miss that part about:
"If one agrees that R=G=B is neutral for both profiles, regardless of the reference whites, then chromatic adaptation must be used to bring them both to the same reference. In that context, AdobeRGB blue lies inside the gamut of ProPhotoRGB."
Pardon me but I don't know how you can get from Adobe RGB D65 to ProPhoto RGB in real life (as apposed to calculations only) without doing a "chromatic adaptation". Isn't that what color transforms are all about? Pretty sure that's how Photoshop handles a color space transform...(and Camera Raw and Lightroom).
We are talking about the real world, right? Photographic images? Not arbitrary color references we can't see and photograph?
-
Great! We agree! We can stop now.
There is one little problem, however:
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment are also out of gamut of Adobe1998 RGB.
Yes, and I have said that tons of time before! The last time I said that was just before this message and I repeat it here:
Joofa said:
The reason Adobe RGB (50) can be contained is that because it has been chormatic-adaptation-transformed from Adobe RGB (D65), and this process has already stripped that offending blue Adobe RGB (D65) primary. After Bradford transformation Adobe RGB (D50) gets a new blue primary.
Sincerely,
Joofa
-
Yes, and I have said that tons of time before! The last time I said that was just before this message and I repeat it here:
Great! We still agree!
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment is out of gamut in both ProPhotoRGB and Adobe1998RGB.
So remind me again, why this color, which is out of both gamuts, is relevant to a comparison between the two?
-
As I see it, the problem is with understanding that we can't (and do not want to) run full adaptation.
-
Farmer, I don't think you are being fair here. If I had listed only case (1) in my note and insisted that is the only option then it would have been something. I clearly provided 4 different cases so that people can understand what is going on here.
I'm not being unfair at all. You could have provided 42 different cases, but if only one of them applies to the practical application then the other 41 are mildly interesting in an academic way, but useless for any other. If the academic discussion leads to a new practical application, then that's wonderful. Such things do happen. However, unless you can show or at least give some idea of how your premise can or might be useful in a practical way, then unfortunately it remains less than useful.
So if there's somewhere you can lead with this to suggest how it might be useful (changing the way CMMs work or some new technology that will significantly change the capture space of cameras, or a new printing or display method - etc etc) then please go ahead and I guarantee that all and sundry here will be listening and eager to understand and learn.
I don't think this has been a waste of bandwidth and the discussion has likely been useful (it has to me - I'm not a colour scientist but I try to read and understand as much as possible - it has a lot of benefit for my job). It's time to either move to the next stage - practical application - or move on to the next topic and leave this one for reference.
It's not really a big deal. I got called out recently a thread. I had no intention of being an arse, but it was perceived that way by some. You move on and try to avoid it. I don't think you've been an arse here, but it gets pretty close when you start commenting on people's post count numbers or suggesting that people should becomes more learned in an area without presenting your own credentials. I understand that sometimes it's not appropriate to background yourself, but in those cases you have to learn to suffer for the benefit of some level of anonymity. Such is life :-)
-
Great! We still agree!
So remind me again, why this color, which is out of both gamuts, is relevant to a comparison between the two?
Mark, I thought you were beginning to understand this process, but it seems you are derailing again. ;D The intent was to show that in linear transformations akin to absolute colorimetry, Adobe RGB (D65) contains saturated blue colors that have no representation in Adobe RGB (D50) or Prophoto RGB (D50).
Hope that helps.
Regards,
Joofa
-
Adobe RGB (D65) contains saturated blue colors…
I thought we just agreed that this color is out of gamut in Adobe1998 RGB.
-
I'm not being unfair at all. You could have provided 42 different cases, but if only one of them applies to the practical application then the other 41 are mildly interesting in an academic way, but useless for any other.
Iliah Borg just gave an example when that is relevant. Please see that above.
If the academic discussion leads to a new practical application, then that's wonderful. Such things do happen. However, unless you can show or at least give some idea of how your premise can or might be useful in a practical way, then unfortunately it remains less than useful.
See above.
It's not really a big deal. I got called out recently a thread. I had no intention of being an arse, but it was perceived that way by some. You move on and try to avoid it. I don't think you've been an arse here, but it gets pretty close when you start commenting on people's post count numbers or suggesting that people should becomes more learned in an area without presenting your own credentials. I understand that sometimes it's not appropriate to background yourself, but in those cases you have to learn to suffer for the benefit of some level of anonymity. Such is life :-)
I fully realize that I was a little politically incorrect a few times, and for that I apologize to everybody including digital dog. But the personal attacks were not started by me. However, I still offer my apology, especially to digital dog.
On the credentials front I thought my arguments would speak for me. But apparently not. You can google me if you want to find my background ;D
Best regards,
Joofa
-
I thought we just agreed that this color is out of gamut in Adobe1998 RGB.
Mark what happened to you? Not in Adobe RGB (D65). We are talking about saturated blues around Adobe RGB (D65).
Joofa
-
As I see it, the problem is with understanding that we can't (and do not want to) run full adaptation.
Adaptation is a necessary function of color space conversion. What is your justification for not using it?
Let’s say someone wants to convert Celsius to Fahrenheit. So you tell the person, “There are 1.8 degrees F to every degree C, so multiply your C by 1.8.” Then you say, “But wait...the Fahrenheit freezing point is not zero, so you have to add 32 to your result to match the freezing points.” At this point the person says, “But I don’t want to add 32 to my result.”
That is exactly what you’re saying when you say you don’t want to execute adaptation. You’re performing half the required conversion, and then making declarations about the results that are only partially processed. It’s like saying 10 C equals 18 F...true if you’re talking about a change in temperature, false if you’re talking about the current weather.
-
> He made the same exact mistake. He even admits it...
LOL See, you think of one or another colour space. Now we are talking about both co-existing in the same scene. Ever wondered why shadows look blue while the whole scene is lit by sun?
-
I'll start again:
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment is out the ProPhotoRGB gamut.
Agreed
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment areisalso out of the Adobe1998RGB (D65) gamut.
Agreed
This color, represented by XYZ [0.1881852, 0.0752741, 0.9911085] viewed in a D50 environment is out of the gamut of both profiles in question. So again, why do we care about it?
-
Iliah Borg just gave an example when that is relevant. Please see that above.
Esoteric. Hardly in the realm of practical application without further expansion. You're bringing this to the table - detail the practical application.
On the credentials front I thought my arguments would speak for me. But apparently not. You can google me if you want to find my background ;D
I've been using the internet since 1991, but thanks for the lesson...
-
This color, represented by XYZ [0.1881852, 0.0752741, 0.9911085] viewed in a D50 environment is out of the gamut of both profiles in question. So again, why do we care about it?
Because it is not outside Adobe RGB (D65)'s gamut and can be represented in it fine.
Joofa
-
> ProPhoto RGB is STILL the ONLY color space I know of that can contain ALL the colors a camera can capture and ALL the colors modern inkjets can print.
Operative word is "know". Cameras do not have gamuts while ProPhoto RGB does have a gamut, and not the widest possible.
-
There is one little problem, however:
The XYZ values of Adobe1998 blue primary [0.1881852, 0.0752741, 0.9911085] when viewed in a D50 environment are also out of gamut of Adobe1998 RGB.
Yes, and I have said that tons of time before!
Because it is not outside Adobe RGB (D65)'s gamut and can be represented in it fine.
Perhaps in view of the above, you can understand why I'm confused.
But regardless… The color XYZ [0.1881852, 0.0752741, 0.9911085] viewed in a D50 environment is not the same color as XYZ [0.1881852, 0.0752741, 0.9911085] viewed in a D65 environment. They don't match—you can show this experimentally. Having the same XYZ numbers is not enough to tell if they are the same color—color is what is perceived.
The color AdobeRGB1998[0, 0, 255] does not equal XYZ [0.1881852, 0.0752741, 0.9911085] viewed in a D50 environment.
-
you think of one or another colour space. Now we are talking about both co-existing in the same scene. Ever wondered why shadows look blue while the whole scene is lit by sun?
and? I don't understand it (but would like to).
Are you talking about high saturated blues (captured with your camera) that you want to preserve (unaltered!)?
-
The color AdobeRGB1998[0, 0, 255] does not equal XYZ [0.1881852, 0.0752741, 0.9911085] viewed in a D50 environment.
Mark I thought we agreed that XYZ=[0.188185 0.075274 0.991108] is outside Adobe RGB (D50) gamut but within Adobe RGB (D65) gamut in absolute terms. I don't know why are you getting confused.
Joofa
-
Point is - in a typical scene there are several different white points, with different CCTs and different SPDs.
-
Mark I thought we agreed that XYZ=[0.188185 0.075274 0.991108] is outside Adobe RGB (D50) gamut but within Adobe RGB (D65) gamut in absolute terms. I don't know why are you getting confused.
I said nothing about XYZ=[0.188185 0.075274 0.991108]. I am talking about this: XYZ=[0.188185 0.075274 0.991108] viewed in a D50 environment.
Do you understand the difference?
Do you understand what I mean when I say:
XYZ [0.188185 0.075274 0.991108] viewed in D50 is not the same color as XYZ [0.188185 0.075274 0.991108] viewed in D65?
-
Point is - in a typical scene there are several different white points, with different CCTs and different SPDs.
don't know what "CCT" and "SPD" stands for... but why would I care about different white points as long I can store all the colors captured in one color space?
-
I said nothing about XYZ=[0.188185 0.075274 0.991108]. I am talking about this: XYZ=[0.188185 0.075274 0.991108] viewed in a D50 environment.
Do you understand the difference?
Do you understand what I mean when I say:
XYZ [0.188185 0.075274 0.991108] viewed in D50 is not the same color as XYZ [0.188185 0.075274 0.991108] viewed in D65?
XYZ space has only a single notion of white point and that is [1,1,1]. A statement such as "viewing in a D50 or D65 environment" in connection to XYZ is not correct. You can assign D50 and D65 to other RGB-type spaces only. BTW, schematically, there is no difference between XYZ, RGB, linear LMS, or any other linear derivative space. However, if you assign a notion of a white point other than [1,1,1] to XYZ you will mess up the structure of colorimetry.
Joofa
-
Correlated Color Temperature and Spectral Power Distribution. Try coming up with a colour space that will capture the gamut of ProPhoto RGB adapted to 3000K and the gamut of ProPhoto RGB adapted to 7500K. Do you think regular ProPhoto can encompass both gamuts?
-
Correlated Color Temperature and Spectral Power Distribution.
thanks!
Try coming up with a colour space that will capture the gamut of ProPhoto RGB adapted to 3000K and the gamut of ProPhoto RGB adapted to 7500K. Do you think regular ProPhoto can encompass both gamuts?
you can create such a color space in Capture One easily. Question is whether or not it is useful... but you can, no problem.
attached the largest color space you can create in Capture One (wireframe | D50, Gamma 1.8 ) compared to "ProPhoto" (shifted to D75 in Photoshop... so another joofa-space just for the purpose of comparision)
-
Joofa, I understand CIE XYZ space just fine. I normally have a copy of Wyszeck & Stiles in arm's reach.
One last time: I'm not talking about assigning a white point, I'm talking about understanding the viewing conditions—the state of the viewer. Matching XYZ coordinates is only valid under the same viewing conditions. If you are talking about comparing XYZ values in different states of chromatic adaptation (which is what you are doing) your results are meaningless unless you account for it.
I've explained is well as I can in post #159 (http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412771#msg412771)
I'm done here.
-
Joofa, I understand CIE XYZ space just fine. I normally have a copy of Wyszeck & Stiles in arm's reach.
One last time: I'm not talking about assigning a white point, I'm talking about understanding the viewing conditions—the state of the viewer. Matching XYZ coordinates is only valid under the same viewing conditions. If you are talking about comparing XYZ values in different states of chromatic adaptation (which is what you are doing) your results are meaningless unless you account for it.
I've explained is well as I can in post #159 (http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412771#msg412771)
I'm done here.
The problem here is that you are not realizing when you said "viewing XYZ in D65 or D50" you actually want to say viewing the same XYZ coordinates in some RGB (D50) and RGB (D65) environment. In those two RGB spaces, the same XYZ coordinate can have different representations (tristimulus). And you are not realizing that is the very fact that the same XYZ=[0.188185 0.075274 0.991108] becomes in-gamut in Adobe RGB (D65) but out-of-gamut in Adobe RGB (D50) in absolute terms.
Joofa
-
> you can create such a color space in Capture One easily
How you checked it encompasses both? By running a colour list that contains all the XYZ values from both gamuts?
> Question is whether or not it is useful
Things are useful when one can apply those things, right?
-
> you can create such a color space in Capture One easily
How you checked it encompasses both? By running a colour list that contains all the XYZ values from both gamuts?
no, just by looking at Color Think's grapher (admittedly only for the D75 shifted ProPhoto).
edit: but both the color spaces are displayed abscol in relation to D50 BTW ... so the "D75"-ProPhoto is shifted towards blue... the white points are not equalized.
> Question is whether or not it is useful
Things are useful when one can apply those things, right?
okay, that's true!
-
I'm trying to visualize this problem, (from empirical observations, it may not make sense at all, feel free to ignore or disregard)
XYZ space is absolute, is not relative to viewing conditions.
A specific illuminant define a white point vector (be it D50, D65, etc)
Different illuminant vectors or white point vectors are not parallel but angled between each other.
Color spaces are volumes that are not necessarily orthogonal to XYZ, and are associated to a specific white point vector, and with the vector and color space we have a white point coordinate in XYZ
A Viewing condition is similar to position the observer just in line with a white point vector. In this case, any XYZ coordinate along the white point vector is neutral (R=G=B).
If from a viewing condition the observer looks at any point along the white vector of another illuminant, it will perceive non neutral colors (Even if in the color space belonging to the other illuminant R=G=B)
This may be the case if our viewing condition is D50, ProphotoRGB, Here R=G=B will look neutral. If from this same position we look at AdobeRGB D65, then the values of adobeRGB R=G=B will not be perceived as neutral
It is like both color spaces where not aligned, and in this case it happens that the blue primary of AdobeRGB is outside of the gamut of ProphotoRGB.
For simplicity and practical purposes, the solution apparently implemented in common color conversion tools is to align both spaces so that the white point vectors are parallel or aligned. I think of this like a "rotation" of one color space to align to the other.
As I understand, the standard practice is to align all color spaces to D50 (It could have been D65 or any other)
When you "rotate" or move a color space (which is my interpretation of Chromatic adapation) some colors that where inside its gamut, are now outside, and vice versa, colors that where outside of the gamut are now inside)
For example, original blue primary of AdobeRGB D65 is now out of gamut in AdobeRGB D50 but it may be the case ( I have not done the calculations) that the new Red primary of AdobeRGB D50 was previously out of the gamut of AdobeRGB D65
Doing conversions from one space to another is now easier, since R=G=B is neutral for both spaces now.
So, if you keep adobeRGB with white point D65, its blue is outside the gamut of ProphotoRGB D50. it is only when you do chromatic adaptation of adobeRGB to D50 that it is completely inside of ProphotoRGB. This is the way that most current applications work and it is the practical way of handling color conversions at present time.
Now, I think that we should discuss about how color management should evolve, how future applications should handle color management instead of arguing if a color in a specific color space is inside or outside of another color space.
Some posters like Iliah have pointed out interesting comments and references about this.
Hope I didn't annoy anybody
-
Francisco, I thought I was done with this thread, but your post provides an interesting way of looking at the problem. It's very satisfying. But, I think one thing that needs to be handled carefully to avoid confusion is the term 'color.' Without including the information about the position of the observer, is it helpful to talk about an XYZ coordinate as a color? It seems like referring to an XYZ point without reference information as a 'color' is a kind of reification error. If you do this, you get into the uncomfortable position of talking about two perceptions which match, but are not the same 'color' or two that don't match that are the same 'color.'
That's important when you want to compare gamuts. For instance, in your example from the perspective of somebody aligned with D50, the XYZ point of the AdobeRGB blue primary falls outside of the ProPhoto gamut (it also falls out of the AdobeRGB gamut from this perspective). But from the same perspective of the D50 viewer there is different XYZ point which matches in perception the original blue primary as seen from D65 and is inside the D50 gamut. So the question becomes is the color indicated by AdobeRGB(0, 0, 255) inside or outside the ProPhoto Gamut. Or to put another way: can a color be specified in the ProPhotoRGB space that matches the color indicated by AdobeRGB(0, 0, 255). The answer of course is yes if you mean by color a perception.
-
So, if you keep adobeRGB with white point D65, its blue is outside the gamut of ProphotoRGB D50. it is only when you do chromatic adaptation of adobeRGB to D50 that it is completely inside of ProphotoRGB. This is the way that most current applications work and it is the practical way of handling color conversions at present time.
Correct...nicely stated. So for the purposes of actually DOING anything with different color spaces, all of Adobe RGB color gamut fit's within ProPhoto RGB when you do a color transform...so anything that WAS inside of Adobe RGB (1998) will end up being contained inside of ProPhoto RGB.
So for practical purposes (and anybody who is a glutton for punishment) if you start with a raw digital capture and are using either Camera Raw or Lightroom (the vast majority of the market), processing your images in ProPhoto RGB (which is the largest gamut available in both applications) should not clip any of the colors your camera has captured...and if it does because of some weird spectral illumination that you shot under, it won't matter anyway because you can't get a larger color space inside ACR or LR. However, you "might" be able to control those weird colors if you create a custom DNG profile using something like DNG Profile Editor. This is often needed for cameras whose infrared filters have been removed.
As for postulating on what changes may be needed for the future of color management, I'm game. But I SERIOUSLY suggest starting a whole new thread for that because, well, the vast majority of the readers here on LuLa prolly won't want to wade through clutter in this thread.
-
Correct...nicely stated. So for the purposes of actually DOING anything with different color spaces, all of Adobe RGB color gamut fit's within ProPhoto RGB when you do a color transform...so anything that WAS inside of Adobe RGB (1998) will end up being contained inside of ProPhoto RGB.
No.
-
No.
So, how do you do a color transform from one color space to another (using ICC color space profiles) using a CMM without having the chromatic adaptation applied?
-
So, how do you do a color transform from one color space to another (using ICC color space profiles) using a CMM without having the chromatic adaptation applied?
Incorrectly. ;)
-
So, how do you do a color transform from one color space to another (using ICC color space profiles) using a CMM without having the chromatic adaptation applied?
See, with a linear bradford color adaption transformation the original saturated blues and some whites of Adobe RGB (D65), i.e. Adobe 1998, get stripped off when you transfer it to Adobe RGB (D50) and later onto Prophoto RGB (D50).
Incidently, nobody has paid any attention to my case (2). If you want full preservation of Adobe gamut to Prophoto, this is the mode to look at.
Joofa
-
yawn....There is probably enough in this thread for a technical paper or two. Why not write your thesis and present at CIC in November ?
http://www.imaging.org/ist/Conferences/cic/index.cfm
-
See, with a linear bradford color adaption transformation the original saturated blues and some whites of Adobe RGB (D65), i.e. Adobe 1998, get stripped off when you transfer it to Adobe RGB (D50) and later onto Prophoto RGB (D50).
Uh huh...what happens when you transform Adobe RGB (1998) to ProPhoto RGB directly using any of the currently available CMMs?
-
Uh huh...what happens when you transform Adobe RGB (1998) to ProPhoto RGB directly using any of the currently available CMMs?
Hi,
I am not an expert on commercially available CMMs. But, what I hear from more knowledgeable posters in this thread is that they like to do a chromatic adaption from D65 to D50, perhaps using a linear matrix like Bradford transform.
Regards,
Joofa
-
Incorrectly. ;)
Define "correctly" than and explain why while doing everything "by the book" local colour editing to get correct skin tones, sky tint, foliage colour is needed.
-
Hi all,
I am slow in catching up.
More gamut plots for refreshment.
(http://2.bp.blogspot.com/_0uN01L3ZNrM/TSQvXFNaGhI/AAAAAAAAAQo/_SVMaJMLdCc/s1600/325+-+D50.png)
(http://2.bp.blogspot.com/_0uN01L3ZNrM/TSQvabFN0YI/AAAAAAAAAQs/eF1NWTwthfo/s1600/325+-+D65.png)
XYZ [0.188185 0.075274 0.991108] viewed in D50 is not the same color as XYZ [0.188185 0.075274 0.991108] viewed in D65?
XYZ [0.188185 0.075274 0.991108] is non-existence in Abode 1998 D50. Comparison is hence in valid.
The problem here is that you are not realizing when you said "viewing XYZ in D65 or D50" you actually want to say viewing the same XYZ coordinates in some RGB (D50) and RGB (D65) environment. In those two RGB spaces, the same XYZ coordinate can have different representations (tristimulus). And you are not realizing that is the very fact that the same XYZ=[0.188185 0.075274 0.991108] becomes in-gamut in Adobe RGB (D65) but out-of-gamut in Adobe RGB (D50) in absolute terms.
I thought that is the main function of CMM which maps with selected rendering intent, the vector from one space to another space.
All mapped vectors possess at least two things in common:
1) same viewing condition
2) within the defined gamut
with best regards
-
explain why while doing everything "by the book" local colour editing to get correct skin tones, sky tint, foliage colour is needed.
your skin tones contain high saturated blues?
-
your skin tones contain high saturated blues?
Andorians?
-
BTW, I note with mild amusement that people who were accusing me of creating a new space ("JoofaSpace"), still don't realize that Adobe RGB (D50) is, if anything, a Joofaspace, because it has been changed from the standardized definition of Adobe RGB (D65) to conform to D50 white point! So ironic. Cheesy And, now they are clinging on to the Adobe RGB (D50) as if their life depended on it.
Does not exist Adobe RGB (D50), you are very confused again.
Adobe RGB is D65, by definition.
The transform D65=>D50 is for adapting white point to the destination color space.
If your destination is a D55 color space, the adaptation will be D65=>D55.
In other words you are not changing Adobe RGB definition for each destination gamut, you are scaling the white point in XYZ.
Your mistake is to transform Adobe RGB to ProPhoto RGB without white point scaling. It seems you are not interested on colors, but only on numbers.
Let me try to explain what are you doing:
we know that
- 1 inch=2.54 cm.
- now we are free to fix the unit of measure, and we say that 2.54 are meters (we are going from cgs reference sytem to MKS reference system without scaling)
- conclusion 1 inch=2.54 meters
Without scaling between reference systems you can get any wrong value.
Lindbloom tried to explain that you are wrong using gray values.
But another time you ignore (or don't understand) what he said.
The reason Adobe RGB (50) can be contained is that because it has been chormatic-adaptation-transformed from Adobe RGB (D65), and this process has already stripped that offending blue Adobe RGB (D65) primary. After Bradford transformation Adobe RGB (D50) gets a new blue primary.
Wrong. Adobe RGB blue primary is not changed.
-When you go from Adobe RGB blue primary to XYZ, the computation is performed using D65, by definition of Adobe RGB
-the scaling is for XYZ, depending on destination color space white reference
From a mathematical point of view you can adapt Adobe RGB blue primary to any white point different from D65 to go from Adobe RGB to any other color space, but that doesn't mean you are changing Adobe RGB blue primary.
You are computing good XYZ values for the appearance of Adobe RGB blue color on different reference systems.
If you don't scale but change the reference system, you get a number XYZ that is no more representative of Adobe RGB blu.
Jacopo
-
Define "correctly"
“Correctly” means to convert the blue from one space into a blue in another space that appears, to a human, to look exactly like the blue in the first space. To get such a color you MUST apply adaptation when the white points are different because a human will apply adaptation when the white points are different (the very reason why we have adaptation.) Otherwise the blue that you calculate will NOT look the same to a human...it’s just the result of a half-processed conversion.
and explain why while doing everything "by the book" local colour editing to get correct skin tones, sky tint, foliage colour is needed.
That's a question that can be seen from a 1000 different angles. Without examples of what you're referring to and and explanation of what you were trying to accomplish, I can't answer such a question.
-
Let me try to explain what are you doing:
we know that
- 1 inch=2.54 cm.
- now we are free to fix the unit of measure, and we say that 2.54 are meters (we are going from cgs reference sytem to MKS reference system without scaling)
- conclusion 1 inch=2.54 meters
Without scaling between reference systems you can get any wrong value.
I too explained with analogies and I think a couple others as well. It's just not sinking in that they're not keeping the same blue by merely specifying a different XYZ white point for the conversion.
The XYZ blue may be strictly defined, but the Adobe 255 blue, as represented by XYZ, only exists as a relationship between the coordinates of the color and the coordinates of the white point. If you now simply select a different white point, you’ve changed the relationship, and thus have changed the blue. It's so obviously that they can’t see it.
Joofa and Iliah...if you use your process with sRGB you get the same result...that there are sRGB blues outside of Pro Photo. Do you claim that sRGB has blues that Pro Photo doesn’t?
-
Thank you jc1 for those beautiful plots. I don't think there should be any doubt left in anybody's mind now that Adobe RGB (D65), the official specification, has blues (and some whites) that are outside the gamut of chromatically-adapted (linear bradford transformed) Adobe RGB (D50), and henceforth to Prophoto RGB (D50).
So all those gamuts that have been claimed as showing Adobe RGB gamut within Prophoto gamut were showing Adobe RGB (D50) within Prophoto RGB (D50) and not Adobe RGB (D65) within Prophoto RGB (D50).
Sincerely,
Joofa
-
More gamut plots for refreshment.
Now do it for sRGB.
-
Does not exist Adobe RGB (D50), you are very confused again.
Adobe RGB is D65, by definition.
The transform D65=>D50 is for adapting white point to the destination color space.
Your mistake is to transform Adobe RGB to ProPhoto RGB without white point scaling. It seems you are not interested on colors, but only on numbers.
Agreed, and when I tried to point this out in my last post, referencing 5 other posts explaining the same facts, I was given an insulting and childish reply. At this point, I can only believe we are trying to engage in conversation with a troll or someone who has a religious belief system with regards to color outside the real world. Such debates are pointless. Normally I’d agree to disagree but the behavior and curt answers, refusal to answer other salient questions means that for me, its best to ignore joofa. But there were some very good posts from others that provided what could be a basis for an excellent white paper or article on color.
-
Thank you jc1 for those beautiful plots. I don't think there should be any doubt left in anybody's mind now that Adobe RGB (D65), the official specification, has blues (and some whites) that are outside the gamut of chromatically-adapted (linear bradford transformed) Adobe RGB (D50), and henceforth to Prophoto RGB (D50).
I take it this means that you're just going to ignore my question? Here it is again...
Joofa and Iliah...if you use your process with sRGB you get the same result...that there are sRGB blues outside of Pro Photo. Do you claim that sRGB has blues that Pro Photo doesn’t?
-
I'm not a color expert. However, I think joofa knows that for most purposes you want to use a chromatical adaption when going from one color space to another. I also think he knows that AdobeRGB is not D50. He's stated repeatedly that what he calls 'AdobeRGB (D50)' is AdobeRGB with a transform to use a D50 white point. For lack of a better name, he labeled it 'AdobeRGB (D50)'. He's also stated repeatedly, ever since his first post on dpreview, that his argument is based on a specific transform without chromatic adaptation.
You guys seem to be arguing about semantics, and not in a good way. And while I'm an empiricist at heart and do it for a living, just to brush away an argument/statement by saying it has no real world applications is short sighted. Bruce Lindbloom seemed to confirm what joofa was saying, though with the caveat that most people would never want to transform color that way, i.e. we want R=G=B to be neutral and not have a color cast.
In my opinion, this seems to be mostly an academic exercise. I think that was pretty clear from the beginning. I don't mean that in a bad way at all. A lot of good things have come from those thought processes. Hell, a lot of this color science was done long before we were worrying about color managed digital photo workflows. And Iliah has hinted at some situations where it might not be just academic.
My summary of 13 pages of threads: "joofa, you're wrong. Oh nevermind, you're not wrong, but only while a certain set of conditions are satisfied (ones you clearly stated at the start). However, since those conditions aren't relevant to the way I work in the 'real world', I'm going to continue to treat you like you're wrong."
Joofa, correct me if I'm wrong here and stepping over my bounds. I learned some interesting things from this discussion.
-
Bruce Lindbloom seemed to confirm what joofa was saying, though with the caveat that most people would never want to transform color that way, i.e. we want R=G=B to be neutral and not have a color cast.
More than don’t want. The question has been asked (and ignored): just why or how can the proposed transforms, (outside Bruce’s calculator or a similar utility that spits out numbers) produce the results this academic exercise predicts? Photoshop? Lightroom? C1? Any available product that would utilize the two profiles in question? And if so WHY?
Please examine Jacopo‘s last post and excellent analogy of cm and meters.
-
Do you claim that sRGB has blues that Pro Photo doesn’t?
Yes of course it has, in an AbsCol sense, starting with sRGB D65 white and stretching to the blues.
Actually, it is you making a quite strong claim and assumption: that human chromatic adaptation to a different illumint would be perfect,
and that it would be perfectly implemented with current RelCol wp mapping according von Kries, Bradford, etc... Somehow I doubt.
Let's better consider a numerically correct but perceptionally wrong starting point than the other way round. Numerical correctness never was the final goal, but it often makes a better starting point to explore appearence.
Peter
--
-
your skin tones contain high saturated blues?
Is it your idea of sarcasm? Or you seriously think the problem of inefficiency and insufficiency of modern colour management affects only blues?
-
“Correctly” means to convert the blue from one space into a blue in another space that appears, to a human, to look exactly like the blue in the first space. To get such a color you MUST apply adaptation when the white points are different because a human will apply adaptation when the white points are different (the very reason why we have adaptation.) Otherwise the blue that you calculate will NOT look the same to a human...it’s just the result of a half-processed conversion.
That's a question that can be seen from a 1000 different angles. Without examples of what you're referring to and and explanation of what you were trying to accomplish, I can't answer such a question.
Well, you do not understand that the better model of the situation is: several colour spaces coexist in the same scene. It is nearly always the case. So, your suggestion to convert is not the correct method to preserve appearance.
You can't answer not because you do not have examples. You do have them on your own photos, but you either ignore them or you can't see the reason. However the reason is physics which happens to disagree with boxed approach of data processing in colour management.
-
Yes of course it has, in an AbsCol sense, starting with sRGB D65 white and stretching to the blues.
But an absolute colormetric conversion results in color shifts, as explained by Sean McHugh over at Cambridge in Colour...
"The exact preservation of colors may sound appealing, however relative colorimetric adjusts the white point for a reason. Without this adjustment, absolute colorimetric results in unsightly image color shifts, and is thus rarely of interest to photographers.
This color shift results because the white point of the color space usually needs to align with that of the light source or paper tint used."
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
-
.. just why or how can the proposed transforms, (outside Bruce’s calculator or a similar utility that spits out numbers) produce the results this academic exercise predicts?
Let's have an image in Adobe RGB in Photoshop, let's assume that we want to appear it "cooler".
One option is to convert to ProPhoto RGB, Intent: Absolute Colorimetric, Engine: Microsoft ICM (or Apple's CMM).
Oh, take care about clipping along white to blue hues.
Peter
--
-
Let's better consider a numerically correct but perceptionally wrong starting point than the other way round.
That's the problem in a nutshell: the numbers are designed to model perception; it's the whole point. If they are perceptionally wrong for no reason, they are wrong. I can say miles and feet are the same thing if I divide the mile by 5280. My math is right, the numbers are right, but I'm still wrong.
But an absolute colormetric conversion results in color shifts
This is true, but I think most people are misunderstanding the process for absolute colorimetric conversions. The correction of chromatic adaptation is a different step than scaling white points. The spec tells you to first chromatically adapt the tristimulus values (including the media white point) and then (in rel col) scale for the white point.
The spec is here if your really interested: http://www.color.org/ICC1v42_2006-05.pdf
Here are the relevant bits (again):
6.2.2 Media-relative colorimetric intentsTransformations for this intent shall re-scale the in-gamut, chromatically adapted tristimulus values such that the white point of the actual medium is mapped
6.2.3 ICC-absolute colorimetric intentTransformations for this intent shall leave the chromatically adapted tristimulus values of the in-gamut colours unchanged.
If you follow the recipe that occurs after this in the spec, you will see where the white point scaling happens in relative colorimetric. It is not a chromatic adaptation at that point: you simply multiply your values by the ratio between the two (chromatically adapted white points). Adobe CMM seems to do this correctly.
-
your skin tones contain high saturated blues?
Is it your idea of sarcasm? Or you seriously think the problem of inefficiency and insufficiency of modern colour management affects only blues?
no, the discussion just happened to evolve around bright, high saturated blues of AdobeRGB clipping in ProPhotoRGB.
As I use neither AdobeRGB nor ProPhotoRGB maybe I am overlooking something. In any case it is possible to preserve all the colors your camera can capture in one color space. Maybe not in Adobe products, but that's a different story. In terms of color management I am finding ACR + LR pretty unusable anyway. Which is again a different story.
Me personally I first think about limited gamuts and color shifts when priniting. But that's a given fact... simply as the capabilities of printers are limited. Therefore I have no idea in how far (where/why) you struggle with the "inefficiency and insufficiency of modern colour management". If we talk for instance about inaccurate white and black points of papers... or anything related to "simulate" a different color appearance on different media... I'm with you. But I am under the impression that you are experiencing limitations on the level of capture & raw-processing. And, again, I don't get the point you are making.
-
Let's have an image in Adobe RGB in Photoshop, let's assume that we want to appear it "cooler". One option is to convert to ProPhoto RGB, Intent: Absolute Colorimetric, Engine: Microsoft ICM (or Apple's CMM).
or even "AdobeCMM" (see above)
-
> In any case it is possible to preserve all the colors your camera can capture in one color space.
To map would be a better term, but that implies we need to define that colour space and mapping method.
-
In any case it is possible to preserve all the colors your camera can capture in one color space.
To map would be a better term
true
but that implies we need to define that colour space and mapping method.
and what's the issue here?
In how far do you feel limited with regard to the tools available?
-
I am not an expert on commercially available CMMs. But, what I hear from more knowledgeable posters in this thread is that they like to do a chromatic adaption from D65 to D50, perhaps using a linear matrix like Bradford transform.
Uh huh...so for the purposes of transforming an image currently in Adobe RGB (1998) to ProPhoto RGB, ALL of the colors within Adobe RGB (1998) will get mapped to, and fit within, ProPhoto RGB without any clipping?
-
> and what's the issue here?
Take a shot of something like Time Square in the evening and try comparing the result with what you've seen on the scene.
-
> and what's the issue here?
Take a shot of something like Time Square in the evening and try comparing the result with what you've seen on the scene.
how did you solve the problem with film back then?
-
Well, you do not understand that the better model of the situation is: several colour spaces coexist in the same scene. It is nearly always the case. So, your suggestion to convert is not the correct method to preserve appearance.
You are trying to mix other arguments.
We are speaking if a color (blue AdobeRGB 1998) may be represented in ProPhoto gamut.
You said it cannot be represented.
You are wrong.
In a real scene you can have several illuminants, not several color spaces.
Another time you are wrong.
Jacopo
-
Let's have an image in Adobe RGB in Photoshop, let's assume that we want to appear it "cooler".
One option is to convert to ProPhoto RGB, Intent: Absolute Colorimetric, Engine: Microsoft ICM (or Apple's CMM).
Let me get this straight, we are in Photoshop, we want to make the image cooler, we skip curves, color balance, all the tools for making the image cooler, but we convert the color space instead? And we are on a Mac and don’t have MS ICM (or Windows and Apples CMM). This is a useful (the best) real world scenario for making the image cooler or for using a process (converting a color space) who’s role isn’t color alteration? Bit of a stretch if you ask me.
-
>Another time you are wrong.
Good answer when you can't find a better one :)
-
how did you solve the problem with film back then?
Several ways, but mostly shooting black and white, or, when in colour, looking for shallow DoF and composing shots in a way that vivid colours are blurred.
-
Good answer when you can't find a better one
This is what you do when you are not able to answer.
I said:
In a real scene you can have several illuminants, not several color spaces
But I suppose you are so confused that you didn't understand.
Jacopo
-
Several ways, but mostly shooting black and white, or, when in colour, looking for shallow DoF and composing shots in a way that vivid colours are blurred.
I like the black & white version... solves almost all the issues with multiple white points :-)
Seriously... you can shoot a sunlit scene late afternoon with high saturated warm tones and at the same time you get high saturated blue shadows (at ~ 10.000K or what). If you don't like the blue shadows just correct them selectively. If you love them, you can push saturation even further. Finally you could as well process the same file with different white points and merge them in Photoshop.
Seems to be somewhat easier then composing multiple shots.
-
Let's have an image in Adobe RGB in Photoshop, let's assume that we want to appear it "cooler".
One option is to convert to ProPhoto RGB, Intent: Absolute Colorimetric, Engine: Microsoft ICM (or Apple's CMM).
--
Peter,
That is an interesting proposition, but we usually do not want the colors to shift and use relative colorimetric. As we have found out, Adobe CMM does not perform absolute colorimetric conversion with matrix based profiles. That option should be grayed out on the drop down menu, as should the option of perceptual rendering between matrix spaces which do not have the necessary look up tables.
My original challenge to Joofa was to show me a color in Adobe RGB which can not be represented in ProPhotoRGB. This is not possible in Photoshop with the Adobe CMM, but can be done with the absolute colorimetric intent in the Microsoft CMM.
An interesting project is to create a Joofa color space with the primaries of Adobe RGB and a D50 white point as shown on the screen capture below. One can then fill the image with RGB 0,0,255 and then convert to ProPhotoRGB. The resultant RGB is 237. Since there is no change in white point, chromatic adaption is not necessary. I presume that the primaries of the Joofa space are interpreted differently for a white point of D50.
The only apparent advantage of the Joffa space is that no chromatic adaption is needed for spaces with a D50 white point. Indeed, when Bruce Lindbloom designed BetaRGB he chose a D50 white point:
"Since Adobe Photoshop and the ICC profile specifications both use D50 as a reference white, this was the logical choice. If instead, a non-D50 white was chosen, then both the creation of, and the use of the working space would require adaptation, which opens the door just a crack for mistakes to be made. Specifying the working space directly in D50 avoids this possibility for error."
Your comments?
Regards,
Bill
-
> This is what you do when you are not able to answer.
Are you talking to yourself?
> In a real scene you can have several illuminants, not several color spaces
So, AdobeRGB is defined independent of the illuminant? Funny where it took you.
-
> you could as well process the same file with different white points
Better to convert using a proper mixture of absolute, relative, and perceptual intents.
-
> you could as well process the same file with different white points
Better to convert using a proper mixture of absolute, relative, and perceptual intents.
this workflow sounds quite cumbersome.
I always leave my files in the so called "camera profile" of Capture One. These are linearized, Gamma 1.8 coded colour spaces based on charaterization data of the respective cameras; tweaked to create a certain "look" but still based on charaterization data.
I can modify my "camera profile" in any fashion I'd like to... selectively.
So no need to mix different RI's... just edit the files so that they look "good" (or "correct" if this is what you want to achieve).
As we have found out, Adobe CMM does not perform absolute colorimetric conversion with matrix based profiles.
"ACE" does not.
"AdobeCMM" does -> http://www.adobe.com/support/downloads/detail.jsp?ftpID=3618
-
> this workflow sounds quite cumbersome.
Actually not if the converter allows to select and set several different white balance zones.
-
> this workflow sounds quite cumbersome.
Actually not if the converter allows to select and set several different white balance zones.
ah, okay... I get it.
In C1 I just select my "camera profiles" (daylight, outdoor daylight, flash, tungsten...) and those provide the required "colour sensitivity" (and gamut) for the respective lighting conditions. Doesn't necessarily mean the image always looks great by default ... but it's quite easy to edit the files accordingly.
-
You wrote:
Well, you do not understand that the better model of the situation is: several colour spaces coexist in the same scene.
I wrote:
In a real scene you can have several illuminants, not several color spaces.
You wrote:
So, AdobeRGB is defined independent of the illuminant? Funny where it took you.
Where is my reference to AdobeRGB?
A real scene illuminant color has nothing to do with color space reference white.
You are trying to switch the argument to white balance, but unfortunately you are weak on that argument too.
Jacopo
-
You need to start from the basics. White balance is the form of chromatic adaptation.
-
Iliah,
I have great respect for your intellect ... but who would ever want to have a scene-referred color-matched shot at night in Times Square? It may be an extreme example of mixed illuminants, but who cares?
When I shoot in a place like that, I worry about a pleasant image ... not color-matching a memory.
What's your point? Where is modern color-managed photographic workflow letting you down? I find the current crop of tools MORE than satisfactory - expecially when compared to the world of film and chemicals.
-
I know C1 and the colour management strategy they adopted. However I do not know if they are working on adopting a more modern one. Some other companies are certainly do however. The problem is that colour management developed for scanning and printing is rooted in the minds of digital camera users and changing it means a significant commercial risk for a well-established company.
-
Uh huh...so for the purposes of transforming an image currently in Adobe RGB (1998) to ProPhoto RGB, ALL of the colors within Adobe RGB (1998) will get mapped to, and fit within, ProPhoto RGB without any clipping?
I think it's been demonstrated now multiple times that a slanted strip of colors in Adobe RGB (D65) from around blue to white has no direct linear representation in Prophoto RGB (D50). As an example an image pixel which is normalized ([0,0,1]) in Adobe RGB (D65) is out of bounds of the gamut of Prophoto RGB (D50).
Joofa
-
Some other companies are certainly do however.
Who and what?
Sandy
-
> but who would ever want to have a scene-referred color-matched shot at night in Times Square?
Architects, in my case.
> What's your point?
My point is we are on the edge of HDR displays being commercially available.
> Where is modern color-managed photographic workflow letting you down?
Modern colour management is not limited to the intents discussed in this thread."Classical" colour management is not letting me down because I know when not to use it. On a side note, funny enough that Munsell's original ideas of colour are much better than what "classical" done while distorting Munsell's space to save on calculations. We do not need those simplified formulae anymore because we have powerful computers instead of rulers.
-
Hi Bill (Bjanes),
You can contain Adobe RGB (D65) in another variant of "Joofa Space" ;D, i.e., Prophoto RGB (D65). And, I mentioned that a number of times including my first note, case (2) below, because it is a larger space:
Joofa wrote on DPReview:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, ProPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, ProPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, ProPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, ProPhoto RGB white point=D65, Fraction needed=0.67
I don't know why Prophoto was standardized at D50 and not at D65.
Sincerely,
Joofa
-
Who and what?
Sandy
Here is one of the examples http://www.cis.rit.edu/fairchild/
-
Here is one of the examples http://www.cis.rit.edu/fairchild/
Not quite a company ::), and looks fairly conventional at a first glance, but thank you anyway; I'm always interested in anything new in color management.
Sandy
-
> Not quite a company
But your question was "who and where".
> looks fairly conventional at a first glance
May need a study, not a glance.
> I'm always interested in anything new in color management.
This is not even "new".
-
Here is one of the examples http://www.cis.rit.edu/fairchild/
Guess he chose not to use such techniques as you describe on the home page image!
(I can't even imagine what that would look like if he had ...)
-
Your mistake is to transform Adobe RGB to ProPhoto RGB without white point scaling. It seems you are not interested on colors, but only on numbers.
Let me try to explain what are you doing:
we know that
- 1 inch=2.54 cm.
- now we are free to fix the unit of measure, and we say that 2.54 are meters (we are going from cgs reference sytem to MKS reference system without scaling)
- conclusion 1 inch=2.54 meters
JBrembat, I have said that a number of times, and I don't know why the point is not getting across that when you go from D65->D50, the length of the "unit stimulus/vector" changes. 1 inch no longer remains 2.54cm!
Sincerely,
Joofa
-
> Guess he chose not to use such techniques as you describe on the home page image!
What type of chromatic adaptation do you see on that image?
-
> but who would ever want to have a scene-referred color-matched shot at night in Times Square?
Architects, in my case.
Would seems a bit like tilting at windmills .... for a commercial product shot in the studio, I get it.
But, trying to color match Times Square at night "accurately" ... seems about as pointless - IMO - as most of this thread. ::)
-
but who would ever want to have a scene-referred color-matched shot
Isn't the direction ILM is taking with EXR in the direction of scene referred color representation instead of output-referred spaces such as Adobe RGB? Its been a while and I have to look into it again that what was it about?
Sincerely,
Joofa
-
> Guess he chose not to use such techniques as you describe on the home page image!
What type of chromatic adaptation do you see on that image?
Would appear that all three images (there are three) were shot with the same film/lighting - or - were digitally processed using the same white point - perhaps to match the combined spectrum of the refracted colors on the wall.
In essence, there is no chromatic adaptation mimicked in the image ... or just one ... an adaptation to the single white point.
Here in the room, I'm currently adapted to the white point of my monitor a I have been staring at it for hours.
-
> there is no chromatic adaptation mimicked in the image ... or just one ... an adaptation to the single white point.
So this image does perfectly illustrate what I'm talking about (I would have taken it differently, in a one shot - but that is beyond the point).
-
But your question was "who and where".
Let me remind you what you said in post 282: "Some other companies are certainly do however."
Your words.
There are uncounted numbers of academics all with a "better" idea, almost all of which will never go anywhere beyond a clever Phd thesis. Not the same as a company actually building real products.
Sandy
-
Joofa, correct me if I'm wrong here and stepping over my bounds. I learned some interesting things from this discussion.
Hi TGray,
You are not stepping over any bounds. And, thanks for understanding what I tried to say. I'm glad that you learned some interesting stuff. The traditional approach to colorimetry has hampered its growth. But there are now some great insights developing borrowing from the areas of signal processing and linear algebra. Stay tuned.
Best regards,
Joofa
-
> Guess he chose not to use such techniques as you describe on the home page image!
What type of chromatic adaptation do you see on that image?
Iliah, - would you have any images for illustration to make the point here ?
Peter
--
-
> there is no chromatic adaptation mimicked in the image ... or just one ... an adaptation to the single white point.
So this image does perfectly illustrate what I'm talking about (I would have taken it differently, in a one shot - but that is beyond the point).
I don't get it ... one shot processed at "daylight" (or whatever) with today's tools would produce that result, no?
-
> Let me remind you what you said in post 282: "Some other companies are certainly do however." Your words.
I was answering you question. Now you can check the list of sponsoring companies.
> There are uncounted numbers of academics all with a "better" idea
I hope in your comment you do not mean Fairchild.
-
I don't know why Prophoto was standardized at D50 and not at D65.
There are many things you don't know.
Prophoto was developed for reflectives media (prints). D50 is the standard for prints.
But for color management, a white point of D65 doesn't change anything.
Of course matrices to go from/to XYZ should be different.
You need to start from the basics. White balance is the form of chromatic adaptation.
Chromatic adaptation for color space conversion is not white balance.
Again you are mixing things.
Adaptation for different white references of color spaces has nothing to do with adaptation for white balance.
You think you can do white balance using a conversion between color spaces. But you can't.
You really need to start from the basics.
Color management target is "preserving colors between color spaces". It is not for white balance.
1 inch no longer remains 2.54cm!
Better than Einstein restricted relativity!
And then your AdobeRGB blue is no more the same color.
You stated that starting from a causual XYZ value (not AdobeRGB blue primary) you can go out of ProPhoto.
I can say more:
starting from an XYZ value you can go out from visible colors.
Very nice sentence. LOL
Jacopo
-
But for color management, a white point of D65 doesn't change anything.
Of course matrices to go from/to XYZ should be different.
So, if D65 does not change anything then why does the matrix change?
Chromatic adaptation for color space conversion is not white balance.
Hmmm.......
Better than Einstein restricted relativity!
Isn't that cool? Color theory and relativity. BTW, do you know that famous physicsts Maxwell and Nobel laureate Schrodinger, among others, did important work in color theory. It appears that our own Emil Martinec is interested in color also? What color attracts physicists?
Sincerely,
Joofa
-
"In color science, chromatic adaptation is the estimation of the representation of an object under a different light source than the one in which it was recorded."
"A common application is to find a chromatic adaptation transform (CAT) that will make the recording of a neutral object appear neutral (color balance), while keeping other colors also looking realistic."
See http://en.wikipedia.org/wiki/Color_balance , read the report ISBN 978 3 901906 30 5, and come back after that.
-
There are many things you don't know.
Prophoto was developed for reflectives media (prints). D50 is the standard for prints.
Other reasons are spelled out here:
http://www.photo-lovers.org/pdf/color/romm.pdf
http://www.kodak.com/global/plugins/acrobat/en/professional/products/software/colorFlow/romm_rgb.pdf
-
That is an interesting proposition, but we usually do not want the colors to shift and use relative colorimetric.
Bill,
Aside from RelCel, it was suggested that White balance is also a form of chromatic adaptation in order to map source white to target white. And we really would not want to "relcol" i.e. to click-whitebalance every image in the Raw converter. Often enough we find it desirable to preserve a bit of the original illuminant & scene white in order to preserve the mood of a scene (let’s call it partially AbsCol). Chromatic adaptation is not perfect in my eyes.
So in total we do not necessarily have a strict RelCol mapping / chromatic adaptation from scene white to monitor white. As for the working space in-between, the question remains about the influence of its white point. Could Adobe RGB D65 really hold specific colors from a scene that are de facto outside ProPhotoRGB D50 in an absolute colorimetric sense, let’s say if we could replace the linear-gamma-ProPhoto RGB version inside ACR by a corresponding linear-gamma-Adobe RGB space. Sorry – I don’t know.
I’d agree that the "barrel capacity" of ProPhoto RGB is probably not the first thing to be concerned about it. Discussion was interesting though.
Kind regards,
Peter
--
-
Thanks for the references, Digital Dog.
Sincerely,
Joofa
-
Could Adobe RGB D65 really hold specific colors from a scene that are de facto outside ProPhotoRGB D50 in an absolute colorimetric sense, let’s say if we could replace the linear-gamma-ProPhoto RGB version inside ACR by a corresponding linear-gamma-Adobe RGB space. Sorry – I don’t know.
--
Why not use Prophoto RGB (D65)? It can have all of Adobe RGB (D65) contained within.
Joofa
-
Why not use Prophoto RGB (D65)? It can have all of Adobe RGB (D65) contained within.
Joofa, - even for me the purely theoretical part is now over,
and you may note that I was very open to your mindset.
IMO the task now is to come up with a practical example and some real-world images for illustration.
I've been asking Iliah but please feel invited as well.
Cheers! Peter
--
-
Why not use Prophoto RGB (D65)? It can have all of Adobe RGB (D65) contained within.
why not use a D50 color space large enough to contain all the colors a camera could capture potentially?
I assume C1's internal colour space meets these requirements. Not sure, though. In any case it seems to be an extremely large colour space.
-
> IMO the task now is to come up with a practical example and some real-world images for illustration.
Illustration of what, please? That colour perception is not restricted to relative colorimetric?
-
why not use a D50 color space large enough to contain all the colors a camera could capture potentially?
You can't increase the "gamut" of a particular color space arbitrarily. It is tied to the white point and primaries. So Adobe RGB (D50 or D65) has a gamut what it has. But Prophoto RGB (D65) includes those troublesome areas of Adobe RGB (D65) which are not represented in Prophoto RGB (D50), and hey, you also get the same white point.
On the other hand one way to "mathematically" increase the gamut is:
(1) If you let overstaturation - more than unit stimulus.
(2) Negative coefficients for tristimulus.
Actually, with both (1) and (2) above, the whole concept of gamut crumbles, because now you can span all of the color space.
Sincerely,
Joofa
EDIT: Modified. Several typos.
-
You can't increase the "gamut" of a particular color space arbitrarily. It is tied to the white point and primaries.
does this also apply to table based profiles? IMO only to matrix based profiles...
-
does this also apply to table based profiles? IMO only to matrix based profiles...
I was not thinking in terms of profiles when I wrote that. I was thinking of a standard definition of a linear color space that I have given before. Human vision is considered to have 3 dimensions, so it is a 3D space. The 4th vector (white point) is there to set units.
Joofa
-
OMG...I can’t believe this needs to be explained…
White balance changes colors.
Adaptation keeps colors the same.
Put another way...white balance results in a change to the color response of the human eye. Adaptation maintains the color response of the human eye.
If you use Iliah’s method of using the Bruce Lindbloom calculator to convert not 0,0,255...but 128,128,128 from Adobe to Pro Photo...you’ll see that the resulting conversion is not neutral. Hence, the color has changed. The only way to get a neutral result (that is to say, the same color response) is to use adaptation. When this is done, the calculator calculates equal values of RGB for the Pro Photo space.
-
So, if D65 does not change anything then why does the matrix change?
When you build an RGB color space, you have to fix :
red,green,blue primaries,white point and a transform to go from/to linear RGB values and nonlinear RGB values (this is what is named "gamma" encoding, as many color spaces use a power nonlinear function, power=gamma).
Starting from this set of values, you can define how to go to/from XYZ.
CIE_XYZ is the mother of any color space.
If you change the white reference, the matrices reflect this change.
This is the reason you cannot change white reference without adaptation when you convert from a color space to a different color space with a different white point.
The matrices to/from XYZ are white reference dependents.
The same is true for Lab. You have to fix a white reference.
ICC fixed D50 as white reference for PCS (Profile Connection Space, XYZ or Lab).
Why not use Prophoto RGB (D65)? It can have all of Adobe RGB (D65) contained within
.
No difference all adobe RGB colors are contained in ProPhoto (D50 white reference).
David Coffin dcraw can output data in ProPhoto (D65). I don't investigate the reason, may be it was more simple. But there is no any difference in color management results.
Jacopo
-
I was not thinking in terms of profiles when I wrote that. I was thinking of a standard definition of a linear color space that I have given before. Human vision is considered to have 3 dimensions, so it is a 3D space. The 4th vector (white point) is there to set units.
how could I create this colour space (i.e. the wirframe; white = ProPhoto)?
I could apply even more saturation but then the white point would start to shift towards yellow/red.
http://www.luminous-landscape.com/forum/index.php?action=dlattach;topic=49940.0;attach=35168;image
-
how could I create this colour space (i.e. the wirframe; white = ProPhoto)?
I could apply even more saturation but then the white point would start to shift towards yellow/red.
http://www.luminous-landscape.com/forum/index.php?action=dlattach;topic=49940.0;attach=35168;image
Isn't it the same image we saw before which was a union of two different color spaces? May be I don't remember exactly. I need to go back and search for that message.
Joofa
-
Isn't it the same image we saw before which was a union of two different color spaces? May be I don't remember exactly. I need to go back and search for that message.
no. It's one single colour space. But table based, not matrix based.
And it is a color space... you could actually use it.
You won't ... but you could.
-
no. It's one single colour space. But table based, not matrix based.
And it is a color space... you could actually use it.
You won't ... but you could.
So what is the point?
-
So, if D65 does not change anything then why does the matrix change?
Hmmm.......
Isn't that cool? Color theory and relativity. BTW, do you know that famous physicsts Maxwell and Nobel laureate Schrodinger, among others, did important work in color theory. It appears that our own Emil Martinec is interested in color also? What color attracts physicsts?
Sir Issac Newton, possibly matched only by Einstein in his contributions to physics, made seminal investigations into color. Also controversy is not new in the field. See this article on Zur Farbenlehre (http://en.wikipedia.org/wiki/Theory_of_Colours). Newton was more concerned with the physical measurement of color whereas Goethe was more concerned with the perception of color. What's new under the sun?
Regards,
Bill
-
So what is the point?
... why not use a D50 colour space large enough to contain all the colours a camera can capture potentially...
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413205#msg413205
-
... why not use a D50 colour space large enough to contain all the colours a camera can capture potentially...
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413205#msg413205
I still don't see where you are getting at? You already have a linear XYZ color space that contains all of the colors that you can see.
Joofa
-
If you change the white reference, the matrices reflect this change.
But I thought you said that changing white point does not change anything?
No difference all adobe RGB colors are contained in ProPhoto (D50 white reference).
I thought with the wonderful graphs presented it has been established that Adobe RGB (D65) is not fully contained within Prophoto RGB (D50). Were you paying attention?
Joofa
-
There is a color space that is a lot larger than ProPhotoRGB, It is called DCam 5, developed by Joseph Holmes.
It is so huge that covers all visible colors. To achieve this, he uses a blue primary with negative coordinates.
http://www.josephholmes.com/propages/gamuts/DCam5.jpg (http://www.josephholmes.com/propages/gamuts/DCam5.jpg)
Scroll down this page (http://www.josephholmes.com/propages/SpacesandSets.html) until "7)DCam 5, J. Holmes" for a description
I don't have personal experience with it, but is surely looks interesting.
-
why not use a D50 color space large enough to contain all the colors a camera could capture potentially?
ProPhoto try to maximize the coverage of visible gamut. To do that imaginary primary are defined.
The problem is that the visible gamut is not a triangle. So something cannot be covered.
In any case natural colors are generally covered.
ICC was trying to solve a similar problem in ICC v4.
In this case the aim is to define a gamut that includes all the rendering device,specially printers.
But ICC v4 is not diffused and, in my opinion (but Greame Gill,author of Argyll, thinks the same),it's not very good for other things.
Jacopo
-
I still don't see where you are getting at? You already have a linear XYZ color space that contains all of the colors that you can see.
then I don't understand why you suggested to use a ProPhoto/D65
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413196#msg413196
never mind...
-
then I don't understand why you suggested to use a ProPhoto/D65
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413196#msg413196
Oh, that one. I suggested that in reference to all of so much talk about Adobe RGB (D65) and Prophoto RGB (D50). When I did my calculations I noticed that when I changed Prophoto RGB from D50->D65, the red and green primaries unit stimuluses did not bump a whole lot and apparently only the blue primary readjusted in a way that Adobe RGB (D65) was neatly contained in it. So I thought it was a natural container for all of those Adobe RGB (D65) blue to white shades that fall outside Prophoto RGB (D50).
Sincerely,
Joofa
-
But I thought you said that changing white point does not change anything?
I'm a little tired to explain the same thing.
I said:
you have to change white point from source color space to target color space to preserve colors.
I thought with the wonderful graphs presented it has been established that Adobe RGB (D65) is not fully contained within Prophoto RGB (D50). Were you paying attention?
Adobe RGB color space is contained in ProPhoto color space.
You can build wrong graphs as you can build wrong numbers.
If you use the correct way to go from a source color space to a target color space, you get the answers.
I tried to explain how a RGB color space is builded. If you don't understand, please read some book or surf the web.
Jacopo
-
Joofa, - even for me the purely theoretical part is now over,
and you may note that I was very open to your mindset.
IMO the task now is to come up with a practical example and some real-world images for illustration.
I've been asking Iliah but please feel invited as well.
Cheers! Peter
Hi Peter,
This whole discussion started from a comment of Bill (BJanes) when he said something about gamuts. I was intrigued to investigate Prophoto RGB and Adobe RGB gamuts and presented my findings with 4 cases. If you remember even the title of my original note on DPRview was "When is ProPhoto RGB gamut bigger than Adobe RGB?" Please notice the word "When" as I presented 4 cases I found interesting. I thought it will be an interesting topic for LL and DPReview communities.
But I was not prepared for the personal attacks.
I am not a professional photographer and I am not ashamed to admit that I don't understand many of the tools used in commercial photography world because I don't use them. I don't even understand all of the lingo associated with them. All of the graphs and other things I did was based upon starting from elementary data regarding Adobe and Prophoto RGB spaces on Wikipedia and I plotted them by hand. However, this weakness of mine was attacked ferociously by many to indicate that I don't want to use certain tools.
I have studied color science and use some advanced topics in a very restrictive domain that does not match with commercial photographers.
So when I ask questions like "Why don't you use Prophoto RGB (D65)?" it is actually not criticizing anybody but I wanted to learn that what stops a professional photographer from using such stuff by slight alteration to standardized parameters.
Hope that helps.
Best regards,
Joofa
-
Why not use Prophoto RGB (D65)? It can have all of Adobe RGB (D65) contained within.
And exactly how would you get an image into ProPhoto RGB D65? You can't get it inside of Camera Raw or Lightroom because they use an internal ProPhoto RGB color and a linear gamma. The white point is D50. So, you would have to do so using a color transform which as we already discovered does a chromatic adaptation. What would be the point? You can already contain all of Adobe RGB (1998) inside of ProPhoto RGB when you do a chromatic adaptation based color transform.
Maybe C1 could process into a ProPhoto RGB D65 profile but since we don't know the internal color space used by C1, we don't really know that ProPhoto RGB D65 would be any better or worse...
So, what raw processor could use ProPhoto RGB D65? If none could, the point is moot.
-
> And exactly how would you get an image into ProPhoto RGB D65?
While it is not very relevant to the discussion, it is easily accomplished, even if converting through ACR/LR. Make a DNG and pre-process it before feeding to a converter.
-
ProPhoto try to maximize the coverage of visible gamut. To do that imaginary primary are defined.
The problem is that the visible gamut is not a triangle. So something cannot be covered.
but that is only a limitation of matrix based profiles.
attached (first attachment) the gamut of a (table based) profile I use mostly (colored; wireframe = ProPhoto; both D50). Actually it's smaller than ProPhoto... but the saturation in the bright blue and magenta exceeds ProPhoto.
Almost all "camera working spaces" in C1 exceed ProPhoto in the (bright) blue and/or magenta and/or cyan... while beeing somewhat smaller overall.
Maybe C1 could process into a ProPhoto RGB D65 profile but since we don't know the internal color space used by C1, we don't really know that ProPhoto RGB D65 would be any better or worse...
looking at the profile Phase provides for your P65 (second attachment) it covers a lot of blue and magenta not contained in ProPhoto (like all other camera profiles also the P65 profiles are D50).
-
Maybe C1 could process into a ProPhoto RGB D65 profile but since we don't know the internal color space used by C1, we don't really know that ProPhoto RGB D65 would be any better or worse...
And its entirely possible that the processing color space is quite different, maybe smaller than this variant of ProPhoto or even ProPhoto itself and either is only used as an encoding color space (convert and spit out data in this space).
One would also have to wonder, if a D65 variant of ProPhoto is so advantages, why didn’t Adobe utilize it? We have Melissa RGB, proving that Adobe isn’t shy about creating their own color spaces. If the ACR team (Thomas) really wanted a D65 variant or something with totally different, I’m sure he would have done so. The Kodak white papers discuss why they decided on a D50 WP. Some could debate their decisions were wrong.
-
> IMO the task now is to come up with a practical example and some real-world images for illustration.
Illustration of what, please? That colour perception is not restricted to relative colorimetric?
yes please - could be a good starting point.
... If you remember even the title of my original note on DPRview was "When is ProPhoto RGB gamut bigger than Adobe RGB?" ...
Or the other way round: when is Adobe RGB gamut bigger than ProPhoto RGB ?
For me it is answered. Joofa, - many thanks for all the lessons learned here !
Let's move to the next question: when and where could it really matter ?
And exactly how would you get an image into ProPhotothe RGB D65? You can't get it inside of Camera Raw or Lightroom because they use an internal ProPhoto RGB color and a linear gamma. The white point is D50...
So you're sure that Eric Chan ('madmanchan') couldn't place a different color space in the heart of ACR...
Of course aside from all restrictions of time, priorities in life, and possible sense of this excersise.
Peter
--
-
So you're sure that Eric Chan ('madmanchan') couldn't place a different color space in the heart of ACR...
No, I'm quite sure he could (and would) if a strong use case could be made. So far I'm not convinced (I can't speak for him although I'll guarantee he's been lurking in this thread).
The one new color space I would like to have in ACR/LR is ProPhoto RGB colors and a linear gamma as an output space. This would allow some Photoshop work done in a ProPhoto RGB linear gamma (I do have a working space profile for that) without having to do a gamma correction to linear and back. Alas, Thomas Knoll said that was pointless since doing the gamma conversion to/from/to isn't very destructive.
You CAN do an export from Lightroom into arbitrary color spaces so one could go into a ProPhoto RGB D65 profile but considering the source processing is done based on D50, I'm not sure that would accomplish too much.
I'll have to take a look at C1 and see if outputting to ProPhoto RGB D65 offers anything...not sure it would. I'm not 100% sure the profiles for the P65+ are actual built profiles from the sensor or if they are arbitrary color spaces...I'll have to ask (and see if I can get permission to post it).
-
> yes please - could be a good starting point.
Do you have a shot with a portrait in a shadow of tree and a asphalt road lit by Sun? That would be a good starting point. Or a shot taken with a fill flash in a room lit by incandescent lamps? That would be a good starting point too.
-
Let's move to the next question: when and where could it really matter ?
What about multispectral imaging in a very narrow bandwidth around those non-overlapping gamuts?
Joofa
-
I'm not 100% sure the profiles for the P65+ are actual built profiles from the sensor or if they are arbitrary color spaces...
they are based on characterization data but further tweaked. So they do not represent all the colours a camera captures (they would be much larger then). Besides they are linearized and coded in Gamma 1.8. In a way they are the "ideal" individual working spaces for the respective cameras (I for one embed the camera profile on output and do all the further editing in Photoshop in that color sapce).
If you have a shot of a gretag macbeth chart and switch the "film curve" to "linear response" and set the input profile ("camera profile") to "no color correction" (or "color view", which is the same) and back to one of the approriate P65 profiles I think you pretty quickly understand how the camera profiles work.
-
Alas, Thomas Knoll said that was pointless since doing the gamma conversion to/from/to isn't very destructive.
It would be convenient if there was a simple to use interactive gamma adjustment accessible through layers in Photoshop. Too bad the gray slider in levels has some aberration from a true gamma transformation... This guy talks about it here on page 19 (http://www.c-f-systems.com/Docs/ColorIntegrityCFS-243.pdf). Instead we have to resort to doing it with color profiles or outside of Photoshop.
-
The one new color space I would like to have in ACR/LR is ProPhoto RGB colors and a linear gamma as an output space. This would allow some Photoshop work done in a ProPhoto RGB linear gamma (I do have a working space profile for that) without having to do a gamma correction to linear and back. Alas, Thomas Knoll said that was pointless since doing the gamma conversion to/from/to isn't very destructive.
The one and only new internal processing space I would like to have in ACR/LR (aside from current linear gamma ProPhoto RGB) is a somewhat smaller internal working space. A kind of an earlier binding when the final target is a small output space. But that's off topic here, and once I find the time I'll open a new thread on this. Need to work out a good example on its usefulness. Referring to you as an author, I'd trust you know what I mean regarding the effort to publish something.
Do you have a shot with a portrait in a shadow of tree and a asphalt road lit by Sun? That would be a good starting point. Or a shot taken with a fill flash in a room lit by incandescent lamps?
Comeon, if you have the right images for illustration please kindly just clip it in here.
Peter
--
-
> Comeon, if you have the right images for illustration please kindly just clip it in here.
I do not understand you. First, you have necessary images yourself - about 90% of images taken outside of a studio have some regions that show why current conversion technique is limiting. If that would not be the case no local editing to get natural colour shall be needed. Second, I can't "clip in" a raw image here.
Anyway. The moment I will see this discussion is getting back to something that is of interest to me I will continue. Those who feel that "classical" colour management is all they need - why worry? Just to put down those who bring in legitimate questions with maxims like "white balance changes color"? LOL.
Those who see how "classical" colour management (and it was not meant to address the problems of digital capture by the way) fails to satisfy their customers may want to take some of the points that were already discussed here.
-
The moment I will see this discussion is getting back to something that is of interest to me I will continue.
Oh, thanks.
Second, I can't "clip in" a raw image here.
... Those who feel that "classical" colour management is all they need - why worry? Just to put down those who bring in legitimate questions with maxims like "white balance changes color"? LOL.
Those who see how "classical" colour management (and it was not meant to address the problems of digital capture by the way) fails to satisfy their customers may want to take some of the points that were already discussed here.
The contradiction is that customers typically don't receive and view raw images. However, I'm not a professional in this business. So if you have a showcase for customer-dissatisfaction based on "classical" color management please just contribute. Ideally referring to the content of this thread. I'm all open for legitimate and illegitimate question (on color management).
Why am I under the impression that there is nothing more to come.
--
-
Wow, I just read this whole thread and I want to thank Joofa for helping me understand a lot about the science of measurement. You are going to save me SO much time on my commute to work. You see, I've always been driving to work in kilometers. 15 kilometers to be exact. Now I realize that I can drive to work in miles and shave about 40% off my commute.
I'll attach a graph I made illustrating this fact.
The green line on the bottom is a number line (canonical and absolute). The blue line is my old commute 15 the red line is my new commute 9.32. You can tell by looking how much shorter my new commute will be (red line).
Remember, don't be unappreciative of the fact there is not a single coordinate system in this scenario. There are three in the same 2D space! One is the canonical number line whose "unit vector" length is fixed. (I can't take credit for this line of genius; I'm paraphrasing Joofa.)
Thanks Joofa! I'm going to save so much money. (Speaking of money, I'm asking my boss tomorrow if he'll switch my pay to Rupies. I just saw the conversion ratio!!)
-
Wow, I just read this whole thread and I want to thank Joofa for helping me understand a lot about the science of measurement. You are going to save me SO much time on my commute to work. You see, I've always been driving to work in kilometers. 15 kilometers to be exact. Now I realize that I can drive to work in miles and shave about 40% off my commute.
I'll attach a graph I made illustrating this fact.
The green line on the bottom is a number line (canonical and absolute). The blue line is my old commute 15 the red line is my new commute 9.32. You can tell by looking how much shorter my new commute will be (red line).
Remember, don't be unappreciative of the fact there is not a single coordinate system in this scenario. There are three in the same 2D space! One is the canonical number line whose "unit vector" length is fixed. (I can't take credit for this line of genius; I'm paraphrasing Joofa.)
Thanks Joofa! I'm going to save so much money. (Speaking of money, I'm asking my boss tomorrow if he'll switch my pay to Rupies. I just saw the conversion ratio!!)
Stephen, unfortunately, what I have said is true. "Unit stimulus/vector" is a varying quantity for each primary. Your miles/km analogy is incorrect. Because that refers to the same entity being measured. I'm not talking about that at all. Please reread what I have written.
Joofa
-
Stephen, unfortunately, what I have said is true.
No, you’re wrong. You have a fundamental misunderstand at the most basic level...your unwillingness to understand the reason for adaptation in color conversion. You can’t seem to grasp neither the fact that color exist only in our minds, nor the implications of that fundamental truth.
At this point I think you're beyond help. You're not going to change your thinking until you actually see your attempts at color conversion fail. Only then will you question your incorrect assumptions. Let's hope this happens sooner rather than later. Hopefully, you won't spread your incorrect information too far.
-
I note that the mistake Stephen Jones is making has resulted in widely held misconceptions about colorimetry, including:
(1) a linear color space is not perceptual enough; resulting in Lab space being overrated
(2) color space distance metrics derived from nonlinear coordinate systems are necessarily better
(3) unrealistic angular dependencies of various color stimuli
Joofa
-
No, you’re wrong. You have a fundamental misunderstand at the most basic level...
Anybody could be wrong and I am no exception. I am trying to learn.
You can’t seem to grasp neither the fact that color exist only in our minds, nor the implications of that fundamental truth.
That was the colorimetry of 80 years ago. Now it is being put on a rigorous linear algebraic framework in an overall signal processing environment.
At this point I think you're beyond help. You're not going to change your thinking until you actually see your attempts at color conversion fail. Only then will you question your incorrect assumptions. Let's hope this happens sooner rather than later. Hopefully, you won't spread your incorrect information too far.
Gosh, you have an axe to grind against me.
Joofa
-
Anybody could be wrong and I am no exception. I am trying to learn.
It feels more like you're trying to dictate. You show no willingness whatsoever to explore the possibility that you may be wrong.
That was the colorimetry of 80 years ago. Now it is being put on a rigorous linear algebraic framework in an overall signal processing environment.
Statements like this just prove my point.
-
Stephen, unfortunately, what I have said is true. "Unit stimulus/vector" is a varying quantity for each primary. Your miles/km analogy is incorrect. Because that refers to the same entity being measured. I'm not talking about that at all. Please reread what I have written.
Nope, not at all. Consider this. I take my drive to work in kilometers and measure it in numbers, call it A, and then I I take my drive to work in miles and measure in numbers, and call it B. And A is not the same as B! A is greater that B! These two different sets of numbers are related by a conversion model say, KM to Miles, but that is all it is about. Now suppose I decide to measure A and B in a system which has rational numbers. I have selected my distances (number line coordinates.) However, there is still a very important step here that Joofa is not realizing. While I have picked my numbers I have not defined that while measuring A and B which what is my units. I have two natural choices, either pick KM or miles, or I can even pick a third unrelated unit. But we shall only concentrate on the first two. KM is set to produce a distance value of 15 for A, but something else for B. What Joofa seems unappreciative of the fact is that when he throws in conversion model it internally restructures the metric system, so that miles are now set to produce the number 9.32 for B, effectively becoming 15. At this stage he forgets about distance A, which still exists. And if we measure A in the new system then it will be a longer drive.
-
Nope, not at all. Consider this. I take my drive to work in kilometers and measure it in numbers, call it A, and then I I take my drive to work in miles and measure in numbers, and call it B. And A is not the same as B! A is greater that B! These two different sets of numbers are related by a conversion model say, KM to Miles, but that is all it is about. Now suppose I decide to measure A and B in a system which has rational numbers. I have selected my distances (number line coordinates.) However, there is still a very important step here that Joofa is not realizing. While I have picked my numbers I have not defined that while measuring A and B which what is my units. I have two natural choices, either pick KM or miles, or I can even pick a third unrelated unit. But we shall only concentrate on the first two. KM is set to produce a distance value of 15 for A, but something else for B. What Joofa seems unappreciative of the fact is that when he throws in conversion model it internally restructures the metric system, so that miles are now set to produce the number 9.32 for B, effectively becoming 15. At this stage he forgets about distance A, which still exists. And if we measure A in the new system then it will be a longer drive.
Interesting parody ;D
May be if you pay close attention to what I wrote you can figure out where are you going wrong?
Sincerely,
Joofa
-
Anybody could be wrong and I am no exception. I am trying to learn.
You are not trying to learn.
You are trying to assert that Adobe 1998 blue color is outside of ProPhoto gamut.
You are wrong and you are not able to understand your mistake.
You are not trying to learn.
Jacopo
-
Nope, not at all. Consider this. I take my drive to work in kilometers and measure it in numbers, call it A, and then I I take my drive to work in miles and measure in numbers, and call it B. And A is not the same as B! A is greater that B! These two different sets of numbers are related by a conversion model say, KM to Miles, but that is all it is about. Now suppose I decide to measure A and B in a system which has rational numbers. I have selected my distances (number line coordinates.) However, there is still a very important step here that Joofa is not realizing. While I have picked my numbers I have not defined that while measuring A and B which what is my units. I have two natural choices, either pick KM or miles, or I can even pick a third unrelated unit. But we shall only concentrate on the first two. KM is set to produce a distance value of 15 for A, but something else for B. What Joofa seems unappreciative of the fact is that when he throws in conversion model it internally restructures the metric system, so that miles are now set to produce the number 9.32 for B, effectively becoming 15. At this stage he forgets about distance A, which still exists. And if we measure A in the new system then it will be a longer drive.
To run with this analogy a bit more, I think the situation is a bit more accurately translated as the funhouse illusion known as an Ames Room:
(http://theory.uchicago.edu/~ejm/pix/20d/posts/dpr/ames-room-2.jpg)
Your height stays fixed but depending on the environment you appear to be taller or shorter. Similarly in the present discussion, the physical quantity -- the XYZ spectral responses -- stay fixed; what changes is your perception of the color depending on the environment in which those spectral responses are perceived. The man on the right appears to be out of gamut ;)
In the other direction, a quite direct analog of the Ames Room was given many pages ago here, where someone posted an image with a checkerboard in it, depending on whether it was in light or shadow, a square with the same tristimuli appeared to be lighter or darker depending on its surrounding squares.
-
Similarly in the present discussion, the physical quantity -- the XYZ spectral responses -- stay fixed; what changes is your perception of the color depending on the environment in which those spectral responses are perceived.
Right...those environments being the Standard Illuminants. Each standard illuminant has a calculated white point in the XYZ space. The human perception of an XYZ color depends on which white point you're "looking" from.
If you convert an RGB space into XYZ using the white point of the RGB space, that white point now defines where the human is "looking" from. When converting that same human "point of view" into a another RGB space, you can't simply change the XYZ white point...that changes where you're "looking" from.
But that is exactly what Joofa is doing with his "absolute" conversions. There's nothing absolute about them...you're simply using the white point of the destination RGB space to reset the white point of the XYZ space...you’re now “looking” at the XYZ coordinates from a different place, and that makes the color appear different.
A same-color conversion that changes the color, is no conversion at all. Who cares if a different blue isn’t in the Pro Photo space?
(Watch...Joofa will respond with, “No, look at the chart.”)
-
What about multispectral imaging in a very narrow bandwidth around those non-overlapping gamuts?
Let’s assume we stand outside the house at somewhat D50 light. Through the windows we see there is colder D65 light inside the house. Let’s further assume that the camera does not impose any limitations to capture the gamut of such scene.
Then comes the conversion of the demosaiced "Raw" RGB data to the working space or internal working space of the Raw converter. Here we have the option to control white-point-mapping by means of the given Temp. and Tint sliders. Now there are two different cases whether we click-whitebalance on a D50 white or a D65 white from the initial scene. And we further can construe different cases depending on the working spaces that are tried here. Let’s stay with regular Adobe RGB D65 vs. ProPhoto RGB D50, or linear-gamma versions thereof when we talk about the internal working space of the Raw converter.
Your assumption - if I understand it correctly – is that Adobe RGB could hold specific colors from inside the house which are out-of-gamut with ProPhoto RGB. And you may be right in an absolute colorimetric sense: White to saturated blue colors from inside the house can be out-of-ProPhoto RGB when we click-whitebalance on the D50 reference white of the scene. Same colors can be inside Adobe RGB when we click-whitebalance on the D65 white from inside the house.
But then we could as well have click-whitebalanced on the D65 white while using the ProPhoto RGB space, thus capturing all in-house colors and probably much more from outside the house.
The point here is that it does not seem to be possible to freeze the absolute colorimetric differences between Adobe RGB and ProPhoto RGB. It is becoming irrelevant.
The same click-whitebalance operation changes its meaning from somehow AbsCol (e.g. scene D65 white to Adobe RGB D65) to somehow RelCol (scene D65 white to ProPhoto D50) depending on the working space used. Subsequent conversion to the monitor white is RelCol anyway.
Peter
--
-
Your assumption - if I understand it correctly – is that Adobe RGB could hold specific colors from inside the house which are out-of-gamut with ProPhoto RGB.
Hi Peter,
I mentioned multispectral imaging in a narrow bandwidth.
I did not say colors coming from a house - typically they are wideband and even a few narrowband colors are drowned in a sea of otherwise those colors that have respresentation in both Adobe RGB (D65) and Adobe RGB (D50). So that the traditionally held conventional photography viewpoint to "keep neutrals the same" suffices (by chromatic transformation), for usual photographs, because, who cares if a few colors are off, and even if somebody cares, then as Iliah Borg says, manual intervention is employed to develop them to liking.
Sincerely,
Joofa
-
Similarly in the present discussion, the physical quantity -- the XYZ spectral responses -- stay fixed; what changes is your perception of the color depending on the environment in which those spectral responses are perceived.
I think with those cool graphs Jc1 has independently verified that the same XYZ color becomes in-gamut for Adobe RGB (D65) and out-of-gamut for Adobe RGB (D50), and hence, by extension to Prophoto RGB (D50).
Sincerely,
Joofa
-
(Watch...Joofa will respond with, “No, look at the chart.”)
No, I won't ask you to look at any of my charts. Have you ever looked at the standard chromacity diagram presented in countless books and available everywhere online? What do you think is wrong with it?
Joofa
-
But then we could as well have click-whitebalanced on the D65 white while using the ProPhoto RGB space, thus capturing all in-house colors and probably much more from outside the house.
Isn't that the same as when I said to use Prophoto RGB (D65) instead of standardized Prophoto RGB (D50), but you took objection to that?
Sincerely,
Joofa
-
Have you ever looked at the standard chromacity diagram presented in countless books and available everywhere online? What do you think is wrong with it?
Being a human invention, there's nothing wrong with it. It is exactly what its creators intended it to be.
-
Look along the axis.
Which one? Why don't you just say what you think is wrong and stop the guessing game.
-
Isn't that the same as when I said to use Prophoto RGB (D65) instead of standardized Prophoto RGB (D50), ... ?
No, scene white: D65 is white-balanced and mapped (on)to regular ProPhoto RGB D50 white, which corresponds to a RelCol transform. By purpose I left out all such hybrid spaces as ProPhoto RGB D65 with my considerations as given above in reply #355. However, we could include it if you feel it’s decisive. Also, by purpose I did not presume any limitations regarding the colors being present in the scene, inside or outside the house.
At the and of the day it is one thing to provide evidence for a specific effect, to calculate it, to illustrate it with 2D or 3D plots, or in Photoshop (as I did: Adobe RGB white to blue being abscol outside ProPhoto RGB). It’s however another thing to work out where it really matters along the digital imaging processing chain. So far my conclusion is that it finally does not matter, because it does not seem to be possible to freeze the abscol differences between Adobe RGB and ProPhoto RGB.
Sincerely,
Peter
--
-
No, scene white: D65 is white-balanced and mapped (on)to regular ProPhoto RGB D50 white, which corresponds to a RelCol transform. By purpose I left out all such hybrid spaces as ProPhoto RGB D65 with my considerations as given above in reply #355. However, we could include it if you feel it’s decisive. Also, by purpose I did not presume any limitations regarding the colors being present in the scene, inside or outside the house.
At the and of the day it is one thing to provide evidence for a specific effect, to calculate it, to illustrate it with 2D or 3D plots, or in Photoshop (as I did: Adobe RGB white to blue being abscol outside ProPhoto RGB). It’s however another thing to work out where it really matters along the digital imaging processing chain. So far my conclusion is that it finally does not matter, because it does not seem to be possible to freeze the abscol differences between Adobe RGB and ProPhoto RGB.
Sincerely,
Peter
--
Oh I see what you are saying.
In this particular case of Adobe RGB (D65) and Prophoto RGB (D50) the contentious colors were a segment from saturated blues to white. As Iliah also pointed out that depending upon other spaces and different source and target white points the gamut mismatch can happen in other parts of the spectrum.
So is your conclusion only specific for Adobe RGB (D65)->Prohoto RGB (D50) or it applies as a general case with color management?
Sincerely,
Joofa
-
In this particular case of Adobe RGB (D65) and Prophoto RGB (D50) the contentious colors were a segment from saturated blues to white. As Iliah also pointed out that depending upon other spaces and different source and target white points the gamut mismatch can happen in other parts of the spectrum.
So is your conclusion only specific for Adobe RGB (D65)->Prohoto RGB (D50) or it applies as a general case with color management?
Joofa, - honestly I don’t understand what you mean. My conclusion is "absolute", however, please feel invited to break open these considerations as given in reply # 355, or to provide a different train of thoughts. But please no single lines on "multispectral imaging in a narrow bandwidth" or pointing to 3D gamut plots. I’ll be all open for any fully developed thread along the imaging processing chain about the relevance of Abobe RGB hues being abscol outside ProPhoto RGB.
Sincerely,
Peter
--
-
Joofa, - honestly I don’t understand what you mean. My conclusion is "absolute", however, please feel invited to break open these considerations as given in reply # 355, or to provide a different train of thoughts. But please no single lines on "multispectral imaging in a narrow bandwidth" or pointing to 3D gamut plots. I’ll be all open for any fully developed thread along the imaging processing chain about the relevance of Abobe RGB hues being abscol outside ProPhoto RGB.
Sincerely,
Peter
--
Hi Peter,
I get your point. I want to thank you for being so understanding of some of the stuff I was trying to say. One of my weaknesses, which I have identified before also, is that while I can understand stuff in color theoretic models, I don't fully understand the workflows of professional photography, and especially when it comes to color management through the "usual" stuff.
I shall think more about the issues raised in this thread and if I have anything useful to say then I shall share it.
But thanks again for all the help.
Best regards,
Joofa
-
I had a similar discussion with my ex about France's lack of horses. She doesn't really talk to me anymore, but I don't think she'd mind if I paraphrased an old conversation:
ME: I wonder what the French did before modern transportation without horses. The word 'horse' isn't even in their vocabulary. How did they get around?
SALLY: Huh? They do have a word for horse; it's 'cheval'
ME: Nope. That's not what I'm talking about. I'm talking about 'horse' in an absolute sense. I don't care about 'cheval.' They're not even the same word.
SALLY: I'm talking about the idea. 'Cheval' in French points to the same idea that 'horse' points to in English. 'Horse' is just a word, you can't ride a word.
ME: Well, you can't ride an idea either, what's your point? [Sally could be a little dense and stubborn, which explains why she is the ex, I think].
Now that I've read and understood this thread. I wish I could go back to that warm summer day with Sally. I'd have the perfect retort:
'Horse' is out of the gamut of the French language. I'd like to see her put that in her pipe and smoke it.
Now that I'm on firm scientific ground about this, I'm going to see what important and practical conclusions I can draw from this revelation. Thanks for the help Joofa!
-
I had a similar discussion with my ex about France's lack of horses. She doesn't really talk to me anymore, but I don't think she'd mind if I paraphrased an old conversation:
[SNIPPED]
Now that I'm on firm scientific ground about this, I'm going to see what important and practical conclusions I can draw from this revelation. Thanks for the help Joofa!
Stephen, it is not difficult to understand. Lets take your example of distance to your office. You woke up the first day of your job and left your house, traveled northbound, without turning arrived at your office. You looked at your odometer and distance was 15 KM. Sally calls you. Just checking if you are nervous about your first day. But you seem fine. You looked at the sky. It seemed the weather was going to change soon. But, it was your first day of job, so you had to get in the office.
Before we go on any further a little about the meaning of the notion of distance. 1 KM = 1000 meters. Right? Lets not further divide the meter into cms, mm, etc., and say our "unit vector" is 1m. But how long is one 1m ??? ??? ??? Your odometer has some idea of how long it should be and you trusted it when it told you the distance was 15 KM.
In the evening you wanted to get back home. It was all dark, cloudy, raining cats and dogs, and snowing. You could not see past a short distance. You thought that your office and house were on a straight road and you traveled northbound in the morning 15 KM so you shall go southbound 15 KM and reach home by just paying attention to the odometer. However, meanwhile your odometer had a mind of its own and it changed the notion of how long is a 1m, and it increased its original notion of 1m by some margin, and started thinking that this is the "new" 1m. But you just went blindly by 15KM, so when the odometer told you it is 15KM you looked around but you were not at your home. You were in a dark place with howling wolves around. There is no home, no Sally, no nothing. You got terrified, scared, shaking in boots, closed your eyes, and sincerely prayed that you will never disagree with Joofa again if you get another chance at life. There was a flash in sky, a strange light. You opened your eyes. You were in your bed. The date was your first day of work. You left home, and reached the job, and incidently noted the distance on your odometer. It was 15 KM. You looked at the sky. It was a shining day. Sally calls you. You say you are doing fine. You looked at your office building, and then reached in to your bag in the car, flipped out your digital camera, and thought who cares if it is a first day. Lets snap some pictures.
Sincerely,
Joofa
-
Of course I'm toying with you Joofa, but you're a real champ to play along.
I'm not a photographer, but a friend pointed this thread out and thought I'd enjoy it. And I did. I work in color: I started out working in industrial pigment doping and now I do advanced detection which involves some color modeling. I say that not to impress, but to encourage you to lower your defenses a bit and really understand the disagreement here. It's actually a common disagreement that generally happens when both sides are only willing to understand their half of the problem. It often boils down to photometry vs colorimetry vs. radiometry vs. appearance modeling. Google will be your best friend here.
Basically, Joofa, you are giving too much credit to the CIE XYZ model when it comes to color. Honesty, it's a little comical because you also criticize it at the same time. Now, I use the word color very specifically to mean the interaction between the human visual system, a light source, and an object. You'll hear this called the color triangle in the literature. Because the CIE model has very specific restraints, one gets into all manner of trouble if one tries to replace the human in the triangle with the CIE model. At it's heart, as someone above pointed out, the CIE model only deals with color matching under the same conditions. Again, it's not a model of color, it models color matching—that's a very important distinction. There's a reason the spectral tristimulus values at the heart of the CIE system are called color matching functions. They are not color defining functions.
It really is useful to talk about absolute colors. But an XYZ tristimulus value is only a color in the same sense that a spectral power distribution is a color. They are both absolute in their own sense, you are totally right about that, but when you speak of them this way you remove the human from the color triangle and so you are no longer really talking about color.
These days, we find it much more useful to talk about fundamental tristimulus values which are based on cone responses rather than 100 year-old color matching data. Believe me, if the CIE had direct cone response data, they would have used it instead of the color matching function. A stimulus that provides the same cone response can (with a lot of caveats) be called the same color. The RLAB space does this and it's not really hard to understand, but the first thing you will notice when you try to go from XYZ to RLAB is a chromatic adaptation matrix, which you seem to really dislike for some reason. The CIECAM02 model requires the same thing (this is instructive: http://www.polybytes.com/misc/Meet_CIECAM02.pdf but again chromatic adaptation is front and center). All color appearance models need to account for chromatic adaptation because it's a fact of the human visual system and the human visual system is central to any conversation about color.
So now look at your problem from this perspective. Take your blue primary in the Adobe color space and, instead of jumping right into the CIE XYZ model, try to think in terms of cone response. If you do that then you'll be beginning to talk about color rather than a matching model or an old photometric definition. If you'll go that far with me, you'll see that you can in fact produce that same cone response with the ProPhoto space. Which is to say, the color is available in ProPhoto. That isn't to say your facts are wrong, just that they aren't as applicable to color (by mine and most everyone's definition) as you assert.
-
I'm not a photographer, but a friend pointed this thread out and thought I'd enjoy it. And I did.
I’m sure glad he did, welcome!
At it's heart, as someone above pointed out, the CIE model only deals with color matching under the same conditions. Again, it's not a model of color, it models color matching—that's a very important distinction. There's a reason the spectral tristimulus values at the heart of the CIE system are called color matching functions. They are not color defining functions.
It really is useful to talk about absolute colors. But an XYZ tristimulus value is only a color in the same sense that a spectral power distribution is a color. They are both absolute in their own sense, you are totally right about that, but when you speak of them this way you remove the human from the color triangle and so you are no longer really talking about color.
These days, we find it much more useful to talk about fundamental tristimulus values which are based on cone responses rather than 100 year-old color matching data. Believe me, if the CIE had direct cone response data, they would have used it instead of the color matching function. A stimulus that provides the same cone response can (with a lot of caveats) be called the same color. The RLAB space does this and it's not really hard to understand, but the first thing you will notice when you try to go from XYZ to RLAB is a chromatic adaptation matrix, which you seem to really dislike for some reason. The CIECAM02 model requires the same thing (this is instructive: http://www.polybytes.com/misc/Meet_CIECAM02.pdf but again chromatic adaptation is front and center). All color appearance models need to account for chromatic adaptation because it's a fact of the human visual system and the human visual system is central to any conversation about color.
So now look at your problem from this perspective. Take your blue primary in the Adobe color space and, instead of jumping right into the CIE XYZ model, try to think in terms of cone response. If you do that then you'll be beginning to talk about color rather than a matching model or an old photometric definition. If you'll go that far with me, you'll see that you can in fact produce that same cone response with the ProPhoto space. Which is to say, the color is available in ProPhoto. That isn't to say your facts are wrong, just that they aren't as applicable to color (by mine and most everyone's definition) as you assert.
Wow, great post. We really need a volunteer to put all the salient points together into some kind of article for LuLa. While this topic kept going and going, and some of it was OT or nasty, there’s some really great discussions and analogies here. I guess I owe Joofa thanks for bringing this group together and for the results it produced. Just needs some editing.
-
These days, we find it much more useful to talk about fundamental tristimulus values which are based on cone responses rather than 100 year-old color matching data. Believe me, if the CIE had direct cone response data, they would have used it instead of the color matching function. A stimulus that provides the same cone response can (with a lot of caveats) be called the same color.
That has me quite puzzled. I would have thought that all the above discussion about chromatic adaptation would tell us that a given cone response can yield a different color perception depending on the context. Such as the checkerboard 'optical illusion' earlier in the thread (forgive me for not wading through all 19 pages to find it).
-
Stephen,
Firstly, you have not realized that what ever I was saying had chromatic adaptation built right into it - in a way that it will automatically happen, when it was indeed needed. You may not have realized it. And, for that I would encourage you to read my messages again and study my plots more closely.
And, it might appear to you that I am giving to much credit to XYZ, but that is not the case at all. I don't think you have realized why I used the word canonical in relation to it. I will go back to my notion of "how long is 1m"? You need to establish a "yardstick" from which to measure. XYZ, RGB, linear LMS (human vision), or any other linear derivative spaces are no special in this regard. But we have to pick one and use it as a yardstick. And, you may not have realized it, but in calorimetry, the canonical yardstick for measurement is XYZ. That is why there is only a single notion of white point [1,1,1] in XYZ, while other spaces, which are schematically the same, share the same space with XYZ, are allowed to have varying notion of white point. I cannot overemphasize this fact. There is no need to go into models of perception, and chromatic adaption, unless you have realized this basic fact.
If you think that by pointing out the "absoluteness" of XYZ, I am ignoring chromatic adaption, you were not paying attention to my messages.
And, now I would request you to kindly write me a matrix for converting CIE RGB->CIE XYZ?
Thanks,
Joofa
-
> Take your blue primary in the Adobe color space and, instead of jumping right into the CIE XYZ model, try to think in terms of cone response.
Now does the record of colour in a raw file follow cone response?
> we find it much more useful to talk about fundamental tristimulus values which are based on cone responses rather than 100 year-old color matching data
Munsell un-edited experimental data is based on human perception. Does it support your statement?
-
That has me quite puzzled. I would have thought that all the above discussion about chromatic adaptation would tell us that a given cone response can yield a different color perception depending on the context. Such as the checkerboard 'optical illusion' earlier in the thread (forgive me for not wading through all 19 pages to find it).
Dammit—just when I think I'm done with this thread, it gets interesting again.
Emil, I'm totally guessing, but I think this is part of what goes under "a lot of caveats" in Stephen's post.
Chromatic adaptation that you see in color models is generally correcting for sensory adaptation not cognitive adaptation, which is less well understood. Sensory adaptation happens in the retina, in fact each eye adapts independently (It's the basis of haploscopic testing). You can experiment with this yourself if you have some old school 3D glass. Wear them for a while and when you take them off you'll notice the weird sensation for a few seconds as each each eye readapts back to normal light.
I don't think anybody believes color appearance models have even scratched the surface of the cognitive aspects of color, but I think most people think getting the sensory aspects worked out, even a little, is a giant step.
For a REALLY powerful illusions that demonstrates the cognitive aspect of color, check this out: http://www.lottolab.org/illusiondemos/Demo%2014.html
Also Joofa: Hilbert Space? Seriously? Why stop there? If you really want to set up a smoke screen, you should invoke Zariski–Riemann space.
-
Also Joofa: Hilbert Space? Seriously? Why stop there? If you really want to set up a smoke screen, you should invoke Zariski–Riemann space.
Smoke screen. Ha ha ha. :D Only if you paid more attention to my comment than being sarcastic.
But seriously, I don't know how to interpret you? Previously I presented a plot so that others can see what I was thinking. And, you came up with a macho statement that you can also produce plots. Now in my respone to somebody else you come up with another mathematical construct. Are you in some sort of competition with me?
Sincerely,
Joofa
-
For a REALLY powerful illusions that demonstrates the cognitive aspect of color, check this out: http://www.lottolab.org/illusiondemos/Demo%2014.html
this one is also pretty surprising as it does not involve a 3D and shadow effect (move mouse over image):
http://www.richard-ebv.de/images/HDS/test/farbe_macht_abhaengig.html
when you move away from the monitor it's even more surprising.
-
I noticed there is an article on Prophot RGB on this forum with contribution from Bruce Fraser and Jeff Schewe:
http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtm (http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml)l
Joofa
-
I noticed there is an article on Prophot RGB on this forum with contribution from Bruce Fraser and Jeff Schewe:
http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtm (http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml)
They gave feedback and suggestions. "Contribution" usually means that their writings appear in the article. For example, you have contributed to this discussion...
That is why there is only a single notion of white point [1,1,1] in XYZ…
Of course, with a tiny bit of research you would have found that the XYZ “white point” (more like the XYZ white) is 1/3, 1/3, 1/3. Obviously, making a contribution doesn’t attest to the quality of that contribution.
Here’s another contribution...in reference to use of the Bruce Lindbloom calculator...
I think you selected the D50 white point for Adobe RGB, where as the standard says to use D65.
Except that you can’t select a different white point for Adobe RGB...there is no function for that in the Bruce calculator. The box labeled “Ref White” is for selecting the Standard Illuminant for the CIE spaces, as described in Bruce’s help...NOT for selecting a different white point for the chosen RGB space. You were using the calculator incorrectly.
And once again we see that making a contribution isn’t always a good thing.
-
> Of course, with a tiny bit of research you would have found that the XYZ “white point” (more like the XYZ white) is 1/3, 1/3, 1/3. Obviously, making a contribution doesn’t attest to the quality of that contribution.
Aren't you are mixing up xyz and XYZ?
-
> Of course, with a tiny bit of research you would have found that the XYZ “white point” (more like the XYZ white) is 1/3, 1/3, 1/3. Obviously, making a contribution doesn’t attest to the quality of that contribution.
Aren't you are mixing up xyz and XYZ?
I was using "XYZ" as "CIE XYZ", the name of the space, in the manner that joofa did in the post I was responding to. Clearly, improper use of terms, from straight misuse to attempts to match usage, has been a problem in this discussion.
But otherwise, yes of course it's xyz as is stated in any description of the CIE XYZ space.
-
I was using "XYZ" as "CIE XYZ", the name of the space, in the manner that joofa did in the post I was responding to. Clearly, improper use of terms, from straight misuse to attempts to match usage, has been a problem in this discussion.
But otherwise, yes of course it's xyz as is stated in any description of the CIE XYZ space.
So, what is the value for white point in XYZ again?
-
So, what is the value for white point in XYZ again?
Who cares. That's not how it's officially specified.
-
Who cares. That's not how it's officially specified.
;D
-
Now does the record of colour in a raw file follow cone response?
Of course it is meant to do that.
Doubts ?
--
-
Of course it is meant to do that.
Doubts ?
--
No doubts. If what you are seem to suggest be true we would not encounter any problems with different colour transforms for different cameras.
-
;D
Well, if you want to be a stickler for the rules then it's [1,1,1] but it's XYZ, not XYZ.
-
Well, if you want to be a stickler for the rules then it's [1,1,1] but it's XYZ, not XYZ.
From your very first post it was all obvious. You do not know what you are talking about.
-
No doubts. If what you are seem to suggest be true we would not encounter any problems with different colour transforms for different cameras.
No one said it's perfect.
--
-
No one said it's perfect.
--
It is not about being perfect. The responses do not follow LMS intentionally, by design, in order to get better noise characteristics (one of the reasons).
-
It is not about being perfect. The responses do not follow LMS intentionally, by design, in order to get better noise characteristics (one of the reasons).
Ever studied the design of Bayer filters ?
Actually, to create a camera filter set that is "perfect", it is not required to exactly the match the human cone responses (or the XYZ responses). All that is required is the filter responses be some linear combination of the human cone responses. If that is the case, then a simple 3 by 3 matrix can be used in software to recover the exact XYZ values.
--
-
From your very first post it was all obvious. You do not know what you are talking about.
XYZ refers to the color matching functions.
XYZ refers to the tristimulus values.
The button text in the calculator refer to names of the color spaces.
Joofa simply called his [1,1,1] values XYZ, leaving the question open as it being xyz or XYZ.
CIE XYZ white is specified in xyz.
And no matter how you (properly) slice it, Adobe RGB is fully contained within Pro Photo. Anyone who thinks it isn't is the one who doesn't know what he's talking about.
-
Joofa simply called his [1,1,1] values XYZ, leaving the question open as it being xyz or XYZ.
The sum of xyz [1/3,1/3,1/3] should be one (1/3+1/3+1/3=1). So if I wrote [1,1,1] then it should be obvious what the intention was. And, [1/3,1/3,1/3] and [1,1,1] are the same "color", only the magnitude is different.
Joofa
-
According to "Joofa" ProPhoto doesn't encompass all the colours AdobeRGB contains.
Maybe "Joofa" can also explain why I can create gradients in ProPhoto going from pure cyan to white & pure cyan to pure blue & pure blue to white that totally* clip when I convert relcol to AdobeRGB?
If AdobeRGB would exceed ProPhoto in blues/cyans some (saturated) colours should not show clipping. But they do. How so?
___________________
* some light, low saturated blues and cyans do not clip, of course, but all high saturated colours do show clipping
-
> Ever studied the design of Bayer filters ?
Collected spectral data on the response of most of popular cameras.
> Actually, to create a camera filter set that is "perfect", it is not required to exactly the match the human cone responses (or the XYZ responses). All that is required is the filter responses be some linear combination of the human cone responses. If that is the case, then a simple 3 by 3 matrix can be used in software to recover the exact XYZ values.
Yes, more or less. But as I said - it contradicts other design goals; so Luther-Ives condition is not followed too closely, to put it mildly.
-
Also Joofa: Hilbert Space? Seriously? Why stop there? If you really want to set up a smoke screen, you should invoke Zariski–Riemann space.
Mark, you might have noticed that I was stressing a lot on a single color space with multiple coordinate systems. In order to represent seemingly different color spaces that I showed in my plot I had to follow some tricks. In my representation the colorimeteric XYZ data was not plotted.
Hope that helps.
Sincerely,
Joofa
-
You are not qualified to judge as you do not know the basics. In the very same posting where you were putting down Joofa's contribution you made a first grade mistake probably only to prove your own thesis that not all contributions are equally useful. You lost it ;D
-
According to "Joofa" ProPhoto doesn't encompass all the colours AdobeRGB contains.
Maybe "Joofa" can also explain why I can create gradients in ProPhoto going from pure cyan to white & pure cyan to pure blue & pure blue to white that totally* clip when I convert relcol to AdobeRGB?
If AdobeRGB would exceed ProPhoto in blues/cyans some (saturated) colours should not show clipping. But they do. How so?
___________________
* some light, low saturated blues and cyans do not clip, of course, but all high saturated colours do show clipping
When did I say cyans? I primarily concentrated in an area around saturated blues in Adobe RGB (D65). And, it turned out that a strip from that area to white was also problematic. As far as cyans are concerned, if you can ball park them in my plot you might see what is happening:
Sincerely,
Joofa
-
Yes, more or less. But as I said - it contradicts other design goals; so Luther-Ives condition is not followed too closely, to put it mildly.
Mildly interesting.
So why did you ask at all in post # 373 (?).
Note that this is not dpreview, it is not about having to have right
(without intending to express any disrespect for those who contribute at dpreview).
--
-
You are not qualified to judge as you do not know the basics. In the very same posting where you were putting down Joofa's contribution you made a first grade mistake probably only to prove your own thesis that not all contributions are equally useful. You lost it ;D
I made no mistake...only from your point of view. You're just upset because you made the same mistake that Joofa did with the Bruce Lindbloom calculator...thinking that the "Ref White" changes the white point of the selected RGB space, when it fact it does not such thing. Your position is based on incorrect conversions.
-
> I made no mistake
;D
-
> So why did you ask at all in post # 373 (?).
Because I wanted to know the basis of your statement.
-
it turned out that a strip from that area to white was also problematic.
As far as cyans are concerned, if you can ball park them in my plot below you might see what is happening:
I can't … as I simply don't understand your graph. So I don't know what to look at.
I am just a simple "user" of colour managed applications...
When did I say cyans?
You didn't talk about cyans… but I have looked at the cyans.
When you compare the gamuts AdobeRGB (white) and ProPhoto (wireframe) abscol in relation to D50…: (http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg)
… you will see that blue->white / cyan->white / magenta->white is potentially problematic.
You can see it even better when you spin the graph:
(http://www5.pic-upload.de/07.01.11/ghj9m2umlcw7.jpg)
So… I've just looked at all the "blues" (incl. cyan).
Now, you didn't adress my question.
If there are saturated blues in AdobeRGB that are not contained in ProPhoto … why do all the blues and cyans of ProPhoto clip when I "softproof" relcol to AdobeRGB and enable gamut warning?
(http://www5.pic-upload.de/07.01.11/u4lhlp1cpnun.jpg)
(http://www5.pic-upload.de/07.01.11/5fbqcgxw16xq.jpg)
-
I can't … as I simply don't understand your graph. So I don't know what to look at.
It shows you the same gamut in a linear space that are you used to seeing in a nonlinear space such as Lab.
I am just a simple "user" of colour managed applications...
You didn't talk about cyans… but I have looked at the cyans.
When you compare the gamuts AdobeRGB (white) and ProPhoto (wireframe) abscol in relation to D50…:
… you will see that blue->white / cyan->white / magenta->white is potentially problematic.
You can see it even better when you spin the graph:
So… I've just looked at all the "blues" (incl. cyan).
Now, you didn't adress my question.
If there are saturated blues in AdobeRGB that are not contained in ProPhoto … why do all the blues and cyans of ProPhoto clip when I "softproof" relcol to AdobeRGB and enable gamut warning?
First of all, I did not make those programs you used so I don't know what they are doing internally.
Secondly, I thought it would appear from my graph, and then, I did a quick calculation and it would appear that a saturated cyan Prophoto RGB (D50) is outside the gamut ;D of Adobe RGB (D65). I don't see what is the big surprise here? I have to check my calculation though.
Joofa
-
I don't see what is the big surprise here?
no surprise... for me. It's in agreement with what most people say: all AdobeRGB colours are encompassed by ProPhoto.
-
no surprise... for me. It's in agreement with what most people say: all AdobeRGB colours are encompassed by ProPhoto.
No.
-
no surprise... for me. It's in agreement with what most people say: all AdobeRGB colours are encompassed by ProPhoto.
They are when you plot them correctly as you’ve done. As all such graphers do. Begging the question again (for the last time), why joofa appears to refuse to look at these 3D gamut plots using either the tool in the CS utility or using Bruce’s plots on his very web site.
-
No.
so why then can I create high saturated ProPhoto blues that clip in AdobeRGB?
-
No.
What's "a color"? Seriously.
Seems like we several definitions going ...
-
What's "a color"? Seriously.
Seems like we several definitions going ...
Why is it so difficult to realize that both Adobe RGB (D65) and Prophoto RGB (D50) have colors that are outside each other's gamut? This was the premise of the whole exercise since a 2D representation of gamut as chromacity diagrams does not show that. Didn't I start from there?
Doesn't my plot show that clearly?
Joofa
-
so why then can I create high saturated ProPhoto blues that clip in AdobeRGB?
Highly saturated blues of Adobe RGB (D65) and Prophoto RGB (D50) are not within each other's gamut. Simple as that.
Joofa
-
Highly saturated blues of Adobe RGB (D65) and Prophoto RGB (D50) are not within each other's gamut. Simple as that.
so when the highest saturated blues of AdobeRGB are "outside" of ProPhoto... why do all ProPhoto blues clip in (i.e. are "outside" of) AdobeRGB?
-
What's "a color"? Seriously.
Seems like we several definitions going ...
As in Through the Looking Glass (Lewis Carroll):
> The name of the song is called "HADDOCKS' EYES."'
> 'Oh, that's the name of the song, is it?' Alice said, trying to
> feel interested.
> 'No, you don't understand,' the Knight said, looking a little vexed.
> 'That's what the name is called. The name really is "THE AGED AGED
> MAN."'
> 'Then I ought to have said "That's what the song is called"?' Alice
> corrected herself.
> 'No, you oughtn't: that's quite another thing!
> The song is called "WAYS AND MEANS": but that's only what it's
> called, you know!'
> 'Well, what is the song, then?' said Alice, who was by this time
> completely bewildered.
> 'I was coming to that,' the Knight said.
> 'The song really is "A-SITTING ON A GATE": and the tune's my own
> invention.'
Or,
"when I use a word, it means precisely what I want it to mean, nothing more nothing less." (Humpty-Dumpty)
???
-
so when the highest saturated blues of AdobeRGB are "outside" of ProPhoto... why do all ProPhoto blues clip in (i.e. are "outside" of) AdobeRGB?
Study my diagram very carefully that I am presenting for the nth time below. Do you see that angle between Adobe RGB (D65) and Prophoto RGB (D50)? These two gamuts are not aligned!
(http://djjoofa.com/data/images/adobe_prophoto_rgb.gif)
Sincerely,
Joofa
-
Study my diagram very carefully that I am presenting for the nth time below. Do you see that angle between Adobe RGB (D65) and Prophoto RGB (D50)? These two gamuts are not aligned!
my reply:
I did not make those programs you used so I don't know what they are doing internally
-
my reply:
I did not make those programs you used so I don't know what they are doing internally
Thomas, I mentioned that before also, and I do it again. I have not used a single commercial program for making my plots. All the data is available online on the Internet such as Wikipedia. I, myself, started from there. Anybody can produce the plots that I have done using basic plotting tools.
I will be honored if that is the case that my simple plots are showing something that you didn't see in pricey commercial programs!
Joofa
-
Thomas, I mentioned that before also, and I do it again. I have not used a single commercial program for making my plots. All the data is available online on the Internet such as Wikipedia. I, myself started from there. Anybody can produce the plots that I have done using basic plotting tools.
still begs the question why ALL ProPhoto blues clip in AdobeRGB (converting relcol as well as abscol).
-
still begs the question why ALL ProPhoto blues clip in AdobeRGB (converting relcol as well as abscol).
Angle, between the gamuts. Please see my diagram again. Well, to be honest, angle alone is not enough. There is another reason also but that is beyond the scope of this discussion. Don't worry about that in the particular case of Adobe RGB (D65) and Prophoto (D50) saturated colors.
Joofa
-
Angle, between the gamuts. Please see my diagram again.
Again: I don't understand it. It's the first time that I've seen color spaces plotted this way.
You could as well tell me it's the outline of a new fish cracker that will be sold outside of Chicago but inside of New York.
Does it show the same as these two?
http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg
http://www5.pic-upload.de/07.01.11/ghj9m2umlcw7.jpg
-
Again: I don't understand it. It's the first time that I've seen a color spaces plotted this way.
You could as well tell me it's the outline of a new fish cracker that is outside of Chicago but inside of New York.
Trust me it is the real representation of gamuts. With a great advantage of being in linear space. I can't overemphasize that fact.
There is no need to go into nonlinear Lab gamuts, such as those in the commercial programs presented here. In fact, though I could be wrong, and I have to verify my findings, but there is an issue of gamut being twisted in those programs but I was afraid to point that out. Because if I did, Digital Dog will be all over me, saying "how come you are right and these established tools have the possibility of being incorrect?"
Joofa
-
Does it show the same as these two?
http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg
http://www5.pic-upload.de/07.01.11/ghj9m2umlcw7.jpg
See, my plots are in linear space and not in nonlinear space, such as the Lab plots you are showing. But you can see the equivalent information with full 3D rotation as I do on my computer. Linearity is very helpful!
Joofa
-
OK Joofa, lets figure it out. I'll start by paraphrasing what I think you are getting at. Although you keep saying people don't understand your graph, I think most people with any colorimetric education do. So I explain what I think you saying and you can correct me if I'm wrong. OK?
So we take the unit RGB values from each space:
R= [1, 0, 0]
G = [0, 1, 0]
B = [0, 0, 1]
And we convert them to XYZ values via an absolute colorimetric rendering for each color space in question. This essentially creates three axis representing three coordinate systems: the XYZ space is indicated by the main axis of the cube in your projection. The three coordinate systems are related via an affine transformation, so the relationship is linear.
Now the way 3D coordinates are normally plotted on a 2D diagram only gives you one perspective. If you look straight down the Z axis you will see the plot like the first attachment. The blue dots are the AdobeRGB primaries; the red dots are the ProPhoto primaries. I've circled the blue primary. Looking at this graph, it appears that the AdobeRGB primaries are completely contained within the Prophoto RGB primaries.
But here's the twist: since this is a three dimensional plot projected into two dimensions, we don't get the whole picture. The second attachment shows what it looks like if we rotate the space and look straight down the X axis instead. (Pay attention to the labeled axis). Now you can see that the blue primary (circled) actually falls outside of the triangle formed by the ProPhoto apices. In three dimensional space that blue primary actually falls outside the solid formed by the ProPhoto primaries. Which is to say it is out of gamut.
Since a chromaticity diagram only shows two dimensions of a three dimensional space, we often don't get the whole picture. This is especially important when comparing gamuts because you are only seeing one slice of a three dimensional volume.
Does this accurately represent what you are getting at Joofa?
-
Does this accurately represent what you are getting at Joofa?
I didn't draw them the way you described. That approach has problems.
Joofa
-
Trust me it is the real representation of gamuts. With a great advantage of being in linear space. I can't overemphasize that fact.
There is no need to go into nonlinear Lab gamuts, such as those in the commercial programs presented here. In fact, though I could be wrong, and I have to verify my findings, but there is an issue of gamut being twisted in those programs but I was afraid to point that out. Because if I did, Digital Dog will be all over me, saying "how come you are right and these established tools have the possibility of being incorrect?"
I am totally open to new findings. If you are right: fine so. Then we've learnt a lot!
My problem is I have no clue (well, little) about the physics and maths behind all that stuff. But as a (not totally unexperienced) "user" I can't replicate your findings and it is also not in line with my understanding of color mapping / color appearance.
So, down to earth...:
I can create high saturated AdobeRGB blues (source) that clip in ProPhoto (target) when I convert abscol from AdobeRGB to ProPhoto (because, well, D65 light is "bluer" than D50 light).
But the inverse "test" doesn't work: all the blues (from the highest saturated blue to almost white) in ProPhoto (source) clip when I convert to AdobeRGB (target)... relcol or abscol, either way. How so... when your findings are right?
-
I didn't draw them the way you described. That approach has problems.
That's not very helpful. I'm really making an effort here to help you get your point across, because you are not very good at communicating it.
These are orthographic projections at 90 degrees from each other. I can rotate it differently and project using perspective, but the data stays the same.
And the point stays the same. So my question is: is this what you are trying to say? Is this the argument you are making for the difference in gamuts?
-
I can create high saturated AdobeRGB blues (source) that clip in ProPhoto (target) when I convert abscol from AdobeRGB to ProPhoto.
Isn't that what he's been saying all along?
-
That's not very helpful. I'm really making an effort here to help you get your point across, because you are not very good at communicating it.
These is an orthographic projections at 90 degrees from each other. I can rotate it differently and project using perspective, but the data stays the same.
And the point stays the same. So my question is: is this what you are trying to say? Is this the argument you are making for the difference in gamuts?
Mark I already said, No. You are not being correct here.
Joofa
-
Mark I already said, No. You are not being correct here.
Joofa
OK. What is the difference between what I have said and what you are saying?
-
OK. What is the difference between what I have said and what you are saying?
Mark, it is quite an involved issue. You want to go into the mechanics. It can take at least one entirely different thread, or several, as there are many issues here. I want to keep this thread on the track with the discussion of gamut differences between Adobe RGB and Prophoto RGB. So far it has surprisingly turned out to be very focused. Which is a marvel in itself. See about 22 pages and still focused.
Lets keep the issues in hand.
Joofa
-
Isn't that what he's been saying all along?
it is what you can see essentially here... comparing the gamuts both under different illuminants:
http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg
that was already discussed somewhere 10 pages above...
But if I remember correctly "Joofa" claims that the high saturated blues of AdobeRGB are also outside of ProPhoto after gamut mapping (from AdobeRGB to ProPhotoRGB... incl. Bradford chr. adaption).
-
But the inverse "test" doesn't work: all the blues (from the highest saturated blue to almost white) in ProPhoto (source) clip when I convert to AdobeRGB (target)... relcol or abscol, either way. How so... when your findings are right?
Both directions are predicted by my findings and I have been saying all along, though I focused more on the (1) below:
(1) Adobe RGB (D65)->Prophoto RGB (D50) clips in abs col.
(2) Prophoto RGB (D50)-> Adobe RGB (D65) clips wheter relcol or abscol as you have observed yourself. <--- I have to verify relcol a little bit more, but abscol will certainly do.
Sincerely,
Joofa
-
But if I remember correctly "Joofa" claims that the high saturated blues of AdobeRGB are also outside of ProPhoto after gamut mapping (from AdobeRGB to ProPhotoRGB... incl. Bradford chr. adaption).
I never claimed that!
Joofa
-
I want to keep this thread on the track with the discussion of gamut differences between Adobe RGB and Prophoto RGB.
That's exactly what I was trying to do. I used your argument (or at least your argument as I understood it) regarding the gamut plots and came to the same conclusion. But all you will say is 'it is quite an involved issue'? Do you not want people to understand you?
Again, I'm making a sincere effort here.
-
But if I remember correctly "Joofa" claims that the high saturated blues of AdobeRGB are also outside of ProPhoto after gamut mapping (from AdobeRGB to ProPhotoRGB... incl. Bradford chr. adaption).
I think his original claims were:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, PropPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, PropPhoto RGB white point=D65, Fraction needed=0.67
I have drawn case (1) in the image shown above. So, except (1) other modes offer a scenario where no clipping needs to happen. I.e., for (2),(3), and (4) the gamut of Adobe RGB seems to be contained within ProPhoto RGB, but for (1) the gamut of Adobe RGB around saturated blues gets clipped in ProPhoto RGB. Incidently, (1) is the standard mode of specification of white points for both Adobe and ProPhoto RGB. So, is standard specification of ProPhoto RGB saturation clipped near Adobe RGB blue primary?
-
(1) Adobe RGB (D65)->Prophoto RGB (D50) clips in abs col.
(2) Prophoto RGB (D50)-> Prophoto RGB AdobeRGB(D65) clips wheter relcol or abscol as you have observed yourself. <--- I have to verify relcol a little bit more, but abscol will certainly do.
so you (we) are still on the level of a D50 white is not a D65 white???
Sobering!
-
Why is it so difficult to realize that both Adobe RGB (D65) and Prophoto RGB (D50) have colors that are outside each other's gamut? This was the premise of the whole exercise since a 2D representation of gamut as chromacity diagrams does not show that. Didn't I start from there?
Doesn't my plot show that clearly?
Joofa
Since this whole debate is about "colors" ... not plots, graphs or numbers ... I was hoping you could define a color for me. Seriously.
-
Joofa wrote:
(1) Adobe RGB (D65)->Prophoto RGB (D50) clips in abs col.
(2) Prophoto RGB (D50)-> Prophoto RGB (D65) clips wheter relcol or abscol as you have observed yourself. <--- I have to verify relcol a little bit more, but abscol will certainly do.
so you (we) are still on the level of a D50 white is not a D65 white???
Sobering!
Hey, I had a typo in my text you quoted. I mentioned Prophoto at a place where I wanted to say Adobe. Please correct. I edited the original message.
Joofa
-
Mark, it is quite an involved issue. You want to go into the mechanics. It can take at least one entirely different thread, or several, as there are many issues here. I want to keep this thread on the track with the discussion of gamut differences between Adobe RGB and Prophoto RGB. So far it has surprisingly turned out to be very focused. Which is a marvel in itself. See about 22 pages and still focused.
Lets keep the issues in hand.
So you're not prepared to explain the mechanics of how you got to your results, but you are prepared to suggest that other commercial programs and other well used utilities might be wrong (even though you say you don't know how they work)?
-
Joofa, do you believe that colors are physical properties?
-
so you (we) are still on the level of a D50 white is not a D65 white???
Sobering!
White is white! And I think "white" is a color .... I just wish I knew what a color IS.
I think I know, but I want Joofa to explain it to me ... then and only then can I pick a "side".
I'm leaning towards the Adobe RGB blue primary IS inside ProPhoto ... but I can't decide until we agree on what a color is.
THAT'S back to basics.
-
So you're not prepared to explain the mechanics of how you got to your results, but you are prepared to suggest that other commercial programs and other well used utilities might be wrong (even though you say you don't know how they work)?
See, I don't need to know how other utilities are implemented. I said before also I was basing that on certain properties of the Lab space, which they use. And, I said I could be wrong. But, I have to verify it. How hard is it to take that I just mentioned a guess? It is not a legal forum. Why do you guys get pissed off on a slight mentioning of something along the lines I am thinking? ??? ??? ???
Joofa
-
See, I don't need to know how other utilities are implemented.
I'm not asking you to do that. I'm simply asking what the difference between my explanation and your is.
-
Joofa, just post your matlab script so people can see what calculations you did.
-
Hey, I had a typo in my text you quoted. I mentioned Prophoto at a place where I wanted to say Adobe. Please correct. I edited the original message.
I did understand it even without your correction.
A "ProPhoto D65" does not exist anyway...
-
White is white!
interresting claim ;D
-
I did understand it even without your correction.
A "ProPhoto D65" does not exist anyway...
Gosh, all effort in vain. Conceptually, there is NO difference between Prophoto RGB (D50) and Prophoto RGB (D65), both can be conceived with the same exact thought!
Joofa
-
Joofa, just post your matlab script so people can see what calculations you did.
Yes, I am thinking along the lines. But after some verification and rechecking of numbers. BTW, it is not Matlab. ;D
Joofa
-
Conceptually, there is NO difference between Prophoto RGB (D50) and Prophoto RGB (D65), both can be conceived with the same exact thought!
so a profile based on ProPhoto primaries but with D65 defined as white point... or a ProPhoto that has been mapped to D65?
-
Hi Joofa,
Ok I will bite, what’s the girls name…
-
Yes, I am thinking along the lines. But after some verification and rechecking of numbers. BTW, it is not Matlab. ;D
Ahh, it looked like it from the images.
-
So that's it Joofa?
You post a graph, which you claim demonstrates that commercial software and color authorities are wrong about a very fundamental idea that is generally held as common knowledge. You continually tell people just to look at the graph.
You say :
Anybody can produce the plots that I have done using basic plotting tools
When somebody does you answer:
it is quite an involved issue. You want to go into the mechanics. It can take at least one entirely different thread, or several, as there are many issues here.
It's very hard to take anything you are posting seriously if you won't make a serious effort to say anything other than 'my graph proves it; look ay my graph.' A lot of people in this thread have taken a lot of their time to make cogent, easy-to-read arguments. Because many of the arguments are direct and clear, it should be easy to make an equally direct clear point about why they are wrong. But you are either unable or unwilling to do that. When presented with a clear argument, you either post your graph again, or you say 'nope', or you redirect with talk of hilbert space and the like.
I would have to go back through all the posts to verify this, but I think I'm the only one so far that has been willing to do the matrix algebra with you and try to form a clear explanation of your methods, but you don't seem to want that. Which makes me think you don't actually want people to understand what is behind your claim.
-
So that's it Joofa?
You post a graph, which you claim demonstrates that commercial software and color authorities are wrong about a very fundamental idea that is generally held as common knowledge. You continually tell people just to look at the graph.
Mark, please don't put words in my mouth. I never said they are "wrong". At one place, in a guess work, I referred to gamut being "twisted". But trust me even if the gamut in those utilities is twisted, it does not make them wrong. It won't start showing in-gamut colors out-of-gamut and vice versa. No. It is referring to a very different fact. I just happened to mention it. It has no connection to figuring out which are in/out of gamut colors between Adobe RGB and Prophoto RGB.
See, that is one thing I don't like. I have tried to be very careful with language. But people have been putting words in my mouth all along. I repeat I am not claiming any xyz commercial utility is wrong.
Next, I said that I shall work on cleaning code, verifying things again, writing it in a document, and put it somewhere online when that is done. Please be patient.
Sincerely,
Joofa
-
If anybody thinks that I am not leading them in the right direction then come on guys, after writing those long messages, going over several times how to interpret white points, how to construct different spaces in the same volume, and presenting graphs, and providing detailed explanations with clear matrix algebra, then it is being very unfair.
Joofa
-
I don't know about the rest of this thread, but this argument here is ... unexpected. And probably correct and interesting.
I could probably understand the maths :) but cannot be bothered - I'll believe you anyway.
Edmund
OK Joofa, lets figure it out. I'll start by paraphrasing what I think you are getting at. Although you keep saying people don't understand your graph, I think most people with any colorimetric education do. So I explain what I think you saying and you can correct me if I'm wrong. OK?
So we take the unit RGB values from each space:
R= [1, 0, 0]
G = [0, 1, 0]
B = [0, 0, 1]
And we convert them to XYZ values via an absolute colorimetric rendering for each color space in question. This essentially creates three axis representing three coordinate systems: the XYZ space is indicated by the main axis of the cube in your projection. The three coordinate systems are related via an affine transformation, so the relationship is linear.
Now the way 3D coordinates are normally plotted on a 2D diagram only gives you one perspective. If you look straight down the Z axis you will see the plot like the first attachment. The blue dots are the AdobeRGB primaries; the red dots are the ProPhoto primaries. I've circled the blue primary. Looking at this graph, it appears that the AdobeRGB primaries are completely contained within the Prophoto RGB primaries.
But here's the twist: since this is a three dimensional plot projected into two dimensions, we don't get the whole picture. The second attachment shows what it looks like if we rotate the space and look straight down the X axis instead. (Pay attention to the labeled axis). Now you can see that the blue primary (circled) actually falls outside of the triangle formed by the ProPhoto apices. In three dimensional space that blue primary actually falls outside the solid formed by the ProPhoto primaries. Which is to say it is out of gamut.
Since a chromaticity diagram only shows two dimensions of a three dimensional space, we often don't get the whole picture. This is especially important when comparing gamuts because you are only seeing one slice of a three dimensional volume.
Does this accurately represent what you are getting at Joofa?
-
It's very hard to take anything you are posting seriously if you won't make a serious effort to say anything other than 'my graph proves it; look ay my graph.' A lot of people in this thread have taken a lot of their time to make cogent, easy-to-read arguments. Because many of the arguments are direct and clear, it should be easy to make an equally direct clear point about why they are wrong. But you are either unable or unwilling to do that. When presented with a clear argument, you either post your graph again, or you say 'nope', or you redirect with talk of hilbert space and the like.
Mark, are you forgetting that Iliah Borg, Peter (DPL), Jc1, and perhaps a few others have independently verified what I said. Come on. I could have stated my findings without showing any graph and it would have been the same result stating the relationship of in/out of gamut colors between the said spaces.
Joofa
-
Mark, please don't put words in my mouth. I never said they are "wrong"
This is the fact that is under consideration as I understand it:
There are no colors in the Adobe1998 RGB space that cannot be reproduced in the ProPhotoRGB space. In other words the gamut of the ProPhoto RGB working space completely contains the Adobe1998 RGB space
This is a commonly-held belief. You claim the opposite.
The clearest expression of your goal that I have been able to find is this:
Have you not understood that the basic premise of my argument is to find color(s) that are represented in standardized Adobe RGB (D65) but not in standardized Prophoto (D50).
I read that to mean that you believe the fact under consideration (what I wrote in bold above) is wrong. I don't think the two statement are compatible. If that isn't what you are sayin—if you don't dispute the fact under consideration, if you don't think it's wrong, please tell us now and we can chalk it up to a big misunderstanding.
You continually assert that your graph demonstrates this, but you won't explain how the graph came to be. The graph has numbers along the outside but the axis aren't labeled. I've been assuming it's XYZ axis, but maybe that's a mistake on my part.
Maybe you can just give us the coordinates of the six points in your graph. (Using the XYZ axis if that is in fact what the outside box is).
-
Joofa, I think this would help people understand your graph:
Plot it as you have, but additional show where the point [.5, .5, .5] fall in each space.
-
Joofa...
attached are 2 sRGB profiles; the suffix is renamed to TXT (as ICC won't upload).
When you rename the suffix to ICC you can use them as icc profiles.
Now, when you compare them the same way you have compared AdobeRGB to ProPhotoRGB... are their gamuts fully contained in each other?
-
Mark, I don't know why you are cooking up stuff that I did not say. Please reread my messages. I have always maintained that I believe those utilities show the gamut of Adobe RGB (D50) within Prophoto (D50), which is my case (3) below. The point of contention has always been the gamut of Adobe RGB (D65) and Prophoto (D50), which is case (1).
Going back to my very first note:
Joofa wrote on DPReviw:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, PropPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, PropPhoto RGB white point=D65, Fraction needed=0.67
Sincerely,
Joofa
EDIT: Highlighted the wrong case. Corrected.
-
Mark, I don't know why you are cooking up stuff that I did not say.
Go ahead and quote from my post: what did I say that misrepresents you. I am really not trying to do that.
-
Go ahead and quote from my post: what did I say that misrepresents you. I am really not trying to do that.
Please reread my message #460. So surprised. It can't get any clearer than that!
Joofa wrote on DPReviw:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, PropPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, PropPhoto RGB white point=D65, Fraction needed=0.67
Joofa
-
...but I think I'm the only one so far that has been willing to do the matrix algebra with you and try to form a clear explanation of your methods, but you don't seem to want that.
I don’t even think that’s necessary. He agreed with the B.L. Calculator calculations that Iliah provide in post #88...
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412428#msg412428
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412431#msg412431
To me it seems like the algebra, for the most part, is set. The question is the validity of the algebra.
In the subsequent 2 pages of responses, of which you were a part of, you, digitaldog, and maybe a couple others tried to correct the mistake Iliah had made. Joofa will not consider any other process of converting the color.
This entire argument boils down to adaptation. If you use adaptation, the blue is within Pro Photo, and if you don’t then it isn’t (or if you simply mess it up because you don’t realize what you’re doing on the calculator.)
Joofa doesn’t seem to care that the blue he started with appears different when trying to find its place in Pro Photo. And that’s the core issue. He only cares about numbers, and we care about the way the blue appears to a human. It seems pointless to continue.
-
This entire argument boils down to adaptation. If you use adaptation, the blue is within Pro Photo, and if you don’t then it isn’t (or if you simply mess it up because you don’t realize what you’re doing on the calculator.)
Yay! We have a winner.
Again, not to put words in joofa's mouth, but I don't think he ever said, "I don't care about adaptation." I think he was pointing out the case where you don't use it, as in his #1 of 4 cases. Later, others put forth the idea that using adaptation is not always the 'right' way to do things, though the examples have been vague.
At least that's how I've understood this discussion.
-
This entire argument boils down to adaptation. If you use adaptation, the blue is within Pro Photo, and if you don’t then it isn’t (or if you simply mess it up because you don’t realize what you’re doing on the calculator.)
Yes, you are 100% correct. I could demonstrate that on Joofa's own graph, but it's pointless because he does not want to commit to the method he is using. If I took the time to make a graph demonstrating this, he would simply say it isn't correct without further explanation. In other words it's a waste of time.
-
Yay! We have a winner.
Again, not to put words in joofa's mouth, but I don't think he ever said, "I don't care about adaptation." I think he was pointing out the case where you don't use it, as in his #1 of 4 cases. Later, others put forth the idea that using adaptation is not always the 'right' way to do things, though the examples have been vague.
At least that's how I've understood this discussion.
TGray, you are a sane voice here. Please help me with others. BTW, I did note that tho_mas apparently found that when going from Prophoto RGB (D50)->Adobe RGB (D65), both abscol and relcol with adaption will be out of gamut. Right tho_mas? So apparently relcol is not always working.
Joofa
-
Yes, you are 100% correct. I could demonstrate that on Joofa's own graph, but it's pointless because he does not want to commit to the method he is using. If I took the time to make a graph demonstrating this, he would simply say it isn't correct without further explanation. In other words it's a waste of time.
I don't know why you are after my methods. I repeat again, Iliah Borg, Peter (DPL), and JC1 have also independently confirmed what I said regarding case (1). If they can do it why can't you?
Joofa
-
BTW, I did note that tho_mas apparently found that when going from Prophoto RGB (D50)->Adobe RGB (D65), both abscol and relcol with adaption will be out of gamut. Right tho_mas? So apparently relcol is not always working.
what?
What I have shown to you is that ALL saturated blues of ProPhoto clip in AdobeRGB when converting either relcol or abscol. Which shows that AdobeRGB does NOT contain a single blue value that is outside of ProPhoto (otherwise the respective value would NOT show clipping).
"relcol is not always working" ... is a strange way to discribe this. In relcol colors of the source color space that are out of gamut of the target color space are clipped to the outer edges of the target gamut.
Now... convert ProPhoto RGB 0/0/255 relcol to AdobeRGB and plot that values in your strange software. You will find that it is exactly the highest saturated blue of AdobeRGB (D65!). How that when AdobeRGB contains higher saturated blues than ProPhoto (supposedly)? How can ProPhoto produce a blue that matches the highest saturated blue in AdobeRGB?
-
Gosh, all effort in vain. Conceptually, there is NO difference between Prophoto RGB (D50) and Prophoto RGB (D65), both can be conceived with the same exact thought!
Joofa
Is prophoto RGB (D50) contained within prophoto (D65)?
PS What is a color?
-
How that when AdobeRGB contains higher saturated blues than ProPhoto (supposedly)? How can ProPhoto produce a blue that matches the highest saturated blue in AdobeRGB?
tho_mas, I think I already gave you an answer a number of times. How hard it is to imagine that both Adobe RGB (D65) and Prophoto RGB (D50) contains colors that are outside each others gamuts. In fact, what you have found out is that going Prophoto RGB (D50)->Adobe RGB (D65) is even more messed up as it clips in both ways: abscol or relcol. So this is a stronger case than Adobe RGB (D65)->Prophoto RGB (D50).
If you ask me again why, then please read my recent messages to you again.
Guys, it is getting very repititious. If TGray can understand things perfectly, what is happening to you?
Sincerely,
Joofa
-
tho_mas, I think I already gave you an answer a number of times. How hard it is to imagine that both Adobe RGB (D65) and Prophoto RGB (D50) contains colors that are outside each others gamuts. In fact, what you have found out is that going Prophoto RGB (D50)->Adobe RGB (D65) is even more messed up as it clips in both ways: abscol or relcol. So this is a stronger case than Adobe RGB (D65)->Prophoto RGB (D50).
If you ask me again why, then please read my recent messages to you again.
Guys, it is getting very repititious. If TGray can understand things perfectly, what is happening to you guys?
Sincerely,
Joofa
Numbers without meaning ... are ... numbers.
Can you define a color? 'cause if you can't, you have said nothing more than "2 is greater than 1".
-
I think he was pointing out the case where you don't use it, as in his #1 of 4 cases.
Right. And what he's failing to realize is that those cases have no meaning whatsoever.
I already gave an analogy with temperature conversion. There's 1.8 F to every 1 C. So to convert C to F you multiply by 1.8. But you also have to consider the freezing point of water. So you have to add 32 to the result to get the actual F temperature that is physically the same as the C temperature.
In Joofa’s #1 and #4 cases, it’s like he’s forgetting about the 32, and then proclaiming that the two temperatures are the same. That’s wrong. The temperatures aren’t the same, and neither are the blues in his calculations.
-
Guys, it is getting very repititious. If TGray can understand things perfectly, what is happening to you guys?
I have no trouble to understand that D50 is not D65.
ProPhoto's white is not contained in AdobeRGB's white and vice versa.
Likewise sRGB is also not fully contained in ProPhoto (have you plotted the 2 sRGB profiles I've posted above?)
A sheet of white paper looks different under tungsten and under daylight...
... unless your eyes adopt to the different lighting conditions.
After adaption to the different lighting conditions the white paper will look "the same".
-
Yay! We have a winner.
Again, not to put words in joofa's mouth, but I don't think he ever said, "I don't care about adaptation." I think he was pointing out the case where you don't use it, as in his #1 of 4 cases. Later, others put forth the idea that using adaptation is not always the 'right' way to do things, though the examples have been vague.
At least that's how I've understood this discussion.
You can say that - or you can say that we have no RGB space currently in common use that covers the whole gamut of visual response and does not include imaginary colours. While we need something here - for those HDR displays that are coming.
-
Is 2 really greater than 1?
Border guards are useful but need close attention when put into operations. Do not allow them to act on their own.
-
I think he was pointing out the case where you don't use it, as in his #1 of 4 cases.
So when using these ICC profiles in any current application, when and how (and why) would a conversion take place without adaptation?
-
You can say that - or you can say that we have no RGB space currently in common use that covers the whole gamut of visual response and does not include imaginary colours.
And you never will. It is a fundamental limitation of trichromatic reproduction. You cannot match all visible colors with only three real primaries.
-
Border guards are useful but need close attention when put into operations. Do not allow them to act on their own.
You don't seem interested in actually contributing. You seem to be intentionally vague and cryptic without offering clear and reasoned arguments.
How dissapointing ... I had thought you were more interested in teaching and spreading the good word.
Perhaps you've spent too much time arguing with the trolls at DPR ... Dunno.
-
And you never will. It is a fundamental limitation of trichromatic reproduction. You cannot match all visible colors with only three real primaries.
this is only a fundemental limitation of matrix profiles
-
this is only a fundemental limitation of matrix profiles
It's more fundamental than that. You may be able to make a profile that can do crazy things and specify off the wall coordinates in LUTs, but you won't be able to actually reproduce the colors with only three primaries.
-
You don't seem interested in actually contributing. You seem to be intentionally vague and cryptic without offering clear and reasoned arguments.
How dissapointing ... I had thought you were more interested in teaching and spreading the good word.
Perhaps you've spent too much time arguing with the trolls at DPR ... Dunno.
My response was to Joofa.
I'm not interested in teaching at all and never was. What interests me is to help; mostly - to help people and ideas under attack from those who are only fit to play the leading role George Ruggle's piece.
-
And you never will. It is a fundamental limitation of trichromatic reproduction. You cannot match all visible colors with only three real primaries.
Do you know why is it so?
-
Do you know why is it so?
Yes. It's because the response curves of the cones overlap. You can't individually stimulate retinal cones separately. You always get unwanted stimulations which will lower the saturation of some colors you are trying to reproduce.
Hold on, let me find it…
-
My response was to Joofa.
I'm not interested in teaching at all and never was. What interests me is to help; mostly - to help people and ideas under attack from those who are only fit to play the leading role George Ruggle's piece.
Thank you very much for all the help. I really appreciate that.
Best regards,
Joofa
-
My response was to Joofa.
I'm not interested in teaching at all and never was. What interests me is to help; mostly - to help people and ideas under attack from those who are only fit to play the leading role George Ruggle's piece.
Congratulations ... You helped prove "2" is greater than "1".
Never mind that we were discussing "weight" and comparing scales on the earth and the moon.
Nice work, Batman.
-
From The Reproduction of Colour by R.W.G. Hunt (an excellent text btw)
It is thus clear that the inability of any beams of red, green, and blue light to stimulate the retinal cones separately introduces a basic complication into the whole of trichromatic colour reproduction. If the ρ and β curves did not overlap in the blue-green part of the spectrum, then green light could be found that stimulated the γ-cones on their own; but, since the ρ and β curves do overlap appreciably, the γ-cones cannot be stimulated on their own. For colour vision, this overlapping provides the basis for good detection of changes in hue throughout the spectrum. But, for colour reproduction, it means that simple trichromatic methods cannot achieve correct colour reproduction of all colours. The difficulty cannot be avoided, because it stems from the basic nature of human colour vision; the result is unwanted stimulations in reproduction systems.
-
You helped prove "2" is greater than "1".
It is a simple (and well-known) joke to disprove, of course if one was listening in his first class on arithmetic.
The point that you are missing is that conversion with regards to white point and thus performing adaptation is not necessarily the only useful way, and it gets progressively less useful while target gamuts are getting larger. For certain media, certain image presentation sizes, and certain viewing conditions adaptation is not necessary at all - worse, it is counterproductive.
It is not wise going in circles. The case was presented. Bruce wrote what he wrote, supporting the case given certain limitations, like some whites which are not run through adaptation are not whites anymore. From our photography we know it is often so. Having lights with different CCTs in the scene is nothing new. Defending ProPhotoRGB as the widest and wisest and the only is something that motivates nay-sayers. Well, they are betting against technical progress and their argument is doomed.
-
> Hold on, let me find it…
Trust me I know what you mean - but it does not change a thing.
-
> Hold on, let me find it…
Trust me I know what you mean - but it does not change a thing.
I don't know what you mean. Change a thing about what?
-
The Reproduction of Colour by R.W.G. Hunt
Come on Mark, stick to salient points here. This Hunt guy was nothing until he stumbled on that Ketchup recipe and really made his claim to fame. ::) Now the Huntz book on color, that’s good reading.
-
It's more fundamental than that. You may be able to make a profile that can do crazy things and specify off the wall coordinates in LUTs, but you won't be able to actually reproduce the colors with only three primaries.
re cameras: you can create color spaces in D50 that do contain high saturated blues cameras can capture and that are not contained in ProPhoto.
Re the said HDR monitors: as devices they do produce colors, don't they? It's certainly doable to create table based profiles for these monitors (based on the colors they actually produce). If this is possible... it's certainly also possible to create "averaged" profiles that generally contain the gamut of these monitors (without containing imaginary colors).
A bit like Photogamut once was desinged as a table based working space targeted at printer gamuts: http://photogamut.org/E_idea.html
Something like that... just with a larger gamut.
-
The point that you are missing
Actually, I'm not missing anything.
I'm sure there will be new models to map and describe the world of reflected light on recorded media ... And equally sure you have some insights into what that future looks like.
But you aren't doing much to get that across HERE. That's the point you are missing.
-
re cameras: you can create color spaces in D50 that do contain high saturated blues cameras can capture and that are not contained in ProPhoto.
Re the said HDR monitors: as devices they do produce colors, don't they? It's certainly doable to create table based profiles for these monitors (based on the colors they actually produce). If this is possible... it's certainly also possible to create "averaged" profiles that generally contain the gamut of these monitors (without containing imaginary colors).
A bit like Photogamut once was desinged as a table based working space targeted at printer gamuts: http://photogamut.org/E_idea.html
Something like that... just with a larger gamut.
Working spaces like Photogamut (if I understood what it was in my quick scan) can get away with a wider gamut because their primaries don't have to be real. ProPhotoRGB does this. But the down side is, if you can't reproduce the primaries, you can't reproduce the color; you can only model it.
I'm not sure how HDR monitors work. But if they only use three primaries, they simply can't reproduce all the colors. As the Hunt quote says, "The difficulty cannot be avoided, because it stems from the basic nature of human colour vision"
No doubt we will find technology that moves beyond this. You could easily reproduced ALL colors on a monitor if you could produce spectral primaries on the fly and not depend on tristimulus reproduction. There are even some old technologies like the Lippmann method that don't depend on three color reproduction that do span the whole gamut. (The Lippmann method is really interesting, though impractical. Worth googling when you have some time)
As far as camera go, Andrew is probably a much better person to ask. I'm really not sure if it's proper to think of camera sensors and raw data as RGB. One of these days I plan on learning a bit about the physics behind camera sensors, but I haven't yet.
-
Actually, I'm not missing anything.
I'm sure there will be new models to map and describe the world of reflected light on recorded media
But you are missing. Reflected light is an old part of the game.
-
I don't know what you mean. Change a thing about what?
He means that it does not change a thing that you know what you're talking about.
The question was an attempt to discredit you.
-
So when using these ICC profiles in any current application, when and how (and why) would a conversion take place without adaptation?
I'm not knowledgeable enough in color science to answer that question. I think the how is probably easy, but the why I am unclear on.
Right. And what he's failing to realize is that those cases have no meaning whatsoever
Again, I'm not knowledgeable enough in color science to answer that question. I'm guessing though that, "those cases have no meaning whatsoever" is not true. It's probably safer to say that, "those cases have no meaning in most practical usage scenarios." That doesn't mean that it's not interesting and perhaps even relevant to think about.
And again, for everyone who is saying, "It's just numbers," needs to relax. This whole discussion is based on science that was probably dismissed as 'just numbers' while it was originally researched, yet here we are, putting it to real world use. If you don't find the discussion relevant to your real world uses at the current time, just ignore it.
-
Probably need another post but...
Here’s my copy and paste with respect to cameras based on a number of conversations with Eric Walowit and Jack Holms, both on the ICC digital photo group.
Digital cameras don't have a gamut, but rather a color mixing function. Basically, a color mixing function is a mathematical representation of a measured color as a function of the three standard monochromatic RGB primaries needed to duplicate a monochromatic observed color at its measured wavelength. Cameras don’t have primaries, they have spectral sensitivities, and the difference is important because a camera can capture all sorts of different primaries. Two different primaries may be captured as the same values by a camera, and the same primary may be captured as two different values by a camera (if the spectral power distributions of the primaries are different). A camera has colors it can capture and encode as unique values compared to others, that are imaginary (not visible) to us. They don't exist and therefor are not colors. There are colors we can see, but the camera can't capture that are imaginary to it. Most of the colors the camera can see we can see as well. Yet some cameras can “see colors“ outside the spectral locus but usually every attempt is made to filter those out. More important is the fact that cameras “see colors“ inside the spectral locus differently than humans.
The point is that if you think of camera primaries you can come to many incorrect conclusions because cameras capture spectrally. On the other had, displays create colors using primaries. Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries. Therefore, the measured pixel values don't even produce a gamut until they're mapped into a particular RGB space. Before then, *all* colors are (by definition) possible.
Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry. The same thing could be said about a color film negative.
Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like with film scanning).
Do raw files have a color space? Fundamentally, they do, but we may not know what that color space is. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this is that the image was recorded through a set of "primaries" and these primaries define the color space of the image.
If we had spectral sensitivities for the camera, that would make the job of mapping to XYZ better and easier, but we'd still have decisions on what to do with the colors the camera encodes, that are imaginary to us.
-
I'm not knowledgeable enough in color science to answer that question. I think the how is probably easy, but the why I am unclear on.
The question was less directed towards color science and more towards implementation in current products or tools that use these profiles. Its one thing to enter numeric values in web based color calculator or go about making graphs that purposely ignore the adaptation. But can we do this in the current tools we use to convert color spaces using these profiles? If not, there’s probably a reason why.
-
> I don't know what you mean.
Can you look at monochromatic light sources and come up with wavelengths that allow for separate responses of L, M, and S?
-
Here’s my copy and paste with respect to cameras based on a number of conversations with Eric Walowit and Jack Holms, both on the ICC digital photo group.
Whoa, I wasn't expecting so much. Thanks! I'm walking out the door, but I'll see if I can wrap my head around the when I'm back home.
-
> There are colors we can see, but the camera can't capture
"Can't capture" is not an exect term here. It is akin to saying "There are brightnesses we can see, but the camera can't capture those"
-
> wasn't expecting so much.
You must be joking.
It was very, very basic, and it needs some rephrasing for accuracy.
-
Probably need another post but...
Here’s my copy and paste with respect to cameras based on a number of conversations with Eric Walowit and Jack Holms, both on the ICC digital photo group.
Digital cameras don't have a gamut, but rather a color mixing function. Basically, a color mixing function is a mathematical representation of a measured color as a function of the three standard monochromatic RGB primaries needed to duplicate a monochromatic observed color at its measured wavelength. Cameras don’t have primaries, they have spectral sensitivities, and the difference is important because a camera can capture all sorts of different primaries. Two different primaries may be captured as the same values by a camera, and the same primary may be captured as two different values by a camera (if the spectral power distributions of the primaries are different). A camera has colors it can capture and encode as unique values compared to others, that are imaginary (not visible) to us. They don't exist and therefor are not colors. There are colors we can see, but the camera can't capture that are imaginary to it. Most of the colors the camera can see we can see as well. Yet some cameras can “see colors“ outside the spectral locus but usually every attempt is made to filter those out. More important is the fact that cameras “see colors“ inside the spectral locus differently than humans.
The point is that if you think of camera primaries you can come to many incorrect conclusions because cameras capture spectrally. On the other had, displays create colors using primaries. Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries. Therefore, the measured pixel values don't even produce a gamut until they're mapped into a particular RGB space. Before then, *all* colors are (by definition) possible.
Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry. The same thing could be said about a color film negative.
Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like with film scanning).
Do raw files have a color space? Fundamentally, they do, but we may not know what that color space is. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this is that the image was recorded through a set of "primaries" and these primaries define the color space of the image.
If we had spectral sensitivities for the camera, that would make the job of mapping to XYZ better and easier, but we'd still have decisions on what to do with the colors the camera encodes, that are imaginary to us.
Exactly ….
Joofa, you need to give the name and phone number of the girl to digitaldog he is correct…
-
The question was less directed towards color science and more towards implementation in current products or tools that use these profiles. Its one thing to enter numeric values in web based color calculator or go about making graphs that purposely ignore the adaptation. But can we do this in the current tools we use to convert color spaces using these profiles? If not, there’s probably a reason why.
Who are those current products marketed at? I'm guessing, for 99% of practical purposes, photographers and people in industries who need to deal with color don't care about these 'numbers', thus those products probably don't implement those features (or bury them out of the way). They want to translate from one color space to another, without throwing colors away, keeping them as perceptually as close as possible. Again, that doesn't mean that it's not interesting to talk about other cases and possibly even relevant.
Secondly, with respect to that web calculator - what do you think these applications you speak of are doing? They are just manipulating numbers for you...
If we tossed out all research that the general public didn't find 'useful', we would have only a fraction of the technology and knowledge we have now.
-
Exactly ….
Joofa, you need to give the name and phone number of the girl to digitaldog he is correct…
Hi Manuel,
As Iliah has noted there are several inaccuracies and misunderstandings in Digital Dog's note. A small thread can be done on them. But, in this thread I'm not prepared to go into them. Otherwise, it needs to be corrected.
Sincerely,
Joofa
-
> wasn't expecting so much.
You must be joking.
It was very, very basic, and it needs some rephrasing for accuracy.
By all means, please do so.
-
Who are those current products marketed at? I'm guessing, for 99% of practical purposes, photographers and people in industries who need to deal with color don't care about these 'numbers', thus those products probably don't implement those features (or bury them out of the way).
So products that don’t produce practical purposes are ideal for conversions that don’t implement adaptation and thus, comply with Joofa’s findings? Talk about a solution in search of a problem. Seems this adaptation is useful, expected and designed for a purpose.
I suppose a car manufacture could make the brake pedal accelerate the vehicle and the gas pedal make it slow down, but there’s hardly a reason to do so. I suppose Adobe could alter the math in Phtooshop so it does the opposite of what the UI tells us to expect, but there’s hardly a reason to do so. This entire exercise of Joofa’s has as yet, proven no real world usefulness. The math may be correct, I don’t know and until he provides it to readers here like Mark that do and have asked for it, its a moot point. But when the rubber hits the road, at least as far as I know (and I’ve asked often), what he proposes to illustrate just doesn’t happen expect as a theoretical exercise. What’s the point?
-
It is akin to saying "There are brightnesses we can see, but the camera can't capture those"
Well brightness is a human perception, it is subjective. There are brightnesses we can see, the camera can't capture. Lightness is a property of a color space, which is defined in a way to reflect the subjective brightness perception (of a color) for us humans.
-
So products that don’t produce practical purposes are ideal for conversions that don’t implement adaptation and thus, comply with Joofa’s findings? Talk about a solution in search of a problem. Seems this adaptation is useful, expected and designed for a purpose.
I suppose a car manufacture could make the brake pedal accelerate the vehicle and the gas pedal make it slow down, but there’s hardly a reason to do so. I suppose Adobe could alter the math in Phtooshop so it does the opposite of what the UI tells us to expect, but there’s hardly a reason to do so. This entire exercise of Joofa’s has as yet, proven no real world usefulness. The math may be correct, I don’t know and until he provides it to readers here like Mark that do and have asked for it, its a moot point. But when the rubber hits the road, at least as far as I know (and I’ve asked often), what he proposes to illustrate just doesn’t happen expect as a theoretical exercise. What’s the point?
Look, I don't want to be confrontational, but your whole argument is essentially, "I don't find it useful, thus it's pointless." Let me say this loud and clear: I DON'T KNOW THE IMPLICATIONS OF JOOFA'S STATEMENT. That doesn't mean it's not useful.
I don't think joofa's argument is supposed to be practically applied in 100% of situations. He's stated repeated that it's under a specific set of circumstances. If those circumstances aren't applicable to you, then why worry about it?
And let me call out this specific statement:
Seems this adaptation is useful, expected and designed for a purpose
That does not equal, "Seems this adaptation is useful, expected and designed for ALL purposes." There's a difference there. I'm not in the industry, but I would think that chromatic adaptation/relative colorimetric conversions (are they the same things?) are what you want most of the time. So I'm guessing that's what the software does. To use the analogy of language, most of the time we want to translate for meaning and intent, not verbatim preserving word order. That doesn't meant that a verbatim translation preserving word order and mangling meaning and intent isn't useful...
-
> Well brightness is a human perception
Like in HSB?
-
From The Reproduction of Colour by R.W.G. Hunt (an excellent text btw)
Mark, I don't understand his point at all. What on earth difference does it make that there is overlap in the spectral responses, as long as they are independent functions?
-
Look, I don't want to be confrontational, but your whole argument is essentially, "I don't find it useful, thus it's pointless."
I never said its useless, I asked the why the use and more importantly, what product provides the use! No one so far has answered either question. Kind of telling.
-
> There are colors we can see, but the camera can't capture
"Can't capture" is not an exect term here. It is akin to saying "There are brightnesses we can see, but the camera can't capture those"
From physiology point of view you are wrong. In general one would consider camera sensor as color blind. You are mixing/believing that S, M, L cones means three pure colors. Humans (males) can distinguish four perceptually unique colors (pure means without mix of any other hue): RGBY.
Camera sensor has only three pure colors RGGB.
-
> From physiology point of view you are wrong.
I said "can't capture" is not an accurate term here. Camera captures everything in visible light that is below saturation point and above noise floor.
> Camera sensor has only three pure colors RGGB.
Yes, if yellow is pure green, or two unequal greens (Adobe recently joined the club adopting the strategy to deal with g1 non equal g2) plus something remotely r and remotely b make for 3 pure colours.
-
Right. And what he's failing to realize is that those cases have no meaning whatsoever
Again, I'm not knowledgeable enough in color science to answer that question. I'm guessing though that, "those cases have no meaning whatsoever" is not true.
If you're not knowledgeable enough to answer, then why are you even taking guesses?
It's probably safer to say that, "those cases have no meaning in most practical usage scenarios." That doesn't mean that it's not interesting and perhaps even relevant to think about.
Probably safer for someone who is not knowledgeable enough to answer, but for everyone else, it’s important to not have meaningless jumbles of numbers touted as proof of something that’s not correct.
-
> Well brightness is a human perception
Like in HSB?
No, like HSL!
-
No, like HSL!
Can't find HSL in Photoshop Info palette, sorry.
-
I never said its useless, I asked the why the use and more importantly, what product provides the use! No one so far has answered either question. Kind of telling.
What's it telling about? Just that it's not been applied yet (as far as we know in this discussion).
No offense to joofa, but I'm guessing his statement is nothing new. I would imagine it is well known to the color scientists working behind the scenes. They know when it is applicable and when it isn't.
I once went to talk by one of the physicist/graphics gurus who works at Dreamworks. He gave a presentation on new physics models they were implementing for Shrek 3. I had some questions for him after the talk which were relevant to my research. I'm not in entertainment; I wanted physical accuracy at all costs. I asked my questions and he laughed and said something along the lines of, "Yeah, that's the right way to do it, but we don't do that. We do something that the artists decided looks good enough and is significantly faster to implement, but it's not physically accurate." Just because something is put into practice is not a referendum on it's validity, accuracy, or desirability. It just means that it's been put into practice.
I'm guessing joofa is from an academic/research background. If so, he's probably used to finding interesting questions/facts and following them to their logical conclusions. Sometimes those conclusions are relevant, sometimes not.
-
> From physiology point of view you are wrong.
I said "can't capture" is not an accurate term here. Camera captures everything in visible light that is below saturation point and above noise floor.
> Camera sensor has only three pure colors RGGB.
Yes, if yellow is pure green, or two unequal greens (Adobe recently joined the club adopting the strategy to deal with g1 non equal g2) plus something remotely r and remotely b make for 3 pure colours.
no,
camera Yellow is not pure obviously. Proper setup would be Red sensor, Green sensor Blue sensor and Yellow sensor. Currently Yellow is achieved by color mixing. Not the same thing.
I am talking about experimental models. What you seem to assume is that S, M, L cones can respond to three pure colors. That is wrong assumption.
You have also other problems that definitely are beyond the scope of original topic.
-
Yes, creating illusions is how it works, be it cartoons or fantasy. Chromatic adaptation can be viewed as creating an illusion, but used unproperly it destroys the illusion. Sometimes chromatic adaptation is for the sake of art, but sometimes it is just meaningless pseudo-physical accuracy and numbers.
-
If you're not knowledgeable enough to answer, then why are you even taking guesses?
I'm not sure anyone in this thread is REALLY knowledgeable enough to talk about it :) I'm not trying to claim I'm an expert. Are you? I do think I have the background and training to think about tough problems that I'm not necessarily intimately familiar with though. I try to approach them with an open mind and not try to be too dogmatic about my position. So I say things like, "I'm not familiar enough with to answer that question," or "I'm not an expert." Which means I'm open to discussion. It doesn't mean that I'd attack people with comments like, "Why are you even taking guesses?"
Bruce Lindbloom, the one expert that people seem to agree on is actually an expert, seems to back up what joofa is saying, with the limited set of conditions that agree with what joofa posited at the beginning.
-
> camera Yellow is not pure obviously.
Have you ever looked at some CFAs directly? In that case you might have seen that what is commonly called green component of a Bayer array is yellow in fact. And you somehow ignored "two different greens" problem, or are we back to dividing by zero and coming with 4=3?
-
> I'm not trying to claim I'm an expert. Are you?
Yes, he does claim he is an expert, and even came up with a groundbreaking statement in this thread, saying white point in XYZ is 1,1,1.
-
Haha, Iliah, I'd love to sit down with you one day and have a conversation. You come across as an interesting guy on these forums.
-
Bruce Lindbloom, the one expert that people seem to agree on is actually an expert, seems to back up what joofa is saying, with the limited set of conditions that agree with what joofa posited at the beginning.
Bruce Lindbloom did NOT back up what Joofa was saying. He said...
"If one takes the position that AdobeRGB blue lies outside the gamut of ProPhotoRGB, then one must also agree that the AdobeRGB grayscale (R=G=B) is not neutral."
Then he says...
"I believe that all of the reference RGB color systems share the basic premise that R=G=B is neutral."
And finally...
"If one agrees that R=G=B is neutral for both profiles, regardless of the reference whites, then chromatic adaptation must be used to bring them both to the same reference. In that context, AdobeRGB blue lies inside the gamut of ProPhotoRGB."
It’s crystal clear that this doesn’t support Joofa’s position. What Lindbloom said is correct...if you perform Joofa’s color conversion of a neutral midtone, such as middle gray, then the result is not gray. Joofa is taking one color, damaging it in the conversion, and then making claims about the damaged color. The claims are true, but no one cares about damaged color conversions, as they serve no purpose.
-
Bruce Lindbloom did NOT back up what Joofa was saying. He said...
"If one takes the position that AdobeRGB blue lies outside the gamut of ProPhotoRGB, then one must also agree that the AdobeRGB grayscale (R=G=B) is not neutral."
I think that is the implication of not having the same illuminants, is it not? Maybe joofa can and should answer this.
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50
I think also that this is what Iliah was getting at with his examples of scenes with multiple illuminants.
-
I think that is the implication of not having the same illuminants, is it not? Maybe joofa can and should answer this.
Or...or...how about this option...finish reading the Lindbloom quotes I provided. The answer to your question is right there.
-
That's a useful approach to getting your point across.
-
That's a useful approach to getting your point across.
Yes, I definitely agree that putting all the information required to answer your question into one post is a useful approach to getting my point across.
-
Mark, I don't understand his point at all. What on earth difference does it make that there is overlap in the spectral responses, as long as they are independent functions?
They are not independent functions—that's what he means. In a perfect world you could independently manipulate the individual cone type; you could find three wavelengths, one for each cone type and send light that would only stimulate each one. But it doesn't work because, with the exception of the far end of the red spectrum there are no wavelengths that only effect one cone. So when you use a green primary with the intention of manipulating the middle cone, you also inadvertently get some of the short cone or the long cone. It's not always a problem because you can often still find the right mix for a match, but for saturated colors it is a problem. He provides a real world example in the book with the calculations, which is convincing, but takes a few pages. (You might be able to find the pages in question by searching the book on Amazon of Google Books for the term: "Unwanted Stimulations" (A term I hear from wife from time to time)
-
Yes, creating illusions is how it works, be it cartoons or fantasy. Chromatic adaptation can be viewed as creating an illusion, but used unproperly it destroys the illusion. Sometimes chromatic adaptation is for the sake of art, but sometimes it is just meaningless pseudo-physical accuracy and numbers.
That's an odd statement from someone who was recently preaching the merits of Mark Fairchild just a few posts ago.
Sensory chromatic adaptation is a real physical thing, not a parlor trick of color scientists. It's something we all know from experience and something that is easy to demonstrate experimentally.
From Fairchild's Color Appearance Models:
Perhaps the most important mechanism of chromatic adaptation is independent sensitivity changes in the photoreceptors…
Physiologically, changes in photoreceptor gain can be explained by pigment depletion at higher luminance levels. Light breaks down molecules of visual pigment (part of the process of phototransduction) and thus decreases the number of molecule available to produce further visual response…
Nobody is saying that the models for chromatic adaptation are perfect, or that there isn't also a cognitive aspect of adaptation, but when you are trying to accurately model color, an imperfect chromatic adaptation is better by orders of magnitude than no chromatic adaptation.
-
> odd statement
What is odd in knowing that tools need to be applied adequately?
> Sensory chromatic adaptation is a real physical thing
Sensors are sensors. Sensory is sensory. Do you see blueish tint on a face of a human standing in a shadow? Sensors do, sensory - it depends.
-
Can't find HSL in Photoshop Info palette, sorry.
Ah, so you think that the naming in Photoshop means that the operation is based on the subjective human perception. Its not. See: http://www.crompton.com/wa3dsp/light/lumin.html and http://en.wikipedia.org/wiki/Brightness.
You are confusing Brightness (something we perceive) with Lightness (the L* in Lab) and assuming that the terms used in Photoshop accurately describe the differences (not so). Much like the Photoshop term Luminosity as in the "layer mode" called "luminosity" is not, it is actually calculating something like the "Luma" which is an old TV RGB transform. Luminosity is almost never the word you want unless your are trying
to describe the total radiant energy (watts/sec) of a source, It has nothing to do with what a human observer perceives. Brightness does.
-
> you think that the naming in Photoshop means that the operation is based on the subjective human perception.
No I do not. And you know that I don't. It is just a name - brightness - that is historically used both ways. You know that, and you know that well. ;D
-
What's it telling about?
That he has not specified any practical use, nor any product or condition other than the hypothetical model he proposes that follows the hypothesis. As has been discussed ad nauseam, there is a reason for the adaptation and short of attempting to illustrate that ProPhoto RGB doesn’t fully contain Adobe RGB (1998), adaptation is used.
-
It’s crystal clear that this doesn’t support Joofa’s position.
Obviously we have our ideas of what we believe is correct here or this thread would have ended long ago. That said, what I read from Bruce’s comments fully agree with yours. Its interesting that some read it the other way. Considering what Bruce wrote, considering what the various utilities that plot gamuts, including Bruce’s show, considering that until I’m told otherwise, all applications TODAY that utilize these profiles follow the “logical” conversions Bruce recommends and some here have illustrated, its difficult for me to understand “the other sides” logic and persistence to accept their position.
-
It is just a name - brightness - that is historically used both ways. You know that, and you know that well. ;D
It may be used historically by some, its still an incorrect usage and the URL I posted explain the differences and why they should not be intermixed.
-
You are confusing Brightness (something we perceive) with Lightness (the L* in Lab) a
Yes he is, and it's funny because he was so prepared to drop Mark Fairchild's name for no particular reason ("Fairchild, anybody") before he knew someone had his book on the nightstand. And it's funny because lightness and brightness are not just a names, they are fundamental concepts in color science, a field Iliah wants to assert some authority in. Authority begins with using terminology correctly. Fairchild devotes a chapter in his book to terminology. The CIE published The International Lighting Vocabulary decades ago. There is NO ambiguity here and there hasn't been for a long time.
-
It may be used historically by some, its still an incorrect usage and the URL I posted explain the differences and why they should not be intermixed.
Please re-read what I typed referring to brightness. Scene is characterized by a range of brightnesses among other things. So we record brightnesses. How those brightnesses are coded in the capture is a different story.
By the way there is no point in discussing why Adobe are still preserving HSB, or wheter Adobe are "some", or "incorrect".
-
> Yes he is
Well, you are not paying attention.
-
> camera Yellow is not pure obviously.
Have you ever looked at some CFAs directly? In that case you might have seen that what is commonly called green component of a Bayer array is yellow in fact. And you somehow ignored "two different greens" problem, or are we back to dividing by zero and coming with 4=3?
CFA without green or red will not see yellow, dichromats see yellow as well as trichromats
-
Obviously we have our ideas of what we believe is correct here or this thread would have ended long ago. That said, what I read from Bruce’s comments fully agree with yours. Its interesting that some read it the other way. Considering what Bruce wrote, considering what the various utilities that plot gamuts, including Bruce’s show, considering that until I’m told otherwise, all applications TODAY that utilize these profiles follow the “logical” conversions Bruce recommends and some here have illustrated, its difficult for me to understand “the other sides” logic and persistence to accept their position.
Speaking to you and Graystar, I'm not disagreeing with you that the accepted way is the 'right' way to do things 99.9% of the time. It makes sense; when we move from one color space to another, we want to preserve the appearance as much as possible most of the time. That doesn't mean that joofa doesn't have a point and that considering it might lead to an interesting discussion of when it might be a good idea NOT to use chromatic adaptation during color space conversions. I don't see this as a black and white scenario (pardon the pun).
And that's how I read Bruce's comment. 99% of the time, AdobeRGB is fully contained in ProPhoto RGB. However, if you do a certain thing which has some large consequences (R=G=B is not neutral), it's not. That certain thing is the example that joofa pointed out.
-
CFA without green or red will not see yellow, dichromats see yellow as well as trichromats
Try taking a shot through a colour separation red filter and you will see what I mean.
-
Working spaces like Photogamut (if I understood what it was in my quick scan) can get away with a wider gamut because their primaries don't have to be real. ProPhotoRGB does this. But the down side is, if you can't reproduce the primaries, you can't reproduce the color; you can only model it.
makes sense - thank you!
-
> when we move from one color space to another, we want to preserve the appearance as much as possible most of the time.
Right. But more often than not we do not have the luxury of capturing neutrals across the scene as being true neutrals. Setting neutrals for one region in the scene may through other regions far off. Essentially that means that in our everyday photography we deal with captures that currently need manual adaptation while preserving natural appearance. So the situation presented here by Joofa is real, and I'm sure every nay-sayer realizes it by now. Why do they argue opposite is a different question, and it is in a domain different from photography or colour management.
-
Considering what Bruce wrote, considering what the various utilities that plot gamuts, including Bruce’s show, considering that until I’m told otherwise, all applications TODAY that utilize these profiles follow the “logical” conversions Bruce recommends and some here have illustrated, its difficult for me to understand “the other sides” logic and persistence to accept their position.
well, Chromix Color Think's (non "pro") grapher does display the gamuts abscol in relation to D50 (i.e. D65 is not adapted to D50). That's how I made my gamut-comparisions above.
In that sense nothing about Joofa's findings is new (if I understand him correctly) - ProPhotos white is not contained in AdobeRGB's white.
(Likewise AdobeRGB's entire range from pure blue to white, pure cyan to white and pure magenta to white is also outside of ProPhoto).
Of course comparing two color space with different illuminants this way implies that one of the color spaces doesn't contain any white at all (i.e. when I look at AdobeRGB under D50 conditions the white is yellow).
-
Try taking a shot through a colour separation red filter and you will see what I mean.
it does not matter if this is green or red, people will still see yellow. While there are three types of cones, these respond to four basic colors indpendently.
-
> people will still see yellow.
Too bad you do not read. I'm talking pre-capture filters and captured data here.
-
Speaking to you and Graystar, I'm not disagreeing with you that the accepted way is the 'right' way to do things 99.9% of the time. It makes sense; when we move from one color space to another, we want to preserve the appearance as much as possible most of the time. That doesn't mean that joofa doesn't have a point and that considering it might lead to an interesting discussion of when it might be a good idea NOT to use chromatic adaptation during color space conversions. I don't see this as a black and white scenario (pardon the pun).
And that's how I read Bruce's comment. 99% of the time, AdobeRGB is fully contained in ProPhoto RGB. However, if you do a certain thing which has some large consequences (R=G=B is not neutral), it's not. That certain thing is the example that joofa pointed out.
It's probably worth just putting this image out there for people to judge for themselves—if you are interested in the discussion, but you are not as you say 'in the industry' a visual sample might be informative. I'm just throwing it out in case a concrete example is useful.
The grey square on the right is roughly (given the vagaries of the internet) neutral grey defined with equal RGB values in AdobeRGB 1998. It should look achromatic. The square on the right is a conversion to ProPhotoRGB with no chromatic adaptation. You could achieve both these colors appearances with the same XYZ coordinates by changing the viewing conditions. But the question, the question this whole thread boils down to is: when you look at these patches under the same viewing conditions, like you are right now, are they the same color? In other words, do they look like the same color.
It was really hard to parse Joofa's meaning, but from what I could gather he wanted to build a case that if we call these two patches the same color, if we start from premise that is questionable at best, then the colors in the AdobeRGB space can be outside the ProPhotoRGB space. That's when all the analogies like "If my aunt had balls she's be my uncle came around." (If that's all I get out of this thread, it's worth it.) But they're not the same color unless you are willing to let XYZ coordinates override you eyes and brain and define color rather than model color. To do that is a misplaced concreteness ( http://en.wikipedia.org/wiki/Reification_(fallacy) ).
There are times like when proofing one paper/device on a different paper device that you want to ignore white points and create color casts. It lets you do things like proof a dull paper on a bright one. But if you spend anytime working with digital imaging, you won't buy that argument in this case. The profiles in question represent working spaces. Which means they are abstract environments in which to work. The number Bruce Lindbloom gave: 99.9% is being generous. I can think of NO time when converting between working profiles that you don't want neutral to stay neutral. None. If it happens you assume something is broken.
So when Joofa shows us that, under a condition that should never be the case, a well-known fact is not true, you must be able to understand that he will be met with some pretty stiff resistance. When he is exceptionally cagey in his responses to questions and is unable to give a clear explanation of what he's doing, but insists that he is right and intimates that some well-respected members of this community don't know what they are doing, he becomes a troll.
-
Thanks for taking the time for typing that, but it really wasn't necessary. While I'm not 'in the industry', I do have the necessary math background and have been through a couple books on color, vision, etc. But no, I don't make my living at it :)
-
Thanks for taking the time for typing that, but it really wasn't necessary. While I'm not 'in the industry', I do have the necessary math background and have been through a couple books on color, vision, etc. But no, I don't make my living at it :)
OK. I really didn't intend to be patronizing, especially since the theory and the math really aren't the central issue — I just wasn't sure where you were coming from.
-
That doesn't mean that joofa doesn't have a point
Actually that’s EXACTLY what it means.
And that's how I read Bruce's comment. 99% of the time, AdobeRGB is fully contained in ProPhoto RGB. However, if you do a certain thing which has some large consequences (R=G=B is not neutral), it's not. That certain thing is the example that joofa pointed out.
What you’re failing to appreciate is the utter invalidity of an R=G=B that isn’t neutral. It has only one meaning...that your conversion process is wrong.
-
Mark, since you're still around -- would you mind replying to reply #511?
-
Yes, you are 100% correct. I could demonstrate that on Joofa's own graph, but it's pointless because he does not want to commit to the method he is using. If I took the time to make a graph demonstrating this, he would simply say it isn't correct without further explanation. In other words it's a waste of time.
So when Joofa shows us that, under a condition that should never be the case, a well-known fact is not true, you must be able to understand that he will be met with some pretty stiff resistance. When he is exceptionally cagey in his responses to questions and is unable to give a clear explanation of what he's doing, but insists that he is right and intimates that some well-respected members of this community don't know what they are doing, he becomes a troll.
Mark, I have no personal vandetta against you. Because, if I did, then trust me you provided me with a wonderful opportunity to embarass you online with that proceedure of yours to determine gamuts, which was so patently incorrect and naive. See, you are trying too hard to give a certain impression (ref: having Fairchild's book on your nightstand). As, TGray noted, we should embrace all of the ensuing discussion with an open mind. Anybody can make a mistake, which includes you and me. But it is just a small discussion; our lives should not depend upon it.
Best regards,
Joofa
-
In the subsequent 2 pages of responses, of which you were a part of, you, digitaldog, and maybe a couple others tried to correct the mistake Iliah had made. Joofa will not consider any other process of converting the color.
This entire argument boils down to adaptation. If you use adaptation, the blue is within Pro Photo, and if you don’t then it isn’t (or if you simply mess it up because you don’t realize what you’re doing on the calculator.)
Joofa doesn’t seem to care that the blue he started with appears different when trying to find its place in Pro Photo. And that’s the core issue. He only cares about numbers, and we care about the way the blue appears to a human. It seems pointless to continue.
Haven't we seen that if we go Prophoto RGB (D50) to Adobe RGB (D65) then even with adaption certain colors fall outside gamut. So, there is a wider issue at hand.
Joofa
-
Haven't we seen that if we go Prophoto RGB (D50) to Adobe RGB (D65) then even with adaption certain colors fall outside gamut. So, there is a wider issue at hand.
No, we haven't. What we've seen is that with adaptation Adobe RGB is within Pro Photo.
The only time we see Adobe RGB outside of Pro Photo is when the illuminant for the XYZ space is switched. Simply selecting a different illuminant for the XYZ space, in the middle of your conversions, is not adaptation...it's a mistake.
-
No, we haven't. What we've seen is that with adaptation Adobe RGB is within Pro Photo.
The only time we see Adobe RGB outside of Pro Photo is when the illuminant for the XYZ space is switched. Simply selecting a different illuminant for the XYZ space, in the middle of your conversions, is not adaptation...it's a mistake.
Please back and read tho_mas' message and read my response to him.
Joofa
-
The only time we see Adobe RGB outside of Pro Photo is when the illuminant for the XYZ space is switched. Simply selecting a different illuminant for the XYZ space, in the middle of your conversions, is not adaptation...it's a mistake.
Again, there is no need to change the Ref. White setting. Leave it at D50 (or wherever),
but set Adaptation to None - right from the beginning. Interestingly enough BL's calculator offers this option.
Peter
--
-
OK. I really didn't intend to be patronizing, especially since the theory and the math really aren't the central issue — I just wasn't sure where you were coming from.
I figured that and know you didn't mean it that way. Maybe it helped someone else. If we all were a bit less condescending in this thread and actually explained our points like you just did, we'd be better off.
Actually that’s EXACTLY what it means.
I'm quite aware of what it means. And that's not it.
What you’re failing to appreciate is the utter invalidity of an R=G=B that isn’t neutral. It has only one meaning...that your conversion process is wrong.
Your language is strong. The utter invalidity? While walking to my car last night, I looked out the building window. The sun had set about 45 minutes earlier. The snow on the ground look positively blue relative to the indoor environment I was in. Last I checked, snow essentially is R=G=B.
Now, that's just an anecdote that may or may not relate to color spaces, but Mark already provided us with a scenario where you don't in fact use relative colorimetric. Is his point 'utterly invalid'?
I'm guessing joofa would say that in his comparison #1 and implicit transformation, that no, the whites of the two systems aren't the same. Instead of shouting, 'You're wrong!' which is what many people in this thread are doing, it'd be a lot more productive to say, 'You're right, but we hardly ever do your case #1; instead #2 is wanted most of the time.' Furthermore, this discussion could more onto more interesting things like:
- Is chromatic adaption in a color model the same as color constancy in the visual system?
- Are there cases when we don't actually want to apply a chromatic adaptation? Iliah has mentioned yes several times. How would one carry that out in practice?
I'd appreciate it if you'd give me a bit more credit for my thought processes. It's funny how people jump on statements like, "I don't work in this industry," and over interpret that. When I said that, and that I'm not an expert, I meant that I don't work in the color science industry, i.e. at Xrite, etc, and also that I haven't worked in research in the field for a living either.
-
Digital cameras don't have a gamut, but rather a color mixing function. Basically, a color mixing function is a mathematical representation of a measured color as a function of the three standard monochromatic RGB primaries needed to duplicate a monochromatic observed color at its measured wavelength. Cameras don’t have primaries, they have spectral sensitivities
The point is that if you think of camera primaries you can come to many incorrect conclusions because cameras capture spectrally. On the other had, displays create colors using primaries. Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries. Therefore, the measured pixel values don't even produce a gamut until they're mapped into a particular RGB space. Before then, *all* colors are (by definition) possible.
Although the forgoing is accepted dogma among color experts, there are some complications. The eye and the camera both have three sets of receptors, roughly red, blue, and green. Each set of receptors responds to a wide range of wavelengths (or else there would be gaps in color recognition). The responses of the eye and two representative cameras are shown. Human color perception is likewise a color mixing function. I once naively proposed on one of the Adobe forums, that if camera RGB filters were constructed to have the same spectral characteristics of the human cones, color reproduction could be improved.
Thomas Knoll replied that perfect reproduction does not require the same spectral response of the eye, but that filters fulfilling the Luther-Ives (http://www.kweii.com/site/color_theory/cri/ives.html) criteria would suffice. Unfortunately no such filters exist and there are additional complications involving imaginary colors and negativge color values (see the paper by Doug Kerr (http://dougkerr.net/pumpkin/articles/Sensor_Colorimetry.pdf).
Furthermore, human vision is not strictly tri-stimulus and opponency (http://en.wikipedia.org/wiki/Opponent_process) is also involved. Some of this takes place in the retina through the action of bipolar cells, but some elements in the brain are likely involved.
I is not surprising that color reproduction with digital cameras is only approximate. Most raw converters assume that the camera does have a "raw space" and use matrix math to convert from the camera space to XYZ. The matrix coefficients are chosen to introduce the least error in reproduction of certain important colors such as skin tones and foliage. Use of nonlinear math rather than a matrix of linear equations could improve the situation once enough computing power is available.
Of course, color adaption is a further complication. How does it take place? In the retina by varying the responses of the sensors (perhaps by varying the synthesis of the photo pigments) or by a perceptual process? If the latter, is would be very difficult to measure perceptions.
Regards,
Bill
-
While walking to my car last night, I looked out the building window. The sun had set about 45 minutes earlier. The snow on the ground look positively blue relative to the indoor environment I was in. Last I checked, snow essentially is R=G=B.
This is a good example of why numbers alone don’t really tell us a lot about color perception or for that matter color. Keep in mind that color is a perceptual properly. If you can’t see it, its not a color despite numbers.
Its not a particular wavelength of light. It is a cognitive perception that is the end result of the excitation of photoreceptors followed by retinal processing and ending in the visual cortex. Color is defined based upon perceptual experiments. A coordinate in a "colorspace" outside the spectrum locus is not a color although this is often referred to as "imaginary colors" (my color scientist tech editor tells me this is by and large also erroneous as you can't map an imaginary color from one colorspace to another as the math (and experimental data) for each colorspace breaks down outside the spectrum locus).
-
Use of nonlinear math rather than a matrix of linear equations could improve the situation once enough computing power is available.
That's already at least partially done - Camera profiles with "hue twists" are in effect doing a non-linear conversion. You could conceive of a conversion with maths that entirely avoided the matrix step, but I've not seen any examples of such a conversion that offered significant advantages versus hue twists. Would be interested if someone did have such an example.
Sandy
-
Using twisted profiles, do you have colour shifts when changing the value of exposure correction slider?
-
Again, there is no need to change the Ref. White setting. Leave it at D50 (or wherever),
but set Adaptation to None - right from the beginning. Interestingly enough BL's calculator offers this option.
You are failing to realize that when you set Adaptation to None, you are saying to use the white point of the selected RGB space.
Setting Adaptation to None (with any Ref White) is the same as using an Adaptation method and changing the Ref White in the middle of your conversion from D65 to D50.
When you convert Adobe to XYZ, the result is tristimulus values that are related to an illuminant. If you select D65 with adaptation, or Adaptation None, then the illuminant is D65. But it's just as valid to select a different illuminant, such as standard illuminant E, with adaptation. You get different tristimulus values, but they’re related to a different illuminant. The tristimulus values and the illuminant create the Adobe blue response in the eye.
But then, your next step is to change the illuminant...either directly in the calculator by selecting D50 (when using adaptation) or indirectly when using Adaptation None (the white point of the destination space will be used.) When you do that you change the blue response in the eye, because the tristimulus values are the same but the illuminant is different. It’s a different blue. So you’re mapping a blue that has nothing to do with Adobe saturated blue, and then claiming that Adobe blue isn’t in Pro Photo.
This must be the hundredth time this has been explained.
-
You are failing to realize ...
No, you fail to realize.
YOU are insistently presuming chromatic adaptation.
I'm considering it as an option, typically the preferred one, but not necessarily.
Example: some years ago I had problems with monitor calibration & profiling. Suddenly all images looked greenish to me (in a color-managed environment). Actually I was not really able to adapt to the new white point of my monitor. I didn't like it. It should have been unchanged D65, but that was obviously not the case anymore. In order to verify my impression I created a white patch, assigned my monitor profile and converted AbsCol to a D65 working space. The result was that R, G, B got different from each other, confirming that my monitor white wasn't D65. The rest turned out to be a handling error with the software package.
Peter
--
-
No, you fail to realize.
YOU are insistenly presuming chromatic adaptation.
I'm considering it as an option, typically the preferred one, but not necessarily.
Well, if we both understand what's happening and what it means, but simply have different views of the validity, then we're at an impasse. We'll just have to agree to disagree.
-
Go back and read tho_mas' message and read my response to him.
for instance this one? -> http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413842#msg413842
Well, it's a statement, not really an answer (i.e. you are not adressing my question).
My point of view: when all PropPhoto blues are clipping converting relcol or abscol to AdobeRGB as target this consequently means that there is no AdobeRGB blue that is outside of ProPhoto. If there would be a AdobeRGB blue value outside of ProPhoto the respective AdobeRGB blue value would not clip.
You say the gamuts fall outside of each other - consequently some AdobeRGB blues should not show clipping.
But all AdobeRGB blues show clipping. Why?
-
Well, it's a statement, not really an answer (i.e. you are not adressing my question).
My point of view: when all PropPhoto blues are clipping converting relcol or abscol to AdobeRGB as target this consequently means that there is no AdobeRGB blue that is outside of ProPhoto.
I'm not sure if this is a complete standalone thought, but I interpreted it as one. If not, ignore what I say next.
If all Prophoto blues clip when converting to AdobeRGB relcol or abscol, that means those blues are not in AdobeRGB. It does not mean that all AdobeRGB blues are (or are not) in Prophoto.
The analogy is squares and rectangles. 'All squares are rectangles' does not imply that 'all rectangles are squares.'
-
> Are there cases when we don't actually want to apply a chromatic adaptation? Iliah has mentioned yes several times. How would one carry that out in practice?
In fact there is a strategy that is called multi-zone white balance in RML (RawMagick Lite). The user has two options - to sample different neutrals across the scene and the algorithm will weight and average those; or to set different white balances for different zones with smooth transitions in between. Effectively it is some sort of control over chromatic adaptation. There are more modern strategies now, too.
Looking at paintings one can see how applying full chromatic adaptation can ruin a chef-d'oeuvre. El Greko, Levitan, Monet, ... Same about perspective, depth of filed (View to Toledo). All of those are creative instruments and can't be applied indiscriminately.
-
for instance this one? -> http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413842#msg413842
Well, it's a statement, not really an answer (i.e. you are not adressing my question).
My point of view: when all PropPhoto blues are clipping converting relcol or abscol to AdobeRGB as target this consequently means that there is no AdobeRGB blue that is outside of ProPhoto. If there would be a AdobeRGB blue value outside of ProPhoto the respective AdobeRGB blue value would not clip.
You say the gamuts fall outside of each other - consequently some AdobeRGB blues should not show clipping.
But all AdobeRGB blues show clipping. Why?
Please see my reply #414 to you. There is at least one more reason also that I just mentioned casually in reply #418, which is involved, and I am not prepared to go in details here.
Sincerely,
Joofa
-
... when all PropPhoto blues are clipping converting relcol or abscol to AdobeRGB as target this consequently means that there is no AdobeRGB blue that is outside of ProPhoto.
The inverse test works reasonably well with the Granger Rainbow posted many pages ago,
ProPhoto RGB blues do not clip when converting AbsCol to Adobe RGB
(within the limits that we can believe in oog marks).
Peter
--
-
Mark, since you're still around -- would you mind replying to reply #511?
Hi Emil,
I thought I did in a follow up here: http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413941#msg413941
-
Looking at paintings one can see how applying full chromatic adaptation can ruin a chef-d'oeuvre. El Greko, Levitan, Monet, ... Same about perspective, depth of filed (View to Toledo). All of those are creative instruments and can't be applied indiscriminately.
Interesting that you should mention Monet. You're probably aware that after he had surgery to remove a cataract, he realised that he was seeing colours differently compared to his youth. Painting with one eye he would describe a scene as blue/green in an area whereas with the other he would show orange/red.
In other words, the exact same scene can fall outside of its own gamut if you filter it incorrectly.
-
Joofa:
You are utterly dismissing any attempts to argue against your hypothesis. You have even dismissed some people as needing to learn more colour science. Since you invoked the science of the matter, it is beholden to you for provision of data and method in order that your hypothesis may be tested - that we may attempt to falsify it. Once that it is done, and assuming it stands up to the rigour of falsification, we can then attempt to discern if it fits with observation. In such case, it may become a workable theory.
By continuing to refuse to provide your actual data ("it's on Google" isn't sufficient), and by simply saying, "but others have found it and worked it out and agreed" also doesn't stand up to scientific scrutiny, because until all parties share their data and method, we have no way of knowing if it's the same and no way of falsifying it.
-
Mark, I have no personal vandetta against you. Because, if I did, then trust me you provided me with a wonderful opportunity to embarass you online with that proceedure of yours to determine gamuts, which was so patently incorrect and naive.
Joofa, I posted those in a sincere attempt to understand what you are saying with your graph. I put it all out there, explained specifically what I was doing, and then asked, "is this what you mean?" It was meant as an opportunity for you to tell me where I was going wrong. I wouldn't find it the slightest bit embarrassing to be wrong and if I'm naive, so be it. Please embarrass me if it means explaining in detail why that graph is important. I've tried to be very clear with everything I've posted here—this is because if I'm wrong, I want people to have enough information to show me exactly where I'm wrong. I don't want to post a bunch of half-committed ideas that are impossible to agree or disagree with.
But calling me naive and showing how I'm naive are two different things. Show me. Show us all. Be blunt, I can take it. I relish the chance to be embarrassed if it means you will clearly explain why that graph that you keep reposting is important to your point.
So, this is what I see on that graph (It's on page two of this thread):
• A three dimensional space with an unlabeled scale along the outer edges
• Six lines arranged inside the space connecting to the origin of the unlabeled space
• Labels indicating that the lines represent primaries from Adobe and ProPhotoRGB (although you've used the terms Adobe(D50) and Adobe(65) throughout the thread, so the label is a little vague.
• A line labeled 'spectral colors'
So you can continue to be cagey and vague about this or you can fill us in.
Here's a start:
•Do the numbers outside the box represent XYZ numbers?
•Which Axis is which?
•The endpoints of the vectors, presumably are XYZ coordinates (but that depends on the first question)—since you are clearly working with numbers, maybe you could just post the coordinates of the vectors. It's only six numbers, you can cut and paste.
-
Using twisted profiles, do you have colour shifts when changing the value of exposure correction slider?
Depend where the twist is; if you were using twists to achieve non-linear sensor space to RGB conversion, you would structure the profile so as to position the twist before exposure correction, and not get color shifts on exposure correction. Which is different to using hue twists to achieve a particular look.
Sandy
-
Joofa, I posted those in a sincere attempt to understand what you are saying with your graph.
Is your idea of "sincere attempt to understand" accomplished by calling me a waste of effort, troll, mocking me several times, saying I'm setting up smoke screens, etc?
Here's a start:
•Do the numbers outside the box represent XYZ numbers?
•Which Axis is which?
•The endpoints of the vectors, presumably are XYZ coordinates (but that depends on the first question)—since you are clearly working with numbers, maybe you could just post the coordinates of the vectors. It's only six numbers, you can cut and paste.
No, it is not XYZ. And, I said that right there in my reply #396 to you.
Sincerely,
Joofa
-
No, it is not XYZ. And, I said that right there in my reply #396 to you.
OK, that's a start. You've put numbers along the outside of the graph. What are those numbers?
-
> if you were using twists to achieve non-linear sensor space to RGB conversion
Why would that be helpful?
-
Hey Joofa! Good news! Everything is fine! Look at this 3D L*a*b* display I produced from Gamutvision using the "Absolute" comparison method (it’s Gamutvision, what all the big names use for testing, so you know it has to be right.) It shows that Abobe RGB (1998) is fully contained within Pro Photo. So you have nothing to worry about!
(http://home.roadrunner.com/~graystar/adobergb-prophoto.jpg)
-
> Interesting that you should mention Monet.
Yes, the purpose of those three particular names was to give examples of three mane reasons.
> the exact same scene can fall outside of its own gamut if you filter it incorrectly.
Incorrectly or artistically.
-
Hey Joofa! Good news! Everything is fine! Look at this 3D L*a*b* display I produced from Gamutvision using the "Absolute" comparison method (it’s Gamutvision, what all the big names use for testing, so you know it has to be right.) It shows that Abobe RGB (1998) is fully contained within Pro Photo. So you have nothing to worry about!
Graystar, I think at this stage it has become like beating a dead horse. Just look at the posts of Peter (DPL) to verify what has been said so far. I think discussion is now turning to the interesting area of when is chromatic adaptation not required.
Sincerely,
Joofa
-
Graystar, I think at this stage it has become like beating a dead horse. Just look at the posts of Peter (DPL) to verify what has been said so far. I think discussion is now turning to the interesting area of when is chromatic adaptation not required.
No. Please look. The display is correct. I can't overemphasize that fact.
-
No. Please look. The display is correct. I can't overemphasize that fact.
Hi,
I prsented my case. Several people independently verified and agreed with the premise under the prerequisites that I stated clearly. It is entirely possible that I have been wrong all along. You don't have to agree with me. You can take up any doubts you have with the makers of these commercial programs.
Sincerely,
Joofa
-
•Do the numbers outside the box represent XYZ numbers?
No, it is not XYZ. And, I said that right there in my reply #396 to you.
OK, that's a start. You've put numbers along the outside of the graph. What are those numbers?
(…crickets chirping)
-
> Interesting that you should mention Monet.
Yes, the purpose of those three particular names was to give examples of three mane reasons.
> the exact same scene can fall outside of its own gamut if you filter it incorrectly.
Incorrectly or artistically.
But the variations Monet experienced were due to faults with his vision. He was so shocked by it that he wanted to redo many of his paintings and of course even destroyed a number.
-
Hi,
I prsented my case. Several people independently verified and agreed with the premise under the prerequisites that I stated clearly. It is entirely possible that I have been wrong all along. You don't have to agree with me. You can take up any doubts you have with the makers of these commercial programs.
This is impossible since you have not presented your data and methodology. Whilst they may appear to have come to the same conclusions as you, nothing has been verified.
-
This is impossible since you have not presented your data and methodology. Whilst they may appear to have come to the same conclusions as you, nothing has been verified.
Hi,
Please see the attachment to Iliah Borg's first message in this thread. All the data you need is right there in his attachment, and it literarily takes a few seconds to punch in a couple of numbers he has shown.
Sincerely,
Joofa
-
Please see the attachment to Iliah Borg's first message in this thread. All the data you need is right there in his attachment, and it literarily takes a few seconds to punch in a couple of numbers he has shown.
No. Please, several others have independently arrived at the same result that’s in the 3D L*a*b* display. But they did not use Gamutvision Absolute comparison. Please look at the display. It was created with Gamutvision. There is no doubt that it is correct.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
-
> But the variations Monet experienced were due to faults with his vision.
Those variations started when he was about 65 if memory serves. Look at his painting accomplished before 1905.
-
They are not independent functions—that's what he means. In a perfect world you could independently manipulate the individual cone type; you could find three wavelengths, one for each cone type and send light that would only stimulate each one. But it doesn't work because, with the exception of the far end of the red spectrum there are no wavelengths that only effect one cone. So when you use a green primary with the intention of manipulating the middle cone, you also inadvertently get some of the short cone or the long cone. It's not always a problem because you can often still find the right mix for a match, but for saturated colors it is a problem. He provides a real world example in the book with the calculations, which is convincing, but takes a few pages. (You might be able to find the pages in question by searching the book on Amazon of Google Books for the term: "Unwanted Stimulations" (A term I hear from wife from time to time)
Thanks, I missed this reply earlier.
They are independent functions, just not orthogonal. It is not necessary that they be orthogonal, just independent. The only time there is a problem is when different spectra cause the same cone response for all three types -- ie metamerism.
-
I agree that for artistic purpose you may not want perfect chromatic adaptation in all cases. There are several photographers that use colored gels over flashes to get particular color effects (Joe McNally comes to mind).
Also, you may have images with different illuminants (like the examples of the inside of the house with an incandescent light and the outside at sunlight) and in these cases, the possibility of selecting different areas with different white balance each looks really interesting.
The part which I fail to grasp is about how to involve different color spaces here. All of the above we can handle today either with color filters over lights (whenever possible) or by blending layers in photoshop (time consuming) but working always in one color space, being AdobeRGB or PhotoshopRGB.
Some possibilities:
- Current color management is not flexible enough as is today and you will have compromises where you loose some saturated colors. An option might be to use the color space that will preserve the saturated colors that interest you as the author of the image (may be that R=G=B is not neutral).
- The possibility to define adaptive color spaces depending on scene content and photographers artistic´s purposes (might be a nightmare to implement)
- Raw converters that allow to select not only different white balance but different color spaces for selected areas of an image. I don´t even know if this make sense or is feasible. I was just thinking in the old days of the darkroom, specifically B&W. Suppose you had a part of the image with normal to high contrast and another with very low contrast, with single graded paper you made compromises, with multigrade paper, you could print different parts of the image with different contrast
These are just ideas that come to mind,
-
> But the variations Monet experienced were due to faults with his vision.
Those variations started when he was about 65 if memory serves. Look at his painting accomplished before 1905.
Around then, yes, I agree.
Of course prior to that is purely artistic, and Monet is an excellent example. My point, though, was that if you're just talking about artistic interpretation then anything is correct. I disagree with that approach - we're talking science. Although it's entwined with art in the case of photography, there's a distinction between the parts. There's no meaning to colour space or adaptation or anything else if you're just going to explain it as artistic interpretation. There's no basis to compare one with the other.
You might as well apply quadratic equation for your conversion and say it's valid because artistically you like the results. From that point of view, fine. From a colour science or colour management point of view, not so fine.
-
Hi,
Please see the attachment to Iliah Borg's first message in this thread. All the data you need is right there in his attachment, and it literarily takes a few seconds to punch in a couple of numbers he has shown.
Unless you're saying that Iliah's data and methodology is entirely how you arrived at the same conclusion, then this is still pointless.
You keep saying you don't mind if you're wrong - well then post up the data and the method.
-
> we're talking science.
Science that suggests to ignore both facts and art is nothing more but a bootleg.
-
Unless you're saying that Iliah's data and methodology is entirely how you arrived at the same conclusion, then this is still pointless.
You keep saying you don't mind if you're wrong - well then post up the data and the method.
Hi,
Please see the following link when I talked about the same numbers:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412129#msg412129
Sincerely,
Joofa
-
Quote from: MarkM
•Do the numbers outside the box represent XYZ numbers?
Quote from: Joofa
No, it is not XYZ. And, I said that right there in my reply #396 to you.
Quote from: MarkM
OK, that's a start. You've put numbers along the outside of the graph. What are those numbers?
Seriously Joofa, I thought this would be a simple question. What are the numbers on the axis of your graph???
The link you just pointed to only talks about XYZ numbers, but you say that's not what you are plotting ?
-
Hi,
Please see the following link when I talked about the same numbers:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412129#msg412129
Just, in one, single post, provide your data and complete methodology. Don't reference anything externally. Otherwise, please don't bother.
-
The inverse test works reasonably well with the Granger Rainbow posted many pages ago,
ProPhoto RGB blues do not clip when converting AbsCol to Adobe RGB
(within the limits that we can believe in oog marks).
Peter
--
Hi,
Is what you are saying different than what tho_mas said here:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg413712#msg413712
Thanks,
Joofa
-
Please see the following link when I talked about the same numbers:
I don’t understand. I thought we all agree that Adobe RGB is contained within Pro Photo. Please look at the display in my previous post. The proof is there. I can't overemphasize that fact.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
-
I don’t understand. I thought we all agree that Adobe RGB is contained within Pro Photo. Please look at the display in my previous post. The proof is there. I can't overemphasize that fact.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
Please call Gamut Vision customer service and ask for a refund ;D
Joofa
-
Quote from: MarkM
•Do the numbers outside the box represent XYZ numbers?
Quote from: Joofa
No, it is not XYZ. And, I said that right there in my reply #396 to you.
Quote from: MarkM
OK, that's a start. You've put numbers along the outside of the graph. What are those numbers?
(Crickets Chirping)
This is a good read from scienceblogs that demonstrates a proper response to unlabeled graphs:
http://scienceblogs.com/pharyngula/2009/05/o_brave_new_world_that_has_suc.php
"But what are the units of the Y axis? What's being measured? I have no idea. I presume it's a stacked percentage of something, but that's unclear. Information produced? Absorbed? Thrown at a wall and forgotten? What kind of information? It's all lumped together and unspecified. Could we have some units, please?"
"This whole chart was built out of some guy's impressions. There are no numbers and no sources and no measurements were made. It puts up a colorful pretense of being quantitative, but there's nothing but vapor and handwaving there."
-
Please call Gamut Vision customer service and ask for a refund
I think you are joking! ;D This software is very good. The Absolute displays are very accurate because it was created by experts. I think you would like Gamutvision. Their expertise has helped us all to agree that Adobe RGB is fully contained within Pro Photo, as shown in the display I posted earlier.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
-
This is a good read from scienceblogs that demonstrates a proper response to unlabeled graphs:
In the same vein:
http://www.scottberkun.com/essays/53-how-to-detect-bullshit/
-
I think you are joking! ;D This software is very good. The Absolute displays are very accurate because it was created by experts. I think you would like Gamutvision. Their expertise has helped us all to agree that Adobe RGB is fully contained within Pro Photo, as shown in the display I posted earlier.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
Too bad I don't have any friends who could attest to my expertise. :-\ A long time ago I tried to endear myself to Emil Martinec, but he hates me. A couple more have been added on this thread >:(
Joofa
-
Too bad I don't have any friends who could attest to my expertise. :-\ A long time ago I tried to endear myself to Emil Martinec, but he hates me. A couple more have been added on this thread >:(
Joofa
I would have to say that it's largely because
1. You have refused over and over again to answer simple direct questions from others who have tried very hard to understand what you are trying to say, and
2. You have repeatedly insulted a great number of serious and highly knowledgeable experts who have very patiently tried to engage you in rational discourse, and
3. You have steadfastly refused to explain how you arrive at the claims you seem to be making.
I find it hard to understand how you obtained a Ph.D. in engineering (according to Google) when you don't seem to understand the necessity of labeling the axis and units on a graph. For that error alone you would have failed any of the hundreds of college freshman-level math courses I have taught.
Eric
-
> I would have to say that it's largely because
> 1. You have refused over and over again to answer simple direct questions
I'm afraid he did answer, but the answers were not understood. Same as the answer Bruce gave in his e-mail that was quoted here.
> you don't seem to understand the necessity of labeling the axis and units on a graph. For that error alone you would have failed any of the hundreds of college freshman-level math courses I have taught.
Everything brought to the extreme turns into rubbish. In this case the labels and scales for the axis were pretty clear from the context (if only one knows it), and if they were not - the (polite) question of what are they should be asked immediately. Now this looks like a straw. Labeling axis does not help if the opponent is on an agenda or does not know the subject.
Here is a small story about labeling axis. Tamm (http://en.wikipedia.org/wiki/Igor_Tamm ) once was stopped by a post-graduate in a corridor of FIAN ( http://en.wikipedia.org/wiki/Lebedev_Physical_Institute ). The guy was asking for an explanation of a graph he made from an experiment. Tamm explained. After he finished they recognized the graph was upside down. They rotated the paper and Tamm gave another explanation.
-
I find it hard to understand how you obtained a Ph.D. in engineering (according to Google)
Oh, they are dime a dozen these days. Don't worry about it. I can probably try to arrange one for you if you like. Very handy for a false sense of ego. And people take you more seriously.
you would have failed any of the hundreds of college freshman-level math courses I have taught.
Glad I never attended your college. I wasn't good in math anyway.
Regards,
Joofa
-
> I think you are joking!
Think again because he does not. There is an error either in how you use it or in the particular calculation module implementation. Simple basic math as well as graphs made by those who understand how to apply AbsCol; and the email from Bruce all give the correct answer.
> The Absolute displays are very accurate because it was created by experts.
Even experts make mistakes, especially in chromatic adaptation. I also suggest that you present the sequence of operations you used so that your steps can be independently verified; and if the error is in the software a proper report given to Norman and his team.
-
> if you were using twists to achieve non-linear sensor space to RGB conversion
Why would that be helpful?
To address the issues discussed in post 560. In theory :)
As mentioned in a previous post, personally I've never seen a practical example of where hue twists were helpful in getting from camera space to a reference space. But that doesn't mean there isn't a way to do so. Hue twists are however, imho, very useful in achieving a particular "look".
Sandy
Sandy
-
> I think you are joking!
Think again because he does not. There is an error either in how you use it or in the particular calculation module implementation. Simple basic math as well as graphs made by those who understand how to apply AbsCol; and the email from Bruce all give the correct answer.
> The Absolute displays are very accurate because it was created by experts.
Even experts make mistakes, especially in chromatic adaptation. I also suggest that you present the sequence of operations you used so that your steps can be independently verified; and if the error is in the software a proper report given to Norman and his team.
No. There is no mistake. Bruce Lindbloom’s email agrees with my display. Please look again. The display is correct. I can't overemphasize that fact.
-
Interesting article by (Prof.) Gernot Hoffmann (http://www.fho-emden.de/~hoffmann/howww41a.html),
page 4 also expands on "chromatic adaptation is not perfect":
http://www.fho-emden.de/~hoffmann/cmsicc08102003.pdf
Peter
--
-
Too bad I don't have any friends who could attest to my expertise. :-\ A long time ago I tried to endear myself to Emil Martinec, but he hates me. A couple more have been added on this thread >:(
That’s okay Joofa...anyone can be mistaken. We are all here to learn. Here is a plot of Adobe RGB against Pro Photo from Bruce Lindbloom 3D Gamut Viewer. His 3D view also has Adobe RGB contained in Pro Photo...like the Gamutvision display. These are the correct views. I can't overemphasize that fact.
(http://home.roadrunner.com/~graystar/plots4.jpg)
-
That’s okay Joofa...anyone can be mistaken. We are all here to learn. Here is a plot of Adobe RGB against Pro Photo from Bruce Lindbloom 3D Gamut Viewer. His 3D view also has Adobe RGB contained in Pro Photo...like the Gamutvision display. These are the correct views.
Hi Graystar,
They are Adobe RGB (D50) and not Adobe RGB (D65). i have mentioned this several times.
I can't overemphasize that fact.
Haha, you parodying me. ;D
Sincerely,
Joofa
-
... when all PropPhoto blues are clipping converting relcol or abscol to AdobeRGB as target this consequently means that there is no AdobeRGB blue that is outside of ProPhoto.
The inverse test works reasonably well with the Granger Rainbow posted many pages ago,
ProPhoto RGB blues do not clip when converting AbsCol to Adobe RGB
(within the limits that we can believe in oog marks).
in how far inverse? I was talking about soure: ProPhotoRGB | target: AdobeRGB... ?
-
Here is a plot of Adobe RGB against Pro Photo from Bruce Lindbloom 3D Gamut Viewer. His 3D view also has Adobe RGB contained in Pro Photo...like the Gamutvision display.
this is relcol
-
Hi Peter,
Thanks for the pdf link. Interesting information.
Sincerely,
Joofa
-
A long time ago I tried to endear myself to Emil Martinec, but he hates me.
Joofa
A bit too strong; there are very few people I loathe, and you are not one of them. Let's just say there have been times I got annoyed at your tendency to focus on irrelevant technicalities.
-
this is relcol
No. The Gamutvision display is Absolute.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
-
No. The Gamutvision display is Absolute.
Bruce Lindblooms grapher that you've just posted is relcol (and of course correct for relcol).
Apparently you seem to think that it displays the same as Gamutvisions grapher:
Here is a plot of Adobe RGB against Pro Photo from Bruce Lindbloom 3D Gamut Viewer. His 3D view also has Adobe RGB contained in Pro Photo...like the Gamutvision display. These are the correct views.
IMHO the Gamutvision grapher doesn't make sense at all.
Where do you suspect AdobeRGB's white in this graph?: http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
-
your tendency to focus on irrelevant technicalities.
I think that sums it up for me. It does seem to me that joofa has a point, but it's most likely not relevant for everyday use. Maybe it is, but most probably not. However there seem to be those who won't acknowledge that he might have a point. Once you do, you can then move onto the next stage - Is it relevant?
Though 'made by experts', 'nobody does it that way', etc. are not valid arguments for correctness or relevance.
-
That’s okay Joofa...anyone can be mistaken. We are all here to learn. Here is a plot of Adobe RGB against Pro Photo from Bruce Lindbloom 3D Gamut Viewer. His 3D view also has Adobe RGB contained in Pro Photo...like the Gamutvision display. These are the correct views. I can't overemphasize that fact.
(http://home.roadrunner.com/~graystar/plots4.jpg)
Here are plots of Adobe RGB and ProPhoto RGB in Colorthink Pro using Relative Colorimetric and Absolute Colorimetric. The program seems a bit flakey and does not always show the same results, but with Absolute Colorimetric working properly the white points should be different. I set both displays to opaque. The ProPhoto RGB is in color and the Adobe RGB is white so they can't be mixed up. With Relative Colorimetric, the white point is adjusted and Adobe RGB is completely contained in ProPhoto RGB.
With Absolute Colorimetric, the white points are different and a portion of Adobe RGB is outside the gamut of ProPhoto RGB as Joofa has maintained.
Regards,
Bill
-
> It does seem to me that joofa has a point, but it's most likely not relevant for everyday use.
If you look at how proofing is done absolute colorimetric intent is in use there for certain cases. The goal of proofing is to mimic behavior of one media using a different media. Consider the real life scene to be presented to the eye observing it in person as one media, and the presentation of that scene on a display or on a print as the other media. Now what are we going to use as the rendering intent if we want to recreate the original impression of the scene?
-
With Absolute Colorimetric, the white points are different and a portion of Adobe RGB is outside the gamut of ProPhoto RGB as Joofa has maintained.
No. Please see the chart in my post here...
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
It is Absolute. You can see the different white points. Adobe RGB is inside of Pro Photo. It is Gamutvision. It is not flaky...it gives the same correct results everytime.
-
> It does seem to me that joofa has a point, but it's most likely not relevant for everyday use.
If you look at how proofing is done absolute colorimetric intent is in use there for certain cases. The goal of proofing is to mimic behavior of one media using a different media. Consider the real life scene to be presented to the eye observing it in person as one media, and the presentation of that scene on a display or on a print as the other media. Now what are we going to use as the rendering intent if we want to recreate the original impression of the scene?
Agreed. That was brought up by Mark I think. Though it would surprise me if you had an image in AdobeRGB and you were proofing in Prophoto RGB for output onto media.
-
> Though it would surprise me if you had an image in AdobeRGB and you were proofing in Prophoto RGB for output onto media.
To me, these two colour spaces are just an example why it is important to be careful using chromatic adaptation. However printer manufactures strive to cover ProPhoto while many photographed scenes fit nicely into smaller spaces. The reverse situation is not well-solved using perceptual intent as well, not to mention currently support for this intent in matrix profiles is extremely limited and visually problematic.
-
Interesting article by (Prof.) Gernot Hoffmann (http://www.fho-emden.de/~hoffmann/howww41a.html),
page 4 also expands on "chromatic adaptation is not perfect":
I don’t think the proponents of using chromatic adaptation to illustrate how these two color spaces in question, and their resulting gamuts appear, have suggested that it is perfect. The argument is its necessary, when using said profiles for color space conversions, imperfect or close to perfect. The proponents of “don’t use chromatic adaptation” to produce a gamut map that enforces their beliefs have not on the other hand, told us when, where, how or why we would not use the adaptation, imperfect or not. Bruce clearly points this out in his post as I read it.
-
> It does seem to me that joofa has a point, but it's most likely not relevant for everyday use.
If you look at how proofing is done absolute colorimetric intent is in use there for certain cases. The goal of proofing is to mimic behavior of one media using a different media. Consider the real life scene to be presented to the eye observing it in person as one media, and the presentation of that scene on a display or on a print as the other media. Now what are we going to use as the rendering intent if we want to recreate the original impression of the scene?
But such proofing conversations are using a true output profile to map the paper white. The two profiles in question are theoretical display profiles as I think was pointed out somewhere in this long set of posts (by Bruce perhaps?). They were designed for a purpose and to be well behaved when making conversions (R=G=B=neutral). Also discussed and demonstrated was the so called clipping (or lack thereof) when using these two profiles with both a RelCol and AbsCol intent. IOW, using proofing in this context with other, LUT based profiles is IMHO OT to the gamut theories proposed here.
-
No. Please see the chart in my post here...
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
It is Absolute. You can see the different white points. Adobe RGB is inside of Pro Photo. It is Gamutvision. It is not flaky...it gives the same correct results everytime.
Hm. I asked you to show the steps you've used to come up with the plot. Attached is a 3D wrl plot made using absolute colorimetric intent and CIECAM02 "original scene - bright outdoors" viewing conditions. AdobeRGB is in white, ProPhotoRGB is in "natural colour".
-
So-called camera profiles are often matrix-based (sometimes even those that pretend to be LUT-based); display profiles are often matrix-based too. We have what we have.
-
Interesting article by (Prof.) Gernot Hoffmann (http://www.fho-emden.de/~hoffmann/howww41a.html),
page 4 also expands on "chromatic adaptation is not perfect":
http://www.fho-emden.de/~hoffmann/cmsicc08102003.pdf
--
Maybe I should have added a couple of further lines to the example reported earlier:
>> Example: some years ago I had problems with monitor calibration & profiling. Suddenly all images looked greenish to me (in a color-managed environment). Actually I was not really able to adapt to the new white point of my monitor. I didn't like it. It should have been unchanged D65, but that was obviously not the case anymore. In order to verify my impression I created a white patch, assigned my monitor profile and converted AbsCol to a D65 working space. The result was that R, G, B got different from each other, confirming that my monitor white wasn't D65. The rest turned out to be a handling error with the software package.<<
But for a couple of days, before getting my monitor back to 'normal' and a believable white, I simply installed a fix Proof, AbsCol, D65 working space to monitor profile. That worked well enough.
This was in times of Photoshop CS when Adobe’s CMM supported AbsCol rendering between matrix spaces. Not sure why it was dropped. Could be an interesting question on its own. Today we need to resort to Microsoft’s CMM. For example, to illustrate that some Abobe RGB colors are outside ProPhoto RGB in an abscol sense:
Screenshot of a Granger Rainbow in Adobe RGB
Customized Proof Setup to ProPhoto RGB, AbsCol rendering
Gamut warning enabled, Conversion Engine: Microsoft ICM
Photoshop CS4 on Windows (should work with Apple’s CMM as well, and was also given with Adobe’s ACE in former Photoshop CS).
Corresponds to some of the 3D plots at least which we have seen here...
When you compare the gamuts AdobeRGB (white) and ProPhoto (wireframe) abscol in relation to D50…: (http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg)
-
Hm. I asked you to show the steps you've used to come up with the plot.
As Joofa has suggested, you can Google that information. It is easy to find and proves that Adobe RGB is completely inside of Pro Photo. I can't overemphasize that fact.
-
>> Hm. I asked you to show the steps you've used to come up with the plot.
> As Joofa has suggested, you can Google that information.
Your report on how you used GamutVision is not in Google.
-
No. Please see the chart in my post here...
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg414096#msg414096
It is Absolute. You can see the different white points. Adobe RGB is inside of Pro Photo. It is Gamutvision. It is not flaky...it gives the same correct results everytime.
I think there are 2 steps involved in your graph.
The "white" of AdobeRGB is spinned towards yellow and the whole thing is displayed under D50 conditions.
Displaying a comparison of both the colours spaces under their own respective lighing conditions is different.
The latter looks like this (the same as my graphs above and those of bjanes and Iliah)
(http://www6.pic-upload.de/09.01.11/nwtlj6pv641b.jpg)
Your image looks like ProPhoto abscol converted to AdobeRGB and displayed relcol to D50 (i.e. to ProPhoto).
Now, with my tools (Color Think standard) I can't replicate your graph, but there's a workaround.
I assigned ProPhotoRGB to the Granger Rainbow. The image loaded in the grapher shows exactly the shape of the ProPhoto icc profile (of course) as you can see here (white = icc profile / dots = image):
(http://www6.pic-upload.de/09.01.11/5cmeujr68ggs.jpg)
I've converted this image (i.e. the Granger Rainbow in ProPhoto) abscol to AdobeRGB.
I can't switch the RI in the Standard version of Color Think's grapher so I've converted the image back to ProPhoto (relcol).
This way I am able to compare it to ProPhoto in the grapher.
This is the result… and it seems that is exactly what your grapher is showing:
(http://www6.pic-upload.de/09.01.11/7o7dtot65jgr.jpg)
the same from a different angle:
(http://www6.pic-upload.de/09.01.11/bebefrcuxmeq.jpg)
I don't know the correct terminology to describe what your graph shows… but it doesn't show the 2 profiles under their respective white points.
-
This was in times of Photoshop CS when Adobe’s CMM supported AbsCol rendering between matrix spaces. Not sure why it was dropped.
I think we should make a difference between "ACE" and "Adobe CMM". These are different CMMs (see attachment).
Only the built in engine doesn't perform abscol in conjunction with matrix profiles as target whereas "Adobe CMM" does.
-
Now, with my tools (Color Think standard) I can't replicate your graph, but there's a workaround.
This link may explain why your copy of ColorThink Standard doesn’t replicate this and why my copy of ColorThink Pro does:
http://lists.apple.com/archives/colorsync-users/2006/Jun/msg00235.html
-
This link may explain why your copy of ColorThink Standard doesn’t replicate this and why my copy of ColorThink Pro does:
http://lists.apple.com/archives/colorsync-users/2006/Jun/msg00235.html
"I'm sure it will create some discussion along the way..."
That's an understatement!! :D
-
This link may explain why your copy of ColorThink Standard doesn’t replicate this and why my copy of ColorThink Pro does:
http://lists.apple.com/archives/colorsync-users/2006/Jun/msg00235.html
I am not sure if I understand correctly:
do you mean "new" Color Think displays the same as "Graystar's" graph from Gamutvision when the RI is set to abscol? So "bjanes" abscol graph shown above (which is the same as mine) is also made with an "old" Color Think version?
So with the RI set to "abscol" is AdobeRGB displayed like this: http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg ...
or is AdobeRGB displayed like this: http://www6.pic-upload.de/09.01.11/bebefrcuxmeq.jpg ?
Or do you simply mean Color Think Pro can switch RI's?
The contribution of Steve Upton is from June 2006. I am using CT 2.2.1b5 released October 2009.
The grapher still displays abscol in relation to D50.
-
I am not sure if I understand correctly:
do you mean "new" Color Think displays the same as "Graystar's" graph from Gamutvision when the RI is set to abscol? So "bjanes" abscol graph shown above (which is the same as mine) is also made with an "old" Color Think version?
So with the RI set to "abscol" is AdobeRGB displayed like this: http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg ...
or is AdobeRGB displayed like this: http://www6.pic-upload.de/09.01.11/bebefrcuxmeq.jpg ?
Or do you simply mean Color Think Pro can switch RI's?
The contribution of Steve Upton is from June 2006. I am using CT 2.2.1b5 released October 2009.
The grapher still displays abscol in relation to D50.
ColorThink Pro 3 can switch rendering intents. You can get both results.
-
ColorThink Pro’s default for mapping is a radio button called Device Gamut (which produces the map the same as setting RelCol). There is another radio button option to pick specific rendering intents, in this context, the selection of Abs will produce a graph that pushes the blue of Adobe RGB outside the gamut of ProPhoto RGB. I don’t know what the defaults for Non Pro are, but what Steve is saying in my mind confirms what Bruce has said as well. The need for adaptation and how (by default and text below), the gamuts should be viewed. Keep in mind here, the two profiles in question here are considered “monitor” profiles.
- to the "adapted eye" each monitor would appear to have a "white" white point and all colors would fall out relative to that white. So to the adapted eye the white points should line up.
- it turns out that any white point other than D50 in monitor profiles was not intended in v2 profiles and has been "outlawed" in v4 profiles. All colors are to be adapted to D50 and the white point should be D50 from now on.
- gamut comparisons should be done with the white points adapted in some manner. This will give a better indication of how two gamuts compare that when one of them has a shifted white point.
With this is mind it makes more sense to map all monitor gamuts to 100,0,0 which is how ColorThink Pro now plots and non-pro ColorThink will follow as well.
-
ColorThink Pro 3 can switch rendering intents. You can get both results.
ColorThink Pro’s default for mapping is a radio button called Device Gamut (which produces the map the same as setting RelCol).
you guys didn't read my post or you did not understand "Graystar's" graph.
"Graystar's" graph is supposed to show ProPhoto and AdobeRGB abscol.
But it's completey different from Color Think's abscol graph (IMO CT's graph is correct).
This is CT abscol: http://www5.pic-upload.de/07.01.11/gnhzegyold.jpg
But this is not CT relcol: http://www6.pic-upload.de/09.01.11/bebefrcuxmeq.jpg
but the latter is... most likely... what "Graystar's" grapher shows: http://home.roadrunner.com/~graystar/adobergb-prophoto.jpg
Whereas relcol is like in Bruce Lindblooms grapher (or Color Sync utility).
I don’t know what the defaults for Non Pro are
well, as I said: abscol
what Steve is saying in my mind confirms what Bruce has said as well. The need for adaptation and how (by default and text below), the gamuts should be viewed.
sure, but that is a different question.
My post above was meant to replicate "Graystar's" graph ... and you can't replicate it in ColorThink... neither when you set the RI to recol or abscol. "Graystar's" graph from Gamutvision involves at least two transforms. That's what my post is about.
-
It appears Gamutvision is a Windows only product, so I can’t comment on it specifically. I can’t comment on why the MS CMM does stuff that the Adobe CMM doesn’t either but if given an option for what to use for conversions, it be ACE. I’ll dig up the old X-Rite (GamutWorks) grapher and see what it provides.
-
It appears Gamutvision is a Windows only product, so I can’t comment on it specifically.
in my opinion it shows something that is definitely not abscol and definitely not relcol.
abscol would show blues/cyans/magentas and white outside of ProPhoto. And relcol would equalize the white points (as in Br. Lindbloom's grapher). This is why I think the graph shows two transformations simultaneously.
I can’t comment on why the MS CMM does stuff that the Adobe CMM doesn’t either but if given an option for what to use for conversions, it be ACE.
well, as I have mentioned several times: "Adobe CMM" does perform abscol with matrix profiles. Other than that it's exactly the same as "ACE".
"ACE" doesn't provide abscol with matrix profiles as target anymore... most likely to avoid "user errors" or so. But at the same time they trashed the option to use abscol intentionally.
You may download "AdobeCMM" here and play around with it a bit: http://www.adobe.com/support/downloads/detail.jsp?ftpID=3617
-
> It does seem to me that joofa has a point, but it's most likely not relevant for everyday use.
If you look at how proofing is done absolute colorimetric intent is in use there for certain cases. The goal of proofing is to mimic behavior of one media using a different media. Consider the real life scene to be presented to the eye observing it in person as one media, and the presentation of that scene on a display or on a print as the other media. Now what are we going to use as the rendering intent if we want to recreate the original impression of the scene?
Bruce Fraser (http://www.creativepro.com/article/out-of-gamut-realizing-good-intentions-with-rendering-intents) had a good post on this subect 10 years ago.
Regards,
Bill
-
I couldn't find a utility that would let me compare gamuts based on two white points in XYZ space. (I thought maybe the geometry would be a little easier to grasp than LAB plots). I had a little free time today so I fired up the python interpreter and blender to take a closer look at what I think is the issue of this thread.
Attached are two renderings of the parallelepipeds in XYZ space comparing the Adobe98 profile and the ProPhotoRGB profile.
In both the black point is the lower left vertex and white(s) are in the upper right.
The first image with the Adobe space completely contained is converted to XYZ using a matrix based on the Bradford-adapted primaries (e.i. the primaries in the actual AdobeRGB1998.icc file). I have not added any additional chromatic adaptation. The white points are equal when you do this.
The image that shows the Adobe space extending out of the ProPhoto space in the Z direction uses the matrix from Bruce Lindbloom's site labeled AppleRGB D65. (The primaries that create this matrix correspond to the chromaticities in the Adobe1998 spec, but are not the primaries found in the .icc file). If you had nothing other than the .icc file I'm not sure why you would use this matrix—you would have to look at the media white point in the .icc file and reverse the Bradford adaptation to get this matrix. Apparently that's what the Apple CMM does though when you set it to absolute colorimetric intent, so someone thinks it's a good idea.
As you can see in the second image, when you use these primaries, the white point is pulled in the Z direction and pulls the blue, magenta, and cyan vertices out of the proPhoto space. The line between the black point and the white points is now a different vector, which means greys in one aren't neutral. Which grey isn't neutral depends on your adaptation state.
It's tempting to think (as this thread has amply demonstrated) that the second image shows a difference in gamut. But another interpretation is that it shows the effects of chromatic adaptation on color perception. If you put yourself in the shoes of two different observers, one adapted to D65 light and another to D50 light, you can make some sense of the second chart. The D65 observer has become less sensitive to blue relative to the D50 observer due to the extra blue in D65 light. The D65 white point looks white and the D50 white point looks yellow to him. The blue primary in the Abode profile from here looks like a nice saturated blue. Now, if we look at if from the D50 observer, things look much different. The D50 white point looks white, of course. The D65 white point looks impossibly white/blue, whiter that white-like what laundry detergents promise. The blue primary of the adobe profile is super-blue, it's much bluer to you than it looks to the D65 viewer. There's a color you can see which looks just like the color the D65 viewer saw when looking at his blue primary. That's the Adobe98 blue primary in the first chart, which is happily within the gamut the Prophoto Space. That color to you looks exactly like the Adobe blue primary in second chart looks to the D65 viewer. One might say they are the same color even though they have different coordinates in XYZ space.
Clearly this idea represents a difference of opinion that is irreconcilable for some.
If anyone is interested, I'm happy to email the blender files that create these renderings. (Blender is free, but a pain in the ass to learn). I'll also send the python scripts that modeled the actual shapes and coordinates if anyone wants to play with them—just send me a note.
Below: ProPhoto RGB (the semi transparent shape) and Adobe1998 (the opaque shape) in two interpretations.
-
Is it just the perspective, or are the sides of the parallelepiped not parallel in the plot? They should be.
-
MarkM,
Thank you for posting both the illustrations and the explanation.
I have followed this thread from the beginning, hoping to learn something about color management, but most of what I have seen has been unlabeled plots that don't even state clearly what we are looking at, or sets of numbers with no meaningful context. I have been hoping someone would actually explain what we are seeing.
If those who have claimed that parts of AdobeRGB lie outside of Prophoto would try to provide a similar level of explanation of what their plots or numbers are about, I think they might stand a much better chance of gaining more respect, at least from me.
Eric
-
Clearly this idea represents a difference of opinion that is irreconcilable for some.
It’s a nicely written appeal, but I doubt it will pique the interest of anyone who would continue to respond to my posts even though I was clearly spoofing Joofa (come on!)
I think there are some very basic ideas that are being missed. First, colors do not exist. More than anything, color is a figment of our minds. When two different spectral distributions have the same color response, then they ARE the same color. It is the response that defines the color...not the light used to produce it.
Second, CIE color spaces are emissive spaces, and color response is dependent on both the tristimulus values and the light used when executing those values (the Standard Illuminants.) That’s why Adobe RGB Blue will convert to different combinations of tristimulus values and illuminant...they all create the same blue, they just use different spectral distributions to do it.
It should be clear to anyone who knows this information that if you keep the tristimulus values but change the illuminant, you’ve changed the color response (and hence, the color.) However, that bit doesn’t seem to matter to some people. As you say, it’s irreconcilable.
-
What Mark’s graph brings to the party for me is the illustration that the gamut doesn’t get larger, there’s simply a significant shift. This backs up the analysis ColorThink Pro provides of the gamut volume differences between Adobe RGB (1998) and ProPhoto RGB (1,205,502 vs. 2,548,220). Using no adaptation, which many here say is the wrong use of these types of display profiles, pushes blues of Adobe RGB (1998) outside the gamut of ProPhoto. Doesn’t make it larger (as claimed in Post #5):
It does not seem like that Prophoto RGB is always wider than Adobe RGB. It seems that saturated colors around blue Adobe primary might clip in Prophoto RGB in standard specification of these spaces. For more information please see:
http://forums.dpreview.com/forums/read.asp?forum=1018&message=37330104
We have an artificial, (some agree incorrect use of these two profiles), showing a theoretical “graph” without full explanation that attempts to back up this theory from post #5. One could say that if you take update the blue primary in Adobe RGB (1998), you can make it do the same thing (after which, someone could say its not Adobe RGB (1998) anymore), and another 30 pages of gobbledygook could be written.
The proponents of the theory still have not provided a means of or the reason to make the shift Mark illustrates. Bruce makes the consequences of doing so clear in his quote.
-
All,
We've known what the "answer" is here since page 2 of this thread - simplistically put, some folks don't agree with the orthodox approach to chromatic adaptation in current color management systems. Or perhaps even the need for it.
Which is fine, and the discussion has given us some useful and memorable posts.
But now it's time to agree to disagree and move on - short a coherent, concrete proposal as to what the alternative approach is, this conversation is going nowhere.
Sandy
-
One could say that if you take update the blue primary in Adobe RGB (1998), you can make it do the same thing (after which, someone could say its not Adobe RGB (1998) anymore), and another 30 pages of gobbledygook could be written.
I think Iliah actually made that point, or a similar one, earlier in this thread, with comparing Prophoto RGB AbsCol with a chromatically adapted version of itself to a bluer color temp.
Nice write up Mark. Maybe I'm missing something, but that's more or less what I got out of Joofa's original post. It's nice to see that you took the effort to explain things a bit more thoroughly than Joofa has been willing to do, but it is essentially the same thing as his example with the four cases.
I just don't see what all the hubbub is about. In his original post, he claims that AdobeRGB has blues outside of Prophoto's gamut when you don't chromatically adapt it to D50. That was it as far as I can read. And it seems most of you have actually agreed with it., minus the commentary that 'you'd never not use chromatic adaptation' or other objections.
Mark, you have a big paragraph at the end of your post talking about an alternative interpretation. A nice description, but again, doesn't this sum it all up:
AdobeRGB has blues outside of Prophoto's gamut when you don't chromatically adapt it to D50.
All the extra discussion, including Bruce's comment, are encapsulated and implied with the "don't chromatically adapt it" part of the statement. There's a warning right there that if you might not be preserving the perceptual relationships of the color*, since you aren't applying chromatic adaptation. We usually want our neutrals to be neutral. And you won't be getting that in this example. Etc. It seems like to me it's really all there in that sentence.
*excluding proofing and some of Iliah's examples
-
It's nice to see that you took the effort to explain things a bit more thoroughly than Joofa has been willing to do, but it is essentially the same thing as his example with the four cases.
In an incorrect representation. But there is no point in beating the dead horse. Please see below.
BTW, I think you are being a little unfair here. I have written detailed posts to illustrate some fundamental misunderstandings and how to do proper evaluation of colorimetric entities.
I just don't see what all the hubbub is about. In his original post, he claims that AdobeRGB has blues outside of Prophoto's gamut when you don't chromatically adapt it to D50. That was it as far as I can read. And it seems most of you have actually agreed with it., minus the commentary that 'you'd never not use chromatic adaptation' or other objections.
I think it is time to move on. Iliah has given a direction: When not to consider chromatic adaption. I think it is better to concentrate here now as this is a topic I also want to learn.
Sincerely,
Joofa
-
In an incorrect representation. But there is no point in beating the dead horse. Please see below.
Ok.
BTW, I think you are being a little unfair here. I have written detailed posts to illustrate some fundamental misunderstandings and how to do proper evaluation of colorimetric entities.
You did write detailed posts explaining your actions later. Your original one was a bit terse which lead to about 6 pages about how "AdobeRGB can't have a D50 white point, because it's then not AdobeRGB." I think you didn't imply that but people got caught in the semantics of the terminology. It probably could have been avoided with a bit more explanation initially. However, folks here have CLEARLY had some issues with what you wrote and how you've presented it. Feel free to call me a 'bit unfair' for recognizing that if you choose.
As far as when not to use chromatic adaptation and moving on, it might be time to start a new thread?
-
Ok.
You did write detailed posts explaining your actions later. Your original one was a bit terse which lead to about 6 pages about how "AdobeRGB can't have a D50 white point, because it's then not AdobeRGB."
What was that on the link below, right there on the 2nd page, which illustrated the confusion many were having including Digital Dog and MarkM:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412251#msg412251 (http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412251#msg412251)
Sincerely,
Joofa
-
What Mark’s graph brings to the party for me is the illustration that the gamut doesn’t get larger, there’s simply a significant shift.
and this is maybe one of the (initial) reasons for the long debate.... simply sounds "strange" that AdobeRGB is wider than ProPhoto... given that these are artifical color spaces that you actually always use relcol.
Would have been a different debate if Joofa looked at the old D65 sRGB and the revised D50 sRGB profiles ... and stated sRGB is wider than sRGB.
-
Would have been a different debate if Joofa looked at the old D65 sRGB and the revised D50 sRGB profiles ... and stated sRGB is wider than sRGB.
As impolite it might sound, we would have a different debate if some of the "color experts" had a better idea that what is a color space. Sorry for being a little politically incorrect. I apologize for the bluntness of language here. But you had given me no choice. Beating the same thing after 33 pages!
Joofa
-
What was that on the link below, right there on the 2nd page, which illustrated the confusion many were having including Digital Dog and MarkM:
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412251#msg412251 (http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412251#msg412251)
From that post...
"Instead of a reflector, suppose there is a source that emits two colors A = [0.1881852 0.0752741 0.9911085] and B= [0.14922403 0.06321976 0.74483862] in XYZ, which are, in absolute terms, two different colors."
This is your fundamental misunderstanding. Besides the fact that colors aren't emitted, the color response of the tristimulus values depends on the illuminant. With the same illuminant, the two sets of values invoke different color responses. With different illuminants, the color responses are the same. There’s nothing here that can be called “absolute.”
Color exists in the mind only...not in the light. Color has no physical properties. Color exists only as a response to light. That’s what you have to realize.
-
I apologize for the bluntness of language here
not a problem. understandable.
-
Is it just the perspective, or are the sides of the parallelepiped not parallel in the plot? They should be.
Good eye Emil. The renderer does apply a perspective view, but not enough to account for that. I had a left over gamma exponent in the wrong spot that was skewing the second image. Fix is attached. It's a significant difference, but the main idea should still be the same.
that AdobeRGB has blues outside of Prophoto's gamut when you don't chromatically adapt it to D50.
I guess I would sum up my view as yes and no. I'm much more in agreement with Graystar that XYZ coordinates without reference are not colors, blues or otherwise. And I think it's more than just a matter of semantics.
The XYZ space provides a very elegant model for seeing adaptation. If you imagine standing on the white point like it's the bow of of a ship and looking toward the stern, you see all the color relationships in front of you: you're at the highest point; straight ahead and down by the propeller is the black point, if you look further down things get yellow until you look almost right under your feet to the yellow point. Magenta/red are on your left, blue/cyan are on your right. Blue is above the black point, but still a little below you. If you look up or in the other quadrants, it's is the land of oxymorons, imaginary colors, blacker than black, etc. What's important is not the coordinate you're looking at, but the direction from where you're standing.
So imagine standing on the D65 white point and looking at that contentious blue point in the second image. You keep staring at the blue point as someone cranks a lever lowering you and the colors around you into the position of the first image until the white point you're on is now D50. The point you're looking at doesn't change color as this happens because you're still looking in the same direction, it still appears to be the same blue but now it fits easily inside the ProPhoto space. At this point you look up at the original coordinates of that blue and it looks totally different. At no point during this exercise did you ever see THAT color blue. That has never been the color we are talking about, it's only a set of coordinates. The color we're talking about, the one you saw in front and below you from the D65 white point, that color is easily reproduced with the prophoto space. It's not out of gamut.
Of course I understand that you can see things the other way. I just think we're talking about two different colors when you do that.
-
What Mark’s graph brings to the party for me is the illustration that the gamut doesn’t get larger, there’s simply a significant shift.
Hi,
According to my calculation the gamut of Adobe RGB (D65) is larger than that of Adobe RGB (D50). This is a very preliminary calculation and I have to verify it further yet.
Sincerely,
Joofa
-
According to my calculation the gamut of Adobe RGB (D65) is larger than that of Adobe RGB (D50). This is a very preliminary calculation and I have to verify it further yet.
One of your issues is language. There is no such thing as Adobe RGB (1998) D50 as was discussed a very long time ago. There’s some color space with Adobe RGB (1998) primaries and a D50 WP you are comparing (god knows how). The gamut calculations from ColorThink clearly produce a report that shows Adobe RGB (1998) is smaller than ProPhoto RGB. If you think its important, I’ll build a variant (JoofaRGB if you will), with D50 WP and ARGB primaries and see what ColorThink now reports, at least between Adobe RGB (1998) and JoofaRGB.
This language issue goes back to your first post in this thread:
It does not seem like that Prophoto RGB is always wider than Adobe RGB
I think what you could have originally said was “It does not seem like Adobe RGB (1998) is fully contained inside ProPhoto RGB, under a condition which probably isn’t possible outside of a web calculator, here you see blue fall outside ProPhoto RGB”. Would have saved a lot of posting between various parties!
Then like above, you started talking about Adobe RGB (1998) with a D50 white point which again isn’t possible, at least it would not be Adobe RGB (1998). We then got into the ideal of joofaRGB.
Then later still, thanks to others, we learned that its not Adobe RGB (1998) with a D50 WP that produces the results you report but rather viewing the two color spaces without chromatic adaptation of which Mark’s last set of posts shows clearly (where most, certainly I agree) that blues fall outside ProPhoto RGB but no, the gamut isn’t larger. Big difference!
-
Digital Dog,
We are running in circles. I think we should now move forward to the implications of not using chromatic adaption.
However, I am putting the terminology as used by me here so that there is no confusion.
Adobe RGB (1998) = Adobe RGB (D65).
Adobe RGB (1998) w/ D50 white point = Adobe RGB (D50)
Prophoto RGB = Prophoto RGB (D50).
Hope that helps.
Now lets move on.
Sincerely,
Joofa
-
I've made an AdobeRGB profile in Photoshop adapted to D50 based Br. Lindblooms adapted values.
This is slightly larger than the regular D65 profile.
I just don't know whether or not Photoshop is the appropriate tool ...
-
Now lets move on.
Sincerely,
Joofa
I can't move on until you tell me what a color is!
-
I can't move on until you tell me what a color is!
How can he tell you what he doesn't know?
-
In ColorThink Pro Adobe RGB (1998) has a reported Gamut volume of 1,207,520. Adobe RGB with a D50 WP (JoofaRGB) has a reported Gamut volume of 1,224,250.
My comment is so what.
Note that these calculations don’t have any way (nor need) to specify a rendering intent.
Neither have a gamut volume close to ProPhoto RGB but I suspect everyone here from post #1 realizes this.
-
How can he tell you what he doesn't know?
I'm getting that impression ...
It is an important point. To say a "color" is not in a color space without being able or willing to define it ... is ... just pure sophistry.
-
Neither have a gamut volume close to ProPhoto RGB but I suspect everyone here from post #1 realizes this.
That was never the issue.
Joofa
-
Adobe RGB with a D50 WP (JoofaRGB)
Please think carefully, as this JoofaRGB is the space you have been seeing in all the gamut tools that you have mentioned! I informed you of that multiple times.
Joofa
-
That was never the issue.
It wasn’t after you cleaned up this language:
It does not seem like that Prophoto RGB is always wider than Adobe RGB
-
I can't move on until you tell me what a color is!
What do you think a color is?
-
Please think carefully, as this JoofaRGB is the space you have been seeing in all the gamut tools that you have mentioned! I informed you of that multiple times.
That was never an issue. At least once we got past the idea that Adobe RGB (1998) is Adobe RGB (1998) based on its three unique and specified units that define that color space! That was after more language munging on your part.
-
It wasn’t after you cleaned up this language:
It was pointed out to you from the very start. Please see below:
Digitaldog,
I am not claiming that the volume of Adobe RGB is bigger than Propphoto RGB. Just that Adobe RGB does not seem to be fully contained in Prophoto, while still apparently being smaller than ProPhoto RGB in volume.
Joofa
Sincerely,
Joofa
-
That was never an issue. At least once we got past the idea that Adobe RGB (1998) is Adobe RGB (1998) based on its three unique and specified units that define that color space! That was after more language munging on your part.
What are those 3 unique and specified units?
Joofa
-
What do you think a color is?
That's not the point ... YOU are making the claims about colors ... I'm trying to interpret them.
If you cannot (or will not) define YOUR terms ... this is simply an exercise is sophist mathsterbation.
-
I've made an AdobeRGB profile in Photoshop adapted to D50 based Br. Lindblooms adapted values.
This is slightly larger than the regular D65 profile.
I just don't know whether or not Photoshop is the appropriate tool ...
I've thought about what one would do to make a joofaspace profile—I'm curious about what you put into the profile you made. The Adobe98 profile that I have already uses the D50-adapted primaries. What primaries did you use in the home-made version? Do they both have same primaries?
My .icc profile which I assume is standard has: R[.610, .311, .019] G[.205, .626, .061] B[.149, .063, .745]
-
It was pointed out to you from the very start. Please see below:
Joofa
Again you are wrong and using sloppy language. From the start? The post I quoted that you made (#5) was dated December 31, 2010, 09:25:44 AM. Now you bring this up, 3 days later (and god knows how many posts):
Quote from: joofa on January 02, 2011, 11:20:06 AM
Digitaldog,
I am not claiming that the volume of Adobe RGB is bigger than Propphoto RGB. Just that Adobe RGB does not seem to be fully contained in Prophoto, while still apparently being smaller than ProPhoto RGB in volume.
Joofa
The main issue so many of us have with you is you don’t genuinely seem to be making an effort to communicate very well. Either totally disregarding questions or providing proof of concept, or just being insulting. Your argument would be easier to accept, well at least analyzed if you wrote more clearly and stopped moving the goal posts during the game!
We’ve gone from you initially saying: It does not seem like that Prophoto RGB is always wider than Adobe RGB. We have to assume you are talking about the gamut here, not someone’s hips!
Then you move onto bastardizing Adobe RGB (1998)’s native white point taking us into another direction.
Then we finally see its not so much bastardizing as ignoring how the WP’s map with these profiles in every application known to man and dog (unless can tell us otherwise, a question still not addressed after frequent requests).
What are those 3 unique and specified units?
Primaries, WP and TRC Gamma. I told you about this way back when, using Photoshop’s Custom RGB Working space dialog to see this and alter it.
-
Digital Dog,
I don't think we are moving forward. Unless you make an attempt I am not going to reply to "running in a circle" situation. I can only take a horse to water but not make it drink. I think I have made enough arguments to support what I have said. Those who understood it got it.
The argument is now becoming counter productive. If I see a post from somebody that needs my clarification then I will step in. Otherwise, have a nice time and enjoy the ride.
Sincerely,
Joofa
-
Digital Dog,
I don't think we are moving forward.
Based on your history of writings here, I so agree! Its interesting to note how like so many of the posts here, when you are shown a record of your activity and actions towards others, you just want to take your toys out of the sandbox and go home. Its telling.
-
I've thought about what one would do to make a joofaspace profile—I'm curious about what you put into the profile you made. The Adobe98 profile that I have already uses the D50-adapted primaries. What primaries did you use in the home-made version? Do they both have same primaries?
My .icc profile which I assume is standard has: R[.610, .311, .019] G[.205, .626, .061] B[.149, .063, .745]
Well, these are the primaries adapted to D50 by BL:
R 0.648431 0.330856 0.311114 G 0.230154 0.701572 0.625662 B 0.155886 0.066044 0.063224
(see: http://brucelindbloom.com/WorkingSpaceInfo.html#AdaptedPrimaries )
In Photoshop's tool you can only use x and y but not Y. Therefore struck through above.
This is why I am not sure whether the profile is correct.
But as it matches the regular AdobeRGB profile in the grapher above (relcol) and also matches an Adobe-RGB-spectrum converted (relcol) to ProPhoto (see attachment) ... I would guess it's okay. At least okay for comparision purposes... as a profile it is probably not useable as it lacks too many profile tags (it's obviosuly the most rudimentary form of a profile).
Attached also the primaries of AdobeRGB 1998 and adapted to D50 in Photoshops tool.
edit: the slight difference in gamut volume here: http://www.luminous-landscape.com/forum/index.php?action=dlattach;topic=49940.0;attach=35571;image ...
is obviously due to the rounded numbers to four decimal places.
-
Thanks tho_mas,
I've never played with the custom profile setting in photoshop. It's interesting that it wants chromaticity coordinates instead of XYZ coordinates. Thanks for posting the image.
-
It's interesting that it wants chromaticity coordinates instead of XYZ coordinates.
aren't these automatically calculated based on the chromacity values offset with the white point?
seems so... Color Think provides the XYZ coordinates of the profile ...
-
aren't these automatically calculated based on the chromacity values offset with the white point?
That's not my understanding. Chromaticity coordinates are a 2D projection from the 3D XYZ space onto the unit triangle. They are not dependent on the white point.
The calculation normally given is:
x = X/(X+Y+Z)
y = Y/(X+Y+Z)
z = Z/(X+Y+Z)
(The CIE loved the letters x y and z for some reason)
This guarantees that x + y + z = 1 which makes one of the variables dependent on the other two. e.i. if you don't know z you can calculate it from x and y: z = 1-x-y So z is normally ignored.
You can take an ZYX coordinate like the blue primary: 0.1881852, 0.0752741, 0.9911085
and from it calculate the chromaticity coordinate: 0.0600 0.790 (rounded).
Edit:
I didn't see the images you uploaded. I'm not sure how PS goes about calculating the XYZ coordinates the colorthink shows. I would be interested to know.
-
That's not my understanding. Chromaticity coordinates are a 2D projection from the 3D XYZ space onto the unit triangle. They are not dependent on the white point.
The calculation normally given is:
x = X/(X+Y+Z)
y = Y/(X+Y+Z)
z = Z/(X+Y+Z)
(The CIE loved the letters x y and z for some reason)
This guarantees that x + y + z = 1 which makes one of the variables dependent on the other two. e.i. if you don't know z you can calculate it from x and y: z = 1-x-y So z is normally ignored.
You can take an ZYX coordinate like the blue primary: 0.1881852, 0.0752741, 0.9911085
and from it calculate the chromaticity coordinate: 0.0600 0.790 (rounded).
phew... that is the part that always esacpes me as a "user" :-)
However, thanks for the explanation!
Joofa.. after this long thread and in particular Mark's clear description of adaption 2 or 3 pages above... would you still phrase the following quotes in the same way?
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412938#msg412938
The reason Adobe RGB (50) can be contained is that because it has been chormatic-adaptation-transformed from Adobe RGB (D65), and this process has already stripped that offending blue Adobe RGB (D65) primary. After Bradford transformation Adobe RGB (D50) gets a new blue primary.
http://www.luminous-landscape.com/forum/index.php?topic=49940.msg412945#msg412945
Mark, I thought you were beginning to understand this process, but it seems you are derailing again. Grin The intent was to show that in linear transformations akin to absolute colorimetry, Adobe RGB (D65) contains saturated blue colors that have no representation in Adobe RGB (D50) or Prophoto RGB (D50).
-
Edit:
I didn't see the images you uploaded. I'm not sure how PS goes about calculating the XYZ coordinates the colorthink shows. I would be interested to know.
honestly... I have no idea! But they are there...
Obviously the little matrix of Photoshops tool provides anything that is needed...?!
-
Joofa.. after this long thread and in particular Mark's clear description of adaption 2 or 3 pages above... would you still phrase the following quotes in the same way?
Hi Tho_mas,
The issue is that it appears that some people have interpreted Mark's illustration to be the same/similar as mine. Perhaps because it seems to suggest that blue's are out of gamut as has been my basic premise from the start of this thread. However, I believe that Mark's illustration is incorrect. This is not how color spaces are "stitched" together. Actually, it is dangerous to think this is how the process work.
I still stand by all of my findings as reported here. So the two comments that you quoted from me stay unchanged.
Sincerely,
Joofa
-
The issue is that it appears that many people have interpreted Mark's illustration to be the same/similar as mine. Perhaps because it seems to suggest that blue's are out of gamut as has been my basic premise from the start of this thread. However, one must realize that Mark's illustration is incorrect. This is not how color spaces are "stitched" together. Actually, it is dangerous to think this is how the process work.
I still stand by all of my findings as reported here. So the two comments that you quoted from me stay unchanged.
You keep saying stuff like that Joofa, which is why this thread keeps getting derailed. Despite all the rancor in this discussion, I really am sincerely interested in knowing if and how I'm doing something incorrect. Since you refuse to explain even basic, fundamental aspects of your plot, we have no idea how to interpret it. I've tried several times to explain how I understand it, only to be told I am naively setting myself up for embarrassment without further explanation.
My plot might be completely wrong, sure. I think it agrees quite closely with Lindblooms grapher if you scroll down the page here: http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html (plotting the two profiles in XYZ looks the same to me). I understand the limitations of visualizing in ZYX space, but that doesn't seem to be what you are saying.
You are simply saying I am incorrect. Full stop. No explanation.
-
The issue is that it appears that many people have interpreted Mark's illustration to be the same/similar as mine.
I am not talking about the graph (but it tells something that you do).
one must realize that Mark's illustration is incorrect
so be it
I still stand by all of my findings as reported here. So the two comments that you quoted from me stay unchanged.
the question was whether you would phrase them in the same way. Do you think it's a good wording?
especially this one:
Adobe RGB (D65) contains saturated blue colors that have no representation in Adobe RGB (D50) or Prophoto RGB (D50)
AdobeRGB contains saturated blues that have a visuell representation in ProPhoto ... AdobeRGB get's a new primary in D50 SO THAT the blue colour looks the same (under changed lighting conditions). The colour is the same... only the coordinates of this same colour are different.
-
the question was whether you would phrase them in the same way. Do you think it's a good wording?
Oh okay, I see, what you are saying. Sorry, for not understanding it first. I think Mark is headed in the right direction with the wording he used. I have to reread Mark's words again, but what I remember, I don't see an inherent contradiction in the process of adaption he has described and my two quotes you used above. I think Mark's intuition is right I just disagree with certain aspects of the physical process of color spaces.
I think it is a good start by Mark. If you notice this is quite similar to the process of adaption described in the pdf that Peter (DPL) quoted a while back. I have thought along the same lines for sometime and that is how I produced the numbers and my plot. So the bottom line is that I agree with Mark's thought but not the physics engineering ;D behind it.
Sincerely,
Joofa
-
I think Mark is headed in the right direction with the wording he used.
cool!
I have to reread Mark's words again, but what I remember, I don't see an inherent contradiction in the process of adaption he has described and my two quotes you used above.
the problem is the word "colour".
When we agree that AdobeRGB's blue has an (adapted) visuell representation in ProPhoto... then we can look at the issues Iliah brought up.
Multiple whitepoints in a scene, rendering intends when proofing etc.
-
Saw this linked today:
http://www.inventoland.net/imaging/uc/slides.pdf
Was posted on http://www.mostlycolor.ch/
-
And here is a related article to the slides above, which includes text describing some of Giordano's slides:
http://www.hpl.hp.com/techreports/2008/HPL-2008-109.pdf (http://www.hpl.hp.com/techreports/2008/HPL-2008-109.pdf)
Dave