I am experiencing some at best un-intuitive, at worst maybe broken color responses when using karma. I am thinking of creating an rfe, but want to make sure that what is happening is actually wrong and not just me being slow/unknowledgeable. The problem is specific to metals as far as i can tell, and kind of hard to explain, so i brought plenty of screenshots.



As you can maybe tell, when a color is pure, in this case red, and in bright lighting (in this case exposure 10 on an area light for demonstration purposes) the usual fade-to-white that is seen in non-metal materials doesn't appear. I am using ACES 1.0 sdr video for color management btw, but that doesn't seem to be the cause.



Adding even the slightest bit of color evenly to the green and blue seems to "fix" the problem. Is this correct behavior? Another related problem i have is with the relative response of seemingly insignificant color amounts in bright lighting.



Above you can see that even the slightest amount of blue seems to turn entirely pink. Same happens with green, turning yellow.
If you add in some green, the pink moves only to the edge/falloff area, but is still surprisingly (to me) noticeable. Don't get me wrong, i know about mixing colors, but the pink skew seems excessive considering the tiny amounts we are working with here, no?



Lastly, i tried to recreate the effect in blender, where the pure-red thing seems to be "fixed", but the pink falloff is also present, although less i feel? (Same OCIO config)




Lastly i just wanted to clear up why i care about this/want to know if it is a bug or just the way things work. I am trying to work with a sort of maroon/bordeaux color, sort of like this.



But whenever a bright light, like a brightspot in an hdri or similar hits the material, it turns pink, like this.



So to reiterate, i get that some skewing would maybe happen irl, but i do think that maybe something is wrong in the math here, over-emphasizing the colors with low values (blue in this case) compared to the higher values (red in this case), making it really hard to get consistent colors, and especially hard to get brand accurate colors. I have created some gradients to illustrate more what i would think was correct/intuitive :



But right now is more like this :



Also i have tested both xpu and cpu, they act the same, so not an "xpu thing", as many things seem to be.

Any info or help is much appreciated, cheers.

I don't think this is wrong. A color will never go to white if any one of the channels is zero. You need to have a non-zero value in every channel.

(0.25, 0, 0) Multiply every channel by 10000 and it's still pure red, G and B are still zero.

(0.25, 0.001, 0.001) Multiply every channel by 10000 and now every channel exceeds 1 and appears white.

Your first example gradient isn't really representitive of shining a bright white light onto something as the color channels increase non-uniformly from right to left which desaturates the color. Shining a white light onto something is like multiplying all the channels equally by some value. In fact if you bring this gradient into an image editing app and increase the exposure you'll see that it becomes pink like in the second gradient.

To expand on that, in real life the spectrum is continuous. Computer color models are based on the human visual model, and if you look at a response chart (like https://en.wikipedia.org/wiki/CIE_1931_color_space#/media/File:Cones_SMJ2_E.svg) you'll see that there's not really anywhere in the visual spectrum where any of the responses of the RGB primaries go to zero. Having pure red (just like a 0 roughness specular) isn't realistic, so the results become unintuitive. A pure red metal can only reflect red light regardless of how blown out the highlights should be.

In your example you have blue set slightly higher than green which, combined with how overblown highlights on metal under bright light can get, is producing what looks like a magenta more than pink on my display. If you want white set both the other values to be equal. Blender is probably just fudging things either on purpose to meet expected behavior / compensate for what I mentioned about pure red being impossible or sorta unintentionally as a fix to a "bug" somebody filed because they didn't understand how metals should work. It's open source and has been around for a long time so your guess is as good as mine. It produces the same magenta when you raise blue more than green which makes me suspect they just raise 0 value RGB channels to 0.001 to be less confusing, but this makes it impossible to create the unrealistic pure red metal which there might be artistic reasons to do sometimes so it's the worse option IMO.

There's another issue in that the color of real metals is defined by complex values sampled across the visual spectrum that can't be properly defined with a single color. Houdini doesn't support full spectrum ior files but Karma CPU is able to render the Conductor node https://www.sidefx.com/docs/houdini/nodes/vop/mtlxconductor_bsdf.html [www.sidefx.com] which defines things using ior and extinction which is more correct but not easy to use unless you have lists of values for the metals you want laying around since the values will make zero sense to you... just have a look at the approximate values for gold on that page. :-) Maxwell Render is one of the few mature renderers that supports full spectrum ior files for conductors and dielectrics (which lets you do things like render models of cut diamonds that display accurate "fire" from reflected light without doing anything hackish), so it is popular among people who need to do accurate architectural or product mockup renders for things like watches and jewelry. I'm not including toy / research renderers in this since several of those can manage this too but you'll never find a way to get files into them that isn't a nightmare.