Add support for tint value

[palemieux]

No description provided.

[umathurred]

Uday Mathur
1 hour ago
Another option would be to represent the white balance using CIE XY ... that is unambiguous

New

Tucker Downs
🌵 1 hour ago
CIE xy (little x little y) is the same as kelvin + duv. They can be mathematically transformed. Though using x,y or u,v directly does allow for much more extreme “white points”

Uday Mathur
1 hour ago
Yeah, I'm glad you mentioned that. White points for creative intent may be non-white

Uday Mathur
1 hour ago
We like CIE xy because it's the same but unambiguous. Kelvin and Tint are subject to how manufacturers handle tint

Uday Mathur
1 hour ago
In our conversation internally we discussed how we have changed the handling of tint over the years and how the SDK abstracts the complexity. So our proposal is to instead represent this as CIE XY .
@Stacey Spears
, please correct me if I muddled the description

Tucker Downs
🌵 1 hour ago
Tint to me means duv which is an unambiguous definition. Non compliant manufacturers might use ambiguous methods.

Tucker Downs
🌵 1 hour ago
Sorry to be short, I’m in another meeting but this is a very important conversation!!

Uday Mathur
1 hour ago
maybe we're one of those problematic non-compliant manufacturers who have changed the locus

Tucker Downs
🌵 1 hour ago
It might be very justified for engineering or artistic reasons!! But whatever the internal selection of white point follows, it can be transformed into plankian K + duv

Tucker Downs
🌵 1 hour ago
I think?

Uday Mathur
1 hour ago
Yes, it may not match what we show in the camera UI or other NLEs but if we choose for compatibility to use duv and planckian, we can transform our metadata to match that

Uday Mathur
1 hour ago
or just report CIE xy

Tucker Downs
🌵 1 hour ago
K + duv is desirable because it closely aligns with controls. But if it will lead to incompatibility we should avoid it.

Uday Mathur
1 hour ago
I don't think it's incompatibility, just may be inconsistent with the UI reported values if we use planckian locus instead of our mixed planckian/daylight

Uday Mathur
1 hour ago
I'll let
@Stacey Spears
speak more for Red. He can speak in more detail than I can

Tucker Downs
🌵 1 hour ago
For example, I imagine if a user selects a 5500K WB you might make the reasonable assumption that they are using natural daylight. Which has a plankian CCT of 5500K + 0.0100duv. If they then add apply a -green of 1 click, maybe the UI says that it’s 5500K - 1G but the metadata might report 5500K + 0.006duv (implying green steps of .004 at this setting)

Tucker Downs
🌵 1 hour ago
Ultimately i don’t think we care about capturing what the UI said the WB was but rather we care about describing at a technical level what kind of color matrix the camera was using. (And actually, maybe describing that directly is a much better way to go… I’m not sure)

Tucker Downs
🌵 1 hour ago
Right? Anyway. If this is a particular pain because MFRs might just insert their relative UI values rather than absolute colorimetry and using xy will clue them into doing the right thing with absolute values then we should use xy.

Uday Mathur
44 minutes ago
I don't think it's a pain. we are probably going to implement it as a transform on our existing metadata to be able to support using old footage

Uday Mathur
43 minutes ago
when we originally discussed this
@Joseph Goldstone
had some nuanced concerns. I think we should wait for his input too
👍
1

Tucker Downs
🌵 43 minutes ago
Hmm. Good point. I have not thought about how existing footage might be imported into a project using the proposed workflows

Uday Mathur
34 minutes ago
and we roughly agree that x1000 DUV will be the encoded value for metadata ?

Tucker Downs
🌵 31 minutes ago
I did some math at one point to get a reasonable range of coverage. I think I came up with x10000 duv and fit the data in 16 bits.

Uday Mathur
26 minutes ago
okay... Red's good with it. I've already tagged Joseph for Arri. Would be good to hear from sony/blackmagic and others (edited)

Tucker Downs
🌵 19 minutes ago
Your point that this is a more restrictive range than xy is a very good one that should be considered more

Uday Mathur
19 minutes ago
I should clarify.. we are open to XY or K+-duv

Joseph Goldstone
18 minutes ago
What I would like to see is this:
CCT
lower CCT where we start to interpolate from Planckian to CIE daylight
upper CCT where we finish interpolating from Planckian to CIE daylight
tint as distance along the isotemperature line with positive values going green-ish and negative going magenta-ish.

Tucker Downs
🌵 18 minutes ago
Perhaps we should allow for either tag to be present.

Uday Mathur
17 minutes ago
@Joseph Goldstone
do those 4 fields capture something that XY do not capture

Tucker Downs
🌵 17 minutes ago
The problem with this Joseph is that the isotherms start crossing and diverging in bad ways where you have the interpolation boundary.

Joseph Goldstone
15 minutes ago
I had not thought of that, and it is a good point; but I want to make it easy for cinematographers to relate to this, and x,y chromaticities aren’t inherently relatable to their prior practice.

Joseph Goldstone
15 minutes ago
I would like to keep going here but I need to jump into an OpenEXR TSC meeting that started a minute ago

Tucker Downs
🌵 14 minutes ago
Grrr. Going into another meeting.

Joseph Goldstone
14 minutes ago
[misery loves company]

Tucker Downs
🌵 14 minutes ago
Please see my above example where I point out that this metadata does not need to strictly match the user interface.

Tucker Downs
🌵 12 minutes ago
Re: xy and cinematographers. I completely agree which is why I support CCT duv

Uday Mathur
7 minutes ago
I'm good with it too. only caveat would be that the tint value may not reflect what was displayed in camera UI for Red
👍
1

Uday Mathur
7 minutes ago
but the color will be accurate

[umathurred]

Tint will refer to duv and will be represented as 1/100,000 with positive values to green and negative values to magenta
a signed 16-bit integer can encode the tint 1/100,000

[umathurred]

Joseph Goldstone referenced RDD 55 floating point representation as an alternative to fixed point that I suggested. We should discuss and choose. I'm open to either

[palemieux]

@umathurred How would you extract the duv value from the camera files:

https://github.com/sandflow/camdkit/blob/main/src/test/resources/arri
https://github.com/sandflow/camdkit/tree/main/src/test/resources/red
https://github.com/sandflow/camdkit/tree/main/src/test/resources/venice

[umathurred]

Red currently uses a different representation for tint. We will add a sdk method to transform our internal representation to this vendor neutral representation.

[palemieux]

By the way, it looks like tint (and white balance) is not an intrinsic characteristic of the camera system but instead selectively applied to some of the outputs. It is therefore not clear to me it is an essential parameter, since it is not always used.