More colour space - RedLog -> Linear Light

[Hugh]

Hi all,

I've not been around on here since a thread I posted last december, and, to be honest, I'm now back with the same question, although this time for the new build.....

We're just about to start working on a film that is currently being shot on a RED camera, and we want to make sure that we've got our heads around the colour-space side of it.

We are a VFX company that works almost exclusively on features. We've worked with standard film scans, SI2K and Viper footage, so we're not scared of new colour spaces - we just want to make sure that we have a scientifically accurate conversion from the files to a format where the pixel values are linearly representative of the number of photons hitting the sensor.

I've not had a chance to put a camera through its paces, which would involve doing tests at different exposures/lighting conditions to test the response of the different export formats, otherwise I'd be somewhat happier to figure this out on my own.

One of the test shots that we have been sent included a section where they stopped the camera down by 1, 2, 3 and 4 stops. Using this, I was able to at least get a rough approximation of the black point (quite lifted - about 0.132, or the equivalent of 135 cineon points)

Leaving the dGamma at 1 (or 1.7 in Shake, as it does an internal division by 1.7), as that's what | want my result to be, I found the best nGamma to be in the region of 1.36 (a far cry from the default Cineon nGamma of 0.6).

The white point made absolutely no difference to my test - as it's just adjusting the brightness of the Linear result (we're more than used to dealing with >1.0 values in comps). Seeing as my test was just based on changing the brightness to adjust the exposure in Linear, followed by a Lin->RedLog at the end, they all concatenated and I saw no change in the result. (Setting the white point to 135.001 was interesting... I ended up with float values in the 6-figures... possibly closer to the actual number of photons! Not practical, but fun to see)


However (after all of that), I'm still not convinced by the result. Whether this is down to the fact that what I thought was a stop, 2 stops etc down in camera was actually not, which gave me a bad base to work from, or something else, I don't know. Or maybe I'm just not trusting the numbers enough. I'd expect, though, when I've got a linear image, to be able to convert it to stardard cineon log and put it through a film lookup cube and have it look good, which I can't do with this at the moment.


So, does anyone have any thoughts? Has anyone done more investigation into the conversion and can let me know some details?

Thanks, all help very gratefully received!

 

[Chris Swinbanks]

welcome to our world, Hugh!
It's still a mindf%$# in VFX, and probably really depends on how far down the pipe you will be travelling in your own facility.
Either choose the transfer curve options presented to you by Red/Assimilate, or shoot your own tests and confirm for yourself how you want to work.
PM me and I can pass on some basic information to help, if you like
Regards
Chris

 

[Hugh]

Thanks, Chris, it's good to know that this part is still getting a lot of other people.

We're just a VFX place, so, like most other projects, we'll be receiving DPXs, and delivering the same back.

At some point, I do definitely want to get a camera in and do some of my own tests, but for now I'm just trying to get as much info on it as I can.

I shall certainly pm you.

 

[Ziggy Uszkurat]

Hugh,

You might want to take a look at ProLost's take on this issue:

http://prolost.blogspot.com/2008/03/red-log.html

Ziggx

 

[Hugh]

I had a look at Stu's thoughts on it, and I believe that those were initially from Build 15 (or earlier)

I'm going to try to get permission to post some examples of what I've been working with (with faces blurred, I'd imagine), so you can understand where I'm coming from so far...

 

[Chris Swinbanks]

At some point, I do definitely want to get a camera in and do some of my own tests

I've just unpacked mine...!
Just haven't got ALL the bits as yet...

Just noticed that you said you're receiving DPX's... then thats it.. someone else has already locked you into a pipeline methodology... sounds like if you're one of possibly several houses that might be working on a project (not uncommon as we know) then the best thing to do is deliver back much as you received it... with effects of course.

 

[Hugh]

That's not a problem for us at all.

We're the only VFX place working on the film, but the DPXs are also being sent over to the DI place for them to do their stuff on it.

The colour space of the DPXs are not necessarily an issue - they could be in inverted 32-bit float log HLS for all I care, but I need to be able to have a conversion that will convert this to floating point linear-light RGB (and then back to the original space again).

Our pipeline is used to dealing with DPXs in and out. And we're used to different colour spaces (I think I mentioned the SI2K and Viper cameras earlier). It's just figuring the colour space and what has happened to the values from sensor->DPX that I need to do.

 

[Hugh]

Warning: I seem to be having some image embedding issues. I'll attach all the images to the post too, so if you just see file names and no images, reference the attached.


Some images to explain where I'm coming from, and what I've tried so far:

First off, an image with 5 source frames in:

red_no_regrade.jpg

The exposure change on these 5 frames was done in-camera, and slated, so I do know exactly what it was.
The centre image is my base reference. You can see the DoF increasing as they stopped down the lens.

My initial plan was to come up with a LogLin conversion so that when I converted these images to Lin, multiplied by 2, 4, 8 and 16 (for -1, -2, -3 and -4) and then applied the inverse conversion, I'd end up with the same effective result, or at least have the blacks in the same kind of place.

First off, I tried this with a standard Cineon LogLin:

red_regrade_cineon.jpg

This sets the black point too low, as the blacks get lifted too much in the -4 stops version. It also loses a lot of its contrast, indicative of the gamma curve being off.

Then I tried Stu's numbers (which he posted back in March, so I suspected could have been to do with build 15):

red_regrade_prolost.jpg

The black point being at 0 obviously causes all sorts of problems here. A somewhat more extreme example of the problems that came up with the Cineon conversion.

So, I looked at this image result, and played with the black point and the nGamma values until I got something where they all looked similar:

red_regrade_custom.jpg

The blacks hold, to a certain extent, but there is a certain amount of contrast loss, which I'd want to spend a bit more time trying to recover.


That's where I've got to so far, anyway. If anyone's got any more thoughts above and beyond, I'd love to discuss this further....

 

[Jason Rodriguez]

Have you tried using something like a Stouffer chart (4110) in order to capture the entire dynamic range of the camera without having to adjust the iris of the camera, and then use a best-fit function calculated from the step-wedge to re-linearize the camera?

For instance, depending on the lenses used to shoot the test, as well as the lighting scenario, actually adjusting the iris may not have the precision you are wanting, as these adjustments may be introducing some other scene-dependent issues which are causing the data inconsistencies you're mentioning.

So for instance, what you could do is shoot a Stouffer, then using Excel's curve fitting tools, obtain an equation that best-fits the data from the step-wedge. From there once you have a "nice" equation, you can create an inverse transform that should relinearize the signal.

Using Shake, you can then use a colorX node to input your relinearization equation if it's something that is not quite straight-forward enough to input into the Cineon conversion node.

 

[Hugh]

thanks Jason -that's exactly the kind of thing that I want to do. I just haven't been able to run my own tests using the camera yet - I've just been working with the test footage that I was sent.

I will, at some point before the footage is actually turned over to us, do some extensive tests.

 

[Stu Maschwitz]

I don't think that there's anything in build 16 that changes the RED Log formula, but I don't know for certain.

My numbers are designed to match a curve provided by RED, and that they do.

I did similar tests, comparing a linear floating-point exposure adjustment to a real, photographed wedge. Like you, I saw differences. I chalked them up to sensor non-linearity, although in truth I was thinking there might be more to it.

-Stu