Argyll for ICC profiling gives horrible results

[TarekAH]

Hi Ted and Tarek

I came across this article by Norman Koren of Imatest ...

Dave

thanks Dave I will have a look on it.

I wanted to mention regarding your last comment on the DeltaE....for a matter of fact actually the deltaE for those profiles no matter of their weird gamuts' shape is really low < 1.5 and I have no peculiarities in color rendition, it is only in the gamut shape (of course with some effect of washed-out/low contrast presents in the image)

[xpatUSA]

thanks Dave I will have a look on it.

I wanted to mention regarding your last comment on the DeltaE....for a matter of fact actually the deltaE for those profiles no matter of their weird gamuts' shape is really low < 1.5 and I have no peculiarities in color rendition, it is only in the gamut shape (of course with some effect of washed-out/low contrast presents in the image)

Tarek and Dave,

I don't how that delta-E was measured although I do know what delta-E means, but I had the following thought:

If the conversion to TIFF somehow made a color wrong for a patch, the profiler would do it's best to make it right. Then perhaps a Lab gamut view of the profile would put the patch in the right place. I'm not too sure about this because I don't know how a gamut viewer works for ICC profiles.

[dje]

Tarek and Dave,

If the conversion to TIFF somehow made a color wrong for a patch, the profiler would do it's best to make it right. Then perhaps a Lab gamut view of the profile would put the patch in the right place. I'm not too sure about this because I don't know how a gamut viewer works for ICC profiles.

Yes Ted I think it is important that the camera RGB "color" (ie the relativity between R,G and B) is not changed during creation of the tiff. I don't know exactly how gamut viewers work with icc profiles but I assume that the profile output is calculated from a range of input RGB values, mainly around the saturated colors at the extremeties of the gamut.

Dave

[xpatUSA]

Yes Ted I think it is important that the camera RGB "color" (ie the relativity between R,G and B) is not changed during creation of the tiff. I don't know exactly how gamut viewers work with icc profiles but I assume that the profile output is calculated from a range of input RGB values, mainly around the saturated colors at the extremeties of the gamut.

Dave

While trawling the web for 'gamut' with respect to ICC profiles, I found this jewel from a printing Company:

The gamut or 'accessible colorimetric space' corresponds to the 2D or 3D plot of an ICC profile. Specific softwares make it possible to compare all the profiles of the peripheral along a graphic chain, in order to spot colors or shades which cannot be reproduced on the outlet profile - eg the paper profile.

In this case, an impossible shade to print will be described as 'out of gamut'. The broader the gamut of an ICC profile, the broader the spectrum of the accessible shades which can be reproduced by the peripheral.

About as clear as Aussie red dirt!

Not offered for your education, Dave ...

These might be useful to us, after a couple of reads:

https://www.argyllcms.com/doc/iccgamut.html - you may have already seen it.

This abounds with funny-looking 2D gamuts but might help us a tad ...

https://chromachecker.com/info/en/pa...profile_manual

I wonder what the gamut of a "neutral" ICC profile looks like? Meaning a profile with either linear LUTs or an identity matrix, in other words, what goes in comes out ...

[TarekAH]

Hi again,
sorry I got busy doing something else these couple of days now and couldn't update much on the subject but I will be on it again soon.

Worth mentioning actually is that I've profiled another Color Checker meanwhile, namely Rez Checker, and the conversion and a profile creation are following the same steps as before, but now I am getting really really good gamut!
Which makes me wonder more, what is going wrong with the Spyder Checker (acquisition, conversion, some of the files corrupted, Argyll misreading something...etc.)?

[Manfred M]

I've been quietly following this thread. I'm not quite into the nitty-gritty tech issues as others here, but the answer seems to be that the colour swatches that Datacolor uses in the Spyder swatches are not the same as the Munsell colours that both x-Rite and ISA (Rez) use. If you check the Image Science Associates (ISA) website, the specifically mention that they buy their colour swatches from Munsell (which are owned by x-Rite, just like Gretag-MacBeth).

Feed the software data that is different than what it is programmed for and you will get output that does not make sense.

[dje]

Tarek one thing I have found with your colprof code is that you are using the option -ax which creates an LUT using XYZ data. I'd suggest you try the option -a1 which will give you a Lab LUT which seems to be what is used by Capture One. Also I'm still looking into whether the Datacolor reference data is D65 or D50. I also think there might be a white balance problem with your tiff but I also need to look at that further.

Dave

[TarekAH]

Tarek one thing I have found with your colprof code is that you are using the option -ax which creates an LUT using XYZ data. I'd suggest you try the option -a1 which will give you a Lab LUT which seems to be what is used by Capture One. Also I'm still looking into whether the Datacolor reference data is D65 or D50. I also think there might be a white balance problem with your tiff but I also need to look at that further.

Dave

For the data that comes with Argyll for Spyder it is mentioned in the file that it is D65. On the other hand I have my own measurements under D50 and I can provide them if necessary although not really a major difference I have noticed by applying either as long as the files are in accordance with each others.

For the gamut's shape yeah you are right I am using mostly "-ax" option, I have tried just right now the different other options and yeah you get different calculations apparently hence different gamuts by each option (picture below)

I have tried one other thing, that to provide instead of XYZ values in the .cie reference file Lab values just like how it is by default in ColorChecker.cie (for x-rite Classic) but unfortunately I got very erroneous output not sure why! (something is hard-coded in Argyll that expects only XYZ input?)

[TarekAH]

