Curi0 wrote:I recorded the video using a smartphone at 120fps and slowed it down to x0.125.
I know, but the video is useless -- because it won't allow me to correctly scientifically analyze the video.
You need finer granularity for strobe-backlight analysis.
If there is no way to get 1000 frames in 1 second (1000 frames per second) high speed camera, then it won't work well enough for strobe-backlight analysis. The frame length must be equal to strobe length or less, so that some frames in between flashes are completely black in between fully-illuminated frames. 120fps won't allow you to do that. You need a camera that takes more pictures faster so you can have completely black video frames in between strobe backlight flashes. It's not possible to analyze your video, I'm sorry -- your video is useless for scientific analysis. If you can borrow some camera capable of at least 1000fps (or even ~480fps minimum). Slow-motion speed is not important. Number of frames per second
is important for high-speed-video analysis of strobe backlights.
That said.... let's do a "spot check":
You could also test using the finger-wave test on white background. Does your backlight look like it is flickering successfully?
Another alternative is to use photograph (while pursuiting the camera sideways) instead of video camera. You can do it with any smartphone. A pursuit camera is simply a moving camera (taking a photograph, not video).
You can practice pursuit camera via
http://www.testufo.com/ghosting -- wave your camera sideways while taking a photograph. The ladder track should show up in the photo. There are instructions at
http://www.blurbusters.com/motion-tests/pursuit-camera but you can also hand-wave the camera for makeshift analysis. Once you've practiced successfully, do the hand-wave at
http://www.testufo.com/crosstalk
Take a pursuit photo without strobing, then another pursuit photograph with strobing -- and you can post to compare the before/after.
That doesn't guarantee timing-precision nor latency-jitter precision.
Curi0 wrote:Still even with the crosstalk a strobed backlight should have advantages. In games my monitor doesn't have ghosting but I think the motion blur must be hiding it.
Many games have software-based motion blur turned on.
Curi0 wrote:Should I flash the backlight on during the long VBI
Yes, during long VBI, not HBI.
You made a mistake with your 60Hz ToastyX -- you're using a large horizontal interval instead of a large vertical interval.
Curi0 wrote:or have a short as possible VBI and flash the backlight just before the next frame (probably less input lags with this method)
That's nonsense:
Anytime a monitor is outside a VBI, it is actively changing pixels on the screen.
Anytime it is actively changing pixels on screen, it's outside VBI.
A monitor refreshes pixels in a very rapid calendar-style fashion, left-to-right, top-to-bottom. Pretend your 1600x900 screen is like a massively big calendar of 900 weeks (vertically) of 1600 days-long (horizontally) each. If you had a one-million-frame-per-second high speed camera, you would actually see the pixels refresh in a calendar-style fashion (scanned sorta like a CRT). A refresh cycle is like a calendar month. Horizontal blanking intervals is like the gap between Saturday and Sunday (like adding a 100-hour pause between Saturday and Sunday) -- like pausing time between weeks.
Vertical blanking intervals is like the gap between months (adding several weeks of pausing between months) -- like pausing time between months..
Liquid crystals are moving molecules. Molecules have momentum. An LCD pixel takes time because it takes time for the liquid crystals to rotate (blocking or unblocking polarized light). That's why after a pixel is refreshed, the pixels still have momentum (it's coasting "Grey to Grey" from one pixel value to the next. A pixel may be white, and the next refresh cycle wants the pixel to become grey. When the refresh cycle hits that pixel, there's a very brief rapid voltage pulse (nanoseconds) to that pixel. While the monitor is refreshing subsequent pixels (subsequent pixels in the calendar-style "scanning" of the pixel matrix), the previous pixels are in a GtG momentum -- the liquid crystal molecules still taking 1ms or 2ms to rotate pretty close to their new positions. Basically a pixel "fades" from one color to the next. The calendar style scanning is very rapid -- over 100 million pixels ("calendar day" matrix equivalent) per second, called the "dot clock" -- 1 dot clock is the refreshing of 1 pixel, and the next dotclock cycle is the refreshing of the next pixel (immediately to the right of it). Once the pixel refreshing reaches the end of a row of pixels, it begins immediately pausing the amount of horizontal blanking interval, before beginning the next row of pixels. Once the bottom edge of screen is reached in a refresh cycle, it begins pausing the amount of vertical blanking interval before the next refresh cycle.
The reason why you want to pause after a refresh cycle is to allow the bottom edge of the screen (most recently refreshed pixels) to finish as much of their "GtG transition" momentum as possible (remember, LCD pixels are essentially molecules being rotated into a new position to change color -- they are behaving as shutters to partially block/unblock polarized light (in combination with polarized sheets & color filters) to generate all that colorfulness. An LCD monitor is still exactly like a 1980s LCD wristwatch -- it's essentially black and white pixels that's been turned to do greyscales, then subpixelled (into red, green, blue) to be combined to give you the full color pixels. So the exact same technology, in an old wristwatch, is being used to create all that beautifulness on a colorful LCD screen! All that molecules in motion.
(It's actually much more complicated than that, but I'm trying to explain the process of how it all works, in just a forum post)
Anyway, back on topic:
Trying to flash the strobe backlight while the pixels are in the middle of their transitions, creates more multi-image effects (called strobe crosstalk). So if your goal is to find the "point of minimum strobe crosstalk", you need to flash the LCD pixels BETWEEN refresh cycles instead.
Whenever a monitor is in VBI, it means the monitor is not actively refreshing LCD pixels. The longer the VBI is, the more completely finished the image on the LCD panel is (thanks to the momentum of the LCD pixels finishing, thanks to the longer VBI pause). The more clear the LCD screen image is (in total darkness) before flashing the backlight to allow the refresh cycle to be seen by human eyes.
So.... The bottom line is you want to flash the backlight between physical refresh cycles.
Due to the GtG lag, you do want to adjust the phasing of a strobe backlight flash slightly later -- basically roughly 1/2 a GtG transition forward in phasing. If you mathematically calculate your VBI is exatly 3ms long (it will vary depending on CRU numbers) then normally an engineer might think you'd flash for 1ms in the center (dark for 1ms, on for 1ms, dark again for 1ms, for a 3ms VBI). But that's not ideal, because of the GtG lag. If your GtG is 1ms, then you want to add half a GtG -- approximately +0.5ms offsetting. So a 3ms VBI might be: dark for 1.5ms, flash for 1ms, dark for 0.5ms.
Now, not everybody has the luxury of such a long VBI. You might only have a 2ms VBI and you want to flash for 2ms. So normally you'd think you want to turn on the backlight for the entire VBI. But because of the GtG momentum lag (if you have 1ms GtG) then you'd want to turn ON +0.5ms after beginning of VBI (the time it finished refreshing the last pixel of the previous refresh cycle) and then turn OFF +0.5ms after end of VBI (the time it begun to refresh the first pixel of the next refresh cycle).
Remember:
Instant of beginning of VBI: The moment right after finishing refreshing the pixel of last refresh cycle.
Instant of end of VBI: The moment the first pixel of the new refresh cycle is begun to be updated.
The best video camera to analyze a strobe backlight is called a "Phantom Flex" high speed camera or similar. However, I will settle for a 1000fps or 480fps high speed camera (some of these can be purchased for ~$200 off eBay).
Anyway:
Bottom line:
Shorter VBI is always worse crosstalk. It's law-of-physics like the speed of light.
The bigger the VBI, the more time the screen is waiting between refresh cycles instead of trying to "fade a pixel from one color to the next" (LCD Grey-To-Grey pixel transitions). This looks like a hazy vertical screen wipe in high-speed-video (480fps+ and 1000fps+).
The higher speed the video, the easier it is to see the LCD GtG in action. 1ms GtG on a 1/120sec (8.3ms) refresh cycle shows up as a "GtG Zone" approximately 1/8th screen height. But this only works if you have a high speed camera fast enough to capture the 1ms GtG (1000fps = 1ms per video frame). Or if you have a 1ms strobe length or 2ms strobe length. That's why 120fps is 100% useless for high-speed-video analysis of LCD GtG / strobe backlights. You really need a faster camera that can capture 1ms-granularity frames, one full thousand photographs per second (1000 frame per second) video camera, to capture all the 1ms timeslots, for proper analysis. Regardless, for high speed analysis, true video frames need to be a tiny fraction of a refresh cycle, no matter how fast or slow GtG is, but having a camera with frames far briefer than GtG aids in analysis greatly.
Nontheless, a high speed video camera is optional -- it only makes it easier to give you technical support for strobe backlight hacking. It just means it'll be much harder to help you remotely (without high speed video footage) unless you can teach yourself how to do a static photograph with a camera-in-motion (panning camera in sync with motion, while taking a photograph), as an alternative method of strobe crosstalk analysis.
Nonteheless, let's work on your ToastyX numbers.
I'll follow up with new ToastyX calculations for you. Keep tuned.