@rumblesan @celesteh That'll be this thing https://www.hellocatfood.com/potentially-harmful/ (10 years old in two days!)

The software the broadcasters were using is closed source and analyses already rendered videos.

For something to work on a live feed there'd have to be a frame delay for it to analyse x incoming frames and then do _something_ to them, which isn't ideal for precise timing of visuals.

I think onus needs to be on the person making the visuals. In hydra there's a function to interpolate between values and the speed of this can be controlled. But it can't protect against flashes due to feedback loops.

@hellocatfood @rumblesan

The BBC uses some software for this which is incredibly expensive.

However, there exists a public formula for calculating contrast, normally used to check if a text and background are distant enough. That formula can probably be used to check contrast differences between adjacent frames.

I think that the delay can be mitigated by comparing to already output frames rather than looking ahead. So for time t (for every pixel?)
a = contrast(t, t-1);
If a <= y, then output t and save it to t-1.

Else t = t + ((t - 1) / a), then output t and save it to t-1

I think this would create a running average and do fading based on contrast, with fairly minimal delay, depending on frame rate.

Unfortunately, I don't know how to test it without access to the broadcast software because it's not like I can ask an epileptic person to rate the results....

A white square bouncing around a black screen is safe and doesn't need a fade trail, so this isn't really right, but its computationally cheap and would probably solve the problem. But if it doesn't we've wandered into a liability dilemma which is why nobody is going to release a floss version of this, nor make it available via a free API. Its expensive because mistakes are incredibly costly.