But for various
reasons (file system performance being one, which is VERY
important in our real-time camera system!) a single file per frame
was not on option in our mindsOkay, so the IHD file is created to take advantage of the speed of the file system, in other words, to get as many sequential writes as possible rather than random writes with single files? If so, that's a pretty smart idea, and it's sort of like mimicing a DDR in a way, although they get to stripe their disk file system in a manner that is the most eficient for their file format rather than the cludge of NTFS we have to deal with (not that NTFS is bad, but I don't like the fact that it's proprietary and there aren't any open source implementations or even abilities to mount and write to it-you can mount, but you can't write).

That is correct Jason. It also offers a form of prioritized RAID
when you have more than one drive to record to. The fastest
drive will get the most frames to make sure throughput is as
optimal as possible. Ofcourse getting two (or more) drives
of the same speed will be better and in this case frame 1 will
be written to drive 1 and frame 2 to drive 2 etc. to make sure
throughput is optimal for higher resolutions and framerates.

Hi Rob,

If you're planning support for Quicktime, could you also add support for higher-resolution Quicktime Codecs for the online format, like Microcosm, None-16 (both are 16-bit codecs), or the 10/12-bit RGB codec from Blackmagic?

I'm assuming that if you implement a QuickTime writer it will be
able to use all the codecs you have installed for it. But then again,
I might be wrong on that.

Jason Rodriguez wrote:
kay, so the IHD file is created to take advantage of the speed of the file system, in other words, to get as many sequential writes as possible rather than random writes with single files?That's correct, Jason. We're starting from the assumption that the drive(s) will be defragmented frequently, so we attempt to get the best performance possible by doing as few file open's as possible and doing lots of sequential writes. During capture, there are no seek's.

Rob Lohman wrote:
I'm assuming that if you implement a QuickTime writer it will be able to use all the codecs you have installed for it. But then again, I might be wrong on that.I believe that's correct, Rob, but I haven't tried it yet.

Jason Rodriguez wrote:
Adobe's just introduced a proposed open universal camera RAW format file called .DNGThat looks interesting, but the site mentions only photography. Though I haven't read the documentation yet, I suspect that this format is optimized for still photography -- where a high frame rate is generally not a big issue -- and not for filmmaking.

Besides, if someone really wanted to use it, it could end up being very simple to convert from IHD to DNG.

so we attempt to get the best performance possible by doing as few file open's as possible and doing lots of sequential writes.Just curious then, why the 1GB limit when FAT32 has a 2GB limit?

Also do you think there will be a seek "hiccup" when the new file needs to be written, or is that what the RAM buffer is there to prevent?

Additionally, I think we'll need some sort of dropped frame indicator.

This all seems very exciting, but I'm wondering how far in the distance we're talking here, especially for Quicktime conversion.

Jason Rodriguez wrote:
Just curious then, why the 1GB limit when FAT32 has a 2GB limit?It seemed like a convenient "chunk" to use, and prevents problems if using unsigned longs for seeking.
Also do you think there will be a seek "hiccup" when the new file needs to be written, or is that what the RAM buffer is there to prevent?Exactly, the RAM buffer should smooth that out.
Additionally, I think we'll need some sort of dropped frame indicator.Yes, I have thought about that, but I'm not yet sure how I'm going to handle it.
This all seems very exciting, but I'm wondering how far in the distance we're talking here, especially for Quicktime conversion.The Convert software is very close to being released under the GPL; at that point, anyone who wants to can add QuickTime support. I have downloaded the SDK myself, I just haven't yet had time to dig into it.

I've worked with the QT SDK a couple of years back and it was
pretty painfull to figure out how everything needed to be done.
However, this was for reading a movie, not writing, which in
theory should be easier. After I'm done with my compression
stuff I hope to spend some more time with the convert application
and output formats and such.

Hi, I have been intrested in this project since I found vence camera 3ccd 1/2 inch I think a year ago.
well now i think I'm ready to have my own one.
Have the mony and the skills to do any mecanical and electric work but not idea off programing.
So i have checked sumix and SI web pages and both have great solutions 1st quest
witch ccd is the best?
I'm looking for a 1 cmos ccd proyect.
maybe the best would be going for SI because of the gygabite interface that aloud for a low profile computer to run it (power is an issue for a portable camera) also i have chaqued the soft they have and it seems that they offer the capabilities to record to disk under windows with access to control frame rate and few other setups.
sumix with usb2 suffer of cpu power consuptin also but wich is the best ccd and software to record to disk and control frame rate is waht may decide the way to go.
by the way thaks every body for this great contribution to cinema and to break the big movie monopoly.

The best sensor by far is the Altasens 3560 which will be in the SI-1920, and also a camera by Sumix, although Sumix's ship date is unknown right now. The SI-1920 is over cameralink and gigabit (but the gigabit interface is coming later).

