makes sense, although i'd argue for --file - in that case. :p

i can't confirm the issue in gnome, but i can't select the same scaling (1.5) as in sway, of course on 1x and 2x this is not an issue.

Oh Oh, that's promising. I'll try to reproduce in GNOME with fractional scaling enabled, we'll see. It's difficult because from what I remember, I can't actually set a 1.5x fractional scaling, only round numbers, so that might be harder to reproduce...

i filed this as a bug against sway in debian, see https://bugs.debian.org/1093671

so for what it's worth, i can't reproduce in GNOME/Wayland... and by "can't reproduce", the images don't look blurry in geeqie in GNOME, they just look fine. i can't take a screenshot in GNOME with shotman, obviously, because we can't have nice things, although shotman could be a little more polite about it... ;)

anarcat@angela:~> shotman -c output --verbose info              (main)
thread 'main' panicked at src/main.rs:167:6:
called `Result::unwrap()` on an `Err` value: the requested global was not found in the registry
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
anarcat@angela:~[101]> RUST_BACKTRACE=1 shotman -c output --verbose info
thread 'main' panicked at src/main.rs:167:6:
called `Result::unwrap()` on an `Err` value: the requested global was not found in the registry

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
   7: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
   8: <unknown>
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

i guess that's an entirely different (and probably unfixable) issue, of course...

but still, it goes to show there might be some interop issue between GTK and sway here, in particular... i guess i'll need to report this on sway now.

thanks again for the help.

interestingly, i can catch the bug with a shotman screenshot! here's a normal shotman screenshot of itself (more or less), this shouldn't look fuzzy:

https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/Screenshot.from.2025-01-20.at.21_52_06.280461690.png

here's the same image, but rendered by geeqie, screenshotted again by shotman:

https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/Screenshot.from.2025-01-20.at.22_24_02.364998203.png

bonus points if notice the sizes of the images:

https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/

-rw-rw-r-- 1 anarcat anarcat 428,162 2025-01-20 21:52 Screenshot.from.2025-01-20.at.21_52_06.280461690.png
-rw-rw-r-- 1 anarcat anarcat 934,878 2025-01-20 22:24 /home/anarcat/snaps/Screenshot.from.2025-01-20.at.22_24_02.364998203.png

the screenshot of the screenshot, probably because of the aliasing/blurriness, makes the PNG compression struggle more, and the image is more than double the size!

amazing.

holy moly. you have now officially, fully, and completely blown my mind. i see the same thing: mpv renders things pixel-perfect, and (almost) all other image viewers i have tried (eog, geeqie, imv, pqiv so far) are fuzzy.

swaybg, on the other hand, is not fuzzy. qimgv is not fuzzy, but its interface is so weird that i can't actually figure out how to show the image in full screen. i'm similarly failing to display the screenshot in full size in swayimg, which is behaving similarly weirdly.

koko and gwenview seems to behave properly. so i'm tempted to lay the blame on GTK, as both of those are KDE/Qt apps, while all the weird ones are GTK (I think?)

an easy way to reproduce the issue is to take a screenshot with shotman -c output, then open it, full screen, in any image viewer. because you should be looking at almost exactly the same image, you will see the fuzziness added.

even digikam and darktable, disturbingly, doesn't seem to be able to display those pixels sharply, and those are supposed to be top-notch photography editors.

wtf. what are we supposed to do with this? all those viewers are screwed?

i am certainly reconsidering my image viewer choices at this point, ugh. i guess i should see if that happens in GNOME as well.

what a nightmare!

(thanks for tolerating my ranting here, clearly this is not your fault!)

i kind of like how shotman works, it's really nice! i'd like to hook into my setup, but for that i'd need to know where shotman saves its screenshot, which this would be useful for.

of course, the fix for me would be a --file option, but i'd understand if you wouldn't want that, see also https://todo.sr.ht/~whynothugo/shotman/35

what's the status on that branch?

i have found that basically no wayland screenshot tool properly captures pixel-perfect screenshots, at least under sway, which was surprising when coming from X11 because scaled displays are otherwise perfectly supported in Sway...

so i had high hopes when i saw that bug report, so i'm wondering what's up...

you can see a screenshot taken with grim in the undertime readme, i tested with shotman and the results are similar. this is with a 2x or 1.5x scaling, results are similarly blurry. it seems this was introduced in my x11 to sway switch here:

https://gitlab.com/anarcat/undertime/-/commit/b1b3d0474d4a07305a7c2adc7dd278454acc0e67

it's nice that shotman puts the files in my screenshot folder out of the box and that there's a way to override those defaults... but it doesn't look like there's a way to actually pick the actual file name, which seems to be autogenerated.

could it be possible to add an arbitrary --file argument, that bypasses the environment/defaults lookups entirely?

this would be essential to hook shotman into my current screenshot/pastebin framework (pubpaste)...

alternatively, i could parse the --verbose output, but that seems much clunkier... other screenshot tools (e.g. grim) provide such a functionaliy, which makes it easy to hook into...

could this be done here too?

thanks!