Blue Skies - Noise & Banding

[Radim Schreiber]

I would like to get best performance out of RED One for recording skies. It is the primary fine art product of my company www.TheSkyFactory.com
We have been experiencing unwanted noise and color banding in our footage.

We are following current workflow:

Expose as close to the right as possible in RED Space
ISO 320
Shooting 4k, RED Code 36 - Max
23.97 FPS
1/48 shutter
Master Prime Lens with Schneider Filters
MOV export


our final export is to MPEG2 - Blue Ray

Is there anything else that we can do to improve grain and color banding/jumping? Would it help us recording in RED Log instead of RED Space?

Thanks
Radim

[Justin McAleece]

what type of .mov are you exporting? Keeping it as uncompressed with the highest bit rate is obviously the best. Also, I would try exposing at ISO 250 and see how that looks.

[Graeme Nattress]

Blue skies are notorious for provoking banding in images, but I've not managed to ever find banding in an R3D's data. The likely culprit here is the nature of MPEG2 (lossy compression and 8bit encoding).

Normally, to defeat banding when dropping from a high bit depth source (like the 12bit R3D) to 8bit, you dither (which adds a small amount of noise to an image) to redistribute the quantization errors that lead to banding. This works great until you go to compress to MPEG2. MPEG2, like all lossy codecs, can't code noise very well, so instead of wasting lots of bits encoding the dither, it encodes the flat-ish areas of the image as flat with no noise, and that leads to visible banding. You can force it to spend lots of bits on the dither, but that might blow your bit-budget. But as there is always some small amount of noise in any image, that basically modulates the flat areas of the image, and they can pulse a little with the noise modulation and not look too pretty.

In the end, there's very little you can do other than add a small amount of noise to dither the sky, and push the bit rate up as far as you can.

Hope that helps,

Graeme

[Radim Schreiber]

Yes, we export uncompressed MOV.

adding noise to fix banding is kind of counter productive for us, because we are trying to minimize noise. I see that banding and noise work together when it comes to compressed file. We may need to change our output and forget about MPEG2. Post production I can worry later too. Now I want to make sure that we are shooting it the right way so we are not wasting time.

Thanks
Radim

[Roberto Lequeux]

Can you go straight from R3D to your final? That might help too.

[Radim Schreiber]

Roberto. We have ordered CS4. I believe we will be able to do direct export that way.

[jimhare]

Are you monitoring on 8-bit DVI or are you basing this on your final output? Try exporting a TIFF and looking at it in Photoshop.

[Dan Hudgins]

One thing you can so to reduce banding is to turn down the sharpness in the display monitor and when you process the R3D files.

If there are any edges the compression and monitor can increase the step size at the band edges, so rather than get 8 bit bands that are almost invisable, you get 6 bit or even 4 bit bands that look very bad.

If you dither a little you get a rough edge to the bands that when sharpened looks even rougher.

So to minimize the band edges, blur the source a little, do not sharpen at any part of the image processing, and turn down the monitor sharpness as far as you can.

If the compression has a sharpness adjustment, turn that down as well. Also do not increase the contrast after compression, so be sure the monitor brightness is down a little and the contrast just lets you get near black and white but not all the way there.

[jbeale]

Reducing noise is a valid goal, but if you want to avoid banding with an 8-bit codec and 8-bit display path, I think you have to accept some amount of dithering (noise, if you like). It's not a camera issue, you can easily see banding on entirely smooth computer-generated gradients, once they're dropped down to 8 bits with no dithering.

[Graeme Nattress]

An bit system (like MPEG2) and especially a highly compressed system (like MPEG2) needs a small amount of noise in the image to at least have a chance of avoiding banding. That's the very nature of such highly compressed 8bit systems.

Graeme

[Dan Hudgins]

I think the 8 bits is not so much the issue as the compression.

When images are compressed it seems that areas are given a common value for their brightness, and adjacent blocks may not be one step (1/256) up or down but more than one step, so what you are seeing are not 8bit steps but more like 6 or 4 bit steps.

