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

RED log vs LOG-C, give me the meat (probably a question for M Most/Graeme)

Gunleik Groven

REDuser Sponsor
Joined
Dec 28, 2006
Messages
13,465
Reaction score
5
Points
38
Location
Norway
Website
quine.no
Gonna test the MX and Alexa over the next week. If that in itself makes this post inapproriate... Hard luck! -:)

I|ve read a lot of Gary Adcocks price of LOG C, and to me it sounds pretty much like what I'd have said of REDlog.

Yes. I understand they're not identical, but the use of them and effect seems pretty similar (note: I have not yet done the test, so this is just me preparing...)

So what are the main differences between these two?
And how do I spot them?

For what applications would I note the most differences and in what way?

I'll do my own tests, but hints at places to look are always interesting...

Cheers!

Gunleik
 
Gonna test the MX and Alexa over the next week. If that in itself makes this post inapproriate... Hard luck! -:)

I|ve read a lot of Gary Adcocks price of LOG C, and to me it sounds pretty much like what I'd have said of REDlog.

Yes. I understand they're not identical, but the use of them and effect seems pretty similar (note: I have not yet done the test, so this is just me preparing...)

So what are the main differences between these two?

They are only similar in the sense that they're both called Log.

Redlog is intended to do one thing - to translate 12 bits of linear light information into a 10 bit container. It is not based on any standard log curve, nor is it based on print density. It is purely a mathematical translation of values in which the lower 8 stops are kept at full precision, and the upper 4 stops are reproduced at a reduced precision. It is not designed to be used with any standard lin to log conversion because it is not based on that, nor is it based on Cineon. Arri's LogC, on the other hand, is based on the Cineon print density curve and is meant to be used with a Cineon based LUT for translation into a gamma encoded world. In the D21, LogC can be produced with a choice of color matrices (they primarily allow different saturation levels) to yield images that will look correct when viewed through a typical print preview LUT when intended for film output. This is absolutely not the case with Redlog, which was never intended to be used for film recording, but only to be used for retaining the original 12 bits of information in a 10 bit file. Because Redlog uses a very "mild" log curve, however, it can be used as a source for color grading in a typical gamma encoded environment with pretty good results. LogC is not intended for this, but that doesn't seem to be stopping people (including Gary) from doing it anyway and encouraging others to as well. Given that most people really don't understand Cineon log curves, the use of LUTs, what they are, or how to properly apply them and where, none of this is surprising. That still doesn't make it correct, though.

Hopefully Graeme will pitch in and correct anything I've said that's not quite accurate.
 
Redlog is intended to do one thing - to translate 12 bits of linear light information into a 10 bit container. It is not based on any standard log curve, nor is it based on print density.

Sounds like OpenColorIO will need a Redlog profile then. Thanks for the info!
 
Back
Top