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.

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.

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.

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,

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?

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, what Linux distribution is Spectr working on?

Ubuntu, SuSE 10.2

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.


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.


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 ;)


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.


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.

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

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.

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

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!?

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.

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 :-)

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

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.

I see how all this development will allow better control and storage of camera parameters in the camera, but how would it be possible to control camera parameters from a remote location, change them and restore them in the camera? I can think of some applications where it would be nice to control several cameras from one location and tweak them as necessary to get the best pictures. Cameramen may not always be involved (robotic movements for example) and there may be many cameras all supplying picture to somewhere else.

Andrey, will the new interface for the 353 also work for the 333?

Oscar,

Some features may be ported back, but I would not count on it - 353 has faster CPU and more memory. But we will help you to upgrade the camera to 353.

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).

Would it be possible to create a function where you use a list of exposures during capture? (like in a text file or something)

Example:

I capture at 50fps. All the odd frames having a short exposure and even frames having a long exposure. Even though the odd and even frames will not totally match up, they can still be combined to create streaks of light after objects with high luminosity. (Blend the long exposure frames using "screen" blend onto the short exposure ones, at 30% or something - doesent have to match perfectly) Creatively this could be useful for several things.

There are probably other uses for such a feature that I haven't thought of...but would it be possible to do? (using PHP or something and not at firmware level - too complex for me)

Probably not possible without going deep into the firmware...but had to ask anyways ;)

//O.

EDIT: one obvious use would be HDRI capture...by capturing say 15 or 20 frames with short to long exposure...and then combine them in post.

Have you see the picture from the NAB07 about the red camera!?
amazing ....I wonder how expansive is a sensor like the one of red one...
and the silicon imaging: I think that something really close to it could be made with the elphel.... they introduce a 35mm adapter so for me if they want to preserve the dof of a 35mm lens they have to use a gg adapter (optical solution preserve only field of view) but for that adaptor they wont about 4000$ ...maybe they have found a non gg solution? (fiber optical magnifier??)
so at the end we are working on something like them (optically side)


edit: the silicon imaging is a optical 35mm adapter like this: http://www.cine-one.com/pdf/angenieux_hdconverter.pdf

but for that adaptor they wont about 4000$

Quality adaptors cost money:

http://www.pstechnik.de

With a bad adaptor (like the diy stuff people building here - none of them capable of HD resolution) no matter how good your camera is the picture will be ruined and you lose a lot of light too - you don't even need a lossless codec if the input is bad. My opinion is that DOF doesn't worth this.

Unfortunately it's really hard to find good industrial lenses (quality 16mm primes like Angenieux don't have HD resolution) which have the needed focal range/angle of view that can be used under normal circumstances. After a long search I decided to use Computar H2Z0414C-MP which has a zoom range covering most of a filmmaker's needs and its pixel count is sufficient for the new Micron sensor the 353 uses. You can find specs here, along with other lenses as well:

http://www.rmassa.com/manu/computar.htm


Zsolt

I guess it all depends on what you are trying to achieve.

In my case, I am going to build a gg solution simply to be able to use my canon lenses...not necessarily to get DOF. (to get access to extreme macros etc)

When it comes to quality...to me - if it works for the end use - it works.
..things can always be better - but the important thing is...does it work??

There are people doing feature film on DV (!!) and acclaimed filmmakers too...so I think the real question that needs to be asked is really what we want to do and then take it from there :)

I will be very curious to see the results of your new lens! Please post a few shots when you have it??

thanks

//O.

exactly the same lens I was looking at! (but to use in an dof adapter)
...for the adapter I'm not of the same idea.
a cinema picture need some spec to be recognized;
aspect ratio and dof are the more important I think
without that you'll have a very good and sharp picture that a viewer recognize like a news or something else but not cinema!
a cinema picture is a cinema picture also in a ipod video screen!
so if you want a cinema camera on the cheap you need an adaptor
and if you use good quality part you'll achieve a good compromise
...try to take a picture from daniel and scale down to 1280 and sharp it a bit...
(big sensor are too expansive now)

exactly the same lens I was looking at! (but to use in an dof adapter)

Zoom lenses have lower image quality. In an adapter you should use a fixed one I think.


a cinema picture need some spec to be recognized;
aspect ratio and dof are the more important I think
without that you'll have a very good and sharp picture that a viewer recognize like a news or something else but not cinema!

Exactly. It all depends on what we call cinema. For me, cinema means theatrical projection of a film. If you have a higher budget then you can rent real HD cameras but if you have a lower budget then your film won't make it to the theaters, unregardless of the camera being used. I see the advantage of the Elphel when doing high quality TV or DVD films and this audience is not so concerned about DOF as some cinephiles are. Film grain effect can be applied in post if needed and gamma also can be varied if we're working with raw input. I'm into the Elphel because I don't have the money to buy/long-term-rent even a DVX100 - it's clear that a shallow DOF won't help my films to reach a wider audience because on this level other things count more. The Elphel has a huge price/performance potential but the performance alone won't beat the big guys like Red, not even SI.

