High Definition with Elphel model 333 camera

Oscar Spierenburg · February 2nd, 2009, 04:17 PM

Small update:

I've finished a follow focus system for the 35mm adapter. The follow focus moves the whole lens mount, so you don't need to change anything (accept focus marks) when you change a lens. You can also change the whole lens mount (thanks to Sebastian's idea for the Elphel lens mount)
You can see the (big) gear sticking out underneath the focus knob. That was necessary to get subtle focus adjustments. One whole turn is a little more than the whole focus range. (sorry for the bad photos)

EDIT: I noticed Sebastian's notes on the wiki Great idea!

Daniel Rudd · February 3rd, 2009, 03:36 AM

once again, i want to say "nice work" oscar (and others).
I wish I could contribute more, but you guys have taken this discussion well out of my league. I understand enough to be impressed.
Thanks for innovating.
Daniel

Andrey Filippov · February 7th, 2009, 01:24 AM

Elphel camera under the hood: from Verilog to PHP

Oscar Spierenburg · February 11th, 2009, 09:58 AM

Sebastian mentioned working on a preset manager for the Elphel control software (camvc)
I've got a suggestion to integrate the camvc into the live preview window of the camogmgui ( see the wiki )

Using D-SLR camera's a lot, I've come to the conclusion that: although you can set white balance manually, most of the times you just end up using one of the presets.
Symbols like a sun, clouds, light bulb etc.
I think when it comes to the Elphel camera interface, such symbols would be sufficient and preferable in real situations.

I've attached a quick example of how I think the interface could look like. Other suggestions are welcome ...unless Sebastian turns pale right now :) ... it's his software after all.

Sebastian Pichelhofer · February 16th, 2009, 07:47 AM

With the color temerpature calculation we got quite a thing started.
I am afraid the math is not that simple:
Planckian locus - Wikipedia, the free encyclopedia

Konstantin Kim helped simplifying this a lot, see attachment:
the T:= Matrix holds the target color temperatures and the following two matrices the R and B coefficients for a 5500°K initial color temperature.

So all we need now is the inital color temperature that the image has when coming directly from the sensor.

Andrey suggested to film a known color temperature image and see how the coefficients after autowhitebalance behave to calculate the resulting initial color temperature.

Maybe we will soon solve this mystery :)

Between I released a new version of the harddisk recording tool camogmgui: Camogmgui - ElphelWiki

It now supports simple creation of film like Naming schemes with fields for Scene, Shot, Take, etc.

Andrey Filippov · February 17th, 2009, 12:02 PM

Sebastian, for calibration using the automatic white balance in the camera you should use some white object. Do you know how that automatic balance works?

This balancing assumes that the most bright object in the frame has white color. So it cuts a little on the color histograms. Both fraction of the pixels above the level and the absolute pixel level can be specified in the parameters - if the number of pixels for the brightest color above specified level is smaller than specified, the level is reduced until the number of pixels condition is met.

After finding level/fraction pair for the "brightest" color component same number of pixels is cut from the right side (high level) of the histograms for the other color components, and the corresponding levels are measured. Then the gains in the channels are changed accordingly to equalize those "white" levels. The current 8.0 software allows additionally to add tint so the "white" object in the frame will have predefined color different from white (camvc allows that using control sliders).

When adjusting gains in the color channels two mechanisms are used (there are user parameters that can impose additional limits). First the analog gain settings of the sensor are used (analog gain is often considered as "ISO" in the digital cameras). But those gain stops are rather far apart (sensor we use has 12.5% steps in some gain range and 25% in the other) so camera uses digital scaling (17 bit multiplication) to "fill" those (12.5-25%) gain gaps. By default the camera uses "theoretical" analog gain values for each gain setting, but it can use a table of measured values so it is possible to write a script that will change analog gain (and simultaneously digital scaling and/or exposure) to calibrate each analog gain actual value.

Sebastian Pichelhofer · February 19th, 2009, 05:05 AM

I will try to get a color temperature meter to make this calibration a real calibration instead of just assuming temperature from a certain light source.

Sebastian Pichelhofer · February 22nd, 2009, 11:13 AM

I made a calibration test shot today.

Konstantin please use these values to calculate the original temperature:

