bizzare blue highlights applied to footage after render w/ color corrector adjustment

Can't figure this one out. After doing a basic saturation adjustment using the 'Color Corrector', this clip renders out with these blue highlights that carry through to any final output. Unchecking that effect removes the highlight, but on re-rendering it appears again. See before & after screen grabs below. 1st time this ever happened. Running FCP 6.0.5

Before


After

What codec are you on? Hit apple 0 for sequence settings, go to render settings and switch to render in 8 bit YUV.



www.strypesinpost.com

Under vid processing tab I was rendering in "10-bit material high-precision YUV"
Sequence, codec is ProRes 422 (HQ) at 100% quality.

I did as you suggested, re-applied some saturation and voila'.... all is good in the world.
I'm gonna read up that stuff for future reference.
Thanks strypes!

Didrik
www.johnckmedia.com

Sadly, Final Cut's 32-bit render pipeline sometimes misperforms if you don't have the right kind of graphics coprocessor in your edit system.

For future reference and googling purposes, what kind of graphics coprocessor does your system have?

Graphics co-processor? If it's misbehaving on the FCP color corrector, which is an FX Script, won't that be handled outside of the GPU?



www.strypesinpost.com

Haven't the foggiest idea. I've never used Final Cut's color corrector. But I have seen stuff like that still before, and rumor has it it's related somehow to graphics.

I'm really just fishing here.

Neither do I.

didrikj, is the pixelation consistent on application of the Color Corrector on all clips regardless of plugin setting? (in other words if you drop the CC without any hue adjustments and give it a render, does it still pixelate?)

If that's the case, can you try dropping in the 3-way, giving it a render and see if it still pixelates.

Then, on a 3rd test, create a new sequence, drag in a clip with a different codec (like DV or DvcproHD), switch render settings to render all in float (render all clips in high precision YUV), and pop on the CC. Does it still pixelate?

I can't re-create the pixelation here on FCP 6. (I also realized i haven't a clue how the hue wheel in the CC works).

Then let us know the specs- FCP version, QT version, OS version, graphics card and machine you're on.



www.strypesinpost.com

Unpaid testimonial: Every Final Cut system in the universe should have Magic Bullet Colorista installed on it.

Editors and their color correctors shouldn't fight like daddy and mommy. They should get along like daddy and daddy's girlfriend.

That as well as Furnace Core, Mocha and a useable lens flare effect. (Are you listening, Apple?).


>They should get along like daddy and daddy's girlfriend.

Well, if it were a PPC and Colorista in the same package, I have a hunch that daddy's girlfriend doesn't get along with mommy.



www.strypesinpost.com

Prior to about a year ago, I would've voted for Knoll Light Factory. But Star Trek had to go and ruin that for all of us.

Here's the graphics card info:

Chipset Model: GeForce 8600M GT
Type: Display
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 256 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0407
Revision ID: 0x00a1
ROM Revision: 3175

FYI - In 4+ years using FCP on a fairly reg basis, this is 2nd time this happened. 1st time was about 6 months ago and it immediately (by about 24 hours) preceded the "implosion" of the graphics card my MacBookPro3,1. Apple care said my graphics card had failed and they replaced it for free.

Quicktime Version 7.6.2 (518)

Gotta bail at the moment, but will reply back with rest of requested info.

[support.apple.com]

The relevant highlights:

Quote

?Apple has determined that some MacBook Pro computers with the NVIDIA GeForce 8600M GT graphics processor may be affected. If the NVIDIA graphics processor in your MacBook Pro has failed, or fails within three years of the original date of purchase, a repair will be done free of charge, even if your MacBook Pro is out of warranty.

You might have yourself a bad graphics coprocessor there. If your laptop is less than three years old, I'd take it and those screen shots to the nearest Apple store and ask them politely for a replacement.

10-bit is a frigging CURSE in current FCP. It's a memory hoig, a bandwidthhig. Every issue like this has been solved by backing down to 8-bit-- including transitions going through a card (I remember this from years ago). Why the hell do we need 10-bit if we're bnot going to film finish, don't see banding, the effects look great and color doesn't splorch? That's a new tech term for what I see above-- splorch.

Just so I know.

- Loren

Today's FCP 7 keytip:
Cycle your timeline track size with Shift-T !

Your Final Cut Studio KeyGuide? Power Pack.
Now available at KeyGuide Central.
www.neotrondesign.com