Talking about resolution: most lenses give their best performance around f4.5. If you have an adaptor then you have two lenses with f4.5 plus the GG with f0.5 that's around f9 meaning you need a lot of light, not counting the fact that cmos sensors have a lower sensitivity than the usual daylight film stock has. If you open these lenses wide (f1.4 for example) to gain some light, you lose resolution again, plus you get some beautiful chromatic abberations as well. Remember the pictures made by the now-legendary Drake camera? They were working with super-fast lenses open as f0.9 and still got some underexposed images even though they've had a better sensor than the Microns.


Zsolt

agree with you for the cheap of the camera (also to me the dvx 100 is expansive ) but I love the picture produced by a dof adapter ...look like a 16mm movie for softness ..thats my opinion
let's see how good will be the 5mp sensor in low light condition!

As roguebug suggested on our IRC channel (http://www3.elphel.com/irc -> http://irc.elphel.com/irclogs/elphel.2007-04-13.log.html) we tried 3MPix sensor and it seems to work fine with 353. So now we have both 5 and 3 MPix (and I'm getting the first images from 11 MPix KAI-11002 - 10342/10347)

cool news :-)
3mpx sensor I think it is better for low light!
any news about the rolling shutter issue comparing 3mpx to the 5mpx sensor?
on the camera that you gave me the link (pointed at a freeway) is evident infact tir or car are distorted about 60° left (higher distorsion for high speed)
to achieve a 2:1 aspect ratio did you think is better, to avoid the problem, roteate the camera 90°(left or right)?

...and I'm getting the first images from 11 MPix KAI-11002 - 10342/10347

Here it is: http://wiki.elphel.com/index.php?title=353

cool news :-)
3mpx sensor I think it is better for low light!
any news about the rolling shutter issue comparing 3mpx to the 5mpx sensor?
on the camera that you gave me the link (pointed at a freeway) is evident infact tir or car are distorted about 60° left (higher distorsion for high speed)
to achieve a 2:1 aspect ratio did you think is better, to avoid the problem, roteate the camera 90°(left or right)?

Matteo, can you post a sample with distortion? You may upload it to our wiki (ignoring image size warning if any)

of course! but there is something like a tent that block the window view!

of course! but there is something like a tent that block the window view!

Camera was just accidentally turned and looked to the wall instead of the street - fixed :-)

done! it is in the wiki

This problem reguard also the red digital camera (look at the Peter Jackson footage promo http://www.reduser.net/forum/showthread.php?t=1883) ....it use a rolling shutter sensor as the elphel 3 and 5 mpx Micron sensor :-)
the solution is ....slow pan and slow tilt ...that is how a movie have to be done

look what I've found! maybe it will be interesting for the future :-)
http://larc.ee.nthu.edu.tw/~syhuang/paper.ps/sensor.TCE.2005.pdf

Logarithmic CMOS sensors are not new, but so far their sensitivity was rather poor

I did post one that had starlight filming ability, and their was that other security camera sensor that reached down to low levels, though I don't think logarithmic, any possibilities we will see these?

I read the article, didn't a couple of us from the digital cinema threads talk with you about using the camera in 03 or 04?

I am glad to hear that you are giving the camera computer autonomy potential, I am wondering how you are going to do the external display/viewing (hardware port, or low res downsized compressed image extracted from the main video stream)?

looking at the micron cmos specification I've seen that
3mpx MT9T001P12STC sensor have 48 MHz Master Clock
http://www.micron.com/products/partdetail?part=MT9T001P12STC

5mpx MT9P001I12STC sensor have 96 MHz Master Clock
http://www.micron.com/products/partdetail?part=MT9P001I12STC

does it mean that for the 5mpx the rolling shutter distorsion is more ore less 1/2 than the 3mpx sensor???

For the same number of pixels - yes, but less than twice as the relatively more extra time is needed for each line

Well, with talk of Red Mini, HV20, JVC single chip professional, XDCAM EX pocket cams, how long till the Elphel 353, and the other compression codecs and video cam projects, Andrey?

Thanks.

First 353 camera went to South Africa today :-)

cool how much does it cost 353 5mpx version? + ide board?

I'm interested in buying a 353 too.

cool how much does it cost 353 5mpx version? + ide board?

Matteo, IDE board is not tested yet, I'm working now on 363 version with large sensors, will get to IDE after the LinuxTag (sometime in June). Currently we have only 10353+10338 with the software just basically ported from the 333 (some bug fixed during that process too)

Hi all!

