Bug 498240

Summary: Spectacle Creates "thresholds_new.pnm" file in home directory every time screenshot is taken.
Product: [Applications] Spectacle Reporter: 7p3jgw609
Component: GeneralAssignee: Noah Davis <noahadvs>
Status: RESOLVED UPSTREAM    
Severity: normal CC: 7p3jgw609, kde, me, qik00yt, shtetldik
Priority: NOR    
Version First Reported In: 24.12.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Example of the correct file created with the additional extra pnm file.

Description 7p3jgw609 2025-01-04 07:05:55 UTC
Created attachment 177093 [details]
Example of the correct file created with the additional extra pnm file.

SUMMARY
After an system update, any time spectacle creates a screenshot it creates this file called "thresholds_new.pnm" in my home directory. It correctly still produces the image I requested, whether it be to the clipboard or to a file, but now all of a sudden this file is created if its missing, or edited if its present. This happens regardless of the output file type, regardless of type of screenshot (rectangle, whole screen, etc). No settings in spectacle seem to stop it from occurring. I have attempted to downgrade the software to no avail oddly enough, so I'm completely lost as to why it's doing this after a system update. 

STEPS TO REPRODUCE
1. Take Screenshot (any type/setting)
2. Check home folder
3. 

OBSERVED RESULT


EXPECTED RESULT
Successfully creates screenshot but also a seemingly erroneous "thresholds_new.pnm" file. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 6.2.5-1
KDE Frameworks Version: 6.2.5-1
Qt Version: 6.8.1-1

ADDITIONAL INFORMATION
The only relevant log I could find is the following output from journalctl
"spectacle[63201]: kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 24.3.2-arch1.1 for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.12.8-zen1-1-zen) in use for device "/dev/dri/renderD128"
Comment 1 7p3jgw609 2025-01-04 07:09:11 UTC
FIXED report
###
SUMMARY
After an system update, any time spectacle creates a screenshot it creates this file called "thresholds_new.pnm" in my home directory. It correctly still produces the image I requested, whether it be to the clipboard or to a file, but now all of a sudden this file is created if its missing, or edited if its present. This happens regardless of the output file type, regardless of type of screenshot (rectangle, whole screen, etc). No settings in spectacle seem to stop it from occurring. I have attempted to downgrade the software to no avail oddly enough, so I'm completely lost as to why it's doing this after a system update. 

STEPS TO REPRODUCE
1. Take Screenshot (any type/setting)
2. Check home folder

OBSERVED RESULT
Successfully creates screenshot but also a seemingly erroneous "thresholds_new.pnm" file. 

EXPECTED RESULT
Successfully creates screenshot without any other files being created.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 6.2.5-1
KDE Frameworks Version: 6.2.5-1
Qt Version: 6.8.1-1

ADDITIONAL INFORMATION
The only relevant log I could find is the following output from journalctl
"spectacle[63201]: kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 24.3.2-arch1.1 for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.12.8-zen1-1-zen) in use for device "/dev/dri/renderD128"
Comment 2 Jet 2025-01-04 21:54:34 UTC
Id like to confirm this happening to me as well. So far only once after update.
Comment 3 Noah Davis 2025-01-04 21:57:38 UTC
This shouldn't be possible, unless it's actually a library used by Spectacle or a library used by a library that is causing the problem.
Comment 4 Jet 2025-01-04 22:00:39 UTC
Also might be relevant, I am using the same GPU as the OG reporter - RX 7900 XTX
Comment 5 7p3jgw609 2025-01-04 22:14:54 UTC
Some additional information, This is a *very* fresh install of Arch Linux and KDE. Installed a week ago, and updated 1 day ago to gain this issue. I had an EndeavorOS (Arch Distro) install with same hardware and KDE without this issue for years. 

I could add in the past the vaapi interactions with the XTX has always been, odd, loves to throw odd errors so it may be whatever library spectacle is using to hwaccel its screenshots. If there is a debug or -no_hwaccel flag or something of the nature, I would love to try it and see if it stops.
Comment 6 Tianshu Feng 2025-01-05 01:38:24 UTC
From what I can find this file appears to be created by the zxing-cpp library (reference to the code: https://github.com/zxing-cpp/zxing-cpp/blob/8f95431dfad9890c34680bff1b7f69989e69d9fa/core/src/HybridBinarizer.cpp#L282). A quick grep search also confirms this file name (thresholds_new.pnm) is contained in /usr/lib/libZXing.so.2.3.0 library file. This library is used for QR code and bar code processing.

FYI I'm also on latest Arch Linux, and both of my systems experience this issue.
Comment 7 Tianshu Feng 2025-01-05 02:01:50 UTC
A workaround seems to have been posted in Arch Linux:

https://gitlab.archlinux.org/archlinux/packaging/packages/zxing-cpp/-/commit/a64a508cc553e2141d21e2d6eb24458614b4fd06

Upgrading zxing-cpp to 2.3.0-2 should probably resolve this.
Comment 8 Jet 2025-01-05 02:50:08 UTC
(In reply to Tianshu Feng from comment #7)
> A workaround seems to have been posted in Arch Linux:
> 
> https://gitlab.archlinux.org/archlinux/packaging/packages/zxing-cpp/-/commit/
> a64a508cc553e2141d21e2d6eb24458614b4fd06
> 
> Upgrading zxing-cpp to 2.3.0-2 should probably resolve this.

Confirmed resolved for me
Comment 9 7p3jgw609 2025-01-05 08:33:18 UTC
(In reply to Tianshu Feng from comment #7)
> A workaround seems to have been posted in Arch Linux:
> 
> https://gitlab.archlinux.org/archlinux/packaging/packages/zxing-cpp/-/commit/
> a64a508cc553e2141d21e2d6eb24458614b4fd06
> 
> Upgrading zxing-cpp to 2.3.0-2 should probably resolve this.

Can also confirm this is indeed the fix.
Comment 10 Shmerl 2025-02-05 04:33:32 UTC
Filed a bug for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095196
Comment 11 Shmerl 2025-02-07 19:49:43 UTC
Also opened upstream bug to reverse that kind of sneaky behavior: https://github.com/zxing-cpp/zxing-cpp/issues/900
Comment 12 Shmerl 2025-02-07 21:35:04 UTC
For the reference, upstream fixed it but it's not released yet:

https://github.com/zxing-cpp/zxing-cpp/commit/82806f5f92173b8cb4e1e9bee13a2d07a33fb69f