Banding when using hue keyer in Color's secondaries

[Jake Bastian]

Has anyone else had this problem? I'm using the clipfinder workflow (FCP exports an xml, relink with clipfinder, send back to FCP and then to Color) and when trying to do my secondary color corrections the hue keyer sees hues where they don't exist or produces banding where none should be happening (i.e. I select the orange hue in a clip with a girl wearing an orange sweater and it doesn't select the entire sweater even when I go into the reds and yellows as well). I've tried it on several systems... early 2007 macs with Nvidia cards that don't allow anything other than 8-bit or floating point color correction and on systems with ATI cards trying it on every bit depth available and the keyer still selects bands rather than entire hue ranges. Am I doing something wrong, or does anyone have a solution to this problem? Shots have been on build 20 and 21, post was done using the latest version of Final Cut and Color.

 

[Brandon Kraemer]

Jake,

Sounds like you might need to modify your technique a bit? Are you looking at the matte mode? Switch into matte mode and adjust your keyer till you get a nice white area that includes your desired selection, then switch into composite mode to see your correction results. Are you adjusting more than the Hue constraints, are you working with the luminance and saturation sliders as well? You probably need to really work the selection tools to get the whole orange sweater. Softness (in moderation) can be your friend as well.

If your issue is purely a technical one (i.e. "keyer sees hues where they don't exist") then no I don't have any recollection of seeing that kind of behavior. Try the above suggestions first, picking hues in the secondaries is not a one step process. Good luck.

 

[Jake Bastian]

The problem comes when trying to key out flesh tones in general. The banding was appearing when using all the constraints (saturation and value as well) so we unchecked boxes finding that the hue constraint in particular was causing the problem by not recognizing hues correctly. This happens exclusively with Red footage, and we figured out that if we render out a first exposure pass and then re-import into color the problem goes away. We can do a first pass on all the footage we shoot to get around the problem but the added time and storage space required to treat all of our footage seems like it should be unnecessary. I could be wrong though.

 

[Brandon Kraemer]

We can do a first pass on all the footage we shoot to get around the problem but the added time and storage space required to treat all of our footage seems like it should be unnecessary. I could be wrong though.

Sounds like a bug then. You might look into what version of Color your working with (1.5?), and if there are any known conflicts with using Red RAW clips of a certain build (i.e. Build 20) with that version. Search the forum too, if you haven't yet. I can't say as I have heard of this issue.

For what it's worth, I pre-transcode my selects before sending to Color, for a variety of reasons. I find it more stable for one.

 

[Patrick Tresch]

Another "bug" with RAW & Color I've come across : it's impossible to get values higher than 100% even if broadcast safe isn't enabled and Force RGB isn't enabled.

Anyone has a clue if this is a "normal" behavour? Using a Prores clip in the same timeline don't show me the same 100% limit (it goes until 110).

Pat.

PS: secondary do work strange sometimes... I've come across problem like when I select the color, the footage switch to a raw view as if I didn't apply any Primary nor gamma/colorspace, but this problem isn't recurent.

 

[Jake Bastian]

PS: secondary do work strange sometimes... I've come across problem like when I select the color, the footage switch to a raw view as if I didn't apply any Primary nor gamma/colorspace, but this problem isn't recurent.

I have come across this as well, though I don't think it's a bug. The people at apple say this is because the raw has greater color range to select from so keying from the raw footage should theoretically allow you to pull a more precise key. If this isn't something that you want, unfortunately I think you have to render out the clip and manipulate that file instead.

 

[Gunleik Groven]

Another "bug" with RAW & Color I've come across : it's impossible to get values higher than 100% even if broadcast safe isn't enabled and Force RGB isn't enabled.

Anyone has a clue if this is a "normal" behavour? Using a Prores clip in the same timeline don't show me the same 100% limit (it goes until 110).

Pat.

PS: secondary do work strange sometimes... I've come across problem like when I select the color, the footage switch to a raw view as if I didn't apply any Primary nor gamma/colorspace, but this problem isn't recurent.

1st isn't a bug but a feature. Comes to apples choice of implementing the Red Room as a KUT in the signal chain. Has some dubious implications, really.

Second sounds more like a bug.

 

[Mel Matsuoka]

Thank you so much for posting this, Jake. I thought I was the only one experiencing this issue in Color.

I'm just speculating here, but I don't think this banding issue is related to Color's handling of raw R3Ds. I get the banding even when I use RED footage that was transcoded to ProRes HQ and Uncompressed 10-bit Quicktimes. I don't get the same "matte banding" problems when working with lesser formats like DVCProHD, however.

I've tried re-transcoding footage at full de-Bayer, but it doesn't seem to help minimize the banding. Drives me nuts.

For what it's worth, I have had this problem even in Color 1.x, with all camera builds between b15 and b21. Running ATI x1900 GPU

 

[Patrick Tresch]

1st isn't a bug but a feature. Comes to apples choice of implementing the Red Room as a KUT in the signal chain. Has some dubious implications, really.

RED footage in Color is ALLWAYS BROADCAST SAFE!!!:hurray::mad2::nads:

 

[Jake Bastian]

Thanks Mel, that does help to know it's not just my machines doing this, and that it's not the De-bayering, or the fact I'm using Nvidia graphics cards on my desktop. Looks like I'm going to have to include a first pass color correction in my post time from here on out.

 

[Patrick Tresch]

I've seen that when the tab "Override Header Settings" is enabled and put to "video 64-940" you can go to the illegal levels (+110%)...

Now, why a setting that is the import value setting of the shot, is also applied to the project values?


Manual:
Using RED Media with Final Cut Studio – Nov 11, 2008 24


Minimum and Maximum Levels for RED QuickTime Media
In Color, RED QuickTime media is processed in its native RGB color space. This does
not allow for processing values above absolute white (100 percent) or below absolute
black (0 percent). As a result, all grades applied to RED media will clip beyond these
outer boundaries, regardless of whether Broadcast Safe in Color is turned on or off.
If Broadcast Safe is turned on, expanding the broadcast safe range by raising Ceiling
IRE above 100 or lowering Floor IRE below 0 will have no affect on the image. However,
restricting the broadcast safe range by lowering the Ceiling IRE below 100 or raising the
Floor IRE above 0 will clip image values at the narrower limits.
The default Printing Density for RED media is “Linear (0 Black - 1023 White).” This
means that when rendering RED QuickTime media as DPX files for film printing, the
minimum and maximum values of 0 and 100 percent in Color correspond to the digital
values of 0 and 1023 in the rendered DPX files. The Printing Density setting for each
shot is located in the Settings 2 tab to the right of the Timeline.