I've been quietly following this thread. I'm not quite into the nitty-gritty tech issues as others here, but the answer seems to be that the colour swatches that Datacolor uses in the Spyder swatches are not the same as the Munsell colours that both x-Rite and ISA (Rez) use. If you check the Image Science Associates (ISA) website, the specifically mention that they buy their colour swatches from Munsell (which are owned by x-Rite, just like Gretag-MacBeth).

Feed the software data that is different than what it is programmed for and you will get output that does not make sense.

Thanks Manfred for your comment.

I am sure though that Argyll software doesn't expects/isn't programmed only to expect Munsell's type of color measurements as they provide themselves various other color checkers measurement inside their "ref" folder including the Spyder one...which indicates, I assume, that their software should handle just as well any input color checker as long as the structure of the input/reference files is the same as what they expect it to be.

PS: I am not an expert either in Argyll, just quite new to using/trying it and that is why I am trying to understand what is going on (under the hood?)

[xpatUSA]

For the data that comes with Argyll for Spyder it is mentioned in the file that it is D65.

FYI, the L*a*b* values provided with the X-Rite/Macbeth 24-patch card are for D50 lighting and D65 for the sRGB values.

However, I measure color accuracy under different lighting **, because I do not own a true D50 light source. After conversion from raw to RGB, I balance the WB on the mid-gray patch #22 and then adjust the image brightness to make the mid-gray patch 120/255 which is close enough to L* = 51 for my purposes.

** warm LED's, camera set to Incandescent. Yes, I am aware of LED emission spectra.

On the other hand I have my own measurements under D50 and I can provide them if necessary although not really a major difference I have noticed by applying either - as long as the files are in accordance with each others.

Tarek, may I ask how you obtained the Spyder values for D50?

[TarekAH]

Tarek, may I ask how you obtained the Spyder values for D50?

I have access to a spectral measurement device such as this one https://www.barbierielectronic.com/e...qb/91-869.html

[TarekAH]

I got actually some interesting results by playing a bit with different parameters...I will try to post the findings soon

[xpatUSA]

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.

[dje]

Ted as I see it, the gamut of an input icc profile is simply the range of output values (in profile connection space) corresponding to a set of input RGB triplets covering a range of saturated colors (ie where at least one of the values of R G or B is zero). Norman Koren talks about this in a reference I posted earlier.

For standard color spaces such as sRGB Adobe RGB etc, you would be aware that these color spaces are defined by three primaries, an illuminant white point and a tone curve. The three primaries in XYZ space define the gamut triangle. The icc profile to convert one of these color spaces to PCS contains a matrix which uses the primaries as columns. So the gamut can be calculated using this matrix. The same applies for a matrix based camera profile. For an LUT based camera profile, the gamut can be calculated by evaluating the LUT response to various saturated RGB inputs. It is not triangular like the matrix version.

For a decent camera profile, the standard patch colors should all fall within the gamut boundary.

As Koren points out in his article, we need to realise that the gamut for a camera profile defined by the above process does not include the effect of the sensor color channel spectral responses which will prevent certain R G B combinations being produced.

Dave

[TarekAH]

I will try to summarize what I came across last week.

First of all, it turned out that mapping for XYZ or Lab color space during the process of creating an ICC profile (cLUT) changes the output dramatically (I am still confused why should that happen in the first place?)
[according to the documentation XYZ cLUT supposedly must be better for additive devices including Cameras, Displays and such which is clearly is our aim, However, it results in really ugly gamut/Tone Curve shapes unlike the Lab cLUT]
Check #48


Secondly and the more important point is, the resultant color space during the conversion from Raw format into .tiff format (Libraw) plays a major role in the later step of creating an ICC profile and its gamut's shape. Below you may check couple of examples how much impact one chosen color space has compared to others.
[which imposes the question, what color space is the more correct to choose during the raw conversion?]

[dje]

Tarek I think that you should be using the RAW "color space" for the tiff, ie no color corrections. Bear in mind that when the profile is actually used, it will be applied to the RAW camera data. If your profile has been made using measurements of something other than RAW, the color corrections it makes on the RAW data will not be accurate. That applies to the Delta E report for the profile too. It is simply and indication of how well the measured patch data is made to match the reference values. If the measured data is something other than RAW, the Delta E report will be misleading.

Dave

[TarekAH]

Tarek I think that you should be using the RAW "color space" for the tiff, ie no color corrections. Bear in mind that when the profile is actually used, it will be applied to the RAW camera data. If your profile has been made using measurements of something other than RAW, the color corrections it makes on the RAW data will not be accurate. That applies to the Delta E report for the profile too. It is simply and indication of how well the measured patch data is made to match the reference values. If the measured data is something other than RAW, the Delta E report will be misleading.

Dave

totally agree!
I am confounded only because the "raw" gives such unreasonable gamut output (is it not? should it after all?)

[xpatUSA]

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. <etc. etc.>

If we're not going to discuss the above, I am slowly forming an opinion that the "gamut" of a profile represents what would come out if the input is perfect, whether by LUTs or a Matrix. If so, a particular output could easily exceed the standard gamut boundary or could equally be inside the said boundary. It could even be that a particular output could be outside the CIE visual gamut but still be OK if presented with the particular input that it is intended to correct!

[dje]

Sorry Ted but I don't understand what you mean when you say "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." Could you elaborate a little please? Are you referring to a tiff produced using a bad profile for example?

Dave

[xpatUSA]

Sorry Ted but I don't understand what you mean when you say "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." Could you elaborate a little please?

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 PCS LAB values of (in this case): 60+20 = 80 and -4 + 8 = 4.

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 correction amounts.

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.

Are you referring to a tiff produced using a bad profile for example?

No. The TIFF does not necessarily need an embedded profile for input to an ICC creator, as far as I know.

HTH.