R3D Color Discussion

[Mark Wilkinson]

ONLY Scratch, RC(X) and RA are native RAW apps. All others apps work off transcoded material.

How exactly does it work in Scratch? Doesn't the RAW file need to be debayered before any real color correction can be applied? I understand how this could be applied non-destructively in the grading data path, but how could an image filter be applied to something that isn't really an image yet?

In the case of Apple's Color, the 16 bit lin transcode is done non-destructively at the first stage - would this be considered a native RAW app?

Thanks.

 

[Lucas Wilson]

How exactly does it work in Scratch? Doesn't the RAW file need to be debayered before any real color correction can be applied? I understand how this could be applied non-destructively in the grading data path, but how could an image filter be applied to something that isn't really an image yet?

In the case of Apple's Color, the 16 bit lin transcode is done non-destructively at the first stage - would this be considered a native RAW app?

Thanks.

Hi Mark,

Actually.... it's Magic. You know - newts and toads and stuff. : )

It's a good question. The RAW file does need to be debayered first. But, because SCRATCH has access to the R3D file format natively, all the color math that comes after the debayering process can be combined with the debayer pass... so that everything happens in less mathematical passes.

What that really means in practical terms is a speed difference.

Because SCRATCH does not have an additional layer to go through, we can process files much faster and with much less of a performance hit than most other applications.

Lucas

 

[Mark Wilkinson]

No alien technology? Disappointing :|

What is the bit depth and format of the data that passes through color correction after the debayering? Is it all 32-bit float? Will the data clip between Primary, Secondary, etc.?

 

[Sidney L. Plaut]

Lucas,

I can't take it anymore Release a mac-based, Rocket Accelerated - affordable Scratch and rule the new world.

W/ easy integration between FCP and Avid mediacomposer or even better make it an editing platform as well. AND stereo capabilities = Be the RED of DI.

In my opinion Apple / FCP package, is evolving very slowly now compared too what it used to. Ive never even seen an Apple /FCP guy on this forum, even though Avid is here. all in all, you guys should move in for the kill

in regards to the actual thread, which I find very interesting, my only grief is that you guys seem very bright, so it puzzles me why you get so upset towards each other over bits and pixles...

best,

Sidney

 

[Lucas Wilson]

No alien technology? Disappointing :|

What is the bit depth and format of the data that passes through color correction after the debayering? Is it all 32-bit float? Will the data clip between Primary, Secondary, etc.?

All processing within SCRATCH is done at 32-bit float, whether you need that kind of precision or not. : )

Lucas

 

[Lucas Wilson]

I can't take it anymore Release a mac-based, Rocket Accelerated - affordable Scratch and rule the new world.

There is a *remarkable* leap between the people who say this would rule the world... and the people who would buy it!

About a year ago, I posted on Reduser an open invitation - if we released SCRATCH on OSX for less than US$10K, how many people would buy it? I don't remember whether I said less than US$10K, or a more specific number like $5K or $7K. That's not actually that critically important. What is important... do you want to know how many positive responses I got?

Seventeen.

Granted, it is a very unscientific poll, but if there is one place where the desire for SCRATCH on OSX is most passionate, it is Reduser. And when I put it out there, I got seventeen people saying "Yeah! I'd buy it!"

Hardly overwhelming, and definitely not a business.

Not trying to pee on your Cheerios, just being the reality police... : )

Look at the Smoke OSX announcement... An incredible piece of software at an amazing price. Hands up - how many people on Reduser have purchased??

Lucas

 

[Nick Shaw]

And as I said before, that also goes for Resolve, Lustre, FilmMaster, Baselight (did I forget something?)...

Can I just note that Baselight can in fact work directly from R3D files (using the SDK) and does not need to transcode to DPX. How many people are actually using it this way is a different matter. One of the stated uses of Filmlight's BLT product is to act as a back-room transcoding station to feed the grading system.

 

[Frank Cueto]

Well, I am in line for a couple ;-)

 

[Frank Cueto]

Can I just note that Baselight can in fact work directly from R3D files (using the SDK) and does not need to transcode to DPX. How many people are actually using it this way is a different matter. One of the stated uses of Filmlight's BLT product is to act as a back-room transcoding station to feed the grading system.

