Also Juan, I'm not sure about Linux support for all the configurations that we're going to be using on our stuff. For instance, without good drivers, we may be in for a life of kernal panics with the incompatabilities that could be present with these custom motherboards/chipsets.

Rob L on GigE:
Actually, there are SDKs available for both Linux and Windoze. Same with the Epix frame grabbers (whose SDK you all have grown to love).

Magnus:
http://www.siliconimaging.com/Sample...th%2012bit.zip
http://www.siliconimaging.com/Sample...+%20filter.jpg

RAM:
I'm not sure at all of the value of putting a lot of RAM into your real-time systems. Post processing machines sure. For real-time, you have to be running out of cache for most of the processing and row buffering so all you really need is some FIFO-type external buffers to average the load. The bottom line in real time processing is either you are keeping up, or you are not. I guess with a really big RAM and "almost fast enough" processing you are gaining some recording time before you drop frames.

USB 2.0 speeds:
Before you rely on any interface for off-loading gigabytes (100's of gigabytes?) of data, be sure to benchmark it. I was told that windows drivers for gigE transfers are at about 200-250Mbps. I haven't seen much continuous transfer on USB 2.0 above about 320Mbps although I haven't looked at drives. I don't know about firewire. We may be licensing a software product that can transfer over gigE at 800Mbps.

SCSI:
If you are doing SCSI drives, I would put the drives in a separate box (better cooling as the fast drives get hot) and a SCSI controller on each computer. If you have two drive RAIDs, you can swap them and keep right on going. Certainly, if you record on the RAID as fast as you can access it and record 45 minutes, it won't take less than that to off-load it. The fastest way is to have it right on the bus going to a bigger array on the same PCI bus.

Steve: I stand corrected on the GigE. I thought those drivers
where only developed for the Windows platform. My bad.

As we stand now we try to keep everything realtime. Recording
to memory or buffering in large amounts might be interesting.
We'll have to wait and see.

I'm assuming though that these new 2.5" SCSI drives won't be as hot as their 3.5" brethren. Am I incorrect in thinking this?

Jason on SCSI:
OK, I'm clueless about the new drives. I'm basing this on fast drives spin fast and generate more heat and when you pack drives they don't cool well. Just a bundle of generalizations that can probably be avoided with proper design.

How do SCSI drives compete with SATA for cost, density and speed? The only benchmark I have heard from a a good source is that 15KRPM SCSI drives can do 50MB/sec across the entire surface.

The 15K Cheetah's are very nice drives, but for my purposes (or anybody doing portable), they're power hogs (and loud), so I won't be messing with those.

I think then for right now I'm going to start out with my original idea of up to 6 laptop hard-drives (across 3 IDE channels), using the 7K60's from Hitachi which spin at 7200RPM. I'll start out by testing three drives on three channels first, and see if that is fast enough. I'll then start adding drives to see when I can hit that magic 120MB/s sustained number (hopefully I'll get there). If I'm not making it by 4 drives across the 3 channels, then I'll just return the drives, and go with SCSI. But I'm thinking that 6 drives on all those IDE channels should be enough.

Actually, if worst comes to worst, I can stripe a five-drive array using 3 IDE channels, and then another 2 across the SATA channels (with PATA-SATA adapters).

OK. Anyways, 7K60's it'll be for now until further notice :)

hmm I am going with 2 SATA 10,000rpm disks for now..easy cheap fast stable..should work fine for 24p 1080 I hope. I know I can use it with 720p no problem, I have done that with 2 ata disks at 55fps 720p

So you can tell that if your are moving fast with your camera, the two 10,000 rpm disks won't suffer any damage?

Hello All.

Thanks Steve.
Do you know at what fps and such that the images were taken?

Best, Magnus Andersén.

Steve, the 1920HD lighting range looks a lot better, almost natural. I also found a bright whitish pixel west north west of the top of the picture frame. But barely noticable, very good.

I was wondering, with that auto gain feature (or was that the Pana), how it goes in a ambiently lit room with a clear (no tint film) window in the background showing a bright sunlit day. A good test of range.


Thanks

Wayne.

Magnus:
Sorry, we try to put some information about the image capture in the file name but that is all I have. Frequently our test images are generated for specific potential customers or situations and are not meant to be universal.

Wayne:
Remember, that these Altasens sensors we are experimenting with are pre-release, engineering only units. Blown pixels and columns are part of the deal.

There is no auto gain. There are independent color gains (analog), a global gain (analog) and a global gain (digital).

Juan:
I think that cameras with disks are like racing cars - it is not the moving fast that gets you, it is the sudden, unexpected stops. ;-} Don't drop cameras with disks?

