Welcome to our community

Be a part of something great, join today!

  • 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 :)

EASY EDITING RED original FILES

Nathan Buxton:What you want is to be able to edit with the REDCODE codec... which may be in the works in the future but as i said that is not up to RED, its up to the editing software developer.[/QUOTE]

EXACTLY, thank you for your explanation!
This is absolutely what I think would be ideal !
Don't you think so ?
 
Nathan,

To be honest,

I don't even have a camera yet and I am in a good position where I have close ties with a post house. I really just wanted to put that out there so that it's out there.

As for holding my horses... I'm way into chillaxing right now.

Happy holidays

Method
 
oh just fyi "hold your horses" was a general statement. I hope i never come off as abrasive or anything.

And yes, Leon, i agree editing in redcode is what WILL happen eventually (or another codec provided by red)... just takes time to make sure it works right.
 
oh just fyi "hold your horses" was a general statement. I hope i never come off as abrasive or anything.

And yes, Leon, i agree editing in redcode is what WILL happen eventually (or another codec provided by red)... just takes time to make sure it works right.

Good ! Thank you for your patience , I"ll try to be patient too...
 
Sorry but @ Nab 2007 Evin Grant was demonstrating editing of the QuickTime reference files and saying the exact word "easy as DV"

antoine.

Thank you for having excellent memory !
But what I wish is to put the original RED file right into the timeline without loosing its quality so Nathan observed smartly that to do so I am expecting a RED codec identical to the original file and that is not feasible today and
who knows when this will happen ?
Have a nice day.
 
Red have suggested that in the future there may be a version of the Quicktime codec which can decode at the full 4k resolution, with a 'proper' de-Bayer, so this will give you what you are after. Since currently FCP can't work with resolutions higher than 2k, that is the main barrier to working with the original format in the FCP timeline, even if that codec was available. That will no doubt change with time.
 
