Emailed Rob, and he is busy, so eventually he'll get back here.

Who put up that nice case design picture a number of months back (two color, one red or green)).


<<<-- Originally posted by Obin Olson :
then i can shoot stuff with no dropped frames low cpu usage and full motion preview!

I would be happy to let some people try the software as soon as we get the basics really working well..you would need to buy a SI 3300RGB and a Epix CL2 card to use things..or you could get a 1920HD ALtasnse from SI! but that will cost a bit more -->>>

What about Gige?

How much does the processor need for 24fps 720p? I have just seen pictures of a Linux machine with new dual (core?) VIA processors, which means the 2W dual core processor should be available in sub-notebooks sometime.

Also I have noticed that notebook and 1.8 inch drives, have gotten greatly improved performance and density. So we are getting to the stage that a $500 notebook with GiGE will be enough.

You can get GigE accelerator boards, that help a lot with data transfer. At work, with 2 machines using accelerator cards if I remember rightly we have been able to get 3 streams at about 10MB/s. These also have the added advantage of taking the network traffic processing away from the CPU. Mind you they are quite expensive.

http://www.alacritech.com/html/gigabit_ethernet.html

Mind you I can't find the post about the thruput this project will need.

Just an idea...

There is a number of Gige cameras out from SI etc, with support planned in the capture packages? Some MB have it, and there are high speed drivers (100MB/s) for some Intel ones.

Thanks

Wayne.

Orinially I was very intersted in the Gige possibilities, guess I still am for that matter. Does anyone know if the Gige cameras also have a Cameralink ability that wouldn't limit the data to Gige rates(have your cake and eat it too)? Obin can the Epix card handle 1080P above 24fps, I know that sounds really greedy but what the hell! If the cameras or card can't really handle much above 1080P @ 24fps then I see no reason to stick with CameraLink.

Rob,
The GigE interface can move 100MB/sec. It can pack the 12 bit data - 2pix/3 bytes. It has an internal buffer so you can use average data rates: 1080p24fps is 1920*1080*1.5B/pix * 24fps = 75MB/sec - room to grow.

You can either get a 1920HD as a -GR (gigabit, remote head, essentially a camera link camera with an external interface and could be used with a frame grabber) or a -GE which has the interface built in.