T = 2810°K

R = 148106 / 65536 = 2,259918212890625

G = 131072 / 65536 = 2

B = 288552 / 65536 = 4,4029541015625

What do we do with the GAINGB in this scenario?

Andrey Filippov · February 22nd, 2009, 07:32 PM

Quote:

Originally Posted by Sebastian Pichelhofer

I made a calibration test shot today.

What do we do with the GAINGB in this scenario?

There is no high-level (in camvc) support for it yet, I just tried everywhere (in the drivers, autoexposure/white balance daemon) to make it possible to use for "jp4hdr" mode (high gain while GAING, GAINR and GAINB are at lower end). So in normal mode GAINGB==GAING, in jp4hdr GAINGB should be 8..15.75 independent of the other 3 gains

Ivan Castell · March 7th, 2009, 06:14 AM

Hi everyone.

I'm really impressed of the quality of this project. I myself, being an indie filmmaker I'll like to make the move and try to build my own digital film camera with DOF hability, but I think that right now building it from the elphel (if you don't have the technicals skills required) it's out of my reach.

But anyway, just checking this footage from the 333 model, with a 35mm dof adapter looks fantastic (apart the artifacts at the edges):
http://community.elphel.com/videos/RomainFULL.avi

Maybe it's an idiot question that has already been rised here, but, it's not possible to have film DOF on this chips without the dof adapter?

What's the entry level minimal cost right now to build such a setup?

What could be the quality of the image that we can get compared to other cameras? RED, scarlett, hvx + 35mm adapter, etc...

Regards.

Oscar Spierenburg · March 7th, 2009, 09:12 AM

Quote:

Originally Posted by Ivan Castell

Maybe it's an idiot question that has already been rised here, but, it's not possible to have film DOF on this chips without the dof adapter?

Right now, it's not possible to have film DOF without the adapter. Because DOF is directly related to the size of the film/sensor. The sensor on the Elphel is 1/2". Using a 35mm lens without the adapter would simply project a 35mm image on a 1/2" screen, making it a huge telephoto lens.
So the only alternative is a bigger sensor. That's something of the future, although they already exist of course (Red, Canon 5D mrkII, Nikon D90 etc.)
We would have to wait for the costs to come down for such sensors... or we have to order a large quantity to get the price down.

EDIT: Interesting sensors are noted here
The Dynamax35 is by far the most promising so far.

Quote:

Originally Posted by Ivan Castell

What's the entry level minimal cost right now to build such a setup?

What could be the quality of the image that we can get compared to other cameras? RED, scarlett, hvx + 35mm adapter, etc...

I guess the costs for the camera are on the Elphel website. You would need a controller PC or mobile device that runs Linux and has an ethernet connection. A cheap EEPC would do, but still a bit big perhaps. But note that everything is still under development.

I don't know yet how the image is compared to other cameras. I'd like to see a test like this with the Elphel one day : Zacuto's Great Camera Shootout! 2008 | Indy Mogul - DIY filmmaking

Ivan Castell · March 8th, 2009, 06:35 PM

Quote:

Originally Posted by Oscar Spier

Right now, it's not possible to have film DOF without the adapter. Because DOF is directly related to the size of the film/sensor. The sensor on the Elphel is 1/2". Using a 35mm lens without the adapter would simply project a 35mm image on a 1/2" screen, making it a huge telephoto lens.
So the only alternative is a bigger sensor. That's something of the future, although they already exist of course (Red, Canon 5D mrkII, Nikon D90 etc.)
We would have to wait for the costs to come down for such sensors... or we have to order a large quantity to get the price down.

EDIT: Interesting sensors are noted here
The Dynamax35 is by far the most promising so far.

I understand about the sensor size, thanks a lot for the info. The best alternative should be that elphel use in the future one of those larger sensors. The Dynamax35 looks really great but I guess it's really expensive. Having these sensor into a working elphel system, and a DNG output format seems like a perfect setup.

Quote:

Originally Posted by Oscar Spier

I guess the costs for the camera are on the Elphel website. You would need a controller PC or mobile device that runs Linux and has an ethernet connection. A cheap EEPC would do, but still a bit big perhaps. But note that everything is still under development.

I've checked their price. A whole system should be around 1000$. Then you need a controller PC and a DOF adapter if you want that kind of look.

Quote:

Originally Posted by Oscar Spier

I don't know yet how the image is compared to other cameras. I'd like to see a test like this with the Elphel one day : Zacuto's Great Camera Shootout! 2008 | Indy Mogul - DIY filmmaking

This shootout is great, it let you see what the different setup looks side by side.

Juan M. M. Fiebelkorn · March 11th, 2009, 10:22 AM

Is there any possibility in a not so distant future of having a more or less simple camera head, maybe Gigabit ethernet, with Internal Dirac Pro (adapted to RAW bayer) compression and some kind of control protocol?

Andrey Filippov · March 11th, 2009, 10:32 PM

Yes, we do plan both. GigE will come first (and USB2, faster CPU and FPGA) - that project is under development right now. After hardware upgrade Dirac is likely too.

Juan M. M. Fiebelkorn · March 11th, 2009, 11:17 PM

Seeing the time frames for this kind of development, I'd rather suggest going directly for USB3, by that time it would be more or less common (1 year ahead I guess).

Anyway if you think I can help just send me an email.I would be glad to receive it :D

February 2nd, 2009, 04:17 PM	#1021
Oscar Spierenburg Major Player Join Date: Jan 2005 Location: (The Netherlands - Belgium) Posts: 735	Small update: I've finished a follow focus system for the 35mm adapter. The follow focus moves the whole lens mount, so you don't need to change anything (accept focus marks) when you change a lens. You can also change the whole lens mount (thanks to Sebastian's idea for the Elphel lens mount) You can see the (big) gear sticking out underneath the focus knob. That was necessary to get subtle focus adjustments. One whole turn is a little more than the whole focus range. (sorry for the bad photos) EDIT: I noticed Sebastian's notes on the wiki Great idea! Attached Thumbnails Last edited by Oscar Spierenburg; February 2nd, 2009 at 06:02 PM.

February 3rd, 2009, 03:36 AM	#1022
Daniel Rudd Major Player Join Date: Aug 2005 Location: North Muskegon, MI Posts: 213	nice work once again, i want to say "nice work" oscar (and others). I wish I could contribute more, but you guys have taken this discussion well out of my league. I understand enough to be impressed. Thanks for innovating. Daniel __________________ Daniel Rudd Digital Storyteller (Sony HDV, Aspect HD) Soundtrack Creation & Royalty Free Music Production www.stock20.com

February 7th, 2009, 01:24 AM	#1023
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Article in LinuxDevices Elphel camera under the hood: from Verilog to PHP

February 11th, 2009, 09:58 AM	#1024
Oscar Spierenburg Major Player Join Date: Jan 2005 Location: (The Netherlands - Belgium) Posts: 735	Sebastian mentioned working on a preset manager for the Elphel control software (camvc) I've got a suggestion to integrate the camvc into the live preview window of the camogmgui ( see the wiki ) Using D-SLR camera's a lot, I've come to the conclusion that: although you can set white balance manually, most of the times you just end up using one of the presets. Symbols like a sun, clouds, light bulb etc. I think when it comes to the Elphel camera interface, such symbols would be sufficient and preferable in real situations. I've attached a quick example of how I think the interface could look like. Other suggestions are welcome ...unless Sebastian turns pale right now :) ... it's his software after all. Attached Thumbnails

February 16th, 2009, 07:47 AM	#1025
Sebastian Pichelhofer Regular Crew Join Date: Jan 2007 Location: Vienna, Austria Posts: 112	With the color temerpature calculation we got quite a thing started. I am afraid the math is not that simple: Planckian locus - Wikipedia, the free encyclopedia Konstantin Kim helped simplifying this a lot, see attachment: the T:= Matrix holds the target color temperatures and the following two matrices the R and B coefficients for a 5500°K initial color temperature. So all we need now is the inital color temperature that the image has when coming directly from the sensor. Andrey suggested to film a known color temperature image and see how the coefficients after autowhitebalance behave to calculate the resulting initial color temperature. Maybe we will soon solve this mystery :) Between I released a new version of the harddisk recording tool camogmgui: Camogmgui - ElphelWiki It now supports simple creation of film like Naming schemes with fields for Scene, Shot, Take, etc. Attached Thumbnails

