Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Tim Lookingbill on November 12, 2011, 05:49:12 pm
-
I've had it with these color shifts converting from ProPhotoRGB to sRGB in certain blues, oranges and yellows. I used to think it was gamut clipping, but I've stumbled upon a clue that may indicate otherwise.
That clue was found in one image that had a particular hue of green ivy I shot in Raw that shifted hue noticeably when switching from i1Display system profile to a eyeball created SuperCal version for Snow Leopard.
Another clue showed up when I converted 255 ProPhotoRGB purities to sRGB and DIDN'T get a color shift using the SuperCal profile like I did with the i1Display. Other color targets (i.e. PDI, Kodak, etc) viewed never noticeably shifted in color switching back and forth between the two display profiles in the system. Photoshop updated the previews without a hitch.
It's just I've been trusting the infallibility of hardware calibration as being the most accurate and consistent until I saw these shifts with this green ivy image and the RGB purities fix switching to the SuperCal profile. To check which hue of green was correct I printed the image in question and get a better match using the SuperCal profile. The majority of other colors match using either display profile.
Is i1Match 3.6.3 the issue or is it a combination of both my aging colorimeter and software calibrating and profiling my sRGB-ish Dell 2209WA?
Below are shots I took of these color shifts switching between profiles in the system and a print sample to show which is close to a match.
-
Whats rendering intent are you using? Relative or Perceptual?
-
Thanks for the reply, John.
This isn't about the print. The print is not the problem. I have no problems with print matching on a wide range of colors from a wide range of images. It's just the colors I've mentioned above.
What I'm trying to find out about is how to know if a calibration software is rendering ALL colors as intended and when it doesn't if it has to do with the aging of the hardware and the software not picking up on it. I shouldn't be getting color shifts in 255 RGB purity primaries created in ProPhotoRGB and converted to sRGB on an sRGB gamut display.
How do you explain the SuperCal display profile not doing this but the i1Display profile is? I've had this problem going back to my first LCD on a 2004 G5 iMac using the i1Display/i1Match package. I even checked this color shifting during a conversion with others in online discussions using newer i1Display 2 profiles and higher quality NEC displays in Mac OS and some see this and others don't.
Even Andrew Rodney mentioned not getting a shift in one of many discussions on this. No one could explain the cause so I just assumed this was gamut clipping. Now I think it's due to the way the profile is written by Xrite not quite integrating well between the way Photoshop works with Apple's video API that influence color managed previews.
I even compared the CMYK readouts to a process color manual to check the way this particular green is suppose to render whether it looks like a cooked green as you see in the print or a fresher cyan heavy magenta reduced green as it appears with i1Display profile rendering.
I've been reading Ethan Hansen's Delta E number evaluations of quite a few hardware calibration packages in another long thread and I believe this is an i1Display/i1Match issue.
-
There's another clue that may point to an Apple API issue when I talked to SuperCaL creator Brock Brandenburg about updating SuperCal to work with Snow Leopard. I noticed his display profiles on the G5 iMac now included correct looking colors compared to the i1Display.
I asked him what he fixed and he said nothing and that Apple fixed it in their video/graphics API. In fact Brock no longer needed to use an expensive piece of software to do the XYZ transform interpretations because of this fix by Apple. He says he uses the colorants measured and written into the display's EDID at the factory which use far more expensive (precise?) instruments in coming up with their numbers.
You see before this, I gave up on eyeball calibrators because they couldn't get the XYZ chromatic adaptation transforms correct that color managed apps use to control hue/saturation in tagged previews, so I bought the i1Display for Mac OS 9 for an sRGB CRT and then updated the i1Match software for Mac OS X on the G5 iMac for Tiger. Even on the CRT I'ld get slight shifts converting to sRGB but never gave it much thought. It's now getting even more pronounced with the Dell 2209WA in Snow Leopard. I'm never sure what's the cause and neither does anyone else I've talked to about it.
I wish Ethan Hansen would do a Delta E comparison including SuperCal's results to the hardware calibrators.
Brock also mentioned he's waiting for the OK from Apple to include his SuperCal in Apple's App Store.
-
How do you explain the SuperCal display profile not doing this but the i1Display profile is?
Even Andrew Rodney mentioned not getting a shift in one of many discussions on this.
The display profile has zero effect on these conversions if I’m understanding you. Easy to test. The color appearance after a conversion of course is based on the two profiles. Why one shows a difference I can’t say, I see no such effects as you mention using the tools at hand. Might want to contact X-Rite, send them the display profile.
I wish Ethan Hansen would do a Delta E comparison including SuperCal's results to the hardware calibrators.
Be kind of pointless for all the reasons one should never use eyeball calibration (we’ve been over this). Consistency in measuring then building a profile is kind of important.
-
Andrew, I find it odd that you sound authoritative in one area of this and clueless in another.
Why would you suspect an Xrite issue when others aren't experiencing it?
I already know the reasons for the use of hardware calibration but you never seem to know how to fix or know why when something goes wrong or be able to explain with authority why Ethan finds so many colorimeter packages vary from model to model and brand to brand in Delta E numbers.
We're suppose to trust the hardware, but we're using software to evaluate what the hardware delivers. There's something off in that logic, but I can't put my finger on it. Wish I was an authority on the matter, but I just plunk down my money and hope for the best.
Know one ever explains why when I recalibrate with the i1Display after a year on the G5 iMac why I'ld never get a pronounced difference between the before and after calibration and in color managed previews. Kind of goes against that consistency claim, don't you think, Andrew?
-
I just contacted Xrite through their Support Services site page. I included the URL to this thread.
I'll report back what response I get.
-
Andrew, I find it odd that you sound authoritative in one area of this and clueless in another.
Why would you suspect an Xrite issue when others aren't experiencing it?
You’d have to ask X-Rite unless you expect folks here (myself excluded) to trouble shoot your system. Of you could try a different product. Bottom line is, you have some issue you have to figure out).
I already know the reasons for the use of hardware calibration but you never seem to know how to fix or know why when something goes wrong or be able to explain with authority why Ethan finds so many colorimeter packages vary from model to model and brand to brand in Delta E numbers.
Well for one, the reason X-Rite just recently implemented what they hope to be a standard in how measuring devices from differing companies can better correlate (XRGA), at this point its aimed at reflective measurement but presumably one could expect some differences in emissive measurements from differing vendors. I suspect there are additional reasons too.
We're suppose to trust the hardware, but we're using software to evaluate what the hardware delivers.
Trust more than our eyes? Yes. But the wrist watch on my arm and the Atomic clock in Bolder probably don’t perfectly correlate, are they the equivalent of a few dE off? Could be. We’re splitting hairs compared to trying to figure out the time using a sundial or either devices that provide a time measurement. Whatever instruments at whatever cost Ethan or others use, somewhere, someone has a higher grade reference device that may not proved the same exact values to a point.
Wish I was an authority on the matter, but I just plunk down my money and hope for the best.
What’s your budget? Can you afford the atomic clock of spectroradiometers? Or you’ll settle for a huey versus the EyeOne Display Pro?
Know one ever explains why when I recalibrate with the i1Display after a year on the G5 iMac why I'ld never get a pronounced difference between the before and after calibration and in color managed previews.
You are evaluating this using what measurement process on what and how many colors?
-
You are evaluating this using what measurement process on what and how many colors?
Well for now this green ivy (which one's correct?...i1Displays? or SuperCal's?) and the 255RGB cobalt blue purity conversion shift to sRGB among other saturated colors using the i1Display. I'm taking one color at a time among 16 million which I don't think has been measured by any device. At least I haven't found any accurate and consistent data on the subject.
Your sundial analogy doesn't help anyone understand or help insure total trust in hardware calibration with all the variances discussed online for at least the past ten years by different users including myself and taking into account Ethan's data.
All I'm doing is being honest and open with my findings and providing a more clearer picture in pointing out ALL the holes in this technology that I don't think anyone's aware of.
And I'm not saying it's all Xrite's fault. I think it's a coordination issue between color managed apps, OS system graphics and the calibration package.
-
Your sundial analogy doesn't help anyone understand or help insure total trust in hardware calibration with all the variances discussed online for at least the past ten years by different users including myself and taking into account Ethan's data.
Thanks for commenting for everyone...
If you want total trust (whatever that means), I think you’ll always be disappointed in any degree of error (measuring or otherwise). There is a reason we humans depend on measurements and measurement devices, be it a ruler, a watch, or a Spectrophotometer albeit not totally trustworthy instead of using our senses alone.
All I'm doing is being honest and open with my findings and providing a more clearer picture in pointing out ALL the holes in this technology that I don't think anyone's aware of.
There’s lots and lots of holes in the CMS technology if you consider the basis which was produced before anyone knew what a computer is, let alone an ICC profile. There are technology holes in automobiles but we use them instead of horse and buggy.
And I'm not saying it's all Xrite's fault. I think it's a coordination issue between color managed apps, OS system graphics and the calibration package.
That’s probably true. But you’ll have to figure this one out yourself unless you believe it can be done remotely and by others. Its an odd issue but certainly a rare one. Maybe you can find someone else with the same issue and narrow down the cause. Most of us are not experience this or if most are, they are not reporting it. I suspect the former.
-
Maybe I'm being dense but doesn't any conversion involving a gamut mismatch (which would almost certainly be the case going from proPhoto to sRGB) involve selecting a rendering intent? I was curious which you were using, and if you possibly tried an alternative ....
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
-
Maybe you can find someone else with the same issue and narrow down the cause. Most of us are not experience this or if most are, they are not reporting it. I suspect the former.
Where were you in all the discussions over at Photo.net, here at LuLa and a few Adobe CM forums I KNOW for a fact you participated in years past where the poster complained about blues turn purple in color managed apps? or did you forget?
I didn't ask for an argument here, just solutions.
I suspect but can't confirm that this may have something to do with how sensitive an ICC color managed code driven graphic system is to slight errors in either or both code and/or transform calculation that's not noticeable on a wide range of colors but only on specific ones that are affected by just one number or misplaced character written into the profile. This could explain why some have issues where others don't.
For instance I noticed when entering X,Y numbers in i1Display's custom color temp adjust that changes the color cast ever so slightly that there are thresholds that at first offer smooth changes and then abruptly jump with just one number change.
This could be the nature of computers and video processors. Just throwing it out there.
-
Maybe I'm being dense but doesn't any conversion involving a gamut mismatch (which would almost certainly be the case going from proPhoto to sRGB) involve selecting a rendering intent? I was curious which you were using, and if you possibly tried an alternative ....
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
We're discussing matrix based synthetic color space profiles (i.e. ProPhotoRGB>sRGB) which don't have any other rendering intent tables except Relative Colorimetric.
-
Let me be clear, John, so you don't misunderstand what's being discusssed.
The shift in luminance/hue in 255 cobalt blue converting from ProPhotoRGB to sRGB shown in my sample image is not suppose to happen as confirmed by Andrew.
I used to think/assume this WAS suppose to happen as "Gamut Clipping" since it started doing this when I first used the i1Display profiles. Before that I was using eyeball calibrators that didn't exhibit this behavior in a conversion but who's colors weren't accurate overall, so I assumed this was part of the accuracy of using a hardware calibrator.
Andrew and others confirmed this didn't happen on their hardware calibrated displays while some did confirm this DID HAPPEN including a professional retoucher for the fashion industry by the name of Patrick Lavoie over at Photo.net.
The green differences don't happen in a conversion, only when loading "in the system" one display profile over the other and having the color managed preview shift the greens as demonstrated.
-
This could be the nature of computers and video processors. Just throwing it out there.
Just wondering if they've broken their levels of precision on floating point numbers which may be causing errors to accumulate over the course of processing? If a programmer is playing a bit loose on accuracy over multiple calculations that can cause noticeable errors over time or on outlier calculations. (Try doing multiple rotates on 3D objects with successive output co-ordinates instead of from the original co-ordinates, you can literally see the errors build up quite rapidly).
-
I already know the reasons for the use of hardware calibration but you never seem to know how to fix or know why when something goes wrong or be able to explain with authority why Ethan finds so many colorimeter packages vary from model to model and brand to brand in Delta E numbers.
Much of the variation we see is due to a combination of manufacturing inconsistency and lack of unit-by-unit calibration. For example, one of the best legacy sensors is the X-Rite DTP-94. It is hopeless on LED backlight or wide gamut dispalys, but on standard gamut CCFL models the manufacturing tolerances were sufficiently tight that the DTP-94 outperformed most other devices. DataColor appears to have made a silent upgrade to their Spyder3 colorimeters a year or so ago. They still vary more unit-to-unit that one would like, but not as badly as the initial units. The i1D2 could be individually calibrated - stock from X-Rite it wasn't - but that only masked some of the large variations between units.
Both of the newest sensors, the BasICColor Discus and X-Rite i1Display Pro, are constructed from the ground up to provide stable measurements. Both pucks are also individually spectrally calibrated before shipping.
As to why different monitor calibration products can create hue shifts when displaying blues or converting from PP RGB blue to sRGB blue, that depends on how they render colors that are not only out-of-gamut, but mathematical fictions in a real-world monitor color space. All the PP RGB primaries are imaginary colors; i.e. they do not correlate to any physical color that can actually be created. Needless to say, your monitor can't display these colors accurately. In fact, almost 15% of ProPhoto RGB colors do not map to physical, real-world colors.
The sRGB blue primary is not an imaginary number, but does fall outside the gamut of most monitors, even wide-gamut models. I have no experience with SuperCal. It is very possible that it simply maps working space primary colors to the monitor primaries. This is neither mathematically nor visually accurate, but it will prevent color shifting when converting primaries between color spaces with vastly different gamut volumes. A pertinent question is: does this matter? After all, you will never encounter a PP RGB blue primary in the wild and the chances of finding even a pure sRGB blue are vanishingly rare. Graphic illustrations are another matter entirely. Spot colors is one of the reasons Adobe sells Illustrator to complement Photoshop.
-
Thanks for the reply and explanation, Ethan.
Unfortunately it doesn't help. I get color shifts not just in 255RGB purities. It's in other colors like in flowers. Also I get the same shifts converting to AdobeRGB. I expect any color space I edit in on a hardware calibrated sRGB monitor to give me all its colors that that display is capable of reproducing and faithfully render them converting to sRGB which is the gamut of my monitor.
Maybe you disagree and/or see me as just being naive about this. I don't like gorgeous yellow, orange and blue flowers I've painstakingly edited to look as intended in ProPhotoRGB taking a hit in hue/saturation converting to the same gamut of my monitor (sRGB) which by the way doesn't happen when I convert to my i1Display profile monitor space. Go figure!
From emails with Xrite's support I finally fixed the green ivy error but it points to a limitation on the part of i1Match and the colorimeter's measurement of my displays native WP which reads it at 6900K which looks a greenish cream which my eyes adapt to seeing as neutral but i1Match expects (has calculated/tuned for) 6500K.
So for better calculations i1Match requires I choose Target 6500K which makes the entire display color cast shift to pinkish blue to get the software to write the proper 6500K XY numbers into the final profile. Of course my eyes eventually adapt to seeing this pinkish blue as neutral but now I've lost some of my 255 levels forcing this color cast correction through the video card.
This is what I have to do to prevent the color transform error showing up in color managed previews (as in the green ivy so far) which has been an age old issue with eyeball calibrators (including SuperCaL) going back years before Apple changed their video API's to correct for this in SuperCal according to what Brock told me. Brock's calculated transforms in the past gave far worse results over a broader range of colors. Now they don't.
What I take from this is that there's a lot of interpretation by hardware vendors as to what WP should look like and the XY number assigned to it to prevent color errors of this sort. See below what looks to me as interpretation over accuracy.
BTW, this Target 6500K WP didn't fix the color shift issue of saturated colors converting to sRGB. Also Xrite support said their i1Display and i1Match are performing as "designed" (interpreted?) And that I should consider purchasing their newer i1Display Pro for what I'm guessing is a better or alternative interpretation.
-
Oh, I forgot to add.
The additional gotcha' on my using i1Match's Target 6500K WP, which my eyes eventually adapt to seeing as neutral, now cause my GE 5000K Sunshine fluorescent lighting next to my display which used to make my white walls appear a reddish yellow to now show a severe green cast after adapting to this pinkish blue Target 6500K.
Prints still appear to match though between using either WP calibrated settings.
-
... now cause my GE 5000K Sunshine fluorescent lighting
It's worth noting that fluorescent lighting is not the most reliable when it comes to critical viewing. The problem with them is that they have HUGE spikes and dips. Even though the bulb might measure a color temp of 5000ºK, it's still going to be limited by the properties of the technology, and as such prone to issues with color casts and metamerism. I don't find it at all surprising that you'd see a cast with a fluorescent bulb. It's the nature of the beast.
Cheers, Joe
-
I've had it with these color shifts converting from ProPhotoRGB to sRGB in certain blues, oranges and yellows. I used to think it was gamut clipping, but I've stumbled upon a clue that may indicate otherwise.
Whats rendering intent are you using? Relative or Perceptual?
Unfortunately, perceptual rendering is not available for Version 3 matrix profiles such as sRGB and ProPhotoRGB. Photoshop does allow one to select perceptual rendering, but the request is ignored and relative colorimetric rendering is performed. The matrix profiles lack the necessary look up tables for perceptual rendering.
Regards,
Bill
-
Joe, I'm aware of fluorescent light's spiky spectra. This is not the problem. There are fluorescent lights on the market that are used quite successfully for proofing prints. Normlicht viewing booth to name one which I believe Andrew uses.
The pinkish blue appearance is not an intended nor is it healthy for eyes or a desired look to edit images on a display with. I tried it.
The i1Match software does not neutralize the rest of the gray tonal scale effectively enough to over ride the eye's adaptive characteristics into NOT seeing the pinkish blue white. Besides that there is no light source in the natural world or artificial that looks this pinkish blue. This is an error (or interpretation) by X-rite and/or Apple's integration of software driven WP appearance downloaded to the video driver. From using Apple's Calibration Utility WP slider adjust, Apple has other ideas on what 6500K should look like as well.
It doesn't matter anyway because I got the i1Match software to measure my Dell's WP at 6600K by adjusting the Dell's RGB gains which of course creates a slightly warm orangish yellow tint. How do you explain that huge jump in interpreting the color cast using the same colorimeter. According to Xrite looks like 6500K could look either pinkish blue or orangish yellow. So much for accurate colorimeters.
This guy was having even worse problems getting accurate native WP readings with his i1Display2/i1Match colorimeter system...
http://forums.dpreview.com/forums/readflat.asp?forum=1004&message=34268372&changemode=1
Reading on to the second page of that thread tells the solution which was to buy another i1Display 2 package. He should've been reimbursed by Xrite which I'm assuming he was.
-
Unfortunately, perceptual rendering is not available for Version 3 matrix profiles such as sRGB and ProPhotoRGB. Photoshop does allow one to select perceptual rendering, but the request is ignored and relative colorimetric rendering is performed. The matrix profiles lack the necessary look up tables for perceptual rendering.
Regards,
Bill
Hi Bill, glad I could get some input from you on this. I've discovered some other very odd behaviors with Apple's CMM driven rendering intents in Photoshop with matrix based/rendering intent limited profile conversions I wasn't aware of before.
I got to tinkering around creating a Lab Color space gradient in Photoshop CS3 to check banding with my newly made 6600K i1Display profile loaded in the system versus SuperCal's version loaded. Of course I get banding using both and noticeably different shaped 3D gamut models viewed in Colorsync utility, but that wasn't the only odd anomaly. See the attached screenshots below.
I always suspected Apple has issues with there CMM in regards to how they influence these rendering intents in Photoshop and is probably the reasons for the slight color shifts I get in highly saturated colors converting from ProPhotoRGB to sRGB even if I don't use Apple's CMM conversion engine.
The first shot is having the i1Display profile loaded in the system and choosing Apple's CMM/Absolute Colorimetric rendering intent to convert to the loaded i1Display profile. No problems to preview. The i1Display profile has a Chromatic Adaption 'chad' ICC tag in its construct and a White Point Media Tristimulus 'wtpt' tag stated at D50. This profile was built from measuring my Dell's native WP after adjusting OSD RGB gains to get the colorimeter to read 6600K.
The second screenshot is having the SuperCal version loaded in the system and converting to it. This profile actually ends up as a simplified matrix formula profile that's read by Photoshop in "CustomRGB..." as straight HDTV Rec 709 XY coordinates including 6500K WP. It doesn't have a 'chad' tag and its 'wtpt' tag is stated at 6500K, not D50 like the i1Display's.
You'll see that Apple CMM still utilizes or deals with WP mapping in odd ways. It does this converting from D50 source space to any 6500K color space, not just my display profiles.
All this still happens even in Snow Leopard on a 2010 Mac Mini.
-
Correction, it doesn't matter what display profile is loaded in the system. If I convert from D50 Lab space to i1Display 6600K profile using Apple CMM/Absolute Colorimetric it doesn't show the orangish yellow cast.
However if I convert to SuperCAL's or AppleRGB or AdobeRGB or any other simple matrix 6500K WP profile it does show this cast.