SUMMARY Would like to see a drop down menu on the "copy to clipboard" button (similar to the arrow next to "save as") which allows you to choose the file format. In particular, there are times when I want to copy to clipboard as a JPG rather than the default PNG. SOFTWARE/OS VERSIONS Using KDE Plasma 5.21.4 on PopOS
What's your use case for this, out of curiosity?
(In reply to Nate Graham from comment #1) > What's your use case for this, out of curiosity? Thanks for taking a look! A common use case for me is trying to screenshot a segment of a photo with the rectangular clipper and then paste it into a message. The photo would be preferably represented in lossy format (e.g. jpg), not png.
Thanks, that use case makes sense. Let's narrow it down to being a menu item that would say "Copy to clipboard as JPEG" and it would only be visible when the default file format to save in was *not* set to JPEG.
Would it satisfy you if copy to clipboard always used the preferred image format or do you specifically want an option to copy as jpeg even when you have PNG as the preferred image format?
(In reply to Noah Davis from comment #4) > Would it satisfy you if copy to clipboard always used the preferred image > format or do you specifically want an option to copy as jpeg even when you > have PNG as the preferred image format? Thanks so much for following up, Noah. I am hoping for an option in the dropdown menu to export to the other format, so the user can choose at copy-time whether they want a lossy or lossless format. That way, the copy to clipboard option is highly usable for (for example) both photo and line art clipping, regardless of a user's application settings.
*** Bug 476714 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #3) > Thanks, that use case makes sense. > > Let's narrow it down to being a menu item that would say "Copy to clipboard > as JPEG" and it would only be visible when the default file format to save > in was *not* set to JPEG. I would like to add my own use case because I don't think this specifically would cover it. I usually save my screenshots in the JPEGXL format for file size reasons. However, when I copy an image saved in that format, the majority of applications (especially web sites in web browsers) would not be able to recognize / use it when I paste it. To get around this, right now I just have to save it as PNG, then click on the highlighted file to go to the new document (because spectacle doesn't automatically go to it - which I do think is normally a good thing but not for this use case), and then finally copy that so that the copied image is a PNG. It would be significantly easier if there was an option to "Copy as". But I think it would cover a lot more use cases and be much more flexible if the destination format wasn't hard coded to JPEG (or PNG) and instead users could choose the one they would prefer to copy to. I would much rather this setting wasn't the preferred image format though because then this feature would be useless for my use case (my preferred format is JPEGXL so that screenshots are saved in that format).
Actually, I want to clarify that I would still use it if "Copy as" was exclusively for copying as a JPEG, but it would not be ideal since I'd still want a lossy format to copy, just one that is more compatible (PNG). So I'd add that a drop down to choose between copying as JPG and copying as PNG would likely cover the majority of use cases (including mine) while still being simple enough, though I still think there would be a few edge cases where it wouldn't.
(In reply to Nate Graham from comment #3) Why? Regardless, that would be useless for me: I usually save as TIFF by default to ensure that metadata is collected (and because it lets me use Deflate compression retroactively) and want this feature so that I can export as PNG when uploading to Discourse instances with automatic conversion disabled. I don't think I've ever used JPEG.
*** Bug 485499 has been marked as a duplicate of this bug. ***
It is unfortunately not possible to reliably copy images to the clipboard in a specific format. You can copy in a specific format, but you will run into issues like https://bugs.kde.org/show_bug.cgi?id=485096. There are ways to work around that, but they're unreliable. Worst of all, when you close spectacle, the system will decompress the data. PNG is unaffected by the decompression, but lossy formats like JPEG and WEBP will become 2-8x larger than their compressed size. Usually, they become as large or significantly larger than PNGs would be, making it pointless to copy in those formats unless users always keep the Spectacle instance while they are pasting. I could allow pasting specific formats with that quirky behavior, but I don't think I should because it's too unreliable and will just frustrate people. PNG eliminates most of the data size issues with uncompressed image data. Perhaps Spectacle should always copy images as PNGs instead of uncompressed images or another format.
(In reply to Noah Davis from comment #11) Those are very good points, and I'd be glad to wait for this until those issues you mean are solved. If any are being tracked here, can they be listed as blockers? (Are those Qt bugs?)
(In reply to Roke Julian Lockhart Beedell from comment #12) > (In reply to Noah Davis from comment #11) > Those are very good points, and I'd be glad to wait for this until those > issues you mean are solved. If any are being tracked here, can they be > listed as blockers? (Are those Qt bugs?) The clipboard contents compatibility issue is arguably a Firefox/Chromium/WebKit/Electron issue. Maybe it's fixable in those projects, but it's odd that it has been effectively worked around in KDE and Qt code. Fundamentally, it means we can't assume apps will accept a given image format, regardless of whether the issues are fixed. I'm not exactly sure where the decompression issue comes from. I made a test project (https://invent.kde.org/ndavis/clipboardimageformatwidgets) and tried to find parts of qtbase that might be relevant. I know Qt adds a bunch of extra mimetypes to the clipboard data for compatibility. In qtbase/src/gui/kernel/qinternalmimedata.cpp there is a part where it will try to write a PNG, but that's only if there's no data for the given mimetype. I also checked Klipper and KSystemClipboard and tried patching those (https://invent.kde.org/plasma/plasma-workspace/-/commit/8cff887b146353fbe4f7681061624581775fa820 and https://invent.kde.org/frameworks/kguiaddons/-/commit/ae1535c6d893041e36c0cd0c1128b092f71aa62f). Unfortunately, there was still no way to reliably prevent decompression. Fundamentally, I don't know if the issues can be fixed and I don't know if the decompression issue is just a side effect of behavior that is necessary for compatibility with apps that don't support most writable image formats.
(In reply to Noah Davis from comment #13) Thank you. That's comprehensive.