I don't think this really matters, but my LCMS is v2.17 without fastfloat. Krita appimage is still on 2.14

I find another way to trigger this same assertion failure, it happens when I move krita from one monitor to the other then moving it back

Hi, Ming!

Do you compile Krita yourself? Could you check what values are passed to the constructor of IccColorProfile? Looking at the code, the only codepath I could imagine is that could cause such assert is that hyprland passing some really weird values as custom colorants...

Git commit 2d989aa34298c8d83a6f112ddd03f5b0eecae0b7 by Dmitry Kazakov.
Committed on 27/01/2026 at 15:09.
Pushed by dkazakov into branch 'master'.

Make asserts softer in IccColorProfile

If LCMS fails to create a profile, then just safe-assert and leave the profile
in an invalid state. It lets people save their files on some Wayland
compositors, like hyprland.

The bug itself is still valid, though it might be in the compositor, we don't
yet know.

M  +4    -4    plugins/color/lcms2engine/colorprofiles/IccColorProfile.cpp

https://invent.kde.org/graphics/krita/-/commit/2d989aa34298c8d83a6f112ddd03f5b0eecae0b7

Yes I compiled from source, but I can also repro with latest appimage krita-6.0.0-prealpha-a457d92b67-x86_64.AppImage so I guess it's hyprland issue

```
(gdb) info args
this = 0x55556d56aca0
colorants = @0x7ffffffd0100: {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x55555938f430, ptr = 0x55555938f440, size = 8}}
colorPrimariesType = PRIMARIES_UNSPECIFIED
transferFunction = TRC_ITU_R_BT_470_6_SYSTEM_M
(gdb) p colorants@8
$4 = {{<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x55555938f430, ptr = 0x55555938f440, size = 8}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x400000002, ptr = 0x6e85c0c000000001, size = 140737488159632}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x0, ptr = 0x0, size = 0}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x0, ptr = 0x0, size = 0}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x0, ptr = 0x0, size = 0}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x0, ptr = 0x0, size = 0}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x0, ptr = 0x0, size = 0}},
  {<QListSpecialMethods<double>> = {<QListSpecialMethodsBase<double>> = {<No data fields>}, <No data fields>}, d = {d = 0x0, ptr = 0x0, size = 0}}}
```

Oops, I guess this is the right way to print it
```
(gdb) p (colorants.d.ptr)@8
$9 = {0x55555938f440, 0x8, 0x400000002, 0x6e85c0c000000001, 0x7ffffffd0390, 0x0, 0x0, 0x0}
```

🐛🧹 Thanks for your comment!

Automatically switching the status to REPORTED so the team can perform further triage.

In the future you may also do this yourself when providing needed information.

(In reply to Ming Chuan from comment #6)
> Oops, I guess this is the right way to print it
> ```
> (gdb) p (colorants.d.ptr)@8
> $9 = {0x55555938f440, 0x8, 0x400000002, 0x6e85c0c000000001, 0x7ffffffd0390,
> 0x0, 0x0, 0x0}
> ```

If you have Krita compiled, could you just add 

qDebug() << "colorants" << colorants;

in the beginning of the function and see what are the actual values passed to Krita before the crash?

Oh, you can also just try to download the latest nightly appimage, then, when the crash happens, press "Ignore" and check the output in the terminal. It should print all the info provided by hyprland into the terminal.

```
SAFE ASSERT (krita): "iccProfile" in file /home/user/sources/krita/plugins/color/lcms2engine/colorprofiles/IccColorProfile.cpp, line 149
WARNING: failed to to create a profile for the compositor's preferred color space
     compositorPreferred = std::optional(SurfaceDescription(colorSpace: ColorSpace(primaries: Colorimetry(Red: xy(x: 0, y: 0), Green: xy(x: 0, y: 0), Blue: xy(x: 0, y: 0), White: xy(x: 0, y: 0)), transferFunction: NamedTransferFunction(transfer_function_gamma22), luminance: std::optional(Luminance(minLuminance: 2000, maxLuminance: 80, referenceLuminance: 80))), masteringInfo: MasteringInfo(primaries: Colorimetry(Red: xy(x: 0, y: 0), Green: xy(x: 0, y: 0), Blue: xy(x: 0, y: 0), White: xy(x: 0, y: 0)), luminance: MasteringLuminance(minLuminance: 0, maxLuminance: 0), maxCll: 0, maxFall: 0)))
     *requestedDescription = SurfaceDescription(colorSpace: ColorSpace(primaries: Colorimetry(Red: xy(x: 0, y: 0), Green: xy(x: 0, y: 0), Blue: xy(x: 0, y: 0), White: xy(x: 0, y: 0)), transferFunction: NamedTransferFunction(transfer_function_srgb), luminance: std::optional(Luminance(minLuminance: 2000, maxLuminance: 80, referenceLuminance: 80))))
```

A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2620

Hi, Ming!

Could you please test the patch?

https://invent.kde.org/graphics/krita/-/merge_requests/2620

The test plan is simple:

1) Activate "Preferred" surface management mode
2) Try to move the window between screens
3) Verify no crashes happen
4) Verify Help->Color Management Report doesn't have any "ERROR" lines telling about initialization failures.


