R3D Color Discussion

[JonathanF]

Unless your colorist is working on Scratch and uses RAW R3D for grading, every other color grading solution, that I'm familiar with (Baselight, Lustre, Filmmaster) does the background R3D transcode to DPX and that is what used for actual grading. 10 bit LOG DI has been around for pretty much..., well, always. All feature DI is done that way, so to claim, that that is not good enough is, shall we say... eccentric. But, if you're convinced (I'm not), that 10 bit LOG isn't good enough and you MUST grade in 4K(?), well, then just use 16 bit DPX But said that, it would be great, if RED or someone else could provide a simple utility, that would consolidate only used R3D files, based on EDL. ALE or XML.
P.S. I just looked over the paper, that you'd mentioned earlier and all Bill is talking about is the description of his method of dithering 8 bit sRGB image for better representation of the original image. How you derive from that paper, that use of LOG DPX for DI is a bad policy is simply beyond me...

No but the issue is that color and exposure transforms in floating point are far superior. The fact that he was applying this to conversions as well as filtering and transform situatoins is moot.

If you are applying exposure corrections in Log space the math is quite simply wrong.

Some grading systems do convert the log to linear before applying this kind of correction, this is generally transparent to the user, but why go there in the first place if you don't have to. Transcoding the data into log and then re-transcoding back to float for certain operations is just batty.

However, the point of my post is not which is better, DPX or R3D. The point of the matter is that the colorist has requested the native R3D files.

He was the director's choice and it's not our place to question his judgment.

Us arguing about it is not going to get a feature from Red we both want any faster.

 

[JonathanF]

R3D Color Discussion

Unless your colorist is working on Scratch and uses RAW R3D for grading, every other color grading solution, that I'm familiar with (Baselight, Lustre, Filmmaster) does the background R3D transcode to DPX and that is what used for actual grading. 10 bit LOG DI has been around for pretty much..., well, always. All feature DI is done that way, so to claim, that that is not good enough is, shall we say... eccentric. But, if you're convinced (I'm not), that 10 bit LOG isn't good enough and you MUST grade in 4K(?), well, then just use 16 bit DPX

There are at least two systems I am aware of out there that apply floating point color transforms directly to the decoded 12 bit datstream in the R3D files without doing a background transcode to 10 bit.

R3D is a 12 bit RAW undebayered format. Some may want to take it down to 10 bit dpx but, log or linear, in the process of making that conversion 2 bits go away.

 

[JonathanF]

Simply converting 12 bit LIN to 10 bit LOG doesn't mean you lose 2 bits.

Jake,

I don't really want to argue with you, but for the sake of avoiding confusion for others I have to take a stand here and point out that you are quite simply wrong.

10 bits of log data is insufficient to house all of the information in a 12 bit RAW image. The raw image itself differs vastly from a conventional image format like dpx. Converting raw to dpx prior to applying color transforms will not result in the same quality of correction you get from a direct linear floating point transform on 12 bit raw data converted directly to floating point (or in this case 16 bit unsigned) prior to application of the color transform.

While I cannot say this for certain, as my experience in this area of development with the SDK is limited, but the 12 bits housed in the R3D file is 12 bits of raw undebayered data. If the debayering and other filtering operations like OLP filtering are happening in the floating point domain then the resulting datastream from the SDK could potentially exceed 12 bits of the undebayered RAW data from the sensor.

But all of that aside, your contention that you can house all the data in an uncompressed 10 bit log file that's contained in a 12 bit linear file is untrue and simply impossible. Full stop. Bits are bits and you can't smash 12 bits into 10 bits.

The cineon and it's later cousin, dpx, use a hack of data redistribution to pack more data into the head and toe of the image AT THE EXPENSE of data in the midrange. This was done because it generally directly corresponded to the density of the camera negative. But that was in 'film land' and we're not in 'film land' any more.

In a Cineon (.cin) file, each channel (R,G,B) is 10 bits, packed 3 per 32-bit word, with two bits unused. The data coming out of the SDK is 16 bit linear unsigned. You can achieve a relatively lossles PERCEPTUAL conversion to 10 bit log space from this data, but there IS data loss. There is no question of this. Any application of downstream color transforms will ALWAYS be of lesser quality than the same color transformation applied to the 16 bit unsigned data that comes out of the SDK. Keep in mind that the operative word here is 'perceptual.'

I don't mind making the perceptual compromise at the end of the post process as the final step prior to recording back onto film, however if I plan to apply numerous, layered color transformations (read primary and secondary color correction) I want my data to retain as much of it's integrity from a depth standpoint as possible for as long as I can.

Perhaps Graeme would like to elaborate as he's far more technically astute than I am in this arena. He himself has noted elsewhere that colour correction works best on linear data, and the lin to log conversion is generally destructive. He has also noted that "colour correcting in a non-linear gamma is troublesome, and really should be avoided."

I would agree on both points.

 

[Kyle Mallory]

Jake,

12-bits to 10-bits is data loss, pure and simple. LOG or LIN makes no difference. The only difference between LOG and LIN is how those resulting 10 bits are presented (or what those 10 bits represent). At the end of the day, 10bits is still not 12 bits.

Further, I think it has clearly been demonstrated (thanks to various camera/post tests, etc.) that the R3D->DPX pipeline in flawed (perhaps not fundamentally, but...). Personally, I would never trust my RED footage to DPX. R3D and EXR are the only formats I'll consider for DI exports.

IFX's Piranha (and Ant) decode the R3D into U16I (via SDK), and immediately convert that to 16-bit floating points (EXR's Half) internally to be processed by the rendering pipeline. All 12bits or the original R3D are preserved until you write your stuff out to something less (like 10-bit DPX). I can say this definitively, because I wrote it.

 

[jake blackstone]

Jake,

12-bits to 10-bits is data loss, pure and simple. LOG or LIN makes no difference. The only difference between LOG and LIN is how those resulting 10 bits are presented (or what those 10 bits represent). At the end of the day, 10bits is still not 12 bits.

Further, I think it has clearly been demonstrated (thanks to various camera/post tests, etc.) that the R3D->DPX pipeline in flawed (perhaps not fundamentally, but...). Personally, I would never trust my RED footage to DPX. R3D and EXR are the only formats I'll consider for DI exports.

IFX's Piranha (and Ant) decode the R3D into U16I (via SDK), and immediately convert that to 16-bit floating points (EXR's Half) internally to be processed by the rendering pipeline. All 12bits or the original R3D are preserved until you write your stuff out to something less (like 10-bit DPX). I can say this definitively, because I wrote it.

