flood's input lag measurements

[spacediver]

before I really try to understand all this, few things I'm unclear on:

in the video you posted, the scanlines are going horizontally. Why is that?

Also, can you remind me what the stimulus was? It went from black screen to full white (or something bright) to full black, right?

suppose that each pixel of the video corresponds to light collected over an entire millisecond (from looking at videos of my crt's scanning, it's a very good approximation).

This is where I have trouble following. your camera does 1000 fps at 224 x 64. I'm assuming the shutter rolls in the vertical direction (across 64 pixels). But this would mean a shutter period of 64 ms, which doesn't reconcile with 1000 fps.

Or did you mean something else?

[flood]

video is rotated

black to white is the screen response. the lighting of the green led corresponds to the initial stimulus.

there's overlap between the collection periods of each pixel

something like:
in frame 0
the top row of pixels collects from between t=0 and t=1ms
the second row collects from between t = 0.01 and t=1.01ms
third row collects from between t=0.02 and t=1.02ms
...
last row collects from between t=0.63 and t=1.63ms

in frame 1
the top row collects from between t=1 and t=2ms
...
last row collects from between t=1.63 and 2.63ms

[spacediver]

something like:
in frame 0
the top row of pixels collects from between t=0 and t=1ms
the second row collects from between t = 0.01 and t=1.01ms
third row collects from between t=0.02 and t=1.02ms
...
last row collects from between t=0.63 and t=1.63ms

Still confused. There are 64 rows of pixels right? And the camera is rolling scan, and at 1000 fps, the last row should be completed at 1 ms, right?

[Chief Blur Buster]

flood,

If I am reading correctly, you're mathematically compensating for the camera's rolling scan already, right?

All of the common Casio 1000fps cameras uses 1/250sec rolling scan. They narrow the video to a wide sliver (quarter-image-height) in order to allow 1/1000sec rolling shutter. Your 1000fps camera seems to be one of those or similar. You may need to mathematically "compensate for" the rolling scan of the high speed camera. The easiest way to compensate is to put a camera's scan perpendicular to the display's scan (90 degrees) so that some simple mathematics can theoretically get literally microsecond-accurate proportional timing. This seems to be what you are already doing. Right?

in the video you posted, the scanlines are going horizontally. Why is that?

That's the artifact caused by having perpendicular scans (e.g. scan direction of camera sensor rotated 90 degrees relative to scan direction of a display). You get a diagonal artifact with this. Perfect diagonals means both scans are running at the same speed. The angle of the diagonal artifact (e.g. 36 degree, 45 degree, etc) also determines the ratio of the two scan velocities.

This would be the way you want to do, to allow it to be mathematically easier to compensate for two rolling scan interfering with each other.

Example: Point a video camera, set to a short frame exposure, rotated 90 degrees, at a CRT TV. You get diagonal scan artifacts that embed useful information (by knowing the scan velocity of one of the two sides, you can mathematically calculate the scan velocity of the other side, just by looking at the video and getting the angle of the diagonal artifact). With enough data, and cross-checking, you can get microsecond-accurate relative input lag calculations with just a lowly 1000fps rolling-scan camera -- once you know the scan velocity of both the sensor and the display.

flood, your numbers seem to be mathematically compensating this already, correct?

[flood]

...yes ;d

the camera consistently underestimates the input lag. this is exactly the expected behavior due to rolling shutter and the position of the indicator LED in the camera's field of view.

so for instance, if A=0.6ms, if the pixels at the top of the frame collect light between t=1.2ms and 2.2ms, the pixels at the bottom collect light between 1.8ms and 2.8ms.

1/250s is a common one for dslrs when capturing full frame stills
the difference in timing is actually around 0.6 to 0.7ms for my 1000fps video

Still confused. There are 64 rows of pixels right? And the camera is rolling scan, and at 1000 fps, the last row should be completed at 1 ms, right?

http://i.imgur.com/IR3MPwU.png

[flood]

