Bug 426734

Summary: For certain image files I cannot paste into krita/create from clipboard
Product: [Applications] krita Reporter: aiena.makehuman
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: ahab.greybeard, arcooke, ghevan, halla
Priority: NOR    
Version First Reported In: 4.3.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description aiena.makehuman 2020-09-19 15:24:24 UTC 
SUMMARY
I have an unusual problem. For certain jpg's etc from firefox if I copy to clipboard. Ctrl+N takes very long time to load and then the preview is blank  I see one "Text Label" in place of the preview image. The image dimensions seem to show up correctly but if I press create. Only a white canvas is created.

If I copy the image from firefox and try to paste into a already created canvas also the image does not get pasted.

I have verified that the image is stored in the clipboard by trying to paste the same image into GIMP and inkscape the only other 2 programs I had at hand (I am aware they are not QT based).
 

STEPS TO REPRODUCE
1. Open Firefox web browser
2. Open this URL https://i.redd.it/vmmixjanvwn51.jpg
3. Right click and copy the image to clipboard
4. Open/ maximise Krita
5. Press Ctrl+N

OBSERVED RESULT
There is a long delay to open the new file creation dialog.
The Image copied to clipboard does not show up in the preview though ctrl+N does activate. The dimenasions of the image copied to clipboard (sometimes) seem to be filled in correctly in Krita but pressing create puts a different background(plain white).

EXPECTED RESULT
The image should be made available to copy from cipboard into Krita.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: kubuntu 20.04, KDE plasma , Qt version 5.12.8,
(available in About System)
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8

ADDITIONAL INFORMATION
This does not happen with all images only some images. If I use the file command in linux this image does not appear any different from other jpegs but others work.

This may be another bug. I noticed that if you use another image and press ctrl+N (one with which it shows a preview and load dims correctly) and then you copy this image which fails to clipboard from FF. Pressing create in krita after that will load this image but with canvas size limited to dimensions of the other image. SO it appears that a part of krita can read this file correctly.

If I save the file locally and open it in gwenview and then use gwenview's copy and press ctrl+n with Krita the dialog takes time to load but the preview resolution etc are detected correctly and krita display's the file well.

I have tested multiple ways and find this behaviour strange.

Other images with which you can test the above behaviour

https://www.mediafire.com/convkey/31aa/mrwqrylr5zm96dczg.jpg
https://www.mediafire.com/convkey/d5bb/qh1ht3sd8vp4xr3zg.jpg

I have a hypothesis that this may have something to do with the size of the image being copied. If its is larger 1000x1000px the issue is exhibited. Additionally this image wont paste even into a currently open .kra.

=== On further testing ===
I noticed in Firefox an image initially loads scaled to fit the Tab. If I magnify the image to 100% and then use copy to clipboard. Then use ctrl+N in Krita the preview does not show correctly ("Text Label" shown in place of the image) but dimensions are shown correctly and pressing create will open the dialog ("as web", "as on monitor) and the image does finally load correctly in Krita. (Note I tested and this behaviour is reproducible with the 2 mediafire links posted above as well).

This bug is very confusing for me to describe. I hope this helps.
Comment 1 vanyossi 2020-09-19 22:17:53 UTC 
This does not seem to be a problem of Krita, but of some other Qt component/software.

macOS and Windows laod the file instantly following the steps in the bugreport
Comment 2 Ahab Greybeard 2020-09-20 10:04:09 UTC 
I can reproduce the observations of the OP when using the 4.3.0 appimage  on Debian 10 with the MATE desktop.
The behaviour is varied and irregular, as had been noted. It mostly does not work.
Setting to CONFIRMED for this reason.

In all cases where krita has difficulty pasting correctly from the clipboard (if at all), GIMP and Libre Office paste image data correctly.

The problem happens if the image is in a browser tab or in an image viewer applcation (Eye of MATE Image Viewer).

The problem is associated with the image size and also if the image is photographic.
Example: The photo in Steps To Reproduce-2. is 2160 x 3840 pixels. If I create a 'hand painted' image in GIMP or krita of that size and then Export it to .jpg or .png, I have no problem if I open it in an image viewer or in a browser tab, then Copy and do a paste into krita either as a new image  or a new layer.

If I use one of my own personal photographs of a comparable size, sometimes it works ok, sometimes it doesn't. Mostly it doesn't.
If I manually create a 3000 x 2000 .jpg image, it mostly doesn't work.
Smaller images around 1000 x 1000 do not show problems.

For the linked photographic image in Steps To Reproduce-2, if I open it in the Palemoon browser and do Copy on the tab image, Palemoon crashes when I open krita. If krita was already open and running then Palemoon crashes immediately when I do the Copy on the image. Other browsers do not have this particular problem.
Comment 3 NiO 2021-05-21 02:52:40 UTC 
I've had this problem for a long time. I cannot usually paste large images (2000x2000 or larger).  

Occasionally it will paste successfully if I make several attempts.  The larger image, the less likely it is that it will paste.  Sometimes I attempt to paste 50+ times and it eventually works.

Here is a screen recording. 
https://files.catbox.moe/oj0qo7.mp4

Another person posted about it here:
https://forum.kde.org/viewtopic.php?f=139&t=156321

I am on EndeavourOS with Budgie Desktop. 
Krita 4.4.3
Qt 5.15.2
Comment 4 Halla Rempt 2022-09-19 13:00:08 UTC 
I fixed this for 5.1.

*** This bug has been marked as a duplicate of bug 443183 ***