Beginner into offline RED workflow

[romy]

Hi
I'd like to test my information regarding the RED workflow and grading the R3D on the Scratch..
so please if anything missing tell me...

1st>>i import the MOV reference files created at the R3D folder and edit it on the FCP..

2ed>>export the EDL

3ed>> go to Scratch..import the R3D files,then load EDL then assemble it by the files in the construct..

then i go!

does i have any setp?
or did i skipped any step?


Regarding the referance QT..which one is better??
+ that mean i must keep the R3D files on the same hard disk i import the QT from? right?cuz it is referance files..

Plz if there is any trick i should know i'll b apprciated..

Best regards
Romy

 

[JD Marlow]

That's essentially the idea --- just note that Scratch really can't deal with much more than crossfades when it comes to getting the list from your offline. Someone please correct me if I'm wrong about that...

When you do go to conform, make sure you have all your R3D Media together (in its original folder structure).

 

[romy]

"Scratch really can't deal with much more than crossfades when it comes to getting the list from your offline"

what do u mean by this?

 

[John Tissavary]

1st>>i import the MOV reference files created at the R3D folder and edit it on the FCP..

correct. _H=1/2 res, _M=1/4 res, _P=1/8 res.

2ed>>export the EDL

right again! CMX3600 is the format, there are specific settings necessary in the edl export dialogue. Most important is to understand that Scratch (and just about all other DI tools) do not use multiple layers like FCP, so everythign needs to be on a single video track. Also, in the EDL export dialogue, make sure to set all audio tracks to 'none'.

3ed>> go to Scratch..import the R3D files,then load EDL then assemble it by the files in the construct..

exactly. load all r3d files first, then assemble via EDL. After you've checked your conform against a reference movie generated from your FCP timeline, you're ready to grade.

Regarding the referance QT..which one is better??

there is no 'better' in my opinion. Whatever runs smoothly on your system is fine. These are used _only_ to edit story and generate an EDL, so it really doesn't matter.

+ that mean i must keep the R3D files on the same hard disk i import the QT from? right?cuz it is referance files..

Yes, keep the directory structure in tact, and don't rename the reference movies unless you want a headache during the conform process.


cheers,

John T.

 

[JD Marlow]

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.

 

[jake blackstone]

load all r3d files first, then assemble via EDL. After you've checked your conform against a reference movie generated from your FCP timeline, you're ready to grade.

John T.

Don't forget in Scratch to apply a correct color space LUT. Now you're ready to grade

 

[jake blackstone]

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.

This rule applies to all of color grading software, not just Scratch.

 

[romy]

Don't forget in Scratch to apply a correct color space LUT. Now you're ready to grade

sory?
what do u mean exactly?

romy

 

[jake blackstone]

sory?
what do u mean exactly?

romy

You need to apply Rec-709 or Redspace LUT for video deliverables or Redlog LUT for DCI and filmout.

 

[romy]

You need to apply Rec-709 or Redspace LUT for video deliverables or Redlog LUT for DCI and filmout.

But the d.o.p usually light and make presets of the image on the redspace.lut..

So when i change it to the REC709..i see colors diffrent than what he was watching during shoting!

same for the REDLOG..

that mean he should from begining define what is his output will be then shot in its preset in the camera?

sorry if am ignorant about this..
but i wanna to understand..

 

[John Tissavary]

You need to apply Rec-709 or Redspace LUT for video deliverables or Redlog LUT for DCI and filmout.

I disagree with that statement, and I'm not the only working colorist that stays away from applying LUTS.

LUTs are very useful for adapting a display to a different target one (monitor to film, DCI, etc...), but, I rarely use LUTs for manupulating color. And since raw lin and raw log are now available in Scratch I find myself using these more often than rec709 or redspace in the rednode.

cheers,

John T.

 

[Juan M.P.]

I disagree with that statement, and I'm not the only working colorist that stays away from applying LUTS.

