Ok.Not trying to sound aggresive but I feel that we got lost in translations.
Most of the explanations I wrote seem to not function at all.If you can please read again my post above.

Second try:

You said

"I'm not sure about that. The ITX boards have a fairly limited CPU performace compared to the desktop ones and if you push huge data in through the PCI bus although you have the chance to record it without involving the CPU but if you want a real-time viewfinder image then you must do a lot of computations on the fly. If you're going HD then you might find the ITX boards too weak. Have you got any test results so far? "

In reply to this

"we can send from the camera head two streams (if necessary) one is the full resolution compressed bayer and the other one could be a quarter resolution 8 bit per color channel image which wouldn't need debayering and could also be lightly compressed so to be sent to viewfinder."

My question is, where are those X86 computations you mention applied?

The second quarter resolution 8 bit per color channel slightly compressed stream is supposed to come from the camera head and doesn't need demosaicing because it already has one color sample per pixel.The only computation if any would be decompressing it.You could even send a 4:1:1 or 4:2:0 stream instead.The conversion to RGB will be performed inside de GPU (Graphics Processing Unit).Also scaling.

(SI at the begining said that they needed a Geforce FX just to display a crappy 1024x768 2D video)

If a 1 GHZ NanoITX can decode Mpeg2, why not decompressing something a lot way simpler?

