tifficc: relative intents disregarded in soft-proof mode

[albfe]

Lately I have been experiencing some problems with tifficc: in softproof mode, it looks like changing the intent by using relative intents always produce the same output (i.e., there is no difference in output among relative colorimetric, perceptual, an saturation), not only visually, files are the same byte by byte; visible changes are there when the absolute colorimetric intent is selected. I have tried different images that are out of gamut w.r.t. the target profile. I may add that, instead, applying the actual transformation correctly produces a different results.

For your reference, I use the following commands for soft proofing: tifficc -i sRGB.icc -p paperprofile.icc -c2 -m0 -b infile.tif perc.tif tifficc -i sRGB.icc -p paperprofile.icc -c2 -m1 -b infile.tif rel.tif

In the past, I could see visible differences among the different intents when using the soft proofing mode, but I am unable to tell when this stopped, as I am not using tifficc often for this purpose.

[mm2]

I have checked tifficc by using the ICC probe profile and found it works ok.

But in the way you are using command line options,, for sure it will give same result. -m intent is the proofing intent That is the intent used to translate the simulation to the output device, the screen probably. It is not the intent to simulate. Since you have not specified output profile with -o, it reverts to built-in sRGB which only have relative colorimetric, so -m0 and -m1 (also -m2) does exactly the same, instructs to translate the simulation to relative colorimetric sRGB)

Probably what you want is (this is with the probe profile)

tifficc -t0 -p Probev1_ICCv4.icc -c2 -m1 -b  infile.tif perc.tif
tifficc -t1 -p Probev1_ICCv4.icc -c2 -m1 -b  infile.tif rel.tif

Note that the simulated intent is set by using -t. not by -m

[albfe]

Thanks a lot Marti for spotting my mistake. I tried to use -t as you suggested and I confirm that everything works as expected.

[albfe]

Just a quick suggestion: maybe it would help to update the manpage of tifficc. For example, for -m it reads -m <0,1,2,3> SoftProof intent. Adding an example on softproofing would also be helpful.

[mm2]

Done as suggested. I'm closing the issue now.

[Jehan]

@mm2 May I ask some question about semantic? So "soft-proof intent" for you is the intent made to replace the normally used display rendering intent (which would then be discarded).

So first: is this wording from Little-CMS only or is it a widely recognized name that when we say "soft-proof intent", we actually mean the intent for the transform from simulated space (e.g. some CMYK space for printing) to output space (e.g. a screen) transform?

In this case, we can consider there are 3 intent concepts, not 2. You simply use your -t intent for 2 of these concepts (depending or not we are in soft-proofing mode). How would you name these differently? A display rendering intent (last transform) and a re-purposing rendering intent (first transform) maybe? (I saw the wording "re-purposing" and "re-targeting" to name the 2 steps in some ICC white paper)

Finally I have a last question about lcms soft-proofing code:

    hArray[0]  = InputProfile; hArray[1] = ProofingProfile; hArray[2]  = ProofingProfile;               hArray[3] = OutputProfile;
    Intents[0] = nIntent;      Intents[1] = nIntent;        Intents[2] = INTENT_RELATIVE_COLORIMETRIC;  Intents[3] = ProofingIntent;

So for soft-proofing, you do 3 transforms: from image space (e.g. a RGB image) to simulated space (e.g. CMYK printing profile) using the rendering intent (-t), then from the simulated space to itself in relative colorimetric, and finally from the simulated space to output space (e.g. the profile of a calibrated screen).

What I don't understand is this intermediary transform. Why transforming from simulated space to itself in relative colorimetric? Won't it be a no-op anyway?

[mm2]

I heard the term "soft proofing intent" in ICC meetings and probably is jargon. It means to me the way you translate colors from the simulation to the device that is used as proofer. Usually the display, but may be a printer. Epson Canon and HP have such printers. I worked in making one when I was at HP. So if you emulate, for example, how an AppleRGB image would show on AdobeRGB, and your display is sRGB only, then you cannot see all the emulated colors so some gamut mapping should be done. For proofer devices the bigger the gamut the better but sometimes it is not feasible at all.

The process is, you convert from the source color space to the simulated color space, in our example from AppleRGB to AdobeRGB. Then you have the device values of colors in the simulated space, RGB in this case, so you need to measure to Lab to get colorimetric information. To do so you perform a relative colorimetric measurement device->Lab. This Lab have to be converted to proofer by means of output profile and proofing intent. You probably want relative colorimetric or absolute colorimetric here, but in the case you are using a printer proofer the device gamut is small and if you only want to capture the overall appearance, to spot artifacts for example, in this case perceptual would be useful.