PS:
And don't forget to report this bug to hyprland developers. That is definitely a bug in their implementation. The compositor should never send nonsense like that:

[3996291.759] {Default Queue} wp_image_description_info_v1#42.primaries(0, 0, 0, 0, 0, 0, 0, 0)
[3996291.761] {Default Queue} wp_image_description_info_v1#42.tf_power(10000)
[3996291.763] {Default Queue} wp_image_description_info_v1#42.tf_named(2)
[3996291.764] {Default Queue} wp_image_description_info_v1#42.luminances(2000, 80, 80)
[3996291.765] {Default Queue} wp_image_description_info_v1#42.target_primaries(0, 0, 0, 0, 0, 0, 0, 0)
[3996291.767] {Default Queue} wp_image_description_info_v1#42.target_luminance(0, 0)
[3996291.769] {Default Queue} wp_image_description_info_v1#42.target_max_cll(0)
[3996291.770] {Default Queue} wp_image_description_info_v1#42.target_max_fall(0)
[3996291.771] {Default Queue} wp_image_description_info_v1#42.done()

Primaries is an obligatory even according to the wayland protocol and it should report non-nonsense (well, the latter is not guaranteed by wayland though :) )

Git commit 601e40f7244bd69d646e09143bee571b8896073e by Dmitry Kazakov.
Committed on 29/01/2026 at 12:15.
Pushed by dkazakov into branch 'master'.

Fall back to unmanaged mode when Wayland reports nonsense

It seems like hyprland compositor is okay with sending us
nonsense instead of the preferred surface description:

wp_image_description_info_v1#42.primaries(0, 0, 0, 0, 0, 0, 0, 0)
wp_image_description_info_v1#42.tf_power(10000)
wp_image_description_info_v1#42.tf_named(2)
wp_image_description_info_v1#42.luminances(2000, 80, 80)
wp_image_description_info_v1#42.target_primaries(0, 0, 0, 0, 0, 0, 0, 0)
wp_image_description_info_v1#42.target_luminance(0, 0)
wp_image_description_info_v1#42.target_max_cll(0)
wp_image_description_info_v1#42.target_max_fall(0)
wp_image_description_info_v1#42.done()

Obviously, LCMS cannot create a profile with zero primaries,
so we should gracefully report the profile creation failure
and continue with different options (just downgrade color
management).

When everything has failed, we just add an "ERROR" message
to the color management report (though it is quite improbable
to happen).

M  +174  -137  libs/ui/KisCanvasSurfaceColorSpaceManager.cpp
M  +6    -0    libs/ui/KisCanvasSurfaceColorSpaceManager.h
M  +8    -1    plugins/color/lcms2engine/colorprofiles/IccColorProfile.cpp

https://invent.kde.org/graphics/krita/-/commit/601e40f7244bd69d646e09143bee571b8896073e