High Definition with Elphel model 333 camera

Odd Nydren · April 8th, 2007, 02:14 PM

Hi all!

Andrey, any news on the progress of the 353?
Really curious...so I had to ask :)

I look forward to your 333 article - please post a link here when it's released!!

//O.

Andrey Filippov · April 8th, 2007, 02:22 PM

Odd, that was a typo of course - I meant the 353/363, not the 333. So I edited that post.
We have some small quantity of 10353 boards factory-built as well as the 5MPix sensor boards. Later this month we'll get more
And - we got video stream from the 353, but autoexposure/white balance is not ported yet (will be soon) - by the end of the month we'll be able to replace 333 with 353.

Odd Nydren · April 8th, 2007, 02:48 PM

Ah great news...thanks for the update Andrey!

Regarding the latest posts in this thread:
I believe that the harddrive & standalone operation is what will make this camera truly stand out from the crowd!

Open source, PHP, USB and add on boards is outstanding (!!)...but I think most (low budget film maker) people don't appreciate those features at first. The stand alone operation will be the thing that "wake people up".

I think there is too much talk about sensors and way too little talk about usability. The open source features makes it possible to make the camera really useful (adaptable to whatever you need)...but it will not shine until you can use the camera as-is...without a laptop and other bulky gear. This is where the 353 really shines.

Thanks for your hard work Andrey!

//O.

Andrey Filippov · April 8th, 2007, 03:10 PM

Odd, we do not have resources and experience to create consumer-ready DV cameras. But I hope we can provide some building blocks that could be used to create DIY systems that could compete with the ones built by the big companies.

Innovation is not limited to the "industry leaders" and with appropriate components it is possible to implement something really new.

But that is not possible (or is very difficult) without open designs - I hate to watch how creativity of developers is spent on installing alternative (often - much better - see OpenWRT) software without any cooperation (often having to bypass active resistance) of the hardware vendors.

We also can not count on all DIY-ers to be software gurus - and here the effective execution of PHP scripts in the camera (and PHP interface to internal resources) is very important - much more people can write and troubleshoot a custom PHP script than to add/modify drivers in the camera.

Oscar Spierenburg · April 8th, 2007, 05:32 PM

Quote:

Originally Posted by Andrey Filippov

Oscar,

Spectr (at our company dot com) is working on it. There are several issues to be resolved.

Andrey, what Linux distribution is Spectr working on?

Quote:

Originally Posted by Andrey Filippov

First - you need a customized version of MPlayer and live555 library - they do not support the big frames we need. And there is also a fundamental problem with RTP for MJPEG - RTP header information limits frame width to 2047 pixels (with our hack 0 is treated as 2048). RTSP allows virtually any frame width (while frame data itself is still sent over RTP.

For film making, normally we only need the (+/-)1600x900 frame size.

Andrey Filippov · April 8th, 2007, 09:23 PM

Quote:

Originally Posted by Oscar Spier

Andrey, what Linux distribution is Spectr working on?

Ubuntu, SuSE 10.2

Odd Nydren · April 10th, 2007, 02:47 AM

Quote:

Originally Posted by Andrey Filippov

Odd, we do not have resources and experience to create consumer-ready DV cameras.

Well...I believe most - if not all - the people on this forum already discarded the idea of using a consumer-ready camera :) for obvious reasons.

Quote:

Originally Posted by Andrey Filippov

But I hope we can provide some building blocks that could be used to create DIY systems that could compete with the ones built by the big companies.

yes you definitely provide a great DIY solution! More so than any other company I've seen so far.

Quote:

Originally Posted by Andrey Filippov

Innovation is not limited to the "industry leaders" and with appropriate components it is possible to implement something really new.

In other words: Exciting times ;)

Quote:

Originally Posted by Andrey Filippov

But that is not possible (or is very difficult) without open designs - I hate to watch how creativity of developers is spent on installing alternative (often - much better - see OpenWRT) software without any cooperation (often having to bypass active resistance) of the hardware vendors.