We actually use Baselight exactly like that EVERY day.

One huge advantage is that we grade/monitor at 2K/HD but from the R3D's all the time.
When the time comes to render/process/NR/Sharpen we actually render at 4K and then downconvert that to deliverables (we could do it all the time, but no BL8 here :-(. Excelent results Not only that. we can process at 4K, and monitor what the downconvert is going to look like at the end. All these without rendering. very VERY handy.

 

[Paulo Emílio]

Lucas, next year ( in few days ) we gonna buy 2 osx smoke, could be a SCRATCH on osx. I think, in my opinion, Assimilate is missing the boat.

Happy New Year !

 

[Lucas Wilson]

Lucas, next year ( in few days ) we gonna buy 2 osx smoke, could be a SCRATCH on osx. I think, in my opinion, Assimilate is missing the boat.

Happy New Year !

...and yet nobody has responded yet that they have actually spent the money!

Just saying...

Lucas

 

[Mark Wilkinson]

I suppose Apple Color is sucking too much air out of the room. It has a pretty robust data path, pretty darn good tools, good solid scopes - gets most people most of the way there - leaving fewer buyers in the pro freelance range.

I've worked with Scratch - nice system - but certainly not rock solid with Red Rockets yet - so everybody is still ramping up.

I've pitched out DPX files to DaVinci systems via Clipster recently as well - frankly looks pretty great (10bit log is very deep in spite of all the pixel parsing that goes on) - and it was rock solid. Good client experience -

I hope Smoke gets some traction - Autodesk has a terrible track record on supporting Mac apps - I would be very slow to pull out my checkbook for those guys...

 

[jake blackstone]

Can I just note that Baselight can in fact work directly from R3D files (using the SDK) and does not need to transcode to DPX. How many people are actually using it this way is a different matter. One of the stated uses of Filmlight's BLT product is to act as a back-room transcoding station to feed the grading system.

Hello Nick. It may APPEAR, that grading on Baselight is done directly off R3D files and FilmLight does an admirable job of hiding this complexity, but it still the same old SDK transcode. Only Scratch is capable in operating directly off R3D RAW files. It may be an insignificant difference in practical terms, but a difference nevertheless. Simple example. Say you have a Quicktime and R3D files on the same timeline and you do a dissolve between them. How can Baselight achieve a dissolve between two different codecs? In Baselight case, R3D first gets debayered and then both QT and D3D gets rendered to FilmLight's own uncompressed codec, instead of DPX on other systems and then the dissolve is created from that codec. In case of Scratch, as Lucas had already explained, no prior debayer needed. This question was verified with FilmLight's engineer during the BLT demo. Said that, I find it really interesting, that with RED Rocket™ even Scratch uses the SDK for debayer...

 

[jake blackstone]

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.

Mark. The discussion on this thread started with the rant, that DPX is the worst media format and it should never be used by anyone, who cares about quality. You ended up using my response(s) totally out of context. Just because I had stated the current state of DI doesn't mean in any way, that I'm against technological advance You can't possibly disagree with my assessment of current state of high end DI. I just don't believe in change for sake of change. Everyone would love to have wider dynamic range and, yes, with new cameras it is around the corner. Cudos to you for leading the change. I would be curious to know, if moving to 16 bit color depth will be as seamless and pain free as you hope, while delivering concrete additional benefits to your clients. So, you're preaching to the choir. Nevertheless, 10 bit Log DPX had served the industry with distinction and continue to do so. It is difficult to overstate 10 bit log DPX based robustness, interoperability and familiarity. So, go ahead and try to take this out of context

 

[JonathanF]

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.

I could not have said it better.

J

 

[Mark L. Pederson]

Mark. The discussion on this thread started with the rant, that DPX is the worst media format and it should never be used by anyone, who cares about quality. You ended up using my response(s) totally out of context. Just because I had stated the current state of DI doesn't mean in any way, that I'm against technological advance You can't possibly disagree with my assessment of current state of high end DI. I just don't believe in change for sake of change. Everyone would love to have wider dynamic range and, yes, with new cameras it is around the corner. Cudos to you for leading the change. I would be curious to know, if moving to 16 bit color depth will be as seamless and pain free as you hope, while delivering concrete additional benefits to your clients. So, you're preaching to the choir. Nevertheless, 10 bit Log DPX had served the industry with distinction and continue to do so. It is difficult to overstate 10 bit log DPX based robustness, interoperability and familiarity. So, go ahead and try to take this out of context

Jake - Sorry, I didn't mean to take anything out of context. I was skimmin' a whole lotta threads. As far as moving to 16-bit - will it will be "seemless and pain free" ... I'm 99.9% sure it won't. But, I will learn more, my team will learn more, and we will be better positioned when others change.

As far as "concrete additional benefits to your clients" ... concrete is subjective. I'll give them 6 more bits than the competition. Seems concrete enough for me.

 

[JonathanF]

In Baselight case, R3D first gets debayered and then both QT and D3D gets rendered to FilmLight's own uncompressed codec, instead of DPX and then the dissolve is created from that codec. So, it's essentially the same thing as with DPX

Are we to assume that the Filmlight folks are taking the 16 bit unsigned data from the SDK and smashing it into something less than that, or is their codec able to handle the full depth the SDK's capable of?

If they are indeed stepping on this then that's the fault of their system, but the I highly doubt they would do that.

My experience with the Filmlight/Baselight folks is that they are sensible and highly competent folks and I can't imagine they would do such a thing.

For that reason alone I cannot accept your assertion that this is essentially the same as working with DPX. The bits just don't add up.

J

 

[Lucas Wilson]

I've worked with Scratch - nice system - but certainly not rock solid with RED Rocket™s yet - so everybody is still ramping up..

Hey Mark...

Out of curiosity, where? SCRATCH v5 was only released a few days ago, and up until then, only a few beta customers were using RED Rocket.

The reason I ask is that it is actually very solid at this point, so wondering what you saw, where, and what needs to be fixed.

Best,

Lucas

 

[Lucas Wilson]

Hello Nick. It may APPEAR, that grading on Baselight is done directly off R3D files...

Hi all,

Let me set the record straight on something.

When the world of RED post-production was born, SCRATCH was the only high-end app that could access R3D files without a very time-expensive transcode.

But, things have evolved. The primary reason we do not fully switch to the SDK is because of performance. Because of our history with RED, we had already built an advanced codebase for dealing with R3D... long before the SDK even existed!

As far as raw quality between the way SCRATCH natively handles R3D and the way the SDK handles R3D - there may be a completely insignificant and invisible rounding difference at the LSB. But other than that, at this point, the quality differences are non-existent.

What does exist is a performance gap. Again, just because of the way our relationship with RED evolved, ASSIMILATE has a history of how we deal with R3D. And because we deal natively as opposed to going through an additional layer (SDK,) the way we access via software is significantly faster than the SDK. For anyone familiar with how code works, this is completely logical.

But please don't let any weird speculation start as to why we are using the SDK for RED Rocket vs. our traditional native R3D access. We're doing it because the quality is the same... AND since we are dealing with RED Rocket, performance is not an issue!

SCRATCH's differentiator in the RED world used to be that we were the only company with access to R3D. Those days are over.

Our differentiator now is that we continue to lead the pack in terms of supporting RED's breakneck evolution, and we continue to innovate and offer new solutions for the RED world that are frankly not available on even close to the same level anywhere else.

No other non-RED application supports RED Rocket the same way SCRATCH does. None. No other application can load up 4.5K R3D files, hit play, and get a realtime full-rez decode. No other company is offering a package like Rocket Fuel... bringing the power of RED Rocket to the post community at a price unheard of even a few months ago.

If people are going to argue about workflow - let it be about important differences in application workflow, cost, and availability. Let it be about why some companies are continuing to charge half a million dollars for post tools that others provide for a tenth of the price. Let it be about how Quantel and Filmlight and ASSIMILATE and Apple deal with mixed-format workflows (that dissolve questions is an interesting one) and what we are all going to do about FLUT and Epic and multi-RED Rocket cards for stereo.

But the back-and-forth about what everyone pretty much agrees are visually insignificant processing minutiae... I'm not sure what it accomplishes.

...my US$.02.

Thanks,

Lucas


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

 

[mikeburton]

Hey Lucas,
Any chance that Assimilate will support other native RAW camera formats such as .cine, Arri RAW, SI2K native files?