LUTs are very useful for adapting a display to a different target one (monitor to film, DCI, etc...), but, I rarely use LUTs for manupulating color. And since raw lin and raw log are now available in Scratch I find myself using these more often than rec709 or redspace in the rednode.

cheers,

John T.

hey john can you be more specific about what you mean? that would be great

 

[jake blackstone]

I disagree with that statement, and I'm not the only working colorist that stays away from applying LUTS.

LUTs are very useful for adapting a display to a different target one (monitor to film, DCI, etc...), but, I rarely use LUTs for manupulating color. And since raw lin and raw log are now available in Scratch I find myself using these more often than rec709 or redspace in the rednode.

cheers,

John T.

John. You're making two assumptions. One, that your way is the only correct way and two, that everyone is grading with Scratch using r3d Personally, I found grading Log DPX in Lustre or Baselight after mapping RAW to Log curve by applying RedLog gamma curve to r3d files serves me best for just about any type of deliverables. And, no, given a chance, I do not have the desire to grade in Scratch. BTW, Filmlight has the same opinion on the subject of using the RedLog. But, if you're happy with your approach, great...

 

[John Tissavary]

Nowhere do I remember saying my way was the only way...

The lut thing is fairly simple: 1D luts have a limited number of code values, depending on the bit depth of the particular lut format. A floating point curve has an order of magnitude more 'code values', therefore it will be a smoother transformation matrix.

Re. tools of choice, I get it. There are plenty of colorists that prefer to work in one package or another, and working in a familiar environment is important when $$$ are on the line.

But I've also done several R3D to film grades using Baselight & Scratch and discovered some things for myself that keep me with Scratch specifically for R3D filmout work, even though I have regular access to several Baselight systems.

It's my opinion... but my opinion was formed from some specific experiences:

I graded an R3D clip from a recent motion picture shot on Red as best I could in linear to establish a 'hero' look for that shot. I then used Redlog to convert the same shot from R3D to log dpx, loaded in Baselight with Truelight 2383 emulation through a well calibrated Barco 2k projector.

I found Redlog to be problematic right out of the gate - highlights were compressed and shadows had a tendency to be too thin & fall apart rather quickly. No amount of noodling got back the detail that was simply pushed out of the log dpx in the conversion process. Not every shot is going to suffer from this, but I picked a worst case scenario - lots of near-clip highlights, lots of shadow with details (the one that really showed the problem was a metal mixing bowl - the gradients really show off how fragile this zone was).

The facility I was working with ended up developing a custom transformation matrix using some Kodak color science for a particular print match so all the code values landed on the correct targets in Baselight & the filmout. After seeing these results, I can tell you without any hesitation that I avoid rec709 and Redlog whenever possible for filmout from R3D footage. With Red Raw Log mode I don't need them - I've got 12 bits of R3D presented to me, mapped in log. A slight advantage, but useful.

Until other systems can work all 12 bits, I believe I get the best results from Scratch, where I have 2 more bits of data, and don't have to commit to a set of code values that are sub-optimal for the chosen print stock. Coupled with Cinespace or other color management aids, I really like the results I get from R3D on 2383 stock.



cheers,

John T.

 

[Martin Tlaskal]

Until other systems can work all 12 bits, I believe I get the best results from Scratch, where I have 2 more bits of data, and don't have to commit to a set of code values that are sub-optimal for the chosen print stock. Coupled with Cinespace or other color management aids, I really like the results I get from R3D on 2383 stock.

Hi John,

Just wanted to clarify something - Baselight has supported 16bit processing internally since the very beginning. However, making full use of it is obviously highly dependent on the bit depth of your input images. If you export 16bit images out of your R3D conversion tool, you should be able to get BL to do what you want with whatever curves you like.

Alternatively, you could load the R3D directly into BL and achieve similar results.

Regards,

-Martin

 

[jake blackstone]

Nowhere do I remember saying my way was the only way...