[Jehan]

I heard the term "soft proofing intent" in ICC meetings

OK. For sure, you have more experience than I in the ICC/color industry field, so I'll take this jargon then. We'll name the first intent (from image space to simulated space) differently.

Then you have the device values of colors in the simulated space, RGB in this case, so you need to measure to Lab to get colorimetric information. To do so you perform a relative colorimetric measurement device->Lab.

It looks to me you are answering about the intermediary proofingProfile to proofingProfile transform in relative colorimetric, but I don't get it. Sure you'll convert to Lab but that would be done internally anyway. How is doing an intermediate transform (from a profile to itself!) in-between the 2 expected transforms (so 3 transforms happening in the end) helping here?

Basically what I'm asking is why your code (instead of being what I wrote above) is not just:

    hArray[0]  = InputProfile; hArray[1] = ProofingProfile; hArray[2]  = OutputProfile;
    Intents[0] = nIntent;      Intents[1] = nIntent;        Intents[2] = ProofingIntent;

[mm2]

t looks to me you are answering about the intermediary proofingProfile to proofingProfile transform in relative colorimetric, but I don't get it. Sure you'll convert to Lab but that would be done internally anyway. Well, to convert from device to Lab you need a profile. Please note that profiles can go Lab->Device but also Device ->Lab, this is mostly intended to measure values OR do proofing.

The transform goes Image -> Lab -> Device to simulate -> Lab -> Render to proofer

The Image->Lab->Device to simulate is a normal transform to the profile being simulated. The used intent may move colors The Device to simulate -> Lab measures colors from the device to simulate to Lab. It needs the profile and relative colorimetric because relative colorimetric does not move in gamut colors. Since the direction is device->Lab all colors are in-gamut Finally you need to represent those Lab values so that's Lab ->Render to proofer.

In total 3 transforms and 2 profiles 1) The normal transform that you would do to the simulated device 2) a measurement transform from simulated device to Lab 3) a conversion from measured lab to output proofer device

This is a multiprofile transform using the simulated profile twice, but with different intents.

Basically what I'm asking is why your code (instead of being what I wrote above) is not just:

Because output from proofing profile are device values, and you need Lab. You have to measure those values to get Lab, the color engine knows nothing on how to do this conversion. Is up to the profile.

[Jehan]

The Image->Lab->Device to simulate is a normal transform to the profile being simulated. The used intent may move colors The Device to simulate -> Lab measures colors from the device to simulate to Lab. It needs the profile and relative colorimetric because relative colorimetric does not move in gamut colors. Since the direction is device->Lab all colors are in-gamut Finally you need to represent those Lab values so that's Lab ->Render to proofer.

Sure. That's all clear and understandable.

OK. I see. So I guess that I was confused by this part:

hArray[1] = ProofingProfile; hArray[2] = ProofingProfile;

Considering what you say, what it does is rather something like:

hArray[1] = ProofingProfile; hArray[2] = WhateverRepresentLabSpace;

Your code must surely handle this properly down the way (ignoring that it was ProofingProfile repeated twice) if I were to follow it.

You have to measure those values to get Lab, the color engine knows nothing on how to do this conversion. Is up to the profile.

Sure. But I was assuming that your engine would do this intermediate Lab conversion (using the profile indeed!) automatically. As an implied intermediate transform between 2 profiles/different spaces. Same as when you said the first transform is Image->Lab->Device to simulate. Here you count it as a single transform, yet also write it with 2 arrows, implying an additional/intermediate passage through Lab. So in this sense, it would be even 4 transforms in total.

After all, what is the difference between a transform from Image to Device to simulate, and another from Device to simulate to Render to proofer? In the end, it's just transforms between 2 ICC profile spaces (or I'm missing something).

Anyway I think I got it. I was just confused by how it was written in your code, but that's probably just internal logic. The logic you explain here makes sense and it's what I would expect indeed.

[mm2]

You almost got it.

Ok, so let's say there are two transforms. One that is the transform that we want to simulate, goes image -> Lab->Device to simulate. It internally uses Lab, but as you will see this lab is not the same as measured lab. Let's take as example AppleRGB, SWOP CMYK and sRGB

I have a value of RGB=(120, 20, 130) in apple rgb.

transicc.exe -t0 -i AppleRGB.icc -o *Lab

