quit
 

Hello!

Unfortunately I cannot wait more for the 353. I have a documentary project to start in June so neither I can wait for more nor I'll have the summer to spend on camera development. It's a pity because renting a camera for long term certainly costs more and it won't produce the quality I expected from the would-be-lossless Elphel. I really wanted it, I had projects to do with it but we just run out of time. Good luck for the rest of you - I might look in sometimes and see how things are going.

Bye,
Zsolt

PS: If somebody's interested, here's the BloodSimple(TM) codec I wrote and experimented with. It creates a bitstream directly from the bayer input, always taking the difference of pixels as input. It works best if we use the algorithm in interframe mode, which means that we calculate the difference of pixels from the same coordinate of the previous frame. This of course needs that whole frame in memory.

An output sample always begins with a one bit flag (F) which tells the decoder if the following sample has the same bit length (F=0) as the previous one (a length of P) or it is greater with G bits (F=1). This G constant can be set according to the input stream and it will tell the contrast ratio of the generated images: with a T bit input, following pixels usually don't have more difference than T/2 bits. Visually lossless is around T/3 but it can be calculated explicitly in a pre-encoding step if needed. (By having the motion blur of the 1/24sec exposure, the blur caused by fast pans won't cause quality loss in the encoder as it would do with shorter exposure times.) If F=0, the decoder uses the previous P bit length but if the sample's most significant L bits are zero then the next sample will be taken with P-L bits (if that sample's F=0). The encoder knows this and if the next sample's length is greater than P-L then it sets F=1. L is usually set to T/4.

With sample videos (no real bayer input, only some grayscale mjpeg stuff with some artifical noise added) it has produced a 2:1 average ratio which means 2.5:1 with low freq content and 1.5:1 with high freq content (ie. trees with leaves with the sky as background). Because the code is so simple one can use several module instances in an fpga, for example, one for each pixel in a 20x20 block (or whatever the Elphel uses), working in paralell with only the memory bandwith setting the performance limits. However, with a smaller no. of instances it may fit beside the theora module; altough two output streams aren't supported yet. And it's really easy to implement it in verilog which can be a concern if somebody's not an expert like Andrey...

353...
 

Hi Zsolt,

Have you tried just calling Andrey?

Last thing we heard he was supposed to have a 353 with hdd support up and running on linuxtag. (30th of may - 2nd of june) In other words..in just a few days!

..so how about calling him and just ask to see if you can buy or borrow (he has generously offered access to cameras if you develop in the past) a pre production model for developing the codec? Worst thing that could happen is that he says no ;)

Oh I just thought I would ask.

If you really feel there is not time - then good luck with the documentary!! ..and we hope to see you drop by here in the future :)

good luck

//O.

Yes, it is coming closer and we should have some interesting hardware at LinuxTag in a few days. And we are already shipping 353 cameras (in basic configuration - just 10353+10338 boards).

hi andrey
can you tell me how long is the 30-pin flex cable connector (J1) that connect the camera to the sensor board!?
is it possible to buy and use a custom one or come soldered ?
I'm looking for design a camera case in "reverse mode" to reduce space so the sensor will be positioned on the back of the case and not in front.

many thanks

Normally we use 1" and 2" cables, with previous models I tried up to 12" one. THe 353 has a flexible clock phase adjustment, so it is possible to adjust it to match data on longer cables if you'll have any problems.

Up to 8" are in stock at Digi-Key, longer need special order, I believe.

Zolt, consider this fro your documentary in the case for the Elphel:

http://www.dvinfo.net/conf/showthread.php?t=94079

It will probably cost similar to the Elphel to setup, plus the adaptor/mounts, computer case etc, could be shared with the Elphel. So, basically you land up paying for thread cost of the Intensity card, cable, and the Canon HV20 over the Elphel (unless you want to use the cineform codec). The Canon produces a somewhat silky image, and offers uncompressed/low compressed 8 bit at least.

I might have posted this before:

http://dailytech.com/Major+Lowlight+...rticle7401.htm

LinuxTag
 

Hi, I was long time in the background. But the opportunity is favorable now to see the camera. I will be on Saturday at LinuxTag and if the basic parts works well, than I try to get it. In my application as "sports-cam" are just 353+338 boards, one CF Card and accu required. The necessary modifications/adaptions wants I to make (with an additional print). The next step is, to design a small case in Inventor-3D. So if you wonder whether I am crazy, because fast motion an rolling shutter doesn't match? Right, I solve it by lower resulution but with higher framerate. Which is possible, we will see in Berlin.
Robert

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. You could still work on it, and use the Elphel for another project. How far advanced is Blood Simple software code and fpga, this could be used for ant bayer camera around here as well?

New Altasens sensors for surveillance, HDV use, and 8Mp etc with extended latitude,
 

Here are a few more sensors worth considering:

http://www.altasens.com/AltaSensBits...essRelease.pdf

http://www.altasens.com/ap7.html
http://www.altasens.com/ap5.html
http://www.altasens.com/ap2.html

http://www.altasens.com/Products%208M.htm

The 3372 and 5262 loom interesting for 1/3inch sensors using the new technology. Pity they don't have 1/2inch, 2/3rd inch, or 4/3rd versions yet.

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

Yes, I agree, visually lossless is good enough, but with Bayer, lossless would be preferable because of the knock on effects of color deviation during de-bayering. Otherwise, I think lossless is only of much use in movies for green screening, and computer graphics, even though I find it more pleasurable to look at than visually lossless.

Is anybody working on the choice of down converting 4:4:4 binned pixels to Bayer pixels before compression, to reduce compression and data rate?

Will the Dirac wavelet FPGA project be of any good to you, or is there any other wavelet FPGA codecs out there (2D-5D)?

There is no point in demosaicing before compression, since in this process you're going to "recreate" missing information. And you want to compress the bayer array because the errors introduced by the compression will be filtered by the demosaicing interpolation anyway...

/me who's working on implementing an high quality and almost not slow demosaicing algorithm.

I have the opportunity to work with the 353 already. I'll keep everyone posted on the results. I'll be ordering the power supplier, so it'll take some time to get started.

Besides that, I'm planning on rebuilding the 35mm wax adapter and perhaps building a Medium-Format adapter for the Elphel.
I'm thinking about testing a MF double lens camera, so I can focus through one lens and capture through the other one. This will solve the 'real-time' preview problem, but will rule out using different lenses. Still, I think it's worth looking in to.

the same idea of me!
I have now a set of mamiya lens 645 manual focus
they are incredibly sharp
I suggest you to take the 80mm f1.9 the fastest lens on the medium format market
and a 45mm f2.8 and /if you can take also the 35mm f3.5 you'll get an incredible variety of prime! :-)
take a look at this site do not go in e-bay! http://www.keh.com/onlinestore/home.aspx

for andrey: cool the ubuntu based distro ...did you get good time at linuxtag in berlin?

Steve, I meant that the video resolution is binned, with one red and blue and two green pixels per binned pixel. This maybe available as an 4:4:4 pixel from the sensor, but 4:4:4 requires too much data rate to compress with quality. Instead, we can use one of the color components to produce an equivalent Bayer pixel (straight, simple, fast, on the fly conversion, by simply dropping the other components) then compress that using one of the schemes here, or grey scale. This will give three times less compression for the data rate (or closer to 2:1 for 720p) but with an quality superior to 4:2:0.

Does this sound feasible?

(Matteo,)

The setup for a dual lens system should be very suitable for film, because the focus knob (on the side) would work the same way as a follow focus.
I doesn't have to be MF of course, I'll just test it because I have some camera's like these lying around to use: http://k53.pbase.com/o4/87/331787/1/...lleicordV2.jpg
I hope the lens on such a camera is bright enough for indoor use. Probably not.