Very true.

Open design not only makes it possible to extend a device or a system...it also fosters a mindset where sharing is a natural part of development. The way it really should be. To me it's pleasure not only to having created something, and use it...but also being able to give it away and see others take it further.

Control (corporate and other) has never fostered real creativity. That most real innovation today is being done by small companies is proof enough.

Quote:

Originally Posted by Andrey Filippov

We also can not count on all DIY-ers to be software gurus - and here the effective execution of PHP scripts in the camera (and PHP interface to internal resources) is very important - much more people can write and troubleshoot a custom PHP script than to add/modify drivers in the camera.

Very true.
My point was just that I think stand alone operation will make people curious about this camera...the open source will make them use it.

Im so looking forward to staring to work with the 353 :) - please keep us posted on progress!!

Thanks!!

//O.

Serge Victorovich · April 10th, 2007, 03:28 AM

If anyone interested in a small, but powerfull DIY dvr please look at this:
http://www.ampro.com/company/News/04...OM_Express.htm

Andrey Filippov · April 10th, 2007, 03:37 PM

Spectr noticed today what seems to be a bug in 3MPix sensor (not present in 1.3MPix and 5MPix) ones. No bug fix is available yet, we'll see what we can do (theoretically it is possible to synchronize new exposure setting with the start of the frame).

It seems that the sensor restarts the frame when the exposure is changed and so the frame rate is not constant even when the exposure is lower than the frame period. When autoexposure is turned on, the exposure change happens often.

Andrey Filippov · April 11th, 2007, 02:10 PM

Quote:

Originally Posted by Odd Nydren

Hi all!

I look forward to your 333 article - please post a link here when it's released!!

//O.

http://linuxdevices.com/articles/AT4415936647.html

Matteo Pozzi · April 12th, 2007, 03:04 AM

good article Andrey it clarify me a lot! so correct me if I'm wrong; you said that the new 353 work with fastCgi and use a 2mb binary to run php instruction that run shell-script that control the camera parameter ...so, for develop a web interface I have to make buttons and link them directly to those php instruction, is that right?! if so is very easy to make a custom gui ...many thanks for it! did you intend to make a tutorial or a list of that php instruction!?

Odd Nydren · April 12th, 2007, 04:01 AM

Thanks for the link Andrey - very good article!!
I agree with matteo, it clarified a lot for me as well.

Quick question - if I create a php page and some graphics and upload it to the camera (like a camera gui), would it be easy to I set it up so that it will keep that info even if powered down and so that when I point a browser to the camera IP, i automatically serves the PHP page I made?

..also - any idea when a 353 with space for a harddrive + firmware that can write a video stream to disk will be available for purchase? Still below 900usd?

oh and sorry for the pressure we put on you, its just a bit tough to be calm when getting excited about your work, the 353 and all :) ...sorry about that!!

thanks

//O.

Andrey Filippov · April 12th, 2007, 08:16 AM

As I wrote in the article - with PHP I just started, made sure it works but currently most parameters are still controlled by ioctl functions. So it will take some time before we'll migrate everything to the new interface (I started with i2c communication with sensor registers and the new boards - 10359, 10347).

PHP is primarily designed to generate HTML pages, but it can be used for other scripting too - a good candidate for the redesign is a webcam scrtipt - it periodically uploads images to the remote server) - current shell script is rather difficult to read/modify.

Of course it is possible to save files that will remain after camera is re-powered - in the camera there is a JFFS2 filesystem for that - it uses flash memory. It is available in all the cameras, starting from model 303, in 333 it is, for example, /usr/html (visible through http as root) - if you change files there, they will remain. (/usr/local/bin is also in JFFS2).

In the 353 flash memory is 128MB - system uses just a small fraction of it.

