Son of "Red Bull" - "Red Facts"

[Graeme Nattress]

REDCODE RAW is 12bit throughout. No, it doesn't drop to 10bit at any stage. I thought I'd made that clear in my earlier posting.

It's a wavelet based codec, so no, it doesn't divide the image up into macroblocks like MPEG codecs.

I think "Bull" refers to the article, rather than the camera...

If you're thinking on a camera to film a feature film, I'd suggest using film. However, if you're looking for a digital cinema camera for making a movie, then I think you should probably test it yourself, and screen the results in an environment that would allow you to best assess the image quality based upon your own needs and priorities.

Compression is not something you can assign a number to and say "good, bad or indifferent" - you must eyeball it.

Graeme

 

[Stuart English]

Questions

Questions

1. Is the color space compressed below 12bit, or 10bit at some stage to achieve a higher efficiency?

2. Does the compression algorithm group areas of the image into sections like MPEG does?

As far as the images speaking "for themselves" I haven't seen any images projected on the big screen. The first article ("Red Bull") evidently addresses this very issue of the images speaking for themselves -- not in a good way.

There Graeme beat me to this -


1. No it stays at 12 bits all the way. Most (all?) other camera / recorder systems are 10-bit (or even 8-bit)

2. No, each frame stands on its own merits. No LONG GOP or GOV processing here..and no grouping of pixels into blocks either.

3. You didn't ask this one, but the camera records full bandwidth i.e all the pixels contained in the original frame, and it also maintains the original color space. Most recorders either reduce the recorded pixel count, or convert to 4:2:2 color space, or both. Only a very few do neither.

As to the image quality statements. We have no visual evidence to comment on what he says he has seen. However there are hundreds of people who have seen RED 4K images on the big screen - at NAB, at IBC, on RED days and in private viewing sessions. I'd be asking as many of those people for their opinions before I took as gospel one negative view.

 

[Joe G.]

Okay, how about the other points:

1. Others have mentioned how a "RedCode72" would be welcome (less compression ratio/higher bitrate). Is that in the pipeline?

2. Where would the improvements be evident?

3. Where can improvements be noticed between RedCode28 to RedCode36?

And 4. How does "wavelet" compression work?

Keep in mind, I've been on your side, assuming that the camera was not deficient in these crucial areas. The color space remaining at 12 bit throughout directly refutes one of Rian Johnson's claims. That's good. This leads to what he did in post production if he isn't happy with the colors.

HOWEVER(2), I did see some problems in that helicopter/snowboarding footage posted here. The 2k imaging was problematic at certain points. I would ask you to have a look at the compression problems clearly visible there.

Has this problem been solved with a later firmware build???

 

[Andrew Walker]

AFAIK, Rian hasn't shot any footage on RED....

Graeme

So this ding dong hasn't shot a frame of footage on the Red camera and he launched this attack against the camera. Red should never have to answer to anyone this stupid.

 

[Stuart English]

Compression

Compression

I did see some problems in that helicopter/snowboarding footage posted here. The 2k imaging was problematic at certain points. I would ask you to have a look at the compression problems clearly visible there.

Explain please? Which footage is that / where is that clip to be found?

As for Wavelets I'd recommend Wikipedia as a starting place. Its quite a simple idea, but the devil (as always) is in the details.

As for data rates, don't be sucked in by bigger numbers....whatever minimum data rate that delivers visually lossless images is the "right" value.

 

[Joe G.]

-

-

"As for data rates, don't be sucked in by bigger numbers....whatever minimum data rate that delivers visually lossless images is the "right" value."

That's the question. Is it visually lossless?

The challenge by Johnson is that you are NOT meeting this threshold. He claims that the data rate is the smoking gun.

How do we know that 12:1, 24:1 compression or more is not sacrificing image quality?

I found the helicopter footage. It is of course compressed on vimeo. So, I can't be sure where the noise came in. Right around the 10 second mark the yellow jacket gets trippy:

http://www.vimeo.com/1048531

 

[Steve Sherrick]

"As for data rates, don't be sucked in by bigger numbers....whatever minimum data rate that delivers visually lossless images is the "right" value."

That's the question. Is it visually lossless?

The challenge by Johnson is that you are NOT meeting this threshold. He claims that the data rate is the smoking gun.

How do we know that 12:1, 24:1 compression or more is not sacrificing image quality?

I found the helicopter footage. It is of course compressed on vimeo. So, I can't be sure where the noise came in. Right around the 10 second mark the yellow jacket gets trippy:

http://www.vimeo.com/1048531

