DaVinci Resolve and KineTransfer

[Gunnar Nimpuno]

Hi guys,
I have some things that need to know technically, regarding using 5K RedRaw footage with DaVinci Resolve system for printing to film. We are going to make a feature film in Indonesia, using Epic (it will be the first time in Indonesia ).
The genre of this film is psychological thriller, and lots of handheld stuff will be used. The post house we chose for final color grading and Kine Transfer will be at Technicolor Bangkok. We just did our camera test, and send all the stuff to Bangkok from Jakarta (we were not able to fly to Bangkok due to the flood disaster over there). And today, I just got an email from their team, explaining how they are going to process the rushes.
They will convert the 5K footage to DPX 10 bit and down converted it to half of the total resolution (!). So the resolution will be 2560x1350 . I was shocked reading this, because I thought they will using our native files (RedRaw) to be graded. But apparently, this is how they work in their pipeline. I cannot ask for a full resolution to be graded, which I believed, will have more color lattitude.
So my question is, how far the Color and Gamma will be shifted if I am using this workflow?. By cutting half of the total resolution, my logical thinking said that, I would have quite a different result than I expected. The production company doesn't want to make any DCP files for film distribution, since the price is pretty high, comparing with make dupes for films (celluloid).
Is there any way/treatment that I should anticipate in the shooting day?. Please advice.

Thanks everybody...!

 

[John Tissavary]

It's actually a very common workflow, and since the film is being shot at 2k (I'm guessing there's not budget for 4k film recording...) it should be just fine.

The process would typically involve converting the 12bit linear 5k down to 10bit log 5k, which when done correctly is a visually lossless conversion process, indistinguishable from the original.

While I do believe there are gains to be had working in original 5k raw during the color correction process, many larger facilities are so heavily invested in a particular (older) workflow that they simply cannot keep up with Red. Then again, your budget, timeline, etc... could also be a factor in how they are processing - I just don't know enough about Technicolor Bangkok's facility to be able to speak to why they chose the workflow they did.

Again, if done correctly, there should not be any color or luminance shifts, no clipping of highlights or shadows, etc..., other than a loss of resolution / quality by shooting 2k to film. But that would be the case even if they graded at 5k, because at some point, unless the budget can handle a 4k recording process, the downrez has to happen.

regards,

John T.

 

[Alexander Ibrahim]

I suggest trying post houses that are more Red friendly ... like Light Iron in LA, and I'm sure dozens of others.

This process seems designed to trash all the advantages of Red.

I mean ... seriously they should at least be using 12 bit DPX, and I'd prefer 16 bit!

You can probably even just hire a Red knowledgeable colorist and have them handle everything.

As far as DCP creation ... that's actually pretty easy to do yourself. Once you have the original DCP files - its just data. Definitely cheaper than film copies.

 

[jake blackstone]

I
I mean ... seriously they should at least be using 12 bit DPX, and I'd prefer 16 bit!

To my knowledge, DPX doesn't come in 12 bit flavor. It's either 10 or 16 bit. For DCI it's 16 bit DPX with only 12 bits used. But I could be wrong:wink5:

 

[Alexander Ibrahim]

To my knowledge, DPX doesn't come in 12 bit flavor. It's either 10 or 16 bit. For DCI it's 16 bit DPX with only 12 bits used. But I could be wrong:wink5:

You are mostly right ...

DPX actually supports anything between 8 and 64 bits per channel (RGBA). That's not what's out there though.

All the common implementations of DPX are 10bit per channel or 16bit per channel. There is a 12 bit format out there, which is typically stored in a 16 bit DPX container. In that case, the "extra" 4 bits per channel are all packed with 0.

(For some computer science reasons, its not worthwhile to implement anything between 10 bit and 16 bit per pixel formats. Word breaks on modern computers occur at 16, 32, 48 and 64 bits. No current system is using 48 bit words that I know. On 64 bit architectures, 16 bit formats (like OpenEXR and DPX) are typically implemented as 64bit words. This explanation is not entirely correct, it glosses a lot - and is useless as implementation advice.)

 

[Peter Chamberlain]

Hi, i am very familiar with Technicolor Bangkok and they will do a good job. I understand the r3d files will be transcoded to 10bit log dpx which is like 14bit linear dpx and as the film out is in the 2K resolution range the resizing can be done anywhere as long as its clean. Tec Bangkok has two Resolve suites and countless film grading credits so their workflow is proven. If there is a particular shot that needs pre grade r3d decoding parameters adjusted the source clip can be used to recreate the dpx.
While Resolve likes working in the native file format right up to the final grade, including r3d's, its the overall result you are looking for and the dpx workflow is fine.
Peter

 

[Gunnar Nimpuno]

Friends, many thanks for all the inputs you made. Its really helfpull for me and team here. Yes, we are still new with this Digital Revolutions yet we are so excited to work with ones. For the most of posthouse in Jakarta-Indonesia, they have been really trying to catch up with any workflows updated. Since I start to decided to work with Red system (both in commercials and feature), I started to learn more and more and more until now. I am very grateful with this reduser.net. You guys are amazing...!. Like Mark Toia always says: Sharing is Caring.