Pricewise - yes, it should remain about that. I also think, as the community here is rather established, to provide certain number of cameras free of charge (3-5 a year) to be distributed for the benefit of your project. Maybe you can think of some way of implementing it to make sure the hardware will not be wasted and lay idle covered with dust somewhere :-)

Matteo Pozzi · April 12th, 2007, 09:08 AM

many thanks for that! when you have time, are you able to tell us what PHP-friendly fread() and fwrite() functions are already implemented and how can I use that (an example)!? I'm trying to understand how the javascript web page dialogue with the camera parameters, in my free time, to customize the graphic interface but I found it very difficult. The only simple thing I can do is to change some preset like pixel height and width! If we could access directly to the parameters ...web button ->http parameter link->camera hw reaction ...it will be a joke :-) many thanks also for your availability

Andrey Filippov · April 12th, 2007, 09:27 AM

Matteo,

right now it is only possible to read/write sensor registers with fread/fwrite and I will post some how-to when more will be ready (I'm still changing the interface). To make the php scripts efficient (fast) we need many different low-level accesses to be implemented - it is like in php itself - to make fast scripts you really need to use many of the different functions it has, even if you can usually write everything yourself in the php code. Embedded functions execute much faster, and having a real challenge of video, will also try to provide various "building blocks" for efficient code.

April 8th, 2007, 02:14 PM	#601
Odd Nydren Regular Crew Join Date: Jan 2007 Location: London, UK Posts: 88	353... Hi all! Andrey, any news on the progress of the 353? Really curious...so I had to ask :) I look forward to your 333 article - please post a link here when it's released!! //O.

April 8th, 2007, 02:48 PM	#603
Odd Nydren Regular Crew Join Date: Jan 2007 Location: London, UK Posts: 88	353... Ah great news...thanks for the update Andrey! Regarding the latest posts in this thread: I believe that the harddrive & standalone operation is what will make this camera truly stand out from the crowd! Open source, PHP, USB and add on boards is outstanding (!!)...but I think most (low budget film maker) people don't appreciate those features at first. The stand alone operation will be the thing that "wake people up". I think there is too much talk about sensors and way too little talk about usability. The open source features makes it possible to make the camera really useful (adaptable to whatever you need)...but it will not shine until you can use the camera as-is...without a laptop and other bulky gear. This is where the 353 really shines. Thanks for your hard work Andrey! //O. Last edited by Odd Nydren; April 8th, 2007 at 03:44 PM.

April 10th, 2007, 03:37 PM	#609
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Bug in 3MPix sensor? Spectr noticed today what seems to be a bug in 3MPix sensor (not present in 1.3MPix and 5MPix) ones. No bug fix is available yet, we'll see what we can do (theoretically it is possible to synchronize new exposure setting with the start of the frame). It seems that the sensor restarts the frame when the exposure is changed and so the frame rate is not constant even when the exposure is lower than the frame period. When autoexposure is turned on, the exposure change happens often.

April 12th, 2007, 04:01 AM	#612
Odd Nydren Regular Crew Join Date: Jan 2007 Location: London, UK Posts: 88	The article... Thanks for the link Andrey - very good article!! I agree with matteo, it clarified a lot for me as well. Quick question - if I create a php page and some graphics and upload it to the camera (like a camera gui), would it be easy to I set it up so that it will keep that info even if powered down and so that when I point a browser to the camera IP, i automatically serves the PHP page I made? ..also - any idea when a 353 with space for a harddrive + firmware that can write a video stream to disk will be available for purchase? Still below 900usd? oh and sorry for the pressure we put on you, its just a bit tough to be calm when getting excited about your work, the 353 and all :) ...sorry about that!! thanks //O.

April 8th, 2007, 02:22 PM	#602
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Odd, that was a typo of course - I meant the 353/363, not the 333. So I edited that post. We have some small quantity of 10353 boards factory-built as well as the 5MPix sensor boards. Later this month we'll get more And - we got video stream from the 353, but autoexposure/white balance is not ported yet (will be soon) - by the end of the month we'll be able to replace 333 with 353.

