Color Banding On Redcine Output

[banksgriffin]

Experiencing terrible color banding issues after conforming to 8-Bit Uncompressed 1080 from R3D files through Crimson. Most of the problem areas are in the darks and when there is a shallow depth of field. The banding appears in FCP and QT. We have runthe gambit of different compression outputs and read virtually every post available on the subject. No matter which way we output (with the exception of DPX files) the footage has this problem across the board. The footage looks impeccable in RedCine so there wasn't an acquisition issue. In dire need of assistance...

THANK YOU RED FOLKS!!
-Best
Banks Griffin
Director/DP

OSX 10.5.3
FCP 6.0.3
QT 7.5

 

[jimhare]

I get the same thing creating 10-bit uncompressed. For me it's unrelated to Crimson, just creating QTs seems to be the problem. Doesn't happen with TIFF/DPX etc.

Looks like 8-bit even when doing 10-bit.

 

[banksgriffin]

Definitely nothing to do with Crimson. I have done all of my subsequent tests directly through RedCine with no other factors involved.

 

[jimhare]

Banks,

Do you notice with both 8-bit and 10-bit? I would expect it with 8-bit but 10 should be clean. And are TIFFS/DPX clean? I believe it's just QT.

 

[banksgriffin]

Yes with both 10 and 8. DPX files are clean and good.

 

[jimhare]

Same as me. Anybody know if this is to be expected? I'd prefer to be able to make clean QTs and not have to make TIFF/DPX.

 

[John Tissavary]

10 or 8 bits-per-pixel is only part of what's going on when you're using Quicktime and a codec. Chances are good that there's an RGB to YUV conversion taking place (4:4:4 to 4:2:2) during your render, handled by whatever codec compressor you've chosen, and, depending on the bit depth of that codec's internal 'machinery', artifacts like this can develop.

Many 10bit codecs, though they technically hold 10 bits per pixel, do internal calculation at 8 bits. Crappy, huh?

On top of that, FCP does not support 10bit RGB at all, only 10bit YCbCr (YUV). So anything you render out of FCP is going to be YUV at some point in the calculation.

I can recommend Avid DNxHD or Cineform as reliable quicktime codecs for high end pro work, but neither of these render reliably out of RedCine.

I usually render DPX out of Scratch (same render engine as RedCine) and then do conversions to qt or avi in other software if that's what's needed. But I also 'modify' my expectations when working with Quicktime, other than DNxHD or Cineform where I can count on the results.


cheers,

John T.

 

[jimhare]

Thanks John. My tests are with uncompressed, and play with the banding directly from the QT app as well as FCP. Would the CODEC and FCP issues still apply in this case?

Is there a way to better control RedCine? Parameters we aren't using?

Thanks again!

Jim

 

[sander kamp]

Didn't see this post so made a new one here:

http://www.reduser.net/forum/showthread.php?t=19729

I find it hard to believe that this is a 10-bit versus 8-bit problem. The problem only occurs when outputting quicktimes from RedCine, in every codec and every bitdepth I tried. When outputting the same clip from RedAlert there is no problem.