4:4:4 10bit single CMOS HD project

[Obin Olson]

Steve N. how is the noise level on the Altasense? is it better then the Micron 3300rgb?

[Florin Popescu]

Hi everyone.

I am new posting to the list, but have spent the last couple of months reading all the info. I have formed my own design in my head and I want to know what people think (especially Steve Nordhauser). I may be wrong.

The idea is simple: split the image in two (prism or mirror) and use 2 1.3Mp sensors (like SI 1280 or 1300) with USB output. Why on earth? Because 2*40 Mbytes/s = 80 and virtual 1020p (allright, more). You can have 2 usb streams at once. Software synchronizes capture and writes 2 streams over fast bus to 2 drives - on a laptop. Stiching is done later. Oh and you get the width almost that of 35mm, larger pixels, so on.

Btw I'm a researcher for Fraunhofer, and although I do not do mp3 or 4 or anything of the sort I know they do use the ARRI D20 around here - which is in no way 'alternative'.

Please talk me out of this so I just buy the Sony and leave you all to tinker happily while I do my sci-fi research. Or...

[Steve Nordhauser]

Obin:
At a gain of 1, they (3300 and 1920HD) are not too different in noise. The 1920HD is much more sensitive (5 vs 3.2 micron pixels) so you can run it at lower gain and get less noise for ambient lighting. If you can completely control the lighting, the 3300 is very good.

Florin:
I wouldn't run two USB cameras on a computer and expect double the rate. First, the fast controllers are the ICH4-6 built into the Intel chipset - you only get one. Next, there is CPU loading from running two. Next, the only laptops I know that support internal RAID are from Saber (?) and are very expensive. Remember, bytes are bytes. If you are capturing 2Kx1Kx10 bits x 24fps, it doesn't matter if it comes from a single camera or dual.

Stitching has its problems. Alignment and post processing can be difficult. It would be feasible with two camera link or gigabit cameras - you can put two gigabits on a laptop if you can handle the data (count bus crossings on a 32 bit system - Obin has become an expert on 32 bit limitations). The good news is that, unlike other methods, you can keep 100% of the light on each sensor.

[Obin Olson]

Well well we are still scratching our heads..this is very weird no conflicts of any type and still with a brand new install of cinelink we are getting 70% cpu with a simple black and white preview!!! this is crazy!

does anyone on the list own the Epix card and SI 3300rgb camera?

the 32bit card on our programmers new P4 machine is running at 18% cpu and we have tested the SDK to be running at what is normal with a compile from a .cpp test program from Epix...Xcap works very well with the new 64bit card @ 18% cpu!

arggg...

[Florin Popescu]

Thank you Steve.

I was thinking of slapping in a second USB 2.0 controller on the pcmcia slot (bottleneck, I know). The 32 bit problem is the big challenge. This was the optimistic solution.

There is a second solution: two laptops (which I have already). No doubling of cpu load and throughput problems.
Stitching is not a major problem if off-line processing is done in due time - it's an algorithmic problem, which I can handle.
The L and R sensors would overlap slightly, and one finds the correct pixel shift by calibration (diagonal lines). You just have to mount them parallel to each other (in the visual plane), and rigidly. A feasible machining problem according to my calculations. (the guy with 2 commercial dv cameras did it!)

The synch (time and settings) between cpus would be done by ethernet. 1/24 of a sec is a LOT of time. Preview is a problem... you wouldn't want to frame just the R half of the shot! But one can downsample pixels and send to the 'master' of the two computers at a low frame rate, compose a low-res and frame rate preview.

Which of your two 1.3mp heads do you recommend, then? I read the specs... And... are their clocks consistent from item to item?

Sorry to butt in on the thread but I think I have a point...

[Obin Olson]

I do indeed have a point. But...this is a real pain! why not just use the 3300rgb with gigabit and have 24fps all day long at 1920x1080? 12bit to boot...I would NOT bother with your idea...I see no real point to it

[Jason Rodriguez]

Obin, is your programmer's GPU the same as yours?

I know on the 855GME, the graphics is on a shared bus with anything and everything else that is grabbing for memory bandwidth. This may be too much (basically 16-bit data unpacked at some point along the way) for the Intel Extreme2 graphics engine to manage, and so you're running into a bottleneck there.

I know with the DFI board you can add an AGP card, so I'm thinking that might not be a bad idea, especially if it's just previewing that is causing you all the grief.

For instance, try a capture-to-disk without previewing and see what happens then. That might help you isolate the problem, or at least point you in a more general direction of where the answer may lie.

[Rob Lohman]

Obin: as Jason suggest you guys need to start trying to figure
out which exact part is giving you the problem. Disabling the
disk writes and preview in sequence should point you at least
in the right direction.

Profiling and timing (your programmer should know) can help
futher pin down the problem if you can't figure it out with things
Jason was talking about.

[Wayne Morellini]

If all these things fail I still recommend what I said before.

Some of these problems canbe selective and interdependent, so one thing runs properly and another not. If you aren't running the same system as your programmer, it is a good idea so that you can get a clean working solution for one motherboard at a time.

3D directX support varies greatly between different chips, the directx software then emulates the missing hardware (much slower), or the hardware runs at a different speed. The problem is exacerbated, in that if you don't use directx properly, or the hardware isn't used in a certain way, it runs slower again. For Shader support, in particular, some of the support in non ATI/NVIDIA chipsets can be really (and I mean really) light and slow.