Kyle and Jonathan.
I can't spend all this time dealing with this matter. So I'm going to recite a few facts and call it a day.
1. Unless material shot on Red, 100% of all DI is done in 10 bit LOG DPX. Of coarse, I'm simplifying things a bit, but anyone who had spent any time working at any of the "Big 5" or other top DI companies would know it. Yes, there are few bits of open EXR and 16 bit TIFFs, but not in any significant number. Why? Pure and simple-economics. Same reason, why 4k DI isn't as significant, as some would like it to be.
2. On Red originated projects, unless it is graded on Scratch, all of the grading is pretty much always done, while using transcoded DPX. All SDK allows is for the "hooks" for the host software to control the background DPX render settings, unlike Assimilate... I'm still waiting on the two native R3D software solutions promised to be revealed by Jonathan.
3. Yes, 12 bits are not equal to 10 bits, but there are two concepts in play, that actually "almost" allows for that. First is a data distribution. Actually you're wrong, when you say"to pack more data into the head and toe of the image AT THE EXPENSE of data in the midrange". In actuality, in the LOG data distribution, only highlight data is compressed. Mids aren't touched at all and lows actually stretched to allow for more data precision. So, the only ones are affected are in the highlight area of the curve and those are LSB by definition And that brings us to the concept number two- lossless compression. It is a compression, but it's as good as it gets. This form of compression had been good enough for every top DI post house for the last 15 or so years. (see 1)
4. "Personally, I would never trust my RED footage to DPX". See 1 as well. A couple of years ago Filmlight was running a demo at NAB and IBC, where they were applying something like 50 layers of color adjustments on Baselight to Dalsa footage and after all that they were able to recover all data intact. Such is the precision of 16 bit floating point calculation used in pretty much all high end grading solutions working with LOG DPX. If 50 adjustment layers aren't enough, then there is something seriously wrong

 

