I would be fine with Blender having the option to fully support both types of color workflow (the one geared for photorealism like described in this thread, and the one that is somewhat useless for realism but works well for graphic design and NPR).
Blender as of now is fairly agnostic as far as workflow types go, it should be kept that way.
The 2.2 function is done outside of LUT by OCIO itself so not even the function, just bypass it. I already bypassed the valid [0, 1] range in python script, I even tried to read the LUT in a separate script and bypass LUT if valid, then generate new LUT, but it doesn’t work. Unless we can somehow do it in config, to just bypass LUT if [0, 1], otherwise I don’t see how it can be done.
weird… Out of curiosity, have you tried other implementation methods for the LUT yet?
I mean obviously it’d be bad in all kinds of ways. This would mostly be to see whether that’s part of the reason this happens
Like, instead of “Best”, try “Linear” or even “Nearest” (iirc those are the possible options?)
I just experimented with the python script, turned out the thing that affected the precision is the input gamut being too large. Changing the input primaries to BT.709 gives super accurate 1:1 result, but wider gamut renders will be clipped.
I ended up keeping E-Gamut, and used some matrices in the config to try minimize the errors. I think it’s working, welcome testing.
oh that would make sense. If you change the gamut, the “1:1 range” is no longer actually 1:1.
One thing I’m unsure about is why the E-Gamut is somehow ok to use when one of the big issue with the various ACES Gamuts is, that it’s got hyperspectral primaries
The point of using E Gamut is to make sure those non-sense negative luminance real camera encoding can go through our guard rail to produce something at least acceptable, instead of being clipped by the LUT. If we can get rid of 3D LUTs and implement things algorithmically, we can get rid of E Gamut as well.
sure, but I’m not really clear on why any of the ACES Gamuts wouldn’t work for that exact same purpose in principle
They don’t extend that much downward I believe, E Gamut is one of those spaces that includes the most negative luminance values.
ah, so it’s actually because the E-Gamut violates the spectral constraint even more strongly in the particular direction that matters (Luminance) than any of the ACES ones do
Again this is like a workaround for LUT clipping, if LUTs can somehow input negative values and doesn’t affect precision, I would use CIE XYZ instead. Using something outside of CIE XYZ here actually made me very uncomfortable.
The positivity constraint comes from the logarithmic shaper, right?
Since Guardrail doesn’t affect colors in the valid range at all, is that shaper even needed? Why not just go fully linear on Guardrail?
Because guard rail still does attenuation for higher than 1.0 values.
Right, fair enough. There might be a better shaper for this situation though, as part of the reason for log shaping is more resolution in the dark (but positive) regions.
Perhaps there is a reasonable shaper that would also compress positive values but doesn’t go undefined at 0…
I have already swapped out the log curve with a ST.2084(10) curve + power 1.5, this combination works the best so far in my experiments.
Makes sense
Failed, caused posterization in line of purple spectral test. The change is reverted.
Man… I don’t know what to do now. Using BT.709 outputs perfect 1:1 results, using anything wider would yield changed result, this is making me crazy.
This may be a bit silly, but one option might be to
or something akin to that
Do you mean doing it in config? Or in python script? I don’t believe OCIO config has “picking out certain range and only do operation to that range” feature.
If we are doing in in python, then we first need to input the negative values in, if they get clipped upon entry, there is no point.
ah I see… I thought you were doing some weird magic like that in-config already. I misunderstood what you’ve been doing I guess…
Can you give me the full chain of what you are currently doing? What does the python script look like by now anyways? You seem to have iterated on it a lot since last I saw a glimpse.
So in config:
Then In python
Then in config
If I change the input primaries to BT.709, then there is no need to transform from and to E gamut in the python script. But then wider gamut renders will be clipped. But anything wider than BT.709 would shift the values around due to precision, even P3.