Okay, this is where this conversation goes south. We can't analyze footage from Vimeo or any other web viewing. Seriously guys, this is only going to fuel misconceptions. I'm not saying Red footage is infallable. But, we have to base our judgements on properly displayed footage. That's the only way you really know what the footage looks like and what problems it may or may not have. I believe this may have been the problem with Rian's analysis of the footage. How exactly was it processed and then displayed. If there are issues with your footage, the best bet is to get in touch with Red and see about getting them files. That will help them determine if there is in fact a problem. But making judgements based on web movies is a big mistake I would think.

 

[Kenn Michael]

Agreed. Until you're watching properly posted footage in a DI theater or a calibrated HD monitor, we can't make any real judgement on footage.

 

[Stuart English]

Image Quality

Image Quality

In making my educated decision on which camera to film a feature film, I want to know what risk there is in RedCode showing compression artifacts and what they will look like. That's the bottom line.

So back to this point. There are several people on this board that have shot features on RED -

- maybe its best to contact them to ask their opinion on image quality?

Although the math is the math and what we engineers use to point to reality, the actual images are what artists trust.

 

[Pawel Achtel]

Others have mentioned how a "RedCode72" would be welcome (less compression ratio/higher bitrate). Is that in the pipeline? Where would the improvements be evident?

Where can improvements be noticed between RedCode28 to RedCode36?

I realize that this is probably a very sensitive issue, bordering on trade secrets, but this challenge is not trivial or meaningless. Less compressed options are available to filmmakers, including some that are completely uncompressed.

In making my educated decision on which camera to film a feature film, I want to know what risk there is in RedCode showing compression artifacts and what they will look like. That's the bottom line.

In footage that I shot there was no humanly visible artefacts or difference between RedCode28 and RedCode36. Wavelet compression of RAW data is MUCH better than block-based DCT performed on RGB or YUV output, with often downsampled chroma (4:2:2) or heavily reduced bit rate (say, 50Mbps) or reduced spacial resolution (like HDCAM)or all of these things: apples and oranges. Even uncompressed RGB 4:4:4 images recorded with HDCAM SR do not compare to 12-bit RedCode RAW.

By recording at higher bit rates than currently available you would have already reached a point of diminishing returns. RedCode72 (72MBps = 576Mbps) would make sense only for higher spacial or/and temporal resolutions.

There have been dozens of tests posted on this forum and, unless you are doing something wrong, like shooting away from native ISO by 5 stops, the images are as clean as best images from the best DSLRs shot in uncompressed RAW. The RedCode compression is, in my opinion, visually lossless. I suggest that you read this comparison test and see if you like the results:

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

 

[Chris Oben]

It seems like Rian Johnson's article has sparked quite a few query's from within the ranks of REDUser which i would say is turning out to be a good thing. This discussion prepares us all when facing similar challenges on a day to day basis with producers who are just coming to understand the technology. I have been dialoguing with ASC President Steven Poster who pointed out Rian's revised article and suggested that I might find it disappointing. Actually I found Rian's article to be a fantastic read. I was not all disappointed. I am always more interested in dispelling conjecture and misconception than regurgitating supposed fact. I have built my career on determining first-hand the actualities of ‘real world results’ both good and bad. So much of what cinematographers do on set relies on our ability to control the environment to the point where it fits into the given shooting format. It is therefore prudent to understand the parameters of that format thoroughly. One of my personal statements is to “test it ‘til it fails” as any other test never shows the edges of usability. Or in other words “where the sweet spot falls apart”. It seems that increasingly I am being approached by producers to help them wade through the hype of all the techno-speak: log, linear, 4K, 2K, long GOP, 8 bit, 10 bit, 12 bit 16 bit 42 bit . . . . so to have the opportunity to add my two cents is welcomed.

My complete response is blogged here:

http://chrisoben.blogspot.com/2008/09/red-raves-rants-red-bull.html

but the general idea is that while Rian Johnson’s “Red-Bull’ article does clearly refute some of the marketing jargon responsible for Red’s current moment in the limelight, the article is written in a form and with a tone that unfortunately doesn’t do much for the author’s credibility. It comes off as a personal rant rather than as a level-headed and thoroughly researched argument. I can see from his website that he likes to stir things up which is apparently what he’s doing here.

Here are two things that are keeping the Red system on my radar. Firstly, I can honestly say that I have never seen better looking video on-set or screened in 2K than I have from the Red system. I am speaking here of the live 720 preview out directly from the camera . . . of course it could be due as well to the fact that the cinematographers I have had the opportunity to work with using the Red include Gale Tattersall (House) and Amir Mokri (National Treasure II, Lord of War). Secondly, in my opinion the integrated controls and operational functionality of the Red camera system rival the best available in HD acquisition.

