Some Questions related to 3D view

CHROMiX ColorThink
1

Hi,

I use at normal the 3D view Lab. One Question is, what I need to do to rotate the Lab scale, so it is related to D65 whitepoint.
The I tried to view a conversion of an Image as Vectors from on colorspace (D65) to another Colorspace (D50). I didnt saw the difference between rel / abs colormetric, which should be related to the angle from black to white (L scale). Is there an option to view this ?
The current Stable version crash when I open the 3D view or 2D view, I use OSX Tiger latest on dual G5. Currently I use therefore the beta. Will there be a stable version later with a fix on this problem ?

kind regards,

Kristian Kratzenstein

2

At 1:49 AM -0800 11/8/05, Kratzy974 wrote:

Hi,

I use at normal the 3D view Lab. One Question is, what I need to do to rotate the Lab scale, so it is related to D65 whitepoint.
The I tried to view a conversion of an Image as Vectors from on colorspace (D65) to another Colorspace (D50). I didnt saw the difference between rel / abs colormetric, which should be related to the angle from black to white (L scale). Is there an option to view this ?

In the current version of ColorThink all graphing is done in D50 Lab. That said, D65 Lab colors will also plot adapted to D50 - meaning that they also have 100,0,0 as their whitest point which will line up with the D50 100,0,0 when graphing.

If you are referring to plotting display profiles that have D65 white points then you will need to wait until ColorThink Pro is available for the first chance to see this. Subsequent versions of (normal) ColorThink will probably have this capability some time in the future.

If you are referring to using a D65 white-point profile to create vectors then use the relative colorimetric intent and I think you should be OK…

The current Stable version crash when I open the 3D view or 2D view, I use OSX Tiger latest on dual G5. Currently I use therefore the beta. Will there be a stable version later with a fix on this problem ?

Yes, basically, as soon as the current beta settles down we will release it as a final version and then you’ll be set. Sorry for the wait… in the meantime, please use the beta…

Regards,

Steve

o Steve Upton CHROMiX www.chromix.com
o (hueman) 866.CHROMiX

–

Post generated from email list

3

Dear Steve,

Thanks for the answer.
The White of the D65 Spaces are rotated to be viewed in a D50 . So the 100,0,0 value is moved to 100, x, y, where x and y are the difference values between the Colortemperature. Just open a sRGB, and you see what I mean. That is fully correct, and I don’t want to argue against that. But :
The problem with the rel Colormetric calculation is, that if I view an Image (from sRGB) with Whitepoint away from 100,0,0. Then I use rel Colormetric to a D50 space : the grey line isn’t rotated, so the bright values are mapped to the gamut of the D50 colorspace. This looks wrong (also with perceptual…).

kind regards

4

At 1:15 AM -0800 11/10/05, Kratzy974 wrote:

Dear Steve,

Thanks for the answer.
The White of the D65 Spaces are rotated to be viewed in a D50 . So the 100,0,0 value is moved to 100, x, y, where x and y are the difference values between the Colortemperature. Just open a sRGB, and you see what I mean. That is fully correct, and I don’t want to argue against that.

well, this may seem strange as I designed & implemented the behavior but I do have an argument with it.

To begin, there’s some history and logic around this one. In the beginning of time I designed the gamut volume so that it would correspond directly to the measured data that built the profile. So if you graph target measurements with the resulting profile, the target colors match up with the profile volume quite nicely. Cool, makes sense, expected behavior, etc. When it came to monitor and working-space profiles I left ColorThink to behave the same way. What this means is that if the monitor profile has a non-D50 white point it maps to a non 100,0,0 white point in the graph as you described.

While this could be argued to be the correct way to do things there are also arguments against it:

  • 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 exactly what I plan to do in ColorThink Pro and then eventually non-pro ColorThink.

But :
The problem with the rel Colormetric calculation is, that if I view an Image (from sRGB) with Whitepoint away from 100,0,0. Then I use rel Colormetric to a D50 space : the grey line isn’t rotated, so the bright values are mapped to the gamut of the D50 colorspace. This looks wrong (also with perceptual…).

yes, understood. Altering the graphing so that the white points all map to D50 also introduces challenges when rendering individual color and their vectors into Lab for graphing… that’s what I’m working on right now in fact.

