Creating R3D files from RGB images - when?

[Axel Mertes]

Hi Jim, RED Team,

I have a question that *may* sound irritating in first place, but I do see a real use for it:

Do you consider to create (kind of artificial) RED CODE RAW images from RGB footage?

With the upcoming RED RAY system as a distribution solution for us film makers, its a great option to spread 4K RAW playback files. But for most of us its *extremely* unlikely to spread our source RAW footage. Instead, its more likely we start to grade it, add VFX and titles etc. We do many processing steps that would - at best - end up with a 4K RGB sequence. Playing 4K RGB sounds not very likely to happen via RED RAY, or is that on the list too? Wouldn't that need 3 times more disk space anyway?

So I think it is a valid idea to consider to convert back from 4K RGB to 4K RAW with a final project just for distribution purposes. It would mean RED CODE RAW would be end-to-end. Right now its only ingest. RAW saves 1/3 disk space upfront. The rest of the compression is comparably mild. I am not sure if I would prefer kind of H.264 compression scheme over RAW deBayered.

Or are you working on a GOP based RED CODE RGB 4K or something like this?

How would be the distribution path for Indy film makers - how can they share composed and manipulated 4K movies they made? Hopefully we will not be stuck with HD or 2K then...

Would be interesting to read some comments here

Thanks in advance,
Axel

 

[Jeff Kilgroe]

There was talk of a REDCODE RGB format, way back when the RED One was still spec'd to record RGB modes.

I can definitely see a use for a REDCODE RGB codec for editing and mastering.

While we're at it... I'll bring up again some suggestions from the past. It would sure be nice to have a way to trim R3D clips and to be able to add some kind of digital watermark or copyright to an R3D.

 

[Zach Nelson]

I'd love to write a plugin to do this.... is the R3D format defined in the SDK perhaps?

 

[Joseph Ward]

I thought RED was going to have RGB for a future option?

 

[KStephens]

I think the primary question being asked here is whether or not it will be possible to compress to Redcode RAW (R3D) format.

As for editing (trimming clips), since Redcode doesn't use interframe compression, it shouldn't be technically difficult to do the process. The SDK could potentially offer a way to write select frames without decompressing (and therefore re-compressing). I haven't seen the SDK, though.

 

[Mike Zinner]

Using any RAW format as an intermediate codec would be a step in the wrong direction as it is an acquisition format. Let me compare this to the CineForm stuff. They have CineForm RAW as the starting point. But as soon as you need to render something, you transparently switch to CineForm Intermediate.

And CineForm Intermediate is what I exchange with other studios. As the CineForm decoder is freeware, everybody can read my files, cross platform. But only people with licenses can encode.

So, if there would be a cross platform, high quality, visually lossless REDCODE RGB codec, with free encoders and decoders via the SDK, that would be great! But I doubt there will be, because the development of such a beast is expensive and there would be no direct benefit for RED. Or would there be one?

I'd rather see Adobe releasing an intermediate codec like that, similar to what Apple did with the ProRes 422 codec.

 

[KStephens]

Using any RAW format as an intermediate codec would be a step in the wrong direction as it is an acquisition format. Let me compare this to the CineForm stuff. They have CineForm RAW as the starting point. But as soon as you need to render something, you transparently switch to CineForm Intermediate.

And CineForm Intermediate is what I exchange with other studios. As the CineForm decoder is freeware, everybody can read my files, cross platform. But only people with licenses can encode.

So, if there would be a cross platform, high quality, visually lossless REDCODE RGB codec, with free encoders and decoders via the SDK, that would be great! But I doubt there will be, because the development of such a beast is expensive and there would be no direct benefit for RED. Or would there be one?

I'd rather see Adobe releasing an intermediate codec like that, similar to what Apple did with the ProRes 422 codec.

I agree that Redcode RAW is best as an acquisition format. I'm also just trying to clarify the question here. I'm quite certain the original poster was referring to using Redcode RAW as a final format, not as an intermediate. In other words, the original question was:

