3

I want to make a basic video oscillator for the web. What I want to do is basically illustrated in a tutorial for Lumen: essentially, I want to define an oscillator to turn on and off a color signal at a given frequency. This is simple to do for a frequency below 60hz, but anything higher does not seem to get the effect that the program is showing.

It seems likely to me that the tutorial is far more simplified than what is going on behind the scenes, and since I don't have background in graphics programming I don't really have the tools to even know what I need to know. I'd like to understand what is going on and if it is possible to produce such things for the web

stackptr
  • 31
  • 2

1 Answers1

3

Yeah, that makes sense. Most flat panel monitors on the market have a 60Hz refresh rate! So you are not going to be able to flicker faster than 60Hz due to technical limitation.

Were you to do this with a electron sweeping oscilloscope, or a LED lamp connected to a PWM source fast enough then no problem (you can find this in arduino samples). It would work.

You can also emulate the effect by rendering multiple frames and then blending them. But you should take careto do correct kind of blending as the monitor output is not nesseserily linear!

joojaa
  • 8,437
  • 1
  • 24
  • 47
  • The Lumen application posted above suggests it can emulate >60hz frequencies by using either horizontal clock or pixel clock simulation. – PaulHK May 22 '17 at 06:53
  • @PaulHK yes but then you need to average frames. Most systems have vertical sync on by default. I mean i can sort of do this on my monitor since i have sync turned off but you couldn't depend on a web application to do this since it wouldnt work for 99% of users, and you have no control over the setting. – joojaa May 22 '17 at 06:59
  • Could you not simulate the time difference from the top-left corner ? This is (roughly) how video game emulators handle raster effects for instance. For example, the middle scanline of the frame would be roughly +8ms from the top of the frame, assuming a 16.6ms frame. – PaulHK May 22 '17 at 07:03
  • @PaulHK Not on the platform you use in a browser, the hardware does multi buffering and you can not escape the sync even if you wanted to, as far as i understand. – joojaa May 22 '17 at 07:04
  • I guess the core of my question is what sort of calculations are being performed in order to emulate a video oscillation of >60hz? Since both Lumen and my browser are running on the same display with the same refresh rate, albeit one is a native app which might mean that it is doing things that are limited in the browser... – stackptr May 22 '17 at 17:57
  • @Corey well the local program has more access to the system. In any case your question does not really specify that your asking about teh emulation. Your just asking why you have problems below 60Hz. But the real answer is to actually calculate the color as it would be. But its just horribly complicated to get it right. multi sample or integrate the result of your data end run it in color correct environment that should do the trick. Only a browser can not know the colorspace. – joojaa May 22 '17 at 18:01
  • The Lumen application is showing results for one frame rather than integrating all possible phases, so we should expect some kind of rolling effect for each frame. Check the red gifs in the link under the 'Frequency ranges' heading. – PaulHK May 23 '17 at 04:05