Hey guys, have another question, especially for Obin and Rob:

Does disk access speed mean as much as disk transfer speed?

I'm actually now thinking of incorporating the small 1.8" Toshiba drives like the ones used with the iPod, etc. Toshiba has a new one that is only 5mm thick, and is the size of a credit-card. I'm planning on cramming 8 of these drives into my case design, and then striping those across four IDE channels as RAID 0. The only hestiancy I'm having is that that disks only rotate at 4200RPM, so the disk access time is 15 msec average, almost twice as slow as a 7200RPM disk. RAID configurations do not help disk-acess time, but they do greatly speed up the disk transfer-rate. Jeff Kreines, for example, is using 12 iPod drives in his Kinetta, and those "magazines" are rated at up to 72fps at 1920x1080 (for future chips). But he told me that he's using sequential writes, because the disk-access times are too slow for anything else-which it totally understandable.

So what I'm worried about is dropped frames, not because the disks aren't fast enough (eight of them definitely will be), but because they can't handle the capture-to-disk, or can't spin up fast enough, etc. for sequential writes to occur when I click on capture-to-disk. In other words, with these capture programs, is there a momentary "spin-up" time like many NLE's have, where space is allotted for a sequential write, and the disks allowed to get up to full speed? Or is it simply a "crash record", and the disks just have to keep up, and there is no concept of trying to keep sequential writes?

I'm hoping that eight drives (two seperate IDE channels on two different busses for a total of 4 IDE channels, so I'm not limited to 32-bit PCI bandwidth) should give me the bandwidith to record at up to 48fps, 1920x1080.

I think it's a bit too early to exactly tell what will work and what
will not. The software Rob S. is developing with some assistance
from myself will write sequential to each disk and just gives the
frame to the next drive in the queue that is available. So in theory
it will probably work. But till will tell how well such systems will
work and whether somethings need to change in the architecture
or not.

As Rob Lohman said, it's difficult to tell until someone actually benchmarks a system. But with enough RAM to buffer the frames, I expect that throughput will dominate for the most part. During capture, the writes happen continuously -- there are no explicit seeks.

On the other hand, if the drive has to seek very often (due to fragmentation, OS stupidity, bad sectors, etc.), that will reduce throughput.

I was planning on software RAID 0 though, so there's no disks to "que", there's only one very fast, massive disk. But again, it would only be fast for data transfer, not actual disk access times. Because of the slower 4200RPM nature of the drives, random access wouldn't be all that great.

And again, I'm also wondering about frames writing to disk-is there a slight "buffer" time, or time to spin up the disks, or does it simply try to dump to disk, and you might get dropped frames at the begginng as it's trying to access the disks and bring them up to full speed?

Jason: we are doing a software form of RAID, therefore you
really do NOT want to setup an OS RAID. The advantage of this
is that you can dynamically add or remove disks (while not
recording at least) and faster drives will do more than slower
drives to lower the chance of dropouts (which a normal RAID
cannot do, it always is sequential).

frame buffers - that is what we are doing - you can set it from 10 - 40 frames

also we are writing to each and every disk like a raid without the RAID from the OS or hardware so frame 1 writes to disk 1 frame 2 disk 2 frame 3 disk 1 frame 3 disk 2 etc

more disks would = higher framerate of capture

You can set the buffer to as much RAM as you like -- it will fill up RAM until the disks are ready and then start writing. You should not have any dropped frames unless the RAM buffer filled up before the disks were ready.

