The Color Wheels Mystery – Demystified

[Jeremy Garchow]

So why add an offset to the value? How is that good for the user?

Couldn’t the Master be used as a better offset control instead?

[Simon Ubsdell]

[Jeremy Garchow] “So why add an offset to the value? How is that good for the user?”

I was using the “offset” there as an illustration for why the mapping doesn’t match between Rec.709 and Rec.2020. It’s not a true value … and I haven’t given enough thought yet to what it would actually be.

I’m not saying that there is a control offset component in this. It’s just that the Wheels are reading the input pixel values AS IF they had an offset applied, and that is the root cause of what we are seeing.

[Jeremy Garchow] “Couldn’t the Master be used as a better offset control instead?”

The Master is indeed a standard Offset control or Brightness control, which is the exact same thing by a different name.

The maths for that is simply: pixelValue+controlValue

I think I might have managed to confuse you by my use of the term “offset” (though I did use it correctly).

… Can you expand on your second question because I’m not sure how you are meaning it to apply to this?

Simon Ubsdell
tokyo productions
hawaiki

[Jeremy Garchow]

First, thanks for attempting to demystify this mystery.

[Simon Ubsdell] “… Can you expand on your second question because I’m not sure how you are meaning it to apply to this?”

My direct question is, why do it this way? 🙂

[Simon Ubsdell]

[Jeremy Garchow] “My direct question is, why do it this way? :)”

To that, my friend, I have no answer ☹

Or rather, I need to make clear that they didn’t “do something funny”.

This is not some exotic color science that they have actively decided to implement. (Sorry, Bill, but it really isn’t this time.)

They simply decided (?) not to normalise the Color Wheels to the Rec.709 scale. Which is to say the the Color Wheels are effectively seeing the “wrong” input values.

(Just as the Color Board is seeing the “wrong” input values in Rec.2020 for the inverse reason.)

Simon Ubsdell
tokyo productions
hawaiki

[Simon Ubsdell]

I just wanted to point out that if you’re eagle-eyed with your maths, you will have spotted that I didn’t complete the “offset” calculation, which should have read like this:

pow(x+.1, 1/gamma)-pow(.1, gamma)

It doesn’t make any difference to the validity of the demonstration. (I have used 0.1 as the variable but, as I have mentioned, I am guessing at that – again, for the purposes of the demonstration it’s close enough.)

I just wanted to keep things simple enough not to confuse – if possible. (Not sure I’ve managed that, but I tried!)

Simon Ubsdell
tokyo productions
hawaiki

[Jeremy Garchow]

[Simon Ubsdell] “Or rather, I need to make clear that they didn’t “do something funny”.”

And by funny, you mean clever?

I know you said not to use the word “bug” but doesn’t this feel like a mistyped or misread or misused calculation?

[Simon Ubsdell]

[Jeremy Garchow] “I know you said not to use the word “bug” but doesn’t this feel like a mistyped or misread or misused calculation?”

That’s a very good question, I think.

The word “bug” can cover so many different things, from simple mistyping, as you say, up to much more fundamental design decisions.

I have a problem with calling the latter “bugs”, but that’s a personal thing.

This is where we need our good friend, Walter.

In this case, I would say there is not even the remotest chance that this is a mistyped line of code.

I simply cannot believe that the team were not aware of the results. My impression was that they thought this would be “good enough”.

But while I can troubleshoot the problem, I simply have no idea how they arrived at the decision to let this through. That’s a people thing …

Simon Ubsdell
tokyo productions
hawaiki

[Walter Soyka]

[Simon Ubsdell] “The word “bug” can cover so many different things, from simple mistyping, as you say, up to much more fundamental design decisions. I have a problem with calling the latter “bugs”, but that’s a personal thing. This is where we need our good friend, Walter.”

I’ll go one step beyond that. Our little studio has been doing a good bit of development work, and I have come to hate the word “bug” for anything. It’s the connotation. Bugs sound external. Who would actually put a bug into something? They just crawl in on their own.

I think the term “bug” lets the developer off the hook. I prefer the words “defect” or “flaw.”

While “bug” deflects blame, “defect” states simply and matter-of-factly that there’s a problem with the product. Defects don’t have agency, and they don’t spring into being through abiogenesis. We create them, and if we care about quality, we must find and repair them.

Simon, these threads remind me of our conversations about the FCPX light wrap [link] and the FCPX keyer [link] — it sounds like an engineering/QA miss.

Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

[Simon Ubsdell]

[Walter Soyka] “I’ll go one step beyond that. Our little studio has been doing a good bit of development work, and I have come to hate the word “bug” for anything. It’s the connotation. Bugs sound external. Who would actually put a bug into something? They just crawl in on their own. “

I couldn’t agree more.

(It’s great to have your input after all this time. How we have missed it!)

Simon Ubsdell
tokyo productions
hawaiki

[Jeremy Garchow]

[Walter Soyka] “I think the term “bug” lets the developer off the hook. I prefer the words “defect” or “flaw.””

Perfect.

So, the FCPX Color Wheels and Color Board are flawed depending on what color space the Library is in.

They also appear to have a defect in the way values are read and/or calculated.

The term I like the best? Busted.

The FCPX color wheels are busted. 😀