What do you mean, why do we need 10-bit? It's two more bits! If I set my timeline to 8-bit, I can't sleep at night. I toss and turn, stricken to the core with the shameful knowledge that I cheated my client out of two of their hard-earned and well-paid-for bits.

Seriously, though. Eight-bit stinks out loud. You can't grade worth a damn, trying to tweak the hue of a region of flat color ? like the blue of a sky ? is an exercise in maddening frustration, and additive compositing simply doesn't work at all, period.

Somewhere along the line, this idea got started that eight bits of precision ? not eight bits of original in-camera sampling, but eight bits of mathematical precision ? was good enough. It's bunk. Using only eight bits of precision is like rounding off to the nearest ten bucks when you leave the tip at the Waffle House. The error might fall on the too-high side or the too-low side, but either way, somebody's getting screwed.

FCP doesn't render in 10 bits at all. It's either 8 bit full integer or 32 bit float. I wish it can do 10 or 12 bit. The codecs are either 8 or 10 bits, YUV. But what's interesting here, is that the GPU seems to have a handle on the render of FXScripts when you go into float.

Color from what i recall does 8, 10, 12, 16 and full precision float, but everything is handled by the GPU.



www.strypesinpost.com

Issues of bit depth and render precision are so complicated they make my head hurt. Basically it breaks down into integer versus floating point, and linear light versus gamma encoded versus logarithmic.

The trend these days (now that computers are generally beefy enough to handle it) is toward 16-bit half-float or 32-bit float, in linear light. Smart people like Ron Brinkmann say this model just flat-out works better, mathematically; it more accurately simulates the way light works. In my experience, it's true. It just works better than integer rendering.

If you're not working in linear light, though, then you have to take gamma curves into account. The computer has to take the gamma curve off, then do its maths, then put the gamma curve back on, and it has to do all that at a really low precision, which contributes to visible artifacts like posterization.

If Final Cut had a 10-bit, or even 12-bit, integer rendering mode, it really wouldn't buy us much. It might be slightly better, but not significantly better. Hell, After Effects has a 16-bit integer mode, and it's no better than 8-bit. You don't see significant improvement until you switch over to linear light, which happens in AE when you go to 32-bit. No reason you couldn't do 16-bit half-float linear light, or even 8-bit integer linear light if you really wanted to. But since more precision is better, 16-bit float is kind of the minimum, and 32-bit float is sort of the sweet spot.

I see 12 bit integer to be more precise, but doesnt require the computational power of full precision float and this would help if you had filter stacks, but if you have a 12 noon delivery and you don't have time to go at 32 bit float, and you want an excuse to finish that coffee break, I'd render in 12 bits...

Speaking of lin light. There was that podcast on FXguide on the subject and he mentioned about the add and screen composite modes would behave differently if it was done in linear light.



www.strypesinpost.com

I've tried to start this post three times now. This is really difficult without visual aids.

It's not so much that add and screen work differently in linear light. The fundamental compositing operations are mathematical ones. Add does with it says: it adds the pixel values together. Screen is more complex; it inverts, then multiplies, then inverts again. But it's still pure math. Those operations don't change based on what numbers you plug in to the operators.

But it is fair to say that the results you get look different when you're working in linear light.

Put simply, light is a linear phenomenon, but the eye is not a linear sensor. You know how an 18-percent gray card ? like on a MacBeth chart for instance ? appears to be a middle gray, halfway between black and white? That's because our eye doesn't respond linearly to the amount of incoming light.

An evolutionary biologist could probably tell you how this adaptation made it easier for our ancestors to avoid being eaten by jaguars, but I really don't know about all that. I just go with "This is how it works because eyeballs are magic."

When all we're doing is looking at @#$%& with our eyes, everything's fairly straightforward; eyeball magic occurs without our having to be aware of it. But things get complicated when we start measuring light with electronic sensors, and then attempting to reproduce that light with electronic displays. An electronic sensor is purely linear: voltage out is directly proportional to number of photons in. But a CRT screen (for example) is not linear. The amount of light coming off a point on the screen is not directly proportional to the amount of voltage we put into the electron gun. So we have to adjust the input to the electron gun in such a way that it produces the correct amount of light. That's what gamma is for.

(With LCD screens it's even more complicated than that; an LCD screen is so non-linear that it can't be described in terms of a gamma characteristic. But that's okay, because LCD screens used on computers and televisions are all carefully engineered to emulate CRT screens, because that's what they were designed to replace.)

