ACES Processing + Separate "Profile" in to "Profile" + "Colour Space"

[ilia3101]

Currently we have some profiles that do all sorts of things. It is inconsistent and weird.

I want to make it be like this:

• Have a selection of output colour space (things like linear, rec709, sRGB, adobeRGB, LOGS can go there)
• Keep the profiles, like tonemapped, standard, film, where they are, and also add a 'exact' for exact output (no processing like contrast and curves).
• When setting the LOGs, automatically set the profile to 'exact'

So MLV App will be able to output in different colour spaces finally(wider than sRGB/rec709 yayy), I know we still don't have a good way of making FFmpeg write this metadata and for it to all 'just work', but I think it is like that anyway with colour grading software, and in many video editors you can just tell it what colour space to interpret footage as anyway.

Will have to make a couple of changes to processing. Maybe after the merge which should be soon.

Apologies for the caps title

[masc4ii]

Sounds interesting. I waited for so long for topics like this and helping with the wb branch... I got rid of implementing unimportant mini features in the GUI only... But yes, please lets merge wb4 to master before.

I am not sure if any encoder software writes correct metadata into the clips. I mostly feel like there is no metadata and the data is converted before by the software. As you wrote, the user has to tell the decoding software which color space it is. This also explaines, why no matter what metadata I wrote with ffmpeg - the picture looked always identical, in all viewers I tested.

Title is easy, isn't it? Profiles is profiles, and color space is color space... or what was the question?! 😄

[ilia3101]

Yeah I wrote the title before I wrote the thing. It's better now.

[ilia3101]

Should we merge already? As it's disable able and to avoid any potential merge difficulties.

[ilia3101]

https://cameramanben.github.io/LUTCalc/ has nice links to info about colour spaces. Leaving it here as a note to remember.

[ilia3101]

For dealing with older MASXML - we should have a new tag for the new profiles and a new tag for colour space, and when we read old profile tag just interpret it in a special way and convert to correct combination of new profile tag and colour space tag.

[ilia3101]

And as soon as we merge lets make a release to get the important matrix stuff out quicker.

[masc4ii]

It should be perfectly mergeable. All function should be there, compatiblity mode is implemented and WB Picker works in both (is only a little slow in new mode). The only thing we should wait with another release is bouncyballs dualiso 2nd iso value in info panel (still work in progress). And... nice link!

[masc4ii]

Oh no... "Don't worry..." ...5 clicks later your repos will be defect again... 😛

Edit1: and here is where the defect happens then... only some clicks later... why now wb4 has to be changed and not master!?

Edit2: Great, your branch has been broken! ...so stupid...

[masc4ii]

Ok... but after these two conflicts both branches are now identical and merged.

[bouncyball-git]

Will be great!!!

* When setting the LOGs, automatically set the profile to 'exact'

Hey guys can we do the following. If log is selected then 'exact' is ok, but if LUT selected after this I always miss the standard sliders which are grayed out. If exporting log do exact if LUT/Filter selected after log turn all processing controls ON again.

[ilia3101]

Let's not stop the user from choosing something other than 'exact' after setting log then. Would that help with the problem you say?

[ilia3101]

As you wrote, the user has to tell the decoding software which color space it is.

Do you know if this is possible in final cut? I couldn't find it there. I know it's possible in Blender video editor.

I really wish there was such metadata, otherwise how in the future is wide gamut and/or HDR content going to be told apart from old rec709 and stuff. Everything is bad.

[bouncyball-git]

I meant that changing any processing parameter if one intends to export pure LOG is not right and all processing knobs etc should be disabled, but if after log applying someone chooses to continue edit and uses lut/filter then processing editor has to be activated again.

[ilia3101]

I think best way would be to let the user to re-activate the editor themselves if applying a lut or something than doing it automatically

[ilia3101]

And I have realised doing the change (in this issue) might be difficult unless we start to use more floating point.

[ilia3101]

I have an idea to use logarithm or some kind of range compression inside processing, that way uint16_t has more dynamic range.

[bouncyball-git]

@masc4ii

Why color picker is so slow?

[masc4ii]

Do you know if this is possible in final cut? I couldn't find it there. I know it's possible in Blender video editor.

If it is possible, I don't know how. But what I know: it does not react on metadata (had that problem in the past).

For the "exact" topic: lets do "exact" (sliders off) and "exact plus changes" or "exact as starting point" or something like that (sliders on).

And I have realised doing the change (in this issue) might be difficult unless we start to use more floating point.

I already wanted to ask you, how you want to realize it without loosing quality and render speed. What about calculating in float a lookup table, which is again u16 in the end?! (A combination of both selected parameters) Like that, speed would be nearly the same.

