APPLE FINAL CUT PRO: Apple Final Cut Pro X FCPX Debates FCP Legacy FCP Tutorials

More "demystification"...

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Bill Davis
More "demystification"...
on Jan 8, 2018 at 7:38:12 pm
Last Edited By Bill Davis on Jan 8, 2018 at 7:43:09 pm

I'm trying to stay out of this because in both software engineering and color theory - I'm pretty much an idiot.

I'm just an end user, and HAPPY to be one.

But this has blown up so much - that I'm fascinated.

I'm also IN LOVE with being in the world where I have access to ALL SORTS and LEVELS of expertise on complex topics that I don't understand myself. Even if I don't understand the math, at LEAST I can learn a bit from those that do.

In one of the X groups, Final Cut Pro X Editors, Phil Pan (the color science guy with what appear to be pretty deep credentials) has been weighing in on this OVERALL engineering debate.

Just to help keep things factual, here's a chunk of his latest public posting there. Again, uncut and un-edited. Just a discussion point for those who are interested in the topic. If you want to engage directly or ask questions of Phil, this is happening in the Facebook Final Cut Pro Editors group.

With publicly graned permission to re-post and done verbatim with no alterations or commentary of any kind beyond some extra carriage returns I added to keep the WALL OF TEXT at a minimum.:

Phil Pan writes:
Maybe I should explain to users why Apple's scope shows data excursion below "0" and above "100" IRE. In a previous comment I erroneously pointed that this puzzling, but this stems from the fact that I haven't done video work in a long while (I mostly focus on film). If you come back to the standards litterature, this turns out to be entirely correct. It seems to throw people off and everyone thinks it's a bug whereas in fact it's the proper way to treat SDI signals.

If you look at SMPTE 259 M and SMPTE 292 M, you'll see that not all code values in an 8bit or 10bit range are used for pixel data. In an 8bit interface, for instance, codes 0 and 255 are used for sync, black starts at code 16 and white is pegged at code 235. The range of codes between 1 and 15 is called 'footroom' and the codes between 236 and 254 is called 'headroom'. The range spanning 1 to 254 is called "Full Range", and the range spanning 16 to 235 is called "Narrow Range" or more commonly "Legal Range". The proper way to process pixel values in SDI video is to peg your computational "0" at incoming code value 16, and your computational "1" at incoming code value "235". You perform your math as you should and then, because your algorithm sits out an array of numbers, you need to limit ('clamp') the minimum and maximum values to whatever your video standard will accept.

The recommended practice in SDI processing is to clamp not to the Narrow range, but to the Full range. It makes sense, because that's precisely why there is a footroom and a headroom to start with. So this is what you're seeing in Apple's colour tools when you scope them. Negative Lift (aka "Shadows") will cause negative excursions down to ~7%; positive Gain (aka "Highlights") will cause excursions above 100 IRE, to ~109% and that is absolutely the official way to do this. Tools that clamp between 0 and 100 IRE are plainly wrong and Apple are showing they're consciencious engineers. Why "-7" and "109", you'll ask ?

Here's the math (for 10bit video; the ratios are the same as for 8bit): For footroom: (1–64)/(940-64) = -0.072. For headroom: (1023-64)/(940-64) =

What's probably not helping users, however, is the nomenclature on the scopes themselves. Some scopes have an overlay that shows the extent of Full range vs Narrow range. If there was a coloured line at 109 IRE and one at -7 IRE, with a label that said "Full range", maybe people would be less confused.

The habit, also, to state 0 to 100% as "IRE" units is antiquated but as we've seen with the whole metric-vs-imperial units, in America people like to stick to their trusted old values. Nothing (especially in a computing system_ would prevent a scope from displaying the vertical scale in code values. You'd clearly see that "0" is in fact code 16 in an 8bit workflow.

Lastly, it should be noted that the same thing applies to Rec 2020.

You need to understand that 709 and 2020 both use the *same* OETF function (BT 1886, which is a gamma of 2.4). Whether they're in 8bit or 10bits, they have the *same* brightness dynamic range. What changes between 709 and 2020 is the chromaticities of the Red, Green and Blue primaries (the perceived colour of these primaries). 2020, because its primaries are more widely spaced, is able to represent more colours and is deemed "wide gamut". This has nothing to do with HDR. In HDR, there is more appropriately Rec 2100, which defines both the PQ and HLG OETFs (so, a much wider brightness range), but still within the Rec 2020 primaries.

This is why in Final Cut, you have three options when working i WideGamut: 2020, 2020 PQ and 2020 HLG. The first one uses the same OETF as 709 (a simple gamma 2.4); the second uses the very broad PQ range which extends to 10K NITs, and the last one is the hybrid Log/Gamma curve that is basically the Rec709 OETF for dark tones, blending smoothly into an extened power function for highlights. HLG was designed for broadcast purposes, to maximise compatibility with non-HDR TV sets.


___

AGAIN the lines above are NOT mine - they are Phils. If you choose to quote the above text, please note it's NOT material coming from ME. (the cow quoting system occasionally inadvertanly misattributes quotes of quotes) and this is NOT my writing. And needs to be attributed to it's ACTUAL author. Thanks.

And thanks too to ALL that have participated in this - Especially Oliver and Simon - without their bringing up their original concerns - I would never have thought about any of this - and I feel better informed because of this whole discussion.

THIS is the new world of education. People sharing thoughts and ideas, more directly.

Thank you Engelbart, Kay, and countless, countless others for making all this possible.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Simon Ubsdell
Re: More "demystification"...
on Jan 8, 2018 at 8:10:59 pm

With respect to Philippe, this is indeed all valid but it is not actually illuminating of the phenomenon under consideration here.

I also notice that he seems to have dropped his "interesting" SMH theory of the color model being employed for the color wheels in 10.4.

Simon Ubsdell
tokyo productions
hawaiki


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 8, 2018 at 8:39:51 pm

Then Simon, please help me better understand this.