BTW, you might want to check out the SBC83850 from Axiomtek, it's ideal for this project with dual SATA channels and a PCI-X slot for a 64-bit framegrabber.

When is the SI-1920 supposed to come out?

Hve you check this driver any ideas of how to aply it to a cmos censor
orange micro
400 Mb/sec. IEEE 1394 compatible (camera consumes only 200 Mb/s bandwidth)
Non-compressed full-motion digital video at rates of up to 30 Frames/sec @ 640 x 480 depending on your system configuration
1/4" Color CCD Image Sensor
62 degree angle of view
Effective Pixels: 659 x 494
PCI 2.1 Compliant
Frame size up to 640 x 480
Focusable lens from 1cm to infinity
Supports YUV 4:1:1, YUV 4:2:2, YUV 4:4:4, and RGB 24-bit formats
Millions of colors (24 bit)
Supports Plug-and-Play specification
Supports up to 2 cameras per bus simultaneously
Connectors
6 foot cable with 6 pin IEEE 1394 FireWire connector
Package Includes:
iBOT FireWire Web Cam
Software CD with drivers

are SI suplying software for the camera ?
How it would work?

Thy guys here on the list like Rob S., Rob L., David Newman, and Obin are supplying software, although there is other software you can purchase.

The SI-1920 should be shipping by the end of October.

Hook the camera up to a PC and have fun!

Just note that we are actually still *working* on this software.
It isn't out yet. It does work already though!

Will the SI-1920 be a rolling or global shutter? How many stops of latitude do they predict?

Rolling shutter, although when you run it at a high enough Mhz, that's no longer a problem.

Also I've gotten 10 f-stops out of the chip at around ISO 500-type noise/grain, so there's lots of dynamic range in this chip, able to handle highlights and shadows.

then is this chip better then the altens chip ?
I heard that the altens have sensitivity issues.
hey rob s, rob l and david abut the software waht can you guys tell me?
for waht I have read you guys are working on a camera friendly user interface is taht right,

Marto Lautz wrote:
then is this chip better then the altens chip ?From what I know, the AltaSens check has far better image quality.
for waht I have read you guys are working on a camera friendly user interface is taht rightThat is correct. Rob Lohman and myself have been working on a two-part system.

The Capture app (ObscuraCap) is like the camera's firmware and is designed to be as user-friendly as possible. It captures the frames and writes them in lossless, raw form to disk. Sort of a "digital negative."

The Convert app (ObscuraConvert) "develops" the raw files into formats that are more suitable for editing. It is currently command-line only, so it isn't quite so user-friendly. But it will be released soon as open-source (GPL) so a UI (and lots of other features) can be added to it.

Marto:
The SI-1920HD is based on the latest Altasens (3560, not the older chips). Jason has all his facts about this exactly correct including the expected ship date with the newest sensors. Software supplied from us tends to be interface specific - either what you get with the gigabit or frame grabber and is very industrial. That is why we have people here working on cinema/broadcast solutions.

If you are not joining in on the development, I would suggest letting the people doing the software have about another month unless they invite beta testing. Right now the work is being done on the SI-1300 (720p), may move to the SI-3300 (1080@24fps) and certainly will end up at the 1920HD.

Thanks Steve,
Sound like i would have to wait, any way I don't know much about programing but in electronics and optics I can help,
please let me know if I can contrivute on anything.
may be desing and make a skeleton ergonomicaly for the camera because i have tools to cast and weld aluminum my best camera that I have used ( I'm using it at this moment) is aaton.
Altasens chips are working at with sensitivity at the moment with an acceptable noise rate?
I may can have involved a friend that do programing.
waht is the plataform you are building the interface on linux well UI I think is cross plataform unix osx linux if I'm not wrong.

The Altasens chip can go up to ISO1600 for sensitivity-that's very sensitive :)

ya but at cost of gain that means noise.
is there any test pictures ?
it is going to be sell by SI?

<<<-- Originally posted by Jason Rodriguez : The Altasens chip can go up to ISO1600 for sensitivity-that's very sensitive :) -->>>

Yeah, I'm still droolling.

Marto, what you said is right, I would still like to find out what the bottom line is myself. I think Jason mentioned 100db max SN in the other thread, at that level you are putting 12-bits=approx 72db, allowing for 18db gain before it affects the bottom bit on average, that would be extrordinary (-ingly usefull).

Hey, does anybody know of a site that tells you the performance curves of human vision, the books here are not good enough? I am interested in how resolution, range and sensitivity of the luminance and chroma change with brightness.

I thought the noise levels of the chip when the gains were set to 0 to be very acceptable, and the dyanmic range was terrific.

Update:

Looks like I will be shipping the 3300 and Epix frame grabber off to the software developer for final work..we can no longer do all the testing via remote over the internet ..the software writer needs to see the issues with display and capture ...I will keep everyone posted as always ;)

