Zolt, on looking at your post again, I think I have been an bit confused. Were you offering up your project for somebody else to take it over?

That's right. 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.

Zsolt

I've uploaded a full resolution version of the 'demo-documentary' I shot with the Elphel 333, the wax 35mm adapter and TV-lens. This short film will probably also be shown at LinuxTAG.
It's compressed with Xvid, but very acceptable to show. (200MB)

http://community.elphel.com/videos/RomainFULL.avi

Hi Oscar,

Thanks for sharing the hi-res version!!

A few questions:

1. How much of a problem do you get with the rolling shutter?

2. Is the footage direct from the camera or did you make any colour adjustments?

3. Is there any way to compress the video stream less...or the ethernet is the bottleneck here?

I really like your short documentary :) Good work!

thanks

//O.

Think it was really nice to see it used this way! the DOF was great. I did notice a few moments of dropped frames which is the main issue I think with the camera just now filming with Mjpeg at above say 70%. I think with the Ogg Mpeg4 encoder this problem should go as they can adjust the compression so the bit rate is fixed like with a normal camera. A fast HD can help this but the bottle neck can also be in the camera I think if the scene becomes very complex.

Thanks Odd and Phil.


1. There is one shot with really noticeable rolling shutter. It's the telephoto shot of a basket with snail-shells. I used it because I liked the image, but a rolling shutter and such a big telephoto lens doesn't really work.
What also doesn't work is shooting hand held. Also a bump on the tripod gives a strange 'wobble' effect. Even a small bump, so you have to use a very good tripod with very smooth movements.

2. Almost all the footage is without color correction. I did use a little level correction, box blur (to get rid of the OGG compression block pattern)

3. Note that this is a Xvid compressed file. The original is better, but there is always some compression. I use 80 or 85 % quality on the camera. Higher percentages give frame drops.
Maybe the file doesn't play smooth on Phil's computer, because I don't think I have frame drops. I'd notice it on the audio-synch.

I have been able to record smooth 90% quality but it also depends on what resolution your shooting at. I prefer to use 2000x800 because I think that gives me the best results. At 90% quality there is a delay in the streaming video when recording at the same time, so I usually use 85.

some screen caps below from previous 333 test projects.
http://www.buysmartpc.com/333/1.png
http://www.buysmartpc.com/333/vlcsnap-1519185.jpg
http://www.buysmartpc.com/333/vlcsnap-1519992.jpg
http://www.buysmartpc.com/333/paint.jpg

I have let people know on my technical thread. Incidentally, I noticed that this thread is now bigger than my technical thread where I host discussions on technology issues, and announcements, since back in the original Digital Cinema threads, so congratulations, you have come an long way, with lots of new people.

A new sensor is coming (slow as a snail )
 

http://www.planet82.com/english/product/smpd_02.asp

"..So, blood simple is an simple inter 2 frame codec, no fancy stuff. This is basically the same as what Juan was working on, good effort..."

If that Juan is me, the thing I was just "testing" was basically some kind of lossless/lossy block based "DCT like" compression scheme using just integers and bit shifts.The nice thing about it is that even in lossy mode any visible block would be busted after a decent demosaicing.
I was thinking that if Elphel can compress Theora on the fly, this RAW Bayer compression should be a piece of cake.The 2 frame differencial was an option in case lower bitrate was required, but I still think that would be a last option because there are still a couple of tricks left before going that route.Anyway Andrey never showed much interest.
Maybe the Etrax mic can't deal with a higher bandwidth than the used for the theora stream.

The limitations of the device in the Elphel has been discussed here previously. I would like to suggest, as I think I remember you had experience with programmable hardware, that you might like to do this project? I had been trying to get Andrey involved even earlier, but there was two things, the Elphel 333 and earlier models were not that good for the purpose, and Andrey had an lot on trying to earn an living out of security sales to spend time on this. When you look at it, apart from better security streams, what we have tried to do would also allow for better machine-vision sales.

Well, in fact I've been in contact with the stuff but in some distant way, not exactly programming but more as some kind of advisor telling people where to look for code/ algorithms and which one to choose over another...
So I can't really say I "Know the stuff". I would really like doing it myself, but I don't have the required time for learning all the needed skills and become some kind of Superman, nobody can do everything by itself alone.
By now I'm just trying to experiment with some Microcontrollers from ATMEL for some other stuff.
Technology here in South America is not as easy to get as in USA, don't even think about getting a Verilog programmer who doesn't think he is Einstein!!!
My small test where done in simple C language on a Pentium 4 HT machine

Theora encoder took me several thousand hours to make - far from "a piece of cake". I need to find some time to port/improve it to the new 353 hardware - job not done yet.

And it is true - I don't see much sense of true lossless video compression, DCT-based JPEG or Theora with quantization coefficients of 1.0 could do the same virtually lossless (why do you need true lossless?) compression with the ratio of ~3x. I would rather try wavelets, but it would be a larger project for me.

Yes we need to make living of the cameras - and currently it is rather far from the security business. Cinema projects are community driven and we would like them to stay that way (at least in the near future) - we can just support them with our hardware.

We are now working on Ubuntu-based distribution that includes FPGA development project. Unfortunately we can not include Xilinx software there - you have to download it separately from their site.

We now have a 10359 board ( http://wiki.elphel.com/index.php?title=10359 ) that is easier to experiment than with the camera FPGA itself.

Quite a good news!!!
Anyway I understand your position, I know the only way I have not being a company is making it work and showing if it is usefull or not.Only thing I want to clarify is that this encoder is not DCT, but integer transforms, and that it compresses the RAW bayer, not an RGB image, and that it is higher than 8 bit per pixel.(10 and up).
I thought that replacing some parts of Theora with these routines would be enough, but you prove me wrong.
see you. :)