What are the camera issues?

Vegas is supports scripting, couldn't anybody write a script to capture the needed files?

What i was talking about focus was the reason you don't have pl adapters for b4 bayonet cameras. The nominal focus plane is so far behind the lens with b4, but with pl it is pretty close. When a prism is used the length to the ccds is increased by maybe an inch. This isn't so bad for zoom lenses but for primes it can be a little pain. But it will still work like you say, just a certain range at one of the ends will not be able to focus i suspect.

Camera isssues pertaining to to getting a specific camera to do what you want it to. Like i explained earlier, IBIS looks to have bad colour filters, so trying to compensate for this is really hard. Also many cameras used only work in a rolling shutter mode, or they just can't get it into global (not sure if this was solved yet, don't think it was), which is okay for sationary objects, but when something moves in scene it looks like it becomes askew.

Depending on how powerful the scripting language for vegas is it might be able to interface with a cameralink camera, but i honestly have my doubts. Most scripting languages are designed for doing things in a program, not doing hardware capture. After being compiled the script will likely be very slow and processor intensive i suspect

Michael: please take your time to thoroughly read through all the threads etc.,
there have been a lot of talk already about different options, possabilities and
what would or would not work.

These systems are highly complex and an NLE (even one like Vegas with its
powerful scripting) is of no use capturing from such devices if they do not
follow a standard it understands.

Cameralink is not something that is used in the "normal" video world. Besides,
Vegas scripting does not prodive access to capturing, neither would it see
any cameralink board or any camera that is not connected to DV or an
analog SD capture board.

If it was as simple as that we would have a lot more finished camera's already.

It all seems incredibly complex. I wonder how the Drake folks did it. Their camera seems to record to an in camera HDD and it all runs on batteries. Since it's uncompressed 4:4:4 720p, it seems even PC could have a hard time capturing it without dropping frames. It would take a very powerfull machine. Now, how the Drake does it all in camera? Just the power consumption for the computer and the HDD, specially if it's a raid, would be above most batteries. Very intriguing.

I did read through the whole Drake thread. But it didn't explain much actually. The other thread is like over 2,000 posts! Just to long I guess.

How drake exactly did it is uknown at this point in time, but I have two guesses:

1) a computer running linux, like some embedded system

2) an FPGA or other processor programmed by them

Both could handle what they are doing if the right hardware and programming
skills where put together.

Depending on how they store the data it is actually quite feasible to do with
current harddisks, remember, they are storing 8 bit data, not 10 or 12!! Also,
if they store the original bayer data (more efficient) it will require this datarate
for 1280 x 720 @ 24 fps:

22,118,400 bytes per second, or 21.1 MB/s.

If it is not bayered it goes up with a factor of 3 to get 63.3 MB/s (which is
a problem).

Perhaps they are using two harddisks with a (software like) RAID solution,
not that hard to do.

