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.