February 17th, 2009, 12:02 PM	#1026
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Automatic white balance - how it works Sebastian, for calibration using the automatic white balance in the camera you should use some white object. Do you know how that automatic balance works? This balancing assumes that the most bright object in the frame has white color. So it cuts a little on the color histograms. Both fraction of the pixels above the level and the absolute pixel level can be specified in the parameters - if the number of pixels for the brightest color above specified level is smaller than specified, the level is reduced until the number of pixels condition is met. After finding level/fraction pair for the "brightest" color component same number of pixels is cut from the right side (high level) of the histograms for the other color components, and the corresponding levels are measured. Then the gains in the channels are changed accordingly to equalize those "white" levels. The current 8.0 software allows additionally to add tint so the "white" object in the frame will have predefined color different from white (camvc allows that using control sliders). When adjusting gains in the color channels two mechanisms are used (there are user parameters that can impose additional limits). First the analog gain settings of the sensor are used (analog gain is often considered as "ISO" in the digital cameras). But those gain stops are rather far apart (sensor we use has 12.5% steps in some gain range and 25% in the other) so camera uses digital scaling (17 bit multiplication) to "fill" those (12.5-25%) gain gaps. By default the camera uses "theoretical" analog gain values for each gain setting, but it can use a table of measured values so it is possible to write a script that will change analog gain (and simultaneously digital scaling and/or exposure) to calibrate each analog gain actual value.