The problem with the current FCP workflow, for me, is with 2K. (I'll wait for 4K). But now, I want to finish in 2K. If you edit away in FCP with the QT wrappers, and then export DPX, the quality is appalling. You couldn't use it for a film-out in a million years. The solution at present, is that you have to manually go and find the shots you want, put them in RedAlert or Redcine, export as DPX, then bring them into FCP and cut away again until it matches. Keeping track of this is next to impossible on anything other then a commercial. Imagine a feature! So, editing the QT wrappers is easy as anything, but actually getting a complete DPX feature out of this thing is an absolute nightmare (especially if you want to use Color as well). I hope a lot of this will be solved with the Pull-List feature promised for Redcine. If we can edit in FCP, and get an easy output from Redcine, which can then go to FCP/Color, great.
 
One thing I don't see being addressed here is that Redcode is Raw, as in not debayered and without color correction baked in. So if by manipulate Redcode you mean, color correct it, apply effects to it, apply transitions to it, etc etc, then you are missing the main point, that it's an origination format, not a intermediate or delivery format.

If all you want is to cut Redcode, well you can do that today on a Macbook pro via the quicktime proxies, but it will have to be converted to an intermediate or delivery format before you can manipulate it properly.

Unless of course you just want FCP to manipulate metadata, which would be great.

Because I don't think manipulation of Redcode makes any sense, here is what I would like to see instead, support with FCP and Quicktime for switching between proxies without using different quicktime files, and a full quality quicktime wrapper. Upshot: It's essentially FCP with Redalert built in...cut with proxies and then switch to full quality for CC, effects and rendering. In other words, cut Redcode on a Prores (or any other) timeline, and have the system dynamically switch between proxies and full quality depending on the current needs of the editor.

IBloom
 
Projected on FILM

Projected on FILM

ibloom,

I may have missed your point or even misread your post. But my understanding is, there is currently no way to capture selects of the RAW r3d files after you have don an off-line in ProRes or whatever.

If you want to proceed with a film out of your finished project it seems that Scratch is the only way and not everyone wants to be constricted or backed into a corner in his or her post process.

Am i making any sense here? Or am I way out onto left field and need a homing beacon to get back on track :biggrin:

I don't know, someone please clear the dust for me.

Respectfully

Method
 
ibloom,

I may have missed your point or even misread your post. But my understanding is, there is currently no way to capture selects of the RAW r3d files after you have don an off-line in ProRes or whatever.

If you want to proceed with a film out of your finished project it seems that Scratch is the only way and not everyone wants to be constricted or backed into a corner in his or her post process.

Am i making any sense here? Or am I way out onto left field and need a homing beacon to get back on track :biggrin:

I don't know, someone please clear the dust for me.

Respectfully

Method

Scratch is the only way to conform directly from R3D files. Any DI system can be used to conform from DPX or Tiff sequences, which can be generated today by Redcine or RedAlert. Though I admit a high degree of cleverness and some manual work is neccessary. S yes you would need to pull selects yourself before you can conform. For short form this is managable.

Scratch does not even modify R3D, it just has the abillity to pull data directly from R3D with no intermediate format.

I hope this is making sense, I understand why people are interested in trimming R3D, but that is very different from manipulating it. IMHO in it's current state, a raw compressed bayer image, no system should create new R3D and cycle it back into the pipeline, which is what I think they are suggesting. For example, you wouldn't consider rendering titles to bayer pattern, and then debayering them.

R3D is always just a data source, not a destination.

So if the fact is that you want FCP to pull for you, then all you need is a full quality QT wrapper to pull Redcode into another format and FCP support for a 4K format, no real need to ever modify R3D.

IBloom
 
Let's hope when Apple does add 4K support to Quicktime and FCP, that they do a major overhaul of Quicktime. It is still weak in some areas (gamma issues, timecode issues, etc). They need to stabilize their pipelines, for example going from FCP to Color, and they need to fully understand Red, as in don't f#@* it up. Avid is apparently taking some major steps in 2008, and I'd like to see FCP do the same as well.

Steve
 
Red have suggested that in the future there may be a version of the Quicktime codec which can decode at the full 4k resolution, with a 'proper' de-Bayer, so this will give you what you are after. Since currently FCP can't work with resolutions higher than 2k, that is the main barrier to working with the original format in the FCP timeline, even if that codec was available. That will no doubt change with time.

It isn't strictly true even today. Final Cut Pro will let you create a sequence up to 4000x4000 pixels, and can actually be duped into working with higher resolutions by exporting a blank sequence to XML, manually editing the resolution, and re-importing it. Some extremely basic testing (dragging two 4096x2048 stills to a timeline, dropping a cross dissolve between them, and rendering the result out to a QuickTime movie) appears to show that FCP can actually work with footage at this resolution.

I'm not sure I see the point, though. I can't think of any plausible situations in which a movie would benefit from the existence of a 4K deliverable, yet the budget would be so low you'd have to do your final conform using commodity software.
 
The problem with the current FCP workflow, for me, is with 2K. (I'll wait for 4K). But now, I want to finish in 2K. If you edit away in FCP with the QT wrappers, and then export DPX, the quality is appalling. You couldn't use it for a film-out in a million years. The solution at present, is that you have to manually go and find the shots you want, put them in RedAlert or Redcine, export as DPX, then bring them into FCP and cut away again until it matches. Keeping track of this is next to impossible on anything other then a commercial. Imagine a feature! So, editing the QT wrappers is easy as anything, but actually getting a complete DPX feature out of this thing is an absolute nightmare (especially if you want to use Color as well). I hope a lot of this will be solved with the Pull-List feature promised for Redcine. If we can edit in FCP, and get an easy output from Redcine, which can then go to FCP/Color, great.

When you say the quality is poor when exporting the QT wrapers to DPX, what do you mean exactly?

Is it not color matching? Is the image visibly degraded? What are you using to export to DPX?

If you export to DPX through Red Alert/RedCine, you can't bring DPX directly into Final Cut unless you use have bought the third party DPX Quicktime Component plugin.

There has been issues with extracting Quicktimes to sequential images, but it depends on the codec.

While ProRes seems to be the codec of choice for editing, it is limited to 4:2:2 at the moment. If that's not a big issue, then export to DPX from the ProRes version.

It's all changing and dynamic and so exciting. Welcome to my wonderful world of post :weight_lift:
 
When you say the quality is poor when exporting the QT wrapers to DPX, what do you mean exactly?

Is it not color matching? Is the image visibly degraded? What are you using to export to DPX?

If you export to DPX through Red Alert/RedCine, you can't bring DPX directly into Final Cut unless you use have bought the third party DPX Quicktime Component plugin.

There has been issues with extracting Quicktimes to sequential images, but it depends on the codec.

While ProRes seems to be the codec of choice for editing, it is limited to 4:2:2 at the moment. If that's not a big issue, then export to DPX from the ProRes version.

It's all changing and dynamic and so exciting. Welcome to my wonderful world of post :weight_lift:


I've done tests with FCP (Gluetools installed), exporting a clip from the High Quality QT wrapper, with compression set to ProRes, RedCode and None. I've also exported the same clips from RedAlert. I then take frames and zoom into them, in After Effects and Photoshop. In the QT wrapper exports, we are in a world of messy, compressed pixels. From Redaltert, all the detail is there.

So, although I can select clips and bring them into FCP as DPX (after Red Alert) that;'s no good for real time editing. And the QTs, although great for editing, are no good for exporting a DPX sequence. You can only get a good quality image from RedAlert or Redcine. So we need that pull-list feature enabled, or editing the QT wrappers is a waste of time (for film out).
 
My understanding is that the decoding that occurs with the QuickTime codec doesn't involve a full debayer. It just treats each group of four pixels in the 4K image as a single pixel in a 2K image. This is fast, but doesn't look great.

In contrast, when you actually transcode to a QuickTime format (or DPX or TIFF) in Redcine, it does a full 4K debayer and then scales down to your output resolution (assuming it's lower than 4K). This looks much nicer, but is slow.

Red has talked about offering higher quality decoding through the QuickTime proxies. I assume (at least until computers get a fair bit faster) that these wouldn't decode in real-time. But they would be a large workflow convenience. If you had a QuickTime proxy that gave you a full-quality 4K image, for instance, you could feed it into Shake, and do compositing with the best possible image data without having to go uncompressed.

Or you could edit with low-quality proxies in Final Cut and then re-link to full-quality 2K proxies to render out your final edit. If you added GlueTools to the mix with that workflow, you could get your conformed edit as a 2K DPX sequence straight from Final Cut, without compromising quality or having to go uncompressed at any earlier stage of the process. That would be a pretty killer workflow!
 
That would be a killer workflow (and your debayer explanation helps a lot). The pull-list will be a solution of sorts, but a hell of a hassle. I'd love to be able to edit QT in the FCP, send to Color, back to FCP and out to DPX with the same quality you could expect by manually getting everything out of Redcine. Which is sort of what was implied at the last NAB, if I remember it correctly, so I assume this is coming.
 
Back
Top