- NC393 development progress and the future plans
- Reaching 220 MB/s sustained write speed with SATA-2 controller
- A web interface for a simpler and more flexible Linux kernel dynamic debug controlling
- I will not have to learn SystemVerilog
- Tutorial 02: Eclipse-based FPGA development environment for Elphel cameras
About this site
This page is created to develop elphel digital cinema cameras. The cinema camera idea started in the first part of 2006 in the mind of a member of the dvinfo forum, and in March 26th 2006 started a new thread called High Definition with Elphel model 333 camera. At the moment we are close to break the 1.000th reply barrier, so searching through them to find good information can be difficult.
This page was born to try to solve that problem.
Previous Elphel models - 333
Here are some important links to understand what we have already.
- all the software that you need to use the camera sourceforge.net
- the link to Axis developer's site
- some video and images from the camera on elphel's community videos, on elphel.com, on tacx-video.com and a video by PS, the first image taken from FS with not the best conditions, a low light 35mm adapter test and one significant test example with a 35mm adapter from Oscar Spierenburg.
and good example of what this setup could do:
- May 18th, 2007, 09:28 PM - first short made with the elphel 333 hd camera + 35mm wax adapter by Oscar Spierenburg using that setup:
The autor said:
"Here is a small version of the 'demo documentary' I made in France. This short film also proves you can synch a separate audio recording(Portable minidisc recorder), using the old clap board method. I also used the wax adapter (which is really a prototype.. notice the soft edges), and only a c-mount TV lens for telephoto shots."
Half resolution (54MB) file here: http://community.elphel.com/videos/RomainSurMeuse2.avi (it's in Xvid compression) Full resolution version Xvid (200MB): http://community.elphel.com/videos/RomainFULL.avi Note: While my girlfriend was working all day in the garden making a path.... I was testing all aspects of the Elphel. Yes, between some shots I helped her a bit, but filmmaking comes first, right? :)
The project started with 333 model cameras, now we use the successor model 353 with the following technical specs:
Quoted from 353:
353 can be equipped with 3 different sensors:
- Aptina 5MP 1/2.5" Sensor
- Kodak 11MP Full Frame Still Image Sensor
- Kodak 16MP Full Frame Still Image Sensor
Both Kodak chips are too slow (~5fps) for real-time video so we use the 5Megapixel CMOS.
With interface board 10369 it is possible to write video to SATA HDD or Compact Flash Cards (2 slots). From the software side a low level tool called camogm or the high level GUI called camogmgui takes care of the recording.
Video can be recorded as quicktime *.mov (MJPEG compression), Ogg Theora *.ogm or as JPEG sequence (all with additional EXIF data like geotags).
Framerates / Imagesizes
In general the chips window-of-interest (only an area of the chip is be used for recording) can be freely modified. The lower the resolution the higher the possible framerate. We don't need the full 5 Megapixels for HD recording.
|Standard||Resolution||Record Mode||max. FPS|
|Full HD (1080p)||1920x1088||color||25.24|
|HD (720p)||1280x720 (1/2 binning)||color||46.2|
DV Standards (caution: square pixels):
- 640x480p (4:3 windowed chip) max. 126.11fps
- 854x480p (16:9 864x480 windowed chip) max. 110.13fps
- 640x480p(1/3 binning full frame chip) max. 81.95fps
- 720x576p (4:3 windowed chip) max. 100.36fps
- 720x576p (1/3 binning full frame chip) max. 66.36fps
- 1024x576p (16:9 windowed chip) max. 84.53fps
5. If it needs custom programming, where do I find info about tools / language etc? Just need a pointer. Any free compilers?
To be able to do development for these cameras you do not need any expensive (or even non-free-as-in-beer) tools. There are 3 levels (not to count client/PC software) 1 - "Web design" - developing of custom user interface - just any web design tools - you can FTP results to the camera 2 - Software applications to run in the camera - you need a PC running GNU/Linux (any flavor) and software from our Sourceforge project page plus additional - from http://developer.axis.com - our software will tell you what to download. 3 - FPGa code development - free (for download) tools from Xilinx - http://www.xilinx.com/ise/logic_design_prod/webpack.htm
6. Does the camera casing have space to accommodate a small hard drive?
Yes, or CF card.
7. Power requirements
Model 333 needs a little under 3W. 353 should need about the same - not to count additional modules - hard drive or flash.
8. Has it a C mount?
CS-mount as it is more universal for cameras - you can install both C and CS lenses
9. If I use a simple SLR mount (Nikon or Canon) to C mount adapter (instead of a ground glass solution), what lens multiplier would be in effect?
That depends on particular sensor that will be used - each sensor usually has info on the Internet.
The same as our previous model had cost: Pricelist
12. Details about the 5MP Sensor
The Aptina 5MP Sensor has a physical size of 5.70mm(H) x 4.28mm(V). Optical format is 1/2.5". But considering that the window of a full HD output only uses around 75% of the chips width the depth of field should be pretty much the same as using a 1/3" prosumer camcorder like the Panasonic HVX200, Sony FX-1 or Canons XL-H1. Aptina claims that the chip has 70db of dynamic range at full resolution and 76db when using 1/2 binning. It outputs 12-bit color data (elphel boards reduces these to 8bit in FPGA? please confirm). It might be possible to overclock the chips (96 MHz) pixel clock to achieve higher fps.
Work In Progress
Reading the dvinfo thread you can find someone (Z.H.) that is making some mod. to the current Fpga;
25 may 2007 - this project by Z.H. is in stand-by and he offer up his project for somebody else to take it over.
"If somebody's interested, here's the BloodSimple(TM) codec I wrote and experimented with. It creates a bitstream directly from the bayer input, always taking the difference of pixels as input. It works best if we use the algorithm in interframe mode, which means that we calculate the difference of pixels from the same coordinate of the previous frame. This of course needs that whole frame in memory.
An output sample always begins with a one bit flag (F) which tells the decoder if the following sample has the same bit length (F=0) as the previous one (a length of P) or it is greater with G bits (F=1). This G constant can be set according to the input stream and it will tell the contrast ratio of the generated images: with a T bit input, following pixels usually don't have more difference than T/2 bits. Visually lossless is around T/3 but it can be calculated explicitly in a pre-encoding step if needed. (By having the motion blur of the 1/24sec exposure, the blur caused by fast pans won't cause quality loss in the encoder as it would do with shorter exposure times.) If F=0, the decoder uses the previous P bit length but if the sample's most significant L bits are zero then the next sample will be taken with P-L bits (if that sample's F=0). The encoder knows this and if the next sample's length is greater than P-L then it sets F=1. L is usually set to T/4.
With sample videos (no real bayer input, only some grayscale mjpeg stuff with some artifical noise added) it has produced a 2:1 average ratio which means 2.5:1 with low freq content and 1.5:1 with high freq content (ie. trees with leaves with the sky as background). Because the code is so simple one can use several module instances in an fpga, for example, one for each pixel in a 20x20 block (or whatever the Elphel uses), working in paralell with only the memory bandwith setting the performance limits. However, with a smaller no. of instances it may fit beside the theora module; altough two output streams aren't supported yet. And it's really easy to implement it in verilog which can be a concern if somebody's not an expert"
"I'm afraid there are no verilog programmers here but somebody might pick it up. As for other bayer cameras, I'm not aware of any other which could be freely programmed like the Elphel. And the compression rate is pretty low (just enough for the Elphel, hopefully), perhaps it might be combined with some other algorithm to get better results."
Graphic User Interface (GUI)
For now we have a very good interface with the possibility of modify every single parameter that you can imagine, it is the ccam.cgi that may be get confusion (being incrementally patched from the first model 303 camera), but it is current.
But for converting the elphel in a cinema camera that freedom is more than enough. Also there are some problems; the software and LiveCD give some difficulty, in fact you can't save the setting in an easy way so to prepare the laptop end the camera you have to spend between 10 to 20 minutes to setup all the command lines that had to be entered to optimize Linux for recording, and more command lines to record etc.
If you want to help us please see this page link</gallery>
Designs for rod support
The idea is to make a universal rod support that could mount:
-The Elphel 353 camera
-Any type of small PC (camera controller)
-Audio interface + microphone
-Most types of 35mm adapters
It is also important that the system is prepared for future hardware changes (like a bigger camera front-end for bigger sensors.)
The following examples are designs by Elphel users/developers:
This design by Oscar Spierenburg puts the camera body in a 45° to safe space for the PC. The tablet PC (touchscreen) is placed in 90° (Portrait) position. (Note: this is not a shoulder mount setup, the middle part is the tripod/steadycam mount.)
Original design by Sebastian Pichelhofer
This is a previous prototype by Oscar Spierenburg with the Tablet PC placed on top of the camera.
Final part list:
Controller-Shell with buttons
Currently the PC.
Screen-Shell (TFT Monitor)
The ideal audio shell would be as follow : Provide two phantom powered (48v) XLR inputs with switches for each input to enable/disable phantom power (required for professionnal mics) and to choose if the input is mic or line level. Some had success using beachtek/juicedlink type adapters. They convert XLR input to mini jack output. So in the first incarnation, this could be a simple "line in" without volume control.
A good quality pre amp can be made using a velleman kit, cfr. http://rebelsguide.com/forum/viewtopic.php?t=1803&sid=c9da5241552feeee72941b44b6ff6e60 the kit is found here : http://www.vellemanusa.com/us/enu/product/view/?id=350491 Note that it doesn't include phantom power. // I think phantom power is a must.
The ideal system would be an opensource audio board.
Intelligent-Handle (USB connected) with ball and joint socket.
This could serve as joint for the handle and wears 6kg by $55.
(do you know of anything else?)
The parts should be produced in aluminium or/and abs-plastic. All designs need to be open source. It would be good to find a university or shopowner who would participate on this project without personal benifits.