Log, Lin, 10-bit, 12-bit, etc

[John Tissavary]

I'll give you an opinion (based on plenty of testing).

16 bit linear is the future.

10-bit LOG should just go away.

And I wouldn't be so quick to subscribe to the "all gets dumbed down for distribution and display." That may be true in many or even most cases at the moment - but display technology will continue to rapidly evolve and new distribution platforms are in development.

Shoot 4K +
Post in a 16-bit pipeline

I'm sure you are aware that Scratch 5 gives you the option for 16-bit processing on the RED Rocket™ - and you can also use more than one RED Rocket™ to more that make up for the speed hit you take going to 16-bit processing with 4K debayer. It's now faster than we all use to work with 2K debayer in 10-bit.

Mark, I couldn't agree more.

10bit log was always a hack to limit filesize / bandwidth for Kodak's SGI based Cineon film system from the early 90's (ancient history in terms of computing hardware & software... though it's still one of the greatest systems ever). Time to move on the at least the new millenium...

There are just way too many PITA issues working with LOG, and way to many cost effective solutions that can handle 16bit LIN 2k finishing. Now 16bit LIN 4k uncompressed may be a bit more of a challenge for the time being...

cheers,

JT

 

[Gunleik Groven]

Clipping relative to exposure middle is utterly dependent upon where you place your mid point. The lower you place your mid, the more highlight protection you get.

Some colour correction tools are indeed designed to be driven upon film neg data. That is the reason for developing this route. However, it's not the only way to get superb images. Grading from existing REDLog curve has proven superb for many, and now, grading from REDGamma has proven superb too.

Graeme

A guesstimate here for 10-bit workflows.

RedGamma would be a good startingpoint for most TV-work (except for troubled shots, where redlog will still be the better)

RedLog would be the way to go for DCP/Film grades - for now.

RedColor is the current best startingpoint for either.

G

 

[M Most]

A guesstimate here for 10-bit workflows.

RedGamma would be a good startingpoint for most TV-work (except for troubled shots, where redlog will still be the better)

RedLog would be the way to go for DCP/Film grades - for now.

RedColor is the current best startingpoint for either.

G

I disagree on all but the last point. That's what makes horse races, though.

Redgamma is usually OK, but if you have a "troubled" shot and you're working in a television environment - or even if you're not - you're better off moving to Rec709 gamma, because it gives you a lot of what RedGamma gives you but without the push on the highlights. If your highlights are too hot looking at the shot through RedGamma, your first stop as a fix should be to change to Rec709 gamma and see if you still have the problem. Chances are you won't.

Redlog has no relation to "normal" film gamma curves or processes. Graeme may not see it this way, but as far as I'm concerned Redlog was a scheme to get most of the pertinent information in the 12 bit linear original image into a 10 bit container, without any real consideration as to how that might be used. That in itself doesn't really help you at all in a film grading environment because it has no relationship to a "normal" Cineon curve, and no relationship to film color science. Up until this point - and we haven't seen
RedFilm yet - the best approach for film projects is probably to grade in a gamma encoded (i.e., Rec 709, or P3 with gamma 2.6) color space and use a properly done inverse LUT to retain that look on the film recording (or have your lab do that if they're able to). Anything else and you're fighting odd color anomalies and artifacts created by the print preview LUT as you're grading it. Without the presence of inverse transforms based on film color science, you're compromising what you're getting if you try to "fake" it into a film color space.

That's my view, based on my experience. Your mileage may vary.

 

[Graeme Nattress]

Actually, if your shot is so troubled, you're probably better off lowering the ISO and leaving the REDGamma as it. That would give more room for highlight grading.

Correct. REDLog is utterly designed as a data transfer curve.

Graeme

 

[M Most]

Actually, if your shot is so troubled, you're probably better off lowering the ISO and leaving the REDGamma as it. That would give more room for highlight grading.

I haven't found that to be the case. I've found that on some shots, the values assigned to the highlights (and the "near highlights") by RedGamma are a bit too high, and lowing the ISO setting does not fix that as well as going to the Rec709 curve. If I stay with Redgamma and lower the ISO setting, I sometimes have to use a curve to get the midrange values back to where I want. But as I said, mileage may vary.

 

[Graeme Nattress]

When you get right down to it, there's no one single perfect gamma curve for every shot. And there's more way than one to grade a particular shot.

What is important is that the calculations are done at a high precision from a linear light starting point giving the most flexibility to choose the method you use.

Graeme

 

[Rich Schaefer]

When you get right down to it, there's no one single perfect gamma curve for every shot. And there's more way than one to grade a particular shot.

What is important is that the calculations are done at a high precision from a linear light starting point giving the most flexibility to choose the method you use.

Graeme

Yup!

I have been shooting film for 22 years, the first thing I do in telecine is look at the base set-up then grade it until it looks the way I want.

So what I am saying is I grade/telecine it to look good and tell the story. I don't worry so much about what log as long as it stays in my shows "legal" limits. (Film-outs and FX work exceptions that may have other specific requirements)

Prost,
Rich

 

[Evangelos Achillopoulos]

No, it's not a monitoring LUT. It's a gamma option that takes linear light RED data and maps it to the code values a film camera could have generated from a log scan.

Graeme

Mike for us that can read between the words its clear that Graeme has done the right thing...

Graeme the question is: When?

 

[Graeme Nattress]

When it's ready.

Graeme

 

[Evangelos Achillopoulos]

When it's ready.

Graeme

:drool5:

 

[severin schultze]

Hi all,

I've got a couple of questions about the color and gamma settings in the camera/in RCX...
REC709 and sRGB are common color spaces for correct viewing on HD-Displays?
What are the other spaces good for? Like REDSpace, REDColor and Camere RGB? If one take CameraRGB, what will you get? Is this unprocessed RGB? Why does it look flat compared to REC709 and sRGB? Because of a bigger colorspace that CameraRGB do provide and the display can't display it properly? And what are REDColor and REDSpace settings really doing? It looks similar to the REDspaces to me...
What are the exact characteristics of the different gamma-log-settings? What would i compare the different settings with REDLog, PDLog 985 and PDLog 685? Similar to the colorsettings what is REDSpace and REDGamma about? I guess, sRGB and REC709 are the correct settings and equivalents for the well known standards...
I always get confused about these settings...

Every help is greatly appreciated!! Thanks!

- severin

 

[Graeme Nattress]

CameraRGB is the uncorrected camera data - hence it looks flat because it's a larger colour space than your monitor is expecting.

For normal video monitoring and use, use REDColor and REDGamma - they're both REC709 compatible.

Graeme

 

[severin schultze]

Hi Graeme,

thanks for clearing things up! But what does compatible in this case mean? Probably that the REDColor space is within the REC709 colors, but something must be different? Is it the saturation? Just from viewing in RCX i'd say the REDColor is just a little less saturated - compared to the REC709 picture. And what about REDSpace? That seems to be a greater "space" as well (like the Camera RGB) and the monitor can't display it correctly?!

Thanks a lot!

- severin

 

[Jan Zahradníček]

CameraRGB is the uncorrected camera data - hence it looks flat because it's a larger colour space than your monitor is expecting.

For normal video monitoring and use, use REDColor and REDGamma - they're both REC709 compatible.

Graeme

But what about grading on screen for DCI purposes? Is REDColor large enough? We usually use CameraRGB. Maybe we should use REDSPACE. Don't know - unfortunately it is not possible to obtain definition of RED color spaces, so we can't compare them to space of our projector or ideal DCI XYZ...

 

[Graeme Nattress]

If you use cameraRGB then the colorimetry is up to you - you have to do it all yourself. I'd use REDColor where that aspect is done for you.

REDColor is wider than 709, but the only issue with colour spaces would be premature clipping on super-saturated colours. At that point, use of the saturation control will bring them into line.

Graeme

 

[Anders Carlsson]

This thread has cleared up a lot of things, thank you for that. One thing I still don't understand though is the use of Redlog. Normally I use log dpx sequences that contain overbrights. I work with them (vfx compositing) and export new dpx sequences and the overbright information is still there. This also works when my source is a normal video file but somehow I have pushed my values above 1.0 in the compositing, but when I export the log dpx file, I get the overbright data and I'm able to recover them in grade. But, Redlog works in a different way, at least for me. Of course I don't get any overbright data as my source, but I would like to output files that can contain overbright data. Example: I import Redlog files into Nuke or AE, convert them to Linear Light (using the settings published on prolost.com or the settings that ship with Nuke), and then I want to output to Redlog in the end. When I do that, I clip every value above 1.0. So, why should I be using redlog? I thought the whole idea of a log file was that it could contain overbright information.

 

[Ido Karilla]

I'll give you an opinion (based on plenty of testing).

16 bit linear is the future.

10-bit LOG should just go away.

And I wouldn't be so quick to subscribe to the "all gets dumbed down for distribution and display." That may be true in many or even most cases at the moment - but display technology will continue to rapidly evolve and new distribution platforms are in development.

Shoot 4K +
Post in a 16-bit pipeline

I'm sure you are aware that Scratch 5 gives you the option for 16-bit processing on the Red Rocket - and you can also use more than one Red Rocket to more that make up for the speed hit you take going to 16-bit processing with 4K debayer. It's now faster than we all use to work with 2K debayer in 10-bit.

Mark as always thank you for your input.

Can you further clarify...If working for film out at 16bit linear on what stage and by whom the lin to log is done?

Thanks.

 

[Graeme Nattress]

REDLog is a good mapping of 12 plus bits of sensor data to a 10bit file. All cameras only ever record up to a maximum brightness level, so the only way they can produce over-bright data is by arbitrarily saying that full brightness is some number less than full brightness, similarly with a log curve, or any other integer coding for that matter.

Graeme

 

[Daniel Broadway]

How would someone export a 16-bit linear TIFF out of REDCINE-X, and then view it correctly in After Effects? I tried it, and it's very dark in After Effects. When I use the old RedCine, I export an EXR with a gamma of 1.0, and in After Effects it looks fine.

What is the correct linear workflow between RED and After Effects?

 

[Marin Balaic]

When you export linear tiff from REDCINE-X you have to tell After Effects it's linear. Import your sequence in AE and go to File->Project settings. Under Depth put 32 bits (float) and under Working space you have to put Linear sRGB (or some other Linear color space). If you don't have linear color space installed, here's an article Stu wrote with some linear color spaces for download. http://prolost.com/blog/2006/2/7/linear-color-workflow-in-ae7-part-1.html Install those and you can assign linear color space to your project. Also, under project settings, check Blend Colors Using 1.0 Gamma, and Match Legacy... After that, you have to tell AE that the footage you imported is in linear light. Right-click your tiff footage in Project window and choose Interpret Footage->Main. When Interpret Footage window opens click Color Management tab and under Assign Profile: choose Working space-Linear (the one you chose for Project Working Color Space-it's right on top of the list) and that's it. If it's still dark, go to View->Use Display Color Management. That's how I usually deal with linear tiff footage after reading all of Stu's posts on that subject on his Prolost blog. If you have any doubts that's a great read.