If you think a delay is a good idea, I could probably implement one, but my thinking is that most people want to start recording as soon as they hit the button.

And as Rob Lohman said, we are doing a form of software RAID 0, but you can use it with a "true" RAID 0 if you really want to. I suppose there might be some benefit to it, such as if the RAID controller had on-board RAM as well, to provide a second buffer. As Rob (and Obin) mentioned, though, software RAID makes it easier to add more drives later.

No, delay is a bad thing, but I just wasn't sure how you guys were implementing RAM buffers, etc. What you guys have going sounds very good.

BTW, since you are using a RAM buffer, how about a method where, depending on the amount of RAM you had, there was a mode that had a continuous loop capture, and when you hit "record" it first layed down the RAM buffer, and then started recording to disk-so the RAM loop is always being refreshed every, say 5 seconds (again depends on the amount of RAM you have), and then when you press record you get the previous five seconds before you press record plus the footage you're currently capturing. The Panasonic SDX900 has a similar capability for documentarians who don't want to roll, roll, roll trying to capture a "moment", or for that sports guy that only wants to record the home runs :)

That's a very good idea. In fact I think it would be doable with very few changes to the code.

I thought you would be doing this anyway, but going on from what Jason suggested, often many things happen before you can hit a button. So maybe optional on screen (or physical) record buttons, that the user can setup from the menue system, and mark buttons, where you can select to record the previouse footage or mark the exisyting footage. With good drives you have 50-72 MB/s capacity, so a single chip 720p can catch up. You could have 3+ buttons, 10, 20, 30, 1 minute etc, or just use double click (like the computer mouse does), triple, quad, pentaclicking of the record button to activate each (crude, but simple and effective). This is mainly for documentary and news gathers though.

I would not use more than half a buffer for this. You want room
to catch startup delays and harddisks not keeping up etc.

I was thinking something like 10-15sec max. The SDX900 has 15 seconds, and that seems like plenty when you think about it. A whole minute would be a PITA if you want to do something with the camera after recording, because you're going to have to nurse it for a whole minute aftewards as it's trying to record back to the hard-drives.

Thats why I suggested that the user be able to congfigure the times they want and ignore the other options (I minute is extreme, for most of us, but somebody will want 2 minutes) Besides with 50 or 70+MB/s sustained mentioned here for certain drives, is a number of times more than 24fps 720p 8-bit requires (talking more doco here), so you shouldn't need to cradle it for longer than 30sec after the shot, and likely only a few seconds most of the time. For Cinema shoots, it is a non issue, as you only have to cover a few seconds for disc startup. Actually, before the latest EC power requirements laws came into effect a few years ago, older drives used to stay spun up for ages, and server drives might still do this.

But just how robust are the drives, can we run around with it?

if you use the iPod drives like I'm thinking of using, they are rated at 500G's of shock in operational mode, and 1500G's shock non-operational. Even the 7K60 drive from Hitachi (2.5" 7200RPM) will take 250G's operating and 1000G's non-operational. That's like dropping it without breaking!

Jason I need your help..can you please download the latest SheerVideo codec and try it with some footage on your FCP HD system?

In 10bit..I need to know what the best export option is for CIneLink..we are working on that now and it seems that codeing for TIFF is not easy...I say we just go from RAW files to mov with the sheervideo codec if MAC can edit that at 10bit

how is the Convert software coming Rob S or Rob L?? maybe we should work with your stuff for conversion?

I can't remember what G's mean what anymore, but I think (only think mind you), 100G was like droping it from one meter on concrete (though I would imagine thats most of the times and not gauranteed). So that's definetly past cradeling it. For a doco configuration, I think IPOD drives would be excellent.

It's a pity we don't have more latitude in processing power for this project, as 50/100Mbit or cineform codecs would allow us to use cheaper single drives for news and doco configurations. I think Elphel will have newer codec FPGA out this year. If we could put together our own controller boards cheaply, I could suggest a raft of parts to use (I have looked into pocket 3D game system and PDA design in the past), but doing that gets very, very, expensive, even just using an advanced reference developement boards. Hopefully Sumix will do it.

