https://bugs.kde.org/show_bug.cgi?id=525449
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |CONFIRMED Ever confirmed|0 |1 CC| |[email protected] --- Comment #6 from [email protected] --- Additional confirmation: Incorrect MIME registration causes Spectacle to save BMP data instead of PNG — workaround verified I encountered a similar issue on Fedora 44 with KDE Plasma, where Spectacle saved screenshots with a .png extension, but the actual image data was encoded as BMP. I was able to identify a conflicting MIME registration introduced by a Chrome-managed application and successfully resolve the issue without modifying Spectacle. 1. ORIGINAL SYMPTOMS ==================== - Screenshots were saved with the expected .png filename extension. - The actual image format was BMP, as identified by MediaInfo and the BM file signature. - Selecting PNG in Spectacle did not produce a PNG-encoded file. - The issue occurred repeatedly rather than as an isolated failure. 2. MIME DATABASE INVESTIGATION ============================== I inspected the MIME glob definitions using: grep -hE ':(image/png|image/jpeg|image/bmp|image/\*):' \ ~/.local/share/mime/globs2 \ /usr/share/mime/globs2 2>/dev/null The output included the following conflicting definitions: 50:image/*:*.png 50:image/png:*.png 50:image/*:*.jpg 50:image/jpeg:*.jpg 50:image/*:*.bmp 50:image/bmp:*.bmp All conflicting entries had the same weight (50). Additional generic image/* associations were also present for JPEG, TIFF, WebP and GIF extensions. 3. IDENTIFYING THE SOURCE ========================= I searched the user-specific MIME package definitions: grep -Rl 'image/\*' ~/.local/share/mime/packages/ \ 2>/dev/null This identified a single file: ~/.local/share/mime/packages/chrome-<application-id>-Profile_<number>.xml The filename indicates a MIME definition registered by a Chrome-managed application associated with a particular browser profile. 4. WORKAROUND PROCEDURE ======================= I disabled the conflicting XML definition by renaming it, preserving the original file as a backup: cd ~/.local/share/mime/packages/ mv chrome-<application-id>-Profile_<number>.xml \ chrome-<application-id>-Profile_<number>.xml.bak I then regenerated the user-specific MIME database: update-mime-database ~/.local/share/mime No system-wide MIME definitions or Spectacle binaries were modified. 5. VERIFICATION AFTER THE WORKAROUND ==================================== Repeating the original MIME glob inspection showed that the generic image/* associations had disappeared. The remaining relevant associations included: 50:image/png:*.png 50:image/jpeg:*.jpg 50:image/bmp:*.bmp I then created a new screenshot using Spectacle and saved it as PNG. MediaInfo confirmed: General Format : PNG Format/Info : Portable Network Graphic Image Format : PNG Compression : Deflate Color space : RGBA Bit depth : 8 bits Compression mode : Lossless RESULT: The workaround was successful. The MIME conflict was removed, and Spectacle resumed producing correctly encoded PNG files. Only PNG output was explicitly verified after applying the workaround. 6. TECHNICAL INTERPRETATION =========================== This strongly suggests that the incorrect output format was related to conflicting MIME registrations, rather than a failure of the PNG encoder itself. A possible failure mechanism is that Spectacle obtains its output image format through MIME type resolution, which can return an unexpected result when third-party applications register ambiguous MIME definitions such as image/*. The observations are consistent with the MIME resolution problem described in this bug report. However, the exact internal code path responsible for selecting BMP has not been independently traced or confirmed. 7. SUGGESTED IMPROVEMENT ======================== Spectacle should ideally determine the intended output encoding from the explicitly selected format or requested output extension, rather than depending exclusively on MIME database resolution. In particular, it may be useful to: - Resolve the requested output format explicitly before initializing QImageWriter. - Validate the resolved format against supported image encoders. - Avoid silently selecting another image format when MIME resolution produces an ambiguous or unsupported result. - Add a regression test involving conflicting image/* registrations for common image extensions. The workaround demonstrates that correcting the user-specific MIME database restores normal operation. Nevertheless, third-party MIME registrations should not cause Spectacle to silently generate image data in a format different from the one requested by the user. 8. WORKAROUND LIMITATIONS ========================= The renamed XML file may be recreated when the associated Chrome application is updated or its desktop integration is refreshed. Therefore, this is a successful local workaround, but not necessarily a permanent solution. 9. ENVIRONMENT AND STATUS ========================= Operating system: Fedora 44 Desktop environment: KDE Plasma Application: KDE Spectacle The exact Spectacle and Qt versions were not recorded during this test. Status: Workaround verified; root cause strongly suspected but not proven by code-level tracing. -- You are receiving this mail because: You are watching all bug changes.
