Color calibration for dummies (without the maths)

[agriggio (Alberto)]

Hi,

@anon41087856

Matrices multiplications are not associative, so the order of application matters.

You mean in floating-point, right? And if so, how do you take this into account exactly? I’m not sure I understand what you mean…

[anon41087856]

@agriggio

You mean in floating-point, right? And if so, how do you take this into account exactly? I’m not sure I understand what you mean…

Floating point or else. We take that into account by ensuring the right operation happens at the right place in the pipe. Which means that, if you least-square-fit a matrix at some point in the pipeline, it needs to be always applied at the same point in the pipe, or the coeffs in said matrix become wrong.

[agriggio (Alberto)]

@anon41087856

Floating point or else.

Matrix multiplication is associative over e.g. the reals, that’s why I found your statement confusing…

[agriggio (Alberto)]

Hi again,

@anon41087856

Then, ICC can be LUT too, but LUT are a double-edged sword (theoritically more accurate than matrices, but also less forgiving to any user mistake during calibration and not exposure-invariant –

FWIW, LUT profiles generated by dcamprof (at least by default) are supposed to be exposure invariant. I never really checked though to be honest

[anon41087856]

With A and B, 2 matrices, and * the matrix product, A * B ≠ B * A is what I meant. Double-checking it on wikipedia, this is not associativity, seems like permutability ? Anyway, words lie, trust equations.

@agriggio

FWIW, LUT profiles generated by dcamprof (at least by default) are supposed to be exposure invariant. I never really checked though to be honest

How ? If the LUT is ever so-slightly non-linear, you lose exposure-invariance by definition. But if your LUT is linear, just use a matrix…

[ariznaf (Fernando)]

My algebra is a bit forgotten but that is commutative property, isn’t it?
As long as I can remember, matrix multiplication is not conmutative but it is associative, meaning (AB)C= A(BC)…

I thought ICC profiles using LUTS and applied at the input profile stage were the mos accurate way to reproduce colors, as long as it can approximate better the non linear behaviour of the sensor color pigments.

Cameras use linear matrices to make the color transformation themselves when generating jpegs, anyway.

But some people uses detailed profiling under controlled light (in studio) to get the most accurate colors and an ICC profile and use programs like capture one that can work in the camera space (after applying that icc profile) to get the most of their camera color reproduction and the most acurate color results.
At least that is what some experts working with product photography recommend.

Any way I don’t mind perfect color reproduction, I just need good natural colors.

I will use CAT16 then (but no color checker to calibrate colors).

Thank you for the clarifications.

[agriggio (Alberto)]

Alright, that’s commutativity. Mystery solved

Regarding luts, better to point at the docs:

http://rawtherapee.com/mirror/dcamprof/dcamprof.html#camera_model

[JackH]

@anon41087856

@JackH

When dealing with linear operators such as ‘white balance’ or ‘color’ matrices there are no more or less fancy spaces mathematically. Just like 3x4x5 is equal to 3x5x4 one can choose to apply the operators in any sequence, or collapse them all into one (3x20) - though perhaps one way is more convenient or intuitively explained than the other.

Yes and no, what you say is too broad.

Hi Aurelien, that’s because I am a broad guy, one has to read between the lines otherwise it’s too easy

@anon41087856

Matrices multiplications are not associative, so the order of application matters.

Pardon? They are linear matrices, one can combine them unless one introduces non-linear changes in between. But I explicitly was not referring to that case.

@anon41087856

Also, if you perform a least-squares fitting, you will get a better or worse fit depending on how your values are normalized and how your matrix is conditioned, so doing WB before matrix fitting or matrix fitting before WB does not produce the same fitting quality.

I happen to have done this and in fact one gets exactly the same final result whether (1) WB is applied to the data before running the optimization routine or whether (2) the optimization routine is run on the unbalanced raw data from the capture as-is. In the end for all intents and purposes CCM(2) = CCM(1)*diag(WB).

@anon41087856

Plus we are dealing with numeric computations, so rounding errors are to be taken into account, and make things slightly less nice than linear algebra theory.

If you use floating point, as I assume you are, rounding errors are immaterial in this case.

Keep up the good work!
Jack

[heckflosse (Ingo Weyrich)]

@JackH

order does not matter

In floating point calculations it’s not guaranteed that:

1. (a + b) + c = a + (b + c)
2. (a * b) * c = a * (b * c)

[agriggio (Alberto)]

On the other hand tough, if the numbers are of the same magnitude (e.g. normalised to [0,1]), the error is not significant, especially in this context (i.e. It’s not something that you can perceive)

[heckflosse (Ingo Weyrich)]

@agriggio Isn’t the normalization irrelevant in this case? The relative error should be the same…

[JackH]

@heckflosse

In floating point calculations it’s not guaranteed that:

1. (a + b) + c = a + (b + c)

Well, I guess it depends what one means for guaranteed (eps = ?). But wouldn’t they effectively be the same in practice?

@heckflosse

2. (a * b) * c = a * (b * c)

I believe those are effectively equal if ‘a’ were the whiteBalancedData->XYZ CCM, ‘b’ were diag(WB_mult) and ‘c’ 3xN image data.

[agriggio (Alberto)]

If you have numbers very far apart in magnitude, you can get cancellation effects and other funny things happening – but those do not apply here

[heckflosse (Ingo Weyrich)]

I agree that for the case of this topic, the differences may be irrelavant. But take this example (more general) in single precision floating point space:

17000000 + 1 + 1 + 1+ 1 = 17000000 != 17000004 = 17000000 + (1 + 1 + 1 + 1)

[agriggio (Alberto)]

Anyway I’m waving my hands a bit here, so take this with a grain of salt
My point is that I would not expect rounding errors to be significant in this context

[heckflosse (Ingo Weyrich)]

@agriggio

My point is that I would not expect rounding errors to be significant in this context

I agree

[heckflosse (Ingo Weyrich)]

I just wanted to point this out, because in RawTherapee we had summation errors up to 10% range for some algorithms (long ago) because we did not take care of this…

[gwgill (Graeme W. Gill)]

@anon41087856

Then, ICC can be LUT too, but LUT are a double-edged sword (theoritically more accurate than matrices, but also less forgiving to any user mistake during calibration and not exposure-invariant – general advice is to stay away from that).

For wide dynamic range, additive device like a camera, a “2.5” D LUT is probably the right approach. This means creating a table in which the per channel luminance lookup is independent (i.e. orthogonal) to the chrominance lookup. If your luminance linearization is done outside the colorspace conversion, then the table could be purely 2D. This would have an advantage over a matrix in allowing for the embedding of spectral sample statistics. i.e. you can weight areas of the table for the best conversion for the likely real world spectra associated with each region in the chromaticity plane.

[kofa (István Kovács)]

It’s just funny how the ‘without the maths’ entry is already at the point of discussing commutativity of matrix operations and error accumulation in limited precision floating point operations.

[anon41087856]

@JackH

I happen to have done this and in fact one gets exactly the same final result whether (1) WB is applied to the data before running the optimization routine or whether (2) the optimization routine is run on the unbalanced raw data from the capture as-is. In the end for all intents and purposes CCM(2) = CCM(1)*diag(WB).

So I would be happy if you could review my code, because my tests don’t show that property. Also, what solver did you use ?