It is fair to say that either method could be used. In canvassing many opinions and looking into an ICC v4 future it makes most sense to change the way things are done now. I’m sure it will create some discussion along the way…

Regards,

Steve

o Steve Upton CHROMiX www.chromix.com
o (hueman) 866.CHROMiX

–

Post generated from email list

5

OK Steve, ‘simple’ feature request… :slight_smile:

ColorThink Pro to have a check-box that can optionally be checked, to force CT to plot a gamut with an ‘un-adapted’ white point. Then you’d keep everybody happy.

Regards

Alan

6

Thanks for the answers.

I don’t know ICC4 with all changes currently, but I should do so in next times.

I ll lock forward the next versions of the software.

Kristian

ps : a checkbox to change the behavirt (or something to switch the whitepoint) would be the best. If it’s not so hard to implement.
psps : This forum doesn’t notify me with the first reply after my message, so sorry for the late reply from me.

7

At 5:22 AM -0800 11/28/05, Kratzy974 wrote:

Thanks for the answers.

I don’t know ICC4 with all changes currently, but I should do so in next times.

The most appropriate one in this case is the change in white point encoding. Basically we won’t be seeing any non D50 white points from here on in.

ps : a checkbox to change the behavirt (or something to switch the whitepoint) would be the best. If it’s not so hard to implement.

that’s pretty much how it’s done in ColorThink Pro. There’s a radio button for ‘Device Gamut’ - which chooses rel col for monitor profiles, lining them all up on the L axis - and abs col for print profiles - showing the true white point of the paper. Or you can select the other radio button which allows the selection of any rendering intent including abs col to equal past ColorThink graphing behavior.

psps : This forum doesn’t notify me with the first reply after my message, so sorry for the late reply from me.

sorry about that I’ll look into it. You can also subscribe to the email-portion of the forum and get all emails on the forum (which is how I do it most of the time)

Regards,

Steve

o Steve Upton CHROMiX www.chromix.com
o (hueman) 866.CHROMiX

–

Post generated from email list

8

Hi again,

To the ICC 4 specification : this one is only relevant to the ICC 4 profiles, to best of my knowledge. So all those ICC 2 profiles out there (Adobe 1998 / sRGB) will be there in the future too. That means the D65 whitepoint will be there. I don’t think that those profiles will be gone in near future (sRGB is currently the standard for all devices).
On the other hand, I see a tag, which allowes an adaption from the used whitepoint (whatever, could also be D65) to the D50 (standard in ICC 4), which is just a 3x3 matrix. This would mean : Yes, all is calculated in D50 but there are still profiles in non D50 space (again, to best of my knowledge), which will be adopted by the CMM later.
So I think, the Whitepoint problematic will be here for still some time.

kind regards

9

At 8:10 AM -0800 12/1/05, Kratzy974 wrote:

Hi again,

To the ICC 4 specification : this one is only relevant to the ICC 4 profiles, to best of my knowledge. So all those ICC 2 profiles out there (Adobe 1998 / sRGB) will be there in the future too. That means the D65 whitepoint will be there. I don’t think that those profiles will be gone in near future (sRGB is currently the standard for all devices).

I’m in agreement with you there.

On the other hand, I see a tag, which allowes an adaption from the used whitepoint (whatever, could also be D65) to the D50 (standard in ICC 4), which is just a 3x3 matrix. This would mean : Yes, all is calculated in D50 but there are still profiles in non D50 space (again, to best of my knowledge), which will be adopted by the CMM later.
So I think, the Whitepoint problematic will be here for still some time.

indeed. Whitepoint issues overall are certainly going to continue to cause problems. The main issue here is that the v2 spec was unclear about how to setup the white point in monitor profiles and many companies (including Adobe) created profiles with non-D50 white points. The v4 spec helps nail that down finally. The ‘chad’ tag you mentioned is a reasonable way for the “true” white point of the profile to be documented (in some manner at least) and also supplies the mechanism for the CMM to calculate the true original white-point referenced colors if required.

Regards,

Steve

o Steve Upton CHROMiX www.chromix.com
o (hueman) 866.CHROMiX

–

Post generated from email list