HtoA - color management, reliability, kick inside Sol IPR architecture, change of defaults (lighting overlap)

Hey, just a small point from my side when it comes to color management & a couple of other things in Houdini since I see this being worked on.

I'm talking from the standpoint that you've got these settings exposed in the Arnold node, they don't take any effect at all - visually. After a bit of debugging they seem to affect the final exr if you render with kick - noticed some avg luminosity differences from oiio inspects on husk renders.

These don't change anything in the IPR:

I've got a healthy amount of skepticism when it comes to color management in Houdini and how it's being handled there (completely ocio rules driven - it believe it also takes precedence for the "Output color family" tagging). For this reason I'm promoting bypassing as much of how it's handled there as possible. I've managed to bypass it w/ other engine, but it was by using husk only as the initialization/trasnlation part & then launching a native render delegate process w/ color management translation layers, might be doable even for the native husk process, but if Arnold's rop exposed an option to switch to the native kick inside Solaris, I'd personally always opt in for that option for more trustworthy pipeline.

I know that this is most likely a big architectural change, but you can kick off a final render w/ kick either way, would be nice to have that option for the IPR as well.

I'm going to reference a couple of resources to elaborate:

USD docs propose & expose linrec2020, you can't find it at all under mtlx image dropdown & the dropdown doesn't do anything at all - https://openusd.org/dev/user_guides/color_user_guide.html

If I'll take it from the source side of things when it comes to mtlx, the `targetSpace` might be bypassed or who knows however it was implemented, I'd certainly not call it a stable implementation of color management - https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXGenShader/ColorManagementSystem.cpp

I'm not sure what your experience with the behavior is in other hydra delegate DCCs, but if at least the `USD MaterialX Builder (Arnold)` subnetwork ran on mtlx with properly correctly working color management on `mtlx image` nodes (non-Arnold variant), it'd be amazing. The native Arnold `Image` node takes an effect on color management w/ automated maketx, but it'd be great if we could have a `Mtlx Image` node with working color management out of the box (handled well & correctly by Arnold) to rely on. The current "Arnold `mtlximage`" has double color management for some reason, one of them's straight text input. Both of them (including the native mtlx one) don't expose linrec2020, the "native" one has whatever rule/signature driven color management, the dropdown doesn't do anything.

Attaching images to avoid confusion:

There's a way to bypass the color management which is to just quite simply build your own color manager for textures inside Houdini which you can rely on & read all `.tx files` as raw, not the most artist friendly way to go about it. I'll gladly share my config & ocio - please take in mind that even Arnold's automated maketx is driven through the rules. Additonally I'd also update documentation from your side on Color management inside HtoA, exposing colorspace parameters e.g. linrec2020 inside `Utility` requires correct family assignment inside the config.

Additionally when it comes to ocio roles, there's one pretty neat one called `srgb-linear` which you can utilize for domelight textures whilst still having scene-linear run on how it was defined, I'm mentioning this since I've noticed some "blasted domelight" issues when it came to Arnold. If `srgb-linear defined` -> use it for domelight, else `scene-linear`.

When it comes to lighting I have to add that Arnold's pretty close what's defined as non-linear here, but I believe that it's simply caused by having `1e+30` as the default value for `AA Sample Clamp` - it's not as bad as the non-linear clipping. I learned to accept the fact that Arnold's significantly brighter than any other render delegate out there as its nature when I was doing comparisons. Might be worth taking a look into if it's not the expected behavior, maybe compare w/ other non-Hou hydra DCCs. I know that having special exceptions purely for Hou in the source from the dev side is not ideal.

(ref - https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_for_houdini_ah_getting_started_ah_Color_Management_html)

Also as a last part when it comes to lighting, it seems that it has gotten way better over the latest releases, but I'm still viewing Arnold's light temperature especially on the warmer side as unpleasant/incorrect/unexpected. You can fix it by building your own custom DRT for wider gamuts (ap0, linrec2020) & shifting high-lum values more towards orange instead of red, but you can't be expecting everyone to have the skills to do that especially when the use of ACES is being promoted, even ACES 2.0 doesn't help much. Linrec709 seems to produce a bit more expected results when it came to light temp.

What I believe the currently exposed color management settings are supposed to be doing:

How I'd like to see in the IPR and on the final exr at the same time when I change dropdown values. As a small addition when it comes to this to avoid user confusion & even I don't know what it does, what even is `output color family` dropdown? You set up scene linear / rendering space & it'd give you that outcome on the exr as expected, is it pure oiio metadata tagging? I don't see the purpose of it & it's not documented. Why is it not united?

Final linrec 709 exr:

Final awg4 exr:

To clarify the exrs results, selected scene-lin colorspace, saw the results within the IPR, got the same results in the final exr. Consistency, getting what I'm expecting (without the necessity of restarting Hou just to change it, hinting at another benefit of having kick process in the Sol IPR, might help with lifecycle issues as well). As a small side-note, `flow` runs on kick.

I'll still have to tinker w/ mtlx implementation from the dev-side & see if I can bypass & correct the Hou way of things on mtlx, magic in reliability happens when you bypass Hou/husk & connect the IPR to the native process & leave husk just for init & translation, hence why I'm suggesting the kick architecture & I'm a bit reliability biased. When it comes to some of the native nodes connected to husk (Moonray w/ outside of USD defined colorspaces just for demonstration) - `mtlximage (Arnold)` as an example, I don't see a reason why it'd not have at least the usd defined colorspaces exposed. The ROP can read the color spaces, so can the (what I'm calling legacy just due to the design - click more times than you'd have to just to connect nodes) native `Arnold Material Builder`:

Start by reproducing the reported differences across the Arnold node, Solaris IPR, kick, and final EXR, then inspect the mtlx image and USD MaterialX Builder entry points. The payload names no files or tests; done would require an agreed scope covering consistent color-management behavior, the proposed kick-based IPR option, and clarified documentation.

Written by the indexing model from the issue text.