Argyll for ICC profiling gives horrible results

[dje]

Certainly, Dave.

By "normal" TIFF", I mean a TIFF produced by means other than all the Argyll-related stuff in previous posts here i.e. no obfuscation by switches, color-spaces or color models. I point a camera at patch-card, take a shot -raw or JPEG- and convert it to TIFF with any convenient editor or viewer. The result includes all the camera settings and all the converter settings - good or bad for either. For this sub-discussion, I assume that the card is perfect and is under the correct lighting e.g. D50.

Next, I assume that somewhere in the journey from a particular color (I chose the yellow patch) to the TIFF value, something is wrong. For discussion, I chose the amount of wrongness in LAB Cartesian terms to be -20 (b* axis) and -8 (*a axis). That means that the profile must add 20 and 8 respectively to produce the correct LAB values of (in this case): 60+20 = 80 and -4 + 8 = 4. I assume a PCS of CIELAB

But at the stage that the tiff is produced, the camera profile has already been applied as part of the raw conversion process. It would have to be faulty to create a gross error in the patch color. You don't get a second go at it.

The crunch here is that I think the profile "gamut" is produced from the LUT or matrix values, the gamut being effectively derived from the difference between perfectly linear (1:1) LUTs or an identity matrix and the presumably-known input color space (?).

I believe that the camera profile gamut is the output of the LUT or Matrix for an input set of saturated RGB values.

With the correction being positive in each axis, the yellow correction will be further away from a*,b* = 0,0 and, had the target yellow been close to the boundary of the standard sRGB gamut, the profile target yellow correction could be shown in the profile "gamut" as outside of that boundary.

If the camera profile is faulty, then yes the yellow patch could end up outside the sRGB gamut boundary as this patch is close to the sRGB boundary.

That's the best I can offer I'm afraid, I'm not sure we are on the same wavelength (parden the pun) on this!

Dave

[xpatUSA]

But at the stage that the tiff is produced, the camera profile has already been applied as part of the raw conversion process....

I am not referring in any way to the in-camera transform(s) from camera "space" (raw) to output space (normally RGB).

Yes, we're on different wavelengths, and I'm unable to express my thoughts clearly enough, so I'll just butt out.

[TarekAH]

I'm still struggling with the concept of a profile having a gamut and what it should look like.

Could we discuss how a single patch would appear in a profile's 2D LAB gamut diagram?

Let's choose yellow under D50 lighting which for Xrite/Macbeth is a*b* = 4,80 (more or less).

Let's now say that a normal TIFF shot of the correct patch comes out wrong e.g. a*b* = -4,60 i.e. too green and not yellow enough.

Let's assume further that the PCS is L*a*b* -not that it should make a difference to the output (only to the input transform, obviously).

Where would that point (Xrite yellow) appear on a profile's 2D LAB gamut diagram and how is calculated?

Is it perchance simply the proper value adjusted by the Cartesian difference betwixt the two, namely a* gets 8 added and b* gets 20 added? In other words, yellow in the profile's gamut diagram would appear at a*b* = 12,100. In further words, a gamut point could easily end up outside the sRGB color space as probably did this yellow.

I, myself, am not really very familiar with the process of calculating/producing the gamut, especially in 3D.

Honestly, I didn't understand the numbers you are referring to here (a*b*=4.8 => x-rite yellow) whereas the fact says (x-rite yellow a*= 4.03, b*=79.81) this is one.

The second thing, I didn't get either why you are making the +8, +20 addition (correction?).


But anyway I guess this paper might be helpful to read, I've just skimmed through it and it seems to explain a bit the concept behind gamut calculation in 2D and 3D.

[TarekAH]

I would like just sum up this thread because it seems I (we) reached a dead-end kind of!

So basically, Argyll profiling procedure works just fine with the tiff image of x-rite Classic downloaded from the internet (Lindbloom). However, there seems to be a problem with profiling a Spyder ColorChecker, at least for me, as with the same exact parameters that yields a good gamut shape for x-rite Classic it does yield an ugly gamut shape for Spyder unless some other parameters are turned on during the raw conversion procedure (e.g. auto-brightening, WB, output color space...etc.) which breaks the concept behind working with RAW unprocessed image!

On the other hand, I had an acquisition with the same camera device for Rez ColorChecker and Argyll yields really nice gamut for it unlike Spyder.

Reference files of Spyder CC were checked and even replaced with real measured values of the same target with no avail, same problem persists.

THANK YOU ALL FOR COMMENTING AND HELPING, ANY FURTHER COMMENT IS, OF COURSE, ALWAYS APPRECIATED

[xpatUSA]

I, myself, am not really very familiar with the process of calculating/producing the gamut, especially in 3D.

