Created attachment 138626 [details] HDR palette SUMMARY I'm noticing that the display of color spots, including floating-point HDR colors, in the Palette docker look very different in the Krita 5 prealpha AppImage compared to Krita 4.4.3, if 1. the document is not in linear sRGB, and 2. a working OCIO config is active in the LUT management docker. I make sure that the color space of the document and the input space in the OCIO config match exactly. In Krita 4.4.3 the palette colors look correct and consistent with every color space that I can find a match for, but Krita 5 only displays them right if the document and OCIO input are (linear gamma) sRGB. The palette color in this case also doesn't match the Specific Color Selector, nor the resulting color on canvas. I always start Krita with LC_ALL=C to avoid the number formatting issue in the OCIO LUTs. STEPS TO REPRODUCE 1. Create or open a document in 16- or 32-bit floating-point, linear sRGB 2. Add an OCIO config like Filmic or ACES in the LUT docker and set the input and display settings correctly 3. Use colors picked from a palette in the Palette docker on canvas and compare their look 4. Convert the document color space to a wide gamut like ACEScg, update the OCIO input space to match it, and compare again OBSERVED RESULT Color spots are not representative of the resulting color on canvas. Even super bright color spots (at float value 16.29 in any channel) appear dimmed in terms of display brightness. EXPECTED RESULT Color spots should match the look on canvas and in the Specific Color Selector like is the case in Krita 4.4.3. SOFTWARE/OS VERSIONS Tested in the 5.0.0-prealpha (git 3d23ca9) AppImage. ADDITIONAL INFORMATION If the OCIO configs I tested with are needed: Filmic - https://github.com/sobotka/filmic-blender ACES - https://github.com/sobotka/ACES-1.2-Displays-Formatted The ACES download is very large because it includes a ton of baked LUTs and ICC profiles. ACES has a lot of input colorspaces and display output options if needed, including HDR10 / HLG display targets. I'll attach the HDR palette I used, which was created by Wolthera, if I'm not mistaken.
Created attachment 138627 [details] palette display comparison And a screenshot comparison.
Ok, so, I cannot reproduce this :( What I did: 1. Load a 16bit float linear rec 2020 image. 2. Open the scene linear KPL file. 3. Use the filmic blender ocio config (sobotka seems to have deleted the other file): (Input CS: linear, Display Device: Filmlike, View: Filmic Log Base, Look: High Contrast I've also tried it with converting the image to a wide gamut image with gamma 22, and with the test-ocio configs from imagework, amongst which the aces 1.0.1 ocio.config. No matter what config I choose, the colors in the docker match the colors on the screen. Mind, LC_ALL=C isn't necessary anymore, but I am unsure if that should make a difference???
Created attachment 141334 [details] wolthera failing to reproduce the bug...
Created attachment 141363 [details] palette display mismatch That is odd. I'm using a nightly build for Windows now from a few days ago (git 6ca8117) and still get the same issue. I also removed the kritarc and kritadisplayrc files and the resources folder to start with the default config, but no change from that either. New screenshot attached.
Created attachment 141400 [details] Krita 5.1 alpha 0636d6f Confirmed on Windows 10 with ANGLE and a SDR monitor, nightly master 0636d6f against 4.4.8, with one of netflix's HDR images: https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Netflix/avif. Attaching screenshot.
Created attachment 141401 [details] Krita 5.1 a89da33ea9 with OCIO v2
Created attachment 141402 [details] Krita 4.4.8
For the sake of transparency, I exported the AVIF that's shown in the screenshots using 5.1 to KRA, then opened the KRA in 4.4.8.
Then it must be a windows only bug :| I don't have a windows device, so I'll have to unassign myself :(
amyspark sussed out that this is also caused by the LCMS fastfloat plugin, despite the original design being that OCIO is in a completely different code path...
Hijacked https://invent.kde.org/graphics/krita/-/merge_requests/1045 to push the patch along with the update.
*** Bug 442004 has been marked as a duplicate of this bug. ***
Git commit 411297e62feb2d04c38182e2e5f3cab8361db46c by L. E. Segovia. Committed on 14/09/2021 at 14:29. Pushed by lsegovia into branch 'master'. LittleCMS: fix linearity check for 32-bit and floating point RGB Related: bug 442004 M +5 -5 3rdparty/ext_lcms2/0001-Add-cmake-build-system.patch M +3 -3 3rdparty/ext_lcms2/0002-Quick-check-for-SSE-support.patch M +4 -4 3rdparty/ext_lcms2/0003-Separate-fast-float-plugin.patch A +27 -0 3rdparty/ext_lcms2/0004-Linear-RGB-also-comes-in-32-bit-and-floating-point.patch https://invent.kde.org/graphics/krita/commit/411297e62feb2d04c38182e2e5f3cab8361db46c
Git commit 565c618bb0e0b18716e5b4637e5186d703c41f92 by L. E. Segovia. Committed on 14/09/2021 at 14:43. Pushed by lsegovia into branch 'krita/5.0'. LittleCMS: fix linearity check for 32-bit and floating point RGB Related: bug 442004, bug 439947 (cherry picked from commit 411297e62feb2d04c38182e2e5f3cab8361db46c) M +5 -5 3rdparty/ext_lcms2/0001-Add-cmake-build-system.patch M +3 -3 3rdparty/ext_lcms2/0002-Quick-check-for-SSE-support.patch M +4 -4 3rdparty/ext_lcms2/0003-Separate-fast-float-plugin.patch A +27 -0 3rdparty/ext_lcms2/0004-Linear-RGB-also-comes-in-32-bit-and-floating-point.patch https://invent.kde.org/graphics/krita/commit/565c618bb0e0b18716e5b4637e5186d703c41f92
Git commit cae8af720c388bda9007cf95ab760ee697e5cd9c by Halla Rempt, on behalf of L. E. Segovia. Committed on 20/09/2021 at 09:24. Pushed by rempt into branch 'master'. LittleCMS: fix linearity check with upstream update Related: bug 442004, bug 441366 D +0 -27 3rdparty/ext_lcms2/0004-Linear-RGB-also-comes-in-32-bit-and-floating-point.patch M +2 -2 3rdparty/ext_lcms2/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/cae8af720c388bda9007cf95ab760ee697e5cd9c
Git commit 5548012a25362e3786cec812a312f5d57b523dd7 by L. E. Segovia. Committed on 21/09/2021 at 14:00. Pushed by lsegovia into branch 'krita/5.0'. LittleCMS: fix linearity check with upstream update Related: bug 442004, bug 441366 (cherry picked from commit cae8af720c388bda9007cf95ab760ee697e5cd9c) D +0 -27 3rdparty/ext_lcms2/0004-Linear-RGB-also-comes-in-32-bit-and-floating-point.patch M +2 -2 3rdparty/ext_lcms2/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/5548012a25362e3786cec812a312f5d57b523dd7
So I think I need to reopen this report. I'm trying the newest Nightly e2a04dd823 on Windows and the same display issue is still present. There are now more general issues with floating-point colors, I put that in a new bug report since I don't know how much it relates to this report. https://bugs.kde.org/show_bug.cgi?id=444439 Picking a color from an HDR palette also seems to be extra broken on 32-bit float documents, if it uses a gamut other than sRGB-g10. Whether OCIO is activated or not, the picked color is a tone-mapped version of the original color value. When picking the painted colors from the canvas they never go above 1.0, and it's immediately visible that they're not HDR with ACES or Filmic active. This problem doesn't occur with 16-bit float. Strangely, the Specific Color Selector also displays the same wrong tone-mapped values after selecting a color patch from the palette if it's set to 32-bit float and a different gamut from sRGB-g10, but not for 16-bit. Lastly, very minor UI complaint: The new version info text on the bottom of the LUT docker is quite long, at least on Windows, and increases its minimum width. So if the LUT docker is in a column with other dockers I can't shrink that as much as I previously could. That's all.