Why color picker is so slow?

That is easy to explain: my method is stupid! Hehe. I really have no idea how to invert calculate a temperature and tint. So what I did is, to try all possible combinations of these two parameters and see what happens. If the difference between the colors is at minimum, it is close to grey -> this setting wins.

/* Trail & Error :-P */
    for( int temp = 2300; temp <= 10000; temp += 10 )
    {
        for( int tint = -100; tint <= 100; tint += 1 )
        {
            processingSetWhiteBalance( processing, temp, tint/10.0 );
        .....

Until now, this was fast enough. I made some optimizations in the past: I only render one single RAW color, but not all possible colors for that. But now, there have some matrices to be calculated on top. This needs time. If someone has a more intelligent algorithm: please let me know or implement it! I just wanted to have a WB Picker and this was my only idea how to solve that.

[ilia3101]

Your idea is good too, could be better even will see.

[ilia3101]

Ok I had a look at the log functions we use in MLV App, and they all clip at insanely high values so I'm going to have to make that function clip way higher than at 6.0

[ilia3101]

@masc4ii Could it be possible to implement gradient in a more simple way? Or were you planning to add white balance to it? As currently the gradient does not need it's own matrix and could just have a single look up table to do the contrast and exposure.

[masc4ii]

As currently the gradient does not need it's own matrix and could just have a single look up table to do the contrast and exposure.

Really? Now it uses its own matrices...

processing->gradient_contrast_curve
processing->pre_calc_matrix_gradient

Yes, it was a wish to add wb to the gradient. But until now it was too much effort for what we'll get. Maybe you know an easier way than mine?

[ilia3101]

I meant: it has matrix, but currently does not need it, so we could simplify it at least for now.

Well it still needs lookup table for contrast and exposure but can be without matrix.

[masc4ii]

Really? Would be cool... if you know how...

[ilia3101]

That is easy to explain: my method is stupid! Hehe. I really have no idea how to invert calculate a temperature and tint. So what I did is, to try all possible combinations of these two parameters and see what happens. If the difference between the colors is at minimum, it is close to grey -> this setting wins.

/* Trail & Error :-P */
    for( int temp = 2300; temp <= 10000; temp += 10 )
    {
        for( int tint = -100; tint <= 100; tint += 1 )
        {
            processingSetWhiteBalance( processing, temp, tint/10.0 );
        .....

Maybe a go through every value of tint but binary search on the temperature?

Also did me putting matrix generation only in the processingSetWhiteBalance make it a lot slower?

[masc4ii]

Also did me putting matrix generation only in the processingSetWhiteBalance make it a lot slower?

Not at all, because you removed it in the find function at the same time. Binary search on temperature?!

[ilia3101]

O good

Binary search on temperature?!

Well not sure if it's possible, but maybe the ratio of blue to red could be used for comparing if higher or lower. I will see what I can do.

[ilia3101]

This is going to be done along with ACES

[ilia3101]

@masc4ii @bouncyball-git Is it ok if LUT is applied while in ACES space? Or are most designed for rec709? Should it be converted to that for luts?

[masc4ii]

Each LUT has a defined input space and a defined output space. Many LUTs are designed for rec709, BMDFilm and Alexa LOG (maybe some more LOG spaces)... but I am not sure about ACES.

[ilia3101]

Ah lut is applied after log!!! (or whatever it is converted to)

[ilia3101]

But it will need to be rethought for the new processing profiles. Maybe a special stage for lut application with choosable colour space for it.

[bouncyball-git]

@masc4ii and I briefly discussed this some time ago. We thought there should be 2 hooks for lut application before processing and after processing (maybe in between too, for ACES).

1. Before will be the place where conversion to all log spaces are done or some initial curves for ACES etc.
2. After is the case you described: convert ACES to color space which is input space for the lut and apply.

Special case: apply some log space (with gamma and primaries, not only gamma) at the beginning -> skip all ACES processing -> apply appropriate output lut.

[ilia3101]

@masc4ii can your curves spline library deal with values above and below 0.0-1.0

[masc4ii]

That should work. With another library I had problems at exactly 0.000, that is why I implemented from 0.001 or something. With this lib I haven't tried that out. But above should work without any problem. When I commited this library, I think I added a commit comment with link to the source. There are some explanations.

[masc4ii]

Here you'll get some more information: https://kluge.in-chemnitz.de/opensource/spline/ If you look at the example picture: range is "-0.5 .. 2.5", so it should work, what you were asking for.

[masc4ii]

Discussion moved to #158 .