True. But as you add HDDs you also increase power consumption. I think what makes more sense is what you said, they store the original bayer data. (As If I knew what's that LOL).

Linux has some great HD appliacations by the way.

Read up on Bayer at this URL: http://www.siliconimaging.com/RGB%20Bayer.htm

Since there is only a single chip in these camera's you have a problem to
get color (since basically all these chip are mono [B&W], except for one
design which is expensive). What they have done is add a tiny color filter
to each pixel on the chip, so each pixel only filters a certain color.

Since the human eye is more sensitive to green the green pixel is used the
most often, so 50% of the pixels on a chip are greenm, 25% are red and the
last 25% are blue. Now to get the full color information you need to re-sample
this information to RGB (red, green & blue), or 3 bytes per pixel. So your
storage requirements increase 3 times.

It's much easier/better (perhaps) to do this after capture on a dedicated
computer, this dramatically decreases processing power, storage space and
bandwidth.

The "downside" to having this bayer chips is that you can debate if they are
really HD or not (since for a 1280 x 720 sensor you would have a resolution
of 640 x 360 for green and 320 x 180 for both blue and red). However,
depending on the quality of the de-bayering algorithm (to get RGB) you can
get some excellent results.

The quality of this algorithm also determines if you have unwanted effects
like fixed pattern noise (where you can "see" the holes in the color ranges
due to missing pixels etc.).

Stepping down/or up the lens, or using an ND, would allow you to move/compress the image into this extra range for extra latitude. CCD's and sensors in general have latitude problems compared to Film. Wouldn't the actual dynamic range be a function of well capacity and noise (QE, fill factor, pad size, a lot less so as they more affect where sensitivity starts, and where the range window is). I'm curious how the broken down noise values of the IBIS effects the true range, and what SN they translate into. I had a try but the SN/Range figures turn up too big, or too small.

The Ibis uses a new mechanism around the photo site to gather and calculate the photons missing the primary site, give it near 100% fill factor. Other sensors use microlens to gather extra light to the photo site, they can not gather 100%, so some light misses. The Micro lens restricts maximum aperture (1.4 for acceptable image I understand) while the Ibis allows super-wide apertures allowing a number of stops (double) more light, and 35mm like DOF (0.75 aperture). Of greater concern is the size difference between the sensors.

The QE of the Ibis is about the average of the 3 different QE values for the Kodak.

Now this is interesting, I suspected there could be something in the filters, but received no confirmation of this. We are still getting more photons (and I believe that one of the film camera companies has a way to use this spill over to increase accuracy in green and calculate it out in the blue, but still very massive in size). Diohcotic?? colour filtering is pretty standardised technology, you would think they would have had similar performance.

Actually Sumix is hoping to attempt one.

I have not seen an SN for the Ibis, what is it?

Red Lake is expensive, I think you will see 2 times difference in price of some of these manufacturers. I mention the Lynx, because there has been much interest in on head programmable computer/FPGA. In a GigaE or Firewire camera there is the possibility of controlling an hard disk from the head (cutting out computer). If you can somehow route external controls into the box (say through serial port) and have preview port (on some cameras) and lens control, you completely eliminate the computer and make the whole system development very simple. If you haven't bought the Kodak development kit yet, I would factor in development costs compared to buying the cheapest comparable all in one camera.

Actually, we have heard of 100euro for the Ibis (maybe lower), Micron is cheaper again. But these are quantity orders (not sure wherever it was small quantity (less than 1000 to 100, or above 1000-10K)).

Hmm, your onto something, I wonder if somebody already has them?

On Juan's suggestion (wasn't I rubbished for suggesting doing a three chip prism before) that equipment seems a good price. If you google D.I.Y/home made clean room and vacuum chambers etc I'm sure you will find some (there was even one for making a CRT tube).

A prism should be available cheap, they are mostly just a chunk of glass. For prototyping you could (theoretically) remove one from an compatible defunct camera. Now Panasonic do cheap prism (3M do cheap projector prism technology so might also have CCD prism). There are a number of optic manufactures around the world, including cheap ones in third world countries (like India) that may even supply to bigger companies. They might be a avenue to get cheap prism once you have finished prototyping. But I think 3 chip will be very expensive, and much work, for small operation like yours (you have to learn optics and problems with HD prisms etc).

It is good to see you getting support here, I wish you luck. I am needing to rationalise my time into more constructive areas at the moment, so look after Keith guys.

Wayne, I think your right about all the factors that influence lattitude but i was unaware that ibis are using some sort of new method other than microlens.

All I know is that it clearly states in the IBIS spec doc that Peak QE for IBIS is >30% but averages around 25-30% and all the colour filter response is given as a relative number.

As for colour filters, well before i compared i assumed that they would be similar, but it really appeared that the blue filter was really affected by green which totally surprised me.

S/N ratios are just used to describe the relationship between the amount of signal and amount of noise. This has been the big problem with cmos for the last several years and is why it hasn't been used much in any type of high end camera, the S/N ratios were hovering around the 40-45 db mark while an interline ccd would be around 55 db. Now, considering that these are logarithmic, that is a huge amount of noise in cmos, but recently cmos has had a nice bump that brougth them up to high end quality. A few years ago nobody would have taken cmos seriously, but thats technology for you. As for the actual numbers, well if they don't give it out than it is really hard to say, but i would suspect that ibis is close to 60db which is good.

I'm seriously thinking about the 3 cmos thing now, and I have factored in the development kit for kodak, but I'm unwilling to make a big purchase of several thousand dollars and might end up with nothing at all so that is why i'm hung up on development now. If i can get it to work perfectly in a simulation, then i don't have to worry so much about designing as I go.

I wish you luck Wayne in all your real world endeavours, i'm gonna live in twillight zone this summer, it ought to be fun and i just might make it out with a camera.

Keith,