If I edit, grade and finalise my footage and want to save it in Redcode RAW, will that ever be possible?

An alternative for now might be to use a Motion JPEG-2000 CoDec for final output.

 

[Jeff Kilgroe]

REDCODE RAW as an editing or indermediate format makes little to no sense. Keep in mind that it is RAW bayer data anyway and not specific image data. So how do you take a processed, visible image in YCrCb, RGB, etc.. and translate that to a bayer-data approximation with no specific color info, etc..? Saving back to REDCODE RAW, other than simple trims, cuts, extractions between frames, will most likely never be possible. This trimming ability would be very handy for distributing R3D RAW files though.

That's where an RGB version of REDCODE comes in. It would make sense as an editing / intermediate codec. I doubt at this point there is much logic to make the camera record RGB natively. I know a lot of people still want the camera to output 1080p live feed over the HD-SDI and HDMI -- RGB shooting modes may help facilitate this on the camera, as has been mentioned. But when it comes to working with the actual footage files, I'd take RAW as we have it now over an in-camera RGB any day.

Lightman is right about being able to trim R3D clips. AFAIK, R3D stores each frame discretely anyway. Perhaps the RED SDK will someday give us such abilities and even access to the RAW data in some way.

I'd rather see Adobe releasing an intermediate codec like that, similar to what Apple did with the ProRes 422 codec.

That's what Adobe's Open CinemaDNG is all about, but supposedly much more powerful.

 

[KStephens]

REDCODE RAW as an editing or indermediate format makes little to no sense. Keep in mind that it is RAW bayer data anyway and not specific image data. So how do you take a processed, visible image in YCrCb, RGB, etc.. and translate that to a bayer-data approximation with no specific color info, etc..? Saving back to REDCODE RAW, other than simple trims, cuts, extractions between frames, will most likely never be possible. This trimming ability would be very handy for distributing R3D RAW files though.

Again, I'd like to point out that the original poster was asking about a final/archival format and not an intermediate format. In either case, I would agree that Redcode RAW doesn't make sense except as an acquisition format.

What the original poster is looking for is the best CoDec to save the final product and is not interested in sharing the original, untreated footage. Obviously, as Redcode RAW is a good CoDec and provides high quality with a low data-rate, it's tempting to wonder if it would be worthwhile to store a finished product in it.

The Bayer image data in Redcode RAW is definitely "specific image data". Bayer is RGB-based. It contains a subset of the full data for the RGB channels. The hard part is interpolating from Bayer-RGB to RGB. That step is both a science and an art. On the other hand, it's a very simple procedure to arrive at Bayer-patterned RGB from RGB data. However, it would not make sense to do so.

 

[Graeme Nattress]

It is not simple to make a bayer image from RGB data though. Well, simple yes, but to introduce the proper filtering to avoid aliasing on the demosaicing, is very tricky. And yes, not really worth the bother...

Graeme

 

[KStephens]

It is not simple to make a bayer image from RGB data though. Well, simple yes, but to introduce the proper filtering to avoid aliasing on the demosaicing, is very tricky. And yes, not really worth the bother...

Graeme

Exactly

 

[Axel Mertes]

I understand the hesitation to consider RAW a distribution format. But given the amount of info that is lost in GOP based compression with MPEG etc. formats, its a valid idea to use a Bayer pattern for reducing the data in first place. We know the results, we use it every day in our RED cameras.

Further, as some mentioned, there is no RGB RED CODE codec available yet (who knows what they are working on right now?) BUT we do know there is RED CODE and its working. We all are amazed by the quality level we see AFTER decompressing/deBayering those RED CODE images. And its fantastic results.

So why not consider to convert back to RAW?
I do like the plan from Adobe for making a "DNG" format - but hey - as the name states its the negative replacement, its not the distribution.