[Tim Whitcomb]

Kyle and Jonathan.
I can't spend all this time dealing with this matter. So I'm going to recite a few facts and call it a day.
1. Unless material shot on Red, 100% of all DI is done in 10 bit LOG DPX. Of coarse, I'm simplifying things a bit, but anyone who had spent any time working at any of the "Big 5" or other top DI companies would know it. Yes, there are few bits of open EXR and 16 bit TIFFs, but not in any significant number. Why? Pure and simple-economics. Same reason, why 4k DI isn't as significant, as some would like it to be.
2. On Red originated projects, unless it is graded on Scratch, all of the grading is pretty much always done, while using transcoded DPX. All SDK allows is for the "hooks" for the host software to control the background DPX render settings, unlike Assimilate... I'm still waiting on the two native R3D software solutions promised to be revealed by Jonathan.
3. Yes, 12 bits are not equal to 10 bits, but there are two concepts in play, that actually "almost" allows for that. First is a data distribution. Actually you're wrong, when you say"to pack more data into the head and toe of the image AT THE EXPENSE of data in the midrange". In actuality, in the LOG data distribution, only highlight data is compressed. Mids aren't touched at all and lows actually stretched to allow for more data precision. So, the only ones are affected are in the highlight area of the curve and those are LSB by definition And that brings us to the concept number two- lossless compression. It is a compression, but it's as good as it gets. This form of compression had been good enough for every top DI post house for the last 15 or so years. (see 1)
4. "Personally, I would never trust my RED footage to DPX". See 1 as well. A couple of years ago Filmlight was running a demo at NAB and IBC, where they were applying something like 50 layers of color adjustments on Baselight to Dalsa footage and after all that they were able to recover all data intact. Such is the precision of 16 bit floating point calculation used in pretty much all high end grading solutions working with LOG DPX. If 50 adjustment layers aren't enough, then there is something seriously wrong

1. Big five going to need to adapt...if not for RED, than certainly for Arri D21
2. NOT TRUE on a Quantel Pablo iQ
3. Highlights are the nemesis of every digital camera, so somethings got to give here...
4. 4K DPX worked great on this film "Drona" (ignoring cost) http://www.lightillusion.com/drona.htm

cheers

 

[Kyle Mallory]

All SDK allows is for the "hooks" for the host software to control the background DPX render settings, unlike Assimilate... I'm still waiting on the two native R3D software solutions promised to be revealed by Jonathan.

Jake,

Can you back up this statement with references? It makes no sense whatsoever for RED to decode RAW 12-bit as U16I, convert to float, internally apply color transforms (from meta), encode to 10-bit DPX, then decode back to U16I, before handing it off to the host application. I hope you haven't insulted Deanan and Rob's intelligence, and Jim's passion for quality, by making such an outrageous suggestion.

As for the two; I gave you one: IFX's Piranha. Tim gave you another: Quantel Pablo IQ, and I suspect (but cannot confirm as definitively as I can with Piranha), that Sony's Vegas Pro 9 does as well (if not also Premiere).

Cheers,

 

[JonathanF]

Jake,

I'm not going to continue the rant as it's just degenerating into nonsense.

You are wrong. Full stop.

Because I know the developers writing the code I can say for certain that IFX's Piranha has a full floating point pipeline. I don't know about scratch, but I believe it does as well, Kyle has chimed in with a few other candidates.

I have 16 major features under my belt, some supervising highly technical custom software development for post (twice on films with budgets in the 100M+ department). I have shot two films on the Red and have been involved in highly tecnical aspects of custom tools development for both of them as well.

I regularly make decisions regarding colorists and other personnel on post and quite frankly you're not making any bonus points calling me an idiot.

J

 

[guhan]

