doug-walker
commented
5 years ago This is also in our v2 plan, but we haven't gotten to it yet.
Another use-case is HDR monitors. You obviously don't want 1.0 in your matte to be at 4,000 nits (or whatever your HDR monitor clips at).
To the specific question about where to put an alpha of 0.5, it should typically be at perceptual 50% (which is a lot lower than 50% display linear). But I agree with the larger point that if someone wanted to build a config that did that, or otherwise have a view to visualize a data channel correctly, they should be able to.
sobotka
Greets all. Hope you are all doing well.
I thought I should put this here in the event that discussions happen that I might not be around to take part in the relevant meeting.
I've been pondering if OCIO should permit view transforms on the data, while keeping the data in the reference as non-colour data. Sounds nutty I'm sure, but hear me out...
If we think about adjusting an alpha plane, say we are painting or rotoscoping, or if we are adjusting a normals pass and manually tweaking or investigating it, we can begin to see where this is going. That is, the data range might very well be non-colour data. In many instances, we can see that the data might be linear, with a given offset, or even feasibly nonlinear data of arbitrary code value allocation.
The issue comes in visualizing the data. That is, if we are painting alpha as per our first example, we'd expect the alpha value of 0.5 to likely be dumped to a typical sRGB display as 0.5 display linear or perceptually 50%? Normals, being represented as a mix of actual colours, make sense to represent them as visual intensities that represent the arbitrary data encoding.
It seems like OCIO is 95% of the way there, in that the transforms are already handled properly through the library, and can be formulated as required. However, the simple flag of
isdatakeeps it out of the transformation chain for viewing, however.Should we consider implementing a means to visualize the data components in OCIO?