It appears (to my layman’s brain) that Phil (I don’t know him so I can only refer fairly to the handle he has elected to use in his posts) feels there are legitimate reasons Apple has made the operations interface choices it has. And that they are science based - not arbitrary or “bugs” in the sense they are mistakes that need correcting.

He appears to feel these are choices that users can easily adapt to in order to achieve the proper results they want consistent with accepted industry practices.

If you feel differently, by all means weigh in if you feel it’s worth your time.

The goal is enhanced understanding. For everyone. Nothing else.

My 2 cents.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index


Simon Ubsdell
Re: More "demystification"...
on Jan 8, 2018 at 8:53:19 pm

[Bill Davis] " And that they are science based - not arbitrary or “bugs” in the sense they are mistakes that need correcting."

I have said all along, despite all the talk of bugs, that this isn't a bug, but nobody wanted to listen. (Just kidding, but seriously, it really, really, really isn't a bug.)

It's a decision. And there is an explanation for why it is happening. And Philippe's observations do, in part, illuminate what is happening (but not I think in an especially helpful way).

But what we are seeing is nevertheless an anomaly. And an anomaly that is, in my view, not helpful to the actual user of the product, who after all is the most important factor in this equation.

I really don't want to make this personal but I do need to stress that Philippe initially posted a remarkable comment on my YT channel to the effect that we were seeing the SMH color model in play in the color wheels, and I think I have conclusively shown that he was wrong about this. And of course he is now no longer espousing this view. We can all get things wrong and no blame attaches to him for having jumped to this conclusion.

The fact is that a midtones (gamma) correction absolutely needs to behave as if the zero and one values were the zero and one values that we see in the waveform monitor. This is a fundamental requirement to make grading adjustments manageable in the real world. (I tried not to complicate my account of this and consequently some might argue that I was guilty of an over-simplication, but for practical purposes, I was not.)

The Color Wheels do not conform to this requirement, as I hope I have conclusively shown.

The fact that they do not conform is most emphatically not an indication that Apple have adopted an exciting new color model that is of unique benefit to the user.

If you force my hand, I am going to have to say that what they have done is poor practice and very unhelpful to any and all users.

But again, it's not a bug. So please, please, please stop using that word.

Simon Ubsdell
tokyo productions
hawaiki


Return to posts index

Tero Ahlfors
Re: More "demystification"...
on Jan 8, 2018 at 9:12:24 pm

How scopes are shown/read should not have any effect on how the tools work. If one wants to see how the actual SDI signal looks one should check out a hardware rasterizer. Full/legal range and subblacks/subwhites have been a thing since forever and there have been workflows for those as well.

¯\_(ツ)_/¯


Return to posts index

Walter Soyka
Re: More "demystification"...
on Jan 8, 2018 at 9:20:18 pm

[Bill Davis] "He appears to feel these are choices that users can easily adapt to in order to achieve the proper results they want consistent with accepted industry practices. "

Phil is talking about how and why FCPX measures output on the scopes -- not how or why the controls on the color corrector affect the image the way they do.

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


Return to posts index


Simon Ubsdell
Re: More "demystification"...
on Jan 8, 2018 at 9:25:05 pm
Last Edited By Simon Ubsdell on Jan 8, 2018 at 9:26:25 pm

[Bill Davis] "Then Simon, please help me better understand this."

I should probably reiterate what is at the heart of this problem and the reason Oliver and I thought it was worth investigating.

Whether you're a professional colorist or just an everyday user of any color system, you absolutely do not want a midtones correction to dramatically affect your shadows and highlights.

The Color Wheels Midtones control operates much more like an Offset control than the Gamma control that it is unquestionably meant to be.

This is not helpful. And it is inefficient in practice.

I highlight the midtones correction because it throws into sharp focus an issue that ripples right across the entire implementation of the wheels.

Does that make the point clearer for you?

Simon Ubsdell
tokyo productions
hawaiki


Return to posts index

Oliver Peters
Re: More "demystification"...
on Jan 8, 2018 at 9:45:19 pm

Just a stupid little question, but has Phil actually used or played with the color wheels using test signals or real world images? Or is his contribution purely theoretical? Fine either way, but it would help to know.

- Oliver

Oliver Peters - oliverpeters.com


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 8, 2018 at 10:46:59 pm

The Facebook group is open to all.

10,000 plus members there, and he’s been happy to engage with anyone about this stuff, openly.

That he’s not here, is a shame. But probably an artifact of overall popularity of locations for information debate and discussion in the FCP X community.

This was once one of the MOST popular hubs of that.

Realistically, sadly, (honestly, crushingly to me personally) not so much anymore.

Sigh.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index


Steve Connor
Re: More "demystification"...
on Jan 8, 2018 at 11:38:34 pm

[Bill Davis] "This was once one of the MOST popular hubs of that.

Realistically, sadly, (honestly, crushingly to me personally) not so much anymore.
"


Well apart from the fact that it has the clearest discussion of all the forums about the Colour wheels "issue"

"Traditional NLEs have timelines. FCPX has storylines" W.Soyka


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 9, 2018 at 12:31:59 am

[Steve Connor] "Well apart from the fact that it has the clearest discussion of all the forums about the Colour wheels "issue""

Sorry, but that’s not even remotely close to true.

I’ve learned 10 times more about this issue in other forums compared to this one. The arguments on BOTH sides have been sharper, science based, and take into account things that appear to be relevant (such as how Apple might be trying to accommodate both Rec 2020 AND Rec 2100 factors in their software approach). (My ignorant layman’s shorthand)

The only thing so have come away from these discussions feeling totally confident about is that this whole topic is nowhere as simple as the initial “everyone knows you just divide this by that and you’ll then be accurate” Frame this thing kinda took on when it first appeared.

It appears that software engineering science is pretty damn complex and doesn’t lend itself to simple solutions.

Who knew?

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Neil Goodman
Re: More "demystification"...
on Jan 9, 2018 at 1:44:56 am

[Bill Davis] "This was once one of the MOST popular hubs of that.

Realistically, sadly, (honestly, crushingly to me personally) not so much anymore."