The lut thing is fairly simple: 1D luts have a limited number of code values, depending on the bit depth of the particular lut format. A floating point curve has an order of magnitude more 'code values', therefore it will be a smoother transformation matrix.

Re. tools of choice, I get it. There are plenty of colorists that prefer to work in one package or another, and working in a familiar environment is important when $$$ are on the line.

But I've also done several R3D to film grades using Baselight & Scratch and discovered some things for myself that keep me with Scratch specifically for R3D filmout work, even though I have regular access to several Baselight systems.

It's my opinion... but my opinion was formed from some specific experiences:

I graded an R3D clip from a recent motion picture shot on Red as best I could in linear to establish a 'hero' look for that shot. I then used Redlog to convert the same shot from R3D to log dpx, loaded in Baselight with Truelight 2383 emulation through a well calibrated Barco 2k projector.

I found Redlog to be problematic right out of the gate - highlights were compressed and shadows had a tendency to be too thin & fall apart rather quickly. No amount of noodling got back the detail that was simply pushed out of the log dpx in the conversion process. Not every shot is going to suffer from this, but I picked a worst case scenario - lots of near-clip highlights, lots of shadow with details (the one that really showed the problem was a metal mixing bowl - the gradients really show off how fragile this zone was).

The facility I was working with ended up developing a custom transformation matrix using some Kodak color science for a particular print match so all the code values landed on the correct targets in Baselight & the filmout. After seeing these results, I can tell you without any hesitation that I avoid rec709 and Redlog whenever possible for filmout from R3D footage. With Red Raw Log mode I don't need them - I've got 12 bits of R3D presented to me, mapped in log. A slight advantage, but useful.

Until other systems can work all 12 bits, I believe I get the best results from Scratch, where I have 2 more bits of data, and don't have to commit to a set of code values that are sub-optimal for the chosen print stock. Coupled with Cinespace or other color management aids, I really like the results I get from R3D on 2383 stock.



cheers,

John T.

John. When you say "I disagree with that statement", to me that statement sounds as a fairly dogmatic in tone. The statement implies, that my workflow is just plain wrong. Do you still disagree, that Rec-709 or RedSpace should be used for video deliverables? As long as we're talking about personal workflow preferences, personally, I only use RedLog gamma encoded 10 bit LOG DPX, regardless of the deliverables. At the end, for video deliverables I just use, DCI to Rec-709 LUT. I know, you do not like LUTs, but it works for me
I need to point out, that the Scratch workflow advice applies to a very narrow slice of people, who only use Scratch, while completely missing much larger group of people, who uses tools other than Scratch and do use DPX transcode.
CineSpace generates 3D LUT with user's specified precision all day long, which Lustre can happily use, even in hardware, if needed. Not a problem for TrueLight as well...
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".
You're comparing apples and oranges. Yes, in RED RAW code you have 12 bits of usable data but it's distributed along a straight line. 10 DPX LOG isn't and that is why Cineon and later DPX were developed in order to be able to represent the original 12 bits of linear data. One can look at this process as a way of lossless compression. 10 bit Log DPX works very well in the DI pipeline and is able to handle even film with it's much wider dynamic range. 16 bit floating point precision now is pretty much the standard in the industry, now that even Autodesk jumped on board.

 

[John Tissavary]

Hi John,

Just wanted to clarify something - Baselight has supported 16bit processing internally since the very beginning. However, making full use of it is obviously highly dependent on the bit depth of your input images. If you export 16bit images out of your R3D conversion tool, you should be able to get BL to do what you want with whatever curves you like.

Alternatively, you could load the R3D directly into BL and achieve similar results.

Regards,

-Martin

Agreed, of course. Baselight's color science, image processing, are second to none, and I'm a proud user of Baselight.

The only distinction I'm trying to make is that, with the exception of Scratch, user must commit to resampling 12bits of RAW into 10bits of log code values.

