Custom Illuminant

[r***@public.gmane.org]

Hello Graeme,



I've checked various documents, including this one
http://www.computer-darkroom.com/softproof/softproof_1.htm and Photoshop
does simulate paper color with all the rendering intents, as I can see when
I do a soft-proof.



I would really like to understand what Photoshop is doing. I have a contact
in Adobe who should be able to point me in the right direction. However
before doing that I would like to understand what is happening at the
profile level.



A print made from a profile that uses an sp file is identical to a print
made with a profile that does not use the sp file. So I assume that the
BtoA (PCS to Printer) is at D50 and is not affected by the custom
illuminant. Is that correct?



If the profile made with the sp file is used for soft-proofing, the paper
white is adjusted correctly (I've also tried different illuminants like A,
F5 etc, all appearing correct). So I assume that the AtoB (Printer to PCS)
does take into account the custom illuminant. Is that correct?



Does this apply to all the rendering intents, or only to Absolute
Colorimetric (as I think you said)?



Is this (or whatever method you use) also applied to FWA compensation (if -i
and -f both specify the custom .sp file)?



I've read your documentation and purchased your paper on FWA compensation,
but I still can't make much sense of what's happening.



Thanks,



Robert

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and Photoshop
> does simulate paper color with all the rendering intents, as I can see when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper white
on the display), or a partial simulation (i.e. representing the paper white
adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting
at the latter. Photoshop having a "Simulate Paper Color" button
doesn't help clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a contact
> in Adobe who should be able to point me in the right direction. However
> before doing that I would like to understand what is happening at the
> profile level.

> A print made from a profile that uses an sp file is identical to a print
> made with a profile that does not use the sp file. So I assume that the
> BtoA (PCS to Printer) is at D50 and is not affected by the custom
> illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed)
to have the white point be exactly D50. So using any non-absolute
colorimetric B2A will (superficially) seem much like the B2A from
a default D50 illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail
that you will see differences, and these depend on the spectral
characteristics of the inks.

