arrggg....we can't figure out why the software runs at 15% cpu on the 32bit card and 85% on the 64bit card!!! it's really weird...we are trying to see if the SDK and DLL files for the 64bit card are not working right..no ideas yet but I am sure it can't be that big of a deal...other then that we have the COnvert part working and feeding files from BOTH twin disks so that we don't need to copy everything from disk 1 to disk 2 for convert and we have a "snapshot " button that allows a color "snap" so we can see what the scene looks like in color...it's to much CPU load to preview in color 1080p 24fps so this will be a nice option

Put a new clean system hard disk in the unit, install only windows and software needed, and then test again. There could even be a conflict with old drivers pieces still left on the system from the 32-bit card, or some other software or internal windows configuration error.

If it won't work on a new system, maybe the MB/card/processor needs a updated bios and drivers. These sort of things are going to happen to a lot of users, unless the software compensates or the hardware configuration is locked down to only supported hardware. It could be that plainly the PCI card and slot aren't the most compatible because their designs don't match up properly, but treat this as a remote possibility, PCIX has been around a long time and should be stable and perform strongly. If all else fails, try another board, and if it works, go back to the original manufacturer and say to them that you wanted to use their board as the standard platform for all your customers, but it has problems, "can you fix it". trying an alternative board will probably be cheaper than getting your programmer to do even more messing around trying to find the problem.

You might also want to make sure that the card isn't on a hardware shared IRQ, possibly with the video card. Usually your motherboard manual will have a layout of the slots that share IRQs. Probably not related to your problem with CPU utilization, but definetely may cause others to have issues with IDE-SATA controllers and sound cards.

thanks guys! I think we have it found the issue...we ran tests with the .cpp test compile from Epix and it works really well on both 32bit and 64bit cards..I will get a recompile and full installer today of our software...I think with all the dicking around and hardware switching I may have a bad install...I will post the results asap later today when this gets done...

will check the IRQ on this system...needs to be done anyway..have not done that yet...

BTW Obin, the FTP site is still up when you need it.

Once you start putting files up, I'll leave them up for a week or two.

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

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...

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.

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...

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...

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

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.

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.

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).

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

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

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.

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 :)

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.

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.

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?

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


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.