you are on a good way, but debayering on a mc/fpga unit? It work, yes, but how good? A bad or poor debayer is like a poor translation software. It translate words, but you dont understand sentences. A poor debayer can produced artefacts and bad colors. And you got only a low resolution. This is what Rob Lohman wrote. But with a good debayer, adjusted at the sensor color filter values, it produced also a high resolution picture. But it is a hard way to write a good debayer and sometimes we god new ideas. Thats why with Drake we do the final debayering in post. For preview, we use a fast, but not the best bebayer.
Keith, for others, please email me.

There are NLE software that do RAW/uncompressed capturing, I am not sure which ports they use. One is the freeware Linux Cinelerra from http://www.heroinewarrior.com. A driver could be written to recognise cameralink/GigaE/Firewire (if not already supported) capture and translate the camera format to native internal NLE preferred format, and translate camera controls. This requires a lot of skill/experience and is best handled by an established driver writer (though it might be possible for a good programmers to intelligently glean the best methods from the existing code (still difficult).

You realise that this is probably going to be an cheap Altasens programmable head with compression, makes me wonder if hard drives and preview monitor canbe attached to it with the camera micro-controller replacing the computer.

I was just expressing that IIDC is not a widely reconized format for raw over firewire and most nle's won't see the camera. With programming anything is possible.

What sumix has told me is uncompressed via Gige and if people are really interested they might do compression in the head, but they seamed very doubtful and more that Gige would be standard and completely necessary.

I barely have some timing code written for the fpga yet and i'm not sure if i'm going to even use it. My fpga skills are not what i need yet so i need more practice and to get my spartan 3 development kit (I can't get a price on virtex II dev kits, so i'm doing coding for spartan). So I'm not even 100% sure how i want to get the data to disk, and i understand completly that the quality of the picture is related to the debayer algorithm.

It's like i'm almost back to square one on the planning.

Well, some interesting stuff is going on, but suffice to say I started this project because i was interested in building a camera and possibly using it for a workterm for my engineering faculty.

Well, I got a workterm today, (assuming when the company does the numbers they can pay me)

This by no means is a negative to the project, but really a positive, because now i can take the money I'm making working 9-5 and work on the project on evenings and weekends.

Most of my time was taken up lately by finding a job anyway, so progress should proceed as much as it did before. Still paper for now, but at least i have and easier way of funding the project.

I'm in transit right now and i have to settle so not much will be done for a few days

Here is what I'm doing now, i'm programming the spartan for timing of the ccd, and multiple modes (all progressive) at 24, 25, 30 fps. So that is started but I haven't decided about how to get it to storage. Its going to need a preview so some sort of debayer will need to be done in the fpga, so I am working on data flow charts for appending the two outputs together and debayer. I'm not doing high end debayer on chip, only enough for preview, maybe some combine thing so you end up with output of 960x540, so this pretty much means vga, but it might be able to be cropped and stretched to SD.

Well, thats what new with me.

Need some help
 

I'm looking for a couple of things and hope someone can help

I am looking for a raw bayer from a dslr, doesn't matter as long as i can open it, a tiff or something would be fine, i just need to do some tests

Also, anyone have any smpte documents, like white papers on smpte 292, 274, 296 or any others pertaining to hd, i don't want to buy them at $30 each so if someone has any it would be a great help

Thanx in advance

I have contacted some idustrial camera makers and it seems many come already with capturing applications. Why aren't people using these applications which comes with the cameras to capture rather than trying to right software to capture?
I have found a camera from a japanese supplier which looks very interesting. It's a color 2/3" which does 25fps at 1080 lines and it's a firewire camera. It also comes with a capture application. It has Global shutter too. I think the Global is the best and the way to go rather than rolloing, right?

Because the stuff that comes with the cameras doesn't really work for a cinema application. There's no good way to capture the image information in a system that an editor will understand, at a consistent speed. It has to be created from the ground up.

I was more talking about capturing the footage to a HDD. After it's in a drive, then you would have to find a way to transfer it to a NLE for editing I guess. But I was talking about the camera capturing part. Sorry for the confusion.

Michael,
Will you please give us a link to this camera?

Unfortunately no link. Just a phone number. They would actually custom make a camera to specifications. I'm currently trying to gather information as what would be the perfect camera for a DIY HD cine camera. Then I will contact him and see if it is possible and how much it would cost.

Micheal
from the sounds of it the camera sounds good, now if only they could provide a few specs on the sensor used. It must be a 1394b because with overhead bayer 1080 at 24p won't make it over 1394a, well it should in theory, but because of protocol overhead it won't so 25p would definetly have to be some sort of dual link firewire or use the new 800mbit standard

