That was really nice! Looks nothing like anything Ive seen on HDV thats for sure! Had a real rustic feel.

good job man I think that this is a very good presentation of the power of this project! :-)
well done

Film...
 

Real cool work Oscar! I look forward to the hi-res one...

Can't wait until the 353 works without a laptop :)

//O.

Thanks, I'll upload the 1600x900 version this week.
It's not so bad to use a laptop. The only thing that slows things down is the software, but then again, only for setting things up. When you're ready to shoot, you can just start and stop recording. Better software could use a function to auto-name the takes of course. That would again speed thing up.
Besides that, you'll always need to shoot from a tripod when you have a camera with a rolling shutter, and the laptop mount I made on the tripod makes it very easy to use. Everything you need is on the tripod.

Here is a picture of the current setup. (I'll make some detailed pictures soon)
http://community.elphel.com/pictures...35mmTripod.jpg

thanks for the image oscar
I've seen that you use a dell inspiron 6400 I think
did you use 7200 rpm hdd!? nvidia or ati video card!?
have you got any trouble with the knoppix live cd?
many thanks
Matteo

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.