| Summary: | Broken color display in the Palette docker with an active OCIO config | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | M <manuel.snudl.zeidler> |
| Component: | Color models | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | amy, dimula73, dreatern, griffinvalley, tamtamy.tymona |
| Priority: | NOR | Keywords: | regression |
| Version: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/565c618bb0e0b18716e5b4637e5186d703c41f92 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
HDR palette
palette display comparison wolthera failing to reproduce the bug... palette display mismatch Krita 5.1 alpha 0636d6f Krita 5.1 a89da33ea9 with OCIO v2 Krita 4.4.8 |
||
|
Description
M
2021-05-20 19:38:44 UTC
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. |