It's not a huge compromise, but I have had plenty of shots where it was (or would have been) nice to have all 12 bits. When the Red SDK allows all developers access to the RAW data, instead of passing requests for debayered RGB, then this will be a moot point, of course.

cheers,

John T.

 

[jake blackstone]

Agreed, of course. Baselight's color science, image processing, are second to none, and I'm a proud user of Baselight.

The only distinction I'm trying to make is that, with the exception of Scratch, user must commit to resampling 12bits of RAW into 10bits of log code values.

It's not a huge compromise, but I have had plenty of shots where it was (or would have been) nice to have all 12 bits. When the Red SDK allows all developers access to the RAW data, instead of passing requests for debayered RGB, then this will be a moot point, of course.

cheers,

John T.

John. You still missing the point. It has nothing to do with Baselight, Truelight, Lustre, DaVinci, Rising Sun or any other specific product or manufacturer. As I already wrote, yes, in RED RAW code you have 12 bits of usable data but it's distributed evenly along LIN curve. 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. One can look at this process as a way of lossless compression. Insistence on working with 12 bits LIN vs 10 bits LOG doesn't allow for any more precision. You can always use 12 or 16 bit DPX LOG transcode, but those extra bits of data will be redundant and will add nothing at the end. There is really no need to promote this new Scratch secret sauce, when in reality it's the same old fairy dust

 

[John Tissavary]

John. You still missing the point. It has nothing to do with Baselight, Truelight, Lustre, DaVinci, Rising Sun or any other specific product or manufacturer. As I already wrote, yes, in RED RAW code you have 12 bits of usable data but it's distributed evenly along LIN curve. 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. One can look at this process as a way of lossless compression. Insistence on working with 12 bits LIN vs 10 bits LOG doesn't allow for any more precision. You can always use 12 or 16 bit DPX LOG transcode, but those extra bits of data will be redundant and will add nothing at the end. There is really no need to promote this new Scratch secret sauce, when in reality it's the same old fairy dust

This is not about Scratch or secret sauce, and I have nothing to promote.

I have witnessed compromises when doing redlog and straight PDlog color matrix transforms from Red's 12bits of linear raw data (not the same as 12bits of RGB) to 10bit log.

I was involved in some tests of Red footage, shot for a motion picture, that was transcoded to DPX via Redline using the redlog LUT and saw for myself the compromise that introduced. That LUT was subsequently abandoned by the colorist and color scientist using Baselight at a DI facility in LA. The highlights were compressed and shadow data was thin because the redlog matrix did not hit the targets sufficiently well, resulting in a loss of data.

Subsequently, a custom color transform matrix was developed by their color scientist to overcome that problem (I guess that constitutes secret sauce...). When the code values from 12bit lin were remapped using this new LUT the highlights, shadows, and color curves were a better match the highlights were no longer compressed, and the shadows were far less prone to 'fall apart' in grading. Unless I'm missing something obvious, that is evidence that 12 to 10bit lin to log encoding is not quite as straightforward, bulletproof, and lossless as you insist when going to Vision print stock.

I know Redlog ought to work, it should take the sensor (source) and film (target) colorspaces into consideration when applying the code value transforms, but I've seen it not work in a number of situations.

That's it for me on this discussion...

thanks,

JT

 

[Lucas Wilson]

John. You still missing the point. It has nothing to do with Baselight, Truelight, Lustre, DaVinci, Rising Sun or any other specific product or manufacturer. As I already wrote, yes, in RED RAW code you have 12 bits of usable data but it's distributed evenly along LIN curve. 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. One can look at this process as a way of lossless compression. Insistence on working with 12 bits LIN vs 10 bits LOG doesn't allow for any more precision. You can always use 12 or 16 bit DPX LOG transcode, but those extra bits of data will be redundant and will add nothing at the end. There is really no need to promote this new Scratch secret sauce, when in reality it's the same old fairy dust

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