When the images on the on-set monitors are delivering crisp, clear, natural colors (or real-time corrected as per the D.P. and/or the director’s wishes) it begets a confidence on set which allows the creatives involved (directorial, camera and art dept) further freedom to adapt and refine their work depending on the situation and variables of that moment. In other words the technology becomes secondary to the creative process. At its best the camera simply does its job without becoming obtrusive. Just like the good old days of film except . . . one can truly see what one will ultimately get . . .

For too long shooting HD has meant intervention from the DIT and assistant team while problems are solved in order to get to the point of looking at an image to begin refining it. In my on-set experience I have found that, unlike other more expensive cameras, the Red offers both a WYSIWYG on set preview and film-camera like functionality to the assistants and operators,without any compromise. Neither the Sony F23, Panavision Genesis, Thomson Viper, Panasonic Varicam, Sony F900 or any other 1080 HD camera (excepting the Arri D20/21) gives lookaround to the operator and the director! Having ‘lookaround’ is something that should be a basic requirement on any ‘professional’ acquisition camera. It just makes sense to see what you are framing out – just like we have done for decades in film. Additionally, neither the Genesis nor the F23 offer a realtime corrected output for a subjectively pleasing colour preview without the rental of additional equipment like the Genesis Display Processor, LUTher Box or a Cinetal display with LUT support. All in all, the Red One achieves unprecedented functionality and image quality in a camera body which is one tenth the price of the F23.

Discreet DOF is part of the director’s toolset that is becoming even more important to utilize with many short form projects being viewed in massive numbers on YouTube. The 1” sensors of the RED and the Genesis, in the hands of a skilled camera person can deliver wonderful images with beautifully discreet depth of field. Unfortunately I’ve had a number of conversations with producers who are of the belief that an HVX200 with its 1/3” CCD’s will deliver perfectly ‘adequate’ imagery for web-based delivery. It’s a cheap rental. I hear things like, “It’s just for the web anyway." . . . I suppose it would be adequate if your story is not necessarily a visual one and it’s acceptable to have everything equally soft focused. I think generally though most producers agree that, like a still photographer, the higher the resolution of the original the better the final product will be . . . and in the case of video – allowing the cinematographer and director the tools to direct an audiences attention via selected focus is even more important than ever.

This is a link to an excellent response by Chris Kenney of ‘Nice Dissolve’ to Rian Johnson’s ‘revised RED rant’:

http://www.indie4k.com/archives/96

and here is part two dealing with compression:

http://www.indie4k.com/archives/97

– his arguments all seem sound except perhaps his belief that RED is perfectly suitable for theatrical projection . . . which is a topic better saved for a night with more hours left in it . . .

 

[Pawel Achtel]

Chris Kenney's blogs are very well written.

 

[Steve Sherrick]

– his arguments all seem sound except perhaps his belief that RED is perfectly suitable for theatrical projection . . . which is a topic better saved for a night with more hours left in it . . .

Curious about this one Chris. I've seen Red projects projected in a theatre and it looks great to me.

 

[Kenn Michael]

Yep, same here. Seen stuff on very big screens and the footage looked fantastic.

 

[Jason Wingrove]

OK this got some blood pumping..(probably exactly what Rian was hoping for)
So....We just just finished a round table podcast on REDCENTRE on it...

Myself & Mike Seymour from FXGuide, John Flowers (from life zero podcast) & Stu Machwitz from the Orphanage and his excellent ProLost.com blog

I must say it was a great conversation covering ALL the plusses & Minuses of RED from all angles.. and of course discussing Rians RED Facts Blog entry.

Rian was of course invited to be involved but did not respond.
Please subscribe to the Podcast as we have 2 new eps up just this week and
as always we LOVE your feedback via red@fxguide.com

Thanks for listening



Please listen here:
http://www.fxguide.com/redcentre

or subscribe in itunes:
http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=277775280

 

[Steve Sherrick]

OK this got some blood pumping..(probably exactly what Rian was hoping for)
So....We just just finished a round table podcast on REDCENTRE on it...

Myself & Mike Seymour from FXGuide, John Flowers (from life zero podcast) & Stu Machwitz from the Orphanage and his excellent ProLost.com blog

I must say it was a great conversation covering ALL the plusses & Minuses of RED from all angles.. and of course discussing Rians RED Facts Blog entry.

Rian was of course invited to be involved but did not respond.
Please subscribe to the Podcast as we have 2 new eps up just this week and
as always we LOVE your feedback via red@fxguide.com

Thanks for listening



Please listen here:
http://www.fxguide.com/redcentre

or subscribe in itunes:
http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=277775280

Good job guys.

It was great having a few different perspectives.

Interesting to hear the experiences of using the cameras too. All valid opinions. Too bad Rian wasn't involved. He has commented on his forum a few times about all of this, and obviously with the second draft he is well aware of the discussion going on. I think your roundtable is a great place to sort these things out.

 