hi can u detail a little more on r3d files in a di colouring stage.when we tried our tests which had 5600k shots corrected with 3200k shots r3d files didnt response properly,that is we cannot correct 3200 shots to nuetral as r3d but was possible when converted to dpx. iam i loosing quality on dpx.we tried this on baselight

 

[Mark L. Pederson]

2. NOT TRUE on a Quantel Pablo iQ

Tim - Pablo uses Red Rocket to convert to DPX on import.

 

[Lucas Wilson]

2. NOT TRUE on a Quantel Pablo iQ

Tim - Pablo does not work on the raw data in the same way that SCRATCH does. It does a conversion from R3D on input to the Pablo and uses the SDK to do it.

The RED Rocket™™ implementation on a Pablo uses the card as an accelerated transcode for input. The way SCRATCH uses it feeds directly from the card -> GPU for a realtime post pipeline... without the need for import. To be clear, though - when using the Rocket card, SCRATCH also uses the SDK. You can actually switch between 8-, 10-, of 16-bit processing in software, which is the traditional native RAW access that SCRATCH has always had, or 8-, 10-, or 16-bit processing in hardware, which is using the SDK through the RED Rocket™™ card.

So, for Jonathan and Jake - I highly encourage you to buy a couple of SCRATCH systems yourself and do the tests, since you can (in realtime) switch between the two options you are debating. I take check, cash, or credit card. : )

Lucas


ASSIMILATE, inc.
LA, CA, USA

 

[JonathanF]

R3D Color Discussion

Tim - Pablo does not work on the raw data in the same way that SCRATCH does. It does a conversion from R3D on input to the Pablo and uses the SDK to do it.

The RED Rocket™™™ implementation on a Pablo uses the card as an accelerated transcode for input. The way SCRATCH uses it feeds directly from the card -> GPU for a realtime post pipeline... without the need for import. To be clear, though - when using the Rocket card, SCRATCH also uses the SDK. You can actually switch between 8-, 10-, of 16-bit processing in software, which is the traditional native RAW access that SCRATCH has always had, or 8-, 10-, or 16-bit processing in hardware, which is using the SDK through the RED Rocket™™™ card.

So, for Jonathan and Jake - I highly encourage you to buy a couple of SCRATCH systems yourself and do the tests, since you can (in realtime) switch between the two options you are debating. I take check, cash, or credit card. : )

Lucas


ASSIMILATE, inc.
LA, CA, USA

Lucas,

We might if it ran on Linux, but we have a deep loathing for Windows at this studio and the SAN won't talk to it either without costly licensing upgrades (not to mention telling the IT guy he's got to maintain a windows box and I don't want to have that conversation). That leaves us in Lustre + Piranha land for now.

We're content with them, I've used Scratch on other small projects and while it's a good tool, but we still have a serious amount of film to contend with and Scratch is really just an R3D pony.

J

 

[Lucas Wilson]

Lucas,

We might if it ran on Linux, but we have a deep loathing for Windows at this studio and the SAN won't talk to it either without costly licensing upgrades (not to mention telling the IT guy he's got to maintain a windows box and I don't want to have that conversation). That leaves us in Lustre + Piranha land for now.

We're content with them, I've used Scratch on other small projects and while it's a good tool, but we still have a serious amount of film to contend with and Scratch is really just an R3D pony.

J

Oh what the heck, I'll take the bait...

We had more than 100 customers worldwide doing nothing but film-based DPX work when RED was merely a twinkle in Jim's eye. Some of our biggest DPX-based clients include: EFilm, Technicolor, Deluxe, Universal Studios, Warner Bros., 20th Century FOX, CinesiteUK, Digital Domain, etc. These customers all purchased SCRATCH long before RED.

- I don't really understand the SAN issue.

ADIC, CXFS, Promise, Bright/ADIC, XSAN/ADIC - all have manageable Windows clients. And they all offer (especially now) very reasonably priced licenses. I know, because I deal with all of them on a regular basis on behalf of our clients.

Several other post manufacturers in the DI space - Quantel and DVS for instance - base their tools on a Windows layer. If you open a Windows system up to the Internet, then yes - that is a pain. But who in their right mind does that with a production system?