I had a chance to talk to Andrey about the development of the new model and things like that. I have to say, my enthusiasm is only growing. It's wonderful to work on something that is in constant development. Thanks to 'open source' but most of all to the 'open mind' of Andrey.

Maybe, or maybe it can help somebody else to port it to our cameras.

For some application - yes, you are right. Somewhere earlier in this thread I explained the modification to JPEG we use to compress images where demosaic algorithms are implemented on the client PC. But for many applications it is not fast enough. So we use compromise - 4:2:0 where number of pixels to compress is just 50% (not 200%) more than in raw sensor data.

Daniel, I finally got to review your images, I did find some compression problems and blocking, but seemed to be better than normal. But what % was each one recorded at, was it lower than 85%?

I loved the look on this, so different, to really get a good idea of the motion I converted it to divx with the divx encoder (wouldn't play the xvid on my multi player) and put it on my regular 29 CRT tv , Beautiful! and it feels really special, not at all videoish, so far it's the most "different" look I've seen

what framerate did you shoot this in? because I was reading that it was hard to capture complex shots without frame drops and all that stuff and they were talking 19fps

They were all shot at 85% quality and I was using a letus35 on all of them except 1.png which I believe to be the most sharp in the bunch. Im not comfortable using 90% yet because of the risk I may get a dropped frame.

It seems that when I use the 35mm adapter the video is not as sharp. I need to do some more tests, it may be that im not properly focused on the gg or possibly just because the lens is wider open.

Oscar, current code uses 48MHz (like in older camera/sensor), we'll increase it to 96MHz as new sensor allows - that will twice decrease effect of the rolling shutter. This is something I'll be working in 2 weeks (I will also connect and synchronize 10 of the 5MPix cameras - that project requires 96MHz.

Hi,

I'm new here but I've been following this thread for a long time. I have a question regarding what Andrey just said.

If you shoot at 96Hz instead of 48Hz, wouldn't that ruin the cinematic motion blur you get with a 1/48 shutter?

And Oscar, did you shoot your Romain documentary at 1/48 or 1/96? Your video looks fantastic. I've never seen anything like it. It reminds me of old film cameras but IMO it lacks some more motion blur, that's why I'm asking for the shutter speed you used. If it was 1/48 then it means the Elphel cannot deliver a really cinematic mblur.

Appart from that, congratulations Andrey. Your camera is a real low cost solution for people trying to get something different and more cinematic than 90% of the other cameras. I'm a great fan of the Elphel and I plan on buying a 353 if my little project doesn't come up as expected.

a few lo-tech questions
 

I've been following this topic for over a year now, and I'm slowly understanding some of the elements and terminology involved, but still in the dark on much of it.

Oscar, the footage you posted looked fantastic. I was very impressed.

Here are a few questions (demonstrating some of my technical ignorance).

1) Oscar, your short project looked great. Is there a reason this setup isn't ready to be used on other short films?
2) (everyone) It sounds like the "bugs" or "roadblocks" remaining have more to do with software issues than hardware. Is this correct? And if so... is it a matter of colaborative manpower?
3) Could someone with a production (but not engineering or technical) background (like me) purchase some of the equipment and collaborate somehow without knowledge of the programming end of it?

Thanks, Daniel

Jose,

Oscar could not use 96 MHz because 1) - he did not have 5MPix sensor capable of that pixel clock and 2) current FPGA code was not designed for such frequency and there is a software enforced limit of 48MHz to protect earlier sensors.

The pixel frequency determines frame time (it can not be less than (simplified)

(number_of_pixels_in_a row+extra_line_time) * (number_of_rows + extra_rows) / pixel_frequency
extra_line_time and extra_rows are sensor-specific parameters

With Electronic Rolling Shutter (used in virtually all CMOS image sensors) - http://wiki.elphel.com/index.php?tit...olling_Shutter the exposure time (long results in motion blur) and frame readout time both determine what you get in the images but in different ways. And so far I do not know of any value of ERS distortion so it is better to try to minimize it.