[Michael Gissing]

[Bill Davis] “If you have counter material from equivalent sources arguing that Adobe or AVID or Resolves methods of doing this stuff are better – bring them to the table. Seriously. Please.”

Phil is talking about monitor calibration and the as yet to be standardized HDR requirements. I actually understand this stuff as it is part of my bread and butter. However, Simon, Oliver and I are talking about how the gamma function in rec 709 behaves non standard compared to every other grade software that we know and have used. Simon has shown how the behaviour is non standard to other systems but the biggest issue here is that the behaviour changes within X depending on color space. No amount of SMPTE standard quotation or monitor calibration requirements can or will change this.

So one last time. X does the gamma function with the new wheels software the same as every other grade system since forever as long as you are in rec2020 color space. In rec709 (the more common space at this time) it simply doesn’t and there is no logical reason why as it is not only different to everyone else but it is inefficient and inconsistent.

All other grade systems are consistent with gamma regardless of color space. This actually has nothing to do with monitor calibration so the nits are irrelevant.

[Michael Gissing]

[Bill Davis] “Michael, with all due respect, I am “grasping” at absolutely nothing.”

So why another new thread? Why keep posting quotes that have already been refuted? Why not adress the issue of inconsistency which is the core of this?

I’ve been here since day one so I do not need to be constantly reminded about your heroic decision in 2011 and how happy you are to be vindicated in your personal decision. If that was relevant to this debate I would be the first to acknowledge that in my response but it’s simply not relevant. I too am vindicated by the decisions I made in 2011 which are totally different to yours and equally irrelevant to this issue.

[Michael Gissing]

The rules of editing seem be as easy for AI as grading. But after the AI automated attempt what tools do you need to get back in and finesse? Wheels for color?
https://www.youtube.com/watch?v=w6va-BpzUyA

The fun starts around 5 minutes

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Michael Gissing]

I’ll try to unpack this Bill in terminology that you might better understand.

I put 20 additive dissolves into my HD timeline. I put 20 additive dissolves in an SD timeline but they all behave more like cross dissolves and look different to how the additive dissolve looks in the HD timeline? They are not quite like the cross dissolves which look identical in both timelines – sort of a hybrid dissolve. You can sort of fix it by editing the start and end points but it adds lots of fiddle to making it look like an additive dissolve.

Would you describe that as a bug/ mistake or undocumented feature? Would you want the NLE maker to fix it or just accept that the dissolves are different in SD and need extra steps to behave? You see the issue is not about color science as Simon has so eloquently illustrated. It’s about inconsistency. I think you are grasping at straws by copy pasting rationalisations that are not coming to terms with that fundamental inconsistency.

[Michael Gissing]

So much depends on the camera sensor, lighting conditions and the intended look. I do documentary post work mostly but my first go to is the color wheels and the lift gamma & gain trims to get basic grade and shot matching. Increasingly depending on the camera & codec, a LUT is required. I put that in the second node so I can make those wheel adjustments pre LUT. And I often add a post LUT node to then make final trims beyond the first node trims. I look at saturation and color boost, contrast etc in the first and third nodes. It is just a matter of how the variables best work to which node I make those adjustments. I look at scopes and also just how it looks

Some cameras can make certain colors overly pop so things like Hue vs Sat can tame some of those characteristics. Same with mixed lighting where say a fluro light is injecting a green spike. I find some cameras and lighting conditions can make curves desirable as I move from basic matching to getting a desirable look. This includes the RGB curves. Next is to look at isolating areas either via power windows or using the face plugin ( or both). Sometimes I use qualifiers to make a sky a bit bluer. The thing is I will vary the order slightly depending on the circumstances and also sometimes change the order of nodes. There is no hard and fast rules but my first call is always to get a basic balance with the wheels and lift, gamma, gain. Everything after that is determined by camera and lighting conditions.

[Michael Gissing]

[Bill Davis] “10.4 was implied to be not just different – but WRONG. It needed to be FIXED – STAT. ”

The comparison to alternative hardware like a mouse or trackpad is not relevant. This is not a viable alternative situation as the software is behaving differently depending on color space, in other words an internal inconsistency. Such inconsistency also creates a less efficient function using gamma adjustment in rec 709 color space. When a function correctly behaves as gamma in rec 2020 but not in rec 709, then Apple have to decide if they fix this or leave the inconsistency. Tip toeing around the problem, avoiding calling it a bug or whatever, the simple fact is the function is inconsistent and also inefficient. If I was beta testing this I would file a bug report and expect it fixed. I get that software people hate the word bug but to me an inconsistency within software would be filed as a bug report. To be kind I will call it a mistake. It is not a ‘different’ way of doing things as that would require internal consistency which is lacking in this case.

Apple have two choices. To fix it (and yes stat is important because it could lead to grading work done pre fix to not track and work having to be redone) or to ignore it which means they expect the user to adjust their grade practice when switching between color spaces and to also accept a behaviour in rec709 that is both different and requires more level adjustment which is inefficient.

[Michael Gissing]

[Simon Ubsdell] “Where would we be without the “magical” properties of One and Zero?”

As long as you don’t divide by zero.

[Michael Gissing]

And thanks Simon for taking the time and effort to present this.

[Michael Gissing]

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

I always imagined it as short for ‘buggered’. As in “we really buggered up the code here”. Maybe that’s just an Australian sensibility where we use words like buggered to mean lots of different things.

[Michael Gissing]

[Simon Ubsdell]”Is it not rather a case of Apple trying to make the naming as un-intimidating as possible to the average user? That’s how I interpreted this decision.”

Dumbing down language is not going to help the user when they deal with any other NLE, which is the real world for most of us. How long does it take to come to terms with a word like gamma? Once learned it makes it possible to go anywhere in the hardware and software world and instantly understand what we are dealing with. Isn’t that less intimidating?

I’m sure Apple is happy to add to confusion if it helps people with the illusion that Apple just works. By all means change naming when genuine innovation creates a new paradigm but this is not anything like that.

EDIT: I know you are being devil’s advocate here Simon so I am not directing this criticism at you.