When saving screenshots, Spectacle does not correctly embed the DPI (dots per inch) value in the image metadata. As a result, when the image is opened on devices or displays with different DPI settings, the displayed physical size of the image is incorrect — for example, screenshots appear larger or smaller than intended. This issue affects workflows where the image's physical dimensions are important, such as documentation, printing, or high-DPI display consistency. Steps to reproduce: Take a screenshot using Spectacle. Save the image as PNG or JPEG. Inspect the image metadata using tools such as identify -verbose (ImageMagick) or exiftool. Expected behavior: Spectacle should store the correct DPI value (e.g., 96 DPI or the actual screen DPI) in the image metadata, so the image displays at the intended physical size across different devices and applications.
Can confirm this. Did a quick comparison: Windows 11 didn't save this information either when doing a fullscreen screenshot with Snipping Tool (Win+Shift+s). MacOS did correctly save it. For example exiftool '-*resolution*' Example-fullscreen-Screenshot-macos.png X Resolution : 144 Y Resolution : 144 Resolution Unit : inches I believe these are the pertinent values for the retina screen they were taken on. Can you give a more specific example of a workflow when this can become a problem for you? Personally, when including a screenshot in a document, for example including an image inline in an email in Thunderbird, I'm so used to it being included in the totally wrong dimensions, so I'm used to resizing every single screenshot by hand. ;)
(In reply to Lenzoid from comment #1) > Can confirm this. Did a quick comparison: Windows 11 didn't save this > information either when doing a fullscreen screenshot with Snipping Tool > (Win+Shift+s). MacOS did correctly save it. For example > > exiftool '-*resolution*' Example-fullscreen-Screenshot-macos.png > X Resolution : 144 > Y Resolution : 144 > Resolution Unit : inches > > I believe these are the pertinent values for the retina screen they were > taken on. Can you give a more specific example of a workflow when this can > become a problem for you? Personally, when including a screenshot in a > document, for example including an image inline in an email in Thunderbird, > I'm so used to it being included in the totally wrong dimensions, so I'm > used to resizing every single screenshot by hand. ;) Thanks for your reply! The reason it’s important to include the resolution (DPI) information in the image metadata is that different devices have different DPI values. For example, if I take a screenshot on a 24-inch 4K display (around 184 DPI) and then view the same image on a 24-inch 1080p display (around 92 DPI), the screenshot appears much larger on the lower-resolution screen. If the screenshot file contains the correct DPI metadata, image viewers and document editors can display it at the correct physical size, matching what was originally shown on the source display. Without this information, the viewer software has no way to know the actual intended print or display size, so it defaults to assuming 72 DPI or 96 DPI, which causes inconsistent visual scaling between devices. This becomes a real problem when sharing screenshots for UI design reviews, documentation, or printed materials, where maintaining accurate physical size or proportions is important.
None of KDE's image viewers will take the supposed DPI into account. They show a pixel as a pixel. We can store it, but I'm quite confident it won't solve the problem you're trying to fix. You can modify the DPI with imagemagick, please confirm if it would solve your use-case and how you tested it, then reopen.
Surely it depends on what software and hardware these images are viewed with. 人力脑机, it might help if you provided some examples how to view these screenshots in order to see the behavior you're describing. Most of us just use KDE software, which David pointed out does ignore it. I have a Macbook here but I'm only touching that with 10-foot poles.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.