@ChrisBrejon by raw I meant ACEScg (that is, the working/rendering space). You had said Rec.2020 which is of course close to ACEScg, but it struck me as odd. So I thought it may be something to check.
Then again, ACES does seem to have a hard time with saturated colors. We know it has a hard time with blue and yellow. So maybe you’ve discovered an issue with red…
ACES reminds me of driving a race car, where the slightest turn of the steering wheel can send you crashing into a wall. ACES likewise seems really sensitive. I think as it grows into more widespread use it will need to develop seat belts and bumpers so it’s not so easy to make errors.
One of those error prone places for me has been in picking colors. That’s why I set the color picking role in our OCIO config to ACEScg to prevent that. I really think they should change that in the official OCIO config. Having it set as Rec.709 makes it almost inevitable that users will pick colors with values above 1. Because the display transform applies a tone map curve to the output image, a value of 1 in sRGB or Rec.709 space will remap to a value of around 10 in ACEScg linear space. In other words, if you pick a color like pure red for your diffuse texture in Maya then the RGB values of <0,0,1> will actually give you pixel values in your render of <0,0,10> making your shaders light emitting which breaks the PBR rule of energy conservation which states that an object cannot reflect back more light that what is shining on it.
Check the pixel value of the red in your rendered image and see what it is. I bet it’s really high (like above 10) which is causing it to clip.