Beginner into offline RED workflow

[jake blackstone]

Jake, just because you keep repeating this doesn't mean it's true.

Film is not RED. The justifications for pushing film scans into a log space do not apply to RED. You are correct that when done properly, a RED -> Log workflow will look awesome. Go look at "Knowing." It was graded in Log Space on a FilmMaster and looks friggin fantastic.

RED is not "distributed evenly along a LIN curve." It is a sensor with its own unique non-linearities. Do you really think that a CMOS sensor with a Bayer filter responds perfectly evenly across the spectrum? If it does... well then I guess Graeme can stop working on making things better!

You do not know RED's curves - they don't publish them and I kind of doubt you've done a full profiling of the sensor chromacity characteristics with ideal glass in a test environment. If you don't know what the source curve is, then you can't create an accurate LOG representation. Film doesn't "just work." There is a TON of research and years of empirical testing that has been done to establish the correct procedures. And that's with published, independently verified source profiles from the film manufacturers. Making assumptions that the Cineon math will "just work" for RED can get you into a lot of trouble.

This is not to say that you can't get great results - you can, and lots of people do all the time. But there is a reason that *all* the software manufacturers want to work with the RAW data - because it is more accurate, the math is cleaner, and a good end result is more easily attained.

You don't see all the vendors saying, "gee... LOG is perfect! We'll just use that. No need for the RAW data." No - they ALL want to work with RAW data. Why do you think that is? For marketing purposes?

This has nothing to do with SCRATCH, and you talking about "secret sauce" and "fairy dust" just obscures the facts.

Lucas
-----
Irritated at Starbucks
ASSIMILATE, inc.
LA, CA, USA

Luki. With all due respect, could you please tell me, when did I say that the Log transcode "just work"?
That is precisely why I'd said this "LOG DPX conversion specifically designed to be able to map the linear 12 bits into 10 bit LOG, especially preserving the highlights. If you still have both problems with lifted blacks and or blown out highlights after r3d to DPX conversion, than I would suggest better "pregrade". Yes, you can't "just do it" and think that you have the whole information. But once RAW is properly encoded into LOG, then data is just as precise. It is obvious, that it would be much better for everyone, if Scratch wasn't given the privileged position on the SDK and the playing field then would have been even, but given realities, LOG transcode is an excellent workaround. I stand by my statement on the "fairy dust". And thank you for making my point with Knowing

 

[Lucas Wilson]

Luki. With all due respect, could you please tell me, when did I say that the Log transcode "just work"?

In an earlier post, you stated,

"Once it's properly mapped into the LOG curve of DPX format, you're then able to represent the original 12 bits of linear data in it's entirety, even with 10 bits. You lose nothing and there is NO compromise. Film traditionally had always been scanned for DI workflow in this manner and it just works."

Lucas

 

[jake blackstone]

In an earlier post, you stated,

"Once it's properly mapped into the LOG curve of DPX format, you're then able to represent the original 12 bits of linear data in it's entirety, even with 10 bits. You lose nothing and there is NO compromise. Film traditionally had always been scanned for DI workflow in this manner and it just works."

Lucas

Correct, in that sentence I was talking about film scanning, not LOG conversion of RED RAW.

 

[Peter Moretti]

romy,

What I meant by the above statement is that, when reading a list from a fairly complicated offline, Scratch is limited in its ability to deal with complicated transitions, effects, speed changes, or titles from an offline. You want to make sure you're bringing in a fairly clean list into Scratch for your conform and re-linking.

Please excuse my ignorance, as I'm still quite new to this world.

Since all professional grading platforms can't deal with "complicated" effects like cross fades, wipes titles, how are these effects applied? Does this mean that the vast majority of effects that Avid and FCP have are useless if the material is going to be graded on an outside platform?

Thanks much.

 

[jake blackstone]

Please excuse my ignorance, as I'm still quite new to this world.

Since all professional grading platforms can't deal with "complicated" effects like cross fades, wipes titles, how are these effects applied? Does this mean that the vast majority of effects that Avid and FCP have are useless if the material is going to be graded on an outside platform?

Thanks much.

Color grading is just that- color grading. Said that, cross dissolves you had just mentioned will work just fine but not wipes. Also speed changes can be applied as well under certain conditions, but this is not recommended, as there is no motion estimation employed. In the old days there was a limited number of wipes used and those could be included in EDL with a special wipe number, that some of manufacturers followed. But today this situation is not as simple and that is why any kind of wipes have to be done during final assembly after the export from color grading. If that doesn't work for you, than you can always render conformed ProRes out of FCP and just color that.