This is Lab (L=36.7445 a=53.0873 b*=-36.2030)

Now I want to simulate a SWOP press. Let's see which CMYK I get on perceptual

transicc.exe -t0 -i AppleRGB.icc -o USWebCoatedSWOP.icc

I convert this to SWOP in perceptual intent, gives me (C=56.0555 M=99.8657 Y=5.6336 K=0.1892)

Ok, now I want to know the Lab of this CMYK. Note that is not the original Lab of (36, 53, -36) which cannot be rendered on a SWOP printer, let's see what has done the SWOP profile. Using SWOP in the reverse direction and with relative intent I measure the color. It is important to use relative colorimetric otherwise it will "undo" the perceptual and this is not what we want.

transicc.exe -t1 -i USWebCoatedSWOP.icc -o*Lab

L=(38.8067 a=43.6602 b*=-29.5742)

Which is a quite different Lab value. This is the measured color we get at the simulation. So now lets represent it in sRGB

transicc.exe -t1 -i*Lab -o*sRGB

R=(140.1642 G=58.5783 B=140.6331)

As you can see a quite different color form original one.

[Jehan]

Yes. It's all quite clear. But I mostly wondered (and still do) why you needed to explicit this CMYK -> Lab transform, and why you say:

It internally uses Lab, but as you will see this lab is not the same as measured lab.

Here is the computation from CMYK to sRGB:

$ transicc -t1 -i USWebCoatedSWOP.icc' -o*sRGB
LittleCMS ColorSpace conversion calculator - 5.0 [LittleCMS 2.12]
Copyright (c) 1998-2020 Marti Maria Saguer. See COPYING file for details.

Enter values, 'q' to quit
C? 56.0555
M? 99.8657
Y? 5.6336
K? 0.1892

R=140.1641 G=58.5783 B=140.6331 

I got exactly the same value, and I didn't need to do the Lab transform explicitly. For sure, it's without a doubt still implicitly done as an intermediary step by LittleCMS. Just like it's also done in the first AppleRGB→SWOP-CMYK step too. But why do you make a difference here between the first (AppleRGB→CMYK) and last (CMYK→sRGB) transforms by breaking up the second into 2 explicit transforms with Lab in the middle? This is what I don't understand.

I perfectly understand (I think but it's complicated, so who knows! 🥲) all your explanation and I completely agree. I just don't understand why you single out this CMYK→Lab transform by making it explicit (as if it were different from the RGB→Lab transform which is still done, but implicitly). The numbers with your own example seem to show that it would not make a difference to leave this transform implicit (as I get the same numbers as you).

[Jehan]

P.S.: by the way, thanks a lot for all the patient explaining!

[mm2]

There is no such thing as implicit lab. When you create a transform you chain two profiles so you use first one from device to lab and the second from lab to device. In normal transforms both profiles are using same intent

What makes this second proofing transform special is that the intent is not same on both profiles. First profile uses relative colorimetric and second one uses what you give with -m

You could think in just one multiprofile transform going device-lab-device-lab-device, which is how it is implemented.

BTW, yes you need not to go to lab in the example. I used it to demonstrate color is different.

[Jehan]

BTW, yes you need not to go to lab in the example. I used it to demonstrate color is different.

Ok so I think I got it. In this example, you didn't need to go to Lab because you were doing a relative colorimetric USWebCoatedSWOP→sRGB. But say we wanted to do it in perceptual (soft-proof intent), then the values are different:

$ transicc -t0 -i 'USWebCoatedSWOP.icc' -o*sRGB
C? 56.0555
M? 99.8657
Y? 5.6336
K? 0.1892

R=136.0316 G=40.4584 B=136.5237 

This does correspond to doing a perceptual 'USWebCoatedSWOP.icc' to Lab (L=35.0781 a=49.5000 b=-32.9570) followed by a perceptual Lab to sRGB (R=136.0316 G=40.4583 B=136.5236).

On the other hand, if I force a relative colorimetric 'USWebCoatedSWOP.icc' to Lab, I get: L=38.8067 a=43.6602 b=-29.5742

Then I run a perceptual Lab to sRGB: R=140.1642 G=58.5783 B=140.6331

Final result is indeed different. I guess that's what this was about. We want the soft-proof intent to only be used from Lab to display/output color space. But we absolutely want to use relative colorimetric conversion from the simulated space to Lab, which was why we could not let implicit Lab conversion happen. That's it, right?

Sorry for having been so slow!