Bug 416515 - Krita cannot save if file contains reference images
Summary: Krita cannot save if file contains reference images
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Reference Images (show other bugs)
Version: git master (please specify the git hash!)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-21 00:35 UTC by Storm Engineer
Modified: 2020-01-28 09:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Storm Engineer 2020-01-21 00:35:55 UTC
If I add reference images to my file, any save attempt, manual or autosave will fail with the following error:

"Could not save [file path]

Reason: Unknown error"

The following error is printed in the terminal:

libpng error: known incorrect sRGB profile
libpng error: known incorrect sRGB profile
saving binary data failed

Deleting the reference images makes save work again.


STEPS TO REPRODUCE
1. Open a file, try saving.
2. Add one or more reference images, try saving again.
3. Delete reference images, try saving again.

OBSERVED RESULT
Save fails if reference images are present.

EXPECTED RESULT
Saving should work.

SOFTWARE/OS VERSIONS
Krita

 Version: 4.3.0-prealpha (git ef0a009)
 Languages: en_US, en, en_US, en, hu_HU, hu
 Hidpi: false

Qt

  Version (compiled): 5.14.0
  Version (loaded): 5.14.0

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 5.4.13-arch1-1
  Pretty Productname: Arch Linux
  Product Type: arch
  Product Version: unknown
Comment 1 Halla Rempt 2020-01-21 07:39:17 UTC
This works here, both with my self-built krita and with the nightly appimage build. 

* Which version of libpng do you have? I am still on 1.6; it seems that 1.7 might be more strict than 1.6.

* If might also be a problem with Qt 5.14... I am still on 5.12, because already 5.13 caused a host of regressions. PNG reference images are saved using Qt's PNG export code, not Krita's PNG export code.
Comment 2 Storm Engineer 2020-01-21 10:26:54 UTC
libpng 1.6.37

I'm going to downgrade qt and see if that fixes it.
Comment 3 Halla Rempt 2020-01-21 10:31:16 UTC
I'm on 1.6.34 to be exact. You're using Arch, right?
Comment 4 Storm Engineer 2020-01-21 10:58:56 UTC
Yes, Arch.

Sadly I could not test downgrading qt, because a partial downgrade caused Plasma to be unable to start.

But Arch actually moved on from qt 5.12 last June, and from libpng 1.6.34 in 2017.

Version histories:
https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt5-base
https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/libpng
Comment 5 Halla Rempt 2020-01-21 11:00:05 UTC
I wonder what more we could test -- maybe loading and saving the png image you use for your reference image in kolourpaint or gwenview?
Comment 6 Storm Engineer 2020-01-21 11:34:20 UTC
The PNG loads and saves fine in Gwenview.

I can also save it just fine with Krita when opened as an image, saving only fails when it's inserted as a reference image.

P.s.: I see you changed the platform. I'm confused about that property. What does it actually refer to? The Krita build's origin (shipped by repo vs compiled)?
Comment 7 Halla Rempt 2020-01-21 11:38:59 UTC
Loading and saving PNG's in Krita doesn't use the Qt image loading saving code; saving reference images does.

The platform consists of the source of the build -- built from sources, Arch packages, that sort of thing -- and the OS (Linux).
Comment 8 Bug Janitor Service 2020-01-22 04:33:13 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 9 Halla Rempt 2020-01-22 10:02:01 UTC
I tried to setup an arch vm yesterday, but that's way too much work just to test with Qt 5.14...
Comment 10 Halla Rempt 2020-01-22 10:16:37 UTC
Oh, and I should have asked: does this happen with any image, or with a particular image or set of images that you are using?
Comment 11 Halla Rempt 2020-01-22 10:39:03 UTC
What I think that happens is that starting with Qt 5.14, QImage keeps the icc profile from the original image around, using the new QColorSpace class. When we're trying to save to PNG, libpng protests because Qt also saves PNG with the sRGB flag, which conflicts with the presence of the ICC profile.
Comment 12 Halla Rempt 2020-01-22 10:45:39 UTC
Okay, that's probably not it. I guess I need the kra file without the reference image and the reference image you're working with to try to see what happens.
Comment 13 Halla Rempt 2020-01-22 15:17:25 UTC
Git commit a6d484ca55513ba88cc15f44cf831905da2e224a by Boudewijn Rempt.
Committed on 22/01/2020 at 14:52.
Pushed by rempt into branch 'master'.

Workaround Qt 5.14's colormanagement preventing png files from being saved

M  +11   -1    libs/ui/KisReferenceImage.cpp

https://invent.kde.org/kde/krita/commit/a6d484ca55513ba88cc15f44cf831905da2e224a
Comment 14 Halla Rempt 2020-01-23 08:43:13 UTC
I've managed to create a minimal project showing the bug in Qt: https://bugreports.qt.io/browse/QTBUG-81604
Comment 15 Storm Engineer 2020-01-24 00:13:51 UTC
Sorry for the late reply. Do you still need my assistance with this?
Comment 16 Halla Rempt 2020-01-24 08:26:28 UTC
Nope -- there's a workaround in Krita, and the fix to Qt actually was accepted today.
Comment 17 Halla Rempt 2020-01-28 09:50:29 UTC
Git commit 6a1e32f1c9a115fc03456b592ab31d6e5f2768e6 by Boudewijn Rempt.
Committed on 28/01/2020 at 09:16.
Pushed by rempt into branch 'krita/4.2'.

Workaround Qt 5.14's colormanagement preventing png files from being saved

M  +13   -1    libs/ui/KisReferenceImage.cpp

https://invent.kde.org/kde/krita/commit/6a1e32f1c9a115fc03456b592ab31d6e5f2768e6