Software
 

Obin & Laurence -- I absolutely agree with both of you. Problem is, without a camera & card, I'm not sure I can develop that software.

As a first step, I thought it would be helpful to be able to successfully open & process a raw file. Then I might have enough confidence to buy the camera and continue development.

Obin, what comes with the capture card? For example, does it come with

1 - an SDK (Software Development Kit)
2 - documentation of the file format(s)
3 - sample files

Those would be helpful to get started.

Ask this of Steve Rob because I am not sure I *think* I heard somthing about a SDK. I will poke around and find out!! I may even work some type of deal like send you my camera for a couple weeks if you really need it for code writing...we can talk for sure about this as things progress . It sure would be great if you could find a way to cut the PC out of the loop once the camera was setup for capture...what about the device that Steve sells that takes cameralink and feeds it down a gigabit wire to a gigabit card on the pc? can this somehow be fed to a disk instead of pc? dunno just an idea....

<<<-- Originally posted by Obin Olson : It sure would be great if you could find a way to cut the PC out of the loop ... what about the device ...that takes cameralink and feeds it down a gigabit -->>>

I've had similar ideas, Obin, and I'm not exactly sure which way to go yet. I think it makes sense to go with CameraLink for now, since it supports a higher bandwidth than Gigabit Ethernet. We'd be set up for higher-resolution chips later on.

My current idea is to build the camera unit into a box with a Mini-ITX motherboard, CameraLink card and a RAID 0 2-hard-drive array. With appropriate software on-board, you'd be able to capture with a (pretty much:-) portable unit. Offline, you'd connect to the camera box via Ethernet & FTP and download the raw files; post-processing would take place on your PC later.

Either way, you need the software on your PC to take the raw files and process them, so that was where I was going to start.

I have some details here:
http://www.obscuracam.com/wiki/wiki/...esignApproach2

(I'd love to try out your camera, Obin, but I might end up buying my own before too long. We'll see!)

Steve -- does this capture card come with an SDK? Can you send me some of the documentation? Thanks!

Rob,
There is an SDK for the capture card. You can get Linux or Windoze support. The cost is $495 but there are no runtime fees so if someone developed a recording application, there would be no cost involved in sharing/selling it. It would be tied to the frame grabber somewhat. If anyone undertakes this and is offering the software free, I will give them aggressive pricing on the SDK and a discount on the camera.

There are two places software is needed - first, capture to disk in RAW format with display preview and basic camera controls (gain/digital exposure). The commercial options I know of are around $1500. CineForm may provide a lower cost option.

Second is the pre-post processing, if you follow that nasty phrase. Moving the RAW images through the basic pipeline - Bayer, YUV, any color balance, etc. to some generic format that can be used by the standard post processing tools.

I think Rob's computer would be perfect for the SI-1300 capture. Find a motherboard using the chipsets with integrated RAID - no bus traffic. Use cheap big drives.

<<<-- Originally posted by Steve Nordhauser :
Rob, There is an SDK for the capture card. You can get Linux or Windoze support. The cost is $495 but there are no runtime fees ... -->>>

That's exactly what I'm interested in!

Another question -- Do you have any idea if there are any similar boards in the Mini-PCI form factor?

<<<-- Find a motherboard using the chipsets with integrated RAID - no bus traffic. Use cheap big drives. -->>>

Exactly -- Mini ITX motherboards are affordable and many of them have integrated RAID and Gigabit Ethernet.

<<<-- capture to disk in RAW format with display preview and basic camera controls (gain/digital exposure) -->>>

Right, that software would be inside the box with a monitor output.

<<<-- Bayer, YUV, any color balance, etc. to some generic format -->>>

Yup, the conversion software would run on the user's PC or Mac after the raw images were downloaded from the camera box.

Why do we want to convert to YUV from RGB??

That seems like a big step down IMHO.

If possible, it would be great to keep the option for full-bit-depth 4:4:4 RGB files.

YUV
 

<<<-- it would be great to keep the option for full-bit-depth 4:4:4 RGB files -->>>

Absolutely, full 4:4:4 RGB (post-Bayer) would be available for output. (The OpenEXR format, for example, supports either RGB or YUV.)

In some cases you might need some processing that you can only do in the YUV domain. Some types of color correction, for example.

Also, some lossless (and near-lossless) codecs work only in YUV -- HuffYUV, for example, and Cinelerra's 10-bit uncompresed codec.

