AVC-Ultra - revamped

Sumfun said:
I agree that RedCode is highly compressed, but it's based on wavelet compression, which is considered by many to be more efficient than MPEG4-based AVC. I'm sure that Panasonic can deliver raw data, but maybe not with 100 Mbps AVC intra.
Click to expand...

And also your not storing 3-chips worth of information with RedCode. You got the Bayer filter as kind of physical compression. Panasonic could probably get away with a reduced bit-rate version of AVCIntra on a AF100 like camera because of the Bayer filter, so long as it's recorded as a raw bayered image.
 
Yes, P2 card are very cool stuff. BUT IT's PROPRIETARY !!!

why Panasonic don't license them to 3rd parties?

6 years after, the p2 card 64GB cost 1900$ !!!

in 2018 the 1.8' SSD 64GB will cost peanuts...
 
Andrew McCarrick said:
Panasonic could probably get away with a reduced bit-rate version of AVCIntra on a AF100...so long as it's recorded as a raw bayered image.
Click to expand...

Unless I'm misunderstanding what you are saying, that's just not right. A reduced bit-rate AVC-I would be just that - AVC-I. It would not and could not be recorded as RAW or compressed RAW, regardless of sensor pattern. AVC-I and compressed RAW two fundamentally different schemes, right now.

Of course, I imagine they could release something like AVC-W - which would be a wavelet-based AVC compression scheme like REDCODE. But then you'd have AVC-Intraframe and AVC-Wavelet.
 
Last edited:
Boy, we're really geeking out here, but I must chime in.

All of the MPEG codecs, including MPEG-4 (otherwise known as AVC (otherwise known as H.264)) only work on video that has been converted to the YUV color space.

There are several different ways to talk about color if you're a video engineer:

1. RGB. "This pixel is 100 units of Red, 125 units of Green, and 225 units of Blue." RGB is the most straightforward way to talk about it.
2. Bayer. "This pixel is 100 units of brightness, and it was in a spot on the Bayer sensor that has a green filter over it."
3. YUV. "This pixel is 100 units of Y (overall brightness), -25 units of U (the difference between the overall brightness of the pixel and the brightness of just the color blue) and 5 units of V (the difference between the overall brightness of the pixel and the brightness of just the color red)" (or something like that)

If you have a camera with a Bayer sensor and want to record its output in any of the MPEGs, JPEGs, ProRes, or similar codecs, you first have to convert it to YUV, which means you first have to debayer it.

Like Michael Olsen said, there are only a few codecs out there that compress Bayer information without first debayering it: REDCODE is one example. Another is CineForm RAW.
 
Last edited:
combatentropy said:
Like Michael Olsen said, there are only a few codecs out there that compress Bayer information without first debayering it: REDCODE is one example. Another is CineForm RAW.
Click to expand...

Why is that though? Isn't an undebayered image essentially a grayscale image? The color is inferred by knowing which pixels are covered by which filters...what is fundamentally different about the image that makes it incompatible with a type of compression?
 
I would expect it isnt nearly that simple, since there is likely a lot more contrast between one pixel and its surrounding pixels in bayer data, and that would cause havoc on most codecs that simplify pixel information by comparing it to surrounding pixel information. I would expect that most bayer codecs separate color channels before compressing pixel data, right?
 
Gabrobot said:
Why is that though? Isn't an undebayered image essentially a grayscale image? The color is inferred by knowing which pixels are covered by which filters...what is fundamentally different about the image that makes it incompatible with a type of compression?
Click to expand...

A bayer image can be compressed however you want. Unless I'm mistaken, all the Canon DSLRs are using a bayer pattern sensor. Most likely Panasonic and Nikon, too. Bayer sensors made great inroads in the photography world years ago. And we all know those cameras can shoot compressed video.

Here's what is fundamentally different about RAW and...well, video.

A "Video" Camera captures the image on the sensor, reads that off, and then immediately turns it into a compressed video file - where color, gamma, etc. are defined based on curves and the like before being written to media. This would be like shooting on a film camera that somehow did the developing inside the camera, resulting in a work print, rather than a negative.

A "RAW" Camera also captures the image on the sensor, reads it off, but doesn't turn it into a video file. It just moves the data to the media to be interpreted at a later point in time. This is like shooting to a negative - you can't just pull it out of the camera and watch it instantly. It has to be processed first, in order to extract the desired color, gama, etc.

And this is why people like shooting RAW or compressed RAW (where the data is compressed without first applying any "looks" in camera). ISO, White Balance, colorimetry, etc. can be truly altered in post since one is dealing with the pure (or very nearly pure) data. It's not color correction, it's more fundamental than that. It's defining what colors should be there in the first place. And whatever interpretation and compression is done can be completed on extremely powerful computers over the course of hours in a color-accurate DI suite - it doesn't have to happen using a tiny little chip inside a video camera in real time with a little monitor out in the sun or under glaring lights. This results in the ability to create very high quality finished compression because additional hardware, software, and time may be brought to bear. This is also one of the greatest downsides, however, as it requires additional time after shooting to process the footage, debayer, and compress to a video format before editing.

I should note, however, that as hardware and software are progressing, REDCODE is becoming an editable format. I don't know where the others stand.
 
Why is that though? Isn't an undebayered image essentially a grayscale image? The color is inferred by knowing which pixels are covered by which filters...what is fundamentally different about the image that makes it incompatible with a type of compression?
Click to expand...