The Epix 64 bit card that Obin has, besides being a fine paperweight, is a 64 bit/66MHz grabber. Camera link is limited to 85MHz clocks. The SI-3300 is single tap - you can move 12 bits at up to 85MHz and meet the CL spec (I've run it over 100MHz but not suggested for a product). The SI-1920HD is a dual tap - you can run the full speed of the chip. Two 75MHz 12 bit data paths. On the bus, this is unpacked so the peak data rate (not buffered) is 75MHz * 2 pix/clock * 2B/pix = 300MB/sec peak on the bus. *Danger* - the 64/66 Bus is a max of 532MB/sec and realistically 450MB/sec. You still can only cross the bus once. Matrox makes the Helios which can handle a 133MHz bus if you have it.

The bottom link is if you are looking for slow motion recording at full HD, CL is still the way to go. For a basic 24-30fps, GigE is good.

Thanks for the low down Steve! I guess in my own head I never really considered shooting 1080p for slow-mo, I always figured I would move down to 720p for that anyway. Obin I know that you were planning on taking your software into the Gige arena at some point but what would it take to get it there? Is it the sort of thing you would be interested in testing now (or in the near future) or would you like to get all the bumps worked out with Cameralink beta testers first?

we need SOLID robust CameraLink FIRST! then I will be looking at other things..at the moment things worked great with the 32bit card(but the speed is much to slow) and now with the new paperweight 64bit card we are having a much higher CPU% while preview and record then we should..I know it's OUR software because Xcap can display full 12bit color with no problems and black and white preview at about 18% cpu! ..this is good news because it's OUR problem not the hardware...we can fix this...

Sounds great Obin, I assumed that that is what your plan was but figured that there was no harm in asking. I have to finish up a promo video Im working on before I will have enough money to buy a camera, but its defintily something I want to do. I would really love to beta test your software when I get one!

Our programmer has CineLink running with 18% CPU at preview with 65mhz 1080p 24fps...I guess I have a bad version or a bug in my build..should get somthing early monday for tests..will keep everyone posted...

how is the 1920 Steve? is it a lower noise camera then then Micron 3300RGB?

You are using 2Ghz CPU, are you saying that the preview and capture works at 18% (400Mhz) that would be great, or just the preview?

Forgot to mention, over at the technical thread I have posted a few good things for the camera, including 300+GB high speed, low cost drives.

how high-speed Wayne? we need atleast 60MB/sec sustained not burst...

Hi-speed for a 320 GB drive. 36.8 to 65 (second from the top on the chart in the link, just below the Raptor).

720p*24fps at top pixel depth of 12bits per pixel = 33.1776MB/s. The ultimate cheap Indie option over the price/MB of the Raptor. Two could be used for 1080HD, if anybody wanted too.

Looking at my earlier post in the Tech thread, there is something faster than a Raptor, Maxtor Atlas 10K V (300 GB Ultra320 SCSI), but it is SCSI.

Thanks

Wayne.

If you don't already, trawl over http://www.storagereview.com/ for drive blah blah..

Maxtor Atlas 10K V [300GB SATA Details]
http://www.storagereview.com/article...8D300L0_2.html

Maxtor MaXLine III [300GB SCSI Details]
http://www.storagereview.com/article...300S0-2_2.html

and for a rainy day!
another quick microatx pentium M mobo with 64-bit 133 MHz PCI-X Rev. 1.0 slot http://www.win-ent.com/MB-06032.htm

ta,
DF

opps....

The Maxtor Atlas 10K V is the SCSI and the Maxtor MaXLine III is the SATA

Could this be of any help ?
http://www.arri.de/infodown/cam/broch/d20_e.pdf

It would be more complicated, by why not have a ram buffer that could easily sustain 60MB/s so that you don't have to use 15k SCSI drives to capture the footage.

That or it would it simpler and cheaper to capture to an 7200RPM four drive RAID 10, temporarily, then move the footage to other drives after capture.

I guess another option regarding a ram buffer would be to setup a ram disk in windows, then buffer the footage in that manner, or transfer between takes There is some free RAM disk software out there, that is supposedly pretty reliable. Just wouldn't want the power to go out before you transfered the data. If you would have to use the buffer then transfer the files between takes, which would be really annoying, but I guess it would feasible. At 60MB/s, you'd get a whopping 34 seconds with a 2GB ram drive. Any RAM above PC100 should have no problem with the throughput.

The Maxline is slightly faster on the inside and slower on the outside compared to the Western Digital 320GB.


Mark--
This has been discussed in times past, and I am sure the projects are already doing this, but if you want to post links and details that would be a help to anybody else doing a project.

The problem with transferring to slower drives, is that many of the slower drives are too slow to sustain a 60GB (or 35GB) read of the footage (unless the footage is compressed and the processor is fast enough to decompressed live) for playback and editing. So we are stuck with using more expensive drives, for the time being, or multiple ones of the cheap ones.

There was to be a 1300 720p camera (and I think Micron could do a new camera again), but by the looks of it Obin might be going to the 1080p cameras and scrapping the 1300 (has to many serious problems).


New Micron sensors--
I have looked through the Micron specs on their new sensors, and while the more expensive models have unspecific max Signal to Noise figures like >41db, the new cheap integrated mobile sensors (that might be suitable) specify exact max ratings in the low 40's dbs, rolling shutter, and I don't know about the smear and blooming problems have been solved. I don't know why they don't take their cameras to 48db, so at least you can do descent 8 bit footage, not to mention a solution to rolling shutter.


New parts, new commercial camera?--
Interesting things come up, I know of new all in one mobile phone chips (522Mhz Cpu), Mobile sensors that are fast enough, and faster 90GB 1.8 inch drives. Theoretically somebody could do a mobile with 720p (even 1080p with compression) with 2:1 (or 4:1 cineform) (over 2-4 hours on a Mobile!) compression or just an pro Eng codec (50-100mb/s nearly). Any volunteers?

The camera companies need to wake up and offer at least a phone camera. Imagine how useful this is for a camera news or doco person, let alone the average user,anything happens and instantly you have a piece to film it (though not the best footage) even a HD version would be welcome to a pro. People are far more likely to pay high prices for these than your average palmcorder.


Thanks

Wayne.

Hi Steve,

A while back I recall that the ETA for the Altasens based SI-1920HD cameras was in the March timeframe . . . is that still reasonably current?

SI-1920HD AltaSens
 

The first production run is shipping on the SI-1920HD. Many of these are going to integrators since what you need is probably something like Obin's code (or at least good support from something like StreamPix) to use the camera.

SO, the answer is: they are are shipping NOW. We have them being integrated by our GigE group, Epix and Coreco for capture.

ok .

we are going with 2 SATA 10k rpm drives

simple. safe.

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

SI-1300 Clock
 

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.