Which version of Krita are you using, and are you using distribution packages or the appimage?

I'm using 4.1.8 from the openSUSE-Tumbleweed-Oss repository.

Created attachment 119569 [details]
Clipboard test

I cannot reproduce. If I right-click on that image, select "copy image" then create a new image from clipboard in Krita, I get the attached result.

Yeah, I've discussed this on the IRC channel beforehand, looks like it is caused by a newer Qt version?

That could be. This laptop still has Qt 5.11, and it works, the appimage has 5.12, and there it's broken. It's even possible the Qt people have updated the the clipboard code on Linux to be in line with what it is on Windows, where the alpha channel never gets through.

Hm, on my laptop with 5.12.0, this isn't broken either, so it might even be a regression in a point release of Qt 5.12.

Even more mysterious, on an Ubuntu VM with Qt 5.12.2 it's not broken either, and that's where the appimages are built.

Alright I've just tried building 4.1.8 from source, but the issue persists.

I'm really distraught by the compression artefacts, it's as if the image was transcoded on the fly to a lossy format, that would also explain the loss of transparency, but why does that even happen?

That's not what I see though, if I look at the image it's only on the semi-transparent edges between pixels and transparent areas that it looks like as if there are artefacts, but that's simply the effect of removing the alpha channel from an image.

All Krita does is ask the QClipBoard class for an image; we get a QImage back and have no control over the format of the image. I have tried to see whether there have been any recent changes in Qt's handling of clipboard handling, but I couldn't find any relevant things.

Right now, I an reproduce with the nightly appimage on Kubuntu 19.04, but not with anything I build myself from master on Kubuntu or KDE Neon. I will have a trie with my OpenSuse based desktop today.

Damn, building master on OpenSUSE Leap 15.0 also doesn't show the problem. Let me try with 4.1.

Okay, I don't think it has got something to with the version of Qt. It looks like it's a timing issue. 

When I print the format of the image we get when created an image from the clipboard three times, I see:

>>>>>>>>>> QImage::Format_RGB32 false
>>>>>>>>>> QImage::Format_RGB32 false
>>>>>>>>>> QImage::Format_ARGB32 true

It's easier to get a clip with alpha channel if the copy is made while Krita is running, but that's not a certainty.

Looking into the mimedata in the clipboard, I see the following formats announced:

>>>>>>>>>> QImage::Format_RGB32 false ("TIMESTAMP", "TARGETS", "MULTIPLE", "SAVE_TARGETS", "text/html", "text/_moz_htmlinfo", "text/_moz_htmlcontext", "image/png", "image/bmp", "image/x-bmp", "image/x-MS-bmp", "image/x-icon", "image/x-ico", "image/x-win-bitmap", "image/vnd.microsoft.icon", "application/ico", "image/ico", "image/icon", "text/ico", "image/jpeg", "image/tiff", "application/x-qt-image")

However, only sometimes there's data for image/png, while there's always data for image/jpeg. Firefox never puts data in for the other image formats:

Format "TIMESTAMP"
Format "TARGETS"
Format "MULTIPLE"
Format "SAVE_TARGETS"
Format "text/html"
Format "text/_moz_htmlinfo"
Format "text/_moz_htmlcontext"
Format "image/png"
data 290949 mime "image/png"
Loaded image succesfully QImage::Format_ARGB32 true
Format "image/bmp"
data 0 mime "application/x-zerosize"
Could not load image of type "image/bmp"
Format "image/x-bmp"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-bmp"
Format "image/x-MS-bmp"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-MS-bmp"
Format "image/x-icon"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-icon"
Format "image/x-ico"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-ico"
Format "image/x-win-bitmap"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-win-bitmap"
Format "image/vnd.microsoft.icon"
data 0 mime "application/x-zerosize"
Could not load image of type "image/vnd.microsoft.icon"
Format "application/ico"
Format "image/ico"
data 0 mime "application/x-zerosize"
Could not load image of type "image/ico"
Format "image/icon"
data 0 mime "application/x-zerosize"
Could not load image of type "image/icon"
Format "text/ico"
Format "image/jpeg"
data 33290 mime "image/jpeg"
Loaded image succesfully QImage::Format_RGB32 false
Format "image/tiff"
data 0 mime "application/x-zerosize"
Could not load image of type "image/tiff"
Format "application/x-qt-image"
Final QImage QImage::Format_ARGB32 true

I've created a bit of a complicated system that probably duplicates what Qt does internally to get the best quality clip, but if there's only a jpeg image on the clipboard, there's nothing we can do :-(

Git commit 09d3bdbe67b955d784c765ab6f633ccc2f0d194e by Boudewijn Rempt.
Committed on 23/04/2019 at 08:34.
Pushed by rempt into branch 'master'.

Check whether we are using the best-quality image on the clipboard

Firefox can put multiple versions of an image on the clipboard. From
tests, there's always a fairly useless JPG, and sometimes a decent
PNG, but of the formats it advertises, in my tests, only these two
are present. It seems a bit timing dependent, in that if Krita is running,
chances for getting the PNG clip are a bit better, but still not 100%.

There's nothing more we can do that check whether we've got the best
image type, in the order PNG, TIFF, BMP, JPEG, and use that.

This is debug output that shows what's on the clipboard if we're lucky:

Format "TIMESTAMP"
Format "TARGETS"
Format "MULTIPLE"
Format "SAVE_TARGETS"
Format "text/html"
Format "text/_moz_htmlinfo"
Format "text/_moz_htmlcontext"
Format "image/png"
data 290949 mime "image/png"
Loaded image succesfully QImage::Format_ARGB32 true
Format "image/bmp"
data 0 mime "application/x-zerosize"
Could not load image of type "image/bmp"
Format "image/x-bmp"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-bmp"
Format "image/x-MS-bmp"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-MS-bmp"
Format "image/x-icon"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-icon"
Format "image/x-ico"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-ico"
Format "image/x-win-bitmap"
data 0 mime "application/x-zerosize"
Could not load image of type "image/x-win-bitmap"
Format "image/vnd.microsoft.icon"
data 0 mime "application/x-zerosize"
Could not load image of type "image/vnd.microsoft.icon"
Format "application/ico"
Format "image/ico"
data 0 mime "application/x-zerosize"
Could not load image of type "image/ico"
Format "image/icon"
data 0 mime "application/x-zerosize"
Could not load image of type "image/icon"
Format "text/ico"
Format "image/jpeg"
data 33290 mime "image/jpeg"
Loaded image succesfully QImage::Format_RGB32 false
Format "image/tiff"
data 0 mime "application/x-zerosize"
Could not load image of type "image/tiff"
Format "application/x-qt-image"
Final QImage QImage::Format_ARGB32 true

We cannot do more than this, so I'm closing

M  +73   -9    libs/ui/kis_clipboard.cc

https://invent.kde.org/kde/krita/commit/09d3bdbe67b955d784c765ab6f633ccc2f0d194e

Unfortunately the patch did not affect my issue, but I did find some more info.
Copying from Gwenview instead of Firefox does work.

Like I tried to say, whether or not firefox also puts a png one the clipboard as well as a jpg is completely random. It might be timing dependent, it might be dependent what other clipboard clients are running on the system -- but it's out of our hands.

Well since it didn't affect the issue I think it's best to revert the commit since pasting images now causes a significant lag.

In the case that there are two images, we are now at least sure we get the right one.