RSS/Atom feed Twitter
Site is read-only, email is disabled

Softproof rendering intent

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 7 messages available
Toggle history

Please log in to manage your subscriptions.

Softproof rendering intent Yoshinori Yamakawa 31 Dec 17:42
  Softproof rendering intent Sven Neumann 02 Jan 13:38
20070102232509.f9237c96.yam... 07 Oct 20:24
  Softproof rendering intent Sven Neumann 02 Jan 17:44
   Softproof rendering intent Alastair M. Robinson 02 Jan 20:24
    Softproof rendering intent Sven Neumann 02 Jan 20:47
   Softproof rendering intent Yoshinori Yamakawa 02 Jan 20:35
Yoshinori Yamakawa
2006-12-31 17:42:53 UTC (almost 18 years ago)

Softproof rendering intent

I think that the explanation of "Softproof rendering intent" in the Color Management preferences is different from actual behavior of the Color Management display filter.

As shown in the description of the tool-tips, it seems to be processed as follows:

[Source]->(ProofIntent)->[Print]->(DisplayIntent)->[Monitor]

However, it is actually processed as follows:

[Source]->(DisplayIntent)->[Print]->(ProofIntent)->[Monitor]

I propose exchanging the 398th line for the 397th line of "cdisplay_lcms.c", or correcting description of the tool-tips.

Sven Neumann
2007-01-02 13:38:09 UTC (almost 18 years ago)

Softproof rendering intent

Hi,

On Sun, 2006-12-31 at 08:42 -0800, Yoshinori Yamakawa wrote:

[Source]->(ProofIntent)->[Print]->(DisplayIntent)->[Monitor]

However, it is actually processed as follows:

[Source]->(DisplayIntent)->[Print]->(ProofIntent)->[Monitor]

I propose exchanging the 398th line for the 397th line of "cdisplay_lcms.c", or correcting description of the tool-tips.

Are you sure? According to the lcms header file, the sixth parameter is "Intent" and the seventh is "ProofingIntent". The current code uses these parameters as such. Why do you think it should be changed?

Sven

Sven Neumann
2007-01-02 17:44:56 UTC (almost 18 years ago)

Softproof rendering intent

Hi,

On Tue, 2007-01-02 at 23:25 +0900, Yoshinori Yamakawa wrote:

It is being written certainly in "lcms.h" like that.

However, please pay attention to the definition of "cmsCreateTransform" function written in "cmsxform.c".

{
return cmsCreateProofingTransform(Input, InputFormat, Output, OutputFormat, NULL, Intent, INTENT_ABSOLUTE_COLORIMETRIC, dwFlags); }

Please think about why the value of "ProofingIntent" is "INTENT_ABSOLUTE_COLORIMETRIC".

Well, I don't know why. All I can do is look at the header file and documentation of littleCMS. What you are saying looks like there is a bug in lcms. Either the code or the header file is wrong. Or we are simply misinterpreting things. Perhaps it would be a good thing to bring this up on the lcms mailing-list. If you do that, please add me to the Cc.

Sven

Alastair M. Robinson
2007-01-02 20:24:26 UTC (almost 18 years ago)

Softproof rendering intent

Hi,

Sven Neumann wrote:

Please think about why the value of "ProofingIntent" is "INTENT_ABSOLUTE_COLORIMETRIC".

The Problem is that ProofingIntent is an ambiguous term. Does it mean "The intent whose effect we wish to simulate on screen", or "The intent used when mapping from printer to screen"?

Assuming the intention within GIMP is to map as follows: RGB -> (Softproof intent) -> Printer -> (Display intent) -> Monitor then GIMP does indeed currently have these reversed.

This can be proved by setting both RGB and Monitor profiles to sRGB, and the Print Simulation profile to USWebCoatedSWOP (or any other D50 output profile).

Since the printer profile's whitepoint is 5000K and the Monitor's whitepoint is 6500K, then changing the Display rendering intent to "Absolute Colorimetric" should produce a yellow cast, matching screen white with the yellower paper white.

In fact, what currently happens is that a blue cast is added. Setting the Softproof intent to Absolute Colorimetric instead, causes a yellow cast, but should cause a blue one. Thus, these two parameters are currently reversed.

All the best, --
Alastair M. Robinson

Yoshinori Yamakawa
2007-01-02 20:35:04 UTC (almost 18 years ago)

Softproof rendering intent

On Tue, 02 Jan 2007 17:44:56 +0100 Sven Neumann wrote:

Well, I don't know why. All I can do is look at the header file and documentation of littleCMS. What you are saying looks like there is a bug in lcms. Either the code or the header file is wrong. Or we are simply misinterpreting things. Perhaps it would be a good thing to bring this up on the lcms mailing-list. If you do that, please add me to the Cc.

Sven

I think that there is a difference of recognition to "ProofingIntent" in between us and them.

In "LCMSAPI.TXT", they are describing in the explanation of "cmsCreateProofingTransform" function as follows:

ProofingIntent: Is the intent for translating emulated colors. Default is INTENT_ABSOLUTE_COLORIMETRIC.

I guess that four words "into Output color space" are missing.

# I forgot to explain the following in the last message. # They are the one having described it based on an actual function definition.
#
# [Input]->(Intent)->[PCS]->(Intent*1)->[Proofing]-> # ->(Rel. colorimetric)->[PCS]->(ProofingIntent)->[Output] #
# *1 If Intent is Absolute colorimetric, it is replaced with Relative colorimetric.
#
# In the above chart, if ProofingProfile is NULL, the chart is changed as follows:
#
# [Input]->(Intent)->[PCS]->(Intent)->[Output]

Sven Neumann
2007-01-02 20:47:01 UTC (almost 18 years ago)

Softproof rendering intent

Hi,

On Tue, 2007-01-02 at 19:24 +0000, Alastair M. Robinson wrote:

The Problem is that ProofingIntent is an ambiguous term. Does it mean "The intent whose effect we wish to simulate on screen", or "The intent used when mapping from printer to screen"?

Assuming the intention within GIMP is to map as follows: RGB -> (Softproof intent) -> Printer -> (Display intent) -> Monitor then GIMP does indeed currently have these reversed.

OK. I will reverse it then. I wonder what should be used in cdisplay_proof.c though. That code probably also needs some review.

Sven