Compression Artifacts

[Mitch Deoudes]

There's another thread discussing this issue here:

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

that includes some pretty good images of the problem. Although the thread starts to wander, and at times breaks up into bouts of spasmodic defensiveness. (I honestly don't understand why technical discussion should provoke such defensiveness in some folks. If we talk about these things, they'll get fixed - or at least we'll generate workarounds. Everybody loves the camera - just chill out.)

I'm going to have to weigh in on the "yes, I've seen it" side. It's definitely noticeable - particularly with tungsten-balanced lighting, mostly in the blue, some in the red, and in areas of low detail (which is, paradoxically, high detail - due to noise... i.e. your eye is going to pick out noise/grain more easily over a smooth surface). And it's definitely visible in motion as well, contrary to what some have suggested.

The thing that really gets me is the *size*. Check out post #8 in the thread above, in the upper-right corner over the blurry background. I'd think that sensor noise would be pretty high frequency - it surprises me that the codec responds with artifacts of that size. Then again, I stopped taking math classes as soon as I was allowed to.

In motion (RGB), it appears as a subtle crawling/pulsing in the luminance of the image. And I think this is the crux of the problem... i.e. film can get plenty grainy in the blue channel as well - but it's an organic effect that we're all used to. Compression / video noise artifacts just look weird.

I'm not sure either of the workarounds already suggested are ideal: 1) blur the blue channel (will piss off the compositors), 2) shoot everything daylight balanced (will piss off DP's and/or producers), 3) wait for uncompressed RAW output.

But I'm hoping with further discussion, we'll come up with something. (I will say, a selection of data rates/compression ratios in the future would be, in the vernacular, "dopesauce". Be great to just crank the rate when necessary.)

[Stacey Spears]

Maybe there could be both; SP 27MB/s and HQ 40MB/s.

I like the idea of different data rates, but one bottleneck might be CF at this point. The RED drive probably has higher bandwidth capacity in RAID0, but is more sensitive to bumpy enviroments.

Does 2k use the 27 MB/s data rate? If so, a test between 4k and 2k would be worthwhile.

This might be an area where someone could develop some algorithms for post to improve the quality or reduce noise. I am not a fan of noise reduction myself, but people use it all the time. a SCATCH plug-in anyone?

[Mark Pugh]

Maybe 3k could be an achievable compromise here - at 27MB/s

[Justin Anderson]

Does 2k use the 27 MB/s data rate? If so, a test between 4k and 2k would be worthwhile.

I assume 2K is 1/4 the datarate since it's 1/4 the image data. Correct me if I'm wrong.

[Justin Anderson]

Would it help to reduce blue and red noise by using filters to correct the white balance before it hits the sensor? (Like CTBs and stuff like that)

[Mitch Deoudes]

Would it help to reduce blue and red noise by using filters to correct the white balance before it hits the sensor? (Like CTBs and stuff like that)

Check out the thread I linked above. This was indeed one of the suggested workarounds. It has drawbacks, of course.

[David Mullen ASC]

It's not very practical for typical scenarios where you'd use tungsten lighting (night interiors and night exteriors), except for bluescreen shots.

The general consensus is that 320 ASA is the native speed of the sensor, so an 80A blue filter would knock this down to nearly 80 ASA, not very practical for your typical night interior scene with tungsten lamps. And of course using a higher ASA rating to compensate sort of defeats the point if you're trying to reduce noise.

I'd say that you're going to have to light night interiors scenes like you'd normally do on film -- with smaller tungsten lamps to match tungsten practicals in the scene, at a reasonable ASA level (320 to 500 ASA) so the light levels are not unrealistic nor overpower the natural ambience -- and deal with any noise level in the blue channel in post somehow if you find it to be a problem. Blue correction filters or blue gels is not really a good idea, not if you're trying to light a night interior scene naturalistically.

[jbeale]

Re: Redcode data rates: I don't know what the current firmware does, but based on Jim's two dragster R3D files posted a few weeks ago, I measured:

A001_C006_071102_001.R3D "Drag2" 2k 16:9 72 fps (526 frames)
Data rate: about 263 kB/frame, or 6 MB/sec at 24 fps

A003_C007_071105_001.R3D "Drag1" 4k 2:1, 23.98 fps (236 frames)
Data rate: about 1047 kB/frame, or 24 MB/sec at 24 fps

This is based on my analysis of the R3D files using a hex editor. The size of image frames within those R3D files is an integer multiple of 512 bytes (padded out with 0x00 bytes). The frame size is variable, but not by much: for example, with the 2k res file, most frames are exactly 263 kB, and the smallest frame is 245 kB.

When you think about it, a 4k 2:1 image is 8 Mpixels with 12 bits per pixel. When the output file is only 1 MB in size, that's quite a bit of compression (12:1).

[Oliver Koeppel]

I think, the problem we´re talking about only gets weight when using full 4k for mastering. If you downconvert 4k in 2k you will not see anything of these problems.
In my mind right now we have only two solutions:
downconvert 4k to 2k makes sense nearly most of times,
if you really need 4k, denoising blue is the way to fix it.
It´s only a workaround for now, maybe red will get it done someday.

btw: ok, have been late with the scars. Got the message :greedy:

[Stacey Spears]

I assume 2K is 1/4 the datarate since it's 1/4 the image data.

Yeah, I suppose it would be difficult to overcrank if you were running at the same rate. :) If you are not overcranking though, being able to up the bitrate could be a good thing.