Wow, great progress Oscar.

I think 4 rods are definitely the way to go as you can easily attach microphones, etc on the top rods.

Would it be possible with your setup to also shoot from the shoulder and have the laptop mounted at a side?

Thanks a lot for the info.

But according to DP advises, when shooting in HD and using a 35mm adapter, focus is really critical. I wonder if the max resolution of your touchscreen (800x480) is enough for that or it'll be better to have a higher resolution screen (720p or something).

About your rod support it looks great but I'm looking for your 3d model for a typical shoulder mount position...

I don't think that a full resolution monitor is required to judge the image (sharpness).

Sony (and maybe others as well) does something called "peaking" to visualize image areas that are in perfect focus.

This basically looks like colored lines around sharp objects:
http://scubavideo.de/wp-content/uplo...peaking_on.jpg

This is done with image areas of high frequency information. Luckily this frequency information is available inside Elphel cameras as it is a byproduct of mjpeg compression. Now we just need to overlay this on a live image somehow.

This is the way to go. Those EEEPC's are relatively slow and real time preview is not yet evident on a slow PC. So we will possibly end up framing on a small (but live) image on the PC and focusing with the "peaking" method. That's why I'm going with the PC on its side now.

I think we should take this step by step. Right now, the camera has a rolling shutter artifact that makes handheld shooting difficult. I'm not saying it's impossible though, but I'd think about a steadycam setup more than a shoulder mount.

But I'll look at the dimensions in the 3d model and see where the shoulder mount should be. Probably still behind the PC, so we don't need to put the PC on the side (which would makes it hard to balance)

what about migrating to a Spartan-6 architecture with a soft core, microblaze or the like?

Spartan 6, yes, but in the current camera the CPU is a bottleneck. So upgrading FPGA will need upgrading CPU also. So I want it to be much faster than softcore and have all of the peripherals I need too.

That's the idea, using the Spartan to receive and send the image data, bypassing the CPU as much as possible, leaving the softcore (microblaze or better yet some open source one) to manage the strictly necessary, like passing settings to the CMOS sensor, etc,etc.

Updated the wiki: HD cinema camera Development FAQ - ElphelWiki

Camera GUI
 

I started working on the cameras screen interface concept.

The nice thing is that this does not require any additional hardware, just some webprogramming and will run directly inside fullscreen firefox.


Here is how other folks do it:

http://www.hdforindies.com/uploaded_...ain-782743.jpg
http://provideocoalition.com/images/...s/DSC_0639.jpg
http://www.thehighwaymanmovie.com/im...onitor1850.jpg

Detailed plans how I want to technically approach this:
-) the main video window is running gecko media player (a firefox plugin that embedds mplayer)
-) the interface around it are 4 java applets (good for realtime drawing)


VLC could also be used for the video window (cross platform compatible) but so far I was not able to overlay anything on top of a VLC video and I was not able to turn off caching in VLC which results in a short delay in the live video stream.


The concept for the layout implies that you (the camera operator) use your right hand to move the tripod handle and your left hand to operate the touchscreen. Thats why the controls are on the left handside of the screen.


Now please find me more images of other manufacturers screen designs and give feedback!

This is really starting to look 'ideal' Sebastian!
I hope a slower PC can stream real time/full screen... what do you think?
One note: The design I'm making now uses the tablet PC on it's side (portrait) Would your interface be auto-scalable when you have a low res screen? Maybe it's an idea to have the HDD file browser bellow the controls, so you see them when you use a PC in portrait mode.
Tomorrow I'll make an example of what I mean.

Great work!

very cool maybe it is possible to add a mask on the top of the image with line of the safe area
silicon imaging gui is what I think is the best one
some ago I worked on this with flash ...but under linux flash is not a good idea elphel GUI-2
and I used big buttons because I tink that the way to go is the use of small screen 10" max

http://www.dvinfo.net/conf/alternati...33-html-2.html

Sebastian,

I made a quick example of my idea about the interface.
If the live image would be auto-scalable (to the screen resolution or window size) then we can use tablet PCs with portrait/landscape modes. This would really make the final camera smaller.
But of course when the screen has rotated 90 deg, you'll end up with a small live preview and lots of empty space.
With that in mind it would be a good idea to make a frame below the interface with the HDD file browser. When you're in landscape mode, you need to scroll down to use the file browser of course.
In my example I've also made the buttons bigger. Those buttons should stay the same size in portrait mode, so they have to be able to rearrange in two rows.

Just some suggestions :-)

Good ideas!

I found out that mplayer can nicely be integrated into java so this would mean the whole application could be a single java applet.

The concept image I made already has the 1024x600 resolution of most netbook screens. But you are right the interface should adapt itself to the current screenresolution.

