CIE - option to apply LUT without hidden gamma transforms.

[maru]

@piotrus3333 please, no need to be disrespectful. Nobody is attacking you. We are simply asking for more informative reports in the future.

please, tell me how do you imagine „more specific details and examples” than this:

use case: to use a lut file as it is intended to be used. lut takes a given number and converts it to a different number. it should be straightforward like that.

and also if you consider this issue is related to a need for different colour spaces and colour management in Corona I think we still do not have an understanding.
it’s about simple math that Corona does wrong edit: incorrectly I mean.

Here are some ideas:
- You could have shown images with the same LUT applied in sRGB vs linear mode
- You could have told us in what specific other software LUTs are applied in linear mode
- You could have presented some evidence that indeed there is some "correct" and "incorrect" way of doing this

For reference, this website https://blog.frame.io/2019/08/12/luts-101/ says:

"LUTs have no way of knowing the gamma or gamut of an input image, nor even the ability to make an educated guess. They’re built by their authors to expect images of a specific gamma/gamut pair, for example Arri LogC/Arri Wide Color Gamut. This presents one of the main points of confusion when it comes to deploying LUTs. End users have to not only understand that a LUT has specific input needs, but also how to determine what those needs are. Frustratingly, this is not always easy. If the author doesn’t either tell the user personally, or notate this information somewhere inside the LUT, we’re left with guesswork and subjective compensations in the grade. This can lead to glaring problems, as well as subtly devious ones, such as small artifacts that go unnoticed until it’s too late, or clipped highlights or shadows."

This means that if we introduce an additional "Work in linear" mode, that might become confusing to users, who do not really know how exactly a specific LUT was authored. Remember that Corona is about simplicity.

We are always interested in how exactly you are using features in your workflow. Why do you need 100% accuracy? You can help us make the report better by explaining to us what exactly you would like to see and, most importantly, why.

To sum up: "it is intended to be used that way" or "it's simple math" or racing bikes and stabilizers are not valid arguments

[dj_buckley]

Nope, no slow phasing out of Corona, just those pipelines have never been something Corona supports but V-Ray does (we're looking at pipelines used by VFX for example, for those where there are separate teams or even separate companies doing different parts of the pipeline, with end results that have be mastered for particular display devices etc.) Given that is what we mean, it most definitely is not 99% of our users :)

The comment made was "if you're working with pipelines relating to colour spaces and colour management" in which case that is 99% of your users, even if it's as simple as calibrating our displays or authoring our final jpegs in specific colour spaces, or shooting our own backplates and authoring our own textures etc.  We're all working with colour management and colour spaces to some degree.  We don't all have to be producing Hollywood blockbusters to be taken seriously.

So it's important that the software we use isn't making things more difficult and works as expected.  If you're not interested in proper colour management etc then don't bother with it at all.  But when you're implementing things like ACES CG for the rendering colour space, and introducing ACES OT tonemapping operators then it would be good to see a full accurate colour management rollout, especially now your host software is taking it seriously.

A simple search for 'Colour Management' or 'sRGB' or 'ACES' here on the forums will show you how popular colour spaces and colour management is for a good chunk of users.

I also notice 'Colour Managed Workflow' has finally been moved to "In Development" for V11, so why suggest 'go use Vray' rather than just "hopefully coming in V11"

Also for what it's worth, "go use VRay" might have been an option this time last year, but not that long ago, a lot of us ended up tied into annual contracts ;)

But back to the original issue .... the original post isn't about Colour Spaces and/or Colour Management.

[piotrus3333]

Nope, no slow phasing out of Corona, just those pipelines have never been something Corona supports but V-Ray does (we're looking at pipelines used by VFX for example, for those where there are separate teams or even separate companies doing different parts of the pipeline, with end results that have be mastered for particular display devices etc.) Given that is what we mean, it most definitely is not 99% of our users :)

one example: Corona supports 1D shapers in 3D .cube luts. Vray does not (it supports maybe 10% of .cube file capabilities)
one .cube lut in Corona can do all the color operations available in VRay’s vfb and more, because you can stack it. suprised?

"(and Corona for some reason is archviz-first)" - that is always what Corona has been. It was built for that purpose, with Adam one of our founders coming from the archviz field with the insight that V-Ray did too much and an engine aimed squarely at archviz that removed the excess and was built for what archviz folks did daily would be much welcomed, with folks like Recent Spaces, The Boundary, AsymmetricA etc. being there as our testers and feedback cases for version 0.1 and onward. So it's not "for some reason", it is THE reason for Corona existing at all!

one funny story: few years back one of the founders of one of those three mentioned studios could not figure out how to move grading from his post production tool to Corona (via lut) just because this unusual way Corona does luts. would you call it a feature well designed? in everyday work it brings the necessity of having “Corona” version of every used lut and lost precision within blacks and shadows. what a waste of otherwise great .cube implementation.

[piotrus3333]

@maru
the quote you posted explains exactly why what Corona does is not correct.
not correct as in: everywhere I know it is done differently.

again, not disrespectful, just trying to get through lack of understanding.
(I was really hoping racing bike metaphor would work..)

another try:
the lut file says that colour X turns to Y.
Corona turns X into Z.
at least questionable, right?

[piotrus3333]

@piotrus3333 please, no need to be disrespectful. Nobody is attacking you. We are simply asking for more informative reports in the future.

Here are some ideas:
- You could have shown images with the same LUT applied in sRGB vs linear mode
- You could have told us in what specific other software LUTs are applied in linear mode
- You could have presented some evidence that indeed there is some "correct" and "incorrect" way of doing this

- images attached, VRay vs Corona, I hope this shows how “uniqe” Corona’s approach to luts is.
edit: yes, view transform in VRay matches that of Corona in this example. yes, "log" mode also does not match.

- every other software you can imagine. some will give you (like VRay) options to do some transforms before or even before and after lut (exposure adjustment for example). Corona is unique. again.

- chapters 6.1 and 7.1:
https://kono.phpage.fr/images/a/a1/Adobe-cube-lut-specification-1.0.pdf

[piotrus3333]

Hi all, thank you for your feedback. We now have this logged as a feature request.

(Internal ID=1213995718)

Ok. this is sorted now. I guess no need to keep the request opened.
Thanks.