I think it is most likely will be a OS/Driver configuration, or some whacked out PCIX support problem (as long as you let the motherboard, chipset, and card/SDK companies know about the problems they will probably correct it through an update).

[Obin Olson]

I will get some test code today that does nothing but preview an image in DirectDraw...this will help us find out if it's our program or the speed of the hardware that is using so much CPU

[Laurence Maher]

Steve,

Not to be a party pooper, but with the huge rumors of this extrememely user-friendly camera from Panasonc AG-HDX100 coming out some time this year with it's supposed 100Mbps and most likely near 4:2:2 color space and add all that to the fact that it's a complete solid device within itself, less likely to need technical patchups and maintanence, and that it records straight to DVCProHD like my MacIntosh takes in via firewire automatically and lossly and the price is under 10k and it's very user friendly . . .


. . . why should I bother going for these new box cameras instead of something I'm a lot less likely to have problems with?

Just trying to give you guys a chance for all the work you've done so far.

Thanks,

Laurence

[Wayne Morellini]

What pixel depth and resolution is recorded to tape for that format? I admit that it will probably be descent for the average low end production (providing they can afford the cartridges). And depending on the motion artifacts i might consider it for documentary and even news gathering.

What will these adventurous projects offer, depends on which one. But eventually when worked out (and assuming a high price for the camera):

Low price

Big chip performance

big bit depth

high latitude

better detail and quality (uncompressed).

So "horses for courses". At the moment people here are chasing the Indie cinema market instead of the documentary/video/Pro Eng market. Until we get a camera up for the other market, the Pana/Sony etc is probably going to have to be easier.


At the moment a TV program called "the beast" is running on my TV. They inter-cut between handcam and Eng, and I presume film. The handcam is :( , the Eng is twice as good :( , the film is twice as good again. Now, I can guess where the Pana is going to come in. Switch over to one of those British BBC programs shoot digitally, and they are lovely, we had an Australian one ("Something in the Air" ) which uses simular values, again gorgeous quality. So the difference is how close can the Pana get to film or the British digital shooting?

If you don't want these things a HD1 is already available for around $1500.

Thanks

Wayne.

[Jason Rodriguez]

Well Laurence,

It's really simple.

There's more to an "HD" image than just resolution.

Do you want your stuff looking like high-resolution video, or like film?

Color saturation, dynamic range, the ability to shoot in more natural-light conditions without having to put fill light in all the shadows in order to keep the highlights from blowing out, etc. There are a lot of image quality characteristics that make and image look that much more like film, and less like a off-the-shelf video camera.

Just having cheap high-resolution imagery is not what I'm after. If that were the case, then I'd already have a ZR1 from Sony, and be happy editing my HDV. Or I'd be totally satisfied with the image quality I get out of the F900's that I rent.

No, I want more :)

I want multiple speed frame-rates (slow-motion).

I want high-dynamic range imagery (greater than 8-bit, and pushing 1000:1 contrast ratios) so I don't have to constantly fight clipped highlights and all the other tell-tale signs of "video"

I want clean saturated colors, not compression artifacts from highly compressed DCT codecs (I'm even quite disappointed by DVCProHD, forget HDV).

I want high-quality exchangeable lenses and super-sharp prime lenses, not a cheap peice of glass with "Leica" or "Zeiss" slapped on the side.

I want DOF from a 2/3" chip, not have to slap a ground glass in front of my lens for half-decent DOF effects.

From today's video camera market I want a lot that they simply won't deliver. But fortunetly the box cameras deliver :)

[Kyle Granger]

Hi all! This is my first post, although I have been avidly following this thread for months. I am impressed by the technical depth in the discussion.

I have been programming two SI-1300's for a 3D application. Regarding Florian's post, I can say that I have not yet detected a variation in the clocks. Furthermore, it is possible to genlock the cameras, making one slave to the master. The sync is to within a scanline or so.

One of the nice things about all the SI cameras, is the clock synthesizer. This allows you to set almost any pixelrate between 20 and 75 MHz you want. I did not find this feature on other industrial CMOS cameras I looked at. You get also a very flexible ROI. The SI-1300 has a constant horizontal blanking of 244 pixel clocsk, and VB of 26 lines, which makes highly accurate framerates completely computable.

What would be an interesting application for the image stitching, is a 360 degree shot. Using an 8mm lens, you get a 45.17 degree FOV. Using 8 of these, and maybe 4 PCS, you could record a 360 degree panarama. Using 8 LDC projectors, you could also display it, in realtime.

[Florin Popescu]

Thanks Kyle.
Have been talking to other people and I am starting to believe in my own idea. One of the amazing things about this thread is how much people (experts) can disagree...

There are ways to split the image into L and R for each camera without losing half the light (not prism, no), and stiching can be done. It is tricky, yes, but doable.

Kyle, what I wanted to know is if the SI-1300U lives up to spec. Does the USB version really get 1K+ 24p 10bit as SI claims or does it miss frames and crash? I'm sure the other versions can, Steve. I want usb.

Splitting the pipeline in 2 reduces load on the usb/firewire whatever, on the disk, on the cpu to manageable levels. PCs are made to handle 30-40mB/s but not double that without lots of pain.

G Ethernet on a laptop? Raid? that's what's hard. I'm talking standard equipment and top level SDK tinkering. that's what's easy... theoretically.