Seems like its pretty much the same peeps that were here in the beginning of this, except maybe Andreas and the tone for FCPX is more positve than it ever has been for sure.


Return to posts index


Bill Davis
Re: More "demystification"...
on Jan 8, 2018 at 10:35:30 pm
Last Edited By Bill Davis on Jan 8, 2018 at 10:48:36 pm

[Simon Ubsdell] "Does that make the point clearer for you?"

Heck no - but that’s because I’m functionally a color idiot - and know far less about this stuff than either you or Oliver.

And obviously vastly less than Phil, too.

As an end user I have ONLY one question that’s of real use to me to answer.

Can I come to the tools (as implemented in X 10.4) and achieve the corrections I might require efficiently and accurately and in ways that don’t get me in trouble later?

Whether the METHOD of how the tools apply any math between the interface and the results is apparently an area of debate just like whether an editor prefer a mouse or a trackpad.

And that’s fine.

But can this tool GET THE JOB DONE is what has basically been called into question in this debate

10.4 was implied to be not just different - but WRONG.

It needed to be FIXED - STAT.

That was what I heard coming out of this discussion.ls early days

Now, apparently it appears to need to be “fixed” merely so it more closely meets the prior preferences of a certain class of colorists that might prefer that it work more like what they are accustomed to.

And don’t get me wrong - that quest is fair and legit.

But it’s “I need the mouse, not the trackpad” to be efficient. A defensible position for any individual editor. but not one fair to apply to ALL editors.

Not shipping a desktop machine without a mouse might be viewed as “non-standard” at one point in computing. Then Laptops become popular and shipping THEM mouselrss becomes just fine.

So is it “broken” (like you can’t move the cursor until this gets fixed - broken.)
Or just “different” like we’re giving you a trackpad not a mouse because we think this makes more sense here.

That’s all I’m trying to figure out.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Michael Gissing
Re: More "demystification"...
on Jan 8, 2018 at 11:02:44 pm

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


Return to posts index

Oliver Peters
Re: More "demystification"...
on Jan 8, 2018 at 11:47:36 pm

[Bill Davis] "Now, apparently it appears to need to be “fixed” merely so it more closely meets the prior preferences of a certain class of colorists that might prefer that it work more like what they are accustomed to. "

That's simply not true. This is not a preference issue. I spent a lot of the weekend putting the Color Wheels tool through its paces for an upcoming blog post of mine. To put it bluntly, it's not right. Period. Yes, you can use it, but to make good corrections is tougher than it needs to be and you quickly induce clipping if you use the midtone wheel's "brightness" control. It works as expected in Rec2020PQ - that's 0 to 10K nits - a theoretical standard that doesn't yet exist in the real world. It does not work correctly in Rec709 or Rec2020 - what all of us use right now.

- Oliver

Oliver Peters - oliverpeters.com


Return to posts index


Michael Gissing
Re: More "demystification"...
on Jan 9, 2018 at 1:10:22 am

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.


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 9, 2018 at 1:49:14 am

[Michael Gissing] "I think you are grasping at straws by copy pasting rationalisations that are not coming to terms with that fundamental inconsistency."

Michael, with all due respect, I am “grasping” at absolutely nothing.

I am listening to multiple voices, and trying to discern who’s opinions make the MOST rational sense. That’s ALL.

My personal bias about this tool is real, but it comes from a history where for months upon months upon months people told me this tool “worked wrong” - when in fact, it was improving my results at every turn.

You will forgive me then for treating THIS debate the same way.

If Apple is “wrong” about the SCIENCE of how they have elected to process Color in 10.4 - then that will come out. Because SCIENCE is absolutely impartial. The math works or it doesn’t.

If, on the other hand, they have merely elected to apply perfectly accurate math in a way that a different interface designer might have done differently - but it still gets the results the user wants - that’s a whole different kettle of fish.

Overall, Apples stuff, in my experience just WORKS.Typically brilliantly. That’s a fact their marketplace results have verified.

A thousand times in 2011 I read: X just doesn’t work right. Ignoring all that was, in hindsight, one of the smartest business choices I have ever made.

If X is ACTUALLY somehow “broken” regards to their color implementation, I have every confidence that they will acknowledge that and fix it. They have done so with reproducible bugs and mistakes over and over again.

Heck, I’d be VERY surprised if somebody either in Apple PR, working for some virtual internet clipping service, or even on the Pro Apps team itself : doesn’t have eyes in this very thread.

These are, after all, VERY public discussions - archived forever.

If they change things, deeply, cosmetically or otherwise - OR if they don’t - it should speak volumes.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Michael Gissing
Re: More "demystification"...
on Jan 9, 2018 at 2:10:42 am

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


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 9, 2018 at 2:38:17 am
Last Edited By Bill Davis on Jan 9, 2018 at 2:43:33 am

[Michael Gissing] "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? "

Because I don’t believe I am. (Posting such quotes)

I’m not convinced they have been.

I’m hearing mosty opinions by non engineers here - and reading what appear to be facts with specific references elsewhere.

To wit: (within the last few hours in that other discussion)

Again from Phil P.

Guys, there’s no sweat and no harm in discussing; this is how everyone gets smarter. I personally enjoy this, as it forced me to brush up my video standards knowledge, having spent most of my recent time dealing with (digital cine) camera files.

Indeed, the wheels, from what I can tell, function differently in standard 2020, PQ and HLG. The reason is simple: There is a standardized OETF for 2020 that pegs diffuse white to studio monitors that are typically set at 120 NITs— the same as 709. And because there is no notion of 'specular' white in SDR (remember that Rec 2020 is also an SDR format), it doesn't matter if your display is set to 400 NITs or 100 NITs — you'll see a natural-looking image as long as the display is calibrated to that OETF.

Still, in a professional environment, you should set your monitors to 120 NITs and operate in a dim room, even if your displays are capable of 400 or a 1000 NITs. The reason is that you might get into issues even on good monitors, with the dark portion of the tone curve, and your perception of contrast will be altered. Film editors need to operate on displays or projectors set at 48 NITs, which requires a totally dark room.