The main functionality of the filebrowser you mentioned would be to review recorded clips I assume.
So why not add a button to review the last recorded clip as well in the main interface.

I don't like the scrollbars, the filebrowser should be accessible with a normal button in the bottom menu I think.




We should start to look for an official name for the project:

I think we need a short project name and lengthier subtitle

Requirements for the project name:
*) short and descriptive
*) easy to remember
*) cool sounding
*) should allow us to reuse the name for sequell/sub projects

Requirements for the subtitle:
*) "open source"
*) "based or powered by Elphel"


Any suggestions welcome!

Btw: I created a google group for developing this camera. Just PM me if you want to participate and I will invite you.

Matteo.. Of course I also haven't forgotten your input. Too bad the flash design doesn't work out. Java is a good alternative. BTW, did you test it with an online camera or do you own an Elphel?

I have a name... just don't know it yet :-) ....but I'm on to it. Need to find someone who speaks Latin;-)

Apertus
 

OK, here's my idea: What is the most unique feature of this project and the Elphel philosophy?

-Open source-

Nothing else. Other features are all irrelevant, the whole point of us talking on this forum is because it's OPEN ..even the choice of the name itself :-)

So I figured.. what's the word for OPEN in Latin?

Open = APERTUS

So how about:

APERTUS - powered by Elphel

I think it's strong word and has a story to tell about the project background.

Oscar, your a genius!

It sounds similar to the very photography related word aperture!.

or the word Apparatus
Wikipedia:
Apparatus, (Latin, apparātus; plural apparatus or apparatuses) is a mass noun used to describe equipment designed or assembled for a particular purpose.


I also thought up some "epic" words but APERTUS beats them all!

Aurora (Aurora - Wikipedia, the free encyclopedia)

Guernica (Guernica - Wikipedia, the free encyclopedia)

Columbus (aren't we keen adventurers as well?)

Latin is the base of most modern languages. All kinds of words and terms originated from Latin, so it makes it universal.

Hi oscar
by now I've not tried any software cause I havn't got the camera yet
and now I'm spending a lot of money on software and hardware for my activity (I'm a civil engineer) so I've not so many money to spend
second, cause I'm not a programmer I had set aside the project for a while because before the coming of Sebastian (god bless you) this project (cinema side of the elphel camera) was growing so slow (I've taken a php book to learn it but it need too many time to me to start from zero) buy I've been a reader of the dvinfo thread :-)
third movie in dslr world was a fresh reality but I think that that project is more "open"
So now we have almost all that we need to start cooperate
I've made some experiment with the adapter. I've tryed a lot on this side
and I've seen that the best compromise is to use a medium format lens I've taken some old mamiya now I've got 35 3.5, 45 2.8, 80 1.9 and 2.8 and zoom 110-220
so the recipe is:
Mamiya 645 lens => 63mm => wax GG => 7mm => PCX Lens D70/FL67 [)=> +-100mm => camera
and the wax gg is made by an alloy of paraffin and beeswax 9:1. The pure paraffin is for a sale in a pharmacy

hope that that help someone :-)

I like tha idea of a name to this project
I like apertus but somthing remind me to aperture by apple
so that my quote

HYENA (very similar to a dog but almost wild - free )

don't know why but I think is cool

hi to all

I'd like to add one thing about the choice of the projects name:
We are not aiming at a mass consumer market with this name. If we would pick a too slick name, we would raise too much expectations on a 'growing' project. It has to have a modest feel to it too.

So I'd suggest we really consider Apertus.
(referring to another discussion:) I think most people around here would know how to pronounce Apertus. :-)

About the name: "Apertus" is still my favourite.
Is it pronnounced just like "aperture" but with an "s" at the end?

I did a quick google search:
Welcome to Apertus - Open Source, SaaS, Out Sourcing is already taken by some Indian open source software service company.

apert.us would still be available ;)

Of course we can also ask for an elphel subdomain: apertus.elphel.com

Another idea about the project name:

What about calling the project: "OpenEyes" and instead of Eye we write "Open Is" or "Open iiis"

Just imagine the video description: "filmed with open eyes" ;D

Regards Sebastian

just for info:

english: open
old latin: apertus
italian: aperto
spanish: abierto

I suggest we close the discussion about the name for now and carry on with the main topic.

It will not be long before I can start testing the first 12v camera (many thanks to Elphel for improving the 12v version!)
What options do we got? The battery has to be usable for at least an hour, easy to mount at various places on the rod support (for balancing) and possibly chargeable 'on camera'. For the 333 I successfully used a drill battery, but it discharged withing half an hour and was very bulky on the camera.

Any suggestions?