If you don't like SCRATCH, that's different. But using a "RED Pony" line, or the excuse of how hard it is to tie it to a SAN is not a valid competitive argument.

Lucas

 

[JonathanF]

Oh what the heck, I'll take the bait...
Several other post manufacturers in the DI space - Quantel and DVS for instance - base their tools on a Windows layer. If you open a Windows system up to the Internet, then yes - that is a pain. But who in their right mind does that with a production system?

If you don't like SCRATCH, that's different. But using a "RED Pony" line, or the excuse of how hard it is to tie it to a SAN is not a valid competitive argument.

Lucas

We use Bright. The license for windows is far more costly than linux now and we, frankly, hate windows (like Bright which is why they finally got fed up and just jacked the price on the licenses for clients). We tolerate macs because a lot of us have Macbook Pros and we edit on FC (plus the licenses for the Bright are super cheap). Windows just ain't going to happen.

However, I didn't know you had that good of file support, that's good to know; like I said, I've used and liked your product when working behind an artist on the few 'out of house' projects where I had an opportunity to get some brief exposure to it.

For us the main issue is adding yet another platform to our infrastructure. Our shop dates back to SGI Crimson machines back in the early 90's and we never introduced windows even during the late 90's NT frenzy. Everything from machine configuration management to filesystem access assumes a *nix type OS. That includes all our scripts, the queue, etc.

Since we also develop a ton of our own tools and have no one willing to port or develop them on Windows the discussion is pretty much moot.

Most of our guys are shell jockeys and I think if you took grep, sed, gawk or any of their other favorites away I'm pretty sure there would be tears.

As far as the SAN is concerned both Windows and Mac performance sucks doo compared to linux, and that's also a big issue for us. Watch a linux box hit your SAN and then watch XP hit it. Watch the load on the SAN, it's pretty enlightening.

 

[Lucas Wilson]

We use Bright. The license for windows is far more costly than linux now and we, frankly, hate windows (like Bright which is why they finally got fed up and just jacked the price on the licenses for clients). We tolerate macs because a lot of us have Macbook Pros and we edit on FC (plus the licenses for the Bright are super cheap). Windows just ain't going to happen.

Have you guys ever considered managing ADIC yourselves without the Bright layer? Seems to be the way a lot of shops in LA are going right now.

I'd be glad to help where I can with the pricing model... and I think I can be fairly effective there. If that's of interest, please contact me offlist.

However, I didn't know you had that good of file support, that's good to know; like I said, I've used and liked your product when working behind an artist on the few 'out of house' projects where I had an opportunity to get some brief exposure to it.

If you're ever interested in a demo license, let me know. Easy to do, and I'd be interested in your opinion.

Most of our guys are shell jockeys and I think if you took grep, sed, gawk or any of their other favorites away I'm pretty sure there would be tears.

LOL. Understood. : )

As far as the SAN is concerned both Windows and Mac performance sucks doo compared to linux, and that's also a big issue for us. Watch a linux box hit your SAN and then watch XP hit it. Watch the load on the SAN, it's pretty enlightening.

I am hitting the edge of my knowledge here - but I believe that has much more to do with the application and how it handles I/O threads vs. the OS. If you just use whatever Windows gives you, then yes - it's doo-doo. If an app manages its own I/O threads at a granular level (like we do) then load management can be very efficient. I have seen more than one Chief Engineer say, "Hmmm... well... how about that..." when doing load testing with SCRATCH hooked up to an ADIC SAN.

I do understand the issues faced when integrating a Windows system into a Linux-dominant infrastructure. But in my experience, it usually has very little to do with Windows per se, and more to do with the fact that a ton of work at the facility level has been done that is OS-specific for Linux and the cost is not justified to recode and integrate a non-compatible OS.

Thanks for the chat...

Lucas

 

[jake blackstone]

Tim - Pablo uses RED Rocket™ to convert to DPX on import.