> If the profile made with the sp file is used for soft-proofing, the paper
> white is adjusted correctly (I've also tried different illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based
on the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation (if -i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by
the spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA compensation,
> but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles
are actually doing. The latter is the hard part because typically the
software vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process
is one of comparing what software does with reference implementations such
as the ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[r***@public.gmane.org]

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and Photoshop
> does simulate paper color with all the rendering intents, as I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white
on the display), or a partial simulation (i.e. representing the paper white
adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting
at the latter. Photoshop having a "Simulate Paper Color" button
doesn't help clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction. However
> before doing that I would like to understand what is happening at the
> profile level.

> A print made from a profile that uses an sp file is identical to a print
> made with a profile that does not use the sp file. So I assume that the
> BtoA (PCS to Printer) is at D50 and is not affected by the custom
> illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed)
to have the white point be exactly D50. So using any non-absolute
colorimetric B2A will (superficially) seem much like the B2A from
a default D50 illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail
that you will see differences, and these depend on the spectral
characteristics of the inks.

> If the profile made with the sp file is used for soft-proofing, the paper
> white is adjusted correctly (I've also tried different illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based
on the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by
the spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA compensation,
> but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles
are actually doing. The latter is the hard part because typically the
software vendors give you no clue, and hide behind inscrutable "user
friendly"
buttons such as "Simulate Paper Color". That's why often the process
is one of comparing what software does with reference implementations such
as the ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know
exactly
what's happening.

Graeme Gill.

[Roger Breton]

Robert,

You wrote " I guess that this will work as the absolute AtoB transform will
only affect the white point (or gray line).".
In case I don't understand your meaning, the AbsCol to the screen affect
*all* colors, not just the white and the grays.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 07:29
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and
> Photoshop does simulate paper color with all the rendering intents, as
> I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white on the display), or a partial simulation (i.e. representing the paper
white adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting at the
latter. Photoshop having a "Simulate Paper Color" button doesn't help
clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction.
> However before doing that I would like to understand what is happening
> at the profile level.

> A print made from a profile that uses an sp file is identical to a
> print made with a profile that does not use the sp file. So I assume
> that the BtoA (PCS to Printer) is at D50 and is not affected by the
> custom illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed) to
have the white point be exactly D50. So using any non-absolute colorimetric
B2A will (superficially) seem much like the B2A from a default D50
illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail that you will
see differences, and these depend on the spectral characteristics of the
inks.

> If the profile made with the sp file is used for soft-proofing, the
> paper white is adjusted correctly (I've also tried different
> illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based on
the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation
> (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by the
spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA
> compensation, but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles are
actually doing. The latter is the hard part because typically the software
vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process is one
of comparing what software does with reference implementations such as the
ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[r***@public.gmane.org]

Hello Roger,

What I meant is that Absolute rendering, in moving the gray line shifts all
colors by the same amount (as opposed to a proportional shift as in
Relative).

It would seem to me that there is still the potential for out-of-gamut
clipping to the working space as a result of the shifting of the colors.
Would that be the case?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 14:34
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

You wrote " I guess that this will work as the absolute AtoB transform will
only affect the white point (or gray line).".
In case I don't understand your meaning, the AbsCol to the screen affect
*all* colors, not just the white and the grays.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 07:29
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and
> Photoshop does simulate paper color with all the rendering intents, as
> I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white on the display), or a partial simulation (i.e. representing the paper
white adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting at the
latter. Photoshop having a "Simulate Paper Color" button doesn't help
clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction.
> However before doing that I would like to understand what is happening
> at the profile level.

> A print made from a profile that uses an sp file is identical to a
> print made with a profile that does not use the sp file. So I assume
> that the BtoA (PCS to Printer) is at D50 and is not affected by the
> custom illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed) to
have the white point be exactly D50. So using any non-absolute colorimetric
B2A will (superficially) seem much like the B2A from a default D50
illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail that you will
see differences, and these depend on the spectral characteristics of the
inks.

> If the profile made with the sp file is used for soft-proofing, the
> paper white is adjusted correctly (I've also tried different
> illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based on
the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation
> (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by the
spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA
> compensation, but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles are
actually doing. The latter is the hard part because typically the software
vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process is one
of comparing what software does with reference implementations such as the
ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[Roger Breton]

Robert,

Yes, all colors are shifted by the same amount, it's a linear
transformation.

Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image in
AbsCol. By definition all CMYK colors are in gamut. The Working Spaces are
completely unrelated to this viewing situation, unless, for some reason, no
CMYK profile is assigned to the image, in which case, yes, Photoshop would
use the CMYk Working Space to do the AbsCol rendering to the screen.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 14:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hello Roger,

What I meant is that Absolute rendering, in moving the gray line shifts all
colors by the same amount (as opposed to a proportional shift as in
Relative).

It would seem to me that there is still the potential for out-of-gamut
clipping to the working space as a result of the shifting of the colors.
Would that be the case?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 14:34
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

You wrote " I guess that this will work as the absolute AtoB transform will
only affect the white point (or gray line).".
In case I don't understand your meaning, the AbsCol to the screen affect
*all* colors, not just the white and the grays.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 07:29
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and
> Photoshop does simulate paper color with all the rendering intents, as
> I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white on the display), or a partial simulation (i.e. representing the paper
white adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting at the
latter. Photoshop having a "Simulate Paper Color" button doesn't help
clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction.
> However before doing that I would like to understand what is happening
> at the profile level.

> A print made from a profile that uses an sp file is identical to a
> print made with a profile that does not use the sp file. So I assume
> that the BtoA (PCS to Printer) is at D50 and is not affected by the
> custom illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed) to
have the white point be exactly D50. So using any non-absolute colorimetric
B2A will (superficially) seem much like the B2A from a default D50
illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail that you will
see differences, and these depend on the spectral characteristics of the
inks.

> If the profile made with the sp file is used for soft-proofing, the
> paper white is adjusted correctly (I've also tried different
> illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based on
the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation
> (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by the
spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA
> compensation, but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles are
actually doing. The latter is the hard part because typically the software
vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process is one
of comparing what software does with reference implementations such as the
ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[r***@public.gmane.org]

Hi Roger,

Hi Roger,

I'm thinking of a soft-proofing round-trip (with Simulate paper) from, say,
Adobe RGB, to an RGB printer profile and back (with Relative Colorimetric
selected as the soft-proofing intent).

So RelCol from ARGB to PCS, RelCol from PCS to RGBDest, AbsCol from RGBDest
to PCS, RelCol from PCS to ARGB.

There could be gamut-clipping from PCS to RGBDest (which is OK from a
soft-proofing point of view).

There could also be a gamut-clipping from PCS to ARGB, I think, which would
not be OK from a soft-proofing point of view. The reason I think there could
be clipping is that the AbsCol from RGBDest to PCS will shift the colors and
so some of these may no longer be within the ARGB gamut.

If the selected soft-proofing intent is Perceptual then it could be worse:
if the printer gamut is larger than ARGB, the perceptual mapping will
stretch the ARGB gamut to the RGBDest gamut so that there will be clipping
to the ARGB space on the PCS to ARGB RelCol mapping. So in addition to the
potential AbsCol color-shift clipping there could be clipping due to the
ARGB space being smaller than the RGBDest space (good reason to use ProPhoto
or bigger?).

Is that correct? I'm fairly woolly on this whole subject, as you can
probably see.

Cheers,

Robert



-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 21:36
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

Yes, all colors are shifted by the same amount, it's a linear
transformation.

Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image in
AbsCol. By definition all CMYK colors are in gamut. The Working Spaces are
completely unrelated to this viewing situation, unless, for some reason, no
CMYK profile is assigned to the image, in which case, yes, Photoshop would
use the CMYk Working Space to do the AbsCol rendering to the screen.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 14:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hello Roger,

What I meant is that Absolute rendering, in moving the gray line shifts all
colors by the same amount (as opposed to a proportional shift as in
Relative).

It would seem to me that there is still the potential for out-of-gamut
clipping to the working space as a result of the shifting of the colors.
Would that be the case?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 14:34
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

You wrote " I guess that this will work as the absolute AtoB transform will
only affect the white point (or gray line).".
In case I don't understand your meaning, the AbsCol to the screen affect
*all* colors, not just the white and the grays.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 07:29
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and
> Photoshop does simulate paper color with all the rendering intents, as
> I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white on the display), or a partial simulation (i.e. representing the paper
white adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting at the
latter. Photoshop having a "Simulate Paper Color" button doesn't help
clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction.
> However before doing that I would like to understand what is happening
> at the profile level.

> A print made from a profile that uses an sp file is identical to a
> print made with a profile that does not use the sp file. So I assume
> that the BtoA (PCS to Printer) is at D50 and is not affected by the
> custom illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed) to
have the white point be exactly D50. So using any non-absolute colorimetric
B2A will (superficially) seem much like the B2A from a default D50
illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail that you will
see differences, and these depend on the spectral characteristics of the
inks.

> If the profile made with the sp file is used for soft-proofing, the
> paper white is adjusted correctly (I've also tried different
> illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based on
the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation
> (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by the
spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA
> compensation, but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles are
actually doing. The latter is the hard part because typically the software
vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process is one
of comparing what software does with reference implementations such as the
ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[Roger Breton]

Robert,

By design, the clipping already occurs right at the Device to PCS stage. By
the time RGB has been converted to PCS, the damage is done. So, to use
RelCol or AbsCol to view the converted or simulated data afterward is
irrelevant, as far as clipping is concerned.

BTW, in your chain of conversion, can you confirm that your printer is
profiled in RGB? I think that's what it is but don't have your original
post.

Perceptual is the same as RelCol is the same as AbsCol when converting
between "Display" RGB color spaces, such as between aRGB and sRGB or between
ProPhotoRGB and aRGB. AbsCol is different when converting to an RGB Output
Device such as your Epson printer.

For soft-proofing, Perceptual Intent is never used, by definition. Not
because of "possible" gamut clipping but because it is not colorimetrically
correct.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 18:07
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi Roger,

Hi Roger,

I'm thinking of a soft-proofing round-trip (with Simulate paper) from, say,
Adobe RGB, to an RGB printer profile and back (with Relative Colorimetric
selected as the soft-proofing intent).

So RelCol from ARGB to PCS, RelCol from PCS to RGBDest, AbsCol from RGBDest
to PCS, RelCol from PCS to ARGB.

There could be gamut-clipping from PCS to RGBDest (which is OK from a
soft-proofing point of view).

There could also be a gamut-clipping from PCS to ARGB, I think, which would
not be OK from a soft-proofing point of view. The reason I think there could
be clipping is that the AbsCol from RGBDest to PCS will shift the colors and
so some of these may no longer be within the ARGB gamut.

If the selected soft-proofing intent is Perceptual then it could be worse:
if the printer gamut is larger than ARGB, the perceptual mapping will
stretch the ARGB gamut to the RGBDest gamut so that there will be clipping
to the ARGB space on the PCS to ARGB RelCol mapping. So in addition to the
potential AbsCol color-shift clipping there could be clipping due to the
ARGB space being smaller than the RGBDest space (good reason to use ProPhoto
or bigger?).

Is that correct? I'm fairly woolly on this whole subject, as you can
probably see.

Cheers,

Robert



-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 21:36
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

Yes, all colors are shifted by the same amount, it's a linear
transformation.

Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image in
AbsCol. By definition all CMYK colors are in gamut. The Working Spaces are
completely unrelated to this viewing situation, unless, for some reason, no
CMYK profile is assigned to the image, in which case, yes, Photoshop would
use the CMYk Working Space to do the AbsCol rendering to the screen.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 14:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hello Roger,

What I meant is that Absolute rendering, in moving the gray line shifts all
colors by the same amount (as opposed to a proportional shift as in
Relative).

It would seem to me that there is still the potential for out-of-gamut
clipping to the working space as a result of the shifting of the colors.
Would that be the case?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 14:34
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

You wrote " I guess that this will work as the absolute AtoB transform will
only affect the white point (or gray line).".
In case I don't understand your meaning, the AbsCol to the screen affect
*all* colors, not just the white and the grays.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 07:29
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and
> Photoshop does simulate paper color with all the rendering intents, as
> I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white on the display), or a partial simulation (i.e. representing the paper
white adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting at the
latter. Photoshop having a "Simulate Paper Color" button doesn't help
clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction.
> However before doing that I would like to understand what is happening
> at the profile level.

> A print made from a profile that uses an sp file is identical to a
> print made with a profile that does not use the sp file. So I assume
> that the BtoA (PCS to Printer) is at D50 and is not affected by the
> custom illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed) to
have the white point be exactly D50. So using any non-absolute colorimetric
B2A will (superficially) seem much like the B2A from a default D50
illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail that you will
see differences, and these depend on the spectral characteristics of the
inks.

> If the profile made with the sp file is used for soft-proofing, the
> paper white is adjusted correctly (I've also tried different
> illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based on
the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation
> (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by the
spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA
> compensation, but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles are
actually doing. The latter is the hard part because typically the software
vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process is one
of comparing what software does with reference implementations such as the
ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[r***@public.gmane.org]

Roger,

I forgot to reply to your question: my printer is an RGB printer (HP Z3100).

Regarding the color shifting that occurs with AbsCol ... I had assumed that
this is proportional to the luminance (so that at the white point the D50
white is shifted fully to the white point in the wtpt tag). However if the
shifting is done using a 3x3 matrix then it must mean that all colors are
shifted by the same amount. Or is the transform modified by the bkpt-wtpt
line to make the shifting proportional? It would seem to me that shifting
all colors by the same amount irrespective of luminance level would be a
pretty lunatic thing to do ... but then perhaps I have gone through a few
inversions and transforms myself :).

Also, when we talk about colors being 'shifted' ... I take it that the only
colors that actually get changed are the RGB output values. The AbsCol
'shift' in the PCS is just redefining the position of the white (and
presumably black) point ... is that correct?

Cheers,

Robert



-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 03 July 2014 03:05
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

By design, the clipping already occurs right at the Device to PCS stage. By
the time RGB has been converted to PCS, the damage is done. So, to use
RelCol or AbsCol to view the converted or simulated data afterward is
irrelevant, as far as clipping is concerned.

BTW, in your chain of conversion, can you confirm that your printer is
profiled in RGB? I think that's what it is but don't have your original
post.

Perceptual is the same as RelCol is the same as AbsCol when converting
between "Display" RGB color spaces, such as between aRGB and sRGB or between
ProPhotoRGB and aRGB. AbsCol is different when converting to an RGB Output
Device such as your Epson printer.

For soft-proofing, Perceptual Intent is never used, by definition. Not
because of "possible" gamut clipping but because it is not colorimetrically
correct.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 18:07
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi Roger,

Hi Roger,

I'm thinking of a soft-proofing round-trip (with Simulate paper) from, say,
Adobe RGB, to an RGB printer profile and back (with Relative Colorimetric
selected as the soft-proofing intent).

So RelCol from ARGB to PCS, RelCol from PCS to RGBDest, AbsCol from RGBDest
to PCS, RelCol from PCS to ARGB.

There could be gamut-clipping from PCS to RGBDest (which is OK from a
soft-proofing point of view).

There could also be a gamut-clipping from PCS to ARGB, I think, which would
not be OK from a soft-proofing point of view. The reason I think there could
be clipping is that the AbsCol from RGBDest to PCS will shift the colors and
so some of these may no longer be within the ARGB gamut.

If the selected soft-proofing intent is Perceptual then it could be worse:
if the printer gamut is larger than ARGB, the perceptual mapping will
stretch the ARGB gamut to the RGBDest gamut so that there will be clipping
to the ARGB space on the PCS to ARGB RelCol mapping. So in addition to the
potential AbsCol color-shift clipping there could be clipping due to the
ARGB space being smaller than the RGBDest space (good reason to use ProPhoto
or bigger?).

Is that correct? I'm fairly woolly on this whole subject, as you can
probably see.

Cheers,

Robert



-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 21:36
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

Yes, all colors are shifted by the same amount, it's a linear
transformation.

Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image in
AbsCol. By definition all CMYK colors are in gamut. The Working Spaces are
completely unrelated to this viewing situation, unless, for some reason, no
CMYK profile is assigned to the image, in which case, yes, Photoshop would
use the CMYk Working Space to do the AbsCol rendering to the screen.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 14:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hello Roger,

What I meant is that Absolute rendering, in moving the gray line shifts all
colors by the same amount (as opposed to a proportional shift as in
Relative).

It would seem to me that there is still the potential for out-of-gamut
clipping to the working space as a result of the shifting of the colors.
Would that be the case?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 02 July 2014 14:34
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

You wrote " I guess that this will work as the absolute AtoB transform will
only affect the white point (or gray line).".
In case I don't understand your meaning, the AbsCol to the screen affect
*all* colors, not just the white and the grays.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 2 juillet 2014 07:29
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi,

I think I have a somewhat better understanding of what's going on now.

What Photoshop does when simulating paper color is to do a normal transform
from the PCS to the destination using the chosen intent and then it does an
Absolute transform from destination back to the PCS. I guess that this will
work as the absolute AtoB transform will only affect the white point (or
gray line).

Certainly modifying the wtpt (and bkpt) values in the profile to match the
paper under the particular illuminant does give a very accurate soft-proof
when the paper and monitor image are viewed side-by-side.

I'm confused about what happens if we do a round-trip conversion from, say
ProPhoto to Destination and back to ProPhoto using a Perceptual intent
(say).

What I would expect would be:
1. ProPhoto->PCS: Relative (since the working space uses a
matrix-based profile). Uses ProPhoto Profile.
2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
4. PCS->ProPhoto: Relative. Uses ProPhoto profile.

If that was the case then I would expect to see a change at 3, which I do if
I use a profile made using i1Profiler or using the canned paper profile.
However I see no difference (or can measure no difference using an i1Pro)
using an Argyll-generated profile. This is affecting the soft-proofing,
which (I presume) uses a round-trip as above.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 25 June 2014 07:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've checked various documents, including this one
> http://www.computer-darkroom.com/softproof/softproof_1.htm and
> Photoshop does simulate paper color with all the rendering intents, as
> I can see
when
> I do a soft-proof.

Hi,

Right, but is that a full simulation (i.e. representing the absolute paper
white on the display), or a partial simulation (i.e. representing the paper
white adapted to the display D65 white point ?).

The document you refer to mentions "Relative Colorimetric", hinting at the
latter. Photoshop having a "Simulate Paper Color" button doesn't help
clarify what it's actually doing either.

> I would really like to understand what Photoshop is doing. I have a
contact
> in Adobe who should be able to point me in the right direction.
> However before doing that I would like to understand what is happening
> at the profile level.

> A print made from a profile that uses an sp file is identical to a
> print made with a profile that does not use the sp file. So I assume
> that the BtoA (PCS to Printer) is at D50 and is not affected by the
> custom illuminant. Is that correct?

No, that's not correct. Using a custom illuminant and/or observer changes
the XYZ numbers and possibly the relationship between the XYZ numbers, but
ICC color profiles are all normalized (i.e. chromatically transformed) to
have the white point be exactly D50. So using any non-absolute colorimetric
B2A will (superficially) seem much like the B2A from a default D50
illuminant and 1931 standard observer XYZ values.
It's only when you examine the profiles in some more detail that you will
see differences, and these depend on the spectral characteristics of the
inks.

> If the profile made with the sp file is used for soft-proofing, the
> paper white is adjusted correctly (I've also tried different
> illuminants like A,
> F5 etc, all appearing correct). So I assume that the AtoB (Printer to
PCS)
> does take into account the custom illuminant. Is that correct?

No, see above. Both the A2B and B2A tables will be different if a different
illuminant and/or observer are used. The B2A table is created by inverting
the device characterization A2B table.

> Does this apply to all the rendering intents, or only to Absolute
> Colorimetric (as I think you said)?

See above - all the tables will be affected, because they are all based on
the same measurement values. The differences between default and custom
illuminant and/or observer are likely to be larger and more obvious when
comparing the absolute colorimetric intent though.

> Is this (or whatever method you use) also applied to FWA compensation
> (if
-i
> and -f both specify the custom .sp file)?

Yes. FWA compensation more accurately simulates the effect of U.V. in the
illuminant on the FWA/OBE in the paper, so naturally this is affected by the
spectrum (ie. the level of U.V.) in the custom illuminant.

> I've read your documentation and purchased your paper on FWA
> compensation, but I still can't make much sense of what's happening.

To have a precise understanding means comprehending the basic color science,
understanding what the profiling process and profiles are doing, and (the
hard part), figuring out what the applications that use the profiles are
actually doing. The latter is the hard part because typically the software
vendors give you no clue, and hide behind inscrutable "user friendly"
buttons such as "Simulate Paper Color". That's why often the process is one
of comparing what software does with reference implementations such as the
ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know exactly
what's happening.

Graeme Gill.

[Graeme Gill]

Roger Breton wrote:

> Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image in
> AbsCol. By definition all CMYK colors are in gamut.

In gamut for the CMYK device, but not necessarily in gamut for the
proofing device or display.

Graeme Gill.

[Roger Breton]

You are right, clipping will happen in transforming the most saturated CMYK
values to the monitor, depending on the gamut size of the monitor space.
Soft proofing the saturated cyans, for example, requires a very large
NEC-like or Eizo or HP Dreamweaver-like kind of monitor to accurately view
the data without clipping. Thank's.

Sorry Robert.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 3 juillet 2014 02:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Roger Breton wrote:

> Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image
> in AbsCol. By definition all CMYK colors are in gamut.

In gamut for the CMYK device, but not necessarily in gamut for the proofing
device or display.

Graeme Gill.

[r***@public.gmane.org]

Well Roger, I'm the one who's sorry for asking all these dumb questions!

I'm doing a bit more reading up and then I'll have some more dumb questions,
I'm afraid!

Many thanks for your help,

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 03 July 2014 12:44
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

You are right, clipping will happen in transforming the most saturated CMYK
values to the monitor, depending on the gamut size of the monitor space.
Soft proofing the saturated cyans, for example, requires a very large
NEC-like or Eizo or HP Dreamweaver-like kind of monitor to accurately view
the data without clipping. Thank's.

Sorry Robert.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 3 juillet 2014 02:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Roger Breton wrote:

> Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image
> in AbsCol. By definition all CMYK colors are in gamut.

In gamut for the CMYK device, but not necessarily in gamut for the proofing
device or display.

Graeme Gill.

[Roger Breton]

Keep them coming ;-)

Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 3 juillet 2014 13:22
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Well Roger, I'm the one who's sorry for asking all these dumb questions!

I'm doing a bit more reading up and then I'll have some more dumb questions,
I'm afraid!

Many thanks for your help,

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 03 July 2014 12:44
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

You are right, clipping will happen in transforming the most saturated CMYK
values to the monitor, depending on the gamut size of the monitor space.
Soft proofing the saturated cyans, for example, requires a very large
NEC-like or Eizo or HP Dreamweaver-like kind of monitor to accurately view
the data without clipping. Thank's.

Sorry Robert.

Best / Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 3 juillet 2014 02:53
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Roger Breton wrote:

> Out-of-gamut clipping? Impossible. Suppose I am viewing a CMYK image
> in AbsCol. By definition all CMYK colors are in gamut.

In gamut for the CMYK device, but not necessarily in gamut for the proofing
device or display.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> What I meant is that Absolute rendering, in moving the gray line shifts all
> colors by the same amount (as opposed to a proportional shift as in
> Relative).

Nothing useful shifts colors by a fixed offset in either XYZ or L*a*b*
or any other typical color space. Typically shifting a white point
involves moving all the other colors in a way that has most effect
for colors with a similar Y/L*, and proportionally less as you
get close to black, the details depending on what space it is done
in, and whether there is a chromatic adaption matrix involved, etc.

> It would seem to me that there is still the potential for out-of-gamut
> clipping to the working space as a result of the shifting of the colors.
> Would that be the case?

I'm not sure what context you are implying, so it's not possible
to specifically answer this. In general, any transformation from one
limited gamut space to another has potential for clipping.

Graeme Gill.

[r***@public.gmane.org]

> Nothing useful shifts colors by a fixed offset in either XYZ or L*a*b*
> or any other typical color space. Typically shifting a white point
> involves moving all the other colors in a way that has most effect
> for colors with a similar Y/L*, and proportionally less as you
> get close to black, the details depending on what space it is done
> in, and whether there is a chromatic adaption matrix involved, etc.

Hi Graeme,

My English is sloppy. What I really meant is that the gray lines are
brought into line (so to speak) ... so (normally) there will be a greater
shift at the white point, less at the middle gray and least at the black
point. But at a particular luminance level, are not all colors shifted by
the same amount in an Absolute Colorimetric transform? I take it that this
is what you said above?

I don't know what a chromatic adaptation matrix does, or how it is produced.
Are you talking about the illuminant and FWA compensations? If so, is there
a separate mapping matrix (as you imply) or is the compensation built in to
the table?

If you know of any really good literature on this whole subject (which would
be comprehensible to someone without a background in color theory) I would
be very grateful for the reference. I do have an engineering degree so I
can cope with a certain amount of maths, but preferably not too much! I
really hate asking silly questions that take up your time and the time of
others, but I've found it very difficult to find fairly in-depth and at the
same time correct information. Going to the ICC is just way too much for
me.

Thanks

Robert

[Roger Breton]

Robert,

The shift will be the same throughout.

Think of the way that the raw colorimetric measurements for an output
profile are first encoded into the PCS: there is XYZ (linear) normalization
to the raw XYZ measurements applied so that L=100 a=0 b=0 on the device
paper. That's what gets encoded into the RelCol tag (A2B0).

Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 3 juillet 2014 09:46
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant


> Nothing useful shifts colors by a fixed offset in either XYZ or L*a*b*
> or any other typical color space. Typically shifting a white point
> involves moving all the other colors in a way that has most effect for
> colors with a similar Y/L*, and proportionally less as you get close
> to black, the details depending on what space it is done in, and
> whether there is a chromatic adaption matrix involved, etc.

Hi Graeme,

My English is sloppy. What I really meant is that the gray lines are
brought into line (so to speak) ... so (normally) there will be a greater
shift at the white point, less at the middle gray and least at the black
point. But at a particular luminance level, are not all colors shifted by
the same amount in an Absolute Colorimetric transform? I take it that this
is what you said above?

I don't know what a chromatic adaptation matrix does, or how it is produced.
Are you talking about the illuminant and FWA compensations? If so, is there
a separate mapping matrix (as you imply) or is the compensation built in to
the table?

If you know of any really good literature on this whole subject (which would
be comprehensible to someone without a background in color theory) I would
be very grateful for the reference. I do have an engineering degree so I
can cope with a certain amount of maths, but preferably not too much! I
really hate asking silly questions that take up your time and the time of
others, but I've found it very difficult to find fairly in-depth and at the
same time correct information. Going to the ICC is just way too much for
me.

Thanks

Robert

[Roger Breton]

I meant "XYZ (linear) normalization to the raw XYZ measurements of the
"substrate* is applied so that Lab becomes L100 a0 b0 for the paper color."

Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 3 juillet 2014 13:50
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

The shift will be the same throughout.

Think of the way that the raw colorimetric measurements for an output
profile are first encoded into the PCS: there is XYZ (linear) normalization
to the raw XYZ measurements applied so that L=100 a=0 b=0 on the device
paper. That's what gets encoded into the RelCol tag (A2B0).

Roger

[r***@public.gmane.org]

Roger,

Before I ask you any more questions about Custom Illuminants, I wonder if
you would be kind enough to answer another (rather long) question for me?
I'm trying to get a better understanding of how an ICC profile achieves its
objective because if I did I think it might answer quite a number of my
questions.

Perhaps I could explain what my current understanding of, say, a BtoA1
mapping does.

LUT
1. The individual L*a*b* (or XYZ if the PCS is in XYZ)) values are fed into
B-curves, one for each channel, which corrects something (I don't know
what).
2. The Lab output of the B-curves may be fed into a chromatic adaptation
matrix (the chad tag) to make corrections from D50 to, say, a Solux lamp as
illuminant. I assume (probably incorrectly) that what this does is to bump
up the blues and maybe the greens (in the case of the Solux lamp) and dampen
down the reds, so that the general color balance of the print under the
Solux lamp will be close to the color balance under a D50 illuminant.
3. The Lab output of the chromatic adaptation matrix, if it exists, is (may
be?) fed into M-curves which corrects something (I don't know what).
5. The outputs of the B-curves or the M-curves (if they exist) are fed into
the color LUT. This maps the Lab values to RGB values (and does the gamut
mapping? or is the gamut mapping done using the gamt tag data?).
4. The RGB values are fed into A-curves which correct for the non-linearity
of the printer.
5. The corrected RGB values are sent to the printer.

Is this correct? If not, perhaps you would be kind enough tell me where I've
gone wrong? Also, what do the B-curves and M-curves do?

There is also a gamt tag in the profile. Is this used for gamut-mapping? If
it is used for gamut mapping, which would make sense, then would I be right
in assuming that the single output value indicates in-gamut if it's 0; 65535
indicates so far out of gamut that it can only be clipped; values in between
indicate the distance of the color from the white point, so it can be used
to compute (by iteration?) the nearest point on the gamut envelope. Or
something along those lines?

And, lastly, in the Argyll profiles I don't see a 'chad' tag even though the
profile's for a non-D50 illuminant. Does that mean that there is no
chromatic adaptation being done? The profile was created using -i and a .sp
file.

Roger ... if you don't have the time or interest to reply, please don't! I
really won't be offended!

Cheers,

Robert
-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 03 July 2014 20:55
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

I meant "XYZ (linear) normalization to the raw XYZ measurements of the
"substrate* is applied so that Lab becomes L100 a0 b0 for the paper color."

Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 3 juillet 2014 13:50
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

The shift will be the same throughout.

Think of the way that the raw colorimetric measurements for an output
profile are first encoded into the PCS: there is XYZ (linear) normalization
to the raw XYZ measurements applied so that L=100 a=0 b=0 on the device
paper. That's what gets encoded into the RelCol tag (A2B0).

Roger

[Roger Breton]

Robert,

In all honesty, it's been a while since I took a look at the specs
(http://www.color.org/specification/ICC1v43_2010-12.pdf).

The computational structure of the B2A1 is extensive and allows for many
possibilities which are not all used in practice.

Step 1 indeed allows for a pre-linearization stage in Lab, before moving the
data forward.
Step 2 is an optional chromatic adaptation stage that takes place in XYZ (to
my knowledge, as the chad matrices are defined in XYZ)
Step 3 is another optional pre-linearization stage (they really wanted to
allow for all kinds of zany color processing...)
Step 4 is the CLUT conversion
Step 5 is another optional post-conversion linearization stage, this time in
device units.

The gamut tag is rarely used if at all. It was supposed to represent the
gamut size of the device and be used for testing in-gamut colors.
To my knowledge, it is completely optional. Last I remember, different
profilers were using this tag in different ways. So, it was not reliable.
All the gamut mapping takes place within the CLUT. That's where all
profilers "make their money".

Now, chromatic adaptation. To my humble knowledge, this is only used for
display profiling, say between D65 and D50.
I have yet to see it implement on an Output Device although it would makes
perfect sense to do so?

Now, I would have to dig further into Argyll (and pick Graeme's brain) about
the use of the non-standard illuminant, such as the Solux lamp.
What does the specs says about this, I am not sure? But I do remember that,
a few years ago, only ProfileMakerPro allowed the use of a non-standard
illuminant in profile calculations. I'm not sure what kind of normalization
goes on in this scenario...

Sorry / Roger




-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 4 juillet 2014 09:42
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Roger,

Before I ask you any more questions about Custom Illuminants, I wonder if
you would be kind enough to answer another (rather long) question for me?
I'm trying to get a better understanding of how an ICC profile achieves its
objective because if I did I think it might answer quite a number of my
questions.

Perhaps I could explain what my current understanding of, say, a BtoA1
mapping does.

LUT
1. The individual L*a*b* (or XYZ if the PCS is in XYZ)) values are fed into
B-curves, one for each channel, which corrects something (I don't know
what).
2. The Lab output of the B-curves may be fed into a chromatic adaptation
matrix (the chad tag) to make corrections from D50 to, say, a Solux lamp as
illuminant. I assume (probably incorrectly) that what this does is to bump
up the blues and maybe the greens (in the case of the Solux lamp) and dampen
down the reds, so that the general color balance of the print under the
Solux lamp will be close to the color balance under a D50 illuminant.
3. The Lab output of the chromatic adaptation matrix, if it exists, is (may
be?) fed into M-curves which corrects something (I don't know what).
5. The outputs of the B-curves or the M-curves (if they exist) are fed into
the color LUT. This maps the Lab values to RGB values (and does the gamut
mapping? or is the gamut mapping done using the gamt tag data?).
4. The RGB values are fed into A-curves which correct for the non-linearity
of the printer.
5. The corrected RGB values are sent to the printer.

Is this correct? If not, perhaps you would be kind enough tell me where I've
gone wrong? Also, what do the B-curves and M-curves do?

There is also a gamt tag in the profile. Is this used for gamut-mapping? If
it is used for gamut mapping, which would make sense, then would I be right
in assuming that the single output value indicates in-gamut if it's 0; 65535
indicates so far out of gamut that it can only be clipped; values in between
indicate the distance of the color from the white point, so it can be used
to compute (by iteration?) the nearest point on the gamut envelope. Or
something along those lines?

And, lastly, in the Argyll profiles I don't see a 'chad' tag even though the
profile's for a non-D50 illuminant. Does that mean that there is no
chromatic adaptation being done? The profile was created using -i and a .sp
file.

Roger ... if you don't have the time or interest to reply, please don't! I
really won't be offended!

Cheers,

Robert
-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 03 July 2014 20:55
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

I meant "XYZ (linear) normalization to the raw XYZ measurements of the
"substrate* is applied so that Lab becomes L100 a0 b0 for the paper color."

Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 3 juillet 2014 13:50
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

The shift will be the same throughout.

Think of the way that the raw colorimetric measurements for an output
profile are first encoded into the PCS: there is XYZ (linear) normalization
to the raw XYZ measurements applied so that L=100 a=0 b=0 on the device
paper. That's what gets encoded into the RelCol tag (A2B0).

Roger

[r***@public.gmane.org]

Many thanks Roger!

The Argyll printer profiles I've looked at use B-curves, which is why I
wondered what they are for. I would have thought that the PCS data is
already linearized and normalised, so I can't imagine what sort of
linearization would be needed on output. Perhaps Graeme can illuminate us?

Other printer profiles I've looked at do have the chad tag but these are all
unity transforms. The chad tag in a 6500K monitor profile I have is very
close to the D65 to D50 Bradford scaling in Bruce Lindbloom's site. The
matrix is in XYZ as you say. I would have expected an Argyll Illuminant A
profile, for example, to have an A to D50 matrix ... but maybe Graeme does
it some other way?

All the printer profiles I've looked at have a gamt tag. These have 3
curves and one LUT. I had a guess at the purpose of the LUT data (3 inputs
one output) but I can't even begin to guess at the purpose of the curves!

I should just forget it and move on ... but I'm one of these people who feel
a need to have some understanding of the underlying technology. I'll do a
bit more reading and see if I can find something that sheds some light on
these mysteries!

Thanks again for your time!

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 04 July 2014 18:27
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

In all honesty, it's been a while since I took a look at the specs
(http://www.color.org/specification/ICC1v43_2010-12.pdf).

The computational structure of the B2A1 is extensive and allows for many
possibilities which are not all used in practice.

Step 1 indeed allows for a pre-linearization stage in Lab, before moving the
data forward.
Step 2 is an optional chromatic adaptation stage that takes place in XYZ (to
my knowledge, as the chad matrices are defined in XYZ)
Step 3 is another optional pre-linearization stage (they really wanted to
allow for all kinds of zany color processing...)
Step 4 is the CLUT conversion
Step 5 is another optional post-conversion linearization stage, this time in
device units.

The gamut tag is rarely used if at all. It was supposed to represent the
gamut size of the device and be used for testing in-gamut colors.
To my knowledge, it is completely optional. Last I remember, different
profilers were using this tag in different ways. So, it was not reliable.
All the gamut mapping takes place within the CLUT. That's where all
profilers "make their money".

Now, chromatic adaptation. To my humble knowledge, this is only used for
display profiling, say between D65 and D50.
I have yet to see it implement on an Output Device although it would makes
perfect sense to do so?

Now, I would have to dig further into Argyll (and pick Graeme's brain) about
the use of the non-standard illuminant, such as the Solux lamp.
What does the specs says about this, I am not sure? But I do remember that,
a few years ago, only ProfileMakerPro allowed the use of a non-standard
illuminant in profile calculations. I'm not sure what kind of normalization
goes on in this scenario...

Sorry / Roger




-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 4 juillet 2014 09:42
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Roger,

Before I ask you any more questions about Custom Illuminants, I wonder if
you would be kind enough to answer another (rather long) question for me?
I'm trying to get a better understanding of how an ICC profile achieves its
objective because if I did I think it might answer quite a number of my
questions.

Perhaps I could explain what my current understanding of, say, a BtoA1
mapping does.

LUT
1. The individual L*a*b* (or XYZ if the PCS is in XYZ)) values are fed into
B-curves, one for each channel, which corrects something (I don't know
what).
2. The Lab output of the B-curves may be fed into a chromatic adaptation
matrix (the chad tag) to make corrections from D50 to, say, a Solux lamp as
illuminant. I assume (probably incorrectly) that what this does is to bump
up the blues and maybe the greens (in the case of the Solux lamp) and dampen
down the reds, so that the general color balance of the print under the
Solux lamp will be close to the color balance under a D50 illuminant.
3. The Lab output of the chromatic adaptation matrix, if it exists, is (may
be?) fed into M-curves which corrects something (I don't know what).
5. The outputs of the B-curves or the M-curves (if they exist) are fed into
the color LUT. This maps the Lab values to RGB values (and does the gamut
mapping? or is the gamut mapping done using the gamt tag data?).
4. The RGB values are fed into A-curves which correct for the non-linearity
of the printer.
5. The corrected RGB values are sent to the printer.

Is this correct? If not, perhaps you would be kind enough tell me where I've
gone wrong? Also, what do the B-curves and M-curves do?

There is also a gamt tag in the profile. Is this used for gamut-mapping? If
it is used for gamut mapping, which would make sense, then would I be right
in assuming that the single output value indicates in-gamut if it's 0; 65535
indicates so far out of gamut that it can only be clipped; values in between
indicate the distance of the color from the white point, so it can be used
to compute (by iteration?) the nearest point on the gamut envelope. Or
something along those lines?

And, lastly, in the Argyll profiles I don't see a 'chad' tag even though the
profile's for a non-D50 illuminant. Does that mean that there is no
chromatic adaptation being done? The profile was created using -i and a .sp
file.

Roger ... if you don't have the time or interest to reply, please don't! I
really won't be offended!

Cheers,

Robert
-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 03 July 2014 20:55
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

I meant "XYZ (linear) normalization to the raw XYZ measurements of the
"substrate* is applied so that Lab becomes L100 a0 b0 for the paper color."

Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 3 juillet 2014 13:50
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

The shift will be the same throughout.

Think of the way that the raw colorimetric measurements for an output
profile are first encoded into the PCS: there is XYZ (linear) normalization
to the raw XYZ measurements applied so that L=100 a=0 b=0 on the device
paper. That's what gets encoded into the RelCol tag (A2B0).

Roger

[Graeme Gill]

robert-/***@public.gmane.org wrote:

Hi,

> The Argyll printer profiles I've looked at use B-curves, which is why I
> wondered what they are for.

They are the inverse of the A2B curves, which are chosen to improve
the profile fit, as well as shift the white point to be on a grid point,
so that it will be mapped with precision.

> The
> matrix is in XYZ as you say. I would have expected an Argyll Illuminant A
> profile, for example, to have an A to D50 matrix ... but maybe Graeme does
> it some other way?

No, because that would defeat the purpose. The point of the chad tag
is to say "and by the way, the instrument measured XYZ values using some
other illuminant, but we converted it to be as if it had been measured under D50 by
applying a chromatic transform". This is not as accurate as doing this spectrally using
the spectral reflectance, or, best of all, using actual D50 measurement illuminant, but
is the best that can be done in this situation to make it conform to the PCS requirements.

The point of creating a (non-standard) profile with a non-standard illuminant
is to actually represent the color appearance under that illuminant, not to
make it as if this wasn't the case undoing it and using a chad tag.

> All the printer profiles I've looked at have a gamt tag. These have 3
> curves and one LUT. I had a guess at the purpose of the LUT data (3 inputs
> one output) but I can't even begin to guess at the purpose of the curves!

The gamt tag is meant to represent the gamut boundary in a binary way. So
typically the 3D Lut maps the PCS to some value that tries to represent
the "in gamutness" of the color in an continuous way, and the 1D lookup
at the end quantizes it. The result is a not-very accurate gamut boundary
representation, which is why no-one uses it.

> I should just forget it and move on ... but I'm one of these people who feel
> a need to have some understanding of the underlying technology. I'll do a
> bit more reading and see if I can find something that sheds some light on
> these mysteries!

Phil Green's book goes into ICC in more detail, but given the flexibility
of the format and the different possible approaches, won't cover everything,
and certainly won't cover the unique things that ArgyllCMS does.

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

Many thanks for taking the time to answer my questions / correct my
assumptions.

Just following on from your answers:
- Why does Argyll provide the gamt tag? It appears to be a standard gamt
tag, but you say that no-one uses it. Do you put it there for the odd CMM
that might? It won't do any harm if it isn't used, of course ... and I
assume that if it is used and the gamut mapping has already been done in the
cLUT (I assume that any XYZ value of 65535 indicates OOG?) that it won't do
any harm (or much harm for values close to but inside the gamut).
- Regarding the AtoB mapping: I've had another look at the i1Profiler
generated profiles and even though it has data in all three tags, the data
is the same - so it appears to be using the Colorimetric mapping for all
three, as in Argyll ... just wasting space.
- I'm not sure if I mentioned this, but Soft-Proofing with Simulate Paper in
Photoshop does the equivalent of: Convert to Profile with selected intent;
Convert back to working space with Absolute Colorimetric. That means that if
the wtpt tag is set to the paper white under the chosen illuminant (using a
.sp file in Argyll, for example) then the print and monitor image match when
viewed side by side.

Thank you for the suggested reading! I'll do some studying before asking
any further questions :).

Robert


-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 05 July 2014 06:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

Hi,

> The Argyll printer profiles I've looked at use B-curves, which is why I
> wondered what they are for.

They are the inverse of the A2B curves, which are chosen to improve
the profile fit, as well as shift the white point to be on a grid point,
so that it will be mapped with precision.

> The
> matrix is in XYZ as you say. I would have expected an Argyll Illuminant A
> profile, for example, to have an A to D50 matrix ... but maybe Graeme does
> it some other way?

No, because that would defeat the purpose. The point of the chad tag
is to say "and by the way, the instrument measured XYZ values using some
other illuminant, but we converted it to be as if it had been measured under
D50 by
applying a chromatic transform". This is not as accurate as doing this
spectrally using
the spectral reflectance, or, best of all, using actual D50 measurement
illuminant, but
is the best that can be done in this situation to make it conform to the PCS
requirements.

The point of creating a (non-standard) profile with a non-standard
illuminant
is to actually represent the color appearance under that illuminant, not to
make it as if this wasn't the case undoing it and using a chad tag.

> All the printer profiles I've looked at have a gamt tag. These have 3
> curves and one LUT. I had a guess at the purpose of the LUT data (3
inputs
> one output) but I can't even begin to guess at the purpose of the curves!

The gamt tag is meant to represent the gamut boundary in a binary way. So
typically the 3D Lut maps the PCS to some value that tries to represent
the "in gamutness" of the color in an continuous way, and the 1D lookup
at the end quantizes it. The result is a not-very accurate gamut boundary
representation, which is why no-one uses it.

> I should just forget it and move on ... but I'm one of these people who
feel
> a need to have some understanding of the underlying technology. I'll do a
> bit more reading and see if I can find something that sheds some light on
> these mysteries!

Phil Green's book goes into ICC in more detail, but given the flexibility
of the format and the different possible approaches, won't cover everything,
and certainly won't cover the unique things that ArgyllCMS does.

Graeme Gill.

[Graeme Gill]

This post might be inappropriate. Click to display it.

[r***@public.gmane.org]

QUOTE:
---------------------------------------------------------------------------
> - You say in relation to ICC V2 behaviour: "The main disadvantage is that
> the gamut mapping will only operate exactly as intended when the profile
is
> linked with the source profile it was setup for". (This only relates to
> Perceptual and Saturation as Colorimetric does not do a gamut mapping). I
> take it that for a print profile, that the source profile should normally
be
> the working space?

It is whatever space your source images are in. Typically the color space
is used as a proxy for the gamut the images occupy. With limited gamut
color spaces (i.e. sRGB) this is usually a good assumption, since images
are typically optimized to occupy much of the available gamut.

This assumption breaks down if images are stored in large/unlimited gamut
spaces such as L*a*b*, scRGB, ProPhoto etc., and alternative strategies
are needed to create an appropriate gamut mapping.

> I had put the monitor profile in the -S flag in colprof,
> but this would seem to be incorrect. Do I understand correctly that if
the
> profile is made with -S AdobeRGB1998.icc but the working space is ProPhoto
> RGB that the Perceptual and Saturation gamut mappings will not operate as
> intended (I was going to say 'wrong', but I'm sure you would tell me that
> there is no 'right' or 'wrong' in these matters :)).

ProPhoto is problematic, since it has a gamut much larger than
typical images, hence is a poor choice as a proxy for the gamut
of the images. Using it as the source gamut for gamut mapping
will typically result in a dull, desaturated result.

You can either use a small gamut, closer to the actual
gamut the images occupy as the source for gamut mapping
(although this then disregards much of the purpose of
storing images in a large gamut space), or you should
move to a more sophisticated workflow, where you
create the gamut mapping for each individual image,
or batch of images, where the source gamut is determined
by the images themselves.
----------------------------------------------------------------------------

Reply:

I take it that the relationship ONLY breaks down in large/unlimited gamut
spaces IF the image gamut is larger than the destination gamut. If I use
ProPhoto, say, but I make sure that my image is within the gamut of my print
profile, I should be OK for Colomimetric intents, surely? And also for
Perceptual or Saturation also, since no mapping is required? The only issue
then would be resolution, presumably, but that should be OK in 16 bit, I
would have thought.

If that's right, then the only real risk of using large gamut spaces as
working spaces is having colors which are out-of-gamut for the destination
space.

In relation to this I have another question. Is there any reason why one
should not convert the image to the print color space prior to doing some
small final edits before printing? The advantage is that these edits would
then be constrained to the print gamut, and also the gamut warning can be
set to the monitor profile to indicate which colors are not viewable
(clipped to the monitor profile). The disadvantage is that the image is
'burnt' to the print profile, but that isn't a disadvantage for me because I
always use copies of the original for printing, one for each paper type,
size, resolution etc.

Thanks again ... I can't tell you how much I appreciate your time and effort
in answering what are mostly pretty dumb questions, not even directly
related to Argyll!

Robert

[Graeme Gill]

robert-/***@public.gmane.org wrote:

Hi,

> I take it that the relationship ONLY breaks down in large/unlimited gamut
> spaces IF the image gamut is larger than the destination gamut.

No, it breaks down if the colorspace gamut is noticeably larger than
the image gamut.

Gamut mapping is determined by the relationship between the source and
destination gamuts. If you are using the source colorspace as your
definition of the source gamut, but it does not actually represent
the gamut of the images you are gamut mapping, then it won't work very
well for those images.

> If I use
> ProPhoto, say, but I make sure that my image is within the gamut of my print
> profile, I should be OK for Colomimetric intents, surely?

For colorimetric, yes, but colorimetric doesn't use gamut mapping - it will
clip if source colors are outside the destination gamut.

> And also for
> Perceptual or Saturation also, since no mapping is required?

How does the gamut mapping know that no mapping is required ? If you
tell it the source gamut is ProPhoto, then it will think that lots
of gamut mapping is needed, since the ProPhoto gamut is so much larger
than a printer !

> The only issue
> then would be resolution, presumably, but that should be OK in 16 bit, I
> would have thought.

Yes, large gamut color spaces typically need a higher pixel depth.

> In relation to this I have another question. Is there any reason why one
> should not convert the image to the print color space prior to doing some
> small final edits before printing? The advantage is that these edits would
> then be constrained to the print gamut, and also the gamut warning can be
> set to the monitor profile to indicate which colors are not viewable

It's a reasonable approach, if you know what you are doing.

Graeme Gill.

[r***@public.gmane.org]

<< How does the gamut mapping know that no mapping is required ? If you tell
it the source gamut is ProPhoto, then it will think that lots of gamut
mapping is needed, since the ProPhoto gamut is so much larger than a printer
!>>

Well that has finally clarified that point for me! So with Perceptual the
whole source gamut is squashed down to the destination gamut, even if all
the colors are within the destination gamut. This means that in a
Perceptual mapping from ProPhoto to print, colors will be compressed
resulting in desaturation of the image, particularly of the more saturated
colors nearer the print gamut boundary.

So the following strategy might make sense for a Relative intent conversion:
- Going from ProPhoto to print, make sure the colors are more or less within
the destination space to avoid too much clipping.

And the following for Perceptual:
- Do a Relative conversion from ProPhoto to AdobeRGB (making sure the colors
are more or less within the AdobeRGB space before the conversion to avoid
too much clipping).
- Do a Perceptual mapping from AdobeRGB to print.

I did a comparison of a 1-step ProPhoto [Perceptual to Print conversion]
with a 2-step [ProPhoto to AdobeRGB conversion, followed by an AdobeRGB
Perceptual to print conversion]:
- If the original image colors are all within the AdobeRGB gamut there is
quite a difference if the print gamut is much smaller than AdobeRGB, but
none if it is of similar size.
- If the original image colors are outside the AdobeRGB gamut, the 2-step
approach is significantly better even if the print gamut is very close to
the AdobeRGB gamut.
This is a bit puzzling because I would have expected a difference in all
cases (if the full ProPhoto gamut is squashed down in a Perceptual
conversion).

What would be nice would be to be able to make the smaller intermediate
working color space using tiffgamut/colprof (from a range of typical
images), but I don't see how that could be done.

Robert

[Brad Funkhouser]

When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try Bruce Lindbloom's BetaRGB, it might be just right.

- Brad


> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>
> << How does the gamut mapping know that no mapping is required ? If you tell
> it the source gamut is ProPhoto, then it will think that lots of gamut
> mapping is needed, since the ProPhoto gamut is so much larger than a printer
> !>>
>
> Well that has finally clarified that point for me! So with Perceptual the
> whole source gamut is squashed down to the destination gamut, even if all
> the colors are within the destination gamut. This means that in a
> Perceptual mapping from ProPhoto to print, colors will be compressed
> resulting in desaturation of the image, particularly of the more saturated
> colors nearer the print gamut boundary.
>
> So the following strategy might make sense for a Relative intent conversion:
> - Going from ProPhoto to print, make sure the colors are more or less within
> the destination space to avoid too much clipping.
>
> And the following for Perceptual:
> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the colors
> are more or less within the AdobeRGB space before the conversion to avoid
> too much clipping).
> - Do a Perceptual mapping from AdobeRGB to print.
>
> I did a comparison of a 1-step ProPhoto [Perceptual to Print conversion]
> with a 2-step [ProPhoto to AdobeRGB conversion, followed by an AdobeRGB
> Perceptual to print conversion]:
> - If the original image colors are all within the AdobeRGB gamut there is
> quite a difference if the print gamut is much smaller than AdobeRGB, but
> none if it is of similar size.
> - If the original image colors are outside the AdobeRGB gamut, the 2-step
> approach is significantly better even if the print gamut is very close to
> the AdobeRGB gamut.
> This is a bit puzzling because I would have expected a difference in all
> cases (if the full ProPhoto gamut is squashed down in a Perceptual
> conversion).
>
> What would be nice would be to be able to make the smaller intermediate
> working color space using tiffgamut/colprof (from a range of typical
> images), but I don't see how that could be done.
>
> Robert
>
>

[Roger Breton]

I like to use eciRGBv2. I'm a D50 "guy", what can I say ;-)

/ Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Brad Funkhouser
Sent: 7 juillet 2014 14:40
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant


When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
Bruce Lindbloom's BetaRGB, it might be just right.

- Brad


> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>
> << How does the gamut mapping know that no mapping is required ? If
> you tell it the source gamut is ProPhoto, then it will think that lots
> of gamut mapping is needed, since the ProPhoto gamut is so much larger
> than a printer !>>
>
> Well that has finally clarified that point for me! So with Perceptual
> the whole source gamut is squashed down to the destination gamut, even
> if all the colors are within the destination gamut. This means that
> in a Perceptual mapping from ProPhoto to print, colors will be
> compressed resulting in desaturation of the image, particularly of the
> more saturated colors nearer the print gamut boundary.
>
> So the following strategy might make sense for a Relative intent
conversion:
> - Going from ProPhoto to print, make sure the colors are more or less
> within the destination space to avoid too much clipping.
>
> And the following for Perceptual:
> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
> colors are more or less within the AdobeRGB space before the
> conversion to avoid too much clipping).
> - Do a Perceptual mapping from AdobeRGB to print.
>
> I did a comparison of a 1-step ProPhoto [Perceptual to Print
> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
> by an AdobeRGB Perceptual to print conversion]:
> - If the original image colors are all within the AdobeRGB gamut there
> is quite a difference if the print gamut is much smaller than
> AdobeRGB, but none if it is of similar size.
> - If the original image colors are outside the AdobeRGB gamut, the
> 2-step approach is significantly better even if the print gamut is
> very close to the AdobeRGB gamut.
> This is a bit puzzling because I would have expected a difference in
> all cases (if the full ProPhoto gamut is squashed down in a Perceptual
> conversion).
>
> What would be nice would be to be able to make the smaller
> intermediate working color space using tiffgamut/colprof (from a range
> of typical images), but I don't see how that could be done.
>
> Robert
>
>

[Roger Breton]

Also, what I like about eciRGB is the fact there is never any issues with
chromatic adaption since everything happens on a pure-D50 scale, from PCS to
RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...

/ Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Brad Funkhouser
Sent: 7 juillet 2014 14:40
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant


When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
Bruce Lindbloom's BetaRGB, it might be just right.

- Brad


> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>
> << How does the gamut mapping know that no mapping is required ? If
> you tell it the source gamut is ProPhoto, then it will think that lots
> of gamut mapping is needed, since the ProPhoto gamut is so much larger
> than a printer !>>
>
> Well that has finally clarified that point for me! So with Perceptual
> the whole source gamut is squashed down to the destination gamut, even
> if all the colors are within the destination gamut. This means that
> in a Perceptual mapping from ProPhoto to print, colors will be
> compressed resulting in desaturation of the image, particularly of the
> more saturated colors nearer the print gamut boundary.
>
> So the following strategy might make sense for a Relative intent
conversion:
> - Going from ProPhoto to print, make sure the colors are more or less
> within the destination space to avoid too much clipping.
>
> And the following for Perceptual:
> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
> colors are more or less within the AdobeRGB space before the
> conversion to avoid too much clipping).
> - Do a Perceptual mapping from AdobeRGB to print.
>
> I did a comparison of a 1-step ProPhoto [Perceptual to Print
> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
> by an AdobeRGB Perceptual to print conversion]:
> - If the original image colors are all within the AdobeRGB gamut there
> is quite a difference if the print gamut is much smaller than
> AdobeRGB, but none if it is of similar size.
> - If the original image colors are outside the AdobeRGB gamut, the
> 2-step approach is significantly better even if the print gamut is
> very close to the AdobeRGB gamut.
> This is a bit puzzling because I would have expected a difference in
> all cases (if the full ProPhoto gamut is squashed down in a Perceptual
> conversion).
>
> What would be nice would be to be able to make the smaller
> intermediate working color space using tiffgamut/colprof (from a range
> of typical images), but I don't see how that could be done.
>
> Robert
>
>

[Brad Funkhouser]

I agree, BetaRGB is also D50, which I like versus the D65s. I'll check out eciRGB... That's not one I'm familiar with.

Thanks for the suggestion.

- Brad


> On Jul 7, 2014, at 3:13 PM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:
>
> Also, what I like about eciRGB is the fact there is never any issues with
> chromatic adaption since everything happens on a pure-D50 scale, from PCS to
> RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...
>
> / Roger
>
> -----Original Message-----
> From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-uGLqWuYN4qO++***@public.gmane.orgg]
> On Behalf Of Brad Funkhouser
> Sent: 7 juillet 2014 14:40
> To: argyllcms-***@public.gmane.org
> Subject: [argyllcms] Re: Custom Illuminant
>
>
> When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
> Bruce Lindbloom's BetaRGB, it might be just right.
>
> - Brad
>
>
>> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>>
>> << How does the gamut mapping know that no mapping is required ? If
>> you tell it the source gamut is ProPhoto, then it will think that lots
>> of gamut mapping is needed, since the ProPhoto gamut is so much larger
>> than a printer !>>
>>
>> Well that has finally clarified that point for me! So with Perceptual
>> the whole source gamut is squashed down to the destination gamut, even
>> if all the colors are within the destination gamut. This means that
>> in a Perceptual mapping from ProPhoto to print, colors will be
>> compressed resulting in desaturation of the image, particularly of the
>> more saturated colors nearer the print gamut boundary.
>>
>> So the following strategy might make sense for a Relative intent
> conversion:
>> - Going from ProPhoto to print, make sure the colors are more or less
>> within the destination space to avoid too much clipping.
>>
>> And the following for Perceptual:
>> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
>> colors are more or less within the AdobeRGB space before the
>> conversion to avoid too much clipping).
>> - Do a Perceptual mapping from AdobeRGB to print.
>>
>> I did a comparison of a 1-step ProPhoto [Perceptual to Print
>> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
>> by an AdobeRGB Perceptual to print conversion]:
>> - If the original image colors are all within the AdobeRGB gamut there
>> is quite a difference if the print gamut is much smaller than
>> AdobeRGB, but none if it is of similar size.
>> - If the original image colors are outside the AdobeRGB gamut, the
>> 2-step approach is significantly better even if the print gamut is
>> very close to the AdobeRGB gamut.
>> This is a bit puzzling because I would have expected a difference in
>> all cases (if the full ProPhoto gamut is squashed down in a Perceptual
>> conversion).
>>
>> What would be nice would be to be able to make the smaller
>> intermediate working color space using tiffgamut/colprof (from a range
>> of typical images), but I don't see how that could be done.
>>
>> Robert
>
>

[r***@public.gmane.org]

Thanks for your suggestions! The main reason I use ProPhoto is that
Lightroom only gives the options of sRGB, Adobe RGB or ProPhoto RGB to
export to Photoshop. Also, Lightroom itself uses a variant of ProPhoto as
its internal working space, so that there is no clipping when going from a
raw image developed in Lightroom to ProPhoto in Photoshop.

I can see that there would be an advantage in having a D50 white point
(which ProPhoto RGB has).

Beta RGB has a 2.2 gamma, eciRGB an L* curve and ProPhoto has a gamma of
1.8. I don't understand the pros and cons. Bruce Lindbloom says regarding
gamma: "it is an important consideration for controlling quantization" and
his conclusion is that a gamma of 2.2 is nearly optimal.

And, finally and perhaps more importantly, as I am constrained to (sRGB,
AdobeRGB or) ProPhotoRGB when going from Lightroom to Photoshop ... would an
extra conversion to eciRGB or Beta RGB not potentially cause damage to the
image (for example in clipping OOG colors and quantization errors)?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Brad Funkhouser
Sent: 07 July 2014 23:28
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant


I agree, BetaRGB is also D50, which I like versus the D65s. I'll check out
eciRGB... That's not one I'm familiar with.

Thanks for the suggestion.

- Brad


> On Jul 7, 2014, at 3:13 PM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:
>
> Also, what I like about eciRGB is the fact there is never any issues with
> chromatic adaption since everything happens on a pure-D50 scale, from PCS
to
> RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...
>
> / Roger
>
> -----Original Message-----
> From: argyllcms-bounce-***@public.gmane.org
[mailto:argyllcms-bounce-***@public.gmane.org]
> On Behalf Of Brad Funkhouser
> Sent: 7 juillet 2014 14:40
> To: argyllcms-***@public.gmane.org
> Subject: [argyllcms] Re: Custom Illuminant
>
>
> When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
> Bruce Lindbloom's BetaRGB, it might be just right.
>
> - Brad
>
>
>> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>>
>> << How does the gamut mapping know that no mapping is required ? If
>> you tell it the source gamut is ProPhoto, then it will think that lots
>> of gamut mapping is needed, since the ProPhoto gamut is so much larger
>> than a printer !>>
>>
>> Well that has finally clarified that point for me! So with Perceptual
>> the whole source gamut is squashed down to the destination gamut, even
>> if all the colors are within the destination gamut. This means that
>> in a Perceptual mapping from ProPhoto to print, colors will be
>> compressed resulting in desaturation of the image, particularly of the
>> more saturated colors nearer the print gamut boundary.
>>
>> So the following strategy might make sense for a Relative intent
> conversion:
>> - Going from ProPhoto to print, make sure the colors are more or less
>> within the destination space to avoid too much clipping.
>>
>> And the following for Perceptual:
>> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
>> colors are more or less within the AdobeRGB space before the
>> conversion to avoid too much clipping).
>> - Do a Perceptual mapping from AdobeRGB to print.
>>
>> I did a comparison of a 1-step ProPhoto [Perceptual to Print
>> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
>> by an AdobeRGB Perceptual to print conversion]:
>> - If the original image colors are all within the AdobeRGB gamut there
>> is quite a difference if the print gamut is much smaller than
>> AdobeRGB, but none if it is of similar size.
>> - If the original image colors are outside the AdobeRGB gamut, the
>> 2-step approach is significantly better even if the print gamut is
>> very close to the AdobeRGB gamut.
>> This is a bit puzzling because I would have expected a difference in
>> all cases (if the full ProPhoto gamut is squashed down in a Perceptual
>> conversion).
>>
>> What would be nice would be to be able to make the smaller
>> intermediate working color space using tiffgamut/colprof (from a range
>> of typical images), but I don't see how that could be done.
>>
>> Robert
>
>

[Ben Goren]

There's another elephant in the room. Adobe's RAW development engine is optimized for "pleasing" color, not accurate color. And, indeed, accurate color isn't really an option with Adobe's RAW development engine; you can't, for example, do decent fine art reproduction / giclee work with it.

RawPhotoProcessor is the best I've found. It outputs directly to BetaRGB, or even to Lab.

As a practical matter, I've not run into gamut limitations with Beta RGB. It encompasses either all or almost all of my iPF8100's gamut, even on baryta papers. AdobeRGB, on the other hand, clips a bit on my best matte paper (Museo Portfolio Rag), and substantially on baryta papers. The only other space I output to is sRGB, which, of course, is fully encompassed by Beta RGB.

In your shoes, ProPhoto may well be the least evil option, but it'd be worth spending some time comparing gamut plots.

b&

On Jul 7, 2014, at 5:01 PM, Robert-/***@public.gmane.org wrote:

> Thanks for your suggestions! The main reason I use ProPhoto is that
> Lightroom only gives the options of sRGB, Adobe RGB or ProPhoto RGB to
> export to Photoshop. Also, Lightroom itself uses a variant of ProPhoto as
> its internal working space, so that there is no clipping when going from a
> raw image developed in Lightroom to ProPhoto in Photoshop.
>
> I can see that there would be an advantage in having a D50 white point
> (which ProPhoto RGB has).
>
> Beta RGB has a 2.2 gamma, eciRGB an L* curve and ProPhoto has a gamma of
> 1.8. I don't understand the pros and cons. Bruce Lindbloom says regarding
> gamma: "it is an important consideration for controlling quantization" and
> his conclusion is that a gamma of 2.2 is nearly optimal.
>
> And, finally and perhaps more importantly, as I am constrained to (sRGB,
> AdobeRGB or) ProPhotoRGB when going from Lightroom to Photoshop ... would an
> extra conversion to eciRGB or Beta RGB not potentially cause damage to the
> image (for example in clipping OOG colors and quantization errors)?
>
> Robert
>
> -----Original Message-----
> From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
> On Behalf Of Brad Funkhouser
> Sent: 07 July 2014 23:28
> To: argyllcms-***@public.gmane.org
> Subject: [argyllcms] Re: Custom Illuminant
>
>
> I agree, BetaRGB is also D50, which I like versus the D65s. I'll check out
> eciRGB... That's not one I'm familiar with.
>
> Thanks for the suggestion.
>
> - Brad
>
>
>> On Jul 7, 2014, at 3:13 PM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:
>>
>> Also, what I like about eciRGB is the fact there is never any issues with
>> chromatic adaption since everything happens on a pure-D50 scale, from PCS
> to
>> RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...
>>
>> / Roger
>>
>> -----Original Message-----
>> From: argyllcms-bounce-***@public.gmane.org
> [mailto:argyllcms-bounce-***@public.gmane.org]
>> On Behalf Of Brad Funkhouser
>> Sent: 7 juillet 2014 14:40
>> To: argyllcms-***@public.gmane.org
>> Subject: [argyllcms] Re: Custom Illuminant
>>
>>
>> When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
>> Bruce Lindbloom's BetaRGB, it might be just right.
>>
>> - Brad
>>
>>
>>> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>>>
>>> << How does the gamut mapping know that no mapping is required ? If
>>> you tell it the source gamut is ProPhoto, then it will think that lots
>>> of gamut mapping is needed, since the ProPhoto gamut is so much larger
>>> than a printer !>>
>>>
>>> Well that has finally clarified that point for me! So with Perceptual
>>> the whole source gamut is squashed down to the destination gamut, even
>>> if all the colors are within the destination gamut. This means that
>>> in a Perceptual mapping from ProPhoto to print, colors will be
>>> compressed resulting in desaturation of the image, particularly of the
>>> more saturated colors nearer the print gamut boundary.
>>>
>>> So the following strategy might make sense for a Relative intent
>> conversion:
>>> - Going from ProPhoto to print, make sure the colors are more or less
>>> within the destination space to avoid too much clipping.
>>>
>>> And the following for Perceptual:
>>> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
>>> colors are more or less within the AdobeRGB space before the
>>> conversion to avoid too much clipping).
>>> - Do a Perceptual mapping from AdobeRGB to print.
>>>
>>> I did a comparison of a 1-step ProPhoto [Perceptual to Print
>>> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
>>> by an AdobeRGB Perceptual to print conversion]:
>>> - If the original image colors are all within the AdobeRGB gamut there
>>> is quite a difference if the print gamut is much smaller than
>>> AdobeRGB, but none if it is of similar size.
>>> - If the original image colors are outside the AdobeRGB gamut, the
>>> 2-step approach is significantly better even if the print gamut is
>>> very close to the AdobeRGB gamut.
>>> This is a bit puzzling because I would have expected a difference in
>>> all cases (if the full ProPhoto gamut is squashed down in a Perceptual
>>> conversion).
>>>
>>> What would be nice would be to be able to make the smaller
>>> intermediate working color space using tiffgamut/colprof (from a range
>>> of typical images), but I don't see how that could be done.
>>>
>>> Robert
>>
>>
>
>
>

[r***@public.gmane.org]

Hi Ben/Roger,

Here is an interesting observation: if you convert an image from ProPhoto to
Print via Beta RGB and compare it to the same image converted from ProPhoto
to Print direct, there's virtually no difference. If you do the same
comparison, but this time via eciRGB instead of BetaRGB, there is a
difference, albeit small. I assume that the difference via eciRGB is
because of quantization errors due to the L* curve.

I did the comparison using the Difference mode in Photoshop.

Based on this ... there may be something to be said for going Lightroom to
ProPhoto and then ProPhoto to Beta RGB, as edits in Beta RGB should have
fewer quantization errors than in ProPhoto, I would have thought (because it
uses a gamma of 2.2 instead of 1.8, and because it's a smaller space), while
not clipping the viewable colors in the original image.

Is it worth the trouble or not?? Does working in a gamma of 2.2
significantly reduce quantization errors when working in 16-bit (which I
always do)? Is it better, visually, to edit with a gamma of 2.2 instead of
1.8? I couldn't begin to answer these questions (!), but perhaps you could?

Regarding the Lightroom/ACR raw processing being optimized for 'pleasing'
colors rather than accurate colors ... that's OK for me as I don't do fine
art reproduction type work.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Ben Goren
Sent: 08 July 2014 01:20
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

There's another elephant in the room. Adobe's RAW development engine is
optimized for "pleasing" color, not accurate color. And, indeed, accurate
color isn't really an option with Adobe's RAW development engine; you can't,
for example, do decent fine art reproduction / giclee work with it.

RawPhotoProcessor is the best I've found. It outputs directly to BetaRGB, or
even to Lab.

As a practical matter, I've not run into gamut limitations with Beta RGB. It
encompasses either all or almost all of my iPF8100's gamut, even on baryta
papers. AdobeRGB, on the other hand, clips a bit on my best matte paper
(Museo Portfolio Rag), and substantially on baryta papers. The only other
space I output to is sRGB, which, of course, is fully encompassed by Beta
RGB.

In your shoes, ProPhoto may well be the least evil option, but it'd be worth
spending some time comparing gamut plots.

b&

On Jul 7, 2014, at 5:01 PM, Robert-/***@public.gmane.org wrote:

> Thanks for your suggestions! The main reason I use ProPhoto is that
> Lightroom only gives the options of sRGB, Adobe RGB or ProPhoto RGB to
> export to Photoshop. Also, Lightroom itself uses a variant of ProPhoto as
> its internal working space, so that there is no clipping when going from a
> raw image developed in Lightroom to ProPhoto in Photoshop.
>
> I can see that there would be an advantage in having a D50 white point
> (which ProPhoto RGB has).
>
> Beta RGB has a 2.2 gamma, eciRGB an L* curve and ProPhoto has a gamma of
> 1.8. I don't understand the pros and cons. Bruce Lindbloom says regarding
> gamma: "it is an important consideration for controlling quantization" and
> his conclusion is that a gamma of 2.2 is nearly optimal.
>
> And, finally and perhaps more importantly, as I am constrained to (sRGB,
> AdobeRGB or) ProPhotoRGB when going from Lightroom to Photoshop ... would
an
> extra conversion to eciRGB or Beta RGB not potentially cause damage to the
> image (for example in clipping OOG colors and quantization errors)?
>
> Robert
>
> -----Original Message-----
> From: argyllcms-bounce-***@public.gmane.org
[mailto:argyllcms-bounce-***@public.gmane.org]
> On Behalf Of Brad Funkhouser
> Sent: 07 July 2014 23:28
> To: argyllcms-***@public.gmane.org
> Subject: [argyllcms] Re: Custom Illuminant
>
>
> I agree, BetaRGB is also D50, which I like versus the D65s. I'll check
out
> eciRGB... That's not one I'm familiar with.
>
> Thanks for the suggestion.
>
> - Brad
>
>
>> On Jul 7, 2014, at 3:13 PM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:
>>
>> Also, what I like about eciRGB is the fact there is never any issues with
>> chromatic adaption since everything happens on a pure-D50 scale, from PCS
> to
>> RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...
>>
>> / Roger
>>
>> -----Original Message-----
>> From: argyllcms-bounce-***@public.gmane.org
> [mailto:argyllcms-bounce-***@public.gmane.org]
>> On Behalf Of Brad Funkhouser
>> Sent: 7 juillet 2014 14:40
>> To: argyllcms-***@public.gmane.org
>> Subject: [argyllcms] Re: Custom Illuminant
>>
>>
>> When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
>> Bruce Lindbloom's BetaRGB, it might be just right.
>>
>> - Brad
>>
>>
>>> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>>>
>>> << How does the gamut mapping know that no mapping is required ? If
>>> you tell it the source gamut is ProPhoto, then it will think that lots
>>> of gamut mapping is needed, since the ProPhoto gamut is so much larger
>>> than a printer !>>
>>>
>>> Well that has finally clarified that point for me! So with Perceptual
>>> the whole source gamut is squashed down to the destination gamut, even
>>> if all the colors are within the destination gamut. This means that
>>> in a Perceptual mapping from ProPhoto to print, colors will be
>>> compressed resulting in desaturation of the image, particularly of the
>>> more saturated colors nearer the print gamut boundary.
>>>
>>> So the following strategy might make sense for a Relative intent
>> conversion:
>>> - Going from ProPhoto to print, make sure the colors are more or less
>>> within the destination space to avoid too much clipping.
>>>
>>> And the following for Perceptual:
>>> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
>>> colors are more or less within the AdobeRGB space before the
>>> conversion to avoid too much clipping).
>>> - Do a Perceptual mapping from AdobeRGB to print.
>>>
>>> I did a comparison of a 1-step ProPhoto [Perceptual to Print
>>> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
>>> by an AdobeRGB Perceptual to print conversion]:
>>> - If the original image colors are all within the AdobeRGB gamut there
>>> is quite a difference if the print gamut is much smaller than
>>> AdobeRGB, but none if it is of similar size.
>>> - If the original image colors are outside the AdobeRGB gamut, the
>>> 2-step approach is significantly better even if the print gamut is
>>> very close to the AdobeRGB gamut.
>>> This is a bit puzzling because I would have expected a difference in
>>> all cases (if the full ProPhoto gamut is squashed down in a Perceptual
>>> conversion).
>>>
>>> What would be nice would be to be able to make the smaller
>>> intermediate working color space using tiffgamut/colprof (from a range
>>> of typical images), but I don't see how that could be done.
>>>
>>> Robert
>>
>>
>
>
>

[Roger Breton]

Robert,

Many moons ago, Bruce Lindbloom demonstrated mathematically that g2.2 was
better than 1.8 for everything.

/ Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of robert-/***@public.gmane.org
Sent: 8 juillet 2014 07:50
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Hi Ben/Roger,

Here is an interesting observation: if you convert an image from ProPhoto to
Print via Beta RGB and compare it to the same image converted from ProPhoto
to Print direct, there's virtually no difference. If you do the same
comparison, but this time via eciRGB instead of BetaRGB, there is a
difference, albeit small. I assume that the difference via eciRGB is
because of quantization errors due to the L* curve.

I did the comparison using the Difference mode in Photoshop.

Based on this ... there may be something to be said for going Lightroom to
ProPhoto and then ProPhoto to Beta RGB, as edits in Beta RGB should have
fewer quantization errors than in ProPhoto, I would have thought (because it
uses a gamma of 2.2 instead of 1.8, and because it's a smaller space), while
not clipping the viewable colors in the original image.

Is it worth the trouble or not?? Does working in a gamma of 2.2
significantly reduce quantization errors when working in 16-bit (which I
always do)? Is it better, visually, to edit with a gamma of 2.2 instead of
1.8? I couldn't begin to answer these questions (!), but perhaps you could?

Regarding the Lightroom/ACR raw processing being optimized for 'pleasing'
colors rather than accurate colors ... that's OK for me as I don't do fine
art reproduction type work.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Ben Goren
Sent: 08 July 2014 01:20
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

There's another elephant in the room. Adobe's RAW development engine is
optimized for "pleasing" color, not accurate color. And, indeed, accurate
color isn't really an option with Adobe's RAW development engine; you can't,
for example, do decent fine art reproduction / giclee work with it.

RawPhotoProcessor is the best I've found. It outputs directly to BetaRGB, or
even to Lab.

As a practical matter, I've not run into gamut limitations with Beta RGB. It
encompasses either all or almost all of my iPF8100's gamut, even on baryta
papers. AdobeRGB, on the other hand, clips a bit on my best matte paper
(Museo Portfolio Rag), and substantially on baryta papers. The only other
space I output to is sRGB, which, of course, is fully encompassed by Beta
RGB.

In your shoes, ProPhoto may well be the least evil option, but it'd be worth
spending some time comparing gamut plots.

b&

On Jul 7, 2014, at 5:01 PM, Robert-/***@public.gmane.org wrote:

> Thanks for your suggestions! The main reason I use ProPhoto is that
> Lightroom only gives the options of sRGB, Adobe RGB or ProPhoto RGB to
> export to Photoshop. Also, Lightroom itself uses a variant of ProPhoto
> as its internal working space, so that there is no clipping when going
> from a raw image developed in Lightroom to ProPhoto in Photoshop.
>
> I can see that there would be an advantage in having a D50 white point
> (which ProPhoto RGB has).
>
> Beta RGB has a 2.2 gamma, eciRGB an L* curve and ProPhoto has a gamma
> of 1.8. I don't understand the pros and cons. Bruce Lindbloom says
> regarding
> gamma: "it is an important consideration for controlling quantization"
> and his conclusion is that a gamma of 2.2 is nearly optimal.
>
> And, finally and perhaps more importantly, as I am constrained to
> (sRGB, AdobeRGB or) ProPhotoRGB when going from Lightroom to Photoshop
> ... would
an
> extra conversion to eciRGB or Beta RGB not potentially cause damage to
> the image (for example in clipping OOG colors and quantization errors)?
>
> Robert
>
> -----Original Message-----
> From: argyllcms-bounce-***@public.gmane.org
[mailto:argyllcms-bounce-***@public.gmane.org]
> On Behalf Of Brad Funkhouser
> Sent: 07 July 2014 23:28
> To: argyllcms-***@public.gmane.org
> Subject: [argyllcms] Re: Custom Illuminant
>
>
> I agree, BetaRGB is also D50, which I like versus the D65s. I'll
> check
out
> eciRGB... That's not one I'm familiar with.
>
> Thanks for the suggestion.
>
> - Brad
>
>
>> On Jul 7, 2014, at 3:13 PM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:
>>
>> Also, what I like about eciRGB is the fact there is never any issues
>> with chromatic adaption since everything happens on a pure-D50 scale,
>> from PCS
> to
>> RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...
>>
>> / Roger
>>
>> -----Original Message-----
>> From: argyllcms-bounce-***@public.gmane.org
> [mailto:argyllcms-bounce-***@public.gmane.org]
>> On Behalf Of Brad Funkhouser
>> Sent: 7 juillet 2014 14:40
>> To: argyllcms-***@public.gmane.org
>> Subject: [argyllcms] Re: Custom Illuminant
>>
>>
>> When AdobeRGB is a little too small, and ProPhotoRGB is just too big,
>> try Bruce Lindbloom's BetaRGB, it might be just right.
>>
>> - Brad
>>
>>
>>> On Jul 7, 2014, at 9:18 AM, <robert-/***@public.gmane.org> wrote:
>>>
>>> << How does the gamut mapping know that no mapping is required ? If
>>> you tell it the source gamut is ProPhoto, then it will think that
>>> lots of gamut mapping is needed, since the ProPhoto gamut is so much
>>> larger than a printer !>>
>>>
>>> Well that has finally clarified that point for me! So with
>>> Perceptual the whole source gamut is squashed down to the
>>> destination gamut, even if all the colors are within the destination
>>> gamut. This means that in a Perceptual mapping from ProPhoto to
>>> print, colors will be compressed resulting in desaturation of the
>>> image, particularly of the more saturated colors nearer the print gamut
boundary.
>>>
>>> So the following strategy might make sense for a Relative intent
>> conversion:
>>> - Going from ProPhoto to print, make sure the colors are more or
>>> less within the destination space to avoid too much clipping.
>>>
>>> And the following for Perceptual:
>>> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure
>>> the colors are more or less within the AdobeRGB space before the
>>> conversion to avoid too much clipping).
>>> - Do a Perceptual mapping from AdobeRGB to print.
>>>
>>> I did a comparison of a 1-step ProPhoto [Perceptual to Print
>>> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed
>>> by an AdobeRGB Perceptual to print conversion]:
>>> - If the original image colors are all within the AdobeRGB gamut
>>> there is quite a difference if the print gamut is much smaller than
>>> AdobeRGB, but none if it is of similar size.
>>> - If the original image colors are outside the AdobeRGB gamut, the
>>> 2-step approach is significantly better even if the print gamut is
>>> very close to the AdobeRGB gamut.
>>> This is a bit puzzling because I would have expected a difference in
>>> all cases (if the full ProPhoto gamut is squashed down in a
>>> Perceptual conversion).
>>>
>>> What would be nice would be to be able to make the smaller
>>> intermediate working color space using tiffgamut/colprof (from a
>>> range of typical images), but I don't see how that could be done.
>>>
>>> Robert
>>
>>
>
>
>

[r***@public.gmane.org]

Well then Roger ... I guess that's the end of the debate? Somehow I don't
think you're entirely convinced :).

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Roger Breton
Sent: 08 July 2014 13:12
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

Robert,

Many moons ago, Bruce Lindbloom demonstrated mathematically that g2.2 was
better than 1.8 for everything.

/ Roger

[Roger Breton]

This post might be inappropriate. Click to display it.

[Ben Goren]

On Jul 8, 2014, at 10:01 AM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:

> My very humble experience is leading me to believe that there are very few
> instances of saturated colors in photographs or every day pictorials?

Saturated colors are very uncommon. Most colorants have spectral profiles similar to those of the paints artists and home painters use. Yellows, oranges, and reds all reflect nothing shorter than a certain wavelength and have a steep transition to being highly reflective (and basically flat) at some point; where that point is is what determines their color, and how sharp the transition is determines their saturation. Greens and blues and violets have a single spectral peak that doesn't tend to be all that bright. The wavelength of the peak determines hue again, and the slope of the peak determines saturation. Then, of course, there're all the mixtures, including many metameric matches with much more complex spectra.

To get truly saturated colors you generally need quantum mechanics: diffraction gratings and variations on that theme (including butterfly wings), or lasers. (There are other sources, but none common).

But, even if you're photographing something iridescent or a laser light show or the like...how are you going to output those saturated colors?

Your monitor isn't going to come close. Your printer doesn't stand a chance.

Unless you're doing some sort of empirical analysis, the fact that you've got a digital file with numbers representing those colors really doesn't do you much good.

There might be some large gamut monitors or printers that are finally pushing the boundaries of BetaRGB. It's probably a good time to start thinking about an update (GammaRGB?) with a gamut expanded enough to accommodate the next couple generations of devices. But, unless you're already outputting to something with a gamut larger than BetaRGB, you're basically not going to find a better compromise than what BetaRGB already represents.

b&

[Roger Breton]

If memory serves, BetaRGB was created by Bruce Lindbloom a long time ago to
fully encompass one the going CMYK color gamut, was it SWOP? Its algorithms
were tuned to search the RGB primaries that would result in no clipping for
this "reference" CMYK gamut, if I recall. Ever heard of ColorSynergy from
PictoColor? Brings back lots of fond memories.

/ Roger

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Ben Goren
Sent: 8 juillet 2014 13:58
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

On Jul 8, 2014, at 10:01 AM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:

> My very humble experience is leading me to believe that there are very
> few instances of saturated colors in photographs or every day pictorials?

Saturated colors are very uncommon. Most colorants have spectral profiles
similar to those of the paints artists and home painters use. Yellows,
oranges, and reds all reflect nothing shorter than a certain wavelength and
have a steep transition to being highly reflective (and basically flat) at
some point; where that point is is what determines their color, and how
sharp the transition is determines their saturation. Greens and blues and
violets have a single spectral peak that doesn't tend to be all that bright.
The wavelength of the peak determines hue again, and the slope of the peak
determines saturation. Then, of course, there're all the mixtures, including
many metameric matches with much more complex spectra.

To get truly saturated colors you generally need quantum mechanics:
diffraction gratings and variations on that theme (including butterfly
wings), or lasers. (There are other sources, but none common).

But, even if you're photographing something iridescent or a laser light show
or the like...how are you going to output those saturated colors?

Your monitor isn't going to come close. Your printer doesn't stand a chance.

Unless you're doing some sort of empirical analysis, the fact that you've
got a digital file with numbers representing those colors really doesn't do
you much good.

There might be some large gamut monitors or printers that are finally
pushing the boundaries of BetaRGB. It's probably a good time to start
thinking about an update (GammaRGB?) with a gamut expanded enough to
accommodate the next couple generations of devices. But, unless you're
already outputting to something with a gamut larger than BetaRGB, you're
basically not going to find a better compromise than what BetaRGB already
represents.

b&

[Ben Goren]

On Jul 8, 2014, at 11:33 AM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:

> If memory serves, BetaRGB was created by Bruce Lindbloom a long time ago to
> fully encompass one the going CMYK color gamut, was it SWOP?

That was only one of his goals. He also wanted something that included the gamuts of various charts (multiple versions of the ColorChecker) and film stocks, and had efficiency and various other requirements (to reduce posterization, etc.). I don't think anybody else has put as much thought into a color space as Bruce did into BetaRGB. All color spaces are compromises one way or another, whether you want them to be or not; the only questions are what you're going to compromise. Bruce found a really, really good balance.

b&

[r***@public.gmane.org]

To me, Beta RGB is absolutely fine as it just encompasses my best print
gamuts, and my monitor (which is close to AdobeRGB) is well within it. As
you say, perhaps that will change, but I'm not too concerned, frankly.

ProPhoto is too big. What I would really like is to be able to click a
button and get a working space that has a gamut that is the intersection of
my print and monitor gamuts, so that I would not need to worry about OOG
colors!

sRGB is too small, ProPhoto too big, Beta RGB too big for my monitor ...
it's trying to fit a square peg into a round hole. Graeme mentioned in one
of his comments that a future icc model might be better based on a triangle
... and although he may have had other reasons for saying that, from a
user-perspective I couldn't agree more! It would certainly simplify things a
lot.

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Ben Goren
Sent: 08 July 2014 18:58
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

On Jul 8, 2014, at 10:01 AM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:

> My very humble experience is leading me to believe that there are very few
> instances of saturated colors in photographs or every day pictorials?

Saturated colors are very uncommon. Most colorants have spectral profiles
similar to those of the paints artists and home painters use. Yellows,
oranges, and reds all reflect nothing shorter than a certain wavelength and
have a steep transition to being highly reflective (and basically flat) at
some point; where that point is is what determines their color, and how
sharp the transition is determines their saturation. Greens and blues and
violets have a single spectral peak that doesn't tend to be all that bright.
The wavelength of the peak determines hue again, and the slope of the peak
determines saturation. Then, of course, there're all the mixtures, including
many metameric matches with much more complex spectra.

To get truly saturated colors you generally need quantum mechanics:
diffraction gratings and variations on that theme (including butterfly
wings), or lasers. (There are other sources, but none common).

But, even if you're photographing something iridescent or a laser light show
or the like...how are you going to output those saturated colors?

Your monitor isn't going to come close. Your printer doesn't stand a chance.

Unless you're doing some sort of empirical analysis, the fact that you've
got a digital file with numbers representing those colors really doesn't do
you much good.

There might be some large gamut monitors or printers that are finally
pushing the boundaries of BetaRGB. It's probably a good time to start
thinking about an update (GammaRGB?) with a gamut expanded enough to
accommodate the next couple generations of devices. But, unless you're
already outputting to something with a gamut larger than BetaRGB, you're
basically not going to find a better compromise than what BetaRGB already
represents.

b&

[Brad Funkhouser]

Well said, Ben.

My Epson 9900 can get a tiny bit outside of BetaRGB but only on my largest gamut paper, whereas it gets outside of AdobeRGB in several areas on several different papers.

BetaRGB is a good fit for me.

Some Acrylic paints do extend outside of BetaRGB, but not often and not by very much. In these cases, I fret over staying with BetaRGB for process consistency versus going to ProPhotoRGB for certainty that no colors get clipped.

- Brad


> On Jul 8, 2014, at 12:58 PM, Ben Goren <ben-1mufkuWgcO2x+LwX+***@public.gmane.org> wrote:
>
>> On Jul 8, 2014, at 10:01 AM, Roger Breton <graxx-XzQKRVe1yT0V+D8aMU/***@public.gmane.org> wrote:
>>
>> My very humble experience is leading me to believe that there are very few
>> instances of saturated colors in photographs or every day pictorials?
>
> Saturated colors are very uncommon. Most colorants have spectral profiles similar to those of the paints artists and home painters use. Yellows, oranges, and reds all reflect nothing shorter than a certain wavelength and have a steep transition to being highly reflective (and basically flat) at some point; where that point is is what determines their color, and how sharp the transition is determines their saturation. Greens and blues and violets have a single spectral peak that doesn't tend to be all that bright. The wavelength of the peak determines hue again, and the slope of the peak determines saturation. Then, of course, there're all the mixtures, including many metameric matches with much more complex spectra.
>
> To get truly saturated colors you generally need quantum mechanics: diffraction gratings and variations on that theme (including butterfly wings), or lasers. (There are other sources, but none common).
>
> But, even if you're photographing something iridescent or a laser light show or the like...how are you going to output those saturated colors?
>
> Your monitor isn't going to come close. Your printer doesn't stand a chance.
>
> Unless you're doing some sort of empirical analysis, the fact that you've got a digital file with numbers representing those colors really doesn't do you much good.
>
> There might be some large gamut monitors or printers that are finally pushing the boundaries of BetaRGB. It's probably a good time to start thinking about an update (GammaRGB?) with a gamut expanded enough to accommodate the next couple generations of devices. But, unless you're already outputting to something with a gamut larger than BetaRGB, you're basically not going to find a better compromise than what BetaRGB already represents.
>
> b&

[Graeme Gill]

Roger Breton wrote:

> Many moons ago, Bruce Lindbloom demonstrated mathematically that g2.2 was
> better than 1.8 for everything.

1.8 is a little on the low side, but in the range of acceptable
perceptual encoding. See "An analysis of Selected Computer Intechange
Color Spaces" by James M. Kasson and Wil Plouffe, ACM Transactions on
Graphics, October 1992, Volume 11 Number 4, page 396.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

Hi,

> Well that has finally clarified that point for me! So with Perceptual the
> whole source gamut is squashed down to the destination gamut, even if all
> the colors are within the destination gamut.

Well, it depends on how you do it. By default the source gamut will
be assumed to be that of the encoding space. But you can override
this with something more precise. ie. "colprof -g src.gam"
or "collink -G src.gam" etc.

> This means that in a
> Perceptual mapping from ProPhoto to print, colors will be compressed
> resulting in desaturation of the image, particularly of the more saturated
> colors nearer the print gamut boundary.

Yes.

> So the following strategy might make sense for a Relative intent conversion:
> - Going from ProPhoto to print, make sure the colors are more or less within
> the destination space to avoid too much clipping.

Yes, one approach is to manually gamut map in some way, and then use
a colorimetric conversion. In some cases a small amount of clipping provides
the "look" people are after by maintaining saturation, rather than
compressing to maintain the space for colors that may not be subjectively
so important. (This is a crude way of determining the "knee" in the
compression curve.)

> And the following for Perceptual:
> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the colors
> are more or less within the AdobeRGB space before the conversion to avoid
> too much clipping).
> - Do a Perceptual mapping from AdobeRGB to print.

Yes, that's one way. Another is to feed in a smaller gamut
as the source into colorpof/collink -g. The smaller
gamut could be from a colorspace (iccgamut) or from the images themselves (tiffgamut).

> What would be nice would be to be able to make the smaller intermediate
> working color space using tiffgamut/colprof (from a range of typical
> images), but I don't see how that could be done.

I don't see why you would want to use the 2 step process, when
a 1 step with a smaller source gamut specified is more efficient.

Graeme Gill.

[r***@public.gmane.org]

QUOTE
============================================================================
> And the following for Perceptual:
> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
colors
> are more or less within the AdobeRGB space before the conversion to avoid
> too much clipping).
> - Do a Perceptual mapping from AdobeRGB to print.

Yes, that's one way. Another is to feed in a smaller gamut
as the source into colorpof/collink -g. The smaller
gamut could be from a colorspace (iccgamut) or from the images themselves
(tiffgamut).

> What would be nice would be to be able to make the smaller intermediate
> working color space using tiffgamut/colprof (from a range of typical
> images), but I don't see how that could be done.

I don't see why you would want to use the 2 step process, when
a 1 step with a smaller source gamut specified is more efficient.
============================================================================
Hi Graeme,

Well, yes, of course I would much prefer to do a 1-step with a smaller gamut
but I wasn't able to generate the smaller-gamut profile. I have tried to do
this using tiffgamut and colprof with -g, but the gamut appears identical
with or without the -g (viewing the icc profiles using viewgam and also
GamutVision from Imatest). The gamut volumes shown by GamutVision are a bit
different, but not much: with -g: 840629; without -g: 848999.

I assumed that the effect of the -g was not to reduce the size of the gamut,
but rather to improve the efficiency of the gamut mapping.

Perhaps I'm doing something wrong. Here are the commands I used:

tiffgamut -v -w -pj -k -cmd -Omygam.gam t1.jpg t1.jpg t2.jpg t3.jpg

(All 3 JPGs have ProPhoto as the embedded profile.

With -g:
colprof -v -A"HP" -M"Z3100" -D"HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG" -qh
-cmd -dpe -SProPhoto.icm -gmygam.gam
-O"HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc"
"HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL"

Without -g:
colprof -v -A"HP" -M"Z3100" -D"HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL" -qh -cmd
-dpe -SProPhoto.icm -O"HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL.icc"
"HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL"

What is also interesting/puzzling is that mygam.gam is made from very
desaturated images, and yet its gamut is bigger in places than
HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc (iccgamut/viewgam). The Photoshop
gamut warning does not show any of the three images as being out of gamut
for HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc

If you would like to see the images, profiles and wrl files they are here:
http://www.irelandupclose.com/customer/argyll/gamlimiting.zip

Thanks!

Robert

[r***@public.gmane.org]

Graeme,

About your comment regarding the 1-step rather than 2-step process:

Quote
============================================================================
> And the following for Perceptual:
> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the
> colors are more or less within the AdobeRGB space before the
> conversion to avoid too much clipping).
> - Do a Perceptual mapping from AdobeRGB to print.

Yes, that's one way. Another is to feed in a smaller gamut as the source
into colorpof/collink -g. The smaller gamut could be from a colorspace
(iccgamut) or from the images themselves (tiffgamut).

> What would be nice would be to be able to make the smaller
> intermediate working color space using tiffgamut/colprof (from a range
> of typical images), but I don't see how that could be done.

I don't see why you would want to use the 2 step process, when a 1 step with
a smaller source gamut specified is more efficient.
===========================================================================

The reason I'm thinking of a 2-step process is that:
- Step 1: ProPhoto-to-AdobeRGB is a relative conversion that will only clip
OOG colors.
- Step 2: The Perceptual AdobeRGB-to-Print mapping should have a lesser
flattening/desaturating effect than would a direct Perceptual
ProPhoto-to-Print mapping (since the AdobeRGB space is smaller than the
ProPhoto RGB space).

Reducing the Print gamut by using colprof -g won't improve the ProPhoto to
Print desaturation ... it will only make it worse (I think).

As I find out more about the different working-space options, I'm beginning
to think that a ProPhoto-to-BetaRGB Step 1 would be better than a
ProPhoto-to-AdobeRGB Step 1 as BetaRGB is still significantly smaller than
ProPhoto, but still bigger than my print or monitor gamuts.

Do you agree?

Robert

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> Well, yes, of course I would much prefer to do a 1-step with a smaller gamut
> but I wasn't able to generate the smaller-gamut profile. I have tried to do
> this using tiffgamut and colprof with -g, but the gamut appears identical
> with or without the -g (viewing the icc profiles using viewgam and also
> GamutVision from Imatest).

Hi,
I'm not sure what you mean. The idea is to generate
an ICC profile that does gamut mapping from the smaller source
to the device gamut. Naturally this doesn't change the device
gamut itself, just the mapping.

> I assumed that the effect of the -g was not to reduce the size of the gamut,
> but rather to improve the efficiency of the gamut mapping.

You are confusing different things.

> tiffgamut -v -w -pj -k -cmd -Omygam.gam t1.jpg t1.jpg t2.jpg t3.jpg

> What is also interesting/puzzling is that mygam.gam is made from very
> desaturated images, and yet its gamut is bigger in places than
> HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc (iccgamut/viewgam).

> The Photoshop
> gamut warning does not show any of the three images as being out of gamut
> for HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc

That depends rather a lot on what Photoshop is doing.

If the gamut you get from tiffgamut is large, then I'm more inclined to believe that.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> What is also interesting/puzzling is that mygam.gam is made from very
> desaturated images, and yet its gamut is bigger in places than
> HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc (iccgamut/viewgam).

Hmm. This seems like it's a bug in tiffgamut, when handling jpg files :-(

With the bug fixed, yes they have a small gamut.

Workaround - convert to .tif and try it again.

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

I've tried it with tif files and I see the same problem. All the files are
here: http://www.irelandupclose.com/customer/argyll/mygamtest.zip

You can view the two spaces with mygam-and-profile.wrl

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 10 July 2014 03:07
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> What is also interesting/puzzling is that mygam.gam is made from very
> desaturated images, and yet its gamut is bigger in places than
> HP_Z3100_CANSONPHOTOHIGLOSS_ARGYLL_LG.icc (iccgamut/viewgam).

Hmm. This seems like it's a bug in tiffgamut, when handling jpg files :-(

With the bug fixed, yes they have a small gamut.

Workaround - convert to .tif and try it again.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> I've tried it with tif files and I see the same problem. All the files are
> here: http://www.irelandupclose.com/customer/argyll/mygamtest.zip

Hmm. - actually it looks like that bug is only in the
beta test code, not V1.6.3.

So, the gamut's I get using V1.6.3 or the .tif files are quite small, and
your .wrl shows that, so I'm not sure what you mean.

It's quite possible for colors to not look very saturated, yet be
out of gamut. Some of the image colors are very dark and saturated, so
it's not very surprising that the printer gamut doesn't encompass them.

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

Part of the problem was that I was relying on the Photoshop Soft-Proof
warning, which doesn't show colors clipped to black or to white (which you
identified).

The second problem was that I was that I was using -pj in tiffgamut and -pl
in iccgamut, so I wasn't comparing apples to apples. With both set to -pj,
an sRGB image which isn't clipped is within the sRGB gamut viewed with
viewgam.

Sorry!

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 11 July 2014 00:44
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I've tried it with tif files and I see the same problem. All the files
are
> here: http://www.irelandupclose.com/customer/argyll/mygamtest.zip

Hmm. - actually it looks like that bug is only in the
beta test code, not V1.6.3.

So, the gamut's I get using V1.6.3 or the .tif files are quite small, and
your .wrl shows that, so I'm not sure what you mean.

It's quite possible for colors to not look very saturated, yet be
out of gamut. Some of the image colors are very dark and saturated, so
it's not very surprising that the printer gamut doesn't encompass them.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:
> The second problem was that I was that I was using -pj in tiffgamut and -pl
> in iccgamut, so I wasn't comparing apples to apples. With both set to -pj,
> an sRGB image which isn't clipped is within the sRGB gamut viewed with
> viewgam.

Hi,
yes, that is a trap. It would be nice to make the tools a bit more
seamless in regard to that.

> If -g is not used, the Perceptual mapping is from the gamut of the source
> profile (which I will call SG) to the gamut of the destination profile
> (which I'll call DG). The B2A0 table, which is responsible for the
> Perceptual mapping, effectively 'squeezes' the whole of SG into DG. All of
> the colors that were present in SG will be remapped to new colors in DG,
> even if none of the colors in SG were outside of the DG gamut (the effect of
> the 'squeeze').
>
> The effect of using -g is to create a new gamut which is the union of DG and
> CG (which I will call UG).

No, effectively the Image Gamut (CG) becomes the Source Gamut (SG).

[There are some subtleties - an image gamut isn't expected to contain the source
colorspace white and black points, so the effective source gamut is the Image Gamut
supplemented by some information from the Source Colorspace Gamut.]

The gamut mapping creation is then basically the same.

> - The table then does a Perceptual mapping from UG to DG.

No, the table does a Perceptual mapping from the Image Gamut (CG) to Destination
Colorspace Gamut (DG).

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

Thanks for your reply. I've made some changes to my description (highlighted
within <<>>) to reflect your corrections with a couple of additions of my
own.

============================================================================
This note only describes the effect of the -g flag in colprof for a
Perceptual mapping only . however it can also be used for a Saturation
mapping.

The -g flag only affects the Perceptual B2A table (in order for this to be
generated by colprof, the -s flag is also required).

-g uses a gamut file which is produced either from tiffgamut (from a set of
images), or iccgamut (from an icc profile). <<There is no advantage to using
an icc profile gamut with -g as this can be better specified with the -s
flag and no -g flag.>> I'll refer to this gamut as the Custom Gamut, or CG.

If -g is not used, the Perceptual mapping is from the gamut of the source
profile (which I will call SG) to the gamut of the destination profile
(which I'll call DG). The B2A0 table, which is responsible for the
Perceptual mapping, effectively 'squeezes' the whole of SG into DG. All of
the colors that were present in SG will be remapped to new colors in DG,
even if none of the colors in SG were outside of the DG gamut (the effect of
the 'squeeze'). <<Where SG is smaller than DG, the boundary colors are not
shifted. >><<If there are image colors outside SG, they will be clipped to
the DG boundary.>>

<<The -g flag effectively replaces SG by CG (with the white and black points
coming from SG), so that the mapping now effectively 'squeezes' CG into
DG.>>

<<The effect is a Perceptual mapping that is less drastic than the full SG
to DG mapping (which can result in desaturation of the more saturated
colors, for example, because they are shifted to inside the DG gamut if SG
is larger than the image gamut). The problem with it is that if the image
contains colors that are outside CG, these colors will be clipped to DG, and
so the perceptual relationship will no longer be fully maintained. For this
reason, profiles using -g should only be used when the image gamut is known
to be inside of CG: this can only be guaranteed if the image is part of the
set of images used in tiffgamut to make CG. With caution, the profile could
be used for an image that was not used to created CG, IF it is known, within
reason, that its gamut is approximately within CG.>>

The reason for this sort of approach is to attempt to reduce the
desaturation that can be the result of a Perceptual mapping from a large
color space to a smaller one. (It is also applicable to Saturation
mappings).

<<If the image gamut is not known to be within CG and we do not wish to
produce a new profile . but we wish to soften the full SG to DG squeeze, an
alternative strategy to using the -g flag is to do a Relative Colorimetric
mapping to an intermediate-sized gamut (for example from ProPhoto to Adobe
RGB), followed by a Perceptual mapping to DG.>>
===========================================================================

Am I nearer the mark this time?

As a slight aside, how are profiles which have no source profile specified
usually made, do you know (for example by i1Profiler)? Must they assume
some intermediate gamut like Beta RGB (smaller than ProPhoto but larger than
AdobeRGB), or is there some alternative algorithm that doesn't require the
source profile?

Many thanks,

Robert

[Graeme Gill]

robert-/***@public.gmane.org wrote:

Hi,

> -g uses a gamut file which is produced either from tiffgamut (from a set of
> images), or iccgamut (from an icc profile). <<There is no advantage to using
> an icc profile gamut with -g as this can be better specified with the -s
> flag and no -g flag.>>

This isn't accurate. You can get away with it in colprof, but not for collink,
so it's worth keeping it straight.
The source ICC profile specifies the source colorspace that the images
are encoded in. By default, it also implies a source gamut, that of
the colorspace itself. The -g flag allows overriding that assumption
and specifying a different source gamut, encoded in the ICC's colorspace.

Summary:
Source Profile = ProPhoto.icm, Image gamut = sRGB is quite
different to Source Profile = sRGB, since you are specifying
different encoding spaces.

> I'll refer to this gamut as the Custom Gamut, or CG.

I'd prefer to stick to the Argyll nomenclature, and call it image gamut.

> <<If there are image colors outside SG, they will be clipped to
> the DG boundary.>>

That should be impossible, because by definition an image gamut of an
image encoded in a particular colorspace, can't be outside the colorspaces gamut.

Yes, I think my code will cope if this does happen, but the only way it can
happen is if you create an image gamut of an image in a different color space
to the source color space. Once again, you might get away with configuring
a workflow that is OK in this situation with colprof, but not with collink,
and the chances of getting it all wrong are quite high.

> <<The -g flag effectively replaces SG by CG (with the white and black points
> coming from SG), so that the mapping now effectively 'squeezes' CG into
> DG.>>

Close enough.

> <<The effect is a Perceptual mapping that is less drastic than the full SG
> to DG mapping (which can result in desaturation of the more saturated
> colors, for example, because they are shifted to inside the DG gamut if SG
> is larger than the image gamut).

That depends strictly on how the image gamut compares with the source colorspace
gamut, and how that compares with the destination gamut. The most dramatic
difference is when the source gamut is much larger than the destination, but
the image gamut is not.

> The problem with it is that if the image
> contains colors that are outside CG, these colors will be clipped to DG, and
> so the perceptual relationship will no longer be fully maintained.

That can be a good thing - that's why tiffgamut has the ability to filter
the colors. You probably don't want to compress the gamut just to accommodate
a couple of percent of the image that are highly saturated colors - compressing
the bulk of the images gamut less and clipping those few pixels may well give
you a better visual result. (This is why sometimes people prefer relative
colorimetric when the bulk of the image gamut is within the destination
gamut, even if small parts are outside.)

> For this
> reason, profiles using -g should only be used when the image gamut is known
> to be inside of CG: this can only be guaranteed if the image is part of the
> set of images used in tiffgamut to make CG. With caution, the profile could
> be used for an image that was not used to created CG, IF it is known, within
> reason, that its gamut is approximately within CG.>>

There are no hard rules there. When you have images stored in a wide gamut
space, then it's a matter of judgement in relation to the images themselves
as to how to define their gamut for the purposes of rendering them
into a restricted colorspace. Critical cases may involve manual adjustment,
just like they always have.

Images already rendered into a more restricted space (ie. sRGB)
can usually be dealt with much more straightforwardly.

(Cue discussions of "early binding" vs. "late binding",
"image referred" vs. "output referred" etc.)

> The reason for this sort of approach is to attempt to reduce the
> desaturation that can be the result of a Perceptual mapping from a large
> color space to a smaller one. (It is also applicable to Saturation
> mappings).

That's one way of putting it. Another way is that it's simply
nonsense to use a wide gamut color space encoding as the source
gamut for gamut mapping, and you get what you deserve if you
try it.

> <<If the image gamut is not known to be within CG and we do not wish to
> produce a new profile . but we wish to soften the full SG to DG squeeze, an
> alternative strategy to using the -g flag is to do a Relative Colorimetric
> mapping to an intermediate-sized gamut (for example from ProPhoto to Adobe
> RGB), followed by a Perceptual mapping to DG.>>

Maybe. Normally using the right options with tiffgamut + collink + cctiff
is all that's needed.

> As a slight aside, how are profiles which have no source profile specified
> usually made, do you know (for example by i1Profiler)? Must they assume
> some intermediate gamut like Beta RGB (smaller than ProPhoto but larger than
> AdobeRGB), or is there some alternative algorithm that doesn't require the
> source profile?

I don't know - it's always been a mystery, and is one of the fundamental
puzzles around the ICC profile format. My guess would be that they use an
unspecified source gamut (a little like the PRMG) and/or they use a more general
non-linear compression curve which starts to compress within (say) 20%
of the gamut boundary and then asymptotes to a flat line (ie. a "soft clipping"
type curve). The results are unlikely to be optimal.

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

Thanks for your reply. It's a slow process for me!

I've made some further changes to my description (highlighted within <<>>)
to reflect your corrections.

===========================================================================
This note only describes the effect of the -g flag in colprof for a
Perceptual mapping only . however it can also be used for a Saturation
mapping.

The -g flag only affects the Perceptual B2A table (in order for this to be
generated by colprof, the -s flag is also required).

-g uses a gamut file which is produced either from tiffgamut (from a set of
images), or iccgamut (from an icc profile). I'll refer to this gamut as the
Image Gamut, or IG.

If -g is not used, the Perceptual mapping is from the gamut of the source
profile (which I will call SG) to the gamut of the destination profile
(which I'll call DG). The B2A0 table, which is responsible for the
Perceptual mapping, effectively 'squeezes' the whole of SG into DG. All of
the colors that were present in SG will be remapped to new colors in DG,
even if none of the colors in SG were outside of the DG gamut (the effect of
the 'squeeze'). Where SG is smaller than DG, the boundary colors are not
shifted. <<If there are image colors outside SG, they will be clipped to the
DG boundary. This can only happen if the profile is used to map an image
with a large gamut from a larger colorspace than the one specified in
colprof. in other words if the profile mapping is incorrectly applied.>>

The -g flag effectively replaces SG by IG (with the white and black points
coming from SG), so that the mapping now effectively 'squeezes' IG into DG
<<with further possible mapping if the source and destination white points
are different.>>

The effect is a Perceptual mapping that is less drastic than the full SG to
DG mapping (which can result in desaturation of the more saturated colors,
for example, because they are shifted to inside the DG gamut if SG is larger
than the image gamut). <<A possible problem, but one that may possibly give
a more pleasing effect, is that if the image contains colors that are
outside IG (which could happen if the image was not part of the set used to
create IG), these colors will be clipped to DG, and so the perceptual
relationship will no longer be fully maintained.>> For this reason,
profiles using -g should <<normally>> only be used when the image gamut is
known to be inside of IG: this can only be guaranteed if the image is part
of the set of images used in tiffgamut to make IG. With caution, the
profile could be used for an image that was not used to created IG, IF it is
known, within reason, that its gamut is approximately within IG, <<or at
least not much larger>>. <<At any rate, for all conversions a visual check
should normally be done, and where the CMM is seen not to handle the
conversion as desired, the image should be adjusted manually.>>

The reason for this sort of approach is to attempt to reduce the
desaturation that can be the result of a Perceptual mapping from a large
color space to a smaller one. (It is also applicable to Saturation
mappings). <<However, it should be noted that the desaturation effect will
be greatest for mappings from large gamuts to small ones, so that choosing a
working space with a smaller gamut may present an alternative approach: in
which case the generation of a profile with an IG could be restricted to
problematic images.>>

If the image gamut is not known to be within IG and we do not wish to
produce a new profile . but we wish to soften the full SG to DG squeeze, an
alternative strategy to using the -g flag <<may be>> to do a Relative
Colorimetric mapping to an intermediate-sized gamut (for example from
ProPhoto to Adobe RGB), followed by a Perceptual mapping to DG. <<However,
normally using the right options with tiffgamut + collink + cctif will
achieve the desired effect .. which I currently have NO idea how to use but
clearly need to look at!>>
============================================================================

Thanks again!

Robert

[r***@public.gmane.org]

Hi,

I would very much appreciate it if someone could give me a bit of a hand
doing a conversion of an image to destination using collink and cctif. I've
never used these before and as usual I'm struggling to understand the
basics.

I've used these commands as a test:
collink -v -qm -g -ip -cmt -dpp ProPhoto.icm HP_Z3100_EpsonEnhancedMatte.icc
PP2EEM.icm
cctiff -v -ip -e HP_Z3100_EpsonEnhancedMatte.icc PP2EEM.icm test.tif
perctest.tif

As far as I can see perctest.tif has been converted to the pp2eem.icm
profile using a perceptual mapping. The HP_Z3100_EpsonEnhancedMatte.icc
profile is correctly embedded.

Am I doing the correct thing?

Many thanks,

Robert

[Ben Goren]

On Jul 16, 2014, at 7:15 AM, Robert-/***@public.gmane.org wrote:

> I would very much appreciate it if someone could give me a bit of a hand
> doing a conversion of an image to destination using collink and cctif.

I've had great luck with this short Perl script:

--------8<--------cut-here--------8<--------
#!/usr/bin/perl -w

use strict;

my $inprofile = $ARGV[0];
my $outprofile = $ARGV[1];
my $intiff = $ARGV[2];
my $outtiff = $ARGV[3];

my $gam = $intiff; $gam =~ s/\.tif*$/.gam/;
my $linkprofile = $intiff; $linkprofile =~ s/\.tif*$/.icm/;

my $argyllbin = '/Users/ben/Documents/Profiles/argyll/bin/';

`${argyllbin}tiffgamut -v -p j \"${inprofile}\" \"${intiff}\"`;

`${argyllbin}collink -v -q h -G \"${gam}\" -i p \"${inprofile}\" \"${outprofile}\" \"${linkprofile}\"`;

`${argyllbin}cctiff -e \"${outprofile}" \"${linkprofile}\" \"${intiff}\" \"${outtiff}\"`;
-------->8--------cut-here-------->8--------

That does perceptual rendering, which is what one generally wants in practice outside of proofing scenarios and variations on that theme. But you can, of course, change the "-i p" to anything you like.

Cheers,

b&

[r***@public.gmane.org]

Hi Ben,

Thanks for your Perl script. I was glad to see it wasn't a million miles
from what I was doing (except for the addition of the image gamut).

I've tried it on three images (all in ProPhoto) converted to 3 different
print profiles. I then compared them to the images converted to the same
print profiles in Photoshop.

Two of the images match the original significantly better than the ones
converted in Photoshop (which is excellent and as I would have expected,
particularly going from a huge working-space like ProPhoto). The Photoshop
versions are significantly lighter with less contrast.

With the third image, which is converted to an Epson Enhanced Matte paper (I
tried both an Argyll-generated profile and a profile generated by my HPZ3100
printer), the Photoshop conversion is better. Some of the shadow areas are
quite flattened in the cctiff version. The Enhanced Matte Paper is a pretty
awful paper with a very poor DMax and small gamut ... but I would have
thought that cctiff would do a better job than a one-step ProPhoto to print
profile in Photoshop.

I'll try a few more images, but apart from the third image it's very
encouraging!

Thanks again!

Robert

[Ben Goren]

On Jul 16, 2014, at 2:22 PM, <robert-/***@public.gmane.org> wrote:

> With the third image, which is converted to an Epson Enhanced Matte paper (I
> tried both an Argyll-generated profile and a profile generated by my HPZ3100
> printer), the Photoshop conversion is better.

As Graeme indicated elsewhere in this thread, you might try filtering out gamut extremes, especially if it's just for some small spikes that are hopeless anyway. I haven't had to play around with that, but it sounds like the problem you're experiencing.

Graeme, might there be some way to add an option or some other tweak to automatically ignore outliers beyond a certain standard deviation, or the like? Manually figuring out what parts of the gamut to ignore can be a challenge, and I rather suspect that some sort of programmatic smoothing is going to do a better job than most of us humans would anyway.

b&

[Graeme Gill]

Ben Goren wrote:

> Graeme, might there be some way to add an option or some other tweak to automatically
> ignore outliers beyond a certain standard deviation, or the like?

Hi,
that's the type of thing that "tiffgamut -f perc" is meant to do.
It filters by popularity. So the idea is that you would routinely
use something like "tiffgamut -f 90", so that the image gamut represents
90% if the image content.

I really need more feedback to add anything else or change how this works - ie.
some examples in which this works poorly, and in which a different
statistical approach might work better.

Graeme.

[Ben Goren]

On Jul 16, 2014, at 4:57 PM, Graeme Gill <graeme-***@public.gmane.org> wrote:

> Ben Goren wrote:
>
>> Graeme, might there be some way to add an option or some other tweak to automatically
>> ignore outliers beyond a certain standard deviation, or the like?
>
> that's the type of thing that "tiffgamut -f perc" is meant to do.

I (obviously!) did not know. I actually don't tend to run into this problem personally, so I'm probably not the best one to turn to for feedback. Still, I'll try playing around with it a bit....

b&

[r***@public.gmane.org]

Graeme wrote

<<I really need more feedback to add anything else or change how this works
- ie. some examples in which this works poorly, and in which a different
statistical approach might work better.>>

Hi Graeme,

I've done a few tests and the results from one set is available here:
http://irelandupclose.com/customer/argyll/argyll-collink-test.zip

The profiles are in the zip file - however you will need Photoshop to
examine the results.

Just to summarise: what I did was to do 3 tests with 2 profiles:
A. Argyll-generated profile using colprof (test profile with only 700
patches).
B. Canson-supplied profile.

The tests were as follows, on an Image in ProPhoto:
1. Convert the image to the destination profile using
tiffgamut/collink/cctif (windows .bat and perl script are in the zip file).
2. Convert the image to the destination using Perceptual with BPC (in
Photoshop).
3. Convert the image to BetaRGB with Relative Colorimetric, followed by
Perceptual conversion to destination (all in Photoshop).

The converted images were then converted back to ProPhoto using RC (I
checked carefully that there was no perceptual change in the conversion back
to ProPhoto). The image in the zip file has all of these images in layers,
plus the original. You can toggle the layers manually, or use the Layer Comp
which is a bit easier. Also, toggling the group masks on and off helps the
comparison.

My conclusion is as follows (on this image, but also on another image which
gave quite similar results):

A1: (Argyll Profile -cctiff). Very good, with the OOG oranges/yellows being
desaturated a bit, slight loss of contrast and the yellows shifted slightly
towards green.
A2: (Argyll Profile -Photoshop). Very bad. The whole image is lightened and
desaturated.
A3: (Argyll Profile -2Step). Very good. OOG oranges/yellows brightened,
slight loss of contrast, but quite acceptable.
B1: (Canson Profile -cctiff). Not great. Image is generally desaturated in
the yellows and greens.
B2: (Canson Profile -Photoshop). Good, but the yellows are brightened
considerably, slight loss of contrast.
B3: (Canson Profile -2Step). Very good. Same as A3. A3 and B3 appear
identical.

So overall, the cctiff approach seems very good providing the print profile
was generated using colprof. The perceptual mapping in Photoshop using the
colprof profile is bad. The perceptual mapping in Photoshop using the Canson
profile is OK. The 2-step approach is very good with both the Canson and
colprof profiles.

The one missing test here is a 2-step test with the perceptual mapping using
cctiff.

Based on these tests (very limited, I know) I would favour either the 2-step
approach or using cctiff etc., with a colprof-generated print profile. I
would be very careful before using a Perceptual mapping in Photoshop using a
colprof-generated profile (at least not with this 700-patch profile!).

I would also be quite encouraged towards using a smaller working space than
ProPhoto :).

I hope that helps.

Robert

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> The reason I'm thinking of a 2-step process is that:
> - Step 1: ProPhoto-to-AdobeRGB is a relative conversion that will only clip
> OOG colors.
> - Step 2: The Perceptual AdobeRGB-to-Print mapping should have a lesser
> flattening/desaturating effect than would a direct Perceptual
> ProPhoto-to-Print mapping (since the AdobeRGB space is smaller than the
> ProPhoto RGB space).

Right, if you use the default of assuming that the images occupy
their encoding space.

> Reducing the Print gamut by using colprof -g won't improve the ProPhoto to
> Print desaturation ... it will only make it worse (I think).

It shouldn't. You should be able to do the AdobeRGB to output gamut
mapping with the input images encoded in ProPhoto space. That's
what -g is for.

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

I would like to make sure I understand what is happening when using -g with
colprof. Here is what I think happens (I'll only cover Perceptual):

The -g flag only affects the Perceptual B2A table (in order for the
Perceptual B2A0 table to be generated by colprof, the -s flag is also
required).

-g uses a gamut file which is produced either from tiffgamut (from a set of
images), or iccgamut (from an icc profile). I'll refer to this gamut as the
Custom Gamut, or CG.

If -g is not used, the Perceptual mapping is from the gamut of the source
profile (which I will call SG) to the gamut of the destination profile
(which I'll call DG). The B2A0 table, which is responsible for the
Perceptual mapping, effectively 'squeezes' the whole of SG into DG. All of
the colors that were present in SG will be remapped to new colors in DG,
even if none of the colors in SG were outside of the DG gamut (the effect of
the 'squeeze').

The effect of using -g is to create a new gamut which is the union of DG and
CG (which I will call UG).

The B2A0 table now 'does' the following:
- Colors that are outside of UG (but within SG) are effectively mapped to UG
using a Relative Colorimetric mapping.
- The table then does a Perceptual mapping from UG to DG.
(I assume that the two steps above are combined into one, seeing as how
there's only one mapping).

The effect is similar to doing a Relative Colorimetric mapping to a working
space a bit larger than DG followed by a Perceptual mapping to DG. However
it is potentially better because it can be controlled more precisely: the
size and shape of UG can be closely matched to the size and shape of the
union of DG and of an individual image, if this sort of precision is
required.

The reason for this sort of approach is to attempt to reduce the
desaturation that can be the result of a Perceptual mapping from a large
color space to a smaller one. (It is also applicable to Saturation
mappings).

I would very much appreciate it if you would confirm if this is essentially
correct (or correct me if I'm wrong).

Many thanks

Robert

[r***@public.gmane.org]

Quote:
---------------------------------------------------------------------------
> - I'm not sure if I mentioned this, but Soft-Proofing with Simulate Paper
in
> Photoshop does the equivalent of: Convert to Profile with selected intent;
> Convert back to working space with Absolute Colorimetric.

Right, but exactly how does it convert from the printing device to display ?
You say "with Absolute Colorimetric", but for the printer to PCS _and_ PCS
to display, or
just the first part ?

Note that the ICC seem to think that people expect/want the "half absolute"
conversion,
where it becomes a relative colorimetric interpretation of the absolute
appearance
of the print (hence the forced use of the chromatic adaptation tag in V4).
This is not
strict soft proof. A strict soft proof is absolute for both, so that the
XYZ values on
the screen are the same as the XYZ of the (expected) print.
----------------------------------------------------------------------------
Reply:

I don't know how to test this properly. What I've done is to use three
copies of a ColorChecker image.
Copy1 is soft-proofed with RelCol, Simulate Paper On
Copy2 is converted to paper using RelCol, converted to working space using
AbsCol, converted to monitor using RelCol
Copy3 is converted to paper using RelCol, converted to monitor using AbsCol

The D50 Lab values measured using an i1Pro (same spot, measurements taken
seconds from each other) are close to each other.

Delta E from Copy1 to Copy2 is 1.4 on yellow
Delta E from Copy1 to Copy3 is 0.5 on yellow

Delta E from Copy1 to Copy2 is 0.9 on blue
Delta E from Copy1 to Copy3 is 0.8 on blue

So, hardly conclusive, but slightly favouring the AbsCol to monitor (not
AbsCol followed by RelCol).

If you know how I can test this correctly I'll be happy to give it a go.

Robert

[r***@public.gmane.org]

Hi Graeme,

I'm not quite sticking to my promise of doing some studying before getting
back to questions!

I read your note "About ICC Profiles and Gamut Mapping" and I would like to
clarify a couple of things:
- You say: "The colorimetric intent is meant to convey the exact device
color behaviour, without any gamut mapping". Clearly there is clipping that
occurs on output to a device like a printer. Are you saying that the
clipping is effectively left to the printer, so the CMM will just output
colors without caring if these colors can be printed or not?
- You say in relation to ICC V2 behaviour: "The main disadvantage is that
the gamut mapping will only operate exactly as intended when the profile is
linked with the source profile it was setup for". (This only relates to
Perceptual and Saturation as Colorimetric does not do a gamut mapping). I
take it that for a print profile, that the source profile should normally be
the working space? I had put the monitor profile in the -S flag in colprof,
but this would seem to be incorrect. Do I understand correctly that if the
profile is made with -S AdobeRGB1998.icc but the working space is ProPhoto
RGB that the Perceptual and Saturation gamut mappings will not operate as
intended (I was going to say 'wrong', but I'm sure you would tell me that
there is no 'right' or 'wrong' in these matters :)).
- You say in relation to ICC V4 behaviour: "The chief drawback, is that only
one (non colorimetric) intent can really be supported, that of saturation".
If I understand you correctly (that if you stretch and compress to and from
the RMG in Perceptual that some horrible things are likely to happen) that
we then we use Perceptual to our peril in V4 LUT-based profiles. Is that
correct? If so, that's a very useful bit of information!!

Regards,

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 05 July 2014 06:37
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

Hi,

> The Argyll printer profiles I've looked at use B-curves, which is why I
> wondered what they are for.

They are the inverse of the A2B curves, which are chosen to improve
the profile fit, as well as shift the white point to be on a grid point,
so that it will be mapped with precision.

> The
> matrix is in XYZ as you say. I would have expected an Argyll Illuminant A
> profile, for example, to have an A to D50 matrix ... but maybe Graeme does
> it some other way?

No, because that would defeat the purpose. The point of the chad tag
is to say "and by the way, the instrument measured XYZ values using some
other illuminant, but we converted it to be as if it had been measured under
D50 by
applying a chromatic transform". This is not as accurate as doing this
spectrally using
the spectral reflectance, or, best of all, using actual D50 measurement
illuminant, but
is the best that can be done in this situation to make it conform to the PCS
requirements.

The point of creating a (non-standard) profile with a non-standard
illuminant
is to actually represent the color appearance under that illuminant, not to
make it as if this wasn't the case undoing it and using a chad tag.

> All the printer profiles I've looked at have a gamt tag. These have 3
> curves and one LUT. I had a guess at the purpose of the LUT data (3
inputs
> one output) but I can't even begin to guess at the purpose of the curves!

The gamt tag is meant to represent the gamut boundary in a binary way. So
typically the 3D Lut maps the PCS to some value that tries to represent
the "in gamutness" of the color in an continuous way, and the 1D lookup
at the end quantizes it. The result is a not-very accurate gamut boundary
representation, which is why no-one uses it.

> I should just forget it and move on ... but I'm one of these people who
feel
> a need to have some understanding of the underlying technology. I'll do a
> bit more reading and see if I can find something that sheds some light on
> these mysteries!

Phil Green's book goes into ICC in more detail, but given the flexibility
of the format and the different possible approaches, won't cover everything,
and certainly won't cover the unique things that ArgyllCMS does.

Graeme Gill.

[Graeme Gill]

Roger Breton wrote:

> What does the specs says about this, I am not sure? But I do remember that,
> a few years ago, only ProfileMakerPro allowed the use of a non-standard
> illuminant in profile calculations. I'm not sure what kind of normalization
> goes on in this scenario...

Does it ?

Argyll has supported this for a long time (Over 10 years ?)

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> Perhaps I could explain what my current understanding of, say, a BtoA1
> mapping does.
>
> LUT
> 1. The individual L*a*b* (or XYZ if the PCS is in XYZ)) values are fed into
> B-curves, one for each channel, which corrects something (I don't know
> what).

Profiles don't correct for anything in particular - the A2B table is meant
to capture the behaviour of the device as a device to PCS mapping. The B2A
provides a convenient inverted version of the A2B, allowing rapid conversion
of PCS to device space. Intent modified B2A tables allow for other mappings
to be applied as well.

The B2A structure provides computation mechanism that the profile
builder can use as they see fit, so it's not really possible to
ascribe a purpose to each step unless you examine the details of
the profile building software, and maybe not even then. Different
software may use different bits for different purposes.

> 2. The Lab output of the B-curves may be fed into a chromatic adaptation
> matrix (the chad tag) to make corrections from D50 to, say, a Solux lamp as
> illuminant. I assume (probably incorrectly) that what this does is to bump
> up the blues and maybe the greens (in the case of the Solux lamp) and dampen
> down the reds, so that the general color balance of the print under the
> Solux lamp will be close to the color balance under a D50 illuminant.

Not for V2 cLUTs, no.
V2 cLUTs have a 3x3 matrix (only if the PCS is XYZ), followed by the 1D lookups followed
by nD lookup, followed by 1D lookups.

You can't assume that the 3x3 is for anything related to chromatic adaptation,
it could be used for other purposes, with chromatic adaptation hidden elsewhere
in the transformation.

> 3. The Lab output of the chromatic adaptation matrix, if it exists, is (may
> be?) fed into M-curves which corrects something (I don't know what).

You don't typically apply chromatic adaptations in L*a*b* space.

> 5. The outputs of the B-curves or the M-curves (if they exist) are fed into
> the color LUT. This maps the Lab values to RGB values (and does the gamut
> mapping? or is the gamut mapping done using the gamt tag data?).

Yes, typically most 3D gamut mapping is done in the cLUT table. The gamt tag
has nothing to do with this.

> 4. The RGB values are fed into A-curves which correct for the non-linearity
> of the printer.

Maybe. Maybe not. It's up to the profile builder.

> 5. The corrected RGB values are sent to the printer.

> And, lastly, in the Argyll profiles I don't see a 'chad' tag even though the
> profile's for a non-D50 illuminant. Does that mean that there is no
> chromatic adaptation being done? The profile was created using -i and a .sp
> file.

The 'chad' tag is for the situation where the instrument illuminant is
not (or does not emulate) being D50. If you are using a spectrometer,
this is not usually the case, since D50 measurements are computed from
the spectral reflectance values.

For ICC V4 the ICC has twisted the display situation to treat it as
if the 'illuminant' was D65, and therefore use the 'chad' tag.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> My English is sloppy. What I really meant is that the gray lines are
> brought into line (so to speak) ... so (normally) there will be a greater
> shift at the white point, less at the middle gray and least at the black
> point. But at a particular luminance level, are not all colors shifted by
> the same amount in an Absolute Colorimetric transform? I take it that this
> is what you said above?

Hi,

I guess my response was a round about way of saying "I don't understand
what you were trying to say". Absolute and Relative colorimetric only differ
by the application of a chromatic adaptation matrix. Relative colorimetric
maps white to the PCS white point, Absolute colorimetric returns the instrument
readings for white.

> I don't know what a chromatic adaptation matrix does, or how it is produced.

Typically (ie. 99.9 % of the time) a chromatic adaptation matrix uses the
Von Kries principle, which basically means scaling the 3 components independently
to map one white value to another white value. What makes it a useful
transform is to do it in the right linear light space, typically a "sharpened
cone" type space. You do that by taking the XYZ and multiplying by the 3x3 matrix
that converts to the cone space, apply the per component scaling, then undo
the 3x3 matrix to take you back to XYZ space. All three steps can be
combined into a single 3x3 chromatic adaptation matrix.

> Are you talking about the illuminant and FWA compensations? If so, is there
> a separate mapping matrix (as you imply) or is the compensation built in to
> the table?

FWA is nothing to do with the white point, it is to do with estimating
the reflectance of a surface under a different illuminant to the one
the instrument is actually using.

> If you know of any really good literature on this whole subject (which would
> be comprehensible to someone without a background in color theory) I would
> be very grateful for the reference. I do have an engineering degree so I
> can cope with a certain amount of maths, but preferably not too much!

I'm not sure that I can give you a good reference. There are certainly
well known reference books such as Hunt or Wyszecki & Stiles or
Judd & Wyszecki etc., but if you want a concise introduction, I actually
like the first few chapters of Mark Fairchilds's "Color Appearance Models",
as well as Ján Morovič's "Color Gamut Mapping". The meat of both of these
books is about more specialized subjects, but the introductions cover
color science basics pretty nicely.

Graeme Gill.


[http://www.amazon.com/Color-Appearance-Models-Mark-Fairchild/dp/1119967031]
[http://www.amazon.com/Color-Gamut-Mapping-225-Morovi/dp/0470030321]

[http://www.amazon.com/Color-Management-Understanding-Using-Profiles/dp/0470058250]
[http://www.amazon.com/Billmeyer-Saltzmans-Principles-Color-Technology/dp/047119459X]

[http://www.amazon.com/Reproduction-Colour-R-W-Hunt/dp/0470024259]
[http://www.amazon.com/Measuring-Colour-R-W-Hunt/dp/1119975379]
[http://www.amazon.com/Color-Science-Concepts-Quantitative-Formulae/dp/0471399183]
[http://www.amazon.com/Business-Science-Industry-Applied-Optics/dp/0471452122]

[Knut Inge]

K hokkkcyyyopkjykykykpo jo kanskje i ikke
2. juli 2014 13:29 skrev <robert-bwQay9wdFlLEb97390d+***@public.gmane.org> fÞlgende:

> Hi,
>
> I think I have a somewhat better understanding of what's going on now.
>
> What Photoshop does when simulating paper color is to do a normal transform
> from the PCS to the destination using the chosen intent and then it does an
> Absolute transform from destination back to the PCS. I guess that this
> will
> work as the absolute AtoB transform will only affect the white point (or
> gray line).
>
> Certainly modifying the wtpt (and bkpt) values in the profile to match the
> paper under the particular illuminant does give a very accurate soft-proof
> when the paper and monitor image are viewed side-by-side.
>
> I'm confused about what happens if we do a round-trip conversion from, say
> ProPhoto to Destination and back to ProPhoto using a Perceptual intent
> (say).
>
> What I would expect would be:
> 1. ProPhoto->PCS: Relative (since the working space uses a
> matrix-based profile). Uses ProPhoto Profile.
> 2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
> 3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
> 4. PCS->ProPhoto: Relative. Uses ProPhoto profile.
>
> If that was the case then I would expect to see a change at 3, which I do
> if
> I use a profile made using i1Profiler or using the canned paper profile.
> However I see no difference (or can measure no difference using an i1Pro)
> using an Argyll-generated profile. This is affecting the soft-proofing,
> which (I presume) uses a round-trip as above.
>
> Robert
>
> -----Original Message-----
> From: argyllcms-bounce-***@public.gmane.org [mailto:
> argyllcms-bounce-***@public.gmane.org]
> On Behalf Of Graeme Gill
> Sent: 25 June 2014 07:37
> To: argyllcms-***@public.gmane.org
> Subject: [argyllcms] Re: Custom Illuminant
>
> robert-/***@public.gmane.org wrote:
>
> > I've checked various documents, including this one
> > http://www.computer-darkroom.com/softproof/softproof_1.htm and Photoshop
> > does simulate paper color with all the rendering intents, as I can see
> when
> > I do a soft-proof.
>
> Hi,
>
> Right, but is that a full simulation (i.e. representing the absolute paper
> white
> on the display), or a partial simulation (i.e. representing the paper white
> adapted to the display D65 white point ?).
>
> The document you refer to mentions "Relative Colorimetric", hinting
> at the latter. Photoshop having a "Simulate Paper Color" button
> doesn't help clarify what it's actually doing either.
>
> > I would really like to understand what Photoshop is doing. I have a
> contact
> > in Adobe who should be able to point me in the right direction. However
> > before doing that I would like to understand what is happening at the
> > profile level.
>
> > A print made from a profile that uses an sp file is identical to a print
> > made with a profile that does not use the sp file. So I assume that the
> > BtoA (PCS to Printer) is at D50 and is not affected by the custom
> > illuminant. Is that correct?
>
> No, that's not correct. Using a custom illuminant and/or observer changes
> the XYZ numbers and possibly the relationship between the XYZ numbers, but
> ICC color profiles are all normalized (i.e. chromatically transformed)
> to have the white point be exactly D50. So using any non-absolute
> colorimetric B2A will (superficially) seem much like the B2A from
> a default D50 illuminant and 1931 standard observer XYZ values.
> It's only when you examine the profiles in some more detail
> that you will see differences, and these depend on the spectral
> characteristics of the inks.
>
> > If the profile made with the sp file is used for soft-proofing, the paper
> > white is adjusted correctly (I've also tried different illuminants like
> A,
> > F5 etc, all appearing correct). So I assume that the AtoB (Printer to
> PCS)
> > does take into account the custom illuminant. Is that correct?
>
> No, see above. Both the A2B and B2A tables will be different if a different
> illuminant and/or observer are used. The B2A table is created by inverting
> the device characterization A2B table.
>
> > Does this apply to all the rendering intents, or only to Absolute
> > Colorimetric (as I think you said)?
>
> See above - all the tables will be affected, because they are all based
> on the same measurement values. The differences between default and custom
> illuminant and/or observer are likely to be larger and more obvious when
> comparing the absolute colorimetric intent though.
>
> > Is this (or whatever method you use) also applied to FWA compensation (if
> -i
> > and -f both specify the custom .sp file)?
>
> Yes. FWA compensation more accurately simulates the effect of U.V. in the
> illuminant on the FWA/OBE in the paper, so naturally this is affected by
> the spectrum (ie. the level of U.V.) in the custom illuminant.
>
> > I've read your documentation and purchased your paper on FWA
> compensation,
> > but I still can't make much sense of what's happening.
>
> To have a precise understanding means comprehending the basic color
> science,
> understanding what the profiling process and profiles are doing, and (the
> hard part), figuring out what the applications that use the profiles
> are actually doing. The latter is the hard part because typically the
> software vendors give you no clue, and hide behind inscrutable "user
> friendly"
> buttons such as "Simulate Paper Color". That's why often the process
> is one of comparing what software does with reference implementations such
> as the ArgyllCMS tools (cctiff, xicclu) or Lcms tools, where you can know
> exactly
> what's happening.
>
> Graeme Gill.
>
>
>
>
>

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> I'm confused about what happens if we do a round-trip conversion from, say
> ProPhoto to Destination and back to ProPhoto using a Perceptual intent
> (say).
>
> What I would expect would be:
> 1. ProPhoto->PCS: Relative (since the working space uses a
> matrix-based profile). Uses ProPhoto Profile.
> 2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
> 3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
> 4. PCS->ProPhoto: Relative. Uses ProPhoto profile.
>
> If that was the case then I would expect to see a change at 3, which I do if
> I use a profile made using i1Profiler or using the canned paper profile.
> However I see no difference (or can measure no difference using an i1Pro)
> using an Argyll-generated profile. This is affecting the soft-proofing,
> which (I presume) uses a round-trip as above.

Hi,
I don't understand why you would expect to see a change at step 3.
You would expect to notice something at step 2, because a print destination
typically has a smaller gamut than ProPhoto, but (at least for ArgyllCMS profiles)
a perceptual AtoB table is always the same as the colorimetric one - there is
no attempt to invert the perceptual BtoA, since this serves no purpose in
the context of how ArgyllCMS facilitates gamut mapping, and certainly
is not required of an ICCV2 profile.

ICCV4 profiles might be different, since they have the (optional) notion of
perceptual transform to/from a reference gamut, with all the limitations
that entails.

Graeme Gill.

[r***@public.gmane.org]

Hi Graeme,

I only expect things out of ignorance (or perhaps by observation, not by
understanding either the mechanisms involved or the color theory).

With a profile (either V2 or V4) from Canson, or one that I've made myself
with i1Profiler, there is a change from Destination to PCS which is in the
opposite direction to the PCS to Destination change. So I assume that with
these profiles both the BtoA and AtoB tables are Perceptual tables. In
Argyll it is a Relative table as you say, so there is no change.

Logically (to me at any rate) I would think that there should NOT be a
change in the AtoB direction (at least from a soft-proofing point of view),
so it would seem to me that Argyll is doing the right thing and X-Rite is
not.

I have read in various places comments like: "Because Perceptual squashes
and stretches in the BtoA direction (to get the source gamut to fit the
destination gamut), it can to some extent be reversed in the AtoB
direction". Misinformation?

Robert

-----Original Message-----
From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Graeme Gill
Sent: 03 July 2014 07:46
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Re: Custom Illuminant

robert-/***@public.gmane.org wrote:

> I'm confused about what happens if we do a round-trip conversion from, say
> ProPhoto to Destination and back to ProPhoto using a Perceptual intent
> (say).
>
> What I would expect would be:
> 1. ProPhoto->PCS: Relative (since the working space uses a
> matrix-based profile). Uses ProPhoto Profile.
> 2. PCS->Destination: Perceptual. Uses Destination profile BtoA.
> 3. Destination->PCS: Perceptual. Uses Destination profile AtoB.
> 4. PCS->ProPhoto: Relative. Uses ProPhoto profile.
>
> If that was the case then I would expect to see a change at 3, which I do
if
> I use a profile made using i1Profiler or using the canned paper profile.
> However I see no difference (or can measure no difference using an i1Pro)
> using an Argyll-generated profile. This is affecting the soft-proofing,
> which (I presume) uses a round-trip as above.

Hi,
I don't understand why you would expect to see a change at step 3.
You would expect to notice something at step 2, because a print destination
typically has a smaller gamut than ProPhoto, but (at least for ArgyllCMS
profiles)
a perceptual AtoB table is always the same as the colorimetric one - there
is
no attempt to invert the perceptual BtoA, since this serves no purpose in
the context of how ArgyllCMS facilitates gamut mapping, and certainly
is not required of an ICCV2 profile.

ICCV4 profiles might be different, since they have the (optional) notion of
perceptual transform to/from a reference gamut, with all the limitations
that entails.

Graeme Gill.

[Graeme Gill]

robert-/***@public.gmane.org wrote:

> Logically (to me at any rate) I would think that there should NOT be a
> change in the AtoB direction (at least from a soft-proofing point of view),
> so it would seem to me that Argyll is doing the right thing and X-Rite is
> not.

Hi,
it's not really right or wrong - the ICC profile format
allows for intent specific A2B tables, and the standardized V4 PRMG
proprietary V2 & V4 "intermediate gamut" approaches to gamut mapping
would make use of this. This approach has notable limitations, and I've
chose to make Argyll's gamut mapping more "pure". With Argyll's approach,
using intent specific A2B's doesn't make any sense.

> I have read in various places comments like: "Because Perceptual squashes
> and stretches in the BtoA direction (to get the source gamut to fit the
> destination gamut), it can to some extent be reversed in the AtoB
> direction". Misinformation?

True enough, but if the "squashing" is really "clipping", then you can't
un-clip, so there is no guarantee that such an A2B is the perfect inverse
of the corresponding B2A. One of the disadvantages of the intermediate
gamut approach is that it's likely to be less precise overall, because of
the double gamut mapping.

Graeme Gill.