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

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

Joined
Mar 16, 2010
Messages
5
Reaction score
0
Points
0
After seeing what the MysteriumX can pruduce, I feel that it is super important to understand how to take care of the files in post, if native R3D isn't an option. I want to go out to grade and to vfx. In my vfx application I can output EXRs and feel comfortable that I get every piece of information, but since this isn't an option in the RED apps, I'm unsure what to do.

- DPX in Redcolor, Redspace etc. I guess this would be a good starting point in grade, as there would be a nice looking image directly after import. But even if I adjust the parameters so that I don't clip, I still "only" have a 10-bit image.

- DPX in Redlog, Pdlog etc. I understand the use of this format when you shoot on film, but I don't understan the purpose when you shoot digital. What you see in the histogram is what you have in dynamic range, so if you clip there, you'll clip in the log-file aswell. Or does log help me to regain the 12-bit? Also, I'm unsure how to adjust my image in a log-space.

- Tiff in Redcolor, Redspace, Linear Light etc. Would this be a better option since it's 16-bit? Whould a 16-bit linear light tiff be ideal, if I produce a LUT that gamma corrects the image to something that I like.

I know it's a lot of questions, but I think it's a common problem that a lot of people would be happy to know more about.
 
For colour space choose REDColor. For a video workflow grading REDGamma is very good. Both are REC709 compatible.

For a more film style REDLog works very well for a lot of people. We're doing a new REDFilm curve for those that find REDLog doesn't quite meet their needs.

DPX10bit is fine as long as there's a good log or gamma curve on it.
16bit Tiff is superb, even for linear light. If you do use linear light, I'd only use a 16bit tiff.

Graeme
 
Graeme, thank you for your reply.

For "more film style", does that mean a grading house that has done a lot of film work and have their setup ready for log-files and don't want to adapt, or are there actual benefits from doing it with log?
 
I would assume, REDfilm would be a more finely tuned log curve that would play nice with some standard log to lin converters? I personally always grade from REDLog. I've always gotten my best results that way. Looking forward to REDfilm as well.
 
REDFilm is based more on analysis of actual film, rather than a pure mathematical model.

Graeme
 
REDFilm is based more on analysis of actual film, rather than a pure mathematical model.

In other words, a form of inverse LUT based on a film target. Or, in another sense, something similar to Arri's LogCFilm LUTs.
 
In other words, a form of inverse LUT based on a film target. Or, in another sense, something similar to Arri's LogCFilm LUTs.

Would this be similar to say a Kodak 2383 LUT that you would generate and apply through cinespace? I guess I'm asking if it will be a monitor LUT or an actual gamma space in the clips that still requires a specific Monitor LUT?
 
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
 
Does anyone know if Cineon Log curves were created by rigorous technical measurement of a particular film stock available at the time or by averaging the "typical" photochemical response characteristics? Or some other method?

On the same track, I have heard varying opinions from top practitioners about the level of precision (or granularity if you prefer) of 10 bit log vs 12 bit linear vs 16 bit linear. Yes, I know that at some point it all gets dumbed down for distribution and display, but during post processing it can be a different ballgame.

Cheers - #19
 
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.

I don't quite understand. Is Redfilm designed to be a "more accurate" PDLog685, or is it intended to yield an image that properly translates colors into a film targeted space? In other words, is it intended to yield a version of the image that looks like the "normal," gamma encoded image when viewed through a print preview LUT (thus accounting for some significant gamut remapping along the way)?

BTW, I think you either mean "the code values that would be obtained from a film negative," or "the code values a film scanner would generate if it were scanning a negative." A camera wouldn't shoot a film scan, it would shoot a live action scene and expose a negative that could then be scanned.

A little too wordy there, but you get my meaning....
 
Does anyone know if Cineon Log curves were created by rigorous technical measurement of a particular film stock available at the time or by averaging the "typical" photochemical response characteristics? Or some other method?

On the same track, I have heard varying opinions from top practitioners about the level of precision (or granularity if you prefer) of 10 bit log vs 12 bit linear vs 16 bit linear. Yes, I know that at some point it all gets dumbed down for distribution and display, but during post processing it can be a different ballgame.

Cheers - #19


It's purely mathematical, not a model of any particular film, and does not conform to any particular film stock as far as I'm aware.


cheers,

JT
 
My guess is we will be able to select REDFILM and the curves will roll off similar to how film dose and then you can grade from there. I think the REDFILM look in camera would be awesome because then we can light to that look/curve.

I look forward to it! It will help Red look even more like film for those that choose!

Prost,
Rich
 
I still don't understand the use of log-files. Isn't the purpose of a log-file to preserve over-brights? From what I understand, a digital camera as RED doesn't contain any overbrights, what you see in the histogram is what you get. So why would I want to use a log file for other reasons that post-houses has already prepared workflows how to use log files. Forgive me if I'm completely misunderstanding this.
 
On the same track, I have heard varying opinions from top practitioners about the level of precision (or granularity if you prefer) of 10 bit log vs 12 bit linear vs 16 bit linear. Yes, I know that at some point it all gets dumbed down for distribution and display, but during post processing it can be a different ballgame.

Cheers - #19

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.
 
Good points Mark.

Do you need more than one RR in Scratch to get realtime full debayer @ 16-bit processing (I guess: yes...)

Is Assimilate still writing their own debayering algorithms, or are they using the SDK by now?
 
Film have great dynamic range, white point is located in a zone about 2/3 of density, over that there's great room for highlights (1/3 in a bended curve, the "shoulder" of response curve). Having all that exposure available in the digital scan is valuable for grading, 35mm printing and positive print (even if positive doesn't have the same DR)
Right now, Mysterium have a good DR, but no a great highlight coverage, it starts to clip 2 stops up. Because you can't underexpose too much (because of noise) you have a somewhat limited space for grading. Looking some exposure tests of M-X it seems the highlight situation doesn't change very much, but there's a big change in lowlights, very low noise. In my point of view, if you can cleanly underexpose a couple of points, then there's more detail in highlights, and from there you can map it more closely to a typical 35mm scan.
I think in 10-bit log data as a negative that have more information that what can be correctly seen in a positive print, or a video or computer monitor, these mediums are more contrasted (less DR) than negative. 16-bit linear (gamma encoded) tiff can hold more information than 10-bit log, but I think it tends to be mapped to be seen "normally" in the computer monitor, then I don´t know how it will be translated to a negative print.
There's many tools that work fine using "normal" 35mm log scans to end in a 35mm print. I think every step from RED to approach to that "normal" log image are welcome...
 
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
 
Back
Top