Best format for working with Dragon in post (raw not an option)

[Lewis Smithingham]

I'm trying to figure out the best way to get the best color/bits/resolution out of Dragon footage, I'm wondering what the best format would be to work in. Here's the info on my current work flow for this project:
I work in Premiere and After Effects (for edit and grade of a director's cut). Because as of right now Adobe does not support Dragon Color or A.D.D. I think it makes sense to transcode to a different codec to work with in Adobe. But what codec/format?
My ultimate output will be 1080p.
What do you guys think? would love to have something that retains 16bit and also retains a decent size for some minor push-ins (I know prores goes to 4k).
Should I bother with A.D.D. the footage does look a bit more noisy then it should for something exposed perfectly, at a low ISO and perfectly black-shaded on set.
I would prefer not to work with something that isn't an image sequence, that's just a bit annoying to edit with, but if something like OpenEXR is my only option, ill have to make it work.

Should say, I am very impressed with dragon, I didn't think that the differences would be noticeable. But they are, color range in Dragoncolor is very nice, also the way the camera handles highlights, particularly when using the motionmount is very nice. Also, in general, the images appear a bit sharper.

Thanks in advance.

 

[Björn Benckert]

I'm trying to figure out the best way to get the best color/bits/resolution out of Dragon footage, I'm wondering what the best format would be to work in. Here's the info on my current work flow for this project:
I work in Premiere and After Effects (for edit and grade of a director's cut). Because as of right now Adobe does not support Dragon Color or A.D.D. I think it makes sense to transcode to a different codec to work with in Adobe. But what codec/format?
My ultimate output will be 1080p.
What do you guys think? would love to have something that retains 16bit and also retains a decent size for some minor push-ins (I know prores goes to 4k).
Should I bother with A.D.D. the footage does look a bit more noisy then it should for something exposed perfectly, at a low ISO and perfectly black-shaded on set.
I would prefer not to work with something that isn't an image sequence, that's just a bit annoying to edit with, but if something like OpenEXR is my only option, ill have to make it work.

Should say, I am very impressed with dragon, I didn't think that the differences would be noticeable. But they are, color range in Dragoncolor is very nice, also the way the camera handles highlights, particularly when using the motionmount is very nice. Also, in general, the images appear a bit sharper.

Thanks in advance.

Do 16bit DPX files. And do the downscale straight from source all the way down to 1080P and do your sharpening before/in the downscale. If you got to much noise even for going to HD and you need ADD then no you did not "exposed perfectly" or something is very wrong dragon at low iso should look slick as glass if exposure is right.

I guess you could use EXR just as well as DPX but I got issues with EXR in certain programs but never with DPX. But thats just my preference. Make sure to export with one folder per clip or so then the folders work just as well as quicktime containers, or better actually as you do not get 16 bit into the quicktime. The DPX files hold source TC and source file name etc and if the folders are named to source file name and random ending then you got a very good base to conform form in your grading software.

It would be great if you could upload a few r3d's just to see what the problem is as there should not be any noise if the exposure is right.

 

[Lewis Smithingham]

Bjorn, thanks for the quick reply. that workflow sounds about right. Ive never exported dpx before. should i export 1 clip at a time?
I didnt mean for you to think that the noise was that much of problem, more than anything, the noise that i'm seeing just looks different, more like film grain. So yah perhaps it isnt too much noise, just different looking noise, or noise in different places.. By perfect exposure, I mean flat waveform on set. shoot me a pm and Ill shoot you an r3d.

 

[Brian Merlen]

I found DPX very intensive to work with, as bad as r3d raw or worse. what kind of super computer are you using to work them if you don't mind me asking...I had a maxed 12 core silver tower using adobe CC and it was like impossible to even use DPX on the bay i was on.

personally i use prores and dnxhd but i also am usually on old syle mac pro bays, or hp z400s, not super great systems to begin with relative to super computers for 10 or 20k. obviously a reconform for coloring is best practice for using these lossy proxies to edit...

 

[Marc Wielage]

I agree 100% with Brian. I think DPX is overkill for 1080 delivery. You can work directly with the R3D originals at quarter- or half-res on many reasonably-fast computers, then export to the HD delivery format of your choice. Alternately, using a flattened file in ProRes 444 1080 can work well, if speed and budget are issues.

Here's a pretty good workflow article:

http://www.ninofilm.net/blog/2012/10/29/a-resolve-9-red-r3d-grading-workflow-guest-post/

Do your offline edit entirely at a modest resolution, then conform the R3D originals and use those within Resolve. I have no problem with people trimming the originals to save drive space, provided they're very careful. Nikolai Waldman's Resolve Collect is a good utility that can pull in just the R3D's needed for the final conform.

If this is a feature, I would suggest cutting the film into reels about 20-30 minutes long and not try to create any longer segments than this for color-correction (or the mix). This will also help when and if any changes occur. Once it's finished, you can create a "super session" and output it as one file if you wish.

Resolve 10.1.5 does handle Dragon Color. My preference is to use whatever color science is appropriate within RedLogFilm, but you can make good arguments for a lot of different approaches for color. Test the workflow first and make sure it's going to work for what you're trying to do.

 

[Hans von Sonntag]

I found DPX very intensive to work with, as bad as r3d raw or worse. what kind of super computer are you using to work them if you don't mind me asking...I had a maxed 12 core silver tower using adobe CC and it was like impossible to even use DPX on the bay i was on.

personally i use prores and dnxhd but i also am usually on old syle mac pro bays, or hp z400s, not super great systems to begin with relative to super computers for 10 or 20k. obviously a reconform for coloring is best practice for using these lossy proxies to edit...

R3D eats power to decode. DPX does need any decoding since it is uncompressed. However a 10 Bit DPX frame weights about 8 MB, now think 16 Bit and add to that 24 of them per second. For a RT stream of 16 Bit DPX and 1080p you need a very fast and huge raid depending on the size if your project.

In commercial land most Flames are running at 10 Bit, one can step up to 12 Bit if desirable (complex green screen) but 16 Bit is IMHO an overkill especially if one works with PP and AE which suggest that the workstation is not connected to a huge high-speed SAN.

You can use 12Bit ProRes444 which Resolve encodes to RGB and hence does not gamma shift in applications that work natively in RGB (FCP-7 has been YUV). My Epic got recently dragonised and I still use something mediocre for documentaries like 10 Bit ProRes 422HQ, even as render files inside Smoke. For commercials we change the online workflow to 10 Bit DPX. But I have my workstations to very fast and voluminous storage connected. IMO, it all depends on the desired level of fidelity and the space where the project later lives in. A documentary for Discovery channel does not need a high-end fidelity pipe-line, same with Vimeo et al. Different is a DCP for international marketing. And of course VFX. But even in VFX the person behind tae machine is more important than the sheer fidelity of the footage if some standard is kept.

Footage from the Dragon sensor does not require any special treatment. Like the MX sensor the AD is 16 bit and so is the RAW file. It's 16 But linear. One can argue that for fidelity maintenance a 16 Bit pipeline is required but then I would answer, yes if super-accurate noise and super-accurate blown-out whites are needed. IMO, it's much more important to expose meaningful and get things in focus than to provide a 16 bit post pipeline. For Dragon footage use DragonColour, it's a clear step up and puts colour-wise Red footage in Alexa realm. For gamma use always RedLogFilm, all the iteration of RedGamma 1-4 drop a lot of information and are only useful for off-line dailies. The logarithmic encoding in RedLogFilm is similar to Arri's LogC and is available to make a meaningful translation from 16Bit linear RAW to lower Bit-rates in RGB without losing much information possible.

Hans

 

[Hrvoje Simic]

Like the MX sensor the AD is 16 bit and so is the RAW file.

To my knowledge Epic internal processing has been stated in 16 bit, ADC for MX has not been clarified.

 

[Björn Benckert]

Bjorn, thanks for the quick reply. that workflow sounds about right. Ive never exported dpx before. should i export 1 clip at a time?
I didnt mean for you to think that the noise was that much of problem, more than anything, the noise that i'm seeing just looks different, more like film grain. So yah perhaps it isnt too much noise, just different looking noise, or noise in different places.. By perfect exposure, I mean flat waveform on set. shoot me a pm and Ill shoot you an r3d.

There is a separate clips option in the export module of RCXP same for resolve, you export a flatpass to one folder per clip.

 

[Björn Benckert]

R3D eats power to decode. DPX does need any decoding since it is uncompressed. However a 10 Bit DPX frame weights about 8 MB, now think 16 Bit and add to that 24 of them per second. For a RT stream of 16 Bit DPX and 1080p you need a very fast and huge raid depending on the size if your project.

In commercial land most Flames are running at 10 Bit, one can step up to 12 Bit if desirable (complex green screen) but 16 Bit is IMHO an overkill especially if one works with PP and AE which suggest that the workstation is not connected to a huge high-speed SAN.

You can use 12Bit ProRes444 which Resolve encodes to RGB and hence does not gamma shift in applications that work natively in RGB (FCP-7 has been YUV). My Epic got recently dragonised and I still use something mediocre for documentaries like 10 Bit ProRes 422HQ, even as render files inside Smoke. For commercials we change the online workflow to 10 Bit DPX. But I have my workstations to very fast and voluminous storage connected. IMO, it all depends on the desired level of fidelity and the space where the project later lives in. A documentary for Discovery channel does not need a high-end fidelity pipe-line, same with Vimeo et al. Different is a DCP for international marketing. And of course VFX. But even in VFX the person behind tae machine is more important than the sheer fidelity of the footage if some standard is kept.

Footage from the Dragon sensor does not require any special treatment. Like the MX sensor the AD is 16 bit and so is the RAW file. It's 16 But linear. One can argue that for fidelity maintenance a 16 Bit pipeline is required but then I would answer, yes if super-accurate noise and super-accurate blown-out whites are needed. IMO, it's much more important to expose meaningful and get things in focus than to provide a 16 bit post pipeline. For Dragon footage use DragonColour, it's a clear step up and puts colour-wise Red footage in Alexa realm. For gamma use always RedLogFilm, all the iteration of RedGamma 1-4 drop a lot of information and are only useful for off-line dailies. The logarithmic encoding in RedLogFilm is similar to Arri's LogC and is available to make a meaningful translation from 16Bit linear RAW to lower Bit-rates in RGB without losing much information possible.

Hans

Yes, flame works in 8, 10,12 or 16 bit. But it's important to separate source bit depth and work bit depth for example in flame I can have a 16bit depth frame going in as a soft import and when that file is displayed/rendered for the first time then I can grade/clamp colors and then bring it down to preferred work bit depth, personally I work in 12 bits pretty much al the time from 16bit source. But if the material is graded allready before entering flame then 10 bit is more than enough.


So it's not needed to be on super fast discs to work from 16bit the only thing is / you will not be able to playback before your first render, or before proxies are created. In flame you have the option to have any sized proxies at any bit depth that is created on import.

 

[Hans von Sonntag]

Yes, flame works in 8, 10,12 or 16 bit. But it's important to separate source bit depth and work bit depth for example in flame I can have a 16bit depth frame going in as a soft import and when that file is displayed/rendered for the first time then I can grade/clamp colors and then bring it down to preferred work bit depth, personally I work in 12 bits pretty much al the time from 16bit source. But if the material is graded allready before entering flame then 10 bit is more than enough.


So it's not needed to be on super fast discs to work from 16bit the only thing is / you will not be able to playback before your first render, or before proxies are created. In flame you have the option to have any sized proxies at any bit depth that is created on import.

Björn, I'm totally with you and all you say about Flame, but depths, proxy-workflow etc... is right, of course.

But the original poster wants to edit/work/finish in Adobe applications (ca. 150 EUR K less costly). Hence my assumption that an uncompressed 16 Bit workflow is probably not really productive. 10/12 Bit log encoded, even to something compressed such as ProRes or DnXHD is probably more meaningful. If his post-production environment has fast Raids etc... he probably would not have asked.

Hans

 

[Juan Melara]

Go Dragon Color / Redlogfilm encoded to 12bit ProRes 444.

Apply a small amount of sharpening prior to scaling. Scale down to 3840 x 2160 to allow for up to a 2x crop. If you don't need that much of a push in or thats too taxing on your system, scale to 2880 x 1620 for up to 1.5x.

You're unlikely to notice any difference no matter how hard you push the footage. I grade a lot of Alexa ProRes 444 and even with some pretty extreme exposure adjustments and grades it never really breaks. Even grading Alexa ProRes 422 HQ never leaves me wanting anymore bits or colour info and I never sit there wishing it was raw...

White balance is important, but as long as you get it +/- ~500k you can bring it back pretty easily.

 

[Hans von Sonntag]

To my knowledge Epic internal processing has been stated in 16 bit, ADC for MX has not been clarified.

I'm pretty sure, MX has already a 16 Bit ADC. Dragon must have one, otherwise the 16 claimed stops would not fit in a linear RAW that has less bit depth. You can do that but then you need the RAW log encoded. MX's specs were officially just about 14 stops. Those stops would have needed a 14 Bit ADC. The original RedOne Sensor had a 12 Bt ADC.

It's interesting to see wether Red will stick to linear RAW in the future. With new sensors coming, delivering even more DR, the question of going perhaps the log route may arise again.

Hans

 

[Brian Merlen]

The first time I tried working with it, it was 16 bit DPX recorded on a 7Q. It came off a Sony F3 and was on a fast SAN hooked to a maxxed old school mac pro, but still couldn't playback in the newest Adobe CC.

The second time I was using a raid 1 with only 2 disks not working together, so that taking a while should be expected. I would like to use Raid 5s, but the drive was being flown on a plane to another country so client refused. During the shoot it was like impossible to cycle cards while encoding 16bit DPX 5k out of redcine. I kept up best I could but still had to encode 12 hours after wrap. This was using an 8 core xeon old school mac pro with rocket and an Epic MX. But like I said its a disk throughput issue the second time.

Generally speaking without rocket not in full playback or with rocket at full is how I work, or I just use prores/dnxhd and reconform. really my clients always choose the pipeline and they happen to just choose prores most of the time cuz its easier on them. A lot of times they don't even do a reconform either so getting the DP happy with the one light and exporting while cycling cards is the name of the game

 

[Björn Benckert]

Björn, I'm totally with you and all you say about Flame, but depths, proxy-workflow etc... is right, of course.

But the original poster wants to edit/work/finish in Adobe applications (ca. 150 EUR K less costly). Hence my assumption that an uncompressed 16 Bit workflow is probably not really productive. 10/12 Bit log encoded, even to something compressed such as ProRes or DnXHD is probably more meaningful. If his post-production environment has fast Raids etc... he probably would not have asked.

Hans

It all depends ofcourse. What I mean is that even if you do not have fast discs etc. if you just export selects as DPX and reconfirm from them then do your color grading and render to 10 or even 8 bit... it's all depending on how long duration you got to deal with act. but for commercials and short form I find it very doable to render before having playback. And to go with a 16bit uncompressed DI gives you all the options there is and the slow down is not to bad. Thats how we do it here on our slow 5 years old macs and it works very well, if we do not work straight from the r3d.

 

[Lewis Smithingham]

thank you dudes. this has all been extremely helpful and informative. Also, you are correct, I'm working on an older macpro system. Not really something that can be pushed too far. However, found out that my EP/director is getting the rocket-x today. so we shall see.

 

[Brian Merlen]

Awesome that your getting a Rocket X! If you end up putting it in your Xeon please let us know how it works out? I am assuming even with the older system it will push it through fast as (or faster) then it would externally via the TB2 bottleneck...