As of right now I'm still working on the fpga program for the timing and the circuit for the gain and stuff. Support IC's are gonna cost a little more than expected but not a significant amount compared to the sensor. I'll likely release the fpga code for the timing in a few weeks and it will allow for 24, 25, and 30 progressive modes - so long as i can run them all off one high speed global clock, if not then a method of changing clocks. The code is vhdl written in xilinx ISE 7.1.

I'm waiting for the spartan 3e development kit to come out because it has a usb 2.0 interface and documentation so usb development might actually happen, but i'm still going for getting a a viewable signal out of the ccd that is confoming to some video standard - for now, just gotta learn how to use block ram or connect to sdram. I want to minimize the number of external chips, but chosing a ccd i should have know i was asking for it.

Anyway, good luck on contacting that manufacturer

Keith, the sensor is a 2/3" CMOS. Don't know who makes it. Didn't ask. Is it important? I know it does 25fps with a global shutter. Check my thread "Perfect DIY camera head". I post some extra information about the camera there. It captures video in avi files. So I think it would solve most capturing problems people are having, wouldn't it? I mean, any NLE can work with avi.

I am sure i'ts the IBIS5 sensor as that is the only sensor that I know of that's 2/3rd inch GLOBAL and color...it's shit..not a good image...looks like a spy cam used in undercover TV news..if it's firewire then it's also 8bit, not good enough for shooting you will need 10-12bit images..8bit will also look like a cheap 1ccd spy camera

As I posted in the other thread, it does 8 and 10bit. So maybe it's not the chip you are thinking.

I will know soon which chip it has.

By the way is global shutter bad? I thought it was the best.

By the way, isn't the Drake 8bit? It doesn't look like a spy camera to me.

Keith please email me off list.

obin@dv3productions.com

thanks

If the data was packed properly then at 24/25p firewire can handle the output of the ibis at 10 bit, but because of protocol overhead, 30p won't work in 10bit.

I really think the only problem with ibis is the colour filters used over the photosites, which, as obin pointed out, leads to bad colour.

I'm pretty sure that most sensors, even with onboard adc, have an analog output so you could just stick amost any adc in their you wanted. You could go as high as 30bit if you can find the adc, or likely more. Getting the bits out isn't the problem, its what they are picking up.

I'm still looking into redesigning around a 3 cmos ibis5-1300 setup because I have poured over those spec sheets all all thay look really bad are the colour filter response on the bayer filter. I would like to see what a b/w one does during some test condidtions

great..but how are you going to get a 3cmos setup working? do you have some beam splitters?

I'd have to get some setup gear for the alignment but i know i can get the desired prisms and then just need to get a proper glue and make a semi-clean-room setup. A little cost, but it could be done fairly easily with a few hours of work and research and calculations.

I don't know if you guys have seent these cameras but they may be worth looking into. It's the first I've heard of them at least. I do not know pricing:

Full 35mm frame size!
http://www.fairchildimaging.com/main...Harrier447.htm

Interesting 1" Chip camera (150fps):
http://www.photonfocus.com/html/eng/...s.php?prodId=1

Keith,
Look into laminar flow tables. They look like a workbench with a fancy filter mounted above. Clean air is blown down into the work area keeping a positive pressure at the table top. Dust doesn't get in. I've used this for working with sensors without cover glasses before.

Fairchild makes sensors that can be purchased and framos.de sells them. They are expensive, very expensive, very very very expensive. I remember on sensor being about 8000 euros without any support electronics at all, at that was just a 512 x 512 one that done 150fps. Just for the sensor used in the harrier 477 it costs 3200 euros. And the camera takes at least 1 second to read out a frame, without using multiple ports it can take 2 - 4 seconds. Very far away from the 1/24 seconds per frame we want. From my experience, a camera costs at least 2 times the cost of the sensor, usually betwen 3 - 10 times normally.

The cmos one has a nice sized sensor, but is square and when cropped it won't be much more than standard def, along with the fact that its monochrome and they don't list a bayer option it is cameralink. To me that makes it fairly useless are hard to work with, but for people interested in high speed imaging then it could be useful, but not for high def. And i would suspect that this camera will be expensive, because it falls into a high framerate category.

Its not hard to find a camera that has the resolution or framerate, its hard to find one that someone can afford. Dalsa makes an excellent cameralink camera that is native 1920 x 1080 and all that jazz, its close to 10k. Awesome specs, can't afford it, and when developing you don't want to have to risk destroying 10 000 dollars every day you try something new.