Thanks Mark for helping to set the record straight. And as I said before, that also goes for Resolve, Lustre, FilmMaster, Baselight (did I forget something?) with or without the RR of coarse. ONLY Scratch, RC(X) and RA are native RAW apps. All others apps work off transcoded material. Sorry, that's SDK... I know, Tim, that you love Pablo, but didn't we already establish, that Pablo isn't a magic box?
Again, guys, anybody, who had spent 30 seconds in any high end DI facility would know, that ALL grading for ALL major movie releases is done off DPX. Just because they do that, doesn't mean they ignore RED or ARRI. Sorry, but no amount of misinformation will change that fact
BTW, from Piranha's web site:
File formats
YUV, TIF, TGA, JPG, PNG,Cineon/DPX, EXR,SGI Image, Movie, Quicktime, MOV, PICT, PPM, PM, MCAM, OBJ
No RED, but even if it said so, it's still would be transcoded first...

 

[Mark L. Pederson]

Again, guys, anybody, who had spent 30 seconds in any high end DI facility would know, that ALL grading for ALL major movie releases is done off DPX.

Yes Jake this true TODAY, but I assure you, it's not true in the future.

This about this. Every feature film deliverables document I have seen in the last 9 months includes a DCDM (Digital Cinema Initiative Distribution Master) - even low budget indies that were picked up by small distribution companies. The DCDM includes frame sequences, by reel, in 2K or 4K 16-bit TIFF in XYZ color space.

So, yes you can make a film-record out from the DCDM, and you can also make DCPs from the DCDM - however - what happens 99% of the time in a "high end DI facility" today - is that the entire DI pipeline is in 10-bit LOG DPX - the film-record out is done with those files (10-bit LOG DPX) and DCPs are most often created directly from the 10-bit LOG DPX - and then, after the fact - a DCDM (with 16-bit TIFF) is created FROM the 10-bit LOG DPX.

So, we are already at 12-bit sensors with 14 and 16-bit just around the corner. And color processing in panels and projectors is already passing 10-bits.

It's easy to fixated on how the big "high end DI facility" do things - and how "ALL grading for ALL major movie releases is done" - but it's also import to understand that things are changing NOW.

It doesn't matter to me how long Technicolor and the other big boys stay in 10-bit log - I'm taking the Offhollywood pipeline to 16-bit in 2010 because that, I believe, is the future.

And with respect to cost - it is much cheaper to hold a feature film in 16-bit files today than to hold a feature film in 10-bit log DPX a year ago.

 

[Lucas Wilson]

1. Unless material shot on Red, 100% of all DI is done in 10 bit LOG DPX. Of coarse, I'm simplifying things a bit, but anyone who had spent any time working at any of the "Big 5" or other top DI companies would know it. Yes, there are few bits of open EXR and 16 bit TIFFs, but not in any significant number. Why? Pure and simple-economics. Same reason, why 4k DI isn't as significant, as some would like it to be.

This will not be true for long.

http://www.oscars.org/science-technology/council/projects/iif.html

The Academy is well down the road of specifying a new file format that will be widely accepted for high-resolution postproduction. It's based on a 16-bit float format similar to EXR.

Several manufacturers are already quietly working on this, and the public rollout will happen sooner than you think.

Lucas


Lucas Wilson
--------------
Director, Business Development
ASSIMILATE, inc.
LA, CA, USA

 

[Mark L. Pederson]

This will not be true for long.
Lucas


Lucas Wilson
--------------
Director, Business Development
ASSIMILATE, inc.
LA, CA, USA

What he said. What I said.

 

[M Most]

This will not be true for long.

http://www.oscars.org/science-technology/council/projects/iif.html

The Academy is well down the road of specifying a new file format that will be widely accepted for high-resolution postproduction. It's based on a 16-bit float format similar to EXR.

Several manufacturers are already quietly working on this, and the public rollout will happen sooner than you think.

I am very curious as to what Red has to say about ACES (the proposed Academy internal format) and what level of support they are prepared to offer in terms of developing an IDT (input data transform, essentially a characterization of the front end capture device) for it. I agree that this is likely where the industry is heading, and if Red wants to be accepted in the mainstream industry (I don't know if they do or they don't, but their likely target market for Epic indicates that they do) they would do well to become part of that solution rather than continue exclusively on a proprietary path.