Kyle,
Glad to see you here. Don't you have SI-3300 cameras? Same features, just a different pixel pitch and resolution.

Florin,
I bought a gigabit cardbus card for my laptop...Netgear GA511 I think, for about $45. Kyle is working with our gigabit cameras. Our USB cameras will move raw 1.3Mpix 8 bit images at about 20-24fps. Greater than 8 bit will be at half that for USB since we only pack data on the gigabit cameras. Non-Intel host controllers will be slower so the second camera won't have a fast controller.

If you want to record on a laptop, you will almost undoubtably want to consider a fast processor and real-time compression. I was told that the Huffy algorithm was pretty quick. Laptop disks are slow - you have to consider your disk bandwidth carefully.

Florian, I am using the CameraLink version of the cameras, over GigeLink, so I can't really to speak about the USB version.

I meant only to make a comment on the SI-1300 clock. I would still go with a single camera solution for what you are trying to do. I did consider a dual-laptop for stereo, but only briefly.

Also what is difficult enough with dual-camera stereo, is getting focus and aperture to match perfectly. I would think the tolerances would be even smaller with your application.

One thing to beware of when doing bandwith calculations, is that the 10-bit data (at least with GigeLink) is packed as 12 bits: 2 pixels in three bytes. Same as with the SI-3300.

The latest laptop and 1.8 inch drives have improved in speed. I would go to Tomshardware and check their news for the last 3-4 months, maybe look in my technical thread, I might have posted some links to some of them there. Still, none of these drives will be able to record more than one single 720p stream, so you need dual drive in a laptop (or external that works fast).

Unless you want to do 3D, I would suggest going for a single camera at 1080p (i.e. 2xcams= around $2K+ + dual laptop or expensive laptop, or + external, plus a lot of hassle, + alignment (prism best, but probably $) etc. USB has the problem in that, unlike Gige/Firewire, it really ties up the processor, meaning more expensive laptop, and drivers aren't necessarily brilliant (even Gige needs special chipset with special custom driver to work fast). So, it starts adding up

Good luck with it.

Thanks

Wayne.

Greetings Steve, and Greetings Jason!

Yes Steve, I still have the 3300. I was wading into the thread gradually, and you blew my cover. ;-)

Everything I said about the 1300 applies to the 3300. And the 1920.

The clock lets me get 1280x692 at 48.0000fps (dropping very other picture to reduce rolling shutter). Or something strange like 1792x747 at 48.0000 on the 1920.

Jason has been helping me solve some bandwidth problems of my own, successfully I might add.

My setup, for anyone who is interested:
Dell Precision 530 (529 euros in Ebay, not state of the art, don't try this at home kids)
1.7 Xeon
32 MB Nvida Quadro2, AGP 4x
3xPCI, 2xPCI-X, 64-bit/66MHz
1 GB RIMM
Intel Dualport Server Pro Adaptor 1000 MT (PCI-X card))
3ware RAID 8006-2, two Maxtor SATA drives (110MB/sec) (also PCI-X)
2 x Pleora GigeLink

The graphics performance is suprisingly steller for me, at least under OpenGL.

The Intel card is now in a PCI slot. Why? Because I can capture more data and write it to the hard disk, than when it is sharing the PCI-X bus with the RAID card (Jason's brilliant suggestion!)

Why is that so? I have no idea. ;-)

Wow, the big guns are showing up!

Just when Obin thought the thread was dead . . . ;)

BTW Obin,

At least from what I've seen on your images, and the Altasens, yes, noise is much lower on the 1920 than the 3300.

The other thing you have to realize is that you're getting 12-bit precision out of the Altasens instead of 10-bit, which allows you to extract more scene information before hitting the noise floor of the sensor. Basically what this means is that you can set the white-point lower, gaining another 2-3 stops of performance in the highlights without banding and other problematic artifacts ruining the scene. Those extra stops can go a long way towards giving you that high-dynamic range "film" look and soft clipped highlights (i.e., not harsh clipped video highlights, etc.).

Film, through it's logarithmic response curve to light, compresses the hightlights beautifully, and this really helps to give film that perception of more naturalistic, higher quality imagery. Highlights blow out the way the eye sees. In order to reproduce that effect in the digital world, you have to give yourself a lot of headroom, the same way that audio technicians in digital like to record with tone at -20db instead of 0db as one would do in the analog world. Once you clip in digital, all the information is gone, so to give the illusion of the massive headroom that film allows, you have to give yourself enough space to do a soft-clip that rolls off the highlights smoothly to the point where either the display device or the eye can't really tell the differneces in detail anymore, and therefore there would be no difference between film and digital at that point-it would simply look like digitized film in it's highlight response.

