Hello there!

I now planned to create this post for some time, eventually with the help of a new year resolution it saw the light of the day now.

I am involved in the development of the Apertus - open source cinema project: http://www.apertus.org and also love shooting timelapse. Got my Merlin/Acuter pan/tilt head a few weeks ago, waiting for tronisoft RS232<->TTL converter to arrive.

Now the reason I am posting here:
Apertus is mainly a cinema motion picture camera. I think it is potentially the ultimate tool for any demanding timelapse shooter. Apertus is still in the middle of development and I am working on the Camera Controlling GUI called ElphelVision: http://www.apertus.org/elphelvision . I already added FPS reduction options recently (see attachment: ) but there is so much more that would be interesting for timelapse.

-) Camera has no mechanical shutter, so you can basically shoot infinite number of images (with DSLRs even if they are rated for 100.000 releases you could run into problems with timelapse rather quickly)
-) Camera can run on its own without the need of a connected laptop or intervalometer
-) exchangeable lens (C/CS Mount)
-) 5 Megapixel resolution (I know DSLRs have much more but considering the biggest target format is most likely FullHD anyway...)
-) Max 15fps at full resolution
-) built in HDR capabilities (there is room for improvements though), but the rather high possible FPS (at least compared the DSLRs) would allow to capture 9 exposure brackets in under one second (if exposure time allows it)
-) RAW modes available
-) Full manual control of all camera parameters (variable FPS, variable exposure time (not just 1/2 or 1/3 EV steps you can use any Float number))
-) Camera is rather power efficient (max. consumption is around 4-5W with video streamer and HDD recorder writing at full load, time-lapse will require less resources)
-) Write video/images directly camera connected SATA device (SSD/HDD/CF card)
-) You could use scripts in the camera to do whitebalance-ramps or exposure-ramps depending on time of the day for example
-) The camera itself could become the controller of devices like the pan/tilt head or the dynamic perception dolly or any other equipment that can be interfaced with via USB, it would even be possible to write metadata like dolly position or pan/tilt values into the EXIF fields of every shot frame

Issues
-) Small sensor (1/2.5", tiny compared to DSLR cameras true, some depth of field is possible though but of course it cant be compared the APS-C, new sensor frontends will be release possibly already this year: 2/3", 1", 4/3", etc.)

So I need your help: with feedback, ideas, feature requests or possibly even help with coding itself (the whole project is open source, I develop ElphelVision in Java).
I know that there is a certain barrier as for real life testing you would need an Elphel camera (800-1300$) but in ElphelVision I added a startup parameter that lets you test the software even without a connected camera (useful for debugging, testing the interface).

Hi Sebastian,

You mentioned frames stored on harddisk, are there any option to transfer files automatically via USB and/or network ?

Removing DSLR shutter life constraint seem to be a nice option for long lasting timelapses, on the other side you may want to preview/monitor and/or securely backup your shots for long lasting timelapses.

I'm also working on an open source project aimed to capture pictures sources and process (add text, legend, date, watermark, publish, ...) them and automatically create videos and publish them. I took the problem from the other side, concentrating the intelligence on a dedicated box that could be used to manage multiple "dummy/simple" sources such as PTP Cameras (DSLR, Compacts), IP Cameras, USB Webcams, ...

PTP Cameras: Highest quality, complex to "weatherproof" (mostly due to the size), limited shutter life, pretty expensive.
IP Cameras (CCTV): Low quality (generally up to 3 Mpix), can be expensive, "weatherproof" versions can be easily found.
USB Webcams: Very poor quality, very cheap, easy to "weatherproof".

Elphel Cameras could well fit between PTP Cameras and CCTV IP Cameras.

If network is available on the camera would it be possible to access a live stream (low res) and capture high res pictures at the same time ?

If I can be of any help just let me know, I would be happy to test a camera and see how it could be integrated within the project I'm working on.

Fanf'

Sorry Sebastian, I just saw that we spoke a bit about Elphel a few weeks ago and don't want to vanpirize your post but I would be interested to test the camera anyway

Nothing spectacular, more a proof of concept:

Another (actually much older) sample of timelapse work with Elphel/Apertus cameras:

There's a point here worth mentioning that would really tip the scales in favor of a camera like the Elphel (and I love the Apertus project, what a great goal =):