I have just posted a few things on a lowend camera in the tech thread, it's pretty high minded stuff, and not helped much by the 5+:1 Jpegs, but worth looking at.

http://www.dvinfo.net/conf/showthread.php?s=&postid=228877#post228871

Rob.s, can we have a RAW capture for this camera:

http://www.guardian.co.uk/space/article/0,14493,1318911,00.html

Now if we "dropped" into a few politicians' press conferences with that, it would sure solve a few problems (and make some pretty flat debate) ;)

Rob.s, can we have a RAW capture for this camera:Sure, no problem. But I think the frame rate will be pretty slow, given a frame size of 100K x 100K :-)

Rob S. how is your capture app doing?

are you getting good preview framerate out of it yet?

Obin Olson wrote
are you getting good preview framerate out of it yet?I have been so snowed under I've barely worked on it for about a month. I'm getting around 25 fps on the preview. A little bit of lag, but not bad -- it's hard to tell exactly how much.

When you mean "not much", is it noticeable? Or is it just a slight amount that is barely noticable? Does the lag reduce if you turn off the color preview and simply go black and white?

BTW, do XCAP or StreamPix have lag in their previews? Just curious.

everything has lag Jason...that is jsut how it is

Yes, I realize that everything (electronic) will have lag, but the chief issue is HOW MUCH lag.

I don't mean to be making this an issue, but it can quickly become one if there's too much lag to follow fast action. In other words, if you're 5-6 frames behind, that can become quite a hinderance in recording fast moving footage.

HUGE progress today!!

things have been reworked and the CineLInk is looking REALLY good..gone from 100% CPU on preview to about 40-60% cpu..frames are SMOOTH now and the image slicing is GONE..not much time now..I will update later...I am excited!! Steve, don't choke on that muffin! :)

Hey Obin,

Great news!

BTW, if you can, how many fps are you getting to your hard-drives? I know you said as many as you want, but realistically how many, at least with the SI-1300? Also are you still recording RAW files, or is there another format that you're exporting to?

Also how fast is your CPU?

I have a glitch in this beta I just got but I should get around 30-50fps 720p on a fast SATA disk drive...maybe more with that special 10,000rpm drive someone was talking about on this board...plus it will save images on 2 disks at a time. This will speed it up alot..I will let you know

still RAW files and converting them into tiffs 8 bit at the moment..very soon 16bit and quicktime Sheer or any Quicktime codec you want ;)

CPU is a 3ghz tower machine at the moment...will be a Mobile Intel 2.6 or 2.8ghz on the micro board

26.37 - 43.95 MB/s sustained on that SATA drive Obin? Which
drive is that?

I get 26-30MB sec on a standard SATA disk drive 50-60MB/sec on 2 drives


I will test the 3300RGB today with 1/4 quad preview and see how that is...and we are working on the "bug" that is not allowing save-to-disk


Rob what is the datarate of the 3300rgb 1080x1920 12bit raw at 24fps? and what is it at 8bit 24fps?

don't we have a table on this board with all the real-world datarates of the SI cameras?


Jason what was the link for that tiny motherboard..it's about time for me to order one ;) for testing!

I know it was not this board:
http://www.kontron.com/products/pdproductdetail.cfm?keyProduct=40088&kps=1082&kp=75

Obin,

Again, your programmer should easily be able to supply you with
such a table. But here are your answers:

1920 x 1080 @ 24 fps : 12 bits in 16 bits = 94.92 MB/s
1920 x 1080 @ 24 fps : 12 bits packed = 71.19 MB/s
1920 x 1080 @ 24 fps : 8 bits = 47.46 MB/s

so RAW 12bit would be 71MB/sec?

If you pack it (ie, not put it in 16 bits), yes.

the board was the SBC83810 from Axiomtek

http://www.axiomtek.com/product_detail.php?model_num=SBC83810&majorcat=Embedded+PCs&subcat=5.25%5C%22+Petit+Boards+%285.75%5C%22+x+8%5C%22%29

hope that helps (and hopefully I can start building one soon too :)

thx Jason that is it

Hey Obin,

The fastest you're going to get is 2.0Ghz, because you're using Penitum M, not the Pentium 4 M (the Pentium M is much faster BTW, even at 2.0Ghz, and yes, I know, it's confusing).

do you think the 2ghz M will have enough power for 1080p 1/4 quad preview and raw data save?

To anybody interested, take note that usually you have a minimum lag of around 20 milliseconds at the video board level.
At least expect to have that delay if everythings works perfect......