Monitor Calibration D50 or D65 ?
Gernot Hoffmann
Color Management, but nobody seems to be interested
in the question though it愀 IMO essential.
My results and conclusions will be posted later.
The prepress folks likes to calibrate monitors by D50 instead of D65.
They expect that the preview without CMS is nearer to a print under D50.
Now let愀 do a test:
A portrait photo with little saturation and a gray background is
optimized in sRGB using a D65 monitor:
http://www.fho-emden.de/~hoffmann/francine28082003.pdf
We can compare three modes of visualization:
1. D65 Monitor, Photoshop 7.0 or any other program without CMS.
2. D50 Monitor, any program without CMS.
3. D50 Monitor, Photoshop 7.0 with CMS, using the monitor profile.
All monitor profiles are accurate within Gamma=+-0.02 and T=+-50K.
The monitor primaries are "near" to the sRGB primaries (not very
important, because the colors are little saturated).
Which mode shows the best preview with respect to a very accurate
print on a fully calibrated inkjet in a D50 light booth ?
Any guess is possible ...
Best regards --Gernot Hoffmann
Roger Breton
> The prepress folks likes to calibrate monitors by D50 instead of D65.
> They expect that the preview without CMS is nearer to a print under D50.
Well, I don't have hard core statistics on D50 vs D65 in prepress, worldwide
but, personally, D65 is harder for me to use than D50. But that's my humble
opinion, both for general use and in Photoshop 7+ for doing critical color
work.
> Now let愀 do a test:
> A portrait photo with little saturation and a gray background is
> optimized in sRGB using a D65 monitor:
> http://www.fho-emden.de/~hoffmann/francine28082003.pdf
I downloaded and viewed the PDF in Acrobat v6 on my D50 calibrated Mac G4
runing OSX. The skin tone looks 'natural' to me. I understand there must be
a Bradford chromatic adaptation going on between the image RGB data and my
CRT monitor profile through ColorSync. So, I can't really visualize this
image directly in 'native' D65 color space on my CRT -- sorry.
> We can compare three modes of visualization:
>
> 1. D65 Monitor, Photoshop 7.0 or any other program without CMS.
Not my case.
> 2. D50 Monitor, any program without CMS.
Not quite my case.
> 3. D50 Monitor, Photoshop 7.0 with CMS, using the monitor profile.
Can't open up the image, by the way, in Photoshop 7 directly without going
trough the 'Rasterize" dialog box. So I open the image in Acrobat 6 and
instead designate sRGB as my RGB working space -- same concept as in
Photoshop.
> All monitor profiles are accurate within Gamma=+-0.02 and T=+-50K.
My monitor profile is accurate to an average of 1.3 DeltaE, judging by the
GretagMacbeth ColorChecker II.
> The monitor primaries are "near" to the sRGB primaries (not very
> important, because the colors are little saturated).
Yes, the colors seems rather unsaturated but they look quite warmer when
viewed under AdobeRGB.
> Which mode shows the best preview with respect to a very accurate
> print on a fully calibrated inkjet in a D50 light booth ?
You mean, you want me to print the image on my calibrated inkjet printer?
And where do you want to me to view the print? I am still waiting for my
Normlicht tubes to come in from the Canadian distributor...
> Any guess is possible ...
Right, but we should come to some consensus, don't you think?
> Best regards --Gernot Hoffmann
Roger Breton
Gernot Hoffmann
Roger,
thanks for your analysis.
In my understanding a color managed device should reproduce the color
physically correct (a D65 image should be shown on a D50 monitor alike
D65).
Now let愀 see what happens:
1. Monitor D65, Photoshop sRGB or a program without CMS.
Preview is very near to print, though both cannot be compared side
by side (one cannot adapt simultaneously to D50 and D65).
2. D50 monitor, program without CMS.
Preview is too yellow-ish.
3. D50 monitor, PhS 7 with CMS. Working space sRGB. Soft proof=Off.
I had expected that the image preview is converted to D65. This
means
it should look like D65. The idea of CMS: device independent
reproduction
of colors. The surprising result:
The image looks blue-ish and the measured color temperature of the
back-
ground is 5500K instead of 6500K.
Altogether a bad preview.
Soft proof = On with Monitor profile shows the image D50-like - too
warm.
My conclusion: The best method is number 1. No confusion.
Web-compatible
for Windows style, good perceptual match of print with D50 booth and
average room light.
It愀 IMO a fundamental misunderstanding that the image should look
warmer on the monitor (therefore D50) in order to get a better preview
for
the print. D50 on a monitor doesn愒 deliver the same impression as a
D50 surround illumination.
No need to print the doc. I have already done this several times.
Best regards --Gernot Hoffmann
Timo Autiokari
hoff...@fho-emden.de (Gernot Hoffmann) wrote:
>In my understanding a color managed device should reproduce the color
>physically correct (a D65 image should be shown on a D50 monitor alike
>D65).
Aha. That is exactly the correct understanding. So a person with a
system that has a D50 calibrated monitor can see the image similarly
as a person whose system has a monitor that is calibrated to the D65.
But now you have found that Photoshop will not deliver that.
Some time ago I wrote here that Photoshop manages the color
temperature setting of RGB working-spaces incorrectly (it almost does
not manage it at all, the only effects it has is when doing Relative
conversion it controls the Bradford conversion and when using the
Absolute intent it cause way incorrect results.
To experiment:
1) Create a R=G=B step wedge from 0 to 255 and Assign a D65 RGB
color-space to it.
2) Duplicate it and Assign a D50 RGB color-space to that.
So what do we have now:
1) Two files with the very same RGB codes,
2) these files are in quite different color-spaces, one of them is in
the D65 working-space and the other is in the D50 working-space,
3) but they both appear *exactly* the same.
This example shows in a nutshell the bug in the Adobe
Color-Management. In this situation when the RGB codes are the same
the outputs must be different. And if the outputs are the same then
the RGB codes must be different.
But in Photoshop it is not so. It considers the color-temperature of
the RGB working-space as if it was a relative value but it considers
the other two parameters of the RGB working-space (Primaries and
Gamma) as absolute values.
This is quite a serious bug since it affects to all conversions with
Absolute intent. There are now quite many output profiles out there
that try to take this bug into account so vendors are begriming to
adapt to this bug! But Adobe either does not listen or they do not
understand.
It is also very difficult to do colorimetric evaluations with
Photoshop e.g. such like you described. For example the only way to
correctly see an image that is in a D50 RGB working-space is to adjust
the monitor also to D50. And the only way to see correctly an image
that is in a D65 working-space is to adjust the monitor also to D65.
(such adjustment can be quickly done with the 'Color Temperature
Adjusted' -dropdown in AdobeGamma).
Timo Autiokari http://www.aim-dtp.net/
Roger Breton
> Aha. That is exactly the correct understanding. So a person with a
> system that has a D50 calibrated monitor can see the image similarly
> as a person whose system has a monitor that is calibrated to the D65.
Yes, that is the expectation!
> But now you have found that Photoshop will not deliver that.
Oops...
> To experiment:
>
> 1) Create a R=G=B step wedge from 0 to 255 and Assign a D65 RGB
> color-space to it.
> 2) Duplicate it and Assign a D50 RGB color-space to that.
I did that. I assigned AdobeRGB to one document and ColorMatch RGB (modified
to have the same gamma of 2.2 as AdobeRGB) to the other.
> So what do we have now:
>
> 1) Two files with the very same RGB codes,
> 2) these files are in quite different color-spaces, one of them is in
> the D65 working-space and the other is in the D50 working-space,
> 3) but they both appear *exactly* the same.
Yes, strange? That's exactly what I am getting???
> This example shows in a nutshell the bug in the Adobe
> Color-Management. In this situation when the RGB codes are the same
> the outputs must be different. And if the outputs are the same then
> the RGB codes must be different.
You mean, if the Source RGB codes are the SAME but the Destination space
(D65 vs D50) are DIFFERENT then the appearance of the two grayscale SHOULD
be different. The D65 scale should be slightly bluish whereas the D50 scale
should be neutral or slightly yellowish, depending n my CRT hardware
calibrated white point, right?
My CRT is hardware calibrated at 5000K CCT. So the D50 scale should not be
affected. But what about the D65 scale? How do you know that there is still
not chromatic adaptation transform going on in the Photoshop engine that
makes the scale look the same as the D50 scale? I would tend to concur with
you that the appearance should NOT be the same.
> But in Photoshop it is not so. It considers the color-temperature of
> the RGB working-space as if it was a relative value
Do you mean that it takes 6500K and stick that to the monitor white point,
not chromatically adapting on the way out to the monitor?
> but it considers
> the other two parameters of the RGB working-space (Primaries and
> Gamma) as absolute values.
OK. You mean it should treat the color-temperature as absolute as well?
> This is quite a serious bug since it affects to all conversions with
> Absolute intent.
Do you mean that this is the but that explains why I am getting a blue
background when I convert absolute colorimetric to my printer? You think
that converting AbsCol to a printer from D65 should not yield a bluish color
cast in whites?
> There are now quite many output profiles out there
> that try to take this bug into account so vendors are begriming to
> adapt to this bug!
Which ones?
> But Adobe either does not listen or they do not
> understand.
They may have their reasons? But this behavior should de documented.
> It is also very difficult to do colorimetric evaluations with
> Photoshop e.g. such like you described. For example the only way to
> correctly see an image that is in a D50 RGB working-space is to adjust
> the monitor also to D50. And the only way to see correctly an image
> that is in a D65 working-space is to adjust the monitor also to D65.
I'll be making some direct comparison, soon, in my course with my students
and I'll gladly report the findings here.
> (such adjustment can be quickly done with the 'Color Temperature
> Adjusted' -dropdown in AdobeGamma).
Come on! How is that possible physically if my CRT is hardware calibrated
for D50? You meanm by software, it's possible to take out some red and green
to arrive at D65 chromaticities (albeit at a lower white luminance value)?
> Timo Autiokari http://www.aim-dtp.net/
Roger Breton
Timo Autiokari
On Thu, 15 Jan 2004 12:52:54 -0500, Roger Breton <gr...@videotron.ca>
wrote:
>Yes, strange? That's exactly what I am getting???
The other name for it is a bug, the mother of all the bugs in this
category.
>You mean, if the Source RGB codes are the SAME but the Destination space
>(D65 vs D50) are DIFFERENT then the appearance of the two grayscale SHOULD
>be different.
In my example the RGB codes are *in* a space.
RGB codes that are R=G=B in a D65 RGB working-space should output D65
color, that has the measurable x,y point of (0.3127, 0.329).
And RGB codes that are R=G=B in a D50 RGB working-space should output
D50 color, that has the measurable x,y point of (0.3457, 0.3585).
>The D65 scale should be slightly bluish whereas the D50 scale
>should be neutral or slightly yellowish, depending n my CRT
>hardware calibrated white point, right?
*Not* depending on the calibrated white point of your monitor.
The output should be different (D65 "cooler" or D50 "warmer").
R=G=B in a D50 working-space should output measurable D50
chromaticity. And R=G=B in a D65 working-space should output
measurable D65 chromaticity. No matter what the actual hardware
whitepoint of the monitor is.
>My CRT is hardware calibrated at 5000K CCT. So the D50 scale should not be
>affected. But what about the D65 scale? How do you know that there is still
>not chromatic adaptation transform going on in the Photoshop engine that
>makes the scale look the same as the D50 scale?
It does not matter if there is chromatic adaptation going on or not.
It is totally incorrect that R=G=B in D50 working-space and R=G=B in
D65 working-space both output the same color. Add to that the fact
that this color they both output happens to be the whitepoint that the
monitor is calibrated to.
So the color-temperature in Adobe Color-Management is totally and
completely detached from the color-temperature of the systems monitor.
>Do you mean that it takes 6500K and stick that to the monitor white point,
>not chromatically adapting on the way out to the monitor?
The Adobe Color-Management does not take the color-temperature of the
system into account correctly.
>OK. You mean it should treat the color-temperature as absolute as well?
Of course it should. The color-management does not work correctly when
it has this kind of bug. Another way to look at it:
Person who sees an Adobe Color-Managed image (that has the embedded
profile) in Photoshop on a color-managed system with a monitor that is
calibrated to D50
does not see the image similarly like
a person who sees the very same image in Photoshop on a color-managed
system with a monitor that is calibrated to D65.
But this is what we should have and it is what we are told that we
have.
>Do you mean that this is the but that explains why I am getting a blue
>background when I convert absolute colorimetric to my printer?
Yes, all Absolute conversions are affected.
>You think that converting AbsCol to a printer from D65 should not
>yield a bluish color cast in whites?
That somewhat depends under what illumination you judge the 'bluish
color cast'. But what you refer to is not just a cast but more like a
strong blue filter that it placed over the print. Absolute colorimetry
should not create such a extreme change, the difference between D50
and D65 is not that huge.
>They may have their reasons?
Yes, Adobe could be facing some serious damage claims in case they
would admit the bug.
>But this behavior should de documented.
It is NOT a feature at all but a serious bug that cripples Adobe
Color-Management quite badly.
>> (such adjustment can be quickly done with the 'Color Temperature
>> Adjusted' -dropdown in AdobeGamma).
>
>Come on! How is that possible physically if my CRT is hardware calibrated
>for D50? You meanm by software, it's possible to take out some red and green
>to arrive at D65 chromaticities (albeit at a lower white luminance value)?
Yes, AdobeGamma does simulate color-temperatures. When you have the
monitor in accurate calibration by hardware you will then tell to
AdobeGamma what that hardware color-temperature of the monitor is
using the dropdown:
' White Point Hardware'
After that you can simulate an other color-temperature using the
dropdown:
'White Point Adjusted'
Please try it, it is a good tool (and works correctly).
Naturally it does it by adjusting the look-up-table ramps in the
display driver card.
Timo Autiokari http://www.aim-dtp.net/
Greg
different colour temperature,
isn't it simply that Photoshop *always* does relative conversions from the
working space, to the monitor space?
This is how almost everyone would want Photoshop to behave, isn't it?
The absolute intent can be viewed by using soft proofing - it's very quick
and easy.
Greg.
Gernot Hoffmann
Timo,
thanks. Seems you are confirming my odd observations
(maybe I“m a little late, but in the Adobe Color Manage-
ment Forum is still a strange silence about this issue).
Robert,
please do me a favour: don“t confuse my very clear test
situation with other working spaces than sRGB.
If we extend the discussion to e.g. Adobe RGB(98) then
this would add further problems: this gamut is not as near
to monitor gamuts as sRGB.
In the moment it looks as if the color management in PhS7
is considerably wrong.
Best regards --Gernot Hoffmann
Greg
news:a815dbcf.04011...@posting.google.com...
> In the moment it looks as if the color management in PhS7
> is considerably wrong.
I still don't understand what the problem is. I've just used the CIE Color
Calculator here:
http://www.brucelindbloom.com/index.html?ColorCalculator.html
and it appears to me that Photoshop 7.01 matches exactly.
I created a 21 step grey wedge, and assigned one copy sRGB, and the other
ColorMatch. Display profile is sRGB.
The ColorMatch version looks *almost* the same, except for the gamma
discrepancy (1.8 vs 2.2). Middle grey (128, 128,128)
is displayed *on screen* with pixel values 146,146,146, which matches the
CIE calculator.
I then did a soft proof of the ColorMatch wedge to my display profile
(sRGB), using absolute intent. The image takes on a yellow cast (as
expected), and middle grey
now has a pixel value of 156,145,127, which matches the CIE calculator!
What *exactly* is the problem supposed to be?
Greg.
Gernot Hoffmann
> Robert,
> ...
Sorry, Roger.
Timo Autiokari
>Regarding Photoshop displaying the greyscale wedge which
>has been assigned a different colour temperature, isn't it simply
>that Photoshop *always* does relative conversions from the
>working space, to the monitor space?
Yes it is doing some kind of relative conversion. But it is not the
task of the color-management to do any chromatic adaptation on the
viewing path. We can only see the images correctly/accurately from
system to system when the color-management displays the colors
similarly, so that the CIE x.y points of the pixels are the same.
After that it is the task of the human vision to either do chromatic
adaptation or not.
>This is how almost everyone would want Photoshop to behave, isn't it?
Well, it will result that:
the same image does not look the same on two computers when one has
hardware whitepoint of the monitor at D65 and the other in D50.
and conversion by Absolute intent results either incorrect appearance
or incorrect RGB codes or both.
So no, this is not what everyone wants.
Timo Autiokari
Greg
>
> So no, this is not what everyone wants.
Thanks, but I'm still not clear.
How exactly should Photoshop display, say, an image in ColorMatch RGB, on a
D65 monitor? It either has to use relative intent,
or absolute intent, doesn't it? How else can it correctly display the image?
Greg.
Timo Autiokari
>I still don't understand what the problem is. I've just used the CIE Color
>Calculator here:
>http://www.brucelindbloom.com/index.html?ColorCalculator.html
>and it appears to me that Photoshop 7.01 matches exactly.
Any calculator that is built by keeping the Photoshop as the reference
will shot the same values as Photoshop.
>What *exactly* is the problem supposed to be?
Ok, We have a photographer and a prepress dept.
1) The monitor of the Photographers color-managed system is hardware
calibrated to D65.
2) The monitors at the prepress are hardware calibrated to D50.
3) The images that the Photographer sends to the prepress do not
appear even closely similarly at the prepress compared to how they
appeared on the Photographers monitor.
And:
1) Absolute intent soft-proofing with any printer profile show
incorrect colors unless the monitors hardware whitepoint and the RGB
working-space are the same.
2) Absolute intent conversion will either result incorrect appearance
or incorrect RGB codes (or both) unless the monitors hardware
whitepoint and the RGB working-space are the same.
Timo Autiokari
Timo Autiokari
>How exactly should Photoshop display, say, an image in ColorMatch RGB, on a
>D65 monitor? It either has to use relative intent, or absolute intent, doesn't it?
Yes, it should do absolute intent. Absolute from RGB to PCS and then
Absolute from PCS to monitor. .
Greg, could you please also do this experiment.
1) View and memorize the appearance of the D50 graywedge in your
current setup, save it with the profile embedded.
2) Set your monitor to D93 by the hardware controls.
3) Calibrate and profile the monitor then.
With AdobeGamma the 2 and 3 are quite easy, just use the monitor
controls and select the 9300K preset (it is well enough for this),
then change the 'White Point Hardware' setting in AdobeGamma to 9300K
and save the monitor profile.
4) Open Photoshop and then the graywedge into it.
And ooooh, that D50 graywedge will be horribly bluish.
Do you now see the problem? Photoshop should show the D50 gray wedge
as D50 gray wedge no matter what the hardware white-point of the
monitor is. Else we do not have color-management.
Timo Autiokari
Greg
> Greg, could you please also do this experiment.
I probably will do exactly what you have instructed at some stage, but I do
actually believe
you already that the resulting yellow/red cast of the D50 greyscale, when
viewed on my D65
monitor using Absolute intent, is excessive. (too much yellow/red). Let's
assume that you're
right, that the colour is *not* the same as would be viewed on a D50
monitor. I'm still
not clear how Photoshop *should* display the image correctly! Is there a
superior way
of doing Absolute conversions? If so, what is it? I'm genuinely interested.
Greg.
Roger Breton
> 4) Open Photoshop and then the graywedge into it.
>
> And ooooh, that D50 graywedge will be horribly bluish.
>
> Do you now see the problem? Photoshop should show the D50 gray wedge
> as D50 gray wedge no matter what the hardware white-point of the
> monitor is. Else we do not have color-management.
>
> Timo Autiokari
Timo, could it be that Photoshop is not managing the neutral axis at all but
as colors progressively move away from the neutral axis they are correctly
managed?
Roger Breton
Timo Autiokari
>I do actually believe you already that the resulting yellow/red cast
>of the D50 greyscale, when viewed on my D65 monitor using
>Absolute intent, is excessive. (too much yellow/red).
Yes, about double.
>I'm still not clear how Photoshop *should* display the image
>correctly! Is there a superior way of doing Absolute conversions?
There is no superior way, just the correct way.
You seem to think that the bug is in the code that does the Absolute
conversion, it is not there but in the information that Photoshop
provides to that code. The actual bugs are in the way Photoshop
manages the whitepoint of the RGB Working Space Profile and in the way
it manages the whitepoint of the Monitor Space.
The errors are very easily seen after an Absolute conversion,
excessive blue or yellow cast. There are also errors after Relative
mode conversion (either the RGB codes or the appearance or both are
incorrect depending on what the whitepoints of the system and the
working-space happen to be) but these errors are not seen very easily
because the gray range will not change in relative conversion.
Again, in a RGB Working-Space that has a CIE x,y whitepoint the R=G=B
codes should output colors on the monitor that have very same
measurable CIE x,y chromaticity no matter what the CIE x,y of
whitepoint of the monitor hardware is. Only then the CIE colorimetry
can work and only then we have color-management.
Timo Autiokari
Timo Autiokari
>could it be that Photoshop is not managing the neutral axis at all but
>as colors progressively move away from the neutral axis they are correctly
>managed?
CIE colorimetry does not manage neutrals differently from colors in
that the conversions are 3x3 linear matrix operations that are applied
over the linear data exactly similarly, in a given conversion each
color is converted by the very same matrix and when the matrix is
incorrectly calculated the errors are all over the place. The
achromatic colors could have more or less error than the highly
saturated colors or visa versa depending on the Intent that was used
but in general there can not be such management of colors as you
mention.
Timo Autiokari
Greg
> There is no superior way, just the correct way.
Ok, then - what *is* the correct way? Is there a color converter/calculator
somewhere
that I could try, which you feel *does* do the conversion properly?
Greg.
Gernot Hoffmann
Greg,
the correct way is that an image which is optimized in PhS in sRGB
on a D65 monitor looks alike in PhS on a D50 monitor (chosen as
Default Monitor in Windows).
Alike means: as near as possible. A perfect match is impossible
because of different gamuts. My test image is therefore little
saturated.
The monitor compensation shouldn´t change the numbers in the file
and also not the measurable numbers in PhS (info palette).
It should change the numbers which are sent to the monitor.
It´s an ordinary white point shift, using a policy for handling
out-of-gamut colors.
There is not even an adaptation problem - both images should look
alike, therefore the adaptation is the same.
Best regards --Gernot Hoffmann
Gernot Hoffmann
Greg
news:a815dbcf.04011...@posting.google.com...
>
> on a D65 monitor looks alike in PhS on a D50 monitor (chosen as
> Default Monitor in Windows).
> Alike means: as near as possible. A perfect match is impossible
> because of different gamuts. My test image is therefore little
> saturated.
> The monitor compensation shouldn´t change the numbers in the file
> and also not the measurable numbers in PhS (info palette).
> It should change the numbers which are sent to the monitor.
> It´s an ordinary white point shift, using a policy for handling
> out-of-gamut colors.
> There is not even an adaptation problem - both images should look
> alike, therefore the adaptation is the same.
This still hasn't answered my question.
Where do I find a calculator, or even the formulas, to convert an image from
ColorMatch RGB to sRGB, in such a way that the resulting colours will be as
accurate as possible? If it's just too complex to give me the formulas, and
no
program is available to do it, how about *you* do the calculations for me,
as a first step:
convert 128,128,128 in ColorMatch RGB to sRGB. Do the same for 255,255,255.
I have *always* felt that something was amiss, either in Photoshop, or
generally with ICC,
regarding absolute conversions - I agree - the result *does* look
excessively yellow.
I now want to understand how to do it properly. So please stop telling me
what the result
should be, and concentrate on telling me *how* to do it.
Greg.
Timo Autiokari
>Ok, then - what *is* the correct way? Is there a color
>converter/calculator somewhere that I could try, which
>you feel *does* do the conversion properly?
you seem to think that it is just some bug in the color conversion
code somewhere in Photoshop so that if you'd calculate the conversion
correctly then Photoshop would show the correct data correctly. It is
not so. There are no calculators that are faulty in such way that it
would correct the faulty implementation of color.management in
Photoshop.
So, this fault is deeper in the general color-management flow in
Photoshop. Photoshop does not manage the working-space whitepoint
correctly. That then will result different kind of errors depending on
1) what the hardware whitepoint of the monitor is and 2) what the
whitepoint of the RGB working-space is and 3) what the whitepoint of
the output device is and 4) what the whitepoint of the media is.
Timo Autiokari
Timo Autiokari
>please stop telling me what the result should be,
>and concentrate on telling me *how* to do it.
We have a tool that has a basic flaw in its color-management flow.
It is rather difficult to give instruction on how to use such a tool
in such way that it gives corect results.
Something can be done, but it involves changes to the montor profile
or to the working-space profile or to both either before or after or
both before and after when a Profile conversion is made. Rather
difficult.
Timo Autiokari
Greg
> you seem to think that it is just some bug in the color conversion
> code somewhere in Photoshop so that if you'd calculate the conversion
> correctly then Photoshop would show the correct data correctly. It is
> not so. There are no calculators that are faulty in such way that it
> would correct the faulty implementation of color.management in
> Photoshop.
Forget Photoshop.
Please see my reply to Gernot, regarding converting pixel values 128,128,128
and
255,255,255, from Colormatch RGB to sRGB. I don't care how you do it, but
it'd be really great if you could tell me the steps you took to do the
conversion, so
I can perform the same transformation myself. I have chosen sRGB because I
am using
sRGB for my monitor space at the moment. If you simply refuse to use sRGB (I
have seen
your comments on sRGB in various forums), please nominate an ICC profile to
use for a
general purpose CRT calibrated to D65. (I will be shortly receiving an Eye
One Display
so that I can accurately profile my monitor)
Greg.
Greg
Pro, using absolute rendering
to my sRGB monitor. It also looks excessively yellow. So, the CIE Color
Calculator, Picture Window Pro,
and Photoshop are all producing the same results. (I haven't bothered to
check the pixel values in PWP, but
I think they'll be identical or very nearly identical, judging by the
appearance)
Or is PWP also using Photoshop as the "reference", duplicating it's bugs?
PWP uses the Little CMS
colour management engine (or the Microsoft default, but I'm using LCMS).
I agree that the appearance looks silly (far too much yellow), but why does
everything seem to do
the conversion exactly the same way? Surely they can't *all* be wrong. If
they *are* all wrong,
I'm still waiting for someone to tell me how to do the conversion the right
way! What information
do you need from me that I haven't already given? All I want to do is view a
greyscale which is
in the ColorMatch RGB space, on my sRGB D65 monitor, and have the appearance
look closer
to how it really *should* look. We know the "media white points", because
they are contained
in the two ICC profiles, right? So come on - I'm waiting for some actual
pixel values that should
be sent to an ideal sRGB monitor to reproduce 128,128,128 and 255,255,255
in ColorMatch RGB.
Greg.
Gernot Hoffmann
Greg,
color space calculations are here on p.14:
http://www.fho-emden.de/~hoffmann/colcie290800.pdf
Now I have a big problem for the two profiles D65 and D50
for the SAME monitor:
X-Rite ColorShop shows:
The primaries are different.
GretagMacbeth/ProfileEditor/Gamut View shows:
The primaries are nearly equal.
We know: Gamut View is buggy (confirmed by GM).
Some people say: ColorShop is buggy.
If the primaries were the same then a white point shift is calculated
by a diagonal matrix.
Doing this explicitly I get approximately the same result as in
the PhS preview: Background Color Temperature 5500K instead of D65
on the D50 monitor.
Best regards --Gernot Hoffmann
Gernot Hoffmann
Greg,
sRGB for monitor space ? sRGB is the WORKING space.
The monitor space is the Windows Default Monitor - the actually valid
calibration (of course on a Windows PC).
About the discrepancies between GM ProfileEditor and X-Rite ColorShop:
GM shows: the primaries for the D65 and the D50 profile are equal.
XR shows: the primaries are different.
Little CMS shows: the primaries are different:
http://www.fho-emden.de/~hoffmann/D65-D50.pdf
I give up.
Best regards --Gernot Hoffmann
Gernot Hoffmann
> Color Management, but nobody seems to be interested
> in the question though it愀 IMO essential.
> My results and conclusions will be posted later.
>
> The prepress folks likes to calibrate monitors by D50 instead of D65.
> They expect that the preview without CMS is nearer to a print under D50.
>
> Now let愀 do a test:
> A portrait photo with little saturation and a gray background is
> optimized in sRGB using a D65 monitor:
> http://www.fho-emden.de/~hoffmann/francine28082003.pdf
>
> We can compare three modes of visualization:
>
> 1. D65 Monitor, Photoshop 7.0 or any other program without CMS.
>
> 2. D50 Monitor, any program without CMS.
>
> 3. D50 Monitor, Photoshop 7.0 with CMS, using the monitor profile.
>
> All monitor profiles are accurate within Gamma=+-0.02 and T=+-50K.
>
> The monitor primaries are "near" to the sRGB primaries (not very
> important, because the colors are little saturated).
>
> Which mode shows the best preview with respect to a very accurate
> print on a fully calibrated inkjet in a D50 light booth ?
>
> Any guess is possible ...
>
> Best regards --Gernot Hoffmann
The condensed result of all these tests:
Though Photoshop knows the actual monitor profile
it doesn愒 show a correct preview.
A D65 image is shown on a D50 monitor VERY wrong.
Color management should provide a preview which is
at least near to the original D65 image (accurate
for little saturated images).
Otherwise we can forget CMS.
G.H.
Timo Autiokari
>Forget Photoshop.
>Please see my reply to Gernot, regarding converting pixel values 128,128,128
>and 255,255,255, from Colormatch RGB to sRGB. I don't care how you do it, but
>it'd be really great if you could tell me the steps you took to do the
>conversion, so I can perform the same transformation myself.
Ok, I do not use the sadRGB just because I have not implemented it to
my Excel workbook models, instead I use the nativePC profile that is
Trinitron-primaries, D65 and gamma 2.5 and that approximates the CRT
monitor that is hooked to Windows PC as accurately as it can be
approximated.
When the ColormatchRGB is the RGB Working-space and the nativePC is
the monitor space then:
1) convert the ColormatchRGB to linear RGB in P22-EBU (this is the
gamut of the ColormatchRGB profile), so apply gamma 1.8.
2) convert that to XYZ by absolute colorimetry.
3) convert that to linear RGB in Trinitron gamut by absolute
colorimetry.
4) convert that to gamma 2.5 space, so apply gamma 1/2.5
So we have:
in ColormatchRGB:
(a) = 255,255,255
(b) = 128,128,128
in CIE XYZ
(a) = 0.964295676, 1, 0.825104603
(b) = (0.276921214, 0, 287174589, 0.236949075
in nativePC:
(a) = 271, 252, 223
(b) = 165, 153, 135
and I believe this is one thing that you are aiming at, the code (a)
is out of gamut. So the conversion algorithm should either do gamut
clipping correctly or adjust the scaling so that clipping is avoided
and this is the more correct thing to do so I use it and we end up to:
in nativePC:
(a) = 255, 237, 209
(a) = 155, 144, 127
Oh yes, Photoshop does not do the gamut clipping correctly, it just
clips the R= 271 in code (a) to 255 leaving the G and B uncorrected.
Now, with this experiment the RGB codes are the same that Photoshop
results when using Absolute Intent so it does the math correctly (less
the out-of-gamut management). BUT PLEASE NOTE: Depending on the
hardware whitepoint of your monitor Photoshop shows either the
ColormatchRGB view or the nativePC view *way* incorrectly. So do not
just do the experiment in Photoshop and conclude that everything is
working correctly.
If your system monitor is hardware calibrated to D65 then the result
in Photoshop appears to have an extremely strong yellow cast (what
appeared to be pure clean white in ColormatchRGB convert to horribly
deep yellow).
If your system monitor is hardware calibrated to D50 then the result
in Photoshop appears to have an much less yellow cast (what appeared
to be only slightly yellowish in ColormatchRGB convert to just a
little more deep yellowish).
In both the above cases the appearance in Photoshop is incorrect
because the original colors that we see on the monitor should not
change at all.
Now you probably will note that doing the conversion by Relative
intent would give unaffected grayrange, it in deed does that but then:
1) the colors will have the errors *and*
2) the grayrange is still shown incorrectly in ColormatchRGB when the
system monitor not hardware calibrated to D50 (and the grayrange is
shown incorrectly in nativePC when the system monitor is not
calibrated to D65).
To understand the 2) please calibrate and profile the system monitor
to D93 and show a R=G=B grayrange in ColormatchRGB in Photoshop. It
looks terribly bluish. Then calibrate and profile the system monitor
to D50 and show a R=G=B grayrange in ColormatchRGB in Photoshop, it
looks like D50 looks, with hint of yellowish. But R=G=B in
ColormatchRGB should look as D50 grayrange no matter what the
whitepoint of the monitor hardware is.
Timo Autiokari
Timo Autiokari
hoff...@fho-emden.de (Gernot Hoffmann) wrote:
>I give up.
Please do not. You are one of the *very* few people on this earth who
are able to understand this problem (in addition to those two who can
not speak about this without being fired).
I complained about this bug the first time when Photoshop v.5 came
out, no-one understood, many agreed that the cast after Absolute
conversion appeared to be extreme some would not agree (those who have
the hardware whitepoint of the system in D50). Then after the v.5.5
was published and yet again when v.6 was published. V7 is still the
same even if some people at Adobe believe (or make-believe) that they
have made a correction.
So please do not give up.
>GM shows: the primaries for the D65 and the D50 profile are equal.
>XR shows: the primaries are different.
>Little CMS shows: the primaries are different:
>http://www.fho-emden.de/~hoffmann/D65-D50.pdf
I said earlier that some vendors are slowly starting to adapt with
this Adobe Color-Management bug. They simply need to be compatible
with Photoshop so they will do what ever is needed in order to
accomplish that. Else they are out of the business.
But it is very bad if this faulty Adobe Color-Management will turn
into a standard. So we really should dig into this issue as deep as
necessary to make it totally clear.
Timo Autiokari
Roger Breton
>
> GM shows: the primaries for the D65 and the D50 profile are equal.
> XR shows: the primaries are different.
> Little CMS shows: the primaries are different:
> http://www.fho-emden.de/~hoffmann/D65-D50.pdf
>
> I give up.
>
> Best regards --Gernot Hoffmann
Gernot,
It could be that the primaries are not reported UNIFORMLY? I.e. Perhaps GMB
is reporting primaries in Relative Units and X-Rite is showing is Absolute
Units? I know it's a bitch now to go from a monitor ICC profile's reported
primaries to the REAL measured primaries!!!
Roger Breton
Roger Breton
>
> Though Photoshop knows the actual monitor profile
> A D65 image is shown on a D50 monitor VERY wrong.
> Color management should provide a preview which is
> at least near to the original D65 image (accurate
> for little saturated images).
> Otherwise we can forget CMS.
>
> G.H.
Or we stick to ONE monitor calibration only?
R.B.
Timo Autiokari
>The condensed result of all these tests:
I propose: *intermediate results*, since there is still some work to
do here.
>Though Photoshop knows the actual monitor profile
>it doesn´t show a correct preview.
That is absolutely correct.
>A D65 image is shown on a D50 monitor VERY wrong.
That is absolutely correct too. Also a D50 image is shown VERY wrong
on a D50 monitor (on a monitor that has D50 as the hardware
whitepoint).
And the actual bomb here is:
Monitors that are profiled with the expensive HW+SW profiling packages
can have whatever whitepoint x,y they are not necessarily calibrated
to any D50 nor D65 but just profiled. So they will have an incorrect
cast always no matter what standard RGB working-space is being used.
>Color management should provide a preview which is
>at least near to the original D65 image (accurate
>for little saturated images)
Should provide accurately view for whatever image, and so that the
image is shown similarly on different computers that have different
monitors (differently adjusted monitors).
Timo Autiokari
Timo Autiokari
>Or we stick to ONE monitor calibration only?
Then you also need to use an RGB working-space profile that has the
very same whitepoint as your monitor hardware has.
But that does not help since as soon as you do a profile conversion to
a profile that does not have that same whitepoint then either the
appearance or the RGB codes will be incorrect. And we do need to do
these conversions every now and then. So you still can forget CMS.
Timo Autiokari
Greg
news:a815dbcf.04011...@posting.google.com...
sRGB is generally accepted to be a close approximation to a typical CRT
monitor.
It can be used both for the working space *and* for the monitor profile! It
is the default monitor profile in Windows.
Greg.
Timo Autiokari
>sRGB is generally accepted to be a close approximation to a
>typical CRT monitor. It can be used both for the working space
>*and* for the monitor profile! It is the default monitor profile in
>Windows.
Greg, you can have Windows PC in the gamma space 2.2 (the gamma space
of the sadRGB profile) only by calibrating the system using an gamma
calibration utility such as the AdobeGamma. Without the gamma
calibration the system gamma will be the same as the monitor's native
gamma that for all the CRT monitors is 2.50.
No CRT monitor and no flat panel have the HDTV primaries that he
sadRGB specify and no calibration utility does this conversion. CTR
monitors have either the P-22 or Trinitron primaries that are very
close to each other and quite far from the HDTV primaries.
sadRGB is not "generally accepted", it is being pushed by Microsoft,
HP and Adobe but that does not make it generally accepted, just
generally forced.
But this issue is a sidestep from the subject of the original thread
so I hope it could be discussed in this new thread.
Timo Autiokari
Greg
Thanks. I downloaded your nativePC monitor profile and set that for my
system monitor profile. Your results match Photoshop 7.01 very closely (not
exactly, but very close, and yes, except for the gamut clipping), and your
results *also* look very yellow.
This came as a surprise to me - I thought that your results would look only
slightly yellow.
I guess this means that a D50 monitor really *is* quite yellow! I'm going to
do an experiment when I receive my hardware monitor
calibrator - I'll photograph the monitor displaying the greyscale wedge,
with the monitor calibrated for both D50 and D65. I'll lock
all the settings on the digital camera between photos. (exposure, white
balance, etc) I can already change the temperature of my monitor
with the monitor controls, but I don't trust this - I'll wait until I
calibrate it accurately.
Greg.
"Timo Autiokari" <timo.au...@aim-dtp.net> wrote in message
news:j25j001sh9vm49i8l...@4ax.com...
Greg
> I guess this means that a D50 monitor really *is* quite yellow! I'm going
to
> do an experiment when I receive my hardware monitor
> calibrator - I'll photograph the monitor displaying the greyscale wedge,
> with the monitor calibrated for both D50 and D65. I'll lock
> all the settings on the digital camera between photos. (exposure, white
> balance, etc) I can already change the temperature of my monitor
> with the monitor controls, but I don't trust this - I'll wait until I
> calibrate it accurately.
Doh!!! I won't need to use the digital camera - I'll be able to *measure*
the colours accurately
with the monitor puck!!
Greg.
Timo Autiokari
>I guess this means that a D50 monitor really *is* quite yellow!
No it is NOT quite yellow, it is just slightly yellowish.white.
Because Photoshop manages the Color Temperature setting of the RGB
Working-Space profile incorrectly (almost does not manage it at all)
the view of the D50 in a Photoshop document window is incorrect, e.g.
it looks exactly like D65 when the actual Hardware Color Temperature
of your monitor is D65 and it looks exactly like D93 when actual
Hardware Color Temperature of your monitor is D93.
After absolute profile conversion from D50 color-space to a D65
color-space *when* the actual Hardware Color Temperature of your
profiled monitor is D50:
the white that was D50 will look like D35 (3600K).
After absolute profile conversion from D50 color-space to a D65
color-space *when* the actual Hardware Color Temperature of your
profiled monitor is D65:
the white that was D65 (!) will look like D29 (2900K).
Timo Autiokari
Greg
We've removed Photoshop from the equation, haven't we? You did the
conversion. You gave me the image data
that should be sent to a nativePC monitor, and the result is a strong yellow
cast. Did you make a mistake in your
calculations?
Greg.
"Timo Autiokari" <timo.au...@aim-dtp.net> wrote in message
news:oofj00pn36pmrsn4a...@4ax.com...
Timo Autiokari
>Timo, We've removed Photoshop from the equation, haven't we?
No, you did.
>You did the conversion. You gave me the image data that should be sent
>to a nativePC monitor, and the result is a strong yellow cast.
Aha, then I quess the Hardware Whitepoint of your Monitor is not D65.
>Did you make a mistake in your calculations?
No, I have not made a mistake.
you wrote earlier:
" I downloaded your nativePC monitor profile and set that for my
system monitor profile."
Doing so will NOT make the Hardware Whitepoint of your Monitor to be
D65. System profile just tells to the CMS what the actual Hardware
Whitepoint of your Monitor is. You need to make it so by using the
hardware controls of the monitor adjusting, either visually using a
good D65 reference light source or with a monitor calibration HW+SW
package.
Timo Autiokari
Greg
"Timo Autiokari" <timo.au...@aim-dtp.net> wrote in message
news:lcjj00dis4q6vs849...@4ax.com...
> On Sun, 18 Jan 2004 10:28:49 +1100, "Greg" <nos...@nowhere.com> wrote:
>
> >Timo, We've removed Photoshop from the equation, haven't we?
>
> No, you did.
You helped me. ;^)
We're making good progress. I understand/agree that my white point should be
calibrated accurately. I will report back
after I have received my Eye One Display. Just by the way, I was in fact
viewing your image data in Photoshop, however,
I assigned the nativePC profile to the image, and because my monitor profile
is also set to nativePC, Photoshop should
not be modifying the image data in any way whatsoever before sending it to
the graphics driver.
I don't think calibrating my monitor accurately is going to change the
appearance very much, but I will do this, just to make sure.
If it still looks excessively yellow after calibrating, I suppose I should
go and have my eyes checked.
Greg.
Greg
news:a815dbcf.04011...@posting.google.com...
> http://www.fho-emden.de/~hoffmann/colcie290800.pdf
Thanks, but I don't need this any more, because it appears that the CIE
Color Converter which
I mentioned earlier can be trusted, because Timo's calculations match
Photoshop very closely (except
for the gamut clipping/scaling issue), and Photoshop matches the CIE Color
Converter. So I'm going
to continue to use the CIE Color Converter.
Greg.
Roger Breton
> That is absolutely correct too. Also a D50 image is shown VERY wrong
> on a D50 monitor (on a monitor that has D50 as the hardware
> whitepoint).
My CRT is hardware calibrated to D50 chromaticities. Are you saying that if
I open up a ColorMatchRGB image in Photoshop (ColorMatch RGB use a D50 white
point) that the image is not displayed properly?
How can I test that?
Roger Breton
Roger Breton
> sRGB is generally accepted to be a close approximation to a typical CRT
> monitor.
> It can be used both for the working space *and* for the monitor profile! It
> is the default monitor profile in Windows.
My Mitsubishi 900u profile and sRGB are very close at first sight but o
closer inspection sRGB blue and magenta XYZ are way more saturated than my
monitor.
I am on a Mac OSX system.
Roger Breton
Roger Breton
wrote on 1/17/04 5:57 PM:
> Timo,
> Thanks. I downloaded your nativePC monitor profile and set that for my
> system monitor profile. Your results match Photoshop 7.01 very closely (not
> exactly, but very close, and yes, except for the gamut clipping), and your
> results *also* look very yellow.
> This came as a surprise to me - I thought that your results would look only
> slightly yellow.
>
> I guess this means that a D50 monitor really *is* quite yellow! I'm going to
> do an experiment when I receive my hardware monitor
> calibrator - I'll photograph the monitor displaying the greyscale wedge,
> with the monitor calibrated for both D50 and D65. I'll lock
> all the settings on the digital camera between photos. (exposure, white
> balance, etc) I can already change the temperature of my monitor
> with the monitor controls, but I don't trust this - I'll wait until I
> calibrate it accurately.
>
> Greg.
So you guys are saying that Photoshop is exagerating the 'yellowness' of my
D50 calibrated monitor? Huh!
Greg, how are you going to be able to document unequivocally what you
propose to do above by photographing your monitor?
Roger Breton
Roger Breton
on 1/17/04 6:03 PM:
> Doh!!! I won't need to use the digital camera - I'll be able to *measure*
> the colours accurately
> with the monitor puck!!
>
> Greg.
As long as you believe in your monitor puck accuracy you will.
I am starting to have my doubt about which instrument gives me the true
reading of my monitor? I just can't afford a Minolta CS-1000! I'd have to
mortgage my house.
Roger Breton
Roger Breton
timo.au...@aim-dtp.net wrote on 1/17/04 6:24 PM:
Timo,
Have you measured all this? What instrument are you using to make your
absolute readings?
Roger Breton
Roger Breton
wrote on 1/17/04 7:17 PM:
Greg and Timo,
I also have an EyeOne. If there are any file you want to send me and any
readings you want me to take at my end on my CRT, you're more than welcome!
Anyone ever tried LinoColor or NewColor7000? This software always impressed
me as managing the white point of the monitor very differently from
Photoshop.
Roger Breton
Roger Breton
Yes,
See my reply about the 3D gamut of my Mitsubishi900u 19" CRT and sRGB gamut.
Anyone got Chromix? Great for visualizing 3D gamuts simulataneusly.
Roger Breton
Gernot Hoffmann
Timo,
two statements and one question.
1. sRGB is ONLY a working space description.
In this sense it´s not relevant whether a monitor is near
to sRGB (if we had a correctly working color management).
2. The Windows default monitor profile is the actually loaded
monitor profile, as measured by an instrument.
Please, no discussion about Adobe Gamma.
a) the LUTs are set by the calibration.
b) the calibrated monitor is characterized: result is the profile.
3. What is Windows RGB in the Proof Setup in PhS ?
One may check PhS help and any other sources. I didn´t find
an explanation. All "user friendly docs" are as blurry as
the PhS help text.
Best regards --Gernot Hoffmann
Timo Autiokari
>Timo, Have you measured all this? What instrument
>are you using to make your absolute readings?
Heh, I'm a poor man, can not afford to have a spectrophotometer so I'm
using simulations. I have some measured light sources and I have
measured many colors of my monitor using a rather good spectro that I
had as a loaner.
Hopefully this does not go into accuracy of measurements. The errors
are so large that one really does not need a spectro to see that
something is way incorrect.
Timo Autiokari
Timo Autiokari
>So you guys are saying that Photoshop is exagerating
>the 'yellowness' of my D50 calibrated monitor? Huh!
Roger,
When the hardware whitepoint of your monitor is D50 and you show an
image that is in a RGB working-space that has D50 whitepoint then the
view is correct. When you convert that image by absolute colorimetry
to a RGB working-space that any other whitepoint than the D50 then the
view is incorrect (e.g. D50 to D65 give very notable yellow cast).
And:
When the hardware whitepoint of your monitor is D65 and you show an
image that is in a RGB working-space that has D65 whitepoint then the
view is correct. When you convert that image by absolute colorimetry
to a RGB working-space that any other whitepoint than the D65 then the
view is even more incorrect (e.g. D65 to D50 gives extreme yellow
cast)
Timo Autiokari
Timo Autiokari
>My CRT is hardware calibrated to D50 chromaticities. Are you saying that if
>I open up a ColorMatchRGB image in Photoshop (ColorMatch RGB use a
>D50 white point) that the image is not displayed properly?
In this case (always when the hardware whitepoint of the monitor is
the same as the whitepoint of the RGB working-space) the view is
correct.
>How can I test that?
So no need to test that. But please do this: Calibrate your monitor to
D93, then profile it and then view a ColorMatchRGB image in Photoshop.
You will see without any spectrophotometer that the view is way
incorrect. Yes D93 is extreme, but it shows that the Adobe
Color-Management has a fault. So there will be an error even if the
monitor is calibrated and profiled to say D51 but naturally a smaller
error.
To test with more common situation:
1) Calibrate the monitor hardware to D50 and profile that.
2) In Photoshop convert a R=G=B graywedge from a D50 color-space to a
D65 color-space by Absolute colorimetry and make note of the
appearance.
Then
3) Calibrate the monitor hardware to D65 and profile that.
4) In Photoshop again convert a R=G=B graywedge from a D50 color-space
to a D65 color-space by Absolute colorimetry and make note of the
appearance.
What happens in (4) appear to be extremely strong change since it is
not D50 graywedge that you see before the conversion, instead it is
shown as an exact D65 graywedge.
To see similar strong errors towards blue just switch D50 and D65 in
the above 1, 2, 3 and 4 steps with each other.
Timo Autiokari
Greg
news:BC2F7E52.133BF%gr...@videotron.ca...
> As long as you believe in your monitor puck accuracy you will.
It received a very good review at Dry Creek Photo, but it will be difficult
to know for sure, yes.
Actually I think I will also use the digital camera, for a qualitative
measurement.
Greg.
Greg
> So no need to test that. But please do this: Calibrate your monitor to
> D93, then profile it and then view a ColorMatchRGB image in Photoshop.
> You will see without any spectrophotometer that the view is way
> incorrect. Yes D93 is extreme, but it shows that the Adobe
> Color-Management has a fault. So there will be an error even if the
> monitor is calibrated and profiled to say D51 but naturally a smaller
> error.
I don't understand. You were saying before that Photoshop was showing the
D50 wedge on a D65 monitor
incorrectly, however, you then did the calculations yourself, and the result
was very nearly the same (gamut
clipping/scaling aside). Why don't you do the calculations for *this* case
as well? What will you say if your
calculations match Photoshop again?
Greg.
Greg
news:a815dbcf.04011...@posting.google.com...
> to sRGB (if we had a correctly working color management).
This is just not true. sRGB is both a working space *and* a "generic"
monitor profile.
It is designed for both. It is in fact the default monitor profile in
Windows, and Photoshop
has no trouble whatsoever using it for the monitor profile.
Greg.
Greg
> "Greg" <nos...@nowhere.com> wrote:
>
> >I do actually believe you already that the resulting yellow/red cast
> >of the D50 greyscale, when viewed on my D65 monitor using
> >Absolute intent, is excessive. (too much yellow/red).
>
> Yes, about double.
Timo, you have now proven that Photoshop is working correctly, because your
calculations match Photoshop's.
Photoshop clips the D50 white, but other than that, it's producing correct
results, at least for this particular
case. So the "about double" comment you made can't be right, because it
contradicts your own calculations.
Greg.
Roger Breton
> When the hardware whitepoint of your monitor is D50 and you show an
> image that is in a RGB working-space that has D50 whitepoint then the
> view is correct. When you convert that image by absolute colorimetry
> to a RGB working-space that any other whitepoint than the D50 then the
> view is incorrect (e.g. D50 to D65 give very notable yellow cast).
So when converting AbsCol a D50 RGB image over to AdobeRGB then the view is
incorrect (noticeable yellow cast)?
But when converting RelCol a D50 RGB image to AdobeRGB then what?
> When the hardware whitepoint of your monitor is D65 and you show an
> image that is in a RGB working-space that has D65 whitepoint then the
> view is correct. When you convert that image by absolute colorimetry
> to a RGB working-space that any other whitepoint than the D65 then the
> view is even more incorrect (e.g. D65 to D50 gives extreme yellow
> cast)
OK I get the idea. In other words, it's Photoshop's method of converting
AbsCol from one RGB space to another that is not correct. Have you found
that the problem only applies to matrix/trc profiles or does it also apply
to LUT type of profiles?
Roger Breton
Roger Breton
> monitor profile.
> It is designed for both. It is in fact the default monitor profile in
> Windows, and Photoshop
> has no trouble whatsoever using it for the monitor profile.
>
> Greg.
Yes, PS has no trouble using it for the monitor profile but what good is it?
Did you ever look at a comparative 3D view of sRGB gamut vs a real, measured
CRT, like yours? There are a host of blue and magenta colors from sRGB that
a true CRT is simply not able to display. So, lot's of clipping in this
region. But maybe for the purpose of this discussion it is quite allright.
Is that your point, Greg?
Roger Breton
Timo Autiokari
>So when converting AbsCol a D50 RGB image over to AdobeRGB
>then the view is incorrect (noticeable yellow cast)?
Yes. Horrible yellow cast when the hardware whitepoint of the system
is D65. Only strong yellow cast when the hardware whitepoint of the
system is D50.
>But when converting RelCol a D50 RGB image to AdobeRGB then what?
Then the R=G=B codes are not affected but the colors are incorrect.
>OK I get the idea. In other words, it's Photoshop's method of converting
>AbsCol from one RGB space to another that is not correct.
It is not so.
The conversion algorithms do result correct numerical RGB values (in
the RGB Working-Space).
But those numerical RGB values (from the RGB Working-Space). are not
correctly converted for screen view.
>Have you found that the problem only applies to matrix/trc profiles
>or does it also apply to LUT type of profiles?
It fault is there with all kind of profiles because the it is on the
path from the RGB Working-Space to the Monitor Space.
Timo Autiokari
Timo Autiokari
>Timo, you have now proven that Photoshop is working
>correctly, because your calculations match Photoshop's.
It is not working correctly. The numerical RGB codes are calculated
OK, but they are not correctly converted from the working-space to the
monitor.
>Photoshop clips the D50 white, but other than that,
What photoshop does is not gamut clipping, gamut clipping includes the
adjustment of the hue. Photoshop just truncates the >255 and possibly
the <0 RGB values, leaving the other channels unmanaged, this will
cause hue errors to the truncated colors.
>it's producing correct results, at least for this particular case. So the
>"about double" comment you made can't be right, because it contradicts
>your own calculations.
It does not contradict to my own calculations.
Are you unable to try the D93 experiment that I have given you twice?
Instead you just use your and my time for this kind of taunting, why?
The D93 test will show you immediately that Photoshop is not managing
the conversion from the working-space to the monitor space correctly.
1. Calibrate the hardware whitepoint of your monitor to D93 and
profile that.
2) Open Photoshop create a R=G=B wedge in a D50 working-space.
That wedge looks horribly bluish.
Please do the above experiment then you will start to understand what
the problem is and how it affects to appearance and to profile
conversions.
Timo Autiokari
Timo Autiokari
hoff...@fho-emden.de (Gernot Hoffmann) wrote:
>1. sRGB is ONLY a working space description.
Yes, if it is used it should be used only as a working space
description. Some software however do install the sadRGB as the system
profile (under DisplayProperties....Color-management).
>2. The Windows default monitor profile is the actually loaded
> monitor profile, as measured by an instrument.
That is so, when there is such a profile. But what to use there when a
custom made profile is not available. I recommend to use the nativePC
profile there, (Trinitron phosphor chromaticities, D65 and gamma 2.5).
Some recommend to use the sadRGB there (E.g. Microsoft, HP and Adobe).
>3. What is Windows RGB in the Proof Setup in PhS ?
I do not know. A long time ago I did inspect it just for the fun but I
do not remember anymore what it was.
I never use it, instead I create my own ProofSetups and I save them
(giving them names that fully characterizes the setups), this way they
are always available at the bottom of the View/ProofSetup -menu.
Timo Autiokari
Roger Breton
I have an D50 RGB gamma 2.2 document I created in Photoshop 8 CS containing
only gray steps (R=G=B) from 0 to 255 in 25 levels increments. Let's call
this "Document A".
>> But when converting RelCol a D50 RGB image to AdobeRGB then what?
> Then the R=G=B codes are not affected but the colors are incorrect.
Experiment A:
Converting Document A using RelCol from "D50 RGB gamma 2.2" to AdobeRGB (D65
gamma 2.2) results in NO code changes AND no changes in the displayed colors
-- irregardless of Conversion Options under Color Settings. That is one
outcome I understand you deplore. You'd like to see the gray wedges take on
a slightly bluish cast, to reflect the change in white point chromaticities
from D50 to D65. Even a Custom Proof Setup, forcing AbsCol in AdobeRGB has
no effect on the displayed colors: the result is not managed to the screen.
> The conversion algorithms do result correct numerical RGB values (in
> the RGB Working-Space).
> But those numerical RGB values (from the RGB Working-Space). are not
> correctly converted for screen view.
Yes, I see what you mean now. The codes are correctly converted from Source
to Destination but the color appearance to the screen of the codes is not
managed at all.
Experiment B:
Converting Document A using AbsCol from "D50 RGB gamma 2.2" to AdobeRGB
results in a new set of codes AND every colors now becomes terribly yellow
to the screen. This yellowness is objectionable, to say the least, and in
your view quite unacceptable? You classify that as a bug. You say it should
be a lot less yellow than what Photoshop makes it? I was under the
impression that all color conversions were handles by the underlying
ColorSync engine. So maybe Apple is at fault. And you're saying the same
phenomenon applies in Photoshop for Windows?
Roger Breton
Timo Autiokari
I very much appreciate the effort you have done here but you have
drawn quick conclusions. I know that this is not very easy to
understand, it took me many months to dig it out. You have done far
better just in couple of days but the root cause is not clear yet.
I try in another way:
When we have RGB codes in a specific color-space, these colors should
be show on the monitor by absolute colorimetry. So that e.g. R=G=B
wedge that is in a D50 color-space will always be shown so that it has
the chromaticity of D50 (on the screen) no matter what the hardware
color temperature of the monitor is. This is what Photoshop does not
do. It always shows R=G=B codes on the screen using the hardware color
temperature of the monitor, totally ignoring the color temperature of
the color-space that the data is in.
Roger Breton <gr...@videotron.ca> wrote:
>Converting Document A using RelCol from "D50 RGB gamma 2.2" to AdobeRGB (D65
>gamma 2.2) results in NO code changes AND no changes in the displayed colors
>-- irregardless of Conversion Options under Color Settings. That is one
>outcome I understand you deplore.
I have not been speaking about RelCol at all so this is not one
outcome that I deplore.
What you explain is what the Photoshop RolCol results. It does not
mean that the fault would not be there.
The monitor of your system is calibrated to D50. If you now take
another system that is equal to your system in all aspects except for
the hardware color temperature of the monitor that is calibrated to
D65 and you open your test image into Photoshop in both these two
system then you will see that the image is not displayed similarly.
They *should* be displayed similarly, that is what the CMS should
provide, the very meaning of CMS.
>You'd like to see the gray wedges take on a slightly bluish cast,
>to reflect the change in white point chromaticities
No I do *not* want that. Please:
1) Create a R=G=B wedge in D50 color-space
2) Create a R=G=B wedge in D65 color-space
3) show them side-by-side in Photoshop.
(use the same primaries and same gamma in both spaces, just change the
color temperature).
What the CMS should provide is: These wedges must *not* appear to be
exactly similar, D50 has different hue than D65.
>Yes, I see what you mean now. The codes are correctly converted from Source
>to Destination but the color appearance to the screen of the codes is not
>managed at all.
Exactly, color appearance is not managed correctly what comes to the
color-temperature of the RGB data.
Just show the R=G=B wedge that is in a D50 color-space with a system
that has the monitor calibrated to D93.
>Converting Document A using AbsCol from "D50 RGB gamma 2.2" to AdobeRGB
>results in a new set of codes AND every colors now becomes terribly yellow
>to the screen. This yellowness is objectionable, to say the least, and in
>your view quite unacceptable? You classify that as a bug. You say it should
>be a lot less yellow than what Photoshop makes it?
When you do this with your system (that has monitor that is hardware
calibrated to D50) the resulting yellow is only strong.
If you do the same using a system that has a monitor that is hardware
calibrated to D65 the resulting yellow is *far* more horrible.
>I was under the impression that all color conversions were handles by
>the underlying ColorSync engine. So maybe Apple is at fault.
Conversions are done by the color engine that is currently in use. But
it is not that the mathematical conversions algorithm would be
incorrect. ColorSync and MicrosoftICM are about as good, AdobeACE
also calculated correctly but it applies the strong slope-limiting.
It is that Photoshop ignores the color-temperature of the data that it
displays so it not using the color engine correctly when it takes the
RGB data from it's color-space and sends it to the monitor.
>And you're saying the same phenomenon applies in Photoshop
>for Windows?
Yes, it happens similarly on both OS.
Timo Autiokari
Greg
> It is not working correctly. The numerical RGB codes are calculated
> OK, but they are not correctly converted from the working-space to the
> monitor.
I specifically asked you to calculate the RGB values which should be sent to
the monitor (D65 Native PC),
which you did. They matched Photoshop's results, except for the
scaling/clipping. Your RGB values
*also* have a strong red/yellow cast on my D65 monitor, which I am extremely
doubtful will be fixed by
accurate calibration. Why is it that Photoshop is wrong, but your
calculations are
right? Your calculations haven't improved anything. The scaling does not
remove the yellow cast.
(just look at the numbers!)
>
> >Photoshop clips the D50 white, but other than that,
>
> What photoshop does is not gamut clipping, gamut clipping includes the
> adjustment of the hue. Photoshop just truncates the >255 and possibly
> the <0 RGB values, leaving the other channels unmanaged, this will
> cause hue errors to the truncated colors.
Just look at your RGB values which you gave me - even with the scaling they
have the
same red/yellow cast. Are you really telling me that the values you
calculated do *not* look
very yellow/red on *your * D65 monitor?
>
> Are you unable to try the D93 experiment that I have given you twice?
Ok then. Despite the fact that my first experiment was a failure (you
weren't able to produce
a D50 to D65 conversion which appeared to be any improvement over
Photoshop's),
I'll do your second experiment if you produce what you feel are the correct
pixel values which
should be send to a D93 monitor, so I have something to compare with.
>
> The D93 test will show you immediately that Photoshop is not managing
> the conversion from the working-space to the monitor space correctly.
>
> 1. Calibrate the hardware whitepoint of your monitor to D93 and
> profile that.
>
> 2) Open Photoshop create a R=G=B wedge in a D50 working-space.
>
> That wedge looks horribly bluish.
>
> Please do the above experiment then you will start to understand what
> the problem is and how it affects to appearance and to profile
> conversions.
What's wrong with the D50 to D65 test? Why not sort it out before moving on
to
this other test? It's exactly the same kind of test. We now have your
*quantitative*
results for D50 to D65.
What do others think about Timo's conversion results? Do they look
excessively yellow/red
on your D65 monitors?
Greg.
Greg
> > This is just not true. sRGB is both a working space *and* a "generic"
> > monitor profile.
> > It is designed for both. It is in fact the default monitor profile in
> > Windows, and Photoshop
> > has no trouble whatsoever using it for the monitor profile.
> >
> > Greg.
>
> Yes, PS has no trouble using it for the monitor profile but what good is
it?
> Did you ever look at a comparative 3D view of sRGB gamut vs a real,
measured
> CRT, like yours?
As I said, my Eye One Display arrives soon, so I really will be able to
measure it then.
> There are a host of blue and magenta colors from sRGB that
> a true CRT is simply not able to display.
You mean that *your* display is simply not able to display, surely.
> So, lot's of clipping in this
> region.
On *your* monitor.
> But maybe for the purpose of this discussion it is quite allright.
> Is that your point, Greg?
Yes, that's pretty much my point.
Have you read the sRGB specification, by the way?
Greg.
Greg
Also, according to a review of the Eye One Display here:
http://www.drycreekphoto.com/Learn/monitor_calibration.htm
it can clip very highly saturated colours. Perhaps this is part of the
reason for the reduction in gamut on your monitor?
Greg.
Greg
Also, I believe your monitor is calibrated to D50? sRGB is D65, so shouldn't
you be doing the gamut comparison
with your monitor calibrated to D65?
And how are you measuring the magnitude of the gamut loss you feel your
monitor has? Do you have any
quantitative results, to help me get a feel for how large the gamut loss is?
Perhaps do the following:
1. Calibrate your monitor to D65
2. Measure pure blue (0,0,255) with your Eye One
3: Compute the dE between your monitor's blue and sRGB
Does this sound reasonable?
Greg.
Greg
Another thing. When I told you that your pixel values that you calculated
looked excessively yellow on my
D65(ish) monitor, you then questioned the accuracy of my monitor. Yet, you
never questioned the accuracy
of my monitor when I told you I was using Photoshop - it was only after I
tried your results that you turned your
attention to my monitor.
Moreoever, you are asking me to make a qualitative judgement for your other
(D93) test, even *after* having
questioned the accuracy of my monitor. Why would you trust such a judgement
for the D93 test, and not the
D65 test?
Greg.
p.s I'll let you know as soon as I receive my Eye One and have calibrated my
monitor for D50,D65, and D93. (not all
at once)
Roger Breton
>> a true CRT is simply not able to display.
>
> You mean that *your* display is simply not able to display, surely.
My display is not that much different from the average hi-end graphic
display used in professional color reproduction. You'd fall off your chair
if you'd see what the color capablities of my other consumer grade NEC
MultiSync FE+700 17 inch monitor are! Pure trash in comparison.
>> So, lot's of clipping in this
>> region.
> On *your* monitor.
On the majority of hi-end pro monitors.
>> But maybe for the purpose of this discussion it is quite allright.
>> Is that your point, Greg?
>
> Yes, that's pretty much my point.
>
> Have you read the sRGB specification, by the way?
In which way? In the extent of colorant chromaticities? You mean gamut size?
What else is there to discuss in sRGB that would have any influence of its
capabilities relative to a "real" display? Gamma? FYI, I've read the specs
many times and I come back to it when in doubt.
Roger Breton
Roger Breton
The EyeOne can clip very saturated colors? I'd like to know on which base.
I'll look up your link but I am highly suspicious this has any bearing on
the color measurements. Always ready to learn.
Roger Breton
Greg
> When we have RGB codes in a specific color-space, these colors should
> be show on the monitor by absolute colorimetry. So that e.g. R=G=B
> wedge that is in a D50 color-space will always be shown so that it has
> the chromaticity of D50 (on the screen) no matter what the hardware
> color temperature of the monitor is. This is what Photoshop does not
> do. It always shows R=G=B codes on the screen using the hardware color
> temperature of the monitor, totally ignoring the color temperature of
> the color-space that the data is in.
This is untrue. Photoshop *does* do this when using soft proofing, if
absolute
intent is used. It does not do the XYZ scaling though.
Greg.
Roger Breton
I think this guy knows what he's talking about.
Some of what he has to say makes me doubt his credibility but overall his
treatment is good although his assessments lacks some hard evidence -- he
does not cite any figures, chromaticities, CIE Lab values, Delta E. Nada.
I doubt the rigour of one sentence which reads: "Play with your monitor
settings and decide which looks best".
Did you order the EyeOne display or the EyeOne pro spectrophotometer?
BTW, I went through the whole page and did not find any mention of "Eye One
Display clippping very highly saturated colours"? FYI, I calibrate my
display with a number of instruments including an EyeOne Pro.
Personnally, you can think what you want, I would not say that some
instrument "clips" colors. I'd say that the instrument's range is limited in
some way, perhaps in its detection threshold or otherwise exhibits
inacuracies in terms of xy +-.003. But 'clipping'? No, I never seen that
word in the context of its measurement characteristics. But don't get me
wrong, I respect every bit your opinion.
Roger Breton
Greg
> I think this guy knows what he's talking about.
Me too. In fact he's a very helpful person to talk to, too.
>
> Some of what he has to say makes me doubt his credibility but overall his
> treatment is good although his assessments lacks some hard evidence -- he
> does not cite any figures, chromaticities, CIE Lab values, Delta E. Nada.
I totally agree.
>
> I doubt the rigour of one sentence which reads: "Play with your monitor
> settings and decide which looks best".
Again, this bothers me too.
>
> Did you order the EyeOne display or the EyeOne pro spectrophotometer?
Just the Display.
>
> BTW, I went through the whole page and did not find any mention of "Eye
One
> Display clippping very highly saturated colours"?
I think I made a mistake - sorry. The sentence is: "The spectrophotometer
version did a better job with highly saturated colors,". I agree that this
is not saying that it "clipped" the colours. (further down, on the same
page, clipping is mentioned, but it's referring to a different product).
> FYI, I calibrate my
> display with a number of instruments including an EyeOne Pro.
>
> Personnally, you can think what you want, I would not say that some
> instrument "clips" colors. I'd say that the instrument's range is limited
in
> some way, perhaps in its detection threshold or otherwise exhibits
> inacuracies in terms of xy +-.003. But 'clipping'? No, I never seen that
> word in the context of its measurement characteristics. But don't get me
> wrong, I respect every bit your opinion.
It's possible that the profiling software is responsible for "clipping", not
the measuring device. (in fact
I think that same pages sort of says this?)
Thanks for respecting my opinion. I don't know nearly as much about colour
theory as most folks in this forum, but
I do feel that I can apply my engineering skills to the issues at hand in
this thread. We may reach a point at
which I cannot participate any further - I don't feel that we have reached
that point yet. (others may disagree ;^)
Greg.
Greg
Also, I thought you had the Eye One Display (the colorimeter version).
Appears I was wrong about that, in which case
I should not have even mentioned that comment in the Dry Creek Photo
review - it doesn't apply to you.
Greg.
Roger Breton
> Also, I believe your monitor is calibrated to D50? sRGB is D65, so shouldn't
> you be doing the gamut comparison with your monitor calibrated to D65?
I believe the gamut comparison can take place independently of white point
calibration but your point is well taken. Perhaps it does have some effect.
I can send you the ICC profile of my monitor you that you can see for
yourself what the 'normalized' coordinates of the primaries are. It turns
out that the difference is less than I hypothesized...
> And how are you measuring the magnitude of the gamut loss you feel your
> monitor has? Do you have any
> quantitative results, to help me get a feel for how large the gamut loss is?
I was counting on a gamut viewing tool I use to give me an estimate of the
total volume space of both gamuts, in DeltaE cube. Unfortunately, I just
found out that it only works on LUT type of profiles.
> Perhaps do the following:
> 1. Calibrate your monitor to D65
> 2. Measure pure blue (0,0,255) with your Eye One
> 3: Compute the dE between your monitor's blue and sRGB
OK. I can tell you in advance, for having done this many times using D65 as
a target white point chromaticities, that I come very close to hitting it
right on, in the order of less than 1 delta E. But the more revealing test
is to calculate the extent of DeltaE for all 6 primaries (RGBCMY). I have
one spreadsheet setup to do that calculation but I have to go one color at a
time. I'll get back to you on that.
> Does this sound reasonable?
Yes.
Roger Breton
Roger Breton
Well, I'm glad you have as I'm always on the lookoot for new information on
color management.
Thank you,
Roger Breton
Greg
> I believe the gamut comparison can take place independently of white point
> calibration but your point is well taken. Perhaps it does have some
effect.
> I can send you the ICC profile of my monitor you that you can see for
> yourself what the 'normalized' coordinates of the primaries are. It turns
> out that the difference is less than I hypothesized...
Thinking about this, I suspect the white point calibration would make a
difference.
The lower the temperature, the weaker the green and blue guns are driven,
with respect
to the red. This must surely equate to a *different* gamut, if not a lesser
gamut? (probably
a lesser gamut I think)
>
> > And how are you measuring the magnitude of the gamut loss you feel your
> > monitor has? Do you have any
> > quantitative results, to help me get a feel for how large the gamut loss
is?
>
> I was counting on a gamut viewing tool I use to give me an estimate of the
> total volume space of both gamuts, in DeltaE cube. Unfortunately, I just
> found out that it only works on LUT type of profiles.
Oh, that's a shame, because a DeltaE cube sounds very useful. I have never
used a
tool which can do that.
Greg.
Roger Breton
> difference.
> The lower the temperature, the weaker the green and blue guns are driven,
> with respect to the red. This must surely equate to a *different* gamut, if
not a lesser gamut? (probably a lesser gamut I think)
I never thought of the relationship between my choice of white point
calibration and gamut size? I know ISO-12646 mandates D50 and nothing else
but I never thought it would be at the expense of gamut size!!! I'll have to
pursue this.
>> I was counting on a gamut viewing tool I use to give me an estimate of the
>> total volume space of both gamuts, in DeltaE cube. Unfortunately, I just
>> found out that it only works on LUT type of profiles.
>
> Oh, that's a shame, because a DeltaE cube sounds very useful. I have never
> used a
> tool which can do that.
Well, I think all hope is not lost. I have another program in which I can
import a profile -- any profile -- and it will give me an estimate of gamut
volume in DeltaE cube!
More on that to follow.
Roger Breton
Greg
> >> So, lot's of clipping in this
> >> region.
> > On *your* monitor.
>
> On the majority of hi-end pro monitors.
That's interesting - you are saying that the majority of hi-end pro monitors
fall short of reproducing sRGB?
(in the blue & magenta areas only, yes?) If anything I would have thought
good quality pro monitors would
*exceed* sRGB. Very interesting indeed.
> In which way? In the extent of colorant chromaticities? You mean gamut
size?
Yes, exactly.
> What else is there to discuss in sRGB that would have any influence of its
> capabilities relative to a "real" display? Gamma? FYI, I've read the specs
> many times and I come back to it when in doubt.
That's ok - I wasn't sure how familiar you were with the specification,
that's all.
Greg.
Greg
> Doing so will NOT make the Hardware Whitepoint of your Monitor to be
> D65. System profile just tells to the CMS what the actual Hardware
> Whitepoint of your Monitor is. You need to make it so by using the
> hardware controls of the monitor adjusting, either visually using a
> good D65 reference light source or with a monitor calibration HW+SW
> package.
Yes, I know all that. My monitor is set to D65 with the hardware controls of
the monitor itself,
and I told Adobe Gamma to use the hardware setting. Is this ok for now,
while I wait for my calibrator to arrive?
Greg.
Greg
> Are you unable to try the D93 experiment that I have given you twice?
> Instead you just use your and my time for this kind of taunting, why?
>
> The D93 test will show you immediately that Photoshop is not managing
> the conversion from the working-space to the monitor space correctly.
>
> 1. Calibrate the hardware whitepoint of your monitor to D93 and
> profile that.
I set my monitor's hardware controls to 9300K, and used Adobe Gamma to
modify your Native PC
profile to use D93 rather than D65, re-tuned my gamma again (2.5, per your
profile), and saved the new
profile, and set it as my system default profile. (I removed all other
profiles from the list, just to make sure)
>
> 2) Open Photoshop create a R=G=B wedge in a D50 working-space.
>
> That wedge looks horribly bluish.
No, it does not. It looks neutral. Sure, when I set my display to D93, the
white does get very slightly more bluer
and brighter. However, Photoshop 7.01 produces what appears to be a very
neutral greyscale wedge.
When I switch to an absolute intent soft proof, it becomes horribly
*yellow*, but we've discussed this at length
already. Also, as final proof that the display is neutral, I did a screen
grab, and pasted the result back into a new
image in Photoshop - the pixel values are *perfectly* neutral.
>
> Please do the above experiment then you will start to understand what
> the problem is and how it affects to appearance and to profile
> conversions.
The result has not matched your expectations, and it has not helped me
understand anything yet.
Greg.
Greg
Are you sure this is the test you really wanted me to do? I suspect what you
really wanted me to do
was to create a D65 wedge, and view that with my monitor set to D50. In any
case, I've just done this,
and yes, it looks slightly blue, in an absolute soft proof. (it doesn't
look as badly blue as the reverse case looks yellow, though)
If this is the test you wanted me to do, I don't understand how it's really
any different to the first
test - it's just the direct opposite. The fact that it looks blue comes as
no surprise to me whatsoever.
I can *almost* believe that the colours Photoshop are displaying for the
D65 -> D50 absolute conversion
are correct. For the reverse case, it just looks too yellow for me to
believe, however it is wrong to
make any conclusions without actually doing some measurements. So, I do
still believe you that
the D50 -> D65 appearance is too yellow, but I'm still waiting for the
solution to this problem - as I said,
your conversion doesn't appear to be any better yet. At the moment, it
appears to me that commonly
accepted methods for performing absolute colorimetry just aren't very good,
but that seems ridiculous.
Greg.
Greg
I assume you wrote the below *before* you realised that your gamut viewer
was not producing
usable results for non-CLUT profiles? If so, I'll wait for your new
results.
Greg.
"Greg" <nos...@nowhere.com> wrote in message
news:400b...@duster.adelaide.on.net...
Roger Breton
>>>> region.
>>> On *your* monitor.
>>
>> On the majority of hi-end pro monitors.
>
> That's interesting - you are saying that the majority of hi-end pro monitors
> fall short of reproducing sRGB?
> (in the blue & magenta areas only, yes?) If anything I would have thought
> good quality pro monitors would
> *exceed* sRGB. Very interesting indeed.
Shame on me. I'll have to take some of that back and qualify my statement.
Right now I have to go. But I'll come back to this issue. I've compared the
gamut of my Mitsubishi 19inch to that of sRGB and, like I was saying in a
previous post yesterday night, it's much closer than I thought. There are
some differences in the blue and magenta. I'll have to quantify those
differences. And there are regions wher my CRT exceeds sRGB. So, my
appologies for being so prompt.
> That's ok - I wasn't sure how familiar you were with the specification,
> that's all.
I discipline myself to carefully exhaust every source of information I can
get get my hands on. But one of the problem of evaluating monitor gamut is
how their colorimetry is encoded per the ICC specs. As you know, when a
reading is made of the screen with an instrument, what we get is absolute
colorimetry. So, it goes, a monitor profile will have at minimum XYZ for
red, green and blue. So, one would think that different brands and makes of
monitors could be compared quantitatively by just comparing their RGB XYZ
tristimulus values. But not with ICC profiles. Because the primarie XYZ are
encoded in an adapted and normalized way. To effectively recover the
original abolute colorimetry is very, very hard -- at least for me. I have
an Excel spreadsheet that takes me from some RGB code to XYZ and Lab D50
through the data contained in a profile. But it's hard to go the other way
around.
In my case, had I had such a facility at my disposal it would have been a
cinsh to compare the gamut of my CRT and those of even more expensive CRT to
that or sRGB, quantitatively, and calculate DeltaEs and so on. The only
alternative I have is to resort to a 3D gamut viewer which operates on the
profile data. And I discover now that there are differences among gamut
viewers!
Regards,
Roger Breton
Greg
> As you know, when a
> reading is made of the screen with an instrument, what we get is absolute
> colorimetry.
I didn't really know that, but it sounds logical. :) (I have never taken a
measurement from a
screen - in fact - I have been wondering exactly what kinds of measurements
my Eye One Display
is going to be able to give me)
> So, it goes, a monitor profile will have at minimum XYZ for
> red, green and blue. So, one would think that different brands and makes
of
> monitors could be compared quantitatively by just comparing their RGB XYZ
> tristimulus values. But not with ICC profiles. Because the primarie XYZ
are
> encoded in an adapted and normalized way. To effectively recover the
> original abolute colorimetry is very, very hard -- at least for me.
I vaguely understand what you are saying, I think. Would it be correct to
say that the reason
it is so hard to make the quantitative comparison is largely because we
don't know how bright (in absolute terms)
a given monitor is capable of going? Or is it to do with the purity of the
phosphor's spectrum as the brightness
changes? (sorry if I'm asking silly questions)
Greg.
Roger Breton
> say that the reason
> it is so hard to make the quantitative comparison is largely because we
> don't know how bright (in absolute terms)
> a given monitor is capable of going?
On the one hand, there is the adaptation problem which I donšt quite know
how to rule out of the equation -- if at all it can be. On the other hand,
what is hard is comparing apples with apples. When you take readings with
your colorimeter, it should give you absolute colorimetry : Y is luminance
in Cd/m2, x and y are the chromaticities. The problem is that most software
will hide the absolute measurements from the user so all we see is the
'encoded' measurements and those are encoded in a special way inside a
monitor profile. What's difficult then is to have some kind of absolute
basis to compare with the colorimetry of an idealized system like sRGB.
Roger Breton
Greg
gamma 2.2. (there's no option for a gamma of 2.5)
Something very suspicious has occurred. When I create a D50 wedge, and view
it in Photoshop using an absolute proof,
it barely changes at all. At first I thought that profiling my display had
fixed the problem with the yellow cast, but I think
something else must be going on, because it's not yellow *enough* now! I
have a suspicion that Photoshop is having
trouble with my display profile. (although Photoshop certainly doesn't
complain about it when opening Photoshop)
Picture Window Pro behaves similarly, but only when using the Microsoft
engine. When
I select the Little CMS engine, a D65 wedge looks very blue, even though my
display
is calibrated to D65!! What a mess. I'll have to contact Gretagmacbeth about
this. :(
Greg.
Greg
comp.graphics.apps.photoshop.
It's looking *very* much like a blatant bug in the Eye One Match software.
Greg.
Greg
I've used the Little CMS display profiler with my Eye One Display puck, to
measure the colour temperature with my monitor set
the way it was during the testing I reported on earlier. With my display
controls set to 6500K, the measured temperature is
6661K, which I assume is close enough for the purposes of our tests,
considering that we are talking about quite strong
colour casts, especially in the case of the D50 wedge to D65 display. I have
not yet bothered measuring the temperature
when my monitor set set to 9300K.
I'm also quite confident that my gamma was set reasonably close to 2.5,
after having cross checked (albeit in a rather indirect way) with my Eye
One.
So at the moment I stand by all my earlier judgements on colour cast
appearances.
I didn't receive any software with my Eye One Display that will allow me to
make quantitative "measurements" of colours on the screen - the closest
thing I have to this at the moment is the Little CMS display profiler, which
at least allows me to interrogate the colour temperature of my monitor,
after having made a profile. I'm hoping that I can find a utility somewhere
to allow me to make measurements.
Greg.
Timo Autiokari
>So at the moment I stand by all my earlier
>judgements on colour cast appearances.
So it is your opinion that Photoshop is working correctly when:
an R=G=B wedge in that is in a D50 color-space
and
an R=G=B wedge in that is in a D65 color-space
appear to have exactly similar grayness when shown side by side in
Photoshop .
And it is your opinion also that the subsequent ICC profile
conversions will have correct results also, when applied to these
wedges.
Phew, I admit it, I'm unable to explain this Photoshop CMS fault to
you.
Timo Autiokari
Greg
> On Wed, 21 Jan 2004 00:19:47 +1100, "Greg" <nos...@nowhere.com> wrote:
>
> >So at the moment I stand by all my earlier
> >judgements on colour cast appearances.
>
> So it is your opinion that Photoshop is working correctly when:
>
> an R=G=B wedge in that is in a D50 color-space
> and
> an R=G=B wedge in that is in a D65 color-space
>
> appear to have exactly similar grayness when shown side by side in
> Photoshop .
This is not true. Photoshop is capable of performing soft proofing, and when
the absolute intent is selected in the soft proof, they are *not* the same
colour.
It is very easy to set up the soft proofing.
However (and I have said this so many times now!) I agree that there appears
to be
excessive colour cast with the absolute soft proofing, especially when
viewing a D50 wedge
on a D65 display. Going the other way (D65 wedge viewed on D50 display), the
colour
cast seems less severe.
>
> And it is your opinion also that the subsequent ICC profile
> conversions will have correct results also, when applied to these
> wedges.
The only difference between Photoshop and your calculations is the XYZ
scaling,
to prevent gamut clipping, as you yourself have proven. Photoshop doesn't
do the scaling,
and so yes, it clips, producing incorrect colours, but only when the
clipping occurs.
For example, viewing a 21-step D50 wedge, *only* the pure white
(255,255,255)
is out of gamut of sRGB, and so it is only this patch which is being shown
incorrectly
by Photoshop. All other patches can be displayed correctly.
Greg.
Timo Autiokari
>This is not true.
It is completely true Mr. Greg@Nowhere
>Photoshop is capable of performing soft proofing, and when
>the absolute intent is selected in the soft proof, they are *not*
>the same colour.
Softproofing is not under the discussion in this thread. No-one have
said that soft-proofing would be faulty. But we really should not be
required to do softproofing just for the for monitor (pre)viewing.
And softproofing does NOT help to the problem at all:
Two people, say a Photographer and his Client
should be able to see a photo (that has an embedded
ICC profile) exactly similarly in Photoshop on their own
systems without communicating about monitor calibration
issues and softproofing settings on the phone.
Please stop here and think. Then read the above chapter again and
think again. At least try.
>The only difference between Photoshop and your calculations
>is the XYZ scaling, to prevent gamut clipping, as you yourself
>have proven.
So the numerical RGB values are calculated OK. But the view in
Photoshop document window is incorrect.
>For example, viewing a 21-step D50 wedge, *only* the pure
>white (255,255,255) is out of gamut of sRGB, and so it is only
>this patch which is being shown incorrectly by Photoshop.
There are 256 "patches" of R=G=B codes in 8-bit/c photos and some 40
of them (in the highlights) are shown incorrectly by Photoshop after
Absolute conversion from a D65 gamma 1.8 space to a D50 gamma 1.8
space and that is a huge amount considering the steep gamma. But those
are just for the R=G=B codes, there will be *far* more "challenging"
color errors with out-of-gamut *color* codes. But this bug is not the
bug that is under the discussion in this thread and it can be avoided
by the very well known trick: Before the conversion scale the image
down (say to level 128) and after the conversion scale it back up as
much as possible (naturally editing has to be done in the 15-bit/c per
channel mode).
Timo Autiokari
Greg
> Softproofing is not under the discussion in this thread. No-one have
> said that soft-proofing would be faulty. But we really should not be
> required to do softproofing just for the for monitor (pre)viewing.
I disagree. Normally, Photoshop does relative conversions from the image
space to the
monitor space, and it does this correctly as well. Naturally, this will make
a grey wedge
appear perfectly neutral. If you want to see the image with exactly the
right colours,
use an absolute soft proof.
>
> And softproofing does NOT help to the problem at all:
>
> Two people, say a Photographer and his Client
> should be able to see a photo (that has an embedded
> ICC profile) exactly similarly in Photoshop on their own
> systems without communicating about monitor calibration
> issues and softproofing settings on the phone.
>
> Please stop here and think. Then read the above chapter again and
> think again. At least try.
If two people really do want to see the colours
*exactly* the same, I think it is reasonable to use soft proofing.
>
> >The only difference between Photoshop and your calculations
> >is the XYZ scaling, to prevent gamut clipping, as you yourself
> >have proven.
>
> So the numerical RGB values are calculated OK. But the view in
> Photoshop document window is incorrect.
>
> There are 256 "patches" of R=G=B codes in 8-bit/c photos and some 40
> of them (in the highlights) are shown incorrectly by Photoshop after
> Absolute conversion from a D65 gamma 1.8 space to a D50 gamma 1.8
> space and that is a huge amount considering the steep gamma. But those
> are just for the R=G=B codes, there will be *far* more "challenging"
> color errors with out-of-gamut *color* codes. But this bug is not the
> bug that is under the discussion in this thread and it can be avoided
> by the very well known trick: Before the conversion scale the image
> down (say to level 128) and after the conversion scale it back up as
> much as possible (naturally editing has to be done in the 15-bit/c per
> channel mode).
Of course there will be more patches if the image has more patches in it.
I don't want to get into a discussion about exactly how Photoshop does the
gamma adjustments,
and yes, I am restricting my comments to the greyscale.
The main point I'm trying to make is this. Even when I view *your*
calculated conversion
from ColorMatch to NativePC (D65), it *still* looks overly red/yellow. You
haven't
solved the problem yet.
Greg.
Roger Breton
> make quantitative "measurements" of colours on the screen - the closest
> thing I have to this at the moment is the Little CMS display profiler, which
> at least allows me to interrogate the colour temperature of my monitor,
> after having made a profile. I'm hoping that I can find a utility somewhere
> to allow me to make measurements.
>
> Greg.
Greg,
You can download an install ProfileMakerPro's free MeasureTool which I
believe will drive your EyeOne Display. That way, you'll be able to make
direct measurements of your screen.
Roger Breton
Greg
> You can download an install ProfileMakerPro's free MeasureTool which I
> believe will drive your EyeOne Display. That way, you'll be able to make
> direct measurements of your screen.
Thanks Roger. If you're right, it's a bit strange that the supplied Eye One
Share program can't also
use the Eye One Display monitor puck - this program seems to only be able to
make reflective
measurements, not emissive. But I'll give that Measure Tool a try - fingers
crossed.
Greg.
Greg
get
it to produce accurate measurements with my monitor puck. :( For example, if
I measure pure white on my D65 monitor, it returns a colour value which has
quite
a strong cyan cast.
I think it's highly unlikely that the puck is defective, given that I'm able
to create
usable display profiles, the puck passes the diagnostics, and that the
measured
colour temperature of my monitor matches closely to the hardware settings
of my monitor. (Eye One Match always writes a whitepoint of D50 into the ICC
profile, but that's a seperate issue)
Rather, I suspect the Measure Tool doesn't support the new Eye One Display
puck. (in the list of devices in the Measure Tool, I see "Eye One
Display(CRT)", and "Eye One Display(LCD)",
but no entry for just "Eye One Display" - my puck does *both* CRTs and LCDs.
I've tried selecting both
devices, but both return the same results)
Have contacted Eye One support again.
Greg.
Greg
D65, etc, has already
been done to death (almost), way back in year 2000. Search for the subject
"sRGB and absolute colorimetric intents".
It's in this same newsgroup - sci.engr.color, too.
Marti Maria ended up putting two monitors side by side, set to two different
colour temperatures,
and displaying the same image on both. This is exactly the sort of test I
want to do. :)
His impression was that they looked pretty close.
I'm actually surprised at Marti's results, despite the fact that the result
is what theory would predict would
happen. I'm still in agreement with Timo that the result of the absolute
intent conversion from D50 to D65 looks excessively
yellow.
I still can't make spot measurements with my monitor puck, so out of
desperation, I am in fact going to resort to
using my digital camera. Stay tuned. ;^)
Greg.