Pages: [1] 2   Go Down

Author Topic: Color Errors? Gamut Clipping?...Or is i1Match 3.6.3 for Snow Leopard too old?  (Read 8142 times)

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.
 
Logged

John.Murray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 886
    • Images by Murray

Whats rendering intent are you using?  Relative or Perceptual?
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.
« Last Edit: November 13, 2011, 12:37:00 pm by tlooknbill »
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.
« Last Edit: November 13, 2011, 12:32:15 pm by tlooknbill »
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/

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.

Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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?
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/

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).

Quote
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.

Quote
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.

Quote
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?

Quote
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?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

Quote
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.
« Last Edit: November 13, 2011, 02:20:15 pm by tlooknbill »
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/

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.

Quote
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.

Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

John.Murray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 886
    • Images by Murray

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
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

Quote
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.
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.
« Last Edit: November 13, 2011, 05:29:49 pm by tlooknbill »
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.

« Last Edit: November 13, 2011, 06:06:21 pm by tlooknbill »
Logged

PhilipCummins

  • Full Member
  • ***
  • Offline Offline
  • Posts: 133

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).
Logged

Ethan_Hansen

  • Full Member
  • ***
  • Offline Offline
  • Posts: 114
    • Dry Creek Photo

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.

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.

« Last Edit: November 14, 2011, 06:10:01 pm by tlooknbill »
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436

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.

Logged

shewhorn

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 537
    • http://

... 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
Logged

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387

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
Logged
Pages: [1] 2   Go Up