Hey, if the Elphel outputs a 1920*1080 image, maybe it can output a 2048*857 (2.39:1). Maybe that is possible?

Sorry, no links, it just some sentences from the guy who did it in the www.avrfreaks.net forum. Just browse through it, you will find them... As for the board, the main problem is the processor, only rating at 200MIPS (it's like a pentium 266 ;)) which is not enough to do any video processing, so it can only be used to interface the sensor with USB2...

(btw, if you come down to it, the only good solution is similar to the elphel architecture : a general microcontroller that's running linux for easily controlling everything and a FPGA for (customisable) video processing power. My point : if the elphel size is ok for you, just use it, it's the most versatile camera for this project.)

Yes, it is a good point (and timely reminder) that the DIY HD projects inevitably it seems strike some technical hurdle on the road towards 2k. By definition a "cinema camera" needs to create an image which could be shown on a big screen if required, so 2k frame sizes are needed -- as deliverables at least -- to meet this technical threshold (and put enough distance between it and say using an HDV camcorder). There are different methods that people are looking into in order to achieve this within various current limitations.

My experiments with the Sumix cameras is to use a smaller frame size to ease the problem (usually 1600 width and whatever height for the ratio of say 1.85 or CinemaScope). Since the Bayer video recordings are uncompressed, enlargement of an uncompressed still sequence may be acceptable enough (?) for the big screen, benefiting from the power of Photoshop to handle still images (and you can use specialised plugins to help retain enlargement quality, and use an action to automate the process). Larger frames can be shot with RAM recording, though this shortens the shot duration too much to be practical.

The Elphel project seems a bit quiet at the moment, though I assume Forrest and Oscar are still experimenting with the 333 camera, and we await the initial findings of the new 353 when they become available. The realtime compression required to fit within the network data rate of these cameras (with no immediate plans of adopting GigE) is a question mark over big screen quality, and tied to finding the best realtime compression schemes which can be used with these Linux-run cameras.

Price has always been a consideration, and right now spending more than the cost of a Canon HV20 seems like quite a gamble. Hopefully, there will eventually be the breakthrough -- that small computer accessory designed for something else, an overlooked free utility or an industry leap in transmition speed -- that's the final piece in the jigsaw everyone's waiting for. When a worthy project stalls over just one small thing I despair...

I am no software coder like some of the smart people on these threads, so my contribution is less than I would like to be able give; I'm just someone who wants to make HD movies any way I can without enough money to hire the equipment. I used to work professionally in the film industry many years ago, but now I'm a Photoshop user for an art gallery (perhaps that's why my post production tends to be Photoshop-centric!). I have put myself in the hands of the Sumix corporation: the recording software I use is pure unchanged Sumix supplied application, so if I can make this work, anyone else can do the same without hacks or reverse engineering. I must say I am very pleased with the uncompressed Sumix image, and an important consideration are the lenses you use to get your pictures (hunt for your secondhand Schneider and Angenieux C-mount prime lenses and stick to them like glue!). I have delayed starting a thread once again because of the recent possibility of using HDD recording, so I'll be starting from scratch again, finding out what I can do with that form of recording using the updated Sumix application when available. I'll keep you all posted about what I find out.

Jose, your investigation into the Micron board has energised many people; I look forward to reading about what you get up to next and what the others say about it; you have character, sir!

Regards to all,
John.

Thanks John,

First of all I wanted to say that I'm not giving up on this project and I'm looking for new solutions every single day. I just sent the Micron board back. I know what it can do and I'll have no problem requesting it again if I choose it for the first completed prototype.

Now, I've got news...

First, I received a package from Omnivision today, but it seems there's been a misunderstanding. When they told me they were sending free samples after talking with them about the demo board they've got I couldn't believe I was going to have something similar to the Micron board at no cost. But of course they were refering to sample sensors. So that's it. Today I received two sample 1/2.5" sensors and nothing more. I'll contact them about the demo board, cause I cannot do anything unless I've got hardware to plug to the computer. Anyway, we've got two 5mp working sensors for free. If we find a way to make them work, then perfect. This can in fact be a huge oportunity, cause we can design our own boards to 2:1 encode the stream before capturing so we have no data rate issues. I say it again, if someone can do it, we have our camera. I've got two sensors. I'll donate one of them to anyone who can make it work.

Now, something that could be BIG. I still have to show you its datasheet and we all have to see if this can fit in the project, but today I received a mail from another reseller offering Panavision (yes, THAT Panavision) sample sensors. Those sensors can capture up to 30fps in progresive and 60fps in interlaced mode. They've got 4 times HDTV resolution, that's 3840x2160 pixels and they're big enough to use 35mm lenses (33.2mm diagonal). They're called Panavision QuadHDTV sensors and I'm attaching the complete datasheet to this post.

The bad points are:

- I still don't know their price. I do know that I can get one for testing purposes, but I'm pretty sure I'll have to pay for it.

- Don't know yet but I guess they don't have any demo board, so we have the same problem we've got with the Omnivision sensors.

- From what I've read in the datasheet, they're not so flexible to program as the Micron sensors. You cannot choose an exact desired resolution so we'd have to set it higher than 2k and then reduce it. There're a few more issues, so I'll wait for any of you to decide if this can or cannot be a good choice.

So, I'm still searching for more.

By the way, now that we're getting some responses on free sample sensors, it would be nice to find out if there's any simple way to connect them to the computer. I'm talking about some kind of board (maybe the ngw100) that we can program to get images from the sensor.

Hey Jose, great job on getting us so far! If no one else better qualified steps up to the plate on your second omni vision sensor I would be willing to give it a go. I of course can't guarantee results but I would be more then willing to try. Do you happen to know where we can find a datasheet on these chips?

I just requested the full datasheet. For now I'm attaching the brief.

If anyone else wants the other one, just ask for it. That way we'll have more chances.

Jamie, PM me with your address.

Remember our main goal is to build a basic sensor-computer interface with added in-board lossless compression if possible (to low down data rate). Developers have full freedom with the interface but I'd suggest GigE. Then we'll develop the software to control the sensor and capture the stream.

Remember there're many different options. Be open minded. Don't close doors.

By the way, don't forget the Ambarella chip! Wayne said it can be directly connected to the sensor to get H.264 streams to an IDE interface. We'd still need the computer to set up resolution, gain... but H.264 is a completely professional codec and can give very good results.

I mailed Ambarella asking for more info but no response yet.

Your omnivision sensor are on a small PCB, you just got the sensor ??
If you need to make a pcb for the sensor board, well it's going to be hard to manufacture and expensive...

For the amberella chip, i'm note sure if you can get easily a chip that support 1080p real-time compression...

(time to order a fpga board and learn VHDL it seems...)

Yes, I just have the sensor. A square piece of silicon. In a little box. Waiting for a whole system to extract sequences from it :)

By the way, remember we have a link to several encoding cores for FPGAs.

Hello Jose,

The OV5620 will not handle full resolution 2K @ 24fps.

A complete 10 bit pixel can be read from the sensor in one clock pulse. However the clock runs at 48 Mhz.

>>> 48000000 / 2048.0 / 1080.0 / 24.0
0.90422453703703709

But at 2.40 ratio it could work. However the paper also talks about maximum transfer rates at specific resolution, I am not sure if a ROI will run at maximum transfer rate.

About SATA eSATA again
 

I have found maybe a solution for highspeed serial ATA conection to LS-371:

This is miniPCI card that support port multiplier function (Chip on it is SIL 3512 that has this function, (ICH7M onboard LS-371 has no support for this only AHCPI and NCQ))
http://www.aaeon.com/PD_Products_Det..._TW_utf-8.html

This is port multiplier for HDDs.
http://www.cooldrives.com/sisiharaesbr.html
It means that your system will see your two external drives as one single drive. You can join those two drives in single enclousure in raid 0 or 1 (jumper selected onboard this multiplier device. I think it has internal hardware RAID fuinction) and have eSATA hot swap. It will run one single cable from your controller to disk enclousure. So when you need uncompressed go for Raid 0, when you need compressed go for Raid 1 for safety.

Here is sata to eSATA internal- external connection:
http://www.cooldrives.com/essaii3gbexp.html
I have not found single one type so you only use one port.

I hope this can help us, and all this sounds very familiar....Like I have seen this somewhere before.

Can someone please check this out once more, maybe I have not seen something.

Take, every time I speak about 2K I mean 2.39:1 2k, that's 2048x858 pixels.

I've been contacted by Cypress. They're offering me two different sensors (not the Ibis). One's smaller and cheap (rolling shutter and less sensitivity) and the other's near 35mm size and global shutter. Both can do 2k at 24fps.

I'll tell you prices and stuff asap.

Chips only, no dev board?