EDIT: The Elphel Wiki has a page about the 12v version: http://wiki.elphel.com/index.php?tit...ions&rcid=5266

Maybe using one of those A123system battery Packs used by DeWall ?

Yes, maybe. We also need a system where you can charge the battery AND power the camera at the same time, like a laptop. This is because we'd like to avoid rebooting (=resetting) the camera when the power runs out.

You could get it, there is newer technology, and dual core netbooks (tablets I don't know much) with DX10 chips with hardware acceleration. I had been waiting for Intel to release there DX10 hardware for their tablets, and now they have new n40 chipset and lower powered atom dual core. Nvidia has released a new small handheld PC box form factor (I believe they might still be talking to VIA about buying them, great move, a lot of nice portable stuff). The form factor can support a variety of processors, but newer Atom dual core is probably what you are looking for. The maximum, battery life for network that I have heard of, second hand, is around 26hours battery life, dual core In think.

Now back to it, for DX10 chips there is GPU programming, I think that the Nvidia version is called CUDA and is c++ like. But the problem is that you don't want to be the one making or converting the open source video codec for it.

Hi everyone,

I'm working on a detailed version of the rods support CAD model for the Elphel. I want to avoid having stuff machined that already exist.
One thing we don't want to make, are the handles on top and on the front. So we should be looking for things like this
(unless we would go for a handle with control buttons of course)


All ideas are welcome!

Here is the summary from a discussion about battery packs were recently had:

Elphels power consumption (10349 - ElphelWiki) is around 5W at full load (streaming video and writing to internal HDD).

With the optional 9-36V Power supply (best efficiency at around 15V) we did an example with a 12 V battery pack (Pb batteries would do the job)

The maximum current with 12V would be around 400mA

If the battery pack has a capacity of around 4000mAh it would allow the camera to operate for a maximum of 9.5 hours (not considering DC-DC losses, degree of efficiency, etc).


An interesting reference for the power consumption of all different cameras and manufacturers can be found here: How to choose your battery

Sony PD 170: 8 Watts
Red One: 60 Watts

A quite detailed explanation here : http://www.antonbauer.com/downloads/2008Handbook.pdf

Their conclusion is probably to buy their own battery packs, but still an interesting read about batteries, specifically for video work.

An interesting project of building a though small Lithium Ion battery pack can be found here: HY Research - Simple Li battery power supply


Last not least its important to have a proper mount system for the battery pack that allows battery changing without screwing and plugin in multiple connectors.
Examples are the Sony V-Mount for their professional cameras or the Anton Bauer mount.

Conclusion:
LiPo batteries are to date the lightest available technology, though very expensive and rather dangerous as they easily catch fire if not charged or discharged properly.

LithIon are probably the most widely spread camcorder, still camera, laptop and cellphone battery packs today. Though they also thread a potential danger if not properly secured and monitored by protection circuits.

There are the heavy and cheap big Pb battery packs that hold a wast amount of power and can be charged rather easily compared to LiIon or LiPo packs. Their weight might help balance the front-heavy rigs (heavy lenses).


Does anyone know an open source / open hardware approach to design a general purpose battery pack?

I bought a universal charger with integrated balancer (needed LiPo) so I can try different types of batteries if needed.
First I'll test out LiPo. They have two connectors to charge:

A balancer cable
A power cable

How about using some kind of a project box ( something like this or this )

The dimensions of the battery I have (pretty standard) are:
W= 50mm
H= 30mm
L= 90mm (maybe longer for higher capacity batteries)

If you have two batteries in an enclosure that mounts directly on the rods support, you only need to connect and disconnect the power cable. Would be like the shell design posted on the wiki, only other dimensions.

I also got a led that will light up if the battery runs down to 9v. I'd like to get a fully functional battery meter, but this is a beginning (to know when you have to change batteries, but also to spare the life of the battery)

I spent many hours in the last 3 days to get the S65 LCD I bought for the camera buttons interface running . Without success so far. I don't have an oscilloscope to be able to properly monitor the ignition sequence. All I can do is measure if there is a signal and if the wiring is OK. I was so desperate I even tried to monitor the signal with the line-in of my sound card but 44KHz are simple not enough when dealing with a 8Mhz+ transmission. All I was able to verify was that there was indeed a signal being transferred.

I kind of gave up and instead of buying a (cheapest) 1000$ oscilloscope I decided to buy a 30$ ready built S65 LCD shield for the Arduino.

But finally a small success in a different area today. I managed to embed an MPlayer video canvas in a java application. It also already works with the cameras live stream!

Now we need a cool name for the viewfinder software that keeps me motivated to go on :)

Great work! How about calling -this- Elphel Vision?