The camera is run by an on-board linux computer, the frames are sitting right there on hard disk -- you can use any open-source linux tools (I know Processing has the functionality to do this) to wrap up the frames into a movie container and preview your timlapse video -as you shoot it-.

The workflow opportunities here are where I think this really shines. It's hard for any small project to compete with the Canons and Nikons of the world in the sense of $/pixel or $/feature, or $/sensor size, but they see no value in solving our workflow problems =)

!c

Sounds like an exciting project! I heard Stanford is working on an open source digital still camera. Can't find the link at the moment.

I agree live continuous preview would be a huge plus. If we can do it on the camera directly, then we have to be able to turn that mode on in the beginning, and leave it on. Unless you have GOD's tripod, you really can't touch the camera or any buttons on it once you start.

You mention ramping exposure. What we really need is an exposure/white balance that takes the running average over a period of time. For instance, if you take a picture every six seconds, average the light meter reading from the last 18 or 24 seconds. This very simple feature would eliminate almost all flicker. And we all hate flicker.

Cheers,
Kirby
www.36viewsofabridge.com
www.peristalticmayhem.com

Hi,

IMHO it would be better to calculate the median instead of the average, this way things like single frame lights (cars that drive by, etc.) don't affect the metering.

Looking forward to the progress of this project.

Best Regards
David

Interesting point. That got me thinking. It's not that the light meter data that should be averaged or 'median-ed', but rather the last few final exposure settings. The difference is subtle, but may be important.

How that was handled in lightrails was a very simple method: thresholding. You establish maximum threshold of change between X frames, and ignore any change that occurs outside of the threshold. (No more than Y change between two frames, and no more than Y+N change across a set of X frames.) It effectively eliminated the problem of dogs walking in front of the sensor, and bright lights flashing across one or (even three) frames, by simply establishing a threshold that would not likely be exceeded between two frames (can the environment really change 3 EV in 1 second? I set the default to something like 1/10th EV [or maybe it was 1/100..] so the maximum change from frame to frame is 1/10th EV, this eliminated interference jumps.). Median-based analysis may work slightly better, but I believe it would not be a cost-effective change -- that is, the amount of effort to do it effectively does not equate the same amount of performance improvement. Also worth mentioning, that they really only work -great- if you don't write out a final images until you have performed the calculation for the entire set -- i.e. working with raw images =) That is to say, you take 100 frames at some base assumption, as RAW images, calculate the curve across them by examining how many pixels are over/under, write the jpegs with the new settings, and adjust the curve for the next 100 frames.

Regarding starting/stopping preview functions while the camera is rolling/not touching the camera - you can do it before hand, or you can also have a remote interface (which I personally prefer), allowing you to fully interact with the camera while shooting without introducing vibrations.

!c

EDIT: BTW, the Stanford camera is the FrankenCamera, found here: http://www-graphics.stanford.edu/projects/camera-2.0/ they do have a firmware image for the Nokia N900, but no actual physical camera for sale as of yet. It's an interesting design, but outside of the firmware, doesn't offer much (other than form-factor) over the Elphel, they have similar sensors. Admittedly, the trick of using two flashes, one strobed continuously at a low level, and the other sync'ed to the end-curtain is pretty cool, but can be done inexpensively using existing technology (i.e. put my Sunpak 622 Super on my K7 or K10, in trailing curtain sync, and then run the smaller strobe from an arduino or something.)

As shutterdrone mentioned: Stanford originally used Elphel camera parts in their "Frankencamera" but then got funding from Nokia which seems to slightly have shifted the focus of the project (they released software for the Nokia 900): https://graphics.stanford.edu/projects/camera-2.0/



Since the camera uses Ethernet as primary communication port just hook up a 30$ wireless router (of course you can also get a more expensive one ) and voila: you have full wireless control of the camera, can access all files over wireless, etc.



The camera has an auto-exposure daemon running that "simply said" looks at the histogram of the image, and makes corrections if the overexposure/underexposure is reaching a certain threshold. This autoexposure source code is of course also available under the GPL so it could easily be modified for this kind of averaging/median/treshhold application. it's currently designed for real-time video but allows editing of treshold margins, limits, etc. I guess someone would need to check out how suitable it already is for timelapse.


I just released the source code of my "Timescript" at: http://wiki.elphel.com/index.php?title=TimeScript
It can trigger any Elphel relevant camera parameter change at a certain frame number (even FPS change).