So that's the goal, and the Altasens seems to get one much closer to that goal than anything else I've seen out there so far.

WOW.I see this thing is warming up guys!!!!
Keep an eye on Kyle :)

Where can we see any samples from the altasens chip?

Steve,
Is it possible to integrate the Altasens sensor in camera having firewire interface or an integration similar to the one used by Pixelink 741-2 series. The camera can be programed with the supplied OEM software, doesn't need any frame grabbers and "can be controlled by third-party IIDC 1.3 (DCAM) compliant applications running on Mac OS X".
From their poll, FireWire is preffered by 63% of respondents.
This way, the RAW, AVI, TIFF, JPEG files can transfered to any computer/laptop (Wintel or Mac) for storage with apropiate drive setup.

Valeriu:
What is the difference between having GigE and Firewire?
GigE isn't more complicated than Firewire, just need to plug a cable.
Also what is the advantge of a slower interface (Firewire 400&800 Mbit) to GigE (1000 Mbit) ?

Mac Mini

>>Mac Mini

As a potential buyer, the option to capture via firewire 400
(like macs do with DVCProHD) would make me very happy.

I guess that would rule out RAW capture, but it would be
oh so convienient.

The Mini could stick on the back like a brick battery
and monitor HD on a Cinema Display via DVI.

of course I guess that means scrapping everything so
far...probibly not something you want to even think about.

Ok the test code is in and we get a SOLID 30% cpu overhead with it..this is GOOD news as it tells us that our code in CineLInk is slow..I have tried the test code in 2 machines and with BOTH 32BIT AND 64bit cards...same figures for all ...around 30-40% cpu..I will have an updated CineLInk today that has been cleaned up and stripped down for SPEED..I have a feeling of good things today!

stick around!

I just can't get over how GOOD the CMOS chip looks...this shot with nothing but overhead office lights...look how soft and NON video it looks.and it's not even been color graded

oh and I have the worst soft lens on the camera..some old cheapo 16mm film 25mm lens

www.dv3productions.com/pub/16bit.tif


down and dirty photoshop CS CC and downscale

www.dv3productions.com/pub/8bit.jpg


the image was shot with TONS of gain 25db? and you can see dea pixels and pixel noise because of that..but still..not bad for a "snapshot"

see the cheap smear on the watch highlight? yep...cheapo lens ;)

Oh ya..SEteve N. can you map out dead pixels in the SI Cameras?

Thanks for the space Jason.looks like I have our site going for FTP again...please everyone don't download more then once or twice as my ISP will get on my ass again and make me take things down!

Obin,
I'm not sure but I think if you use the Normalize controls in XCAP-lite to capture the reference frames, the library should be able to use them. I use the black level and gain reference frames all the time for our noisier cameras.

There is no map generated - just full image references.

edit:
Who would buy a camerahead with Altasens ProCamHD 3560 (1920 x 1080p, 12 Bit):

1.) with FireWire 1394b (800) max. 30fps (at 12Bit)

or

2.) Additional with build in double removable HDD disk frame to record direct full 12Bit RAW data up to 30fps on 2 x 2.5" HDDs. (In this case Firewire is only for prewiev and setup)

or

3.) max 60fps. Same as 2, but with 2 x build in double removable HDD disks to record direct up to 60fps on 4 x 2.5" HDDs.


Who are interested ?
And what would be your bid?

How are you planning on doing that, since a RAW data-stream at 60fps will in no way fit onto two 2.5" drives? We have to be talking some form of compression here.

Rai I don't understand what your asking..please try again..

I had edit my posting, i hope its clear now.

!double the fun!

Back for more. Why was I going dual? because I wanted to fashion something *truly* portable. As Steve pointed out in his expert fashion, there is a major bottleneck in notebook HDD speed.

Just got a new fujitsu notebook at work with latest intel m chipsest, gige, and one of the newest and fastest hds available. tested it at about 25MB/s sustained write (that's DV speed ain't it). But say I get myself an even faster laptop with two HDDs and interleave/save. Back to that 2 number.

