Welcome to our community

Be a part of something great, join today!

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

RubberMonkey & Baselight settings?

Robin Moran

Well-known member
Joined
Dec 26, 2007
Messages
133
Reaction score
0
Points
0
Age
50
Location
Jakarta, Indonesia (currently)
Website
www.robinmoran.com
Hi,

I'm currently in the process of conforming my project using RubberMonkey to go into Baselight. Making DPX for them. My question is does anyone know if I can use RED Log? Or do I have to go to PDLog985, PDLog685, or Lin? I'm avoiding Lin (guessing it's linear) so that the grader has more play in Baselight. Please advise.

P.S. This is not a cinema finish.

P.P.S. sorry for second posting of the same thread. thought a general workflow thread would get a faster response.
 
Hi,

I'm currently in the process of conforming my project using RubberMonkey to go into Baselight. Making DPX for them. My question is does anyone know if I can use RED Log? Or do I have to go to PDLog985, PDLog685, or Lin? I'm avoiding Lin (guessing it's linear) so that the grader has more play in Baselight. Please advise.

Technically, you can use whatever you want. Practically, you should ask the facility and/or the colorist what THEY want.
 
Cheers guys. Appreciate it. The facility has never graded RED using DPX RED Log. They've graded DPX Lin, which is why I asked if anyone has any experience using the different Log settings for Baselight. I saw a post with a person saying that the facility wanted PDLog685.

Big T, saw your tests a month ago. Brilliant stuff. Glad to see quick solutions for jobs that need quick turnarounds.
 
Cheers guys. Appreciate it. The facility has never graded RED using DPX RED Log. They've graded DPX Lin, which is why I asked if anyone has any experience using the different Log settings for Baselight. I saw a post with a person saying that the facility wanted PDLog685.

If you're not intending to record to film, and are looking at a video finish only, the "best" choice - or at least my "best" choice - is to use Redlog, whether they have used it before or not. The advantage of Redlog over, say, Rec709 (also a good choice) is that although you have to put in a negative offset and add contrast to get the image in the proper range, in doing so you're actually minimizing noise, which tends to be in the lower ranges of the image. All values are being pulled down, and nothing is being pulled up. Not to mention that you get a bit more highlight protection due to the higher values being log encoded, which creates a bit of a "knee" to the highlight falloff. The Redlog curve is gentle enough to be corrected without the need for a conversion LUT, so the correction for video output can be pretty straightforward, have lots of range, have better highlight protection, and be very, very clean. In my opinion, it's the best option if you're not working directly from the R3d files - and sometimes even if you are.

Just one opinion, though.
 
Mike's opinion is right though. Redlog wil give you some great range. I would avoid pdlog 685 it can introduce banding in the midtones.
 
I've already prepped the DPX using REDLog. I'll keep you guys posted on how it handles in Baselight. Tx.
 
Hey clueluzz, I assumed you'll grade your footage at G1 Post Group, right?
Just give them REDLog, they will know what to do.

Say my hello to Ben.
 
If you're not intending to record to film, and are looking at a video finish only, the "best" choice - or at least my "best" choice - is to use Redlog, whether they have used it before or not. The advantage of Redlog over, say, Rec709 (also a good choice) is that although you have to put in a negative offset and add contrast to get the image in the proper range, in doing so you're actually minimizing noise, which tends to be in the lower ranges of the image. All values are being pulled down, and nothing is being pulled up. Not to mention that you get a bit more highlight protection due to the higher values being log encoded, which creates a bit of a "knee" to the highlight falloff. The Redlog curve is gentle enough to be corrected without the need for a conversion LUT, so the correction for video output can be pretty straightforward, have lots of range, have better highlight protection, and be very, very clean. In my opinion, it's the best option if you're not working directly from the R3d files - and sometimes even if you are.

Just one opinion, though.
This is really interesting mmost.
When I use REDLog in Scratch and then I compare it to the DPX that I've been exported using REDLog, I see there is a difference in shadow area.
And I really like the DPX one.

But this doesn't happen when you use PDLog (at least I don't notice it).
 
pvillow? You based in jakarta too?
 
This is really interesting mmost.
When I use REDLog in Scratch and then I compare it to the DPX that I've been exported using REDLog, I see there is a difference in shadow area.
And I really like the DPX one.

But this doesn't happen when you use PDLog (at least I don't notice it).

In the latest version of Scratch, there's a setting under Process called "RedRawLog." There is a user settable gamma setting attached to it. This is not the same as the Redlog LUT. If you pass the raw file directly (i.e., set Process to Camera RGB or Redspace for the color matrix), apply the Redlog LUT in the Matrix LUT slot, and do all color correction on top of that (i.e., on a scaffold) it should be exactly the same as processing the R3d file through, say, Redline with Redlog gamma, as you're presenting the LUT with the linear light representation in both cases. I've found that to be true in the past, but I might check it again since you're bringing it up. One of the mistakes commonly made is to put the Redlog LUT in the View LUT slot. This will not do the same thing as what I just described, because you're changing the pipeline and performing color correction prior to the LUT.
 
In the latest version of Scratch, there's a setting under Process called "RedRawLog." There is a user settable gamma setting attached to it. This is not the same as the Redlog LUT. If you pass the raw file directly (i.e., set Process to Camera RGB or Redspace for the color matrix), apply the Redlog LUT in the Matrix LUT slot, and do all color correction on top of that (i.e., on a scaffold) it should be exactly the same as processing the R3d file through, say, Redline with Redlog gamma, as you're presenting the LUT with the linear light representation in both cases. I've found that to be true in the past, but I might check it again since you're bringing it up. One of the mistakes commonly made is to put the Redlog LUT in the View LUT slot. This will not do the same thing as what I just described, because you're changing the pipeline and performing color correction prior to the LUT.
I applied the REDLog LUT in the Matrix LUT slot only.
And I compare it to the DPX that I exported using REDLog in Redline.
I was using v4 at that time.
 
I applied the REDLog LUT in the Matrix LUT slot only.
And I compare it to the DPX that I exported using REDLog in Redline.
I was using v4 at that time.

I'll look at it again when I can find some time, but the only difference I can think of would be the fact that Redline is completely processing the image to 12 bit RGB prior to applying the LUT, while Scratch is doing essentially a "quick debayer" to RGB prior to the LUT transform. I think we're probably getting into processing differences that are really only known to the authors of Redline - i.e., the coders at Red - and Scratch - i.e., Assimilate's coders. Either way, I can't imagine that the differences are all that significant, as each method is using similar techniques to achieve the linear light RGB image, and the same LUT.
 
I'll look at it again when I can find some time, but the only difference I can think of would be the fact that Redline is completely processing the image to 12 bit RGB prior to applying the LUT, while Scratch is doing essentially a "quick debayer" to RGB prior to the LUT transform. I think we're probably getting into processing differences that are really only known to the authors of Redline - i.e., the coders at Red - and Scratch - i.e., Assimilate's coders. Either way, I can't imagine that the differences are all that significant, as each method is using similar techniques to achieve the linear light RGB image, and the same LUT.
It's not that significant.
But I just curious about the reason behind it.
And it makes me more curious when I found that it happens only with REDLog.

Anyway, thanks for your time mmost.
I'll wait for your test result.
 
Back
Top