Steve thanx for the tip, I'll look into a setup like that, sounds interesting to say the least.

I'm still unsure what method I want to go. The Kodak camera head design is about 1/2 way done (FPGA design and testing is has to be done before the design can be finished), but the price of a 3 cmos setup is very luring because off the sensor cost. After some initial setup the cost to build one cmos camera would be more, but even if i built 2 the cost per camera would go down below the kodak design.

Final design so far
 

A little note on where my design is going and maybe some people can comment and criticize the idea.

The camera design is 2 parts plus a hard drive (The hard drive is just a hard drive pretty much, so not really a main part). I know some people will not like it after the description and some people will.

The parts are a camera head and a "deck"

The camera head will output hd-sdi, but It will output the bayer over the luma channel and the chroma will be left empty. I'm doing this because it is fairly easy to implement and provides something of an industry standard. It will also output a component signal, but the signal will just be the bayer, from playing with some bayer images i made up it should be okay for viewing, framing, focusing, but not critical viewing of the subject colours. I might be able to implement a simple debayer, but won't be their initally in my prototype.

The least worked on and more exciting thing that i've come up with is the deck. And yes, it is more of a deck than anything. No, the hard drive will not have a file system and will not be directly readable by plugging it into a computer unless someone wants to make a program for reading it. It is a small device that will take in 4:2:2 HD-SDI and record it, uncompressed, to a hard drive (raw data into sectors). Initially it will only record the luma channel for the above camera head in the prototype. It will then be expanded to another hard drive to capture the chroma, or a second bayer camera. And possibly (because its not to hard to do) take component input for use with hdv cameras. It will have HD-SDI out and component out for monitoring just like a hdcam and betacam decks does. It will have a standard serial control, rs-422 or rs-232, can't remember which is standard for video stuff, but will be usable in things like fcp and avid without much work and will act like a normal deck.

I know we all want 4:4:4 but I think that a half decently priced 4:2:2 uncompressed deck could be very useful to almost anyone from high end pro work to low end work.

I'd apperciate some feedback. Like i said the deck isn't worked on much yet, but that is mainly because of my lack for the intellectual property of a sata or ata core for the fpga. They exsist, but companies never respond to my information requests.

Don't be afriad to leave criticism, good or bad, so long as you can give me some explanation of what is wrong and why

I have been highly interested in FPGA and possabilities to use it with SATA,
ATA, USB or firewire (+ storage protocols). However I found it all confusing
and not much information on what is available.

One thing I am wondering. How are you going to store a bayer stream in
4:2:2? That sampling refers to YUV, not bayer. Besides, you can't afford
to loose any bytes in the bayer stream because you really need those to
construct the RGB image. You could say that bayer already is a form of
4:2:2 (since green is sampled twice as much as red and blue), but don't
degrade this signal any futher. A bayer chip cannot really output 4:4:4,
however you could call it that if you leave the bayer stream intact.

Hooking up the harddisk and specifically reading of it might prove to be a
problem on the Windows operating system (I'm not sure how easy it is to
get raw sector level access to a harddisk, but it is something I was going
to look into).

Another option (perhaps) might be to implement a network (gigabit prefered)
link if you can find a TCP/IP module for FPGA and transfer the footage in that
way. Might be a lot easier to implement on the "computer" end, for all sorts
of operating systems (Windows, Unix, Mac)

Fpga's are fairly confusing when you start getting into command based protocols like usb 2.0, firewire, ata, and sata, Other than that they are fairly easy for some things, but you continually have to use a lot stupid commands.

From what it sounds like you don't understand how HD-SDI works, and if you don't then a lot of others don't either.

4:2:2 refers to y (luma) and uv (2 chorma) channels. The y channel has 1920 x 1080 active pixels. It doesn't matter what is in those pixels, whats coming off my ccd is is 1920 x 1080, it doesn't get debayered, just transported over the luma channel, the signal IS still perfectly bayer, untouched. So what is in the chroma channels. Well first, in SDI it becomes one channel of 1920 x 1080 rather than 2 of 960 x 1080. Initially nothing is sent over it, but i could send a second bayer if i wanted because it is one 1920 x 1080 channel, not the 2 that everyone thinks it is.

I emphasize, the bayer is not touched, just because it goes over the luma channel doesn't mean anything. I could send audio over the luma channel if i wanted so long as it is going at 74.25Mhz it doesn't care what it is. Preview won't look good but will be watchable with my design, and latter a plugin for avid and fcp can be made to debayer and the like.