When it comes to HDR, there is a conundrum facing software designers, the same as it is facing users: To what target display are you mastering to ? Because different so-called "HDR" displays are not capable of the same dynamic range, the industry tends to gravitate around different mastering levels — 400, 1000 and 4000 NITs for HDR. If your encoding is for Dolby Vision, that system handles well the problem at the display level. Other systems less.

So there you are, doing an edit in WideGamut (2020 chromaticities) and HDR PQ (OETF). Maybe you got footage from a properly converted ARRI raw file and you have a pretty good PQ-encoded image that extends to 10,000 NITs. What do you do with it ? Do you grade it to full range, or to 4000 NITs ? Or to 1000 NITs ? You'll be tempted to grade it to whatever your own HDR display is capable of, but contrary to standardized broadcast displays, we're not there yet, in a number of HDR setups. The industry has yet to come to terms.

So put yourself in Apple's shoes. They need to support HDR and in a way that makes sense. What makes sense at this stage is to treat your HDR material as full range and to apply linear transformations to it, that are mathematically invertible. They use Offset, Lift, Gamma and Gain in PQ. In SDR 2020, from what I can tell, they use offsets for master and shadows, and gain for midtones and highlights, but going through a weighting function (that's why the effect looks non-linear). This is consistent with general practice for SMH, although there is no "standard" per se (nothing SMPTE, EBU, ASC or AMPAS have recommended). Resolve uses arbitrary bezier polynomials to split the Luma range, and that's their approach.

In the meantime, their design intent is that if you're grading a 709 project, things will look and perform normal. If you grade in SDR 2020, things will operate normally, similarly to 709. When you grade in HDR, things will behave as best they can, given the current nature of the medium...

——-

Phil continues, but I’ll stop there because this whole conversation is getting boring. The point is I feel like I’m getting higher quality explanations with more explanatory detail - all buttressed with references to textbooks and SMPTE publications encouraging me to NOT rely on opinions about this stuff, but rather go determine the truth for myself (to the extent, at least, I’m capable of understanding it.) ELSEWHERE.

This is supposed to be a conversation seeking the TRUTH about the allegation that a piece of software may have BAD DESIGN at its core.

It’s software I make my living with.

So making good choices about it is important to me.

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.

What will help EVERYONE is the truth.

Not defending anyone’s opinion silos - most assuredly including mine.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Michael Gissing
Re: More "demystification"...
on Jan 9, 2018 at 3:03:30 am
Last Edited By Michael Gissing on Jan 9, 2018 at 3:04:19 am

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


Return to posts index

Walter Soyka
Re: More "demystification"...
on Jan 9, 2018 at 3:11:40 am