(edit - BTW, YUV isn't necessarily a step down -- it can still remain 4:4:4 and lossless. You don't lose any information other than a tiny bit because of the mathematical conversion involved.)

sounding VERY good. I did not know that ITX boards had pci or pci-x slots..ROB I jsut spoke with the cameralink card company and they will have a 64bit card in a few weeks forsale..that will allow a MUCH higher datarate = higher framerate and or higher bit depth all = good things ;) um what aobut this 10bit stuff? if I save as 10bit like the camera outputs how do you use that? I think that file codecs are 8bit 12bit and 16bit right? or?

I can't find any ITX boards with sata but lots of mini-atx with raid sata

http://www.directron.com/ideq200vb.html

<<<-- Originally posted by Obin Olson : I did not know that ITX boards had pci or pci-x slots -->>>

Yes, all the Mini-ITX boards I've seen have one PCI slot. (Mini-ITX is 170mm x 170mm)

<<<-- they will have a 64bit card in a few weeks forsale..that will allow a MUCH higher datarate = higher framerate and or higher bit depth all = good things ;) -->>>

Yes, definitely something to keep an eye on, but IIRC, we don't need anything beyond 32-bit for this particular camera.

<<<-- what aobut this 10bit stuff? if I save as 10bit like the camera outputs how do you use that? I think that file codecs are 8bit 12bit and 16bit right? or? -->>>

You're right, most codecs are 8-bit. (HuffYUV, for example, is 8-bit 4:2:2)

Most of the uncompressed codecs I've seen are 10-bit. For example, Apple's QuickTime has an uncompressed 4:4:4 10-bit codec. I'm not sure about AVI codecs -- I haven't seen anything other than 8-bit so far.

What file format will you be needing to use?

We need to keep the Rob's apart in this thread, heh.

Steve: I'm very interested (and the other Rob seems too) in such
an SDK and camera option. I'm all for open software on this since
there will be enough hurdles to take after we complete this.
Perhaps we could both work on the project together Rob?

A mini PC of some sort would be most ideal in my mind as well.
It should be more easy to work with than a chip which needs
programming and if we look for the right one has all the options
we need to hook it up to the rest of the world.

It's basically writing the camera's "firmware". Can you shoot me
an e-mail Steve with some more details?

well the question is if you save as a 16bit tiff then you waist the extra bits right? and make a file that is bigger then needed?

I will need 10bit or the max the camera can output so that in post with software like Combustion we can take all the bits and color grade the footage images are fine I don't have any need at all for avi or "video" files

<<<-- Originally posted by Obin Olson : I can't find any ITX boards with sata but lots of mini-atx with raid sata -->>>

Yeah, I'm having some trouble finding exactly the right board. I'm sure it's out there (or will be soon). This one is pretty close:

http://www.viaembedded.com/product/e...herboardId=261

... but has only 100 Mbps Ethernet. Painfully slow when downloading such huge files.

<<<-- Originally posted by Rob Lohman : We need to keep the Rob's apart in this thread, heh. -->>>

Too true! :-)

<<<-- Perhaps we could both work on the project together Rob? -->>>

Sure, I'd love to! Assuming, of course, that we can agree on the goals and detailed design. I suspect we're on the same page.

<<<--- A mini PC of some sort would be most ideal in my mind as well. ... It's basically writing the camera's "firmware". -->>>

Exactly. I looked into embedded chips and so forth, but that seemed a little intimidating to start out with. On the other hand, I'd like to write the software in a modular enough fashion that someone could adapt it to a fully custom hardware later on.

<<<-- Originally posted by Obin Olson : well the question is if you save as a 16bit tiff then you waist the extra bits right? and make a file that is bigger then needed? -->>>

That's true, assuming there is no compression (such as RLE). I'm not very familiar (yet) with what you can do with a 16-bit TIFF file. Assuming it can be compressed, the extra bits (containing lots of zeroes) will disappear.

<<<-- I will need 10bit or the max the camera can output -->>>

Absolutely. I think it's extremely important to find as many formats as possible to keep all the bits intact as far into the post-processing chain as we can. Ideally we won't "truncate" to 8 bits until we're doing the final encoding.

Can I assume that some of the software you use -- such as Combustion -- supports 16-bit TIFF files? I know CinePaint supports 32-bit TIFF, so I may take a look at its source code to see how it works.