As to hooking a hard drive up to a computer. That is why I said it would be a deck. Incorporating a file system would mean that you will need 3 things. FPGA, Processor, and Ram. I'd need a team of engineers to do this, not just me an engineering student. So that is why you control it through a serial port just like a betacam deck and use your nle to capture with a hd-sdi card. I guess a lot of people here are probably hung up on firewire and computer things rather than proper industry standards.

I'm stressing that i'm going to avoid protocol implementation at all cost (more like at huge time and cost savings). Whenever you have to start doing heavy responding to requests and having stuff do things like "handshake" its gonna slow down and become way more complicated. I'm not dealing with it. What i can do is a deck. A deck that would beat a hdcam deck and be way cheaper.

It is true I know next to nothing about (HD-)SDI. However, I think the confusion
came from 4:2:2 which indicates some things.

It's good to know the bayer is untouched. That's all that matters in the end.

It never occured to me that we could use HD-SDI to get the footage into the
computer after it has been shot. That's a good and interesting point!

What price do I need to think about for such an HD-SDI card for my Windows
computer?

p.s. does this mean that HD-SDI has less bandwidth available for the U & V
channels? So either they are using 50% of the pixels or they are combined
into one channel (effectively getting 1920 x 1080 pixels)? That would mean
HD-SDI is two channels of 1920 x 1080?

Decklink by black magic designs is what i was thinking for hd-sdi capture. They have a barebones pci-x capture board that would be perfect for about 600 dollars usd. It has hd-sdi in, out, and the serial controller on it. It is only 4:2:2, but that is all i am working with, well, only half of that technically.

http://www.blackmagic-design.net/

You pretty much hit the nail on the head. HD-SDI is really only 2 channels of 1920 x 1080, but one of the channels gets chopped into 2 half channels at some latter point after being deserialized. What goes into the serializer is 2 10bit channels and an ancillary data channel (which i don't use).

I'm not sure exactly how the 2 colour half channels are combined, i think they are rotated (CbCrCbCr) or one might be apended to the other, but the rotating sounds so much easier because could be done with a handful of transistors.

I so need to shell out about $150 for all the stupid smpte documents i need, rather than going on the small amount of data from data sheets.

I know that nobody shoots steroscopic anymore (except for the spykids movie) but its so appealing because it is so easy to implement. All it would require is another sensor and to run my data packing code a second time. I don't know if anyone would actually be interested, just a thought.

Hi, i've been a silent reader of all those HD camera thread for some time now, and have been really pleased by the developpement you're doing (no pc, fpga).

I wanted to point you out to this article :
http://www.linuxdevices.com/articles/AT3888835064.html
where the guy add some compression to the camera, using fpga... and the source code is available. Ok, the codec isn't a really good choice _at all_ (imho, it suck hard) but that prove that a sort of lossless codec _on the bayer_ (like DCT + huffman or whatever entroy coding) is possible using fpga ... cutting down a 1280x720@24fps stream to 25-30Mb/s would fit on a single harddrive bandwidth, even a 2.5" one.


Also, the guy aside me is working on a CMOS camera head using National, now Kodak KAC-9638 (color version is 9648) and i found the price really interesting (18$ heh) ... Is Rolling Shutter _that bad_ ? it would really cut down the price for a 720p camera.

I have been going through the stuff on cameras designed by elphel and its been somewhat useful. It looks like a route that could be useful to a camera design as they already have work done for an 11mpixel kodak sensor. The main think is that it actually runs an embedded linux for the gigabit link.

I do not want to have to put in a processor and run software as that is currently beyond me. HD-SDI isn't because that data flows regardless of if something is recieving it or not.

I don't know to much about rolling shutter, as I have never had to deal with it, since my design uses an interline transfer ccd. Their have been numerous discussions and the problems associated with it deal with objects moving and becoming skewed. I'd suggest searching the forum.

Cmos sensors are fairly cheap. Digikey lists a bunch, but most have tiny optical formats (usually 1/4" at most) and usually won't handle the framerate at the higher resolution. And not all cmos have performance like ibis or altasens. Older cmos technologies had much more noise in them, and this technology is still used today to make sensors for things like cameraphones.

I'm sticking with my ccd design because right now i've go it down to a handful of fpga programs that are easily handled. I had to scrap some of the stuff i'm working on but i did away with needing external ram in the camera head, which is good.