Clearly I can imagine that an GOP based layer ABOVE RED CODE (so no more I-frame only compression style) would allow even stronger data reduction with still good quality. But is that really coming?
Who is developing that?
Would RED RAY ever play Adobe DNG?
We do know that RED RAY is planned to play RED RAW. At least. And I do know that I want to show my final results with it - not my source footage (at least not alone my source footage).

Thats why I am asking this.

Creating an artifical RAW file is probably already existing code. I know that many poeple who worked on deBayer algorythms use RGB images, convert them to artificial Bayer pattern images and deBayer them to compare deBayered result with original RGB. Its a good approach to see how close your algorythm can get to the "target" you aim at.

Axel

 

[Graeme Nattress]

Yes, there's already existing code And although Bayer works great for cameras, I don't think it's the best thing for compression. I have other stuff for that

Graeme

 

[filip kovcin]

...
Creating an artifical RAW file is probably already existing code. I know that many poeple who worked on deBayer algorythms use RGB images, convert them to artificial Bayer pattern images and deBayer them to compare deBayered result with original RGB. Its a good approach to see how close your algorythm can get to the "target" you aim at.

Axel

i am wondering how that red raw was tested BEFORE the camera even existed? i am sure it was there before the camera and the sensor. for me it just looks logical, but i am not connected with red team so i cannot say for sure.

filip

 

[filip kovcin]

a few minutes later

a few minutes later

hm...

well, maybe sensor existed before... but not sure (again), so the red path was eiter option A or B

A) sensor is existing and after testing etc. red raw was introduced

or

B) red raw is existing (under other name or not named) and then mysterium sensor was built

filip

 

[Graeme Nattress]

REDCODE was developed using RAW Bayer images from Frankie. And quite frankly, those 4k RAW, uncompressed images were a real pain to deal with.

Graeme

 

[Dj Joofa]

There is no catch 22 here. There is a lot of data and algorithms available for deMosaicing in the research community for quite some time, which of course, can be made available freely in many circumstances. If one needed to test their algorithms, then, even before Red was conceptualized, that should not have been a problem.

Of course, testing algorithms on your hardware is the ultimate goal and the desirable thing to do. But a lack of hardware these days should not be seen as an impediment solely for the reason that the hardware is not developed to a stage where it can generate data.

 

[Michael Thornton]

Creating R3D files from RGB images

There is no image gain in converting analog Bayer pattern (RAW) to digital RGB then R3D, why do it?

Actually it's would be a net lost because of Digital RGB I think.

R3D has a lot more range encode in it.

I don't know the future, but I would rather not go back to the RGB past.

There are a ton of RGB friendly formats already.

R3D is the future.

Just convert it back if you think RGB is better. R3D to any RGB and stay there.

Keep in mind that it's the R3D none RGB that is the revolutions here.

Be very careful of what you ask, you might get it.

My ten cent.

Tek

P. S. The way R3D stored information is no less than genius, and it's the future.

 

[KStephens]

I understand the hesitation to consider RAW a distribution format. But given the amount of info that is lost in GOP based compression with MPEG etc. formats, its a valid idea to use a Bayer pattern for reducing the data in first place. We know the results, we use it every day in our RED cameras.

What you are referring to by "GOP" compression is called interframe compression. Perhaps there will be a Red CoDec for that, but for now, you do have some other options. The problem is that converting from RGB to Bayer-patterned RGB is not worth the hassle, as Graeme wrote. There are other ways of saving space. Would 8-bit colour (RGB24) be enough, if you preserve all the resolution?

 

[Axel Mertes]

To me its simply the fact that there must be an RGB codec available and useable with the RED RAY at the moment its going to ship, otherwise we will find that RED RAY can just be used for playing back RAW camera footage.

Who wants a player just for dailies?

The price tag of this player makes it interesting for showing off final material. So we want to convert our material to something that can be used on the RED RAY.

So if RED tells us there is something coming along (Graeme somehow leaked out some info with "I have other stuff for that ") then I am happy.

So Graeme, back to the point:

"I have other stuff for that "

Tell us more, WHAT other stuff do you have in petto?

Cheers,
Axel