Andrey, when you get to do the IDE in June...will you also make a housing that fits the IDE drive? I do know you have a lot on your mind, just curious to know if you think it might happen June/July or something?

I definitely want to buy a 353 once a drive can be fitted within the camera and you can capture video with just the 353 in stand-alone mode!

If it takes awhile before that happens - no problem - I have patience :)

//O.

EDIT:
Oh and congratulations on your first 353 shipped!!! :)

So, what can the 353 do at the moment, can it do anything more than the 333, in Cinema camera terms?

When can we expect various cinema camera projects to come through?


Thanks

Wayne.

So, what can the 353 do at the moment, can it do anything more than the 333, in Cinema camera terms?

When can we expect various cinema camera projects to come through?


Thanks

Wayne.


Wayne, I hoped I described it in the LinuxDevices article (http://dvinfo.net/conf/showpost.php?p=658462&postcount=610) :-)

Right now it can do basically the same as 333 (JPEG/MJPEG branch) - our first goal was to switch to the new hardware. I will work on porting (and updating) Ogg Theora in late summer - now I'm busy with high res/slower CCD variant (363). There are several benefits for cinema projects - camera is faster, we have USB port connected (audio) as well as IDE for hard drives. We do not have either of them already running but I'm sure we will.

Other thing - software. I'm starting this migration with CCD (363) version, but it will be come to the video (353) camera too - PHP control of the camera (i2c communication with the senor is already possible from the PHP code). Why is that important - see http://linuxdevices.com/articles/AT4415936647.html

hi andrey I've seen on the micron page this cmos sensor
http://www.micron.com/products/cmos/highspeed/partlist
http://download.micron.com/pdf/datasheets/imaging/mt9m413c36stc.pdf
for our hd camera project will be perfect
no rolling shutter problem because have truesnap micron tecnology
big enough to use 35 mm lens (so we have no need for a 35mm adaptor)
and big pixel for good low light shooting ....will be a must!
and not only for hd cinema
you can enter in fast camera market http://automotive.micronblogs.com/2006/11/truesnap_global.html

(maybe in the future they will produce a 35mm equivalent 1920 x1080p for the cheap...I'm dreaming)


Features/Top Level Specifications
• Array Format: 1,280H x 1,024 V (1,310,720 pixels)
• Pixel Size and Type: 12.0μm x 12.0μm TrueSNAP
(shuttered-node active pixel)
• Sensor Imaging Area: H: 15.36mm, V: 12.29mm,
Diagonal: 19.67mm
• Frame Rate: 0–500+ fps @ (1,280 x 1,024), >10,000
fps with partial scan, [e.g. 0–4000 fps @ (1,280 x 128)]
• Output Data Rate: 660 Mbs (master clock 66 MHz,
~500 fps)

maybe you already know
but ILM industial light and magic have developed :

"OpenEXR is a high dynamic-range (HDR) image file format developed by Industrial Light & Magic for use in computer imaging applications.

OpenEXR is used by ILM on all motion pictures currently in production. The first movies to employ OpenEXR were Harry Potter and the Sorcerers Stone, Men in Black II, Gangs of New York, and Signs. Since then, OpenEXR has become ILM's main image file format. "

http://www.openexr.com/index.html

and blender (the 3d model renderer for linux-win- mac- bsd.....) support it

hi andrey I've seen on the micron page this cmos sensor
http://www.micron.com/products/cmos/highspeed/partlist
http://download.micron.com/pdf/datasheets/imaging/mt9m413c36stc.pdf
for our hd camera project will be perfect
no rolling shutter problem because have truesnap micron tecnology
big enough to use 35 mm lens (so we have no need for a 35mm adaptor)
and big pixel for good low light shooting ....will be a must!
Matteo, I know about this sensor, but there are several "but":
1 - it has 10 parallel 10-bit outputs, not just one
2 - it is much faster than even 10353 can handle
3 - that sensor is 100x price of the small ones
4 - Sensor is rather old, and I know Micron was improving sensor technology really fast. So I'm not sure that big pixels really "work" proportionally to their area 3-5-8 MPix sensors may have higher relative sensitivity.

So (for special applications) it is really easy to build a fast camera with that sensor - just connect 10 of the 10353 boards and a Gigabit switch - after it there will be a single cable to a computer that can record the 500 fps video.

100x wow so more than 2000$!!!!
crazy

Isn't that sensor available fro around $700US?

Andrey, good idea, high speed cameras are very expensive, and I think a few people came here with cameras for less than $10K, But your plan might lead to an high speed camera for less than $5K, which some around here would be very interested in.

How is the QE and fill factor of that chip now, it was very poor before. How, does it compare to the one from Fillfactory?

About the 353, the hardware is available, but Cinema improvements have not yet been implemented (there are many sub projects going on here, like Bayer codec compression, with unknown separate time schedules).