Point a video camera, rotated 90 degrees, at a CRT TV. You get scan artifacts that embed useful information (by knowing the scan velocity of one of the two sides, you can mathematically calculate the scan velocity of the other side, just by looking at the video and getting the angle of the diagonal artifact). With enough data, and cross-checking, you can get microsecond-accurate relative input lag calculations with just a lowly 1000fps rolling-scan camera -- once you know the scan velocity of both the sensor and the display.

flood, your numbers seem to be mathematically compensating this already, correct?

my microsecond data is from arduino setup
no one has the patience to get so much data from analyzing video frames carefully
i just did the video comparison to show that everything works as expected..

[Chief Blur Buster]

something like:
in frame 0
the top row of pixels collects from between t=0 and t=1ms
the second row collects from between t = 0.01 and t=1.01ms
third row collects from between t=0.02 and t=1.02ms

One minor correction to your numbers. I think you meant:

the top row of pixels collects from between t=0 and t=1ms
the second row collects from between t = (1/64)ms and t=1+(1/64)ms
third row collects from between t=(2/64)ms and t=1+(2/64)ms
...
last row collects from between t=(63/64)ms and t=1+(63/64)ms

That said, the graphs confirm accuracy very well.

my microsecond data is from arduino setup
no one has the patience to get so much data from analyzing video frames carefully
i just did the video comparison to show that everything works as expected..

Looking at your data briefly, it works.

Congratulations for breaking the accuracy barrier of a cheap 1000fps consumer camera.

By my math calculations, in ideal conditions, you can get 15 microsecond differential lag timing accuracy (1000fps / 64pixels) from a cheap $200 consumer camera with a 1000fps feature this way (e.g. Casio EX-FC200S), via perpendicular-opposing-scan effects. There's apparently many ways to pull accurate data from the opposing scan, not just by my ideas I already knew. Timing accuracy is the shutter scan time, divided by image pixel height. A rolling-scan 1000fps 1080p camera would get accuracy of slightly less than 1 microsecond.

This is Area 51 stuff.

[spacediver]

http://i.imgur.com/IR3MPwU.png

thanks for the image. But how does frame2 (row 1) occur before frame1 (row 64)??

I think I just don't understand how a rolling scan camera works. I'll try to look it up, so that I can understand your image.

[flood]

something like:
in frame 0
the top row of pixels collects from between t=0 and t=1ms
the second row collects from between t = 0.01 and t=1.01ms
third row collects from between t=0.02 and t=1.02ms

One minor correction to your numbers. I think you meant:

the top row of pixels collects from between t=0 and t=1ms
the second row collects from between t = (1/64)ms and t=1+(1/64)ms
third row collects from between t=(2/64)ms and t=1+(2/64)ms
...
last row collects from between t=(63/64)ms and t=1+(63/64)ms

no thats not what i meant

That said, the graphs confirm accuracy very well.

my microsecond data is from arduino setup
no one has the patience to get so much data from analyzing video frames carefully
i just did the video comparison to show that everything works as expected..

Looking at your data briefly, it works.

Congratulations for breaking the accuracy barrier of a cheap 1000fps consumer camera.

By my math calculations, in ideal conditions, you can get 15 microsecond differential lag timing accuracy (1000fps / 64pixels) from a cheap $200 consumer camera with a 1000fps feature this way (e.g. Casio EX-FC200S), via perpendicular-opposing-scan effects. There's apparently many ways to pull accurate data from the opposing scan, not just by my ideas I already knew. Timing accuracy is the shutter scan time, divided by image pixel height. A rolling-scan 1000fps 1080p camera would get accuracy of slightly less than 1 microsecond.

This is Area 51 stuff.

my data is from the photodiode arduino setup... im not planning to use high speed videos in that way. in practice you can get ~0.1 ms precision from 64 pixel 1000fps video thoigh

[spacediver]

just in case anyone missed it, here is the link to flood's methodology for the arduino photodiode setup:

http://esreality.com/post/2691945/micro ... surements/