(SI's camera, as I said before, needs a Pentium-M because of the wavelet based Cineform codec which is really heavy, not because of problems for displaying the incoming video stream.)

On another side 99.9 % of people don't know how to design a PCB or code an FPGA (VHDL or Verilog whatever you like).I'm within that number.I don't even know how to code in C.Don't know how to perform operations at the bit level and can't even implement a huffman table.What I did was just some internal testing to check image quality and compression ratio.

There are enough examples for things not working because of lack of a suitable platform for coders to work with, and I have the fear that this one, at least within the Video camcorder area, could become one of them.

Nano-ITX

http://www.via.com.tw/en/products/ma...erboard_id=361

http://www.digit-life.com/articles2/...ia-epia-n.html

Mini-ITX

http://www.via.com.tw/en/products/ma...erboard_id=450

Final Note: MS Windows is a no go for this system.

See you.

Whoops, my bad. It seems like I accidentally deleted this part when replying so it got left out. Answering to this topic: I'd be glad if we could send two streams from the camera head. After a quick review of the 333's fpga architecture I came to think that we can't but we need Andrey's answer on this because I'm still not sure what modifications are needed to achieve this.

Agreed...


Zsolt

Hmm, exactly like what I was suggesting back at the start of the digital cinema camera projects. I was against the increased complexity for doing FPGA and custom camera for the first cameras (due to complexity) but also suggested using the Elphel back then because it already was designed. Unfortunately, it turned out that doing machine vision software modification for live recording was actually an relatively simple thing, according to people from machine vision companies that now have software versions to do that, that I talked to in the last year or so. The only people that listened to me, and asked for my advice, went on to actually make commercial cameras.

I think you should all get together, in a spirit of open source, and brotherly love, and make as many codecs versions as you like, and the camera work of course?

I forgot, the Elphel really needs better sensors then the previous Microns, this is the one biggest problem. While we can jazz the color up, even normal cmos HDV cameras are starting to produce latitude and low noise. With an better sensor, they can maintain an edge over HDMI capture solutions on cheap cameras, the problem is that this is just infeasible. The solution would be a much more expensive sensor board for indie people using the best of the second class solutions (even the special Ibis implementation as implemented on the Drake). In reality, I have only come across a few sensor technologies that lead for the price. FF and Kodak are the old ones, Foveon, and another that I posted here before, with 170db latitude and super super sensitivity (name slips me). Any others I can't remember.

I have talked with Andrey before about the possibility of using the Elphel unit as an encode/capture device for other cameras. I think, as far as Andrey is concerned, if you want to do it, then you are welcome to. To it's natural conclusion, if the camera was designed to take, apart from just component/HDMI, USB/FIREWIRE/GIGE/Machine-vision, then it could replace a computer for acquisition from other box cameras.

Juan is right . . . for "quadlet" based demosaic, you don't need a powerful graphics chipset . . . we've been able to-do it on any of the modern Intel embedded chipsets such as the GMA900 and 950. Quadlet is REALLY easy since you're just either averaging or picking one of the green bayer channels, and then combinding that with a R and B channel to make a RGB pixel . . . the resolution is a quarter of the HD full-resolution version, but it's VERY fast to-do.

You'll have issues on a 855GME based system because of the way it was constructed with minimum memory bandwidth and the north-bridge/southbridge interlinks, but the 915 and 945 chipsets will work just fine for ingest and display of HD quadlet data in real-time.

With the Core 2 Duo, Mini-ITX boards can be VERY fast. And if you're not requiring CineForm compression or something of the equivalent, then using one of the LV versions of those chips (so only 10-15W max TDP) would seem like a pretty no-brainer solution as it could be passively cooled (no fan required, just a really big heat-sink) and easily battery powered.

What's with the Drake nowdays? Are they still in business? If they aren't then we might just ask them to provide us with the design of that sensor board and attach it to the Elphel...

Zsolt

for me the images of the elphel 333 look better then the drake ....but this is my opinion

Well, back. I have discovered a new CCTV sensor promising 2000 times more low light sensitivity and an color hi-res version:

http://www.marketwire.com/mw/release...ease_id=198786

Good news, there are more options now.

I don't know, Rai has never told me (like nobody ever has mentioned what happened to the Sumix camera, which was a very good opportunity for them). The Drake was an very good opportunity, but unfortunately it would need to price against the Red/Silicon, which means higher resolution or lower price. I take it that the Drake is gone. Wherever you and can pry the sensor broad design from anybodies dead hands is another thing. But even though it had an descent well capacity and SN (through the external circuit) and good latitude, it would be good to look at alternatives too. It would be interesting if Cirrus re-targeted the FF Ibis chip towards higher quality or lower price.

I am now of the mind that 50/60fps and an pocket camera would also be useful for portable production, on the video side, along side a full digital cinema type camera. Unless you can spend the time to do cinematic style shooting (to reduce judder in moving objects) the smaller size and higher frame rate matters.

More news on that sensor. it appears that it uses an quantum effect to move thousands of electrons for each photon. I mentioned other research that got two electrons moved by one photon, an number of years ago, now it looks like QE efficiency ratings just went out of the window.

http://www.pcmag.com/article2/0,1895,1908418,00.asp

I've also seen this info 2 weeks ago but I've found no images produced by this sensor and no spec info about. L'et's look on it

Wow, I guess I managed to read the whole thread! This project seems truly interesting.

What I was wondering is when the 353 arrives, it most likely will have support for a HDD. And you could use something like a Nokia 770 to control it. But how are you going to monitor the video? Through the Nokia monitor? Has it got enough resolution to adequately pull focus and such? It is after all HD. Or would it be possible to add an additional monitor? Or would a UMPC be the best solution if it has a high res screen?

I always forgot that with the new Micron sensor we can go up to 60fps which is around the minimum if we want to avoid the use of a mechanical shutter. I think fps is the first criteria to choose by and only then we can take a look at other parameters. (And its resolution is also really good for the Elphel because it's around the limit we might compress and record with the camera.)

Btw, about this new sensor they write:
This can mean that it won't work when the light level is higher than that threshold.

Zsolt

Made a GUI idea designed for touchscreen purposes. Wanted the GUI too look simpler and not as "frightening" as the current display, and also less industrial.

It´s just a quick sketch but any suggestions on improvement? Am I heading in the right direction?

Nikos, do you mean to design this for the Elphel? I own the 333 and I'm really looking forward to a more simple setup/control panel, dedicated to film making.
Maybe something that also implements audio recording.

Hi oscar have you got some screengrab to show us what is possible to do with the elphel 333+35mm adapter? I want to make the project too but for now I'm waiting for the 353... I don't know much of programming but I'm trying to understand how the "ajax-html" control panel of the elphel work so that I "can" change the gui but now I've so little time to spend
nice to see so many people looking at this project!

Yes, it would be for the Eplhel, dedicated to filmmaking as you say. Although I do not have the skills to program the interface, I would like to come up with ideas that maybe someone else can implement.

Since you own and use the 333, please come up with suggestions on which main buttons that should be in the interface if you have any.

Also, like Matteo asked, I would love to see some pics shot with the 333 with the adapter.

Matteo, I'll climb on the roof and shoot something.... (and I don't mean pigeons)

Nikos, that's great.. I'll write down what buttons I use when I shoot a clip.

This is perfect. I know its hard to do, but its good guide how to do it.
http://www.siliconimaging.com/Digita...Interface.html
Only thing I will add is disk free space indicator all the time on screen.

I think is on this Touchscreen LCD:
http://www.cappuccinopc.com/parts/mr-xe-700y.asp

the silicon imaging gui is the best one I said that on this thread long time ago :-)
for the lcd the best one is one from Lilliput (http://www.lilliputweb.net/product8.html) I've made a projector based on one of this to watch dvd on the wall and work awesome and is not so expansive! you can find one new on ebay at about 230$

I agree the SI gui is great but I dind´t think it would be possible to code something like that i Ajax with overlays and all. or is it?

353/333 interface dont have to be so fancy, all that matters is functionality and this is the way how. I wish SI sell their software at lower price and without cineform suff and compatible with couple of machine vision cameras so we can have a chioce to choose a camera on our budget and resolution.

http://ubuntustudio.org/
maybe is arrive the time to switch to linux

When I put all my equipment on the roof and set up the elphel software, a dark cloud stopped by and it began to rain very badly...

I shot some low light tests indoors, but I forgot to crank up the JPEG quality (standard at 70 %) That's the reason for the large compression artifacts.
Besides that, you can see the result of my 35mm wax adaptor and the Elphel 333.

http://s09.picshome.com/d35/comp_1__0-00-08-04_.jpg
http://s09.picshome.com/d35/comp_1__0-00-30-00_.jpg


I'll write more about the software/control panel later when I have more time.

good result Oscar I've tried to resize the picture to 1280x720 and they look much sharper than the result of a hdv camera with 35mm adapter cool!
one question; you said that thay are low light test indoors ....but how much low light!? are you able to tell more about the light setup!?
and last ....are you able to shot a test in complitely night with the light of only a wax candle at a distance of about 1 meter with a 50mm lens so that is possible to compare with some other setup?
many thanks Matteo Pozzi

Matteo, I used one 150W light.
I'll write more when I have more time. I don't have the camera with me the comming three days.

Control Panel
 

Nikos, here are some thoughts on the software.

Most of the time you spent before actual filming is setting up all basic settings to 'default' film. Default would be i.m.o. - 24fps, shutter at max 30, 900x1600 pixels, JPEG quality to at least 80%, streamer to kuklin-rtsp at 24FPS.

I think everyone who wants to use the camera for film making, would want these settings set up as default.
This would also mean that you don't need these settings on the 'main page' anymore.

The only buttons you need are:

-exposure control (auto and manual)

-White balance (which can be automatic while pointing at a white object or something and an option to press 'hold' so it won't change while filming.)

-Brightness, contrast and gain

-color/BW (or color saturation)

-STEAMER ON/OFF (very important)

-REC (somehow I can't use the rec button on the AJAX panel so I use some button called stream.sdp. (maybe Andrey knows more about this)


I think that's it. It would be nice to have big buttons because of the clumsy touchpad on most laptops.
Nikos, you say ' for touchscreen purposes', but I hope -not only- for touchscreen?

(edit)For those who want to see how the current AJAX controls works, take a look at the online Elphel camera's: http://www3.elphel.com/online_cameras

And here is a good article on the software: http://linuxdevices.com/articles/AT5951285077.html

Hi oscar I haven't understand what is the streamer on/off
if I have time I'll try to develop something!
best reguard Matteo Pozzi

Matteo,
Normally, the camera will give about one picture per second. But when you start he streamer (Theora) it will start streaming images at a given FPS. The nice thing about the AJAX interface is that it shows a big image and a magnified smaller window for focusing, when the streamer is OFF. Of course a 'film' control panel could start the streamer as default, but I don't know if I'd prefer it.

Here you can see the streamer on/off button in the AJAX setup:
http://s09.picshome.com/0b9/ajax_streamer.jpg

perfect I've understand so the interface is exactly the html page that is on the elphel.com page (now with windows I cant use it ...don't know why...but I've used some ago) are you able to tell me some more about the firmware upgrade of the camera? is the html included in this one or there are some different mode to mount it on the camera? how many kb is it possible to use to make the html? and last is it possible to make a big html with a good graphics (big image) to install on the pc and not in the camera to control it with button that are link to somthing like http://192.168.0.9/axis-cgi/jpg/imag...compression=30 ( ---->to obtain an image with the assigned set of parameters)? maybe I'll write also to Andrey to ask for more specific info

I've asked Andrey if he has some time to clear some things up over here...
If it's 'plain' HTML language, I can possibly help myself.

Interfacing the 333, 353 status
 

I recommend using ccam.cgi, as we do not have anybody to support Video API now - the FPGA/drivers code went ahead and Video API is lagging.

The latest production firmware is 6.4.35 (available at SourceForge), default streamer (working) is made by Khlutchin, you may try it with the computer boot from our Live CD/DVD were the Mozilla plugin to view RTP stream with MPlayer is already configured.
With MS Windows you may try the software - it should probably work with the same firmware 6.4.35.

https://sourceforge.net/project/show...kage_id=217626

Meanwhile I'm busy with the 353 - I had to change the design to use "large page" flash as the ones I used became obsolete in several months after they appeared. a good thing - the new flash is twice bigger (128MB).

Now I'm testing the second revision of the 353 board - hope to get real images from it next week.

I also released multiple other boards that will work in/with the 353 camera - these boards will be tested in the next couple months:

10357 - a board with 8 CF slots - with 16GB cards it will be possible to have 128GB solid state "disk";
10359 - splitter/preprocessor for up to 3 sensor boards. It has the same FPGA+DDR SDRAM as the main board and should be capable of some image pre-processing (like some of 3-d extraction from stereo imagers). I plan it to make an optical camera position tracker to compensate for the ERS distortion effect. This board is connected to the 10353 board instead of a single sensor board and has 3 of the same flex cable connectors fro connecting up to 3 sensor boards to it.
Next 3 boards are designed for non-video applications (2 fps, 11 and 16 MPix with Kodak KAI-011002 and KAI-16000 CCDs) - improved from our model 323 camera:
10347 - Timing/control for KAI series sensors;
10342 - KAI-11002 sensor front end - in pair (sandwich) with 10347 allows connection of KAI-11002 to 10353 board;
10344 - same for the KAI-16000 sensor.

Andrey,
Can you make support for Kodak KAI-2093. This would be very interesting for us! If you can make this how much would cost 353 with this sensor? Anyway have you ever seen footage from this sensor? Is this any good for us (film making )?

I have also have interest for 353&KAI-11002, how much will be cost estimate for this combo?

But can we change the ccam.cgi and save it in some way.
If you look at the page of one of the online cameras as a HTML source, you see a very complex script, but still, it's a html webpage. Can it be edited and saved to the camera or LiveCD?

Oscar,

you can change ccam.cgi but you do not need to do it. It is a binary application that processes HTTP requests in the camera, requests themselves are generated from html+javascript (camvc.html, *.js) files in ftp://<camera_ip>/usr/html/ directory (visible as http://<camera_ip>). This directory resides in JFFS system and is write enabled so you may change/add files there. For experimenting I would recommend using /var/html directory (linked as /usr/html/var) that is in RAM-disk so it is perfectly safe to change data there (will be erased after reboot) - files will be visible as http://<camera_ip>/var/

Andrey

Igor, maybe it is possible, but I can not work on this right now. I can help if somebody will be eager to do that - it is likely that the 10347 will work as is, just 10342 should be replaced by a sensor-specific one.

I have the design files for the not-yet-released boards in the password-protected directory, but we do give access upon request.

As for the price - these cameras are more expensive, especially the senors themselves. I can estimate it may be 50% more than the 333 camera, plus the cost of the sensor.

Many thanks Andrey so if we make an html page with buttons that link to a HTTP requests in the camera we can make a different GUI right? ok, you say that is better use ccam.cgi so the http request of the button of the new gui will have to "start" with http://<camera-ip-address>/admin-bin/ccam.cgi? + the parameter that they change like described in http://wiki.elphel.com/index.php?tit...2C_XML_or_VRML

or can we use also the link described in http://wiki.elphel.com/index.php?title=Video_API

How much, big (kb) will have to be the html page? is it possible to use .swf flash file to save space and make a better graphics? I've seen F4L (http://f4l.sourceforge.net/?q=node&from=30) and maybe.....

and last did you plan to produce a 5 mpixel camera based on 333 hardwere?

Yes, that is correct


This API is lagging behind ccam.cgi ( - we do not have anybody to work on it now. As for ccam.cgi - I always upgrade it myself when I change drivers or FPGA code. So it may be ugly (being incrementally patched from our first model 303 camera), but it is current.

Actually - a lot. in the 333 it is probably around 8MB (flash is 16MB vs. 8MB in model 313 and the amount of software is not much higher). In 353 flash is 128MB.

Yes, the 5MPix board was designed for 333 (and is supported by the current firmware). The only difference between 5MPix sensor board (10338) for 333 and 353 is the interface voltage and a single linear regulator IC on the board determines that.

Thanks Andrey, very good info, you are most helpfull.
So for KAI-2093 we are talking about under 3000$?
Is it GigE in your plans for 353 or any other model?
I think that you mentioned IDE interface before CF? Whats happend?
I like interchangeable CF idea but I like more fixed IDE.
Keep up your good work.

I'm also interested in a camera using the KAI-2093 or KAI-4021 sensor.