April 8th, 2007, 03:10 PM	#604
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Odd, we do not have resources and experience to create consumer-ready DV cameras. But I hope we can provide some building blocks that could be used to create DIY systems that could compete with the ones built by the big companies. Innovation is not limited to the "industry leaders" and with appropriate components it is possible to implement something really new. But that is not possible (or is very difficult) without open designs - I hate to watch how creativity of developers is spent on installing alternative (often - much better - see OpenWRT) software without any cooperation (often having to bypass active resistance) of the hardware vendors. We also can not count on all DIY-ers to be software gurus - and here the effective execution of PHP scripts in the camera (and PHP interface to internal resources) is very important - much more people can write and troubleshoot a custom PHP script than to add/modify drivers in the camera.

April 10th, 2007, 03:28 AM	#608
Serge Victorovich Major Player Join Date: Oct 2005 Posts: 376	If anyone interested in a small, but powerfull DIY dvr please look at this: http://www.ampro.com/company/News/04...OM_Express.htm

April 12th, 2007, 03:04 AM	#611
Matteo Pozzi Regular Crew Join Date: Jul 2005 Location: Milan, Italy Posts: 169	good article Andrey it clarify me a lot! so correct me if I'm wrong; you said that the new 353 work with fastCgi and use a 2mb binary to run php instruction that run shell-script that control the camera parameter ...so, for develop a web interface I have to make buttons and link them directly to those php instruction, is that right?! if so is very easy to make a custom gui ...many thanks for it! did you intend to make a tutorial or a list of that php instruction!?

April 12th, 2007, 08:16 AM	#613
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	As I wrote in the article - with PHP I just started, made sure it works but currently most parameters are still controlled by ioctl functions. So it will take some time before we'll migrate everything to the new interface (I started with i2c communication with sensor registers and the new boards - 10359, 10347). PHP is primarily designed to generate HTML pages, but it can be used for other scripting too - a good candidate for the redesign is a webcam scrtipt - it periodically uploads images to the remote server) - current shell script is rather difficult to read/modify. Of course it is possible to save files that will remain after camera is re-powered - in the camera there is a JFFS2 filesystem for that - it uses flash memory. It is available in all the cameras, starting from model 303, in 333 it is, for example, /usr/html (visible through http as root) - if you change files there, they will remain. (/usr/local/bin is also in JFFS2). In the 353 flash memory is 128MB - system uses just a small fraction of it. Pricewise - yes, it should remain about that. I also think, as the community here is rather established, to provide certain number of cameras free of charge (3-5 a year) to be distributed for the benefit of your project. Maybe you can think of some way of implementing it to make sure the hardware will not be wasted and lay idle covered with dust somewhere :-)

April 12th, 2007, 09:08 AM	#614
Matteo Pozzi Regular Crew Join Date: Jul 2005 Location: Milan, Italy Posts: 169	many thanks for that! when you have time, are you able to tell us what PHP-friendly fread() and fwrite() functions are already implemented and how can I use that (an example)!? I'm trying to understand how the javascript web page dialogue with the camera parameters, in my free time, to customize the graphic interface but I found it very difficult. The only simple thing I can do is to change some preset like pixel height and width! If we could access directly to the parameters ...web button ->http parameter link->camera hw reaction ...it will be a joke :-) many thanks also for your availability

April 12th, 2007, 09:27 AM	#615
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Matteo, right now it is only possible to read/write sensor registers with fread/fwrite and I will post some how-to when more will be ready (I'm still changing the interface). To make the php scripts efficient (fast) we need many different low-level accesses to be implemented - it is like in php itself - to make fast scripts you really need to use many of the different functions it has, even if you can usually write everything yourself in the php code. Embedded functions execute much faster, and having a real challenge of video, will also try to provide various "building blocks" for efficient code.