[Elphel-support] Global Shutter

[Abe Bachrach]

Sebastian, that sounds like something to try, but wouldn't that
significantly reduce the field of view?

Also, do you know if the WOI settings avoid the "horizontal blanking" issue
which is what would cause the binning/skipping solution to not provide that
great of an improvement? I don't see anything about how the windowing works
in the datasheet.

thanks,
-=Abe

On Mon, Nov 29, 2010 at 5:38 AM, Sebastian Pichelhofer <
sebastian.pichelhofer at gmail.com> wrote:

> On Mon, Nov 29, 2010 at 04:07, Abe Bachrach <abachrac at mit.edu> wrote:
> > thanks for the quick response.
> > In talking with one of the other people in lab, we realized that most of
> the
> > experience that we had working with cameras with rolling shutters was
> with
> > cheap webcams. We hoped that the readout on the elphel sensor *might* be
> > fast enough that the rolling shutter effect would be insignificant.
> > Unfortunately it doesn't sound like that is the case.
> > - if the time gap is ~1/15 sec that means that if the camera is moving at
> > 5m/s (~11mph) then camera would move 33cm during the readout period. 4X
> > binning would make it a bit better, however the sensor would move ~8cm,
> > which is still quite significant.
>
> You mentioned you need only a small fraction of the 5 megapixels
> resolution the sensor offers. If you reduce the WOI (Window of
> Interest) you can increase the framerate and therefore the readout
> time (more than with binning):
>
> For example at 640x480 you can reach a max. of 126fps which would
> reduce ERS artefacts to just a little more than 10% of the 33cm you
> mentioned at 1/15s.
>
> Regards Sebastian
>
>
> > For more info on the rolling shutter distortion that I'm referring to,
> see:
> > http://en.wikipedia.org/wiki/Rolling_shutter
> > There are algorithms out there, that try to compensate for the rolling
> > shutter distortions:
> > http://mpac.ee.ntu.edu.tw/Exhibition/rolling-shutter.php
> > http://www.cvl.isy.liu.se/research/rs-dataset/0382.pdf
> > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05459408
> > However it is much better to avoid them altogether by using a sensor with
> a
> > global shutter. This is the approach taken by most people in the robotics
> > and machine vision communities.
> > As I said on the phone, I believe the Elphel platform would be VERY
> > attractive for many people in the machine vision/robotics community,
> however
> > a global shutter is a must for any of the applications that involve fast
> > motion which many of them do.
> > thanks!
> > -=Abe
> >
> > On Sun, Nov 28, 2010 at 9:45 PM, Andrey Filippov <andrey at elphel.com>
> wrote:
> >>
> >> On Sun, Nov 28, 2010 at 7:30 PM, Abe Bachrach <abachrac at mit.edu> wrote:
> >>>
> >>> One other question for Andrey/someone else is:
> >>> - How much time elapses between when the first and last row are
> read-out?
> >>> from looking at the datasheet, it says that the maximum datarate is
> >>> 96Mp/s, which would mean that for full resolution, the time gap would
> be at
> >>> least 0.052488 seconds.
> >>
> >> Abe,
> >>
> >> It is somewhat longer than that because of the large "margins", the
> >> average data rate of the sensor running at 96MHz is ~75MPix/sec. There
> are
> >> formulae  in the datasheet that allow to calculate line readout time for
> >> different ROI and decimation
> >>>
> >>> - is the sensor being run at the full 96MHz clock rate? Is that time
> gap
> >>> number correct?
> >>
> >> 96MHz - yes, correct, but the "gap" is wrong - at full resolution
> readout
> >> time (and so the delay between the first and last line exposure) is
> ~1/15
> >> sec
> >>>
> >>> also,
> >>> - How does the subsampling mode effect this. If we put the sensor in
> >>> binning/skipping mode, and downsample by 4x, ideally, this would mean
> that
> >>> there it takes 0.0032 seconds to read out a frame.
> >>
> >> Yes, that is correct. Just keep in mind that there is a large "dead"
> time
> >> (horizontal blanking)  added to each scan line, but small on top and
> bottom
> >> (vertical blanking)
> >>
> >> Andrey
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20101130/12fb8490/attachment-0002.html>