SUMMARY Create from Clipboard is a bit buggy in Krita 5. I've tested it in both beta1 and pre-alpha and got the same results. STEPS TO REPRODUCE 1. Right click an image from a browser 2. Select copy image 3. Click New File in Krita 4. Click Create from Clipboard OBSERVED RESULT I've gotten a few different results: a. Krita crashes b. Krita doesn't detect the new image and image dimensions from the clipboard c. Krita creates an image but only gets the correct dimensions with a white background layer, the image from the clipboard has to be pasted manually. d. Krita doesn't show the preview of the image from the clipboard in the Create New Document docker EXPECTED RESULT Krita shows a preview of the image from the clipboard, and clicking Create would automatically put the image from the clipboard as the background layer in the new document as it has done in Krita 4 SOFTWARE/OS VERSIONS Krita Version: 5.1.0-prealpha (git ab9b478) Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.11 Version (loaded): 5.12.11 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.19042 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (NVIDIA GeForce RTX 2060 Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true supportsBufferMapping: true supportsBufferInvalidation: false QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: true useBufferInvalidation (config option): false Hardware Information GPU Acceleration: auto Memory: 16332 Mb Number of Cores: 12 Swap Location: C:/Users/Rexel Bartolome/AppData/Local/Temp Current Settings Current Swap Location: C:/Users/Rexel Bartolome/AppData/Local/Temp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Disable Vector Optimizations: false Disable AVX Optimizations: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: true Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 2 Screen: 0 Name: \\.\DISPLAY1 Depth: 32 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: Model: Refresh Rate: 60 Screen: 1 Name: \\.\DISPLAY2 Depth: 32 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: Model: Refresh Rate: 60
Which browser are you using? There is a known bug in Chrome that puts images on the clipboard in a broken way...
(In reply to Halla Rempt from comment #1) > Which browser are you using? There is a known bug in Chrome that puts images > on the clipboard in a broken way... I'm using Firefox, and actually now that I've tested it, everything works fine when I copy images from Chrome but not Firefox :( I'm also using the portable zip versions of Krita 5 as I want to keep Krita 4 as my main workhorse while I test things out. I've tested it again on Krita 4 and copying from both Firefox and Chrome works fine.
I can also reproduce this with firefox _and_ chromeium on Linux.
I don't think this is browser-related as I've come across this issue with images copied from Krita itself. 1. Create an A5 600 DPI document with layers. 2. On Paint Layer 1, create a max setting Random Noise filter mask. 3. Flatten the image and cut with Ctrl + X. 4. Check Create from Clipboard, it should be read properly at this moment. 4. Restart Krita. 5. Check Create from Clipboard, it's no longer read properly. Sometimes you'll get an image with wrong dimensions or the image won't be read at all.
Git commit afb8e54832f8ffd59d0272183ecc537a0aca06a3 by Dmitry Kazakov. Committed on 05/10/2021 at 05:24. Pushed by dkazakov into branch 'master'. Fix assert when creating an image from Krita's internal clipboard When we copy local nodes, we should reinitialize both image and shape controller links. This patch fixes the former link, but keeps the second one unset. It should fix a crash when creating an image from the clipboard. M +7 -1 libs/ui/kis_mimedata.cpp https://invent.kde.org/graphics/krita/commit/afb8e54832f8ffd59d0272183ecc537a0aca06a3
The Oct 07 5.1.0-prealpha (git f2ad3000) appimage on Debian 10 MATE still has a strange problem. When first started, an image copied using the 'Eye of MATE' image viewer will cause a crash if I use Edit -> Paste into New Image. An image copied with the 'gThumb' image viewer will have no problems after usaing Edit -> Paste into New Image. After that, I can use an image copied with 'Eye of MATE' with Edit -> Paste into New Image and krita will then give me the list of options of how to paste it. Choosing to paste into a new document gives no problems. When it crashes, the terminal says "Segmentation fault". There is no relevant log entry.
I can confirm the crash :(
Git commit 8f6c508e889c694876d806750489d5c6e00b1fb0 by Dmitry Kazakov. Committed on 12/10/2021 at 08:42. Pushed by dkazakov into branch 'master'. Fix crash when creating a new image with URL present in the clipboard Basically, KisClipboard::clip() should not ask anything related to multiple URLs in the clipboard. Its responsibility to load only one image from the clipboard (the first URL if there are multiple). Parsing of multiple URLs is the responsibility of a higher level code. M +9 -2 libs/ui/actions/KisPasteActionFactories.cpp M +2 -7 libs/ui/kis_clipboard.cc M +49 -0 libs/ui/utils/KisClipboardUtil.cpp M +3 -0 libs/ui/utils/KisClipboardUtil.h https://invent.kde.org/graphics/krita/commit/8f6c508e889c694876d806750489d5c6e00b1fb0
The bug seems to be fixed now. I have tested the following cases: 1) "Copy Buffer" from nomacs works 2) "Copy" (file url) from nomacs works 3) "Copy Image" works on both Firefox and Chromium 4) "Copy Link" doesn't work, neither on Firefox nor on Chromium, because they save the link as text/plain. For every case I tried the following: a) Create new document from clipboard b) Ctrl+V the clip into existing document If you still have issues, please reopen the bug :)
Git commit df528d74058bc976a103d4f10e2a53d960a054c2 by Dmitry Kazakov. Committed on 13/10/2021 at 08:18. Pushed by dkazakov into branch 'krita/5.0'. Fix crash when creating a new image with URL present in the clipboard Basically, KisClipboard::clip() should not ask anything related to multiple URLs in the clipboard. Its responsibility to load only one image from the clipboard (the first URL if there are multiple). Parsing of multiple URLs is the responsibility of a higher level code. M +10 -2 libs/ui/actions/KisPasteActionFactories.cpp M +2 -7 libs/ui/kis_clipboard.cc M +49 -0 libs/ui/utils/KisClipboardUtil.cpp M +3 -0 libs/ui/utils/KisClipboardUtil.h https://invent.kde.org/graphics/krita/commit/df528d74058bc976a103d4f10e2a53d960a054c2
*** Bug 443902 has been marked as a duplicate of this bug. ***
Git commit 510842271ecd1b6f56163636235d5642ba7b16e2 by Dmitry Kazakov. Committed on 17/11/2021 at 13:47. Pushed by dkazakov into branch 'krita/5.0'. Fix assert when creating an image from Krita's internal clipboard When we copy local nodes, we should reinitialize both image and shape controller links. This patch fixes the former link, but keeps the second one unset. It should fix a crash when creating an image from the clipboard. M +7 -1 libs/ui/kis_mimedata.cpp https://invent.kde.org/graphics/krita/commit/510842271ecd1b6f56163636235d5642ba7b16e2
Git commit 30f7b1c9e966dca97f83f24da077df2789168aa8 by L. E. Segovia. Committed on 27/11/2021 at 00:43. Pushed by lsegovia into branch 'krita/5.0'. Fix position inconsistency in Paste at Cursor URL-backed images are handled by KisClipboardUtil::clipboardHasUrlsAction, which sidesteps all positioning logic. Yet, KisClipboard::instance()->clip also handles URL-backed images via KisClipboardUtil::fetchImageByURL. Conversely, clipboard bitmaps are pasted into a paint device which is then recentered. This commit fixes the dissonance by dropping the specialization, and ensuring that all clip() paths are centered. Related: bug 446120 M +0 -6 libs/ui/actions/KisPasteActionFactories.cpp M +7 -5 libs/ui/kis_clipboard.cc https://invent.kde.org/graphics/krita/commit/30f7b1c9e966dca97f83f24da077df2789168aa8
Git commit 573a7622a2fbddef8379c2b84fe6eadfd24a46e6 by L. E. Segovia. Committed on 27/11/2021 at 13:25. Pushed by lsegovia into branch 'master'. Fix position inconsistency in Paste at Cursor URL-backed images are handled by KisClipboardUtil::clipboardHasUrlsAction, which sidesteps all positioning logic. Yet, KisClipboard::instance()->clip also handles URL-backed images via KisClipboardUtil::fetchImageByURL. Conversely, clipboard bitmaps are pasted into a paint device which is then recentered. This commit fixes the dissonance by dropping the specialization, and ensuring that all clip() paths are centered. Related: bug 446120 (cherry picked from commit 30f7b1c9e966dca97f83f24da077df2789168aa8) M +0 -6 libs/ui/actions/KisPasteActionFactories.cpp M +7 -5 libs/ui/kis_clipboard.cc https://invent.kde.org/graphics/krita/commit/573a7622a2fbddef8379c2b84fe6eadfd24a46e6