1080p S&Q colour banding
 

I was shooting some Clouds today using S&Q motion at 1080p. I had set 1/25 in S&Q so the camera was grabbing one frame a second (fast motion).

Unfortunately the image seems to be suffering badly from colour banding, which is a real shame as I really like the footage. I have confirmed that the footage is the same on the camera so it's not an import issue, it's happened during capture.

I also shot some footage at 5/25 which is fine so it has something to do with using 1/25.

Maybe something to watch out for!

Paul.

PS, I'm starting to think Sony need to employ me as a beta tester!

Oh, no! It's all I can say:(

So now we have:

- vignetting
- back focus
- colour banding
- WB problems

Well, I guess I was lucky not to have sold my old good V1E away for half-free; even when I finally do get my EX1 after several months waiting, it'll be more for experimenting purposes rather than important projects (of which I have several planned for this month alone). At least for a couple of months to come, that is... Thank God we have the Prime Support here, Paul!

PS. And Paul, I was sort of a beta tester for the V1E, if it consoles you!

I have shot similar cloud shots with the EX1 and have not seen this.
I wonder if it has something to do with SQ 1 frame/s mode?

Having said that, 8 bit video has never been really great with gradients regardless of camera. Now when Cineform releases their portable 4:2:2 10 bit recorders, things will change.

Here's a similar grab from footage shot at 5/25 at 1080p, which you can see doesn't suffer the same problem.

C'mon Steven - all the cameras I've ever used have been 8bit, and I've never seen banding like this!

Like I said, I have cloud shots that do NOT show this with the EX1, so maybe it's something to do with the SQ 1 frame per second mode that was used at that time.

Yes, it's true 10 bit gradients are better than 8 bit. And YES, his example is clearly showing bad banding.

As I said in the opening post, it happened in the 1/25 setting and not in the 5/25 setting so that's a yes.

It may also have been a one off, I guess time will tell!

Strange?

Here's am EX1 grab from some evening footage in AZ. I see no banding.

I got similar banding once when shooting a sunrise on my A1 - I just assumed it was due to a combination of 8 bit, 4:2:0 color and a subject with very little green component (the sunrise was primarily reddish-brown).

I can't imagine why the ex1 would look different in interval mode vs. regular recording though, unless it has something to do with the way the compression is applied. Maybe the frames are being compressed one at a time as they come in, rather than buffering and then building a GOP - so this could be what 35mb/s I-frame looks like.

I can't help but forgive the camera though, the rest of the footage was really nice.

http://dvinfo.net/conf/showthread.php?t=111942

OMG it looks like low color GIF image with no dither. awful

No - it's a compression issue, not bit depth or colour space. And easy enough to prove in Photoshop with the right original with a smooth gradient. The original shouldn't show any banding (despite being 8 bit), but then make JPEGs with increasing levels of compression. There will come a point where you should see contouring exactly like in the examples at the start of this thread.

It's down to insufficient bits being available to code the differences subtly enough within the macroblocks, and often less data is available for chroma than luma. (And 4:2:0 should LESSEN the problem for a given datarate. Half the number of samples compared to 4:2:2, so twice as many bits can be allocated per pixel with all else equal.)
That seems an extremely good guess at what is going on.

I would guess that no matter how the GOP is built with timelapse one could easily hit a situation where every frame is totally different and very easily max out the available bandwidth. Perhaps this is why we have the option of recording more than one frame at a time. Being able to record an entire GOP would ensure one I frame per trigger and then in post only pull the I frames.
Of course if there is that much frame to frame variation your timelapse is probably going to look pretty sad when played back.
The other option might be to record more fps than you really need and then speedup in post.

I thought so too... but it doesn't hold up to further investigation:

35mbs = 35,000,000 bits/second = 4,375,000 bytes/second

4,375,000/25 = 175,000 = 175 kilobytes per frame.

Paul's second sample above (clouds3.jpg) is compressed to 174kb and doesn't show any banding at all... even if interval recording is being compressed & stored as iframe only it's not enough to explain the banding unless the codec is significantly less efficient than jpeg.

Two things to bear in mind...

Firstly I was not using the frame record function, I was using undercranking with S&Q motion.

Secondly, the images posted were screen grabbed and re-exported as jpegs so the file size of each will not be directly relative to the original.