ACES 1.0.1 luma in OpenColorIO-Configs? about aces-dev HOT 8 CLOSED

@hpd does this issue make any sense to you? I'm not familiar enough with the contents of the OCIOconfig to know what to do here. It seems to me this is actually related to the OCIO-config and not the ACES transforms themselves.

from aces-dev.

@sobotka is this an issue with the ACES 1.0.1 release transforms or is this just something that should be changed in the OpenColorIO-config?
If the latter, please open an issue on that repository since the ACES OCIO-config is not hosted here.

from aces-dev.

I guess this is a question of what the luma is being used for, typically people use it for saturation adjustments, but things like ASC CDL are defined with respect to Rec 709 rather than more generically. Even our CDLs coming to us for use on ACEScc are still defined against the original definition.

Now obviously people could use the luma for other purposes, but I would guess most people are not, so to resolve this I suspect the definition of CDLs would need a tweek.

It would be interesting to determine the real difference/improvement from switching to the correct weighting, most comparisons have typically been tested in situations involving chroma subsampling not for correct saturation control.

Kevin

Sent on the go...

On 13 Nov 2015, at 23:40, Scott Dyer [email protected] wrote:

@sobotka is this an issue with the ACES 1.0.1 release transforms or is this just something that should be changed in the OpenColorIO-config?
If the latter, please open an issue on that repository since the ACES OCIO-config is not hosted here.

—
Reply to this email directly or view it on GitHub.

from aces-dev.

As far as I know, the luma coefficients are not used by OCIO to affect any of the color operations. I believe that they are the remnants of a partially implemented feature.

@jeremyselan should be able to provide more information.

from aces-dev.

They are, but at the same time they are the only sane way to get coefficients for a greyscale conversion or such from a config with assumed arbitrary reference space primaries. I implemented that for an application and it was the only way.

Until @Shootfast offers the chromaticity based configuration details he has been thinking about. ;)

from aces-dev.

If I remember correctly, the reason the luma coefficients weren't further developed is that @jeremyselan and the Sony OCIO team made the decision to avoid any/all implied color conversion when and if possible.

The colorspaces in the 'Utility' family cover conversion from standardized colorspaces and gamuts like XYZ-D60, P3-D60, P3-DCI, sRGB, Rec.709, Rec.2020, Adobe RGB, Adobe Wide Gamut RGB and RIMM ROMM (ProPhoto). If there is a colorspace specification that you need to convert to/from that isn't covered by that list, or the list of Input Transform colorspaces, it would be great to have you contribute a new colorspace and associated transforms to the config. Can you describe the problem you're trying to solve in a bit more detail?

It's a simple change to set those values to something reasonable for ACES but it might give people the wrong impression, namely that the values should be used or have an affect on the config.

from aces-dev.

I am sort of hacking an ACEScg space together for a wide gamut reference for an application. The application already uses OCIO, but it relies on those luma coefficients to desaturate to greyscale etc.

While a freshly coded application could rely on transforms to do this, this application also uses the coefficients at other places during rendering etc.

As such, I happened to spot the luminance / luma coefficients and noticed that they would result in the wrong result as the reference is assumed ACES it seems.

I would add that not having OCIO be chromaticity aware is a bit of a problem for all sorts of UI elements and such, but that is OCIO's issue, not this one. Just a comment that having OCIO know something about the reference space, or some other mechanism to glean that information for a particular transform assumption would be extremely useful from a UI / interface coding reference.

from aces-dev.

Cleaning up old open issues...
This was an issue with the OCIO-Configs which are not hosted here.

from aces-dev.