So we've got two sets of numbers for every pixel in a given image: the actual values that the sensor recorded, and the values that we're going to send to the display device to make it put out the correct amount of light. These numbers are different, and we use gamma encoding to translate between them. It's approximate at best, but it's what we do.

This is fine, right up to the point where you start changing the numbers. Because which number do you really want to change? Say you're using a color corrector, and you want to boost the brightness of the midrange values in the image. Presumably the values you want to boost are the ones that appear to your eye to be the midrange ones. But remember, that's not really the middle of the range, because 18=50. So the computer has to do an inverse gamma correction to figure out what "midrange" means, before it can alter the numbers.

That's just one example. Where it gets interesting is in compositing. Let's say you go out and shoot two slides. I mean like actual 35mm color film slides, like you'd put in a slide projector. On one of those slides, you shoot a landscape in daylight. Totally ordinary vacation snap. On the other slide, you shoot fire in an otherwise lightless room. Weird and more than a little creepy, but okay.

Now you decide to rig up two slide projectors pointed at the same screen. You put these two slides in, turn the projectors on and oh no the meadow is aflame.

To do the same thing in your computer, you just use the add operation. That's literally simulating what the two slide projectors were doing. It's taking the light ? i.e., the values ? from one image and adding it to the light from the other, just like shining two slide projectors at the same screen. (This, incidentally, is why we shot the fire in an otherwise lightless room. We only wanted to record the light that came from the fire itself, not any other stray light that happened to be lying around.)

Except the add operation doesn't work, does it? The results are all wonky and wrong to the eye. Why? Because the computer is trying to be too smart for its own good. It's doing that reverse gamma correction business again, and consequently getting the math all wrong. It's subtly wrong, but it's wrong. Wrong enough that your eye isn't even momentarily fooled.

If you work in linear light, on the other hand, the computer says, in quite specific terms, "screw gamma." It takes those two images, both linear in nature by virtue of the fact that electronic sensors are linear, and simply adds the numbers up. Then it gamma-corrects the whole thing, so when it feeds the requisite voltages to the attached display device you get a natural-looking range of luminance values.

So you see, compositing operations are all the same. But the results you get are different depending on which numbers you put in, because the numbers you put in dictate how closely you're simulating the way actual photons behave in the real world.

"Screen," though ? ugh. People who come from Photoshop think "screen" is a good compositing operation to use for putting something light over something dark. They're mistaken. "Screen" doesn't simulate any physical process. It's moderately useful in very specific circumstances when you're working in gamma space and when you're doing integer maths that truncate overflow values. But since you shouldn't be doing either of those things, ever, "screen" is a compositing operation you should never use.

Of course you can still use it for creative purposes. There are no rules when art is involved. But if what you're doing is trying to make your shot look real, if you're trying to simulate what would have been photographed if the giant robot had really picked up the little boy while the gas station behind them exploded, then all you basically ever want to use is "over" and "add." And use them in linear light space, and in floating-point precision so your overflow values aren't clipped to white.

This is interesting, while we're on rendering in 8 bit vs 32 bit float.

Dave Newman's post on QT being primarily 8 bit.

Quote
http://www.reduser.net/forum/showthread.php?t=33640&page=3
Sloppy/old implementations are 8-bit only, as the original specification didn't include alternative pixel formats, resulting every tool having to fallback to the 8-bit RGBA mode with that broken 1.8 gamma (at random times.) As QuickTime came to the PC later, more QT implementations on the PC support deep pixels than from QuickTime on the Mac. Tools like Autodesk Combustion and Adobe After Effects can support QuickTime at 16-bits per channel (format 'b64a') (I think Scratch just added it, also Nuke, but not Fusion -- EyeOn, catch up), whereas most tools on the Mac seems to be 8-bit only for QT sources. For the tech. side of things is bizarre that the Mac every made as a production suitable platform (Avid did it spite of QuickTime.) FCP has support for some deep formats, but only YUV formats like 'v210' (10-bit 4:2:2) and 'r4fl' (32-bit float, yuva 4:4:4:4.) While FCP has this 32-bit float, most of its filters don't support it, the product is shockingly unpredictable when it choose to deep modes (although rendering is stable.) Color doesn't support Quicktime at all, and accesses ProRES and others, only through an internal Apple API, bypassing QuickTime. There are very few post production solutions that reliably maintain deep pixel precision using compression, one reason why Stu Maschwitz's Rebels guide recommends uncompressed AE finishing, as DPX is mostly commonly 4:4:4 10-bit RGB. CineForm has fought this battle and won in places to allow for deep pixel compressed workflows, Adobe is good at supporting deep pixel API (beyond the 16-bit QuickTime support it has), FCP works, and many Windows tools are pretty good with QuickTime. With ProRES, CineForm and Avid DNxHD now proving compression and deeper color is compatible, we are seeing more tools improve there support, although slower than you want, although I doubt QuickTime Player will ever get there.