[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."

To start, let's not conflate color management with color grading!

I'd highly suggest reviewing some of Baselight's workflow materials. There's a lot to learn about color science that's applicable to any platform:
https://www.filmlight.ltd.uk/workflow/truelight.php

And of course, Baselight has an excellent technology for managing colour (they are English!) inside their colour grading system:
https://www.filmlight.ltd.uk/products/truelight/overview_tl.php

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


Return to posts index

Tero Ahlfors
Re: More "demystification"...
on Jan 9, 2018 at 6:31:14 am

[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."

It's not a competition. It's not about who's better. It's about using the mutually agreed upon standards on making fast and accurate corrections. There are obviously feature differences between pieces of software but if you learn the basic tools on one you can easily transfer that skillset to some other program. Or if you're learning from a book that's also what you get. I started with FCP classic and went on to Color, AE, Color Finesse, Premiere, iQ, Smoke/Flame/Lustre, Speedgrade, Fusion, Nuke and now I've parked on Resolve. Every single one of these worked like I expected them to and I could use the skills I've learned along the way and learning only the program specific new stuff.

If for some reason the tools would not work like that I'd probably first think I'm in a special mode (like the log tools in Lustre or Resolve) and not that there's something wrong because every single software has used the same standard before.

Those Phil posts have a lot of good technical stuff but it's mostly irrelevant tech jargon in this case. Instead I'd really like to see some real world footage this new approach is supposed to tackle well. I don't have FCPX but according to the information I've gathered it would take multiple corrections to do one if the shadows and highlights don't stay where they're supposed to. I'd never have a client around if the image would keep changing multiple times when making, then fixing, a single correction.


Return to posts index

Andrew Kimery
Re: More "demystification"...
on Jan 9, 2018 at 6:45:02 am

Isn't Phil's text in Bill's OP part of video coloring 101? I remember reading about it in FC Legend's user manual when I first started seriously grading maybe 10yrs ago or so. Bill, Phil basically talks (in painful detail) about how scopes can show users levels that are out of broadcast safe and why that's normal.

Bill, I know you have an audio background so let me take a stab at a very rough audio analogy.

Imagine you are using a new three band audio equalizer and the Mid adjustment bleeds into the Bass and Treble in a way that you've never experienced with any other three band equalizer you have ever used. So every time you touch the Mids you have to make excessive Bass and Treble adjustments where as other three band equalizers don't require the same back and forth/counter balancing adjustments to get the same, desired result. On top of that, you discover that the equalizer works as expected when working with 48k, 16bit audio and it only gives you the unexpected results when working with 96k, 24bit audio.

[Bill Davis] "This is supposed to be a conversation seeking the TRUTH about the allegation that a piece of software may have BAD DESIGN at its core."

So go seek the truth. Listen to what people have to say. Google things. Ask questions. Listen. You are interjecting a surprising amount and you seem to be more inclined to agree with Phil because he is speculating in a way that puts FCPX in a more positive light and less inclined to agree with Simon or Michael or Oliver just because they've aren't.

[Bill Davis] "Phil continues, but I’ll stop there because this whole conversation is getting boring. "

Unfortunately you stopped right when Phil was getting on topic. All but one of posts you've copied and pasted from Phil aren't really relevant to the discussion being had here and the one copy/paste that was very on point Phil seems to have backed away from because it looks like he inadvertently based the whole thing on a false assumption.

You've said more than once that all of this is totally outside of your wheel house (which is fine) yet you are still trying to tell people that they wrong but you, admittedly, don't know what you are talking about so you end up trying to use Phil as your proxy warrior. Hell, I used to color full time for broadcast and I still remember enough that I don't have trouble following what's going on (including Phil's quoting of chapter and verse) but there's no useful info I can add to the discussion so I've just been lurking and learning.


[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."

People already have, they've just tried to keep things in laymen's terms so the conversation can be accessible to experts and non-experts alike. It's not as impressive sounding as quoting scripture, but it keeps the non-experts from getting left behind as they try to decipher what all the jargon means and how it's applicable (or not) to what's being talked about.


Return to posts index

Herb Sevush
Re: More "demystification"...
on Jan 9, 2018 at 1:43:31 pm

[Andrew Kimery] "Imagine you are using a new three band audio equalizer and the Mid adjustment bleeds into the Bass and Treble in a way that you've never experienced with any other three band equalizer you have ever used. So every time you touch the Mids you have to make excessive Bass and Treble adjustments where as other three band equalizers don't require the same back and forth/counter balancing adjustments to get the same, desired result. On top of that, you discover that the equalizer works as expected when working with 48k, 16bit audio and it only gives you the unexpected results when working with 96k, 24bit audio."

I have been waiting for someone to make that analogy. Simon's posts led me to that exact scenario, and it is very helpful in understanding the way the color wheels are supposed to work.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Oliver Peters
Re: More "demystification"...
on Jan 9, 2018 at 1:52:01 pm

[Herb Sevush] "and it is very helpful in understanding the way the color wheels are supposed to work."

If you want to see how the color wheels are supposed to work (correctly), open a fresh Library and set it to wide gamut. Then create a 2020PQ project. Now import some log footage, preferably Alexa LogC. The built-in LUT will be active. Apply color wheels and grade. Behaves as one would expect. In wide gamut Rec2020PQ.

- Oliver

Oliver Peters - oliverpeters.com


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 9, 2018 at 10:05:19 pm

[Oliver Peters] "If you want to see how the color wheels are supposed to work (correctly), open a fresh Library and set it to wide gamut. Then create a 2020PQ project. Now import some log footage, preferably Alexa LogC. The built-in LUT will be active. Apply color wheels and grade. Behaves as one would expect. In wide gamut Rec2020PQ."

Wait, what?

The same controls are NOT disfunctional in one mode with one set of files, but they are disfunctional in a different mode with other files?

That’s kinda weird isn’t it?

If the color correction algorithm is wrong, it seems like it would be wrong everywhere - but I don’t know enough to have a useful opinion - as I’ve noted from day one.

The crowd here obviously feels this tool is broken.

Others, elsewhere, apparently don’t think so.

If Apple feels this is an issue that needs addressing, I suspect they’ll address it in one of a few obvious ways...

Change it to work more like you guys expect.

Issue guidance on how to use THIS new tool.

Or ignore the whole thing and see if their users adapt to it just like I’ve adapted to the way keyframes function in X - which hardly anyone feels is ideal - but still lets me get my jobs done just fine.

Time will tell.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Oliver Peters
Re: More "demystification"...
on Jan 9, 2018 at 10:56:05 pm

[Bill Davis] "Wait, what?
The same controls are NOT disfunctional in one mode with one set of files, but they are disfunctional in a different mode with other files?
That’s kinda weird isn’t it? "


Exactly. That's what we've been saying across several threads.

[Bill Davis] "If Apple feels this is an issue that needs addressing, I suspect they’ll address it in one of a few obvious ways...
Change it to work more like you guys expect.
Issue guidance on how to use THIS new tool."


That's really all we've been asking for all along and have stated at every opportunity.

- Oliver

Oliver Peters - oliverpeters.com


Return to posts index

Michael Hadley
Re: More "demystification"...
on Jan 11, 2018 at 8:29:29 pm

I just sent in a bug report on the rec 709 color wheel flaw. Too bad. I really do like the functionality and GUI of the wheels but you end up chasing your tail when you start using them. So: back to the color board/Color Finale/Chromatic for now.

Hope they fix this fast.


Return to posts index

Michael Gissing
Re: More "demystification"...
on Jan 9, 2018 at 11:34:59 pm

[Bill Davis] "The same controls are NOT disfunctional in one mode with one set of files, but they are disfunctional in a different mode with other files? That’s kinda weird isn’t it? "

Finally the penny drops. It's not the files however but the mode that determines the inconsistency.


Return to posts index

Jeremy Garchow
Re: More "demystification"...
on Jan 10, 2018 at 1:24:00 am

[Bill Davis] "The same controls are NOT disfunctional in one mode with one set of files, but they are disfunctional in a different mode with other files?

That’s kinda weird isn’t it? "


I would encourage you to actually participate in the “science” and follow along with Simon’s video.


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 11, 2018 at 8:22:27 pm

Well, I tried to.

Then, like most of ACTUAL engineering - the more I read, the more complex and befuddling the topic appeared to become.

Simon presented it as simply "they should have simply divided THIS by THAT underneath this control - and they messed things up because they didn't do that."

Then others expanded my thinking into color spaces, how the math actually changes depending on whether the software is in REC 709 or REC 2020 - and now, it seems to me that the solution might be a BOATLOAD more complex than I first imagined.

The good news, is that there are ACUTAL electrical engineers and software designers, who are surely looking at this now - and I'm sure THEY will figure it out.

On a personal, note, you've also got to understand something...

It REALLY felt like another "here we go again" on this subject to me: Magnetic Timeline: READY-FIRE-AIM— Trackless Audio: READY-FIRE-AIM —NOW it's "Apple has screwed up color correction in 10.4 - READY-FIRE-AIM...

The internet is AWASH today with READY-FIRE-AIM. And those folks were out in force in the first two days of this discussion by accepting the simple narrative: "How could Apple allow such a fundamental functional SCREWUP in the new tool."

Now, thanks to Simon, Oliver and many others, those first few days of "HEY, THIS IS REALLY BROKEN" voices have quieted a bit- as the discussion has revealed how it MIGHT be more complex than it appeared at first blush - and now perhaps, time and reasoned discussion and solutions can take over.

Don't get me wrong, I KNOW it still may be BROKEN - FULL STOP.

And, yes, my personal triggering is definitely a factor . After all, THIS is the place I argued for years that Apple had a reason that they did THOSE things people were Ready-Fire-Aiming about originally. I'd even argue that the view largely accepted now that the dust has cleared is that they had perfectly legitimate reasons for doing all of those things.

But that READY-FIRE-AIM environment is STILL largely our new reality.

And that means it's more critical than ever to go beyond just the "shouting fire" stage.

Which is where I kinda thought this things was headed in the first days of this thread.

Just my 2 cents.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Michael Gissing
Re: More "demystification"...
on Jan 11, 2018 at 10:19:51 pm

[Bill Davis] "It REALLY felt like another "here we go again" on this subject to me: Magnetic Timeline: READY-FIRE-AIM— Trackless Audio: READY-FIRE-AIM —NOW it's "Apple has screwed up color correction in 10.4 - READY-FIRE-AIM..."

And because that is your default response, so many of us get frustrated with you because most of us are not in attack dog mode. I was beginning to wonder if you were reading what we were posting, hence my comment that you were clutching at straws. Your typical defence, which seems triggered by your default response, is frustrating and irritating when it seems you are not listening to reasoned argument and proofs. This also extends to opinion which, when it differs but is perfectly valid, also seems to trigger your default response.

We don't all hate FCPX. And even if we don't or can't use it, our reasons are no less valid. Specifically they are not an attack on X which we have all seen develop into a tool that many use with precision and pleasure.


Return to posts index

Simon Ubsdell
Re: More "demystification"...
on Jan 11, 2018 at 10:23:51 pm
Last Edited By Simon Ubsdell on Jan 11, 2018 at 10:28:46 pm

[Bill Davis] "Simon presented it as simply "they should have simply divided THIS by THAT underneath this control - and they messed things up because they didn't do that.""

I wasn't going to contribute further to this discussion because I think I've more than outstayed my welcome, but I have to put down a marker here.

I did not at any point in any terms whatsoever suggest or imply, let alone state or "present", that Apple have "messed up", as you are explicitly saying here that I did.

On the contrary, I have throughout strenuously and repeatedly (almost to the point of tiresomeness) resisted any such suggestion whenever anyone (including you!) attempted to make it.

There is simply no doubt about this. It is a matter of unequivocal record.

May I ask you to retract this claim, please?

Yours amicably, S.

Simon Ubsdell
tokyo productions
hawaiki


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 12, 2018 at 2:41:46 am

Fair enough, Simon.

Consider any implied criticism fully and publicly retracted.

I freely acknowledge that you came back into the discussion subsequent to your initial post, and made it SUPER clear that you were NOT saying X was flawed.

Just please understand this IS still EXACTLY how those initial “FCP X is NOT a professional tool” memes got started in 2011. Instead of saying from square one “I don’t get what APPLE is trying to do here.” The messaging that started to catch fire was that X was once again flawed for professional use. (Thank god at least THIS TIME Conan didn’t hear about it!)

What breaks loose in public today is often a crapshoot in the world of PR.

AGAIN, you were very clear in your subsequent messaging.

And, I really do appreciate that.

Peace.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

greg janza
Re: More "demystification"...
on Jan 12, 2018 at 6:20:21 am

[Bill Davis] "What breaks loose in public today is often a crapshoot in the world of PR."

As of January 11, 2018 Apple's market valuation is $891.66 billion. I don't think a random anomaly in one of their products will cause undo harm.

I Hate Television. I Hate It As Much As Peanuts. But I Can’t Stop Eating Peanuts.
- Orson Welles


Return to posts index

Simon Ubsdell
Re: More "demystification"...
on Jan 12, 2018 at 9:33:59 am
Last Edited By Simon Ubsdell on Jan 12, 2018 at 11:36:27 am

[Bill Davis] "I freely acknowledge that you came back into the discussion subsequent to your initial post, and made it SUPER clear that you were NOT saying X was flawed. "

Thanks.

[Bill Davis] "Instead of saying from square one “I don’t get what APPLE is trying to do here.” The messaging that started to catch fire was that X was once again flawed for professional use. "

One final clarification:

I explicitly and clearly labelled my initial video as a "Mystery" - specifically, "Apple FCP X 10.4: The Color Wheels Mystery".

And I concluded it by saying (almost verbatim): “I don’t get what Apple is trying to do here.” Specifically I said: "I just don't understand it".

I still don't know what Apple are trying to do and I don't pretend to.

Who steals my purse steals trash; 'tis something, nothing;
'Twas mine, 'tis his, and has been slave to thousands;
But he that filches from me my good name
Robs me of that which not enriches him,
And makes me poor indeed.


Simon Ubsdell
tokyo productions
hawaiki


Return to posts index

Steve Connor
Re: More "demystification"...
on Jan 12, 2018 at 12:55:30 pm

[Simon Ubsdell] "[Bill Davis] "Instead of saying from square one “I don’t get what APPLE is trying to do here.” The messaging that started to catch fire was that X was once again flawed for professional use. "

One final clarification:

I explicitly and clearly labelled my initial video as a "Mystery" - specifically, "Apple FCP X 10.4: The Color Wheels Mystery"."


So many windmills!

"Traditional NLEs have timelines. FCPX has storylines" W.Soyka


Return to posts index

Tony West
Re: More "demystification"...
on Jan 12, 2018 at 2:07:43 pm

[Simon Ubsdell] "I still don't know what Apple are trying to do and I don't pretend to.
"


I think most people on the forum appreciate the work you and Oliver have done on this, including myself.

I kind of looked at your thread in two parts, 1) your explanation of how conventional colors wheels work as oppose to the way apple's did, and 2) you insisted that apple had done it this way on purpose.

"Again I want to stress that Apple have not "done anything wrong" here and it's not a bug. It's a choice they have legitimately made."

I was curious about that second part from the beginning and I'm still a little curious about it. How did you know that was "a choice they have legitimately made."? Did apple tell you that?


Return to posts index

Tero Ahlfors
Re: More "demystification"...
on Jan 12, 2018 at 2:44:07 pm

[Tony West] "Did apple tell you that?"

Probably not but I'd guess this how it went down:

-Somebody programmed the math that works differently between the different standards
-Somebody tested the functionality
-Somebody approved it
-They shipped it

It's not a random bug that just happens in certain edge cases as the results are the same for all users.


Return to posts index

Tero Ahlfors
Re: More "demystification"...
on Jan 12, 2018 at 3:14:45 pm

They had preview events for the tools. I was wondering if anyone noticed this difference during those.


Return to posts index

Oliver Peters
Re: More "demystification"...
on Jan 12, 2018 at 3:44:33 pm

[Tero Ahlfors] "They had preview events for the tools. I was wondering if anyone noticed this difference during those."

Maybe they need to expand their pool of beta testers.

- Oliver

Oliver Peters - oliverpeters.com


Return to posts index

Steve Connor
Re: More "demystification"...
on Jan 12, 2018 at 3:57:07 pm

[Oliver Peters] "Maybe they need to expand their pool of beta testers.
"


This much we do know

"Traditional NLEs have timelines. FCPX has storylines" W.Soyka


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 12, 2018 at 10:09:17 pm

[Simon Ubsdell] "Who steals my purse steals trash; 'tis something, nothing;
'Twas mine, 'tis his, and has been slave to thousands;
But he that filches from me my good name
Robs me of that which not enriches him,
And makes me poor indeed."



Exactly.

The public impression of YOU, Simon, - a person making truly useful contributions to the creative arts - should never have their “good name filched” in ANY way.

And FCP X (and the dedicated team of real people working on it) - should have the same consideration, perhaps.

All I’m saying.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Neil Goodman
Re: More "demystification"...
on Jan 13, 2018 at 1:29:08 am

[Bill Davis] "And FCP X (and the dedicated team of real people working on it) - should have the same consideration, perhaps.
"


There's a difference there. Have you never publicly criticized something you bought? Something you use on the daily? You sure as hell criticized Adobe for subscriptions and Avi for being a dinosaur. Dont those companies and the people behind them deserve the same? MHO is absolutely not. You put something out there in the public and you open the floodgates, especially these days.

People on this or any forum shouldn't have to tip toe around your personal feelings for Apple.


Return to posts index

Steve Connor
Re: More "demystification"...
on Jan 13, 2018 at 9:06:13 am

[Neil Goodman] "People on this or any forum shouldn't have to tip toe around your personal feelings for Apple.
"


Let alone stop making valuable contributions here based on his attempts to shut down any real or even implied criticism of FCPX

"Traditional NLEs have timelines. FCPX has storylines" W.Soyka


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 13, 2018 at 6:25:49 pm

[Neil Goodman] "There's a difference there. Have you never publicly criticized something you bought? Something you use on the daily? You sure as hell criticized Adobe for subscriptions and Avi for being a dinosaur. Dont those companies and the people behind them deserve the same? MHO is absolutely not. You put something out there in the public and you open the floodgates, especially these days.

People on this or any forum shouldn't have to tip toe around your personal feelings for Apple."


Sure I've criticized things. But it's not my default mode. For example, I've criticized the FCP X approach to key framing. I, (like many others) find it overly "fiddley" and I don't think it's entire interface is well designed. I don't harp on that or make it the ONLY thing I say about X, but I've said it and I'm still saying it. There are dozens of other things I've had difficulties with in X as well - (Loss of the Project Library, The complex switch to the Library Model. The loss of the ability to work audio "above the line." ) All annoyances to me.

But I have CHOSEN not to DEFINE my posts here by the parts of the glass that I see as less than full. Not when I can drink what I need, when I need, in such a personally satisfying fashion.

In the interim, where am I with THIS problem? Answer: Working away happily. Cranking out X projects day after day that don't require the thing that needs fixing.

Look, I GET that if you do color work daily - this is a snafu. But ALL productive X editors didn't have an internal way to do color beyond the color board before this - so waiting until it's addressed is simply no MONSTER deal IMO.

At worst, it delays some of the utility of a brand new feature, while MANY other features are in place, working fine, and very useful for users.

I still feel that way.

If you don't - then you're free to say THAT here too.

But that it seems to make you ANGRY - isn't about the features really, is it? It's about seeing ALL criticism of your position as a personal attack, rather than professional critique. (And, yep, I'll cop to that as much as the next guy.) It's HARD not to see every thing that's the slightest bit controversial (or even not!) I post here ripped apart by those with an alternative view.

But that's where we are in the world now. These are contentious times in public discourse.

And there's only two ways to deal with it, IMO. Pull back and let ONE view define the argument from day one. Or voice what I believe, even if it turns out i'm wrong 50% of the time - and let the brickbats fall where they might.

I'm still OK with that. If YOU aren't - that's not my problem, really. But I am sorry it makes you feel so angry, Neil.
Honestly. It must be tiring to be so upset so much. Or maybe not. Maybe that's just what you do. I've certainly seen others who have the same angsty reaction in lots of situations in life. If you and I are one of those "oil and water" matchups, Ces't la vie.

We'll both do fine regardless, I suspect.

Take care.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Neil Goodman
Re: More "demystification"...
on Jan 13, 2018 at 10:56:53 pm

[Bill Davis] "But I am sorry it makes you feel so angry, Neil.
Honestly. It must be tiring to be so upset so much. Or maybe not. Maybe that's just what you do. I've certainly seen others who have the same angsty reaction in lots of situations in life. If you and I are one of those "oil and water" matchups, Ces't la vie. "


Im not angry Bill, not in the least and I respect your expertise in X - I really do.

I do however think your tendency to defend X blindly whether you know about the topic at hand or not gets a bit old at times, and to me it seems like your personal attachments to X and Apple in general can cloud your judgement when having debates about X or apple.

We are all on this forum for the same reason, there's something we all like about X, but its ok to not like things about it too and publically talk about them w/o it instantly inciting a post from you about how people are attacking X and the rep is tarnished, and it not fair to the devs.

but like you said Ces't la vie


Return to posts index

Robert d'Alexis
Re: More "demystification"...
on Jan 14, 2018 at 1:48:49 am

Bill & Neil
It's "C'est la vie", not "Ces't la vie". :-)


Return to posts index

Jeremy Garchow
Re: More "demystification"...
on Jan 14, 2018 at 2:02:03 am

[Robert d'Alexis] "It's "C'est la vie", not "Ces't la vie”"

Translation:

That’s life, not T’hats life. :-D


Return to posts index

Robert d'Alexis
Re: More "demystification"...
on Jan 14, 2018 at 1:33:26 pm

What you wrote was spot-on, Jeremy.
Translation
"Vos propos ont fait mouche, Jeremy"
Now back to our regularly scheduled programming. :-)


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 14, 2018 at 5:04:07 pm

As a narrator, I find “”such is life” a more visually and rhythmically satisfying translation.

Accuracy be dammed - this is ART first - linguistics second, dammit!

🤪

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Jeremy Garchow
Re: More "demystification"...
on Jan 15, 2018 at 1:23:50 am

[Bill Davis] "But I have CHOSEN not to DEFINE my posts here by the parts of the glass that I see as less than full. Not when I can drink what I need, when I need, in such a personally satisfying fashion. "

But you certainly criticize people who aren’t drinking out of the same glass as you, even if they fill their cups from the same spring and may not be as satisfied.

And I would say it is your default mode. You react first, or in your terms, fire first. And if the dissenting information comes from this forum in particular, you seem generally averse to the message of it has anything to do with questioning Apple design intention, and you’d rather copy and paste information that doesn’t really pertain to the subject of the original discussion from Facebook. Simon spent time and went through not only how lift/gamma/gain control works, but also how it’s not working in FCPX color wheels, and then created two follow ups to further the discussion.

I realize I am piling on at this point, but the color wheels are some kind of busted in a way that isn’t beneficial to users. Apple made a great effort, after many years of user feedback, to add these wheels. They didn’t have to, there are plenty of great third party solutions you understand, but they did. The problem is that they work unexpectedly. The saturation curves are very cool and super useful. The wheels are super cool, they just aren’t super useful for everyone at the moment as they can bungle up a grade pretty quickly. I can’t imagine Apple would intentionally design wheels to bungle up a grade quickly. I imagine you probably feel the same way. So that leaves the question, why do they work this way?


Return to posts index

Bill Davis
Re: More "demystification"...
on Jan 15, 2018 at 5:30:37 pm

[Jeremy Garchow] "The problem is that they work unexpectedly."

Fair criticism. (The entire post, not just the quote, btw)

I do truly appreciate your framing in the above quote itself the way you did, Jeremy.

If the original thread had been framed thusly, I probably wouldn’t have said anything.

Of course it wasn’t.

The impression had nothing to do with “unexpected operation.”

It was framed largly in terms of: broken, flawed, - dangerous, even.
The message was: It’s a major screwup, Apple - fix this at once!!!

Yet here we are, two weeks later with likely a million editors exploring and using the new tools.

And the hue and cry about it is pretty “tempest in a teapot” so far.

But maybe that will change.

Creator of XinTwo - http://www.xintwo.com
The shortest path to FCP X mastery.


Return to posts index

Neil Goodman
Re: More "demystification"...
on Jan 15, 2018 at 6:21:02 pm

[Bill Davis] "The impression had nothing to do with “unexpected operation.”

It was framed largly in terms of: broken, flawed, - dangerous, even.
The message was: It’s a major screwup, Apple - fix this at once!!!"


Where was it framed this way? Certainly not on this forum.


Return to posts index

Mark Smith
Re: More "demystification"...
on Jan 9, 2018 at 1:32:16 pm

The way color wheels work in rec 709 is giving me acid flashbacks to doing a tech set up on a analog video camera , say a PC70. Back in those days it was the case that engineering set up controls were pretty interactive, so if you adjusted black shading, it affected white shading, so then you’d have to re adjust white shading to compensate, with an inevitable trip back to black shading again as you balanced controls in an iterative process that was boring and time consuming. Color wheels work prety much like this in Rec 709 . This might be what apple intended but I think they have some serious explaining to do about WHY this is better, OR they better fix it fast. Color wheels are nice, I want them to work, but they are just a waste of time for rec 709.
I watched a color grading tutorial on youtube the other day touting the new color wheels. Throughout the tutorial the WFM in X was visible and as the tutor went through adjustments to his sample footage, levels moved up, and levels moved down . Net result was that his sample looked the same post grade as pre grade, nothing had changed, all the while the tutor was struggling with the fact the if he tried to adjust either the highlights or shadows, the adjuste he made affected the whole image.
I say Apple needs to roll out 10.4.1 with color wheels that work , darned soon.


Return to posts index

Oliver Peters
Re: More "demystification"...
on Jan 9, 2018 at 7:40:46 pm

For those who really want to understand color correction, might I suggest two of the best books:

https://www.amazon.com/Art-Technique-Digital-Color-Correction/dp/024081715X...

https://www.amazon.com/Color-Correction-Handbook-Professional-Techniques/dp...

- Oliver

Oliver Peters - oliverpeters.com


Return to posts index

Andrew Kimery
Re: More "demystification"...
on Jan 9, 2018 at 7:43:37 pm

[Oliver Peters] "For those who really want to understand color correction, might I suggest two of the best books:

https://www.amazon.com/Art-Technique-Digital-Color-Correction/dp/024081715X.....

https://www.amazon.com/Color-Correction-Handbook-Professional-Techniques/dp.....
"



Both great recommendations, Oliver!


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2018 CreativeCOW.net All Rights Reserved
[TOP]