Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

R3D 2 R3D

That would be nice, but I think the plan is to save to "something special" as Graeme described the file format that drives the Red Ray to me at NAB. Who knows?
 
"Something special" would be perfect if it's just the R3D raw as it is wrapped in something else.
Hope it comes soon.
 
Anybody else? Maybe from Red? Need to plan shipments to Getty.
Thanks
 
Paolo Tinari said:
Will it ever be possible to save to R3D?
Click to expand...

Paolo - question is save what to R3D? As R3D is a proprietary format, you cannot transcode other video files to R3D. You can only read R3D files that are recorded in RED cameras. Lim
 
Hi Tai,
i would like to trim R3D clips
 
Paolo Tinari said:
Hi Tai,
i would like to trim R3D clips
Click to expand...

Paolo, not that I know of at the moment whereby someone comes up with a tool to directly cut R3D file natively and saved the edited R3D without re-rendering. You can trim "R3D" with the various Editing software like FCP and Adobe Premier. But you have to render the edited "R3D" files to non-R3D formats eg Quicktime formats, DPX or TIFF - Lim
 
Tai Wah Lim said:
Paolo - question is save what to R3D? As R3D is a proprietary format, you cannot transcode other video files to R3D. You can only read R3D files that are recorded in RED cameras. Lim
Click to expand...
Tai,

This is not necessarily true. R3D is just a common modern format once you decrypt it (I will refrain from letting the cat out of the bag). What makes it unique is it's encrypted making it impossible to use custom debayering algorithms on it unless you brute force it. We knew that before there was even an SDK and it's not exactly a secret any more what R3D really is.

I have an idea why they did this; the R1 has both high end consumer and professional applications so there's more than ample opportunity for things to go badly sideways with an all new workflow, but that's just me speculating.

I'm quite sure you can imagine, being in Red's position, the nightmare support would have? It opens up a myriad of opportunities for people to fubar their footage that would reflect quite poorly on the camera. I would however consider a two tiered SDK program and open that up to certain parties.

More to the point of this thread, I don't think R3D would be a sensible archiving format. It's suited as an acquisition format but not an interchange format. The Academy IIF format will likely address these requirements more directly.

You could do linear DPX files at 16 bit. Not exactly small, but it's probably the best understood at this point.

J
 
Trimming R3D files is possible. Until RED provides the functionality though, it will probably cost you some hard cash in internal development or consulting costs.

As for saving things to R3D. Jonathan is correct. There is little point to rendering stuff back out to R3D files. For starters, you'd have to convert your RGB images back to a bayer-pattern image, which would not be a smart thing to do.

If you want a size/feature comparable intermediate format, you should probably look strongly at the Cineform line of codecs, and they are both based on similar technologies, and I believe can carry the bit depth and meta data from the original R3D material.
 
Kyle Mallory said:
If you want a size/feature comparable intermediate format, you should probably look strongly at the Cineform line of codecs, and they are both based on similar technologies, and I believe can carry the bit depth and meta data from the original R3D material.
Click to expand...

What I am assuming here is that you want to store graded footage in it's completed state.

