SUMMARY I'm trying the newest Nightly e2a04dd823 on Windows and it seems there are now several problems with clipping HDR colors. If the document is in 32-bit float and uses any gamut other than the default sRGB-g10, it's not possible to get color values above 1.0 in any color channel anymore, either from paint brushes or stacking layers in Addition blend mode. If the document is converted to a different profile like sRGB-srgbtrc or ACEScg-g10, the colors also get clipped to a max of 1.0 in the process. Additionally, very saturated high-brightness colors get visually shifted in the conversion. These problems don't seem to happen with 16-bit float, but converting to 8 or 16-bit integer will also result in those color shifts, so it's not even possible to guarantee the visual appearance of the image for export in an SDR format anymore. STEPS TO REPRODUCE Conversion: 1. Create a document in 32-bit float and default sRGB-g10 2. Paint with a brush set to Addition, or stack layers in Addition mode 3. Use Image > Convert Image Color Space and choose a different profile 4. Check the resulting color channel values from the canvas Blending: 1. Create a document in 32-bit float, choose a different profile than sRGB-g10 2. Paint with a brush set to Addition, or stack layers in Addition mode 3. Merge and check the resulting color channel values from the canvas OBSERVED RESULT Loss of color information, potential visual shifts. EXPECTED RESULT Retention of the HDR colors. SOFTWARE/OS VERSIONS Krita 5.1.0-prealpha (git e2a04dd) on Windows 10
*** This bug has been marked as a duplicate of bug 355727 ***
@Amyspark are you sure about closing this report as duplicate? Based on comment in https://bugs.kde.org/show_bug.cgi?id=437429#c17, it seems to be a regression after recent changes, so it should be open and with tags "regression" and "release_blocker" instead of a duplicate of a 4 year old bug. @M can you please confirm that it didn't happen in Krita 4.4.8 so I can reopen it as its own bug and not duplicate of bug 355727?
Right, so I did some more testing. First, I could not reproduce the problem that basic blending operation I know can algorithmically handle HDR color values would clip them, such as Addition, or Multiply and Normal with values above 1.0. I found is that the Specific Color Selector could show the values clipped at 1.0, but the Foreground color selector window shows the correct channel values, and that picking an HDR color from a palette would also paint a clipped or somehow tone-mapped version of the color. That would tie back to https://bugs.kde.org/show_bug.cgi?id=437429 So unless I can reproduce what I thought was happening initially, I'm assuming I was mislead by the number readouts and those blending modes are not affected. What I can confirm however is that certain color space conversions will clip color values to 1.0, possibly between linear and non-linear profiles. This is not exclusive to Krita 5.1, I can reproduce it the same way in 4.4.8 on Windows, but curiously 4.4.8 on Linux doesn't seem to have the issue. It might be a Windows specific bug, but not a regression to Krita 5.1. To reproduce on a Windows build: 1. Create a document in 16 or 32-bit float and ACEScg-g10 2. Produce some HDR color values on the canvas and merge down all layers 3. Verify from the Foreground color picker that any color channel is way above 1.0 4. Use Image > Convert Image Color Space. Leave the bit depth, choose sRGB-srgbtrc (not linear). Rendering intent can optionally be relative colorimetric 5. Check the colors on canvas again in the Foreground color picker The colors on canvas should now be clipped at 1.0. Some 16-bit float conversions seem to be more robust, but most combinations will still result in clipping on my end. You can also try the conversion result of negative float colors from Subtract. Though none of the color pickers seem to indicate negative values.