Wish me luck with the project. We are going to shoot in 7 days, with Epic!.

All the best.

 

[M Most]

I suggest trying post houses that are more Red friendly ... like Light Iron in LA, and I'm sure dozens of others.

And LightIron did the DI of "The Social Network" in exactly the manner being described by the original poster.

Working directly from R3d files doesn't inherently make something better, and advocating it doesn't mean it yields an inherently superior result. The fact is that every project has its own specific needs, time frames, creative involvement, and deliverables list. There are many ways to do anything, including a DI from a project shot primarily on Red cameras. You can get superior results from different approaches by understanding what is involved in each to yield those results, not necessarily by assuming that only one approach fits all.

 

[sander kamp]

Sent you a PM.

 

[Gunnar Nimpuno]

@sander kamp, got it. Cheers mate.

 

[Alexander Ibrahim]

And LightIron did the DI of "The Social Network" in exactly the manner being described by the original poster.

Working directly from R3d files doesn't inherently make something better, and advocating it doesn't mean it yields an inherently superior result. The fact is that every project has its own specific needs, time frames, creative involvement, and deliverables list. There are many ways to do anything, including a DI from a project shot primarily on Red cameras. You can get superior results from different approaches by understanding what is involved in each to yield those results, not necessarily by assuming that only one approach fits all.

Working from R3D can't make something better.

Throwing out 75% of the data at the start of grading can make it much worse.

That's what we are talking about. Dropping 2 bits of data reduces chroma gradations from 4096 to 1024 per channel. Reducing resolution from 5K to 2.5K is again a 75% reduction in resolution.

Are you saying that there is some other benefit to Technicolor's pipeline that makes it worthwhile to dump 75% of the image data at the start of work?

There isn't - or at least there isn't to the film's image quality.

With every single digital format from the best to the crappiest, you should stay with the camera master data, with every step in the process being non-destructive until final output.

When we step away from that the tradeoffs must be clear.

10 bit DPX is fine, but let's not pretend it could possibly be in any way better than staying in R3D.

If Technicolor was offering 16 bit 5K DPX or OpenEXR ... well those formats are not as flexible as R3D, but they come close enough not to squabble if there is some other benefit.

Do I believe the results will be satisfactory? Most likely.

Do I believe the results will be as good as possible? No.

Here is my problem: When I make TV I accept "satisfactory", when I make a feature I want to explore "as good as possible"

 

[Steve Shaw]

I have to say that I cannot recommend any workflow for RED grading that doesn't use the raw red files...

Converting to any other file format before grading can all too easily restrict the final delivery quality. It will not necessarily do so, but more often than not will.

I would look for a post house that uses a system capable of a raw red workflow.

What about someone like Annapurna in Hyderabad, India? They have a great 4K/5K Mistika set-up, capable of real-time Red raw workflows.

After grading, re-sizing and file conversion for the final delivery is fine. I just strongly suggest no files conversion is ever performed, if at all possible, before grading.
The potential difference in final image quality is huge!

 

[Rob Ruffo]

You are mostly right ...

DPX actually supports anything between 8 and 64 bits per channel (RGBA). That's not what's out there though.

All the common implementations of DPX are 10bit per channel or 16bit per channel. There is a 12 bit format out there, which is typically stored in a 16 bit DPX container. In that case, the "extra" 4 bits per channel are all packed with 0.

(For some computer science reasons, its not worthwhile to implement anything between 10 bit and 16 bit per pixel formats. Word breaks on modern computers occur at 16, 32, 48 and 64 bits. No current system is using 48 bit words that I know. On 64 bit architectures, 16 bit formats (like OpenEXR and DPX) are typically implemented as 64bit words. This explanation is not entirely correct, it glosses a lot - and is useless as implementation advice.)

Once again I learn something super-useful and new on Reduser. Thank you for that!

 

[Raphael Varandas]

Reduser.net always learning here... can't stop saying that.
cheers and best wishes Gunnar.

 

[M Most]

With every single digital format from the best to the crappiest, you should stay with the camera master data, with every step in the process being non-destructive until final output.

In theory I don't disagree with that. However, what I was talking about is that not every project either allows that or works best that way. Any picture with a significant number of visual effects shots is not going to fit well into that type of pipeline because by definition, compositing cannot be done with a RAW format. Also, some formats require things like retiming (GoPro footage comes to mind), noise reduction/sharpening, and other types of image processing. While it's nice to think that everything fits into a standard box, in my world that's never been the case. So you design a pipeline on a per project basis, one that will yield the best and most consistent results given the specific conditions of the project, as well as the fewest mistakes. Sometimes that means working from native files. Sometimes it doesn't.

 

[Gunnar Nimpuno]

Very useful informations here,I feel so grateful joining this reduser.net . We just wrap yesterday,shooting for 10 days in a menacing forest. Cannot wait to see the result later on in Bangkok. I just wondering,if there are some post house in Asia who are ready for accepting RED Raw as its native files to work with?. This will be very useful for us in our next project coming up (China,Hongkong,Jakarta). Thanks guys!