Like R3D, Cineform (as Kyle suggests) uses jpg2000 and is a good choice, it supports at least 12 bit and you can even do chroma interpolation if you have cheezy source like 4:2:0 (although with your red footage it's not necessary). Storing the finished project in RGB is a really good thing. That's what makes the Cineform option so attractive.

Cineform is not free (but it's not that expensive) so if that's a consideration you should probably just go with a frame based archiving option like exr or dpx.
 
The purpose is to submit to Getty Images. They dont consider Cineform (which would be an amazing choice because of its being so crossplatform. It's not a matter of quality because they accept Prores which is almost the same). They accept dpx, of course, but i want to save me days of rendering as i have a lot of clips and would love to save the raw nature. Best thing is to send R3D (they CC themselves on Scratch) but i would love just to trim the clip i'm going to submit and not the whole "show".

I think that its time to think Redrocket
 
Paolo Tinari said:
The purpose is to submit to Getty Images. They dont consider Cineform (which would be an amazing choice because of its being so crossplatform. It's not a matter of quality because they accept Prores which is almost the same). They accept dpx, of course, but i want to save me days of rendering as i have a lot of clips and would love to save the raw nature. Best thing is to send R3D (they CC themselves on Scratch) but i would love just to trim the clip i'm going to submit and not the whole "show".

I think that its time to think Redrocket
Click to expand...

There is a feature request in for the SDK, i.e. to allow R3D's to be trimmed and edited (for instance modifying the audio data or merge audio into R3D, etc. from external recording devices during post to make editorial's life easier).

It was a "coming soon" feature but I haven't heard any word on there being any progress.

A LOT of people want this but the simple fact is the wheel's just not squeaky enough yet.

Maybe you should jump on the bandwagon and call up the guys like Stuart and add your voice to the list of people who need this.

Your reason is just as good as a lot of the others I have heard, plus you have a justifiable business requirement for that feature (which is only necessary because they encrypt the datastream btw).

I cannot think of another single vendor that locks you out of trimming camera source footage like this. It's kind of a minor irritation point that flares into full rash every so often for a lot of users.

J
 
I never test but Clipfinder can save to R3D.
 
JonathanF said:
Tai,

This is not necessarily true. R3D is just a common modern format once you decrypt it (I will refrain from letting the cat out of the bag). What makes it unique is it's encrypted making it impossible to use custom debayering algorithms on it unless you brute force it. We knew that before there was even an SDK and it's not exactly a secret any more what R3D really is.

I have an idea why they did this; the R1 has both high end consumer and professional applications so there's more than ample opportunity for things to go badly sideways with an all new workflow, but that's just me speculating.

I'm quite sure you can imagine, being in Red's position, the nightmare support would have? It opens up a myriad of opportunities for people to fubar their footage that would reflect quite poorly on the camera. I would however consider a two tiered SDK program and open that up to certain parties.

More to the point of this thread, I don't think R3D would be a sensible archiving format. It's suited as an acquisition format but not an interchange format. The Academy IIF format will likely address these requirements more directly.

You could do linear DPX files at 16 bit. Not exactly small, but it's probably the best understood at this point.

J
Click to expand...

Jonathan, as with any codec, it can be hacked. As with my follow-up answer to Paola, I do not doubt if anyone with sufficient technical knowledge will be able to do that. Just that RED as you said correctly encrypt their encoding process. Did not looked at RED SDK yet, but I am sure it is only for decoding their .r3d format. Just want to answer Paola simply, triming .r3d file and not re-rendering on native RED .r3d file at the moment is not possible. Lim
 
JonathanF said:
Tai,

Yeah I know, been there... I know a few people who have hacked the codec, it's not rocket science. I think the encryption is more to keep the idiots at bay. Honestly I don't blame Red one bit for doing it.

J
Click to expand...

I have a compression expert friend trying to reverse engineer the b20 format. From what he's done so far, he says it's not encrypted and not a typical j2k stream either. It appears to him that the compression has been evolving through the builds.

I wonder if that's why we don't have a trimmer yet.
 
Thanks

Thanks

Thanks for this thread.

For the first time I shot something under unpredictable conditions and had to just let the camera run. So of course I have a lot of useless crap footage.

I'd been digging around in the various RED tools to try to find a simple "I only need this ten seconds, the rest is five minutes of absolute crap and I don't want to have to store it." tool and for the life of me couldn't find this functionality.

:beatdeadhorse5:

Just add my voice to the chorus. It would be great not to have to store mostly junk R3D's so that they can be relinked to for finishing. I really don't need anything else, just a very simple trim tool.

Steve <--- stops looking, starts rendering
 
I do single take nature shots that fill up a whole red drive so what I do is just remove the 2GB chunks I need. If you pull out the first r3d into another folder you can figure out on average how many frames are in one 2gb chunk.
 
This might sound like a stupid question, but here we go:

If you take only one of the R3Ds from a long sequence, will it work independently of the rest? Im going to give it a crack and see.
 
You must log in or register to reply here.
Back
Top