Jeff Epler's blog

A Faster-than-light travel idea for SF setting

According to general relativity there is no privileged frame of reference, and faster than light travel leads to time travel paradoxes.

Concept: Using rolling shutter for digital IS

Rolling shutter image of propeller blades (from Wikipedia)

I make no claim that this idea is original, but I wanted to write it down anyway.

Take an ordinary CMOS digital camera sensor with a rolling shutter and since it only costs a few cents, add accelerometers and gyros.

Now, instead of merely capturing each row from the sensor into a finished image, record each row from the sensor separately, along with its location on the sensor and the time the capture started and ended; record this and the accelerometer and gyroscope data.

When you've got enough processing power available (in the camera if you have it, on a general-purpose computer if you don't), use [the integral of] the accelerometer and gyro data to estimate the orientation and position of each row within a larger image, refine it by using any overlap between rows to align them. Once all rows have an initial placement, refine the placements repeatedly until the best fit is achieved. Paint all the rows onto a larger canvas, trim the result down and interpolate at any spots you didn't cover. ALE and hugin have some excellent algorithms for these steps, though there are probably some additional tricks and wrinkles when all the input images are 1d.

You can even incorporate multiple complete scans of the sensor in this way, adding information without increasing smearing due to motion of the camera. This information can either be used to reduce sensor noise or increase output resolution using ALE algorithms.

You could also do your best without having accelerometers and gyros: use any simple motion estimate (such as zero between the first and second rows, and the previous alignment-based estimate from row N-1..N for row N..N+1) as input to the alignment step.

Finally, an altered CMOS sensor that reads out in an interlaced fashion (or other "non-linear" fashion) would be even better, because the first few rows read out would be spread over the sensor, "pinning down" rows that are read later. For instance, if the initial stride is 16 rows on a 1024-row sensor and the full exposure time is 1/8s then the basic geometry of the scene is captured in just 2ms (relatively little motion being possible in this time) and subsequent rows read will have the opportunity for overlap with both rows "above" and "below" during the initial alignment phase.

WWVB CRT mock-up

The plan is to be able to watch the leap second on some manner of wwvb-controlled clock of my own making.

To that end, Chris gifted me with a compact B&W CRT from Goodwill, and I picked up a TellyMate, which can display 38x25 text on a TV.

Ignoring for the moment the difficulty of receiving the WWVB signal when all the interference from a CRT TV is right nearby, I've created a mock-up of what the display will look like (except that the font won't be nearly so good looking as this):


         0123456789
   0.. 9 M01100000M  Minute  = 30
  10..19 000000111M  Hour    = 07
  20..29 000000110M  YDay    = 66
  30..39 011000010M  DUT1    = +0.3
  40..49 001100000M  Year    = 2008
  50..59 100001000M_ nols LY nodst
   
  Local time:
  1:31:00.0 AM

  Thu Mar 6 2008
  UTC-0600 (CST)

At the top, the WWVB data is displayed, along with its interpretation. The previous minute and the current minute are mixed, with the cursor indicating the most recently read second of data. Whatever piece of data is currently being read or will next be read will be blanked out until all bits are received (for instance, during seconds 0..8, "minute" will be blank; from 9..18, "hour" will be blanked).

Most of the time the "_" shown after second 59 will be blank. During a leap minute it will be "_" and during the leap second it will read "M".

Below, in larger lettering, the local time will be displayed. I think I can achieve 10 updates per second, so I'll show tenths but not hundredths (or, say, thirtieths). The UTC offsets for standard and daylight saving time will be hardcoded (so if I move to Colorado to be closer to WWVB I'll have to fix my firmware).

The WWVB receiver and decoder is written and passes my tests. I have yet to write the display code (and optimize it--I can transmit fewer than 500 characters and control codes per 1/10 second to the tellymate), and I also have to work out how to get enough reception that having the WWVB display is not a big old waste of time. (or maybe I'll just display a simulated WWVB signal instead—with a disclaimer, of course. stop looking at me like that.)