BTW: LiPo works perfectly with the camera. I don't know yet how long the battery will run the camera though.

I've tested the camera interface and HDD recorder interface on the TabletPC in portrait mode(upright). Although the camera interface is normally a mess on this low resolution screen, in portrait mode it works surprisingly better! The window is scaled down better and the long 'tab' of camera controls fits the screen.

The HDD recorder interface (camogmgui) doesn't show up that well in portrait mode, but that's only because the layout is designed horizontally.

I guess the images below explain everything.

(I still feel this is a good setup, the preview image is small, somewhat like most camcorder LCD's, but you have a lot of space left for all the controls. But, the main reason is to save space on the rods support.)

Very nice Oscar!

Both camvc and camogmgui as shown in your last post are actually just workarounds because we have no real cinema camera control software yet.

Calling THIS software "Elphel Vision" is a great idea between, at least it definitely got me motivated.

I did further tests for Elphel Vision and managed to draw text overlay on top of a live video feed from the camera in a java applet (using mplayer in slave mode). See attached image. (Yes it is "the very hungry caterpillar") :)

I actually climbed on the roof today and shot some footage with the LiPo.

Cathedral on Vimeo - Yes, I have a cathedral in my backyard :)

I didn't use a 35mm adapter. The image is not sharp enough (too big aperture I guess). So clearly, focusing is difficult without a focus aid. There seem to be some frame drops, but it could also be that I couldn't fix the frame rate (must be something in the new firmware.)

The battery (2000 MaH) dropped from 12.8v to 11.8v after +/- 1,5 hour.

Hope to be testing "Elphel Vision" some time on the roof ;) It looks very promising.

Get rid of window decorations
 

Oscar, you'd rather open camvc2.html in a new window (as the alert message says) - it will give you more room especially on the small screen. And camvc _is_ designed to work in the new window. When doing it first time you'll need to enable popup windows in Firefox
Next (it is also written in the alert box) open "about:config" in firefox, enter "dom" in the filter and edit several options so the camvc2 can:
- hide address field:
dom.disable_window_open_feature.location false
- hide status bar
dom.disable_window_open_feature.status false

In Linux you may save even more space - right-click on the title bar of the window, select "advanced->no border" (alt-F3 to be able to restore it back).

Sorry if it has been asked before, but what is the "lag" of this setup? I mean, how much is the delay between live action and what you see on the screen ?

Philippe, I think Sebastian had good results (semi real time), but I can't judge if the lag (about 1/2 sec.) I experience on the tabletPC is a result of the speed of the PC. On a fast laptop I was able to get almost real time preview. In the current camogmgui I can only choose 'update every 1 second' as live view, so that's not really workable. But as Sebastian says, it's a workaround interface and he is implementing mplayer now.

Battery update:
I've soldered a 'LiPo saver' on the battery wires and put everything in an improvised enclosure with rod support mount. The 'LiPo saver' is a LED light that lights up when the battery reaches 9v (3v per cell). This is because a LiPo battery must not be discharged under 2.5v per cell.
Maybe it would be possible to make a relay in stead of the LED and actually shut down the battery (or maybe it already exists)

The internal camera delay resulting from putting the full frame into memory and reading it out again for compression, image processing, etc. should be extremely small (maybe a single frame at 25fps if at all).

But I also get varying delays in the player displaying the video live stream from time to time that are very well noticeable.

VLC for example has built in caching so it will fill up a buffer of read data in advance to displaying it. Mplayer should be optimized for not causing any delay but as Oscar mentioned there still can be a short delay sometimes. We will need to do some investigation to solve this problem.

Here is the first concept for the DICTATOR Camera Control Interface.

It will work together nicely with the touchscreen / laptop and the Elphel Vision Software.

But it can also be used standalone with the camera. There is just no direct way to view live video then.

What do you think?

This looks great !

Other batteries types have a drop of voltage before being empty. Here an article with some nice curves : Battery monitoring

A great way to monitor battery level could be to feed the battery voltage to an analog to digital convertor (an analog input on the arduino?) then monitor the voltage of the battery and have some kind of meter shown on the lcd screen or on the web interface.

Different battery types have different discharge curves. The firmware of the camera should have one for each type of battery (nicd, nimh, lipo...), then the user could choose which battery type/ capacity is connected to the camera and have a precise meter of the remaining battery level.

I don't know if it works like this in other systems, but I think it could work. I guess other more intelligent systems (like stamina) have built in electronic in the batteries that have this curve and the initial capacity of the battery stored. All this can be done in camera I think.

Have you guys at Elphel considered using a Beagle board to power the next camera ?

They look very interesting in the video department (and inexpensive). But I wonder if they are open source...

BeagleBoard.org - brief