I said "Could we discuss how a single patch would appear in a profile's 2D LAB gamut diagram?"

Honestly, I didn't understand the numbers you are referring to here (a*b*=4.8 => x-rite yellow) whereas the fact says (x-rite yellow a*= 4.03, b*=79.81) this is one.The second thing, I didn't get either why you are making the +8, +20 addition (correction?).

My mistake - the decimal point should have been a comma and I rounded a*= 4.03, b*=79.81 to a*= 4, b*=80 for the purposes of discussion.

But anyway I guess this paper might be helpful to read, I've just skimmed through it and it seems to explain a bit the concept behind gamut calculation in 2D and 3D.

Thank for the link. The paper describes another way to convert from RGB to L*a*b* and only mentions "profile" once in connection with the sRGB space. But there was an interesting table here:

https://www.hindawi.com/journals/tswj/2014/671964/tab1/

which shows us that the listed X-rite patches 13 to 18 are not sRGB primaries and secondaries. For example:

sRGB yellow is a*, b* = -18, 83

Xrite yellow is a*, b* = 4, 80 (rounded down)

Not saying that Xrite yellow is wrong ... -it is what it is.

Since the paper (or any other reference about CIELAB) provides transforms from RGB to L*a*b*, one could postulate both a correct target RGB color in the scene and an incorrectly converted RGB color in the TIFF. Transforming both colors to L*a*b* would allow the difference to be calculated easily and provide the requirement either in a matrix or LUTs within the target profile to make the correction, thereby rendering the correct color in the PCS. I've avoided mention of a specific color and actual numbers in this paragraph so as to establish a principle of how it works without obfuscation.

[TarekAH]

My mistake - the decimal point should have been a comma and I rounded a*= 4.03, b*=79.81 to a*= 4, b*=80 for the purposes of discussion.

Oh got it! I thought you meant both values a*b* to be 4.8 that is why I was really confused
yeah now it makes sense.

I said "Could we discuss how a single patch would appear in a profile's 2D LAB gamut diagram?"

I would be more than happy to discuss that, maybe we open a new thread for that as it sounds to be a different topic of the original one

[xpatUSA]

I would be more than happy to discuss [2D CIELAB profile gamut view], maybe we open a new thread for that as it sounds to be a different topic of the original one

Just now, I said:

"Since the paper (or any other reference about CIELAB) provides transforms from RGB to L*a*b*, one could postulate both a correct target RGB color in the scene and an incorrectly converted RGB color in the TIFF. Transforming both colors to L*a*b* would allow the difference to be calculated easily and provide the means to make the correction either in a matrix or LUTs within the target profile , thereby rendering the correct color in the PCS. I've avoided mention of a specific color and actual numbers in this paragraph so as to establish a principle of how it works without obfuscation."

So, the question becomes how to produce a matrix or set of LUTs that will transform (i.e. correct) wrongly captured colors in the TIFF into correct colors in the PCS. Sounds easy enough but probably not for this 80-yr old man ...

... for example, I'm not familiar with MATLAB:

http://robotics.stanford.edu/~ruzon/...re/rgblab.html

An RGB to CIELAB conversion routine.

[TarekAH]

Just now, I said:
So, the question becomes how to produce a matrix or set of LUTs that will transform (i.e. correct) wrongly captured colors in the TIFF into correct colors in the PCS. Sounds easy enough but probably not for this 80-yr old man ...

... for example, I'm not familiar with MATLAB:

http://robotics.stanford.edu/~ruzon/...re/rgblab.html

An RGB to CIELAB conversion routine.

I made this very quick sketch of the concept behind calculating the transformation matrix for correction.
Basically, you have the captured image (raw)

1-you start extracting rgb values from each patch (30 patches in this example) separately in small amount (i.e. averaging a small area, say 10x10 pixels)

2-then you arrange the acquired values in a matrix of certain polynomial degree (here in the example it's been chosen to be 2nd degree polynomial which yields of 9 elements + 1's = 10 elements in total)

3- you arrange the end-result that you wish to have (the ground-truth values) in a similar manner (30x3; #patches x channels)

4- you solve algebraically to find out the (correction) matrix that if it got multiplied by the raw values gives the ground-truth...Tadaa, you got it!

[xpatUSA]

Thanks, Tarek.

Looks right to this old man (-I had to look up "polynomial").

Similar in action to my raw-only Sigma camera where the raw values are R-ish, G-ish, B-ish (Foveon sensor, not RGGB).

Sigma's Photo Pro converter processing: a raw-to-XYZ 3x3 matrix, followed by a WB correction 3x3 Matrix, then the standard XYZ to RGB transform for the selected color space ...