[feature] low res pixel blur

[a-viv-a]

At the moment there is only a smooth blur—a lot of data can be retrieved from smooth blurs, like text and decent approximations of images. The default blur seems pretty heavy, so maybe this is unneeded, but I think it would be really helpful to have a pixel blur which can be applied as a distinct option from the existing smooth (Gaussian?) blur, for censoring names ect.

Spectacle is an example of a screenshot tool that I know has both blur types.

Thanks for an awesome tool!

[gabm]

I agree.. I am unsure about the interface

[RobertMueller2]

For the time being we could connect this to a modifier, e.g. Alt. Bonus points if there's a visible distinction between normal and alt mode while dragging.

In the long run, I think the toolbar buttons should get an indicator pointing out a secondary mode.

[pointydev]

Flameshot has a method of secure pseudo-pixelation that uses the pixels surrounding the selection as the basis for the colours inside it, completely discarding the contents within. You can see the results of what that looks like in the original PR: flameshot-org/flameshot#3765

[kikeijuu]

If UI is a holdup, would launch commands for changing the blur method be possible? ATM while the blur is good for focus (eg. blocking out irrelevant content), it is quite insecure. Most of the text and icons in this image can be sussed out, even as a Human. Is there anything users can do to help w/this? Great tool btw ^^

[RobertMueller2]

The holdup is the lack of an implementation at this time 😉 I do not think the UI question is blocking this.

[kikeijuu]

I'll try my hand at a PR between paperwork over the next few days then :D

[pointydev]

If you're trying a PR, could I recommend taking a look at the code I posted from Flameshot? It is highly effective but looks decent as well.

[kikeijuu]

I'm coming from flameshot actually, so that sort of implementation is ideal, at least for my usecase (sounds like a-viv's as well?). I'm about as good as a victorian chimney sweep at this but I'll do my best :>

[RobertMueller2]

Have fun and good luck if you want to try an implementation. Feel free to reach out via matrix chat or discussion or an early draft PR if you have any questions. Here are some remarks, and I don't mean to say we wouldn't merge it 😉

• How is this suggested approach supposed to behave when I select 100% of the area, i.e., when there's no "fringe" left? This may be tricky to do with flameshot, but it's definitely a possibility in Satty. Even if it makes no sense, it is a valid input. The algorithm is guarded against it, I just have no idea what the result would look like. I assume if this feels like a limitation, we can document it in readme or later on, documentation.
• Depending on how close the implementation is, we may have to add a credit note or even figure out how/if it can be re-licenced
• Now I am thinking that pixelation may be a different tool from blur, perhaps we want both a standard pixelation and the fringe pixelation as a pixelate tool, while leaving the blur tool where it is. Or we can leave that part for a followup change if anyone's bothered.
• finally, I would like to take the opportunity to point out for anyone coming to this issue in the meantime before we add this, that Satty right now can fill Rectangles and Ellipses, while perhaps not artistically equivalent to a pixelation approach, it does make the original info impossible to retrieve.

[kikeijuu]

Hiya! I've been using rectangles. but since their color can pop/take focus away, I would really like pixelate ^^

I was able to build without warnings/errors a pixelate mimicking the one flameshot uses. The only thing I ran into is my gtk theme no longer applying, but I think that's unrelated as I only edited blur.rs (maybe just a weird quirk with building here vs using the arch package?)

You can see how it looks here, side by side with the regular blur (went w/the alt binding) on various elements. Left on panes is blur, right on panes is pixelate.

This could be ready for a PR, but the licensing and design direction and such is something I have no experience with qwq My implementation as well was written largely with (sandboxed) ai, which I know only complicates things further.

I'm no fan of AI myself (I really, really don't know rust for this sry) so I totally understand if that disqualifies this as a PR to start with.

Still, I've made a fork here, and if it looks good (and different enough from the flameshot method, which I believe it is looking at the two and the results they produce, (this isn't quite secure psuedo-pixelation, its less secure than that and you can see it show some of the color below) but I really do not know licenses), I am ready and willing to make a PR :D

edit2: while I'm on hyprland myself, I got a few niri users to try and it's working great so I'm going to make that early draft pr ^^

[RobertMueller2]

I'm not going to start a philosophical discussion about LLM usage in this issue, so I'll keep this brief, but I'm happy to continue the discussion elsewhere, e.g. discussions section. Let's just say for practical reasons and supportability, somebody has to understand what the code does. The troubleshooting skills of LLMs, this may of course depend on model, eco systems and languages, are not on a level yet where we can just merge stuff and hope we can successfully throw any issues that arise at another LLM session.

So if the submitter does not understand the code, the reviewer/person who clicks the merge button has to.
But then that approach kinda violates 4 eyes principle. So while we're not going to (or intend to) turn back the wheels, and can't pretend it isn't there, we have to require that PR submitters vouch for the code they submitted, that includes a technical understanding of what it does. There's an open PR #351 about contribution guidelines that tries to clarify things.

[kikeijuu]

Totally get that! I really don't like using AI or dealing with the technical debt it introduces so that I understand. And sorry that I didn't see that contributions PR >.> Keeping something around locally is more than good enough for me until a human can properly address this issue. I'll probably keep the repo synced until then as a few other Satty users I'm friends with need the pixelate functionality, but I'll close the PR if it's not closed already ^^

Thanks again for maintaining Satty!

[RobertMueller2]

we can keep the PR open for reference purposes for now/until we have an implementation. I mean, if people want to use it as a patch for their own installation, if they build themselves anyway, that might be useful.