A major part of compression is looking for common blocks of color, but as nyvz said, the staggered pattern of the Bayer sensor guarantees that there will be no block of the same shade bigger than one pixel. I'm sure you could feed this into an AVC compressor, but it would be woefully inefficient.

The reason these codecs like to start out with a YUV (or more correctly, YCbCr) image is because it's so easy to compress. First, it takes advantage of the same phenomenon that the Bayer sensor does, which is that the human eye pays more attention to brightness than color. So, the first thing it does is throw out half the Cr and Cb. The Y (brightness) channel remains at 1920 x 1080, but the Cr and Cb are downsized to 960 x 1080 (4:2:2) or even 960 x 540 (4:1:1). In this way, you have thrown out a third or even half of the bits before doing any fancy pattern compression. And at this point you really have three monochrome images per frame. They've already been debayered, so the gradients are smooth (nice and compressible).
 
Last edited:
So a raw camera recording to a compressed format like AVC would work out better with 3 chips?
And for a raw camera recording uncompressed, having 3 chips (or a foveon sensor ;)) would reduce the post processing time/bother?

is there a raw format you can record the EX1 SDI output to?
as in one of those, external recorders that seem to be coming out a lot these days
 
themagickite said:
So a raw camera recording to a compressed format like AVC would work out better with 3 chips?
And for a raw camera recording uncompressed, having 3 chips (or a foveon sensor ;)) would reduce the post processing time/bother?
Click to expand...

RAW typically is shorthand for uncompressed Bayer. Uncompressed from three-chip cameras is typically just called uncompressed. Three-chip cameras, yes, would be more straightforward to compress to one of the DCT codecs, because you do not first have to debayer it. The whole point of debayering is to unravel it into three channels, or layers: red, green, and blue. A three-chip camera has full-resolution layers for each of the three primary colors from the get-go. That is, unless it uses pixel shifting. Then you're back to something like debayering.

But three-chip cameras are incompatible with all the still camera and cinema lenses that we're all wild about. It would have to have TV-standard-size chips (1/3, 1/2, 2/3) to use any lenses in the marketplace. Otherwise, it would have to come with its own lenses. It also can be argued that the three-chip design is a little wasteful.

Another way to go about it is to use a single sensor, but not in the Bayer pattern, but in the Q67 pattern.
 
Last edited:
One small correction: 960x540 color is 4:2:0, not 4:1:1. I do t think any HD format uses 4:1:1 but if they did it would be 480x1080.
 
combatentropy said:
A major part of compression is looking for common blocks of color, but as nyvz said, the staggered pattern of the Bayer sensor guarantees that there will be no block of the same shade bigger than one pixel. I'm sure you could feed this into an AVC compressor, but it would be woefully inefficient.
Click to expand...

But that'd be an issue for a wavelet too, right? Since H264/AVC is a block based optical flow technology, wouldn't it actually do relatively better in that regard compared with a wavelet which typically smooths over pixel variations? In fact if I recall correctly, Red saves the red, green and blue pixels to different images in the codec for that reason. It still doesn't seem like there's anything innate that prevents a raw image from using a particular type of compression...whether the image is YUV, RGB or bayer doesn't really seem that important. YUV isn't essential to how H264/AVC work...H264/AVC's just a type of optical flow compression, and you can do that on any moving image regardless of how it manifests itself.
 
I think discussing compression of RAW hinges on one particular point - quality.

People who want RAW want to shoot it because of the quality it offers over typical video codecs. Quality which is inherit to the 1:1 pixel data of "True RAW" and the ability to adjust the image so much and so precisely in post.

If you take RAW and compress it with some other codec, you are doing, to an extent, what every video camera already does. It takes the RAW data off the sensor and compresses it in a rather lossy form (which often includes downscaling and so on to generate a useful image in a video format). To get away from that, you have to create a form of compression which works with the RAW file and leaves the color space and gamma space up to later interpretation. As has been said before, traditional video codecs need that information present in order to do what they do. Otherwise you just end up with a black and white video with no color or gamma metadata - not what we are looking for.

The reason REDCODE is such a powerful codec is because it is (at least very very close to) visually lossless and, at some compression levels, mathematically lossless (though I don't believe those levels are publicly available yet). And in doing it's image compression, it doesn't bake in the color and gamma. So it leaves you with a pristine image that hasn't been "locked" by in-camera color and gamma processing.

Now, Canon is already doing a form of compressed RAW. mRAW and sRAW are available on their DSLRs as a form of RAW still image compression that demosaics and downscales the image, but leaves color and gamma open to the user, resulting in a significantly smaller file. But this throws away any control over the demosaic algorithm.
 
H264 can be mathematically lossless as well...it just uses a different way of compressing the data. Once uncompressed in post there isn't anything different from the data than if you used a wavelet compression.

Now I assume in practical lossy use wavelet's produce better results than H264, but there shouldn't be anything that makes it impossible to use H264.


Also, I know we're all pretty visual people obviously, but keep in mind that to the computer nothing is a picture. It's all just data. And as such, a matrix of raw pixel readings from a bayer sensor isn't significantly different to a YUV image. The important thing to an H264 type codec is that it can find patterns in the data (especially temporally using optical flow techniques).
 
You must log in or register to reply here.
Back
Top