February 19th, 2009, 05:05 AM	#1027
Sebastian Pichelhofer Regular Crew Join Date: Jan 2007 Location: Vienna, Austria Posts: 112	I will try to get a color temperature meter to make this calibration a real calibration instead of just assuming temperature from a certain light source.

February 22nd, 2009, 11:13 AM	#1028
Sebastian Pichelhofer Regular Crew Join Date: Jan 2007 Location: Vienna, Austria Posts: 112	I made a calibration test shot today. Konstantin please use these values to calculate the original temperature: T = 2810°K R = 148106 / 65536 = 2,259918212890625 G = 131072 / 65536 = 2 B = 288552 / 65536 = 4,4029541015625 What do we do with the GAINGB in this scenario? Attached Thumbnails

March 7th, 2009, 06:14 AM	#1030
Ivan Castell Regular Crew Join Date: May 2003 Location: Zaragoza (Spain) Posts: 33	Hi everyone. I'm really impressed of the quality of this project. I myself, being an indie filmmaker I'll like to make the move and try to build my own digital film camera with DOF hability, but I think that right now building it from the elphel (if you don't have the technicals skills required) it's out of my reach. But anyway, just checking this footage from the 333 model, with a 35mm dof adapter looks fantastic (apart the artifacts at the edges): http://community.elphel.com/videos/RomainFULL.avi Maybe it's an idiot question that has already been rised here, but, it's not possible to have film DOF on this chips without the dof adapter? What's the entry level minimal cost right now to build such a setup? What could be the quality of the image that we can get compared to other cameras? RED, scarlett, hvx + 35mm adapter, etc... Regards. __________________ http://ivancastell.org

March 11th, 2009, 10:22 AM	#1033
Juan M. M. Fiebelkorn Major Player Join Date: Jun 2004 Location: Buenos Aires , Argentina Posts: 444	Is there any possibility in a not so distant future of having a more or less simple camera head, maybe Gigabit ethernet, with Internal Dirac Pro (adapted to RAW bayer) compression and some kind of control protocol?

March 11th, 2009, 10:32 PM	#1034
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Yes, we do plan both. GigE will come first (and USB2, faster CPU and FPGA) - that project is under development right now. After hardware upgrade Dirac is likely too.

March 11th, 2009, 11:17 PM	#1035
Juan M. M. Fiebelkorn Major Player Join Date: Jun 2004 Location: Buenos Aires , Argentina Posts: 444	Seeing the time frames for this kind of development, I'd rather suggest going directly for USB3, by that time it would be more or less common (1 year ahead I guess). Anyway if you think I can help just send me an email.I would be glad to receive it :D