The fastest notebook hd i can find on net, a 5400 one, is 34MBs read, so somewhat less for write (about 20% less for write than read from what I've seen). Anyone sees better ones, let me know. Most have 100MBps burst but who cares.

My USB external and portable 3.5" hd, howEVER, clocks at 30MBs read and write with 24% CPU loading. Same over Firewire. Lesson: external esb drives can and often are FASTER in sustained tr than any internal notebook drive.

Now, with a SI1920HD (please quote me please, Steve, offline, this vs 3300s, all GigE, so I can start making REAL contributions to this thread) what this means is I can tweak real-time compression (lossless jpg?) and maybe manage to squeeze 24fps1080p down to 50MBs (usb speed) and not overload cpu. At best, after lots of time spent scratching my facial stubble.

In light of 3CCD 50MBs panasonic coming out... well...

I have desktop RAID btw, but that's another matter. I'm going mobile.

we just found the issue with record to disk..our disk write code is out pacing the hard disk ability to keep up after 3-6 sec of record..we are looking at multithreading the save ..

we are going to write large chunks of data on the disk as this will allow a smooth save for the 96/MB sec datarate

also CineLink has been running for 2 hours previewing 24fps 12bit 1080 quad pixel @ 43% cpu

Does anyone know about the Altera Development kit that uses c++ for it's FPGA ??

Steve N.

how much work to support the 1920HD?

also I know you have told us but is the 1920 rolling or global? and if it's rolling what is the max MHZ it will push with a good CLEAN image output?(@ 1080p)

Obin:
Congrats. You are moving serious data around. I would be careful about c++ programming for an FPGA. In video, you don't have much time between pixels 1920x1080x24fps is about a 60Mhz pixel clock. 16nsec between clocks. I would talk with Altera about whether this will work. The more abstractions you have, either you need lower level tools or at least you need to understand the lower level ramifications of the high level operations. Like writing device drivers in C++. Sure for a mouse, but for video? Maybe if you understand what the assembler of your loops look like.

The 1920HD is an Altasens camera. Rolling shutter, can run to 1080p@60fps with clean images (150MHz clock). You can also run it with that clock rate and take data off at 24fps to bang on rolling shutter issues. It is not a simple sensor - we are still testing out some of the less obvious functions. I think the people at the factory don't know about all the bells and whistles either. There is basic GUI support with both the Epix and GigE link versions right now.

Steve what type/speed FPGA would you look at to take in 1080 data record it on disk as raw files and display in black and white with quad pixel readout to a screen?


and BTW Juan I have gamma adjustment on the way for the preview letting us see into the darks and display an image that you CAN set exposure from!

ww.dv3productions.com/pub/dog.tif

so what is the datarate of the 1920HD at 150mhz!? 1080!

Greeting, Obin! Your programmer may already doing this, but I thought I'd mention it. You definitely want to be using Windows' CreateFile() and WriteFile() calls with the OVERLAPPED flag, and a call to GetOverlappedResult(). This will allow for async writing, although Windows will most of the time, treat the write synchronously (returning "written" bytes in the WriteFile() call). The buffer size must be a multiple of the disk sector size (512 for me, though it can be 1024, or 2048 bytes). I saw things much slower with fopen, fwrite, fclose.

There are ways to force async writing (e.g., by extending the valid data pointer to a file (only under XP)), but I did not see any improvement.

I am also trying to get 96MB/sec, and have managed only 87.8MB, wth the current setup, although I can get 114MB/sec with the RAID alone, doing 2MB writes.

Still, with a 0.75GB buffer (on a 1GB machine), I can record for 94 seconds.

Yes, you definitely want to be writing larger chunks.

<<<-- Originally posted by Obin Olson : www.dv3productions.com/pub/dog.tif -->>>

getting a 404 on that image.

Obin, I have been normally using 48 and 50 FPS with the SI-1300 and SI-3000. It is possible to instruct the grabber to drop every other frame (or x frames), so you receive 24 or 25 (or have timelapse). (you probably know this)

It is *also* possible to increase the clock rate, and increase the number of lines in the vertical blanking period, and still maintain the desired framerate. This further reduces artifacts from rolling shutter, since the time per scanline is reduced. Caveat: there is a limit to the number of lines in the VB interval, though I can't say off the top of my head what that is. You might, for instance, have to run the camera at a 58.45 fps rate (with normal VB), add the additional (max) VB lines, set your skip to one, and then receive your 24.0000 or 23.9760 frames per second.

I know I am basically repeating what Steve said.

Kyle and Obin,

If you guys can barely squeeze the data into RAIDs, how am I ever going to make into notebook hdds. Here's how..

As the data is scanned sequentially from the chip, a histogram of pixel or pixel differential is compiled for each frame, and when it's flushed from the buffer onto disk, it gets huffman coded. Variations thereabouts. A simple scheme requiring very few computational resources, time or memory... much less than jpg.

Not deterministic, sure, but you can't shoot uniform random noise over whole dynamic range even if you tried. Do you guys really write RAW data?

This type of lossless compression seems to get compression ratios of at least 2 (with everyone's favorite huffman coder).

Seems easier than getting getting that extra 10% out of the drive. And if you have to NLE or whatever, what's the use of a 100MB stream anyway?

LOL hahaha, do you really believe what you are saying?
you are getting something like 94 Mbytes/s.
so you wanna huffman compress it to record it onto a Laptop 2.5 inch drive???
like what? a 2.5 inch 10K RPM one?
So your huffman will compress like 3:1 sustained or even more?

I'm not getting your point, really.not trying to be offensive...

Edit:Now that I see you are Dr. and Fraunhofer guy.Why don't you just make some kind of lossy codec for it, keeping at least 10 bit bitdepth.
You could even modify Xvid or simillar to accept 10 bit and compress the bayer.
May be even better avoid huffman and use a range encoder!!

we are using VB indeed it works well for what it is...as far as the save stuff I think that is exactly what we are doing ;) and thanks for the info! I did pass it on to our programmer just incase

www.dv3productions.com/pub/dog.tif

works fine for me....

Wow how gamma can help with the exposure of th image while shooting! I have been playing around with it with CineLink...looks like we will still need a way to show histogram? or maybe zebra... also i want to have a button that allows one to 'zoom in' on a live image for focus ..this will help lots...


I got a chance to hook up the touch screen monitor today an d 'playshoot' with no recording(as it's not working yet) ...touch screen is VERY good and EASY to use! bad thing is the screen has a weird tint to it with the touch surface...I don't like that...anyone seen a VGA splitter so that we could have a nice clear screen to frame with?

"I am using a commercial routine written in assembler to write to disk. I
have tried both the asynchronous version (Overlapped) of CreateFile with
WriteFile and fOpen, etc... and that are an order of magnitude slower than
the routine I use. I also tried copying memory to disk and a wide variety of
methods that did not work well either.

Right now I am writing a multithreaded test case and I have the basic
structure written. I hope to finish it tonight so that I can do extensive
testing in the morning... I'll keep you posted."

<<<-- Originally posted by Obin Olson : www.dv3productions.com/pub/dog.tif

works fine for me.... -->>>

maybe it wasn't finished uploading when you posted, coming in now.

I imagine that's going to look pretty amazing when it's fully working and the dead pixels have been taken care of. They say that S16 7212 has the same resolution, but I don't know, I've seen a lot of the 7218 printed and it doesn't appear to have nearly the resolution of this camera. I cant imagine how great those Zeiss primes will look on this monster. Actually now I'm really wondering how this would compare to 2-perf 35mm.

Great job. Can't wait to see more samples

that really looks like scanned 35mm slide film. so exciting.

>> "I am using a commercial routine written in assembler

Very Cool!

> If you guys can barely squeeze the data into RAIDs,

Florin, my system is 3-4 years old, and relatively underpowered for such an application, so I would not consider my results as a typical data point.

Jason and I have spent many emails trying to figure out the source of my bottleneck, and it is looking like the RAID controller is guilty. At 3ware's website, the docs on the 8006-2 do not mention onboard memory nor a cache, so I must assume there is none. That could explain the behaviour. It could also just be an inherent system-limit of the Precision 530. The synergistic interaction of all the components makes profiling difficult to find the exact cause. Or maybe I'm just not smart enough. ;-)

BTW, CPU usage stays below 25%, even while the writing is falling behind by about 8MB/sec.

For me right now, a Broadcom BC4452 is a little pricey, but the Promise SX4 has 64MB to 256MB onboard memory (user may add SIMM), and may work at 66MHz in a PCI-X slot (though the board is 32 bits).

Obin: VB is Visual Basic?

Audio Note:

BTW, my solution for sound is an old portable Sony DAT. I can download the sound digitally as a post-process. I have also tried MiniDisk, and it also works, although at 44.1, and with some compression.

I do use a clapper board. ;-)

To mask the computer noise, I just keep the box far away. I have made a master cable with mouse, keyboard, VGA, and two ethernet cables to run the computer "remotely", up to 20 meters away. I use a light 17" LCD screen as a viewfinder.