Ouch! $1800 for one micro OLED display! from eMagin

Wayne:
What am I, chopped liver? If we can get a tested codec board with compression, I'll consider a camera with it built in.

Sorry Steve, I was refering to our pc projects, and what Sumix was doing with their compressed camera product, I wasn't refering to SI.

It's in pretty good shape, but I'm not sure when it will be ready for initial release. I'll get back to you as soon as I can.

I think that's the problem Wayne, that you were only talking about Sumix and not about SI.

(How's that song go ... "Anything that Sumix can do, SI can do better" ...? ;-)

I was only kidding, dude!!!! :-) I have no axe to grind, SI vs. Sumix.

OK, I didn't think you were trying to grind an axe. I'm just irritated by people needlessly dancing on my toes in the past. I wasn't questioning you, just what was implied.

Toe dancing is fun ;)

BTW Wayne how can you post in this board after the email you sent me?

I would have thought you would NEVER come here again after that storm ...

Hey Obin,

If you use Sheer without recording a Log instead of Linear signal, then you're loosing a very important 2-bits of information (either in the highlights or the shadows-both are bad).

I'd suggest that if you really want Sheer (which is a good thing), that you look into a 10-bit log format, not linear format, which again will clip information, especially from the Altasens.

I'll download the new Sheer when I get home and see what I can do. It may not be till Sunday that I can play around though because I have a meeting with the producer this weekend of a film shoot coming up, and then auditions are Tomorrow and Saturday. Hope the delay isn't too much for you.

BTW, Wayne, I'm slightly skeptical of Sumix, just because it seems as though their QA isn't quite all there, and also the Altasens over firewire800 is going to be missing a lot of bits somewhere along the line. Not quite sure how you're going to get a fast enough frame-rate to get rid of that rolling shutter problem and still maintain a high bit-depth. Might be good for doco cameras, but I'm hoping for something more that can be used for feature-quality films and VFX (greenscreen/slow-motion).

Also Steve, I noticed in the brochure that you can record with the Altasens as low as 4fps? Will that be true for the SI-1920 with the EPIX framegrabber?

Thanks again everyone.

Jason:
Slow is easier than fast. In a free running mode, our programmable pixel clock can go down to 20MHz, but on the Altasens dual tap that is two pixels. So, 50ns x 2.1Mpix is 9.5 fps. Slower free running might be possible - I will have to check to see if there is something else going on. You can always use it in single shot mode where each frame is requested from software. The gotcha is that since it is always integrating, it takes two read cycles to get a good frame - the first clears the sensor of its current integration and the second is a good read.

The XCAP software lets you record every 'Nth' frames which is nice for time lapse. I believe this free runs the camera and just stores certain frames.

FIne Jason..do it as soon as you can !

thanks!

Jason, thats why I quoted Sumix's "plans", I'm a little skeptical too, the level of sophistication they are aiming for is high, but the proof is in the pudding and Ill wait to see if they deliver. I can understand it from the Asian business perspective: keep quiet, take advantage of the opportunity and do the work, then attack the market. If that is their plan then we might be in store for something with their second round cameras. As long as they have good real cinematographers, and videographers to help in the design and beta test, they should not do too badly. If they are as good as their plans, it is likely they are reading everything here, to learn more and improve their product.

They are making all the right noises (but proof is in the pudding again). FirewireB is supposed to deliver 100MB/s (single line same as Gigabit Ethernet throughput). They are aiming for a compressed camera, in the second round of releases, which is quiet sophisticated. That would require on camera processing, and memory buffering. But it would be simple for them to build up to this by first implementing memory buffering to allow high shutter rates and maximising bus traffic, pixel packing, and the log gamma curve (they were talking about) in the first release camera. With all these groups doing parallel projects it worries me. Even I was thinking of doing one next year.

By the way Jason, what is "BTW", and what did you mean by "QA" (Question and answers?).

Now to bed.

BTW- By the way

QA- Quality Assurance

Still not sure about FirewireB if we're needing 64-bit frame-grabbers for the Altasens. They're going to have to clip bits somewhere. In other words, you're not going to get a high-speed camera.