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

DPX vs. R3D

T

Tommy

Well-known member
Joined
May 19, 2008
Messages
64
Reaction score
0
Points
0
Which, at this point, is the preferred method... color grading 2K DPX files or RED QuickTime files (and finishing with 2K QT)? Also, is there a difference between RED QuickTime and QuickTime wrapped R3Ds? Thanks, Tommy
 
DPX holds only 10-bit data (in case of current Apple Color can export and practically used in general, for other cases see Ramona's explanation below) where native R3D can hold 12-bit raw data.
If you are experienced with handling 10-bit DPX data well, but not certain about going through R3D workflow, you might want to start off with DPX output with balanced setting, then after you gain experiences with developing R3D footage then switch to handling R3D natively.

For Quciktime with R3D, there is always native R3D file, then proxies in QuickTime format with different sizes to do offline editing. Wrapped QT means QuickTime clip with R3D data wrapped in, so it won't need original R3D data to work natively.
 
Kaku Ito said:
DPX holds only 10-bit data where native R3D can hold 12-bit raw data.
Click to expand...

While that's true, it's not really that simple. A 12 bit linear image - which is what the Red creates after performing a demosaic - is easily and very effectively contained within a 10 bit log format if the math is done correctly and the curve used is formulated in a way that doesn't result in a significant loss of precision. In the case of Red, their Redlog curve is designed specifically for this purpose, with the only loss of precision occurring in the highest values, in which that slight precision loss is insignificant for the final result.
 
Thank you for following up. All of that details will mean something after you experienced different results with different methods, so all I was saying is to start from what you understand and feel confident with.
 
Kaku Ito said:
DPX holds only 10-bit data where native R3D can hold 12-bit raw data.
Click to expand...

This is absolutely incorrect!

You can pack a variety of colorspaces, bit depths and rasters in a DPX. We do it everyday.

You can pack both log and lin data
You can pack both SMPTE and full scale range.

If the r3d files can give the 12bits, then it should be available to pack in the DPX as such. If it can't then it should!

Then the next question is how to handle it, as most products don't support anything more than 10bit for monitoring BUT there are plenty of products that support spitting it out :)

This is where LUTs really come into play. Converting the 12 or 16bit data to 10bit for viewing in a way that best represents what you are seeing.

and then of course log and lin and colorspace conversion.

*We have feature film clients grading everyday with frames that reside on the disks as full range (up to 16bit) DPXs. It is all the tools in between that they must work around.

Most of our clients doing TV work, stay within the 8/10 bit realm.

If a project is going to both, they work the highest (full range) they feel comfortable with and apply the appropriate LUTs and colorspace conversions to take it down.

Don't mean to sound harsh but.....
Bad info just confuses people, please get the format info correct, not to be confused with particular application issues.

Cheers,
Ramona
 
Kaku Ito said:
DPX holds only 10-bit data where native R3D can hold 12-bit raw data.
If you are experienced with handling 10-bit DPX data well, but not certain about going through R3D workflow, you might want to start off with DPX output with balanced setting, then after you gain experiences with developing R3D footage then switch to handling R3D natively.

For Quciktime with R3D, there is always native R3D file, then proxies in QuickTime format with different sizes to do offline editing. Wrapped QT means QuickTime clip with R3D data wrapped in, so it won't need original R3D data to work natively.
Click to expand...
There is a 16 bit version of DPX format as well. In case LIN gamma is the preferred method of grading with a true LIN RED originated material and REC-709 deliverables, it can be easily achieved by using 10 bit LIN DPX format. 10 bit LOG DPX can handle most of film's dynamic range of 12-14 stops, so RED material will be fine with it's more limited dynamic range, even while the employing 10 bit resolution and a LIN gamma.
 
jake4n said:
There is a 16 bit version of DPX format as well. In case LIN gamma is the preferred method of grading with a true LIN RED originated material and REC-709 deliverables, it can be easily achieved by using 10 bit LIN DPX format. 10 bit LOG DPX can handle most of film's dynamic range of 12-14 stops, so RED material will be fine with it's more limited dynamic range, even while the employing 10 bit resolution and a LIN gamma.
Click to expand...

Please clarify that you don't mean linear to light when you talk about LIN DPX.

True linear (to light) from a 12bit linear source put into a 10bit container will be too destructive.

12bit linear (to light) put into a 10bit container with a REC709 gamma encoding is fine.

In general, it's not good to use Lin when talking about gamma encoded images.
 
jake4n said:
There is a 16 bit version of DPX format as well. In case LIN gamma is the preferred method of grading with a true LIN RED originated material and REC-709 deliverables, it can be easily achieved by using 10 bit LIN DPX format. 10 bit LOG DPX can handle most of film's dynamic range of 12-14 stops, so RED material will be fine with it's more limited dynamic range, even while the employing 10 bit resolution and a LIN gamma.
Click to expand...

I don't think many apps support the 16bit version of DPX. Shake requires you to have a bit depth node set to 16bit to make a DPX file higher than 8bits, but it's not 16bits.

I believe pretty much 10bit DPX is what most people use and support.
 
Deanan said:
Please clarify that you don't mean linear to light when you talk about LIN DPX.

True linear (to light) from a 12bit linear source put into a 10bit container will be too destructive.

12bit linear (to light) put into a 10bit container with a REC709 gamma encoding is fine.

In general, it's not good to use Lin when talking about gamma encoded images.
Click to expand...

Hi Deanan. I'm sorry but I'm not familiar with tern linear to (light) term. Do you mean linear as a true RED linear gamma, versus "linear" 2.2 video gamma, which isn't linear at all? We already had this conversation on a different thread a while back. Anyway, that is why I had said, that in case of REC-709 deliverables the conversion to 10 bits should work. At no time did I advocate to do it for the film or DCI deliverables.
 
Thomas Mathai said:
I don't think many apps support the 16bit version of DPX. Shake requires you to have a bit depth node set to 16bit to make a DPX file higher than 8bits, but it's not 16bits.

I believe pretty much 10bit DPX is what most people use and support.
Click to expand...
All of the high end color grading systems do support 16 bit DPX. And yes, you're correct, 10 bit LOG DPX is the preferred DI workflow.
 
sorry I was referring to Apple Color and general use of DPX. So Ramona is right. That'll end my posts here then, because I confused people.
 
Kaku,

Don't take it personally. Ramona is a good person. That's her signature message. i have emails from her with the same words.
 
I edited my original post to clarify the format/app spec. differences.
 
You must log in or register to reply here.
Back
Top