I know from my computer generated images that banding shows up if the 8bit BMP filels are converted to JPG and as JPG the banding is obvious. This is even when JPG is set to so called 100% quality.

I was including +/- one bit dithering automaticly for BMP export (24bpp), but made that an option because of possable problems making MPEG-2 files because any noise in the MPEG-2 stands still because the full frame refresh rate is only about 4-8fps or something like that. So with the dithering on you can see patches of texture that come and go in blank areas like the sky.

What is odd about MPEG-2 is that the "grain patches" that show up are sometimes blurred on some frames and sometimes sharpened on other frames it seems for no reason, and even when encoding 480 copies of the same original frame the display changes from one frame to another showing artifacts in different parts of the frame. One would think that the image should look the same for all the compressed frames if the exact same input frame was used, but that is not what happens, you get different results for the same input frame.

And as I mentioned any sharpen makes the tone step size at the boundary larger, so if you sharpen an 8bit image the step at the boundary may increase by several tone steps. This is more of an issue in compressed images that may already have the tone difference between bands or blocks more than one tone step, when you sharpen you "outline" the edge of the bands or blocks making them more visable. Even the sharpen in the monitor can do this "outlining" of the bands and blocks.

Some compressors seems to have some kind of sharpen as well as soften filter in them, and so if the images get sharpened before or after compression the edges of the bands and blocks can have their step size made larger than one tone step.

My point being that 8bits (24bpp) is not to blame for all of the issues that show up in so called 8bit images (such as JPG or MPEG-2/4 vs. BMP 24bpp), much of the problem is due to compression and sharpen making the tone boundaries larger than one tone step, and also issues with the monitor peaking of high frequencies which would cause exaggeration of tone boundries even in images that are uncompressed and un-sharpened. Some video boards also have peaking so make problems with edges. Even the monitor cable can affect the high frequency bandwidth to the display for analog monitors, and so affect how tone boundries appear.

On Apple computers some tone scaling was done(?), so if you have an 8bit image set to gamma 2.4 for viewing on an analog monitor (PC), and you display it on a computer (or HD TV) that uses tone scaling to shift the gamma to 2.22 or 1.8 or something, the tone scaling can introduce unevenness to the tone steps, and peaking will exaggerate that unevenness to the point that it becomes visible, or more visible.

[Graeme Nattress]

It's the 8bits combined with the compression and the particularly type of compression that is the issue. If you have 8bits, but uncompressed, you can use dither effectively and the problem vanishes. If you had MPEG2, but at a higher bit depth, (and a bit higher data rate) the problem would, I hope, go away. Put 8bit and MPEG2 together, and you're bound to have issues!

Graeme

[Rudi Herbert]

Yes to all of the above, however, we haven't answered the concern in the original post of whether the chosen workflow can be improved. I think you're shooting RED at its best, highest quality settings, except that yes, I would expose for 200-250 ISO since when shooting skies, light should not be an issue and that should decrease noise somewhat. Other than that, you're pretty much maximizing the RED's capabilities, so nothing I would change.

As for CS4, I use it, love it, swear by it, can't believe how everybody is not using it, but that said, transcoding directly from the R3D should not be much better than from DPX or Cineon, but yes, better than from QuickTime. I would shoot 4K, downsample to 2K, then reframe for 16:9 and export from After Effects directly to high quality MPEG2 for BluRay. That's produced the best results from the very limited testing I've done.

[donatello b]

i go out to blu ray ... many times i'll render out 8bit (because 32bit float takes 7-8X longer) sections to see what they look like projected (blu ray RE disc) ... many times i do see some banding, these are sections that have heavy CC, and i see highlights that get clipped ... i do NOT see the banding or clipping when i render out using 32bit float ..
either way i think the rendered m2t ( or is it m2v) clip ends up 8 bit .. 32bit float does make a difference ...