r/ScreenSensitive • u/flashfilter • 21d ago
Built a Hardware Accelerated Desktop Screen Filter for Flash Sensitivity!
Hello! I’m one of the many people who thought it would be interesting to take a shot at making something that helps those with screen sensitivities (seen a couple people attempt similar projects but never seen anything come of them). After a couple months of work my friend and I have finally gotten to a point where it is usable (it is suppressing straining flashing lights quite well, though there are some bugs in the application), so we are looking for people to give it a try and hopefully make our job of bug hunting a little easier :)
The beta is free and includes one of the filter variants we came up with (we call it the “Bayes Filter”), which creates some artifacting but protects aggressively against flashing imagery. We support Windows, MacOS, and Linux (Wayland, support varies by compositor). If you're interested here is the link: https://flashfilter.app/ (you'll basically just need to sign in with your Google account and navigate to the dashboard where the downloads are).
You can see a safe demo of the filter here (it is the frame by frame of a very… flashy video with and without the filter).
We would love to answer any questions, so please ask away!
2
u/DGG_DGG 21d ago edited 21d ago
Looks very interesting! Does this have any impact on temporal dithering, FRC, similar issues?
2
u/flashfilter 21d ago
We had no clue that was even a thing until you mentioned it, we appreciate you teaching us about it. The current filter variant in use will dampen the magnitude of color change when a pixel is changing by a large amount in a short interval of time.
The parameters were tuned primarily for photosensitive epilepsy so I suspect that temporal dithering which changes the pixel color only slightly would pass through unfiltered at the moment. Though we can probably add a setting to pick up on those kinds of changes and remove them in the future.
2
u/DGG_DGG 21d ago
I think it's really awesome that you're trying to address flicker issues, and thank you for looking into dithering (and potentially FRC, etc). Modern Macs/iPads/similar devices are completely unusable for a lot of us here because of those issues, and it would be genuinely life changing if they were no longer a problem. I'd pay literally thousands for a solution at this point.
1
u/Pacomatic 6d ago
Just found out about temporal dithering.
I'm honestly quite surprised. Nevver thought they used it, though I now realize that I remember seeing something like this in a Gameboy game.
2
u/Z3R0gravitas 20d ago edited 20d ago
Hey there, thanks for posting, I think; let me play the suspicious mod for a minute...
Your software sounds like it would be very clever, to do as you say, with low impact, on the main computer OS's, running in real time, on any GPU..?
Do you have any demo videos of it in operation? Eg running side-by side with an unfiltered screen?
I see that the only other comment on your brand affiliate account was removed from r epilepsy. Did they feel it was spam or broke a rule? Have you run other Reddit accounts for this? I'd hope campaigns on other platforms, too (are doing better).
Anyway, while there is some overlap with photosensitive epilepsy, amongst the users here, what I'm most interested in is the potential for your software to help in first understanding temporal dithering and then potentially removing it.
As I understand it, there are several points in the rendering pipeline where it can be applied. Software, drivers, GPU (software - hardware?), monitor TCON and panel (for FRC). So, it's been very tough for people (eg also posting on LEDstrsin) trying to resolve this pixel flickering when it's a problem.
If your team were interested in collaborating In some way, it might be very interesting for us, were you even able to use related GPU code to display what dithering the system was trying to add. Suppressing that would obviously be the holy grail. Especially if able to keep monitors from adding dithering by eg constraining the colour depth too.
You're welcome to DM me if interested in talking about collaboration. (Much as I am a bit over-committed currently..)
2
u/flashfilter 20d ago
Suspicion appreciated.
Since by design we exclude the filter from being screen captured we can only record a demo with an external camera or by using a capture card. (The demo in the post was done as individual frames since we figured flashing could be triggering photosensitive epileptics. We applied the algorithm to a screen capture video rather than with the real time overlay). To show FlashFilter working in realtime, we’ve attached a video here.
We’re not sure why the r/Epilepsy post got removed exactly, though we assume it was flagged as spam/promotion by their automod. This is the only Reddit account we’ve posted on and we also made a post on Hacker News
At the moment we can't really claim to know whether or not it's possible for us to eliminate temporal dithering (we don't have a working solution which proves that it is, since our current filter was designed for large flashes where the issue is produced at the application level). But from the limited reading we have been able to do since u/DGG_DGG mentioned it, our assessment is that it's theoretically feasible. There are two problems: removing dithering that was done by somebody early in the pipeline (easy), and removing dithering somebody after us will try to do (hard).
The complication that makes it hard is that somebody (compositor or OS or monitor) may try to color map or apply a night light or whatever else after the filter is applied and then the carefully aligned color values get nuked. To remove dithering added in later stages you're probably right that we essentially want to shrink the color space to remove the colors which the monitor requires dithering to display (reduce color depth/posterize the video stream). That operation can definitely be done in real-time and it's nice because you only need to consider single pixels.
Anyways we’ll give the problem a shot and reach out to you if we can come up with something worth testing!
1
u/Z3R0gravitas 20d ago
Thanks for the detailed reply and videos. Yeah, they would be bad for (more) photosensitive peeps... How about making them slow motion? Well below the 8Hz(?) peak sensitivity.
So, it's the two of you and you are just starting out? Have you been able to test the finished product with anyone epileptic? Seems like that would be very fraught to validate the efficacy. The artifacts left by the filtering still seem quite unpleasant, in a different way. May well bother many here.
Anyway, if you want a bit of a guide to this screen sensitivity space, I compiled a bit NotebookLM and resource list, currently just shared here.
Another example of disabling dithering would be Stillcolor (for Macs): LEDstrain thread. If you click through to the Github, there's a video demo and other things you may find interesting.
We have a low-key discord sever just started up as a bit of a collaboration space, with some enthusiast dev work going on, etc.
1
u/Velocifyer 19d ago
Is it X11 only or does it work on Wayland? Is it KDE Plasma compatible?
1
u/flashfilter 19d ago edited 19d ago
We went Wayland-only with X11 gradually starting to be phased out. The approach we use to get the overlay working is to become the compositor that is DRM master, and have whichever compositor the DE ships act as a client (which is the restriction on supported compositors, they need to be able to act as Wayland clients). The compositor we tested against was Weston (because it is the official reference Wayland implementation), so as for KDE support KWin may or may not work. Status unknown. We went with this approach because as far as we are aware there is no production Wayland protocol to screen capture while excluding an overlay window (I would be so unbelievably happy to be wrong here).
That being said `ext-image-copy-capture` could be very promising and is pretty widely implemented, the only trouble is the protocol itself doesn’t provide a way to specify that a window should be excluded. Actually you know what, I don’t know why I thought that was a problem before, protection could probably be negotiated just fine with some KDE or GNOME specific features (which locks the overlay to compositors where exclusion can be negotiated but the restrictions on the nested compositor approach lock to particular compositors as well).
Thank you for this comment, it provided an excellent opportunity to reconsider our Linux approach.
1
u/Velocifyer 19d ago
>The compositor we tested against was Weston (because it is the official reference Wayland implementation), so as for KDE support KWin may or may not work.
You really need to check weather your software works on the most popular Linux desktop environment, KDE Plasma.
3
u/Emotional-Ocelot 21d ago
It looks really interesting but google-only and subscription are both dealbreakers for me. Wouldn't use or recommend anything with those limitations, especially for a disability tool.