@troy_s looking forward to playing with the new Luts. I hope I can try them over the weekend. Thanks!

@troy_s What is EOTF?

@troy_s Filmic log encoding with the Basic contrast looks very nice. Will play with them later.

@cegaton Electro Optio Transfer Function. That is what Thomas M and the bunch over at Colour Python chose for the single term. Aka transfer curve.

@cegaton Hoping for feedback on the contrast curves. I am thinking three or five variants, with enough default range to be extremely useful as a creative kit.

@troy_s when you say log encoding is that in fact the transfer curve ? So log encoding is the transfer curve and rec709 is the color model ? Together the color space ?

@OldMan Close!

Remember that when you say "colour space" you mean two things:

1) A set of primaries measured in chromaticities. Typically expressed using the xyY model.

2) An EOTF (Electro Optio Transfer Function aka Transfer Curve)

So if we say "Rec.709" we know that if it is a colour space (it is) it has these two components.

If we say sRGB and it is a colour space (it is), it too has these two facets.

In the case of Rec.709, it is an encoding colour space, meaning it isn't meant to be viewed. It uses specific chromaticities for the R, G, and B lights, and a specific two part transfer function (roughly averages to a power curve of ~1.9)

In the case of sRGB, it uses the exact same light chromaticity as Rec.709, but it uses a different EOTF.

So in the case of the filmic LUTs, the primaries are 709 chromaticities, the EOTF for the "basic" is a log encode, and the colour model is RGB.

Examples of colour encoding models: RGB, YCbCr, YUV, Lab, LCh, etc.

Examples of colour spaces: sRGB, Rec.709, ACES, AdobeRGB.

Examples of transfer functions: sRGB's EOTF, 709's EOTF, AdobeRGB's EOTF.

Examples of chromaticity sets: sRGB's primaries, 709's primaries, ACES primaries, AdobeRGB's primaries... Etc.

@troy_s I see the new curves at github.com/sobotka/filmic-blender/blob/master/config.ocio but I'm not sure where the install and use guide is? I think that you have directed me to a readme before but can't find it now.

@3pointedit replace the current blender/version#/datafiles/colormanagement with the contents of the filmic-blender-master folder.

@3pointedit the basic instructions are at github.com/sobotka/bassam-test

@3pointedit you need the looks and luts folder along with the config.ocio

form this link: github.com/sobotka/filmic-blender

@3pointedit They aren't really for public consumption just yet. Feel free to test them however, if you trialled the last set.

Hi everyone

@troy_s I have played a bit with your filmic log and contrast looks. Basic contrast is great, I can't even reproduce it with the CDL node, I always get shadows a bit crushed, and some highlights burned. It seems to me that your contrast curve is doing a mapping with some toe and shoulder and is compressing data but not destroying it, am I right ? How could I reproduce this in compo ?

Just to illustrate, have a look at the scope, you clearly see clipping of highlights and shadows in the CDL corrected (I managed to keep shadow without to much clipping, but I had to add positive offset, about 0.03) while in the basic contrast everything is here living at what seems a good place. Here is the CDL corrected :

And the basic contrast one :

From distance, it's difficult to spot the difference, but if you look at the shadow between the cubes near the center, you can see details in basic contrast image which are not in the CDL corrected one.

@tynaud Correct.

@tynaud The curves control both below middle grey and above independently. Try flipbooking them.

To do the same with CDL you would have to get your power roughed in, then slope to pull the values back down. Impossible to get 1:1

@troy_s So we need some kind of rgb curves operating in scene referred within the good range. Back to UI limitations.

@troy_s Making a node group which is applying a parametric sigmoid function could be done perhaps...

@tynaud This is why I gathered these. What we really need is to have an imager be able to select which curve they want and have it mapped inversely to the UI

@tynaud That way no matter how complex the curve over whatever scene referred range maps perfectly 1:1 with the imager's UI.

But this whole discussion is moot without educated and talented imagers supporting with understanding and knowledge.

Hence: Teach more imagers!

We don't need more hacking, we need things to be fixed correctly that aids the imagers.

You can get the full data range into your image via CDL if you understand what it is doing to your image, but you have to be careful. It still won't deliver two or three part adjustments in a single pass however.

@troy_s with the full range, I could not (or I am doing something wrong perhaps) get as close as I wanted to your look. By single pass, you mean I could try successive cdl nodes ?

@tynaud Try this order using False colour to sample your values.

Power. Rough in your contrast.

Slope: Tweak it to bring back the few values that slip off the top.

Alternate to dial in the look until values are retained. Once you are close and incremental, ads in a very, very, very slight offset as needed, which will require very slight slope adjustment again.

Anyways, all much easier if the UI has colour transform on it.

Then you can adjust CDL "as though" the imager were log like encoded, yet still be operating on the scene referred values.

Haha, so time consuming and so frustrating ! Time to have some sleep I guess. bye !