The podcast mentioned that screen was used to sorta "fix" the problem with add, but without really sorting out the math. For the linear light workflow, what I'm getting is something like this, correct me if i'm wrong:

YUV 709 video -> gamma correction -> linear working space -> gamma correction to HD 709

With raw/film it's probably something like:

log -> LUT (conversion to linear) -> linear working space -> LUT to match film stock -> film out

I'm not sure how FCP approaches this or if it works with a baked in gamma from the outset.



www.strypesinpost.com

Ok ya'll, ran a bunch of tests this morning. Here are the details per strypes request below:

1. Consistency - No, I can't really get the splorch to appear consistently. So far it's only happened on clips with more detail and more visual objects in the frame (more people, things, cars..etc.). Also possibly on clips that have more highlights in the frame.

2. 3-way CC applied to the offending clip did not cause splorching. Again, I'm only doing very basic tonal adjustments. In this case applying a bit of saturation only.

3. So far I verified that only saturation adjustment causes the splorch. Adjusting whites, blacks, mids works fine.

4. dv/dvcpro vs. ProRes 422 - Created a new ProRes 422 sequence with render settings to render all in float. Popped in material from 6 diff tapes. Source material was recorded in HDV but captured as dv/dvcpro on one and ProRes 422 in the other. Was able to replicate splorch in only one of the dv/dvcpro clips (not all). Ironically, the ProRes 422 clip was one that I had splorching on about 6 mos ago, but today couldn't replicate.

Get this... After 30 min of doing this test and 20 back and forth renders the offending file stopped splorching out after like the 6th saturation adjustment..... Random...

Lastly, I quit FCP, trashed render files, re-rendered timeline from #4 above; no splorching.
Then added in original clip that started this post off, applied CC and splorching arrives.
Added original clip to timeline again, applied 3-way CC and no splorching.

5. FCP: 6.0.5, QT: 7.6.2, MacOS: 10.5.8, Graphics: GeForce 8600M GT, MacBookPro 3,1.

Here are screen shots of what I replicated at the beginning of this morning's test.

Before (dv/dvcpro)


After (dv/dvcpro)



Here are screen shots from 6 months ago (1st time with problem) but I couldn't replicate today. You can notice the slight saturation bump here. Splorch is in the background on this screengrab.

Before (ProRes 422)


After (ProRes 422)







strypes Wrote:
-------------------------------------------------------
> Neither do I.
>
> didrikj, is the pixelation consistent on
> application of the Color Corrector on all clips
> regardless of plugin setting? (in other words if
> you drop the CC without any hue adjustments and
> give it a render, does it still pixelate?)
>
> If that's the case, can you try dropping in the
> 3-way, giving it a render and see if it still
> pixelates.
>
> Then, on a 3rd test, create a new sequence, drag
> in a clip with a different codec (like DV or
> DvcproHD), switch render settings to render all in
> float (render all clips in high precision YUV),
> and pop on the CC. Does it still pixelate?
>
> I can't re-create the pixelation here on FCP 6. (I
> also realized i haven't a clue how the hue wheel
> in the CC works).
>
> Then let us know the specs- FCP version, QT
> version, OS version, graphics card and machine
> you're on.

The only sort of consistency I can find is that they are generally chroma/luma hotspots. But that shouldn't introduce pixelation unless there's some limiter on it that's gone awry.

Try trashing fcp prefs.



www.strypesinpost.com

That was a great monograph, Jeff, thank you.

I'll likely appreciate higher-bit values when I start mastering more HD.

- Loren

Today's FCP 7 keytip:
Cycle your timeline track size with Shift-T !

Your Final Cut Studio KeyGuide? Power Pack.
Now available at KeyGuide Central.
www.neotrondesign.com