[Joe G.]

podcast

podcast

The only real new information I got from that podcast was Stu M.'s take on Panalog vs. 12 bit linear.

According to Stu M., the Genesis blows away the Red One because the color space is logarithmic (something I brought up here once before but never got a decent explanation) vs. the Red's "linear" (Raw) color space.

Stu said that Red delivers only about 2 stops of highlights, while Panavision delivers about 5 STOPS of highlights ("above 18% grey").

Since he'd done an article and tested this previously, I figure the Red techs need to readdress this issue.

I could not see much in Stu's Prolost test photographs on the web. The only thing plainly visible was that film was superior to both.

However, there appears to be more to the story if Panalog gives 3 extra f-stops of latitude. Does it? Does it accomplish this by using 14 bits from the sensor as opposed to Red's 12 bits?

1) Is there a way to increase Red's dynamic range with a new logarithmic color space scheme?

2) Will EPIC have such a scheme?

3) Is 12 bit linear actually inferior to 10 bit log (as Stu has now claimed)?

Since these criticisms are coming from a highly technical and experienced post production supervisor, I would expect serious answers.

 

[Stu Maschwitz]

You can extract a log image from an R3D easily enough. The reason for Genesis's lovely five stops over 18% gray is that Panalog has exposure recommendations that put 18% gray at five stops below saturation. The brilliance of Panalog is that it is a tested system designed for film output, not just a color space designed to near-losslessly pack the data into a 10-bit file.

You could shoot RED at five stops below saturation, but I haven't seen images that make me think that would be a safe thing to do as a matter of course. Maybe with the latest builds it's less risky. I have not tested this.

The two stops thing is if you follow the Rec709 exposure guidelines. I wrote about that here.

What RED needs is a color space designed and tested for filmout, with meaningful exposure guidelines that leave a ton of room for highlights without giving you muck at exposure. RED Log would work fine for this, we just need the latitude and the documentation.

I have every confidence that RED can get there. When I talk about the brilliance of Panalog it is in part an encouragement to RED to emulate what's great about it.

-Stu

 

[Casey Green]

Here is how Rian's article starts:

"This is a second draft of this article. As we were ammending the first draft to address new arguments, we found that it was becoming mired in what could be an endless back and forth over technical definitions and minutia. So we're going to zoom back, take a breath, and refocus this piece on what was meant to be the original point of it in the first place..."

Everyone knows you Zoom In to Refocus! j/k

 

[Dj Joofa]

And 4. How does "wavelet" compression work?

Hi Mail4Joeg,

Doesn't matter the compression is wavelet, DCT, etc., because we just want to remove redundancy. If you understand the following, then trust me you would have understood half of compression methodology:

Given an image suppose you plot each neighboring pairs of pixels on a graph. Say pairs of pixels 1 and 2, pixels 3 and 4, pixels 5 and 6, ..., and so on -- pixel 1 on x-axis and pixel 2 on y axis, pixel 3 on x-axis and pixel 4 on y-axis, and so on. Since natural images have mostly nearly the same value for neighboring pixels you would see that your graph is scattered along a diagonal line between x-axis and y-axis (i.e., a line at a 45 degree angle).

Now if I ask you to represent pixels and 1 and 2 with a single number, then naturally the best choice (in some sense) is to pick the the closest number on that diagonal line and replace pixels and 1 and 2 with that number. Do the same for all pairs (pixels 3 and 4, pixels 5 and 6, ..., and so on).

Actually, the value you picked for each pair on the diagonal line represents the average value of those two pixels. This number has most of the information of the two pixels and by replacing both pixels with the average value you have incurred a small loss but not a whole lot. If you wanted no loss then you could also keep the difference of those two numbers, and from the average and difference, you could derive the actual numbers for each pixel pairs.

If we just keep one value (of course the average, and not the difference, as average has most information in our case), then we have done compression, because for each pixel pair of 2 numbers we have reduced it to 1 number and reduced the number of values to store in the whole image by half.

However, if we are going to keep both average and difference values then it is of not much use for compression because we come back to the same number of stored values (though different numbers). But, if you look closely, since the most information is concentrated in the average values, then for some pixels we can keep the difference if it is big, and for many pixels, since it is small, we may throw it away. Now we have somewhere between half and full numbers of stored value, but the image with this sort of compression looks very good.

And, that is exactly the basis of typical compression applied to images, whether wavelet, DCT, etc. In fact the first basis function in DCT is the average value, same for wavelet (though the average may be a smoothed function and not a straight average.) and the difference value may be chopped up into a number of sets so that we can decide which sets to keep and which to throw away.

And we accomplish that by considering more pixels in one go than 2, typically 8x8 for DCT, and full image for wavelet.