Make the interchange roles required for future config versions

[doug-walker]

The interchange roles feature (aces_interchange and cie_xyz_d65_interchange) was introduced in OCIO 2.0 as a way to connect an OCIO config to other configs or to external color spaces or color management systems. (See the proposal and discussion in issue #927.) Since historically OCIO configs have been their own self-contained universe with no outside connection, this represented a big philosophical change. We therefore made these roles optional.

However, as we work to connect OCIO with other projects, this ability to make connections external to a config file becomes more and more important. For example, to be able to integrate OCIO with the chromaticities attribute in OpenEXR files is one recent use-case. Without the interchange roles, these connections could only be done via potentially unreliable heuristics which may fail to find a way to connect.

As with other features of config files, we could make it mandatory for these roles to be present in the config validation process. This issue is to collect opinions on whether we should do this for an upcoming release. It would represent a trade-off that places a (probably small) burden on config authors in order to make the connection to external systems more robust.

The config file format has a version number and this would obviously be incremented along with any change of this sort. At a minimum, for previously released config verions (version 2 and 2.1, as of this writing), the interchange roles would remain optional.

Note: if the config does not use the display-referred connection space, then the cie_xyz_d65_interchange role could remain optional.

[zachlewis]

Could a config contain cie_xyz_d65_interchange instead of aces_interchange?

I'm thinking of cases where a config isn't using ACES in the first place. Do we compel authors to add an ACES2065-1 space for the sake of connection / translation? Do we arbitrarily choose a specific chromatic adaptation method, or do we let config authors choose an arbitrary chromatic adaptation method? If it's the former, and cie_xyz_d65_interchange is defined, why have authors explicitly create an AP0 color space in the first place (when it could be derived implicitly)?

[ThomasWilshaw]

I think it would be great if the CIE role became a requirement for all configs to give a ground reference for doing colour work in apps that is outside the scope of OCIO. Is there any reason not to go all the way and include chromaticity coordinates, white point and other CIE colourimetric definitions (such as luminance weights)? Correct me if I'm wrong but I'm guessing 99% of configs use a very small number of working spaces between them so OCIO could easily provide reference implementations for all the standard working spaces (Rec709, ACES Rec2020 etc.).

[sobotka]

This is a terrific step via mandatory roles.

Moving a step further to canonize CIE colourimetry, perhaps it would be worth considering extra information in the role label?

1. CIE_1931_D65_XYZ, opening up for a potential CIE_2012_D65_XYZ
2. adaptation_matrix which would permit folks to derive the origin encoding. Similar in spirit to the ICC chad tag, and permit an open ended, technical / analytical specific need, without accidentally locking folks to a specific matrix.

TCAM V2 onward, as well as other forward looking spectral based image formation chains, I believe are anchored in CIE 2006 LMS, and therefore clarity on the CIE specification XYZ transformation would be welcome and useful.

Do we compel authors to add an ACES2065-1 space for the sake of connection

This would be a huge error, given how it handcuffs everything into the poorly formed 1931 model. It would have a lasting negative impact on forward looking research and management.

[KelSolaar]

CIE_1931_D65_XYZ, opening up for a potential CIE_2012_D65_XYZ

If specifying the observer, we would need to define explicitly the degree. It is ok as being explicit for 1931 and 1964 but for 20125, we need to specify it explicitly.

We have then a problem with mapping between observers for everything non-spectrally defined but this is another topic.

[doug-walker]

Thanks for the feedback!

@zachlewis , please keep in mind that the aces_interchange and cie_xyz_d65_interchange connect into different parts of the OCIO block diagram. I have heard others also say that their scene-referred source data is CIE XYZ and they want to use that directly rather than convert it to ACES2065-1. However, this seems to ignore the fact that there is a View Transform that separates the two reference spaces. (As to the chromatic adaptation question, that was the bane of ICC colour management and it will likely be the same for ACES, lol.)

I think what you are actually asking for (?) is a new interchange role that would allow people to plug their CIE XYZ data into the scene-referred side of the block diagram. But is the convenience worth the added complexity?

We could discuss deprecating the original role names and adding new ones named something like: scene-referred-CIE-1931-XYZ-D65-interchange and display-referred-CIE-1931-XYZ-D65-interchange. Although it would be regrettable to not use ACES2065-1 since it is, by far, the most well-specified scene-referred color space encoding. And it then becomes a bigger project to implement and test this since the previous roles are already released.

@ThomasWilshaw , OCIO already does provide reference implementations of the common color spaces (see the BuiltinTransform). The concept of adding chromaticities and etc. to color space definitions has been suggested by Troy and others (even me, lol) over the years. It has been a very controversial topic in the working group meetings. There are good points on both sides of the argument but, at least for the purposes of the discussion within this specific Issue, OCIO remains a transform-based system.

@sobotka , the question of utilizing more recent standard observers is certainly a very interesting question that is made more pressing by the increasingly narrow band displays. But as Thomas points out there is the need to deal with these other parameters such as angle as well as the complexity of conversion to/from 1931. I feel like we might want to wait for more concrete proposals regarding how to deal with this before taking action in that direction. But if we do change the names, we could add the "1931".

It's interesting there have not been any opinions saying not to make the roles mandatory. (Yet, anyway!)

[sobotka]

I have heard others also say that their scene-referred source data is CIE XYZ and they want to use that directly rather than convert it to ACES2065-1. However, this seems to ignore the fact that there is a View Transform that separates the two reference spaces.

I don’t think it ignores it at all. The point is; there is nothing that ACES does other than lean on top of CIE colourimetry, so it makes sense to remove that dependence middle layer and cut to the chase of proper CIE based colourimetry. ACES can’t live without CIE colourimetry, and CIE colourimetry can live and express everything ACES can, completely fine, without the added rubbish.

The image formation step, whatever the choice of lingo being a view transform or such, really matters not here. It’s the nature of the expression of the encoding that matters, and CIE colourimetry is by far and above the most resilient.

But as Thomas points out there is the need to deal with these other parameters such as angle as well as the complexity of conversion to/from 1931.

I think the point is missed here. OCIO doesn’t need to concern itself with transforming or conversion here. It would merely be a hint for authors seeking to integrate into forward looking systems leaning on 2012 CMFS. For example, integrating additional facets into a TCAM pipeline. In a more distant future, OCIO could of course integrate some helpers here, but it is more important to communicate the technical facets of a given encoding.

It's interesting there have not been any opinions saying not to make the roles mandatory.

That’s because it is a heck of a wise proposition!

[zachlewis]

@zachlewis , please keep in mind that the aces_interchange and cie_xyz_d65_interchange connect into different parts of the OCIO block diagram. I have heard others also say that their scene-referred source data is CIE XYZ and they want to use that directly rather than convert it to ACES2065-1. However, this seems to ignore the fact that there is a View Transform that separates the two reference spaces. (As to the chromatic adaptation question, that was the bane of ICC colour management and it will likely be the same for ACES, lol.)

I think what you are actually asking for (?) is a new interchange role that would allow people to plug their CIE XYZ data into the scene-referred side of the block diagram. But is the convenience worth the added complexity?

We could discuss deprecating the original role names and adding new ones named something like: scene-referred-CIE-1931-XYZ-D65-interchange and display-referred-CIE-1931-XYZ-D65-interchange. Although it would be regrettable to not use ACES2065-1 since it is, by far, the most well-specified scene-referred color space encoding. And it then becomes a bigger project to implement and test this since the previous roles are already released.

(FWIW, I don't have a problem with aces_interchange -- it's perfect for the configs we use at work, and if config authors are using AP0 / AP1 as their scene reference, aces_interchange provides the most intuitive connection to the outside world).

I'm not sure we'd need separate scene-referred and display-referred cie-1931-xyz-d65 spaces necessarily? As long as cie_xyz_d65_interchange points to a display color space, the scene-color space equivalent would presumably be whichever color space whose conversion from cie_xyz_d65_interchange yields an identity transform, and vice versa. Unless I'm missing something, which is entirely possible.

For what I'm proposing, I'm specifically thinking about the problem of how to interpret the exr/chromaticities attribute in an OpenEXR header with respect to a config (presumably, by computing an RGB-to-RGB matrix converting from one scene-linear encoding to another). I haven't 100% worked out if my logic is sound, but I think it might be kosher for general "config-to-config" transforms too, possibly by requiring the "encoding" attribute for at least Display Color Spaces.

IF we take as given that whenever we're converting from chromaticity coordinates, unless otherwise specified, we're dealing with converting from a "scene-linear" encoding, we'd only be using the cie_xyz_d65_interchange space as an intermediate "shortcut" to compute a matrix for converting directly into the scene reference space, one scene linear state to another (as opposed to using cie_xyz_d65_interchange as display-side entry point to arbitrary Processors).

(The exception being, if the chromaticities indicate the encoded primaries are already XYZ, absent other hints, perhaps it's reasonable to assume that the encoded image is display-linear, and that we should convert directly to the display reference space; same goes if additional metadata indicates the encoding is "display-linear")

So, if an author chooses to define scene-linear spaces relative to, say, a D65-based scene reference space, there's no need to bring CATs into the equation. And if configs are using AP0 or AP1 as their scene-reference space, if we can't heuristically ascertain a match to defined color spaces, I imagine it makes sense to look to any existing XYZ-D65 spaces in the config to hint at the CAT to use by default when converting from D65-whitepoints and custom primaries to AP0. In fact, this would happen by default if the "cie_xyz_d65_interchange" space (if defined) were used to convert to the scene-linear reference whenever converting from a D65 whitepoint, and "aces_interchange" (if defined) were used to convert to the scene-linear reference when converting from an ACES whitepoint. This would allow config authors to control for whether or not a custom primaries / D65 whitepoint source takes a chromatically adapted path or two through D60 on its way to other D65-based color space.

(I also think it would be cool if, when specified, an optional OpenEXR exr/adaptation_matrix metadata attribute (a la Troy's suggestion above) could be used to override the "default" CAT method inferred from the relationship between AP0 and XYZ-D65, or from a potential "default_chromatic_adaptation_transform" OCIO config attribute. Food for thought).

I've gotta do work stuff now, but I think I can probably rephrase this more clearly.

[zachlewis]

I'm so sorry for the word count.

and disclaimer, I'm talking about stuff like distortions created by mismatched chromatic adaptation transforms -- essentially imperceivable, unless you're specifically looking for trouble.

As I understand it, right now, the API provides an overloaded Config.GetProcessorFromConfig(...) function for cross-config color space conversions, via a "bridge" color space defined in both configs. The "bridge" space is either explicitly provided, or implicitly inferred from the presence of aces_interchange and / or cie_xyz_d65_interchange roles defined in both configs.

• Best case scenario:
  • scene -to-scene conversions pass through aces_interchange,
  • display-to-display conversions pass through cie_xyz_d65_interchange.
• If only one of those roles exists in both configs, or if converting scene-to-display or display-to-scene, the Processor traverses over one of the configs' default View Transform (i.e., the "colorimetry" transform that defines the scene and display reference spaces relative to each other.)

Ultimately, I think this behavior is fine, and doesn't need to change -- but I also think by making "aces_interchange" synonymous with "scene-referred-interchange", we're conflating three related but distinct concepts:

• Entry-point orientation ("scene" vs "display" interchange interfaces)
• Objective identification ("aces", "cie_xyz_d65")
• "Betweenness Centrality" (i.e., whether "aces" is the "scene-reference" space )

We take for granted that "aces_interchange" always points to a scene color space (very often the "reference" space); and if "cie_xyz_d65_interchange" is also defined, it [presumably] points to a display-linear space, if the config has display spaces.

However -- there /are/ cases when "aces_interchange" might not point to the "scene-reference" (e.g., configs whose scene color spaces are defined relative to a D65-based connector space, where all color spaces share the same path to AP0); and there /are/ cases where configs are defining scene colorspaces relative to an xyz connector space. If I'm trying to connect either of these kinds of configs to the vanilla ACES-1.x OCIO config through an "aces_interchange" space, it's possible to end up with imperfect roundtrips and distortions where a Bradford turns up where a CAT02 is expected...

Here's what I'm thinking:

Proposal:

The constellation of interchange roles defined in a config should dictate the strategy employed for constructing the conversion matrix into the OCIO graph.

1. The presence of aces_interchange indicates that the config author is using an ACES-based scene-reference space, and wants to use ACES for interchange
   • Dictates a fixed, config-independent set of rules governing the chromatic adaptation transform into ACES for certain camera vendors / gamuts. Specifically -
     • Sony, AWG, Canon: CAT02
     • Panasonic, RED: Bradford
     • Rec709 / P3-D65 / P3-DCI (D65 sim) / Rec2020: Bradford
   • The author is responsible for making sure color space definitions adhere to these rules
     • (Which should make it easy to objectively identify these linear color spaces in the config, should they exist)
   • If aces_interchange is not defined, either cie_xyz_d65_interchange or linear_srgb (or both) must be.
2. If defined, linear_srgb points to the space to use for converting from scene-linear spaces;
   • If both aces_interchange and linear_srgb are defined, "ACES rules" have priority, because the presence of aces_interchange implies that ACES is used as the scene-reference connection space.
   • Use linear_srgb for unknown D65-based primaries when an existing color space cannot be identified in the config using aces_interchange heuristics
   • If aces_interchange does not exist, when converting from ACES white point, easy to detect whether an AP0 or AP1 space already exists in the config; if not... "just use Bradford"
3. The presence of cie_xyz_d65_interchange points to the color space to use for converting from display-linear and nonlinear encodings (entering the graph from the display side).
   • If neither aces_interchange nor linear_srgb exist:
     • If the config isn't using display color spaces, use cie_xyz_d65_interchange for scene-side conversions as well.
   • Otherwise, the scene reference space is the first non-data scene ColorSpace whose to_reference and from_reference transforms as identity transforms.
     • D65-adapted primaries derrived from the default ViewTransform may help inform the objective identity of the scene-referred space.

Am I making sense? Is this worth the complexity? Am I crazy? Maybe I'm crazy. I'm probably crazy.

[MrLixm]

Zach telling he's crazy but why not going one step crazier ? Why not removing the concept of arbitrary reference colorspace ? Do we really need it, or actually could it be simplified ? Allow me to develop my idea :

Is the arbitrary reference colorspace useful ?

Allow me first to just disclaim that I'm not an expert with OCIO and some points I'm making might actually not be pertinent. In that case feel free to comment it.

If I might make this affirmation, but the reference colorspace is something that I never found very clear. It is mentionned quickly in the documentation but it is something that took me time to figure out. While really being the core of the colorspace logic. It is also not clearly defined in the config. There is mention of the reference role, but it is optional and has often been forgotten so you would have to guess it by other ways.

Something I'm still not sure, is the reference colorspace also the working colorspace ? This is will depends of how DCC implements it but I think often the working colorspace is assumed to be defined in the scene_linear role which happened to also be quite often the reference space. So yes it can be, but it is not used directly as the working-colorspace.

Then what it is useful for ? And that's a genuine question cause I can't provide an exact answer. For the "reference" part I guess this allow OCIO to 100% abstract the color-science, the user provide the transforms and OCIO just does the math. For the "arbitrary" I'm not sure. This probably offer flexibility for anyone to use whatever they want but at the same time it create division between different config and led to this issue #1639.

Changing the system

Let's start by changing the reference colorspace to not be arbitrary anymore. Every transform specified in a colorspace is formulated in reference to this reference colorspace (as it is currently), but the difference is that it will be a pre-determined, fixed colorspace that will be the same for everybody.
This has some deep implication, the first one is solving the interchange format discussion. Anyone could convert a config to an other by having a fixed common point. It offers a lot of new possibility but not sure they all fit withing the OCIO goal. Technically you could ommit to declare the sRGB Display colorspace, and anyway OCIO could have it stored internally as a builtin and could be queried by the application.
But then what is actually preventing us for also storing other common colorspace as built-ins, like DCI-P3, AdobeWideGamut, ... ? This would kind of go against this quote : "it’s only knowledge of color science comes from it’s execution of the transforms defined in the OCIO configuration file". That we could actually counter-argue by having a look at OCIO 2.0 who introduced built-ins transform for ACES.
So how should OCIO behave here ? I think it opens a cans of worms here. But let's continue on this way ...

But now we are missing why the previous reference system was useful for. what if we want to express a colorspace but not from the reference ? Like cie_xyz_d65_interchange is currently used. Well with a few syntax change we could allow to specify what is the new "local reference" for this colorspace , that must be an other colorspace defined in the config. Then OCIO will make the connection between reference -> local reference -> target colorspace and produce the conversion graph behind the scene.

This can be expressed in the OCIO syntax as :

 - !<ColorSpace>
    name: ACES - ACEScg
    from:
        reference:
             !<MatrixTransform>  { matrix: [ 0.825139, 0.17797, ...

# where `reference` is this new fixed colorspace.
# The config author is in charge to provide the correct transform to convert from
# ACEScg here, to the known reference.

Which could be even allowed to be simplified to :

 - !<ColorSpace>
    name: ACES - ACEScg
    from:
        !<MatrixTransform>  { matrix: [ 0.825139, 0.17797, ...

Then with a "local reference" would give :

 - !<ColorSpace>
    name: sRGB
    from:
        ACES - ACEScg:
            !<MatrixTransform>  { matrix: [ 0.005, 0.857, ...

Which could technically lead to infinite nested references :

 - !<ColorSpace>
    name: sRGB crunchier
    from:
        sRGB:
            !<CDLTransform> { power: [ 1.3, 1.3, 1.3 ], sat: 1.2 }

I personnally found this syntax clear and elegant.

This method would not prevent to work as before, where all the transform are specified for an arbitrary reference. You simply need to define on time the transform between this arbitrary reference and the new fixed reference, and use the arbitrary reference in all other colorspaces :

# this will be the new arbitrary reference, we defined a first time against the
# new fixed reference.
 - !<ColorSpace>
    name: ProFilmWideGamut
    from:
        !<MatrixTransform>  { matrix: [ 0.005, 0.857, ...
        
# then all the other colorspaces are defines against it
 - !<ColorSpace>
    name: sRGB
    from:
        ProFilmWideGamut:
            !<MatrixTransform>  { matrix: [ 0.005, 0.857, ...

 - !<ColorSpace>
    name: ACES - ACEScg
    from:
        ProFilmWideGamut:
            !<MatrixTransform>  { matrix: [ 0.825139, 0.17797, ...
        
# and so on ...

Technically these changes doesn't actually require the reference to be fixed. It could maybe be a new issue in itself. They do allow to keep the flexibility fo the arbitrary reference while having it actually fixed. Which having a fixed reference related to this issue ...

Opened issue

• This still doesn't resolve what this new fixed reference colorspace should be. And my color knowledge will not allow me to answer that. But I still have the opinion that if CIE is the root of every colorspace why not starting from here ? (it is for example what the colour library have choose to express RGB colorspaces 😉)
• Now that we have a fixed reference space, does interchange roles are still needed ? As they could be produced by OCIO behind the scene. Or they could still have to be defined by the user.
• What about specifying multiples references per colorspace ? I don't know why it could be useful but with the new above syntax we could have this :

 - !<ColorSpace>
    name: ACES - ACEScg
    from:
        ProFilmWideGamut:
            !<MatrixTransform>  { matrix: [ 0.825139, 0.17797, ...
        sRGB:
            !<MatrixTransform>  { matrix: [ 0.05619, 0.4563, ...

---

It was a long-one, I'm sure I have forgotten things or arguments that could invalid my suggestion but that's why I'm asking you to please tell me why this would not work.
I do feel that I could have gone further in the explanation but that is first mainly to just opened the discussion on new paths.

Cheers.
Liam.

[EaryChow]

Question, why D65 for the XYZ space? I believe the proper XYZ has Illuminant E white point, where XYZ of (1, 1, 1) convert to CIE xy with the formula "x= X/X+Y+Z, y=Y/X+Y+Z" result is xy (1/3, 1/3) and that's the chromaticity of Illuminant E if you google it. It seems strange to standardize XYZ against another white point, no?

Standardize Iluminant E also has the advantage of being compatible with Spectral Renderers (using D65 as white point in spectral rendering will cause bias, so spectral renderers are mostly if not all using I-E white point). I think we should enforce the requirement to have a cie_xyz_e_interchange role

[KevinJW]

The rationale goes something like this:

This particular interchange space is used for display referred situations, where a lot of Standards' display calibrations use a D65 white point, by selecting this we avoid the need for any chromatic adaptation for most use cases.

Basically all ITU, sRGB, Display P3, etc have a D65 white point, yes there are alternates D93, DCI, ACES, creative white points etc, but most of the time the interchange is being used to encode for feeding to the device and not for creative or perceptual reasons (which should be handled in the view/look rendering).

As to bias in any spectral renderer, the interchange space is way down stream of what you may or may not be doing in that sense and requires the author of any config to have chosen their spectral weightings to integrate down into your 3 channels, these weighting would also add a bias in that sense and are probably a better place to do so.

You can choose to light your spectral render scene with any SPD you wish; daylight, tungsten, LEDs etc subject to what ever you are trying to simulate, then apply your integration weightings to get to 3 channels, you can scale these to get your desired balance., you might for instance select the ACES ones, or try to match a particular camera vendor, etc. Once you have 3 channels weighted by these integration functions (observer) you have effectively left the spectral scene and now have an "observer referred" scene, which has to pass through the view rendering before encoding for your choice of displays.

it is at this point the role is intended to be used.

[EaryChow]

I believe a standardized XYZ role should not be tied to a particular kind of display device. There needs to be an XYZ IE standard role for generalized chromaticity exchange. Having an XYZ role in Blender for example it would be used for the Black Body shader etc. to read chromaticity for correct XYZ to RGB conversation.

It doesn't make any sense to try to make XYZ "display referred", XYZ is a psudo LMS like model for chromaticity our human eyes see, not a display standard.

[sobotka]

As to bias in any spectral renderer, the interchange space is way down stream of what you may or may not be doing in that sense and requires the author of any config to have chosen their spectral weightings to integrate down into your 3 channels, these weighting would also add a bias in that sense and are probably a better place to do so.

I am 100% uncertain of the “way down stream” here?

Whether we like it or not, our Arabic numeral system enforces some “magic values” that happen when we apply multiplication etc to them.

To this end, given that the CIE XYZ colourimetric stimulus specification is normalized to 1.0, there is only one “innate” neutral in this metric.

TL;DR: Any adaptation, I believe, is already based on notions of bias, because of the mechanisms employed to manipulate the values; the actual mechanism is in meatspace, and never generates nonsense values for example, because it is a closed domain of Hering opponency. This meatspace processing is also unknown, and therefore any and all attempts at emulation are ill defined I reckon?

So in terms of colourimetry, given the basis vectors, I believe there might only be one “true neutral” of 1.0 / 3.0?

[KelSolaar]

Hi @EaryChow,

Standardize Iluminant E also has the advantage of being compatible with Spectral Renderers (using D65 as white point in spectral rendering will cause bias, so spectral renderers are mostly if not all using I-E white point). I think we should enforce the requirement to have a cie_xyz_e_interchange role

Whether it is E, D65 or anything does not really matter provided you know what it is and it is correctly specified.

I would like to also point out that CIE Illuminant E is not more compatible with a spectral renderer than CIE Standard Illuminant D65 (or any other illuminant for that matter). The beauty of using a spectral render is that it is actually possible to dismiss the concept of adopted and adapted illuminant as the rendering is performed in a space where no instrument integration or balancing has occurred yet. Put another way, and as @KevinJW pointed it out, the radiance incident to the instrument (or observer) might have an infinite variety of spectral distributions and one is free to apply any desired white balance weightings (or chromatic adaptation transform). Importantly, there is also no requirement for the CIE XYZ tristimulus values to be neutral, white balanced or chromatically adapted.

From a practical production standpoint, CIE Illuminant E is not used in a spectral renderer, you will typically use a Daylight or Blackbody-like illuminant or the irradiance of an existing fixture or environment that was spectrally measured. Worth noting that CIE Illuminant E is an "abstract" illuminant that does not have any real world counterpart where all the other CIE Illuminants have.

I believe a standardized XYZ role should not be tied to a particular kind of display device. There needs to be an XYZ IE standard role for generalized chromaticity exchange. Having an XYZ role in Blender for example it would be used for the Black Body shader etc. to read chromaticity for correct XYZ to RGB conversation.

Somehow repeating what I wrote in the beginning: If you know the source and target encoding specification, the interchange space is not critical provided it is also well specified. ICC uses D50 for example, we do use D65 in Colour because it is the most widely used (and is the CIE recommended standard Daylight Illuminant). It makes colour conversions easier for wide variety of applications. If we were to use something else, e.g. CIE Illuminant E or D50, we would pretty much require chromatic adaptation for any colour transformation to satisfy a "niche", albeit arguably important use case!

Cheers,

Thomas

[EaryChow]

I would like to also point out that CIE Illuminant E is not more compatible with a spectral renderer than CIE Standard Illuminant D65 (or any other illuminant for that matter). The beauty of using a spectral render is that it is actually possible to dismiss the concept of adopted and adapted illuminant as the rendering is performed in a space where no instrument integration or balancing has occurred yet.

The problem is, in most production scenes, most surfaces will be textured with RGB, so a production-ready spectral renderer need to be able to use RGB texture inputs. It is usually done by upsampling/spectral reconstruction from RGB to spectra before path tracing. Now, does it make sense for an I-E light to hit an Linear BT.709 defined white surface and reflect D65 out? This is just white, think about other colored situations, how biased it would become with D65 white point. This is exactly why we need to use I-E in spectral renderers.

[KelSolaar]

How you perform spectral upsampling (or recovery) is an entirely separate problem and discussion to that of a whitepoint for interchange. I agree with you that depending on the algorithm you want to use CIE Illuminant E when upsampling but it really depend on the actual process.

That being said, you will almost certainly never get D65 out of that process, you will get a metamer that might account for D65 as a function of the upsampling process. Those two metamers were generated with a D illuminant and E from white for example:

The problem is that you have no clue in the first place whether your white surface reference or photograph has a flat spectrum because the integration / RGB process has irremediably reduced its dimensionality. Without more information, any metamer is valid. Whether your white surface reference or photograph is white depends on the illumination it has been shot under and the white balance setting the camera was set to.

[doug-walker]

Closing this since PR #1711 updated Config::validate to log an Error if the required interchange roles are not present in configs of version 2.2 or higher. The ociocheck command-line tool was updated to inform config authors if they are not adhering to this new requirement.

Thank you for the interesting thoughts and discussions in the comments on topics related to this issue.