A lot of people have worked hard in building cameras for High def and all sorts of stuff like that and I have been trying to keep up with it for months.

I am not really much of a videographer as I am an engineering student, but I am really interested in the challenges of HD cameras and solving problems related to this. I love editing for people and doing the tech stuff on shots.

I have been mulling an idea I had for a few weeks now and although I haven't really started the design process I decided to post what I would like to do.

Everyone is working hard to address the problem of building a working camera and in most cases this gets tied to a computer. Even the highly anticipated andromeda for the DVX100 looks like it will initially be tied to a computer or a laptop or something like that.

Personally I hate the idea of being tied to a computer to do recordings and using bulky monitors and the likes to deal make a working HD camera that is below 100k.

I want to design and build not a full camera (initially anyway), but more of a development platform to help people quickly take some parts initially and within a few weeks have a working, and more importantly, self contained camera.

So what is this platform that can be quickly changed into a camera. To put it simply, just another computer - with a few changes.

It would be a shoulder mounted computer with a place to plug in cameras via usb 2.0 or firewire 400 / 800 or gigabit ethernet. (I'm not sure about camera link because I just can't see myself being able to design so that the thing isn't huge, but if people really want it then I'll see what I can do.) There would be a method for an external hard drive to mount, this will likly be a proprietary mount of my own design that will either allow for hot swap sata drives or usb 2.0 or firewire. A standard definition viewfinder will then be connected via s-video or composite. It will have either a built in battery that powers everything, or a port for a battery belt, or both.

So, all that is left is to find a camera that is usb, firewire, or ethernet, and then write a program that interfaces everything.

The unit would have standard buttons and a power zoom handle.

As of right now I have exams coming up next week, and the way engineering works where I live is that I need a work term, but since i'm not a senior I'm having a hell of a time finding a job since locally it seems that most places are not hiring students. What I may end up doing is this as my workterm, its a poor substitute but if the feedback is good then I might be able to get some students from my level who are having a hard time finding a job like me to work on this project, and hopefully develop some software. And a working device that is sell-able. And since my work term is only 4 months long I would want a working product that I could sell by sept.

I really want some feedback on this and want people to be as harsh as possible so that I can see the problems in the begining and fix them. The latter through the development process the more costly and harder it is to fix problems.

ANY FEEDBACK PLEASE!!! I don't know enough to design this for everyone interested and that is what the target market would be so I need to know what you want.

Keith Wakeham
Engineering student
Memorial University, NL

Want to help me? read all of my thread and let me know...we are almost at a point of a working camera now...

welcome aboard keith:

there are I think three major threads.

wayne morellini,s http://www.dvinfo.net/conf/showthread.php?s=&postid=298266#post298266

obins http://www.dvinfo.net/conf/showthread.php?s=&postid=298547#post298547

rai and markushttp://www.dvinfo.net/conf/showthread.php?s=&postid=298154#post298154

all three are working on the next varicam killer

I read most of the major threads about 4 months ago, on break between semesters and i was really impressed, i'm a little behind on whats been happening lately and this has only come up recently as a possible thing for me.

I'm been trying to catch up on some today, but my memory is flakey so I'll re-read.

I was up some where about page 130 when i lost track of obin's and i haven't been up on the either also so I guess i'm in for some reading.

I'd love to help with your camera obin, if your still on the cameralink route then I have a challenging problem to solve, which might not be as hard as i expect to get a framegrabber into a half decent sized case, but harder than that is getting a small mainboard with pci-x if your using that...

I just gotta do some more reading i guess and research.

I've got a touch of pnemonia and some studying to do so i'm at home tonight doing this.

because of this i'm planning on starting some design stuff tonight.

Keith

Richard you hit the nail on the head! as I have seen first hand the true quality of VariCam footage...not...that...great..IMHO

anyway Keith yes I am on the cameralink interface because it's fast, really fast..we are working off a small microatx board with pci-x slot...

I love how you refer to these as the next varicam killer.

Personally I was going to try and avoid cameralink, but after thinking about it and doing a little plan for some of the preliminary designs I'm really looking hard at trying to get it in their.

As I said before I am trying to make this a multi format development tool that can be turned into a full blown camera.

I'm going through a product development process (I knew that design class was going to come in handy) and refining what exactly I want this think to do.

Right now I'm concerned about power consumption and size. I know i can design and machine a casing from aluminum or magnesium alloy or something (Engineering students at my school also has access to a computer machining shop that does stuff so cheap its almost insane - manual milling is fun too).

Obin: I noticed as of late your software is really taxing that P4 cpu. I really wanted to head toward intergrating an itx P4 board, or athlon board into the camera but the cameralink starts challenging me. You used to have a standard pci capture card didn't you? Did it prove to slow or could that possibly be worked into again for single ccd at < 2 mpixel. Microatx is pushing the size a bit but I'm gonna see what i can do.

I'm sorry that some of my question (and i know that some are definetly already answered in the forums) are answered by searching the forums, but things change quickly and some quick answers saves my lots of time of searching.

Keith

hmmm...camera link yes usb is too slow pci is also not fast enough..gigabit can be done but at this stage we have the fastest thing going..why screw around with that...i am going to get atleast 24fps 1080x1920 images from our system...help i could use would be in the machine shop with large cnc parts...we will design but have no machine shop here..also if you wanted to start to look at the power supply issues that would help....don't forget I am NOT using a P4 cpu but a Dothan Mobile..MUCH less heat and power!!! a great little cpu! we could use design of the hard disk "holder" in the camera as I am not sure how to do that yet so that you can "load" disks when you fill them up and need more...A viewfinder needs to be designed and I have not even started that yet...the list goes on but I would need to know how you want to help i guess...


don't look at this a big money maker...I have no idea how many will sell..look at it as a side gig at best...maybe we are in for a good supprise? that would be great..

I am building this system out of NEED not want...it has been a project of love not money ..just a fyi

our micro atx is fine..the more a camera weighs the better anyway for a smooth image...don't worry about the micro atx size

Okay, I'm beginning to understand a bit of the direction you need me to go in with this.

I was really hoping that a pci framegrabber would work, but I'm gonna go out on a limb and do some design work for some concepts with the matx in mind and a pci-x frame grabber.

I'm still thinking that this is going to be more of a universal design platform, but if cameralink is what is needed than the other stuff can still be their, but not the main thing then.

I was never in this for money, I'm an engineering student, all we think about is our next meal and how much information a stress stran curve can tell us about a material... so off topic

I like designing and overcoming challenges. I've never been good with the size challenge of things, but i'm getting better. Compact but functional is the aim of the game for me. Just not to compact, i can't stand hand held cameras.

I'm thinking native sata is the way to go for the capture drives, at least 2 in raid 0 in a small quick release box. Sata is hot swapable so that shouldn't be a problem - well it is in the spec, if chipsets support it is another thing.

The viewfinder seems to be a function of money throwing as i like to think of it. If you throw at little money at the problem you'll end up with a .3 mpixel lcd eye piece, but if you throw a lot then you get a b/w crt, and if you have a fan and buckets of money than you'll end up with dmd devices or d-ila or high res lcd or oled. I just have to find an equilibrium for cost. Thinking that a b/w SD crt will be good enough for focusing. But i could be wrong.

I'm gonna have some designs done for tomorrow morning - mainly just sketches for refinement and stuff to help decide where to go with the design.

Keith

I can tell you this..SD for a viewfinder will NOT cut it...maybe 1/4 quad pixel display but that is still at 960x540 so over the "standard" SD res anyway...yes your right. we are using SATA drives 2 in raid. the only way we get enough speed. server drives to be exact.

so..ideas on viewfinder ?? I have seen the OLED..should be enough as it's 800x600? well almost anyway..we can scale things down...as it stands we don't have color display..this is a limit of the cpu power that is on the market at this time...this will change soon...and we may still have color display while not recording...but that is not a biggy for now...zebra is more of an issue to a pro then color preview...


what can your buddys do for CNC work? what size? type of CNC machine? axis?

Have anyone noticed that a Pentium M 2.13 GHZ has a consumption of 99 watts itself alone?
add the Mobo, memory and disks and you'll easily end up with at least 150 watts...

What your asking for a viewfinder starts making things a little difficult, but it can be done. I'm thinking that either it will have to be made from scratch (ekkkk!!!) which means i really need to find a new electrical engineering friend from a really higher up term. But I'm thinking on finding something like a single display hmd or something and remounting it to be a viewfinder.

Oled is still very new - and expensive, but I think a tiny lcd or a dmd based one might be cost effective. Or maybe the holy grail IMO, a crt. A b/w crt doesn't have a grill, just a screen of phosphors, so the resolution is just a result of focusing and scanning speed, and these are only limited by the physical properties of the tube.... You can scan as fast as you want until the tube explodes from overheating, so it might have to be cooled, which would be an entirely other subsystem to deal with.

CNC
We have two machines, both are big. One can handle parts 4 feet x 4 feet x 3 feet and is 3 axis, but has an attachment for spinning the part to make it 4. The other, well, i haven't really seen it but it is bigger and 5 axis when an attachment is connected. There are also some half decent sized cnc lathes, can hand about 9 inchs with the right chuck.

So no worries about being unable to machine the parts, all they need is a cad file in the right format and the chunk of metal... and a few days, or possibly a couple of weeks because a lot of people use it for projects and stuff.


WD raptor drives can drive up the power consumption, but i have a laptop with a pentium-m 1.6 and with an 80whr battery i and can go for about 2.5 hours of gaming. If the clock speed went up i could se power consumption of the cpu doubling but i can't see the rest uping it to 150 watts on a pentium M, maybe a p4-m though. The only true way to measure is to put an amp meter in line with the all the wires and see how much it draws.

You guys are really pushing my dream of making a cheap development platform out the window for an expensive high end beast. So I might run with two, lowend one of my own design, and the uber beast from places unknown for you guys.

Doing sketches today, soildworks this afternoon for concept refinement, and studying this evening.

what is your goal? as you can see I am deep in development of the system...do you want to make the case? viewfinder? power sub-system? software? what? I am doing all my work with the software at this time becase without that we have nothing of use....then I will start the design...

I think my goal is still the same, more of a developement platform, but one that is going to suit the needs of peoples current development.

For me that means everything but a camera head and software.

So What i have in mind is a microatx computer with pci-x framegrabber card with a built in boot drive and removable storage drives. A battery pack system with all the power converters needed to run the thing so either everything runs of one battery, or one power jack like most eng style cameras are. It should run for 2 hours of actual recording and have storage to at least 1/2 the running time. The viewfinder will be universal but I will design one that would be on the unit already. All of this would be packaged into something that looks similar to a dvcpro shoulder mount camera. There will also be a Handle for the powered zoom and just to stabalize when shouldering the camera. Although most shots with a camera like this would be tripod, Some shots will always require manually moving the camera and shoulder mount seems the less stupid of the methods for the right price.

So what the end result would be obin, is you plug in your camera, wire up the zoom if necessary, load up your software, and your done - the camera would be complete. Nothing else required. I'll handle the after though stuff so that you and anyone else could deal with the "getting a working camera" problem.

I hope this is clear enough, maybe calling it a development platform is throwing people?

Just a little update on where i'm standing with the design and how it is going to be setup

Using a CIA matrix method of chosing the design here is a run down of how the device will be setup from the criteria i have chosen for all the important parts.

It will be an eng style camera. Mainboard will be facing so that ports will be at the back and card is at the bottom (Mainboard is closest to your face).This causing some wire routing problems but it is a compromise that had to be made for the HDD. The card will stick straight off the board, not 90 degree brackets or anything like that, simple. The HDD will load on the outside of the camera, possibly a drop down method to secure the hard drive without having to have an insane amount of mounting design.

While going through the matrix process I came to an overwhelming conclusing on the battery. Based on what I understand and using criteria of ease of connection, cost of battery, run time, recharging, long run use, and weight / balance it turns out that a battery belt looks like the best option. Amazingly it was very close to a perfect score, with having the battery mounted on the back with the closest rating, but only scored near 75% of perfect.

Since a dc port is a given anyway i'm gonna design for an anton bauer battery mount on the back of the camera. I'm so not building a battery from scratch.

So now for a full blown sketch and some solidworks designing - just rough cad work to get an idea of how it is going to look.

When i get my engineering account at my university straigthened out i'm going to setup a website, its already in the works, but i just can't host it.

I can host if you need it...
this all sounds great..your biggest challenge is going to be the power and viewfinder...as you may know our system will have atouch screen to run the camera...this will also have the image display..the problem is that in bright sunlight you can't see an LCD ..this is ONE of the reason we need a viewfinder system...I would guess that we can split the VGA port going to the touch screen AND the viewfinder..keep in mind this camera NEEDS to work with CINE style equipment..matte box follow focus filters lenses etc...so you really need to get all the specs of ARRI and panavision stuff so we don't re-invent the wheel...I am thinking maybe even use PL mount lenses..this would need a converter from C-mount to PL mount..maybe you can CNC that?

I did notice that the Drake camera is using some c-mount lenses that are of a very high quality..maybe we don't need PL..not sure yet...

From what i remember when i used p&s mount for the canon xl1s that primes aren't light weight and they need a hefty mount, so what you will likely need is a a full blown mounting device because i personally wouldn't want to hang a PL mount lense off of a c-mount adapter. It will actually have to be mounted to the camera body so that the body takes the weight and not the camera.

I just realized I'm thinking out loud.

I'm familar with some of the arri stuff and mounts, but I don't know anything about panavision, i'd assume similar, i could be assuming wrong. Time for research.

I just put up a little website for the time being on cjb.net to keep track of everything, i'll eventually move it to my university account this coming week

http://indiedp.cjb.net/

Not much on it yet, but its a start.

I don't know if its because of a lack of intrest or maybe because of me not being on this forum for long enough or not being clear.

I'm doing exams now, and i'm halfway through (phew, only 2 more and i'm homefree).

If you have checked out the website essentially i'm pretty much tailoring the indie dp to be a housing for obin's camera setup, and right now i'm working on getting info on arri mouting stuff and designing a c-mount to pl mount.

Obin, if you check this, do you want the adapter to just connect, because the sensor size is way off from 35mm, so you won't get the DOF and the lenses or do you want to use a groundglass setup, even though it would lower the amount of light. Up to you. I'm also trying to figure out how to connect all this stuff together and my orginal intent of somthing that kind of looked like a shoulder mount camera seems to be less and less of a good idea. Do you want to go similar to the Drake camera, or have any ideas for the over all body. You know what you have, and so do i (to a degree anyway) so let me know your ideas.

As for the indie dp mini, that is going to be my little project. Right now i'm looking for an imaging sensor. I've been thinking of getting a sony one from framos.de and overclocking it with some cooling so i can get 24fps, but it might be a bad idea. (blowing up a 300 dollar ccd isn't something i'd like to do) I've checked the thomas register and globalspec and contacted kodak and it's almost impossible to get a sensor, let alone a good one at a half decent price, any ideas? (gotta buy at least a 100 of the KAI-9023 at 1000 each, if i wanted that one - ouch)

If i could get a reasonably priced FF or FT ccd then i'd do a mechcanical shutter, but doesn't look promising. Time to call dalsa and see if they low volume engineering samples.

Hello Keith

We have been planning to do very small shoulder mount platforms for sometime (after the software is finished). I have been looking at the VIA nano-itx boards (12cm*12cm (or less)). The processors have 1Ghz for 1 W. I have been waiting for software, camera and newer higher speed nano-itx boards with Giga Ethernet links to come into the market. With Obin's latest progress it looks like more than capture and preview might fit on a nano-itx board (compression). I was thinking of even chasing up some non working ENG cameras and rip the insides out and put a system in it, anybody with defunct GY-DV500, or 5000 can also contact me. Being a trendy sort of person, all that matters is pro filming features, trendy looks, and size (smaller the better).

If you were thinking of just capture and preview, then there is a smaller/lower powered Via platform for the handheld game system, and Pocket PC's/Palm that could even fit inside the case of a PD150/DVX etc. Don't get too phased by the viewfinder/monitor problem, many RGB type displays (LCD's) have RGB subpixels horizontally (though on a PDA this might be oriented in a less useful way). So 640(*3 sub pixels) across will give you an idea on the focus of 1920 pixels (focus is radial, so only the horizontal is needed most of the time). JVC's new camera has a useful focus assist feature and that is to edge enhance the bits that are in focus in the preview.

I happen to be looking up a mid price Kodak camera at the moment, it uses a Foveon X3 chip and I know previous cameras had their own SDK. I believe I have a technique to get it to output HD live (also has snapshot mode). I will probably publish details (except for he HD stuff which comes off another project) to the list, as I lack the strength and time to do it myself for the moment.

Don't forget that with the smalcamera sensors you have a whole primitive HD camera system for $69 (don't like that cheaper model (more expensive higher res version available) I have it here, even though it works well with dual slope like feature sometimes it blooms and moirs etc) that has enough sensor bandwidth and USB2 bandwidth for the job (though the compression engine might be limiting factor). They also have a ready made development system with SDK.

Don't forget the original Rob Scott's camera system. He has been doing it alone, and doing it tough, for $100 for capture software. Obin gets most of the volunteers to do cases etc, Rob gets nothing but the occasional correspondence with Rob lobtham. I don't know where ever Obin plans a big fully built camera system or where ever he will sell the software independently (like Rob) for roll your own.

Thanks

About my suggestion of a camera on the Foveon X3. I had a further research on it and cannot find global shutter again, and the frame rate was a misprint on a site, and this Polaroid camera does not use the SDK kit I thought it did. So it is not worth it. But here are the links anyway:

http://www.foveon.com/press_x530.html

http://www.foveon.com/press_SmallFormat.html

http://www.alt-vision.com/hvduo5m.htm

http://www.alt-vision.com/fo18-50-f19.htm

To bad to hear about th Foveon, I remember when everyone got supper hyped about it then the low frame rate keep it back.

Personally, Even though naming things is likely a bad idea to start with I did anyway, for those who went to the website.

Unfortunately, My university account is botched and i can't serve from it, my luck, resulting in no updates on the page cuz cjb really sucks.

I have the website updated on my hard drive, but that is useless.

I'm going to completely develop the Indie dp mini, as it is currently called, into a full camera pretty much.

Right now i'm doing paper work design and its actually getting done somewhat. I've selected the body stylingly and how it should work (This might seem backwards to most but this is how product development works) considering what needs to be inside it (with plenty of room). I'm really looking hard at the KAI-2093 Kodak sensor and timing circuit. $250 for an engineering sample, 1150 for tested one without defects.

This sensor has dual output, which, when you crunch some numbers and stuff it does something really strange. Each output has the exact same bandwidth as full rgb or yuv standard def. (960 x 1080 = 1036800 = 720 x 480 x 3 ). I've been thinking that maybe i could botch a capture card, like a usb one, to taking the two signals.

The only reason i'm doing the pushing for the Kodak CCD sensor rather than a cmos is because it is perfect resolution and specifically design for hd imaging like the altasens and is available in any quantity i want, plus one other think. The diagonal is .75 of an inch, that is even bigger than the altasens area, and makes pl mounts way more of an option for the DOF issue.

I'm also glad that someone else took some intrest in my ideas and posted to the thread. (It seems i talk to myself in it a lot - i'm so lame)

I never though on the subpixel thing in lcd's, that is a really good point, and the focus assist on the jvc is a good idea, but i think it needs improvement from what i heard. I think it only shows the center for focusing, but what if your subject is off center. So if the software could move the digitally zoomed area around for focusing than that would be awesome.

I'm gonna try and look up that via plateform, because if it could use ide or sata drives and i could make it fit inside the pov body i'm designing, that would be awesome. I don't plan on compression, so i don't think i'd need much processing power. Most of my mockups have been under impression of a mac mini or itx stuck on the back of the camera.

Anyway, first day with no exams, horray, i'm done (for this semester), i'm gonna work my ass of with this design stuff today.

Good to see you here. But the problem is that there has been so much written for so long, that most people are talked out/left. So you might very few people interested in anything outside the current projects. So it might be better to be with somebodies project (unfortunately) and post on those threads.

Advice on programming, there is a very steep learning curve for the sort of programming needed for capture (real time embedded) compared to apps programming. Very few programmers would no it, and not many programmers would be up to learning it (PC's/Windows XP are complex fro real-time). So if you want to do capture i might be best to team up with somebody that knows their stuff. It is also a long process, maybe better to avoid doing camera capture.

Machines: New Apple Notebooks and Mac Mini's coming out. Present one is limited. New Xbox2, more powerful than Mac's, power PC etc, cheap. Just pointing a few extra options than PC (that people are concentrating on). I don't know how much simpler Mac is than PC to real-time but i imagine it is, and even the Xbox2.

Do you have links to information on that Kodak stuff?

There are also various free web page providers around the world. I have seen them with 50 and 100MB of account space. Google search may help.

That Foveon camera I mentioned before, misprint, was a Polaroid.

Yes i do links on the kodak and I have pricing

http://www.kodak.com/global/en/digital/ccd/
-here for genereal ccd

http://www.kodak.com/global/plugins/acrobat/en/digital/ccd/products/interline/KAI-2093MLongSpec.pdf
-here for the specs on the one I plan on purchasing

The first link gives way to all kodak imaging sensors including cmos, but the KAI-2093 is a really nice on paper sensor.

First 100 pieces purchased $1130 ea
Engineering Grade $250 ea
Evaluation Board (Includes EG Imager) $2500 ea

The engineering grade will be what i plan to work with first, the have more sensor defects but are still 100% functional and good for proof of concept, just not so representative of a working device, their might be rows of pixels dead.

Right know I'm stuck with getting the digital output from out camera block design onto a hard drive. But really, this and software were the real problems to begin with.

From my experience I am pretty sure that i could get an fpga to take the dual outputs from the kodak, link them together, debayer and output a hd-sdi signal and an rbg (analog or digital)with a virtex II or virtex II pro - But then its the giant computer problem. A computer with PCI-X or If i wait a year then PCIe with a giant breakout box.

I don't have enough knowledge or experience with PHY devices so I can't implement ata or sata. The Virtex II pro has rocket io which can be clocked for sata, except there are a couple of necessary things the rocket io would need to do that it just can't do. One of them is something called OOB. If it did then i'd be plugging away bypassing the computer and using hard drives more like tapes.

Your probably right about the threads, maybe i should just go work silently like a shark and come back up when i have something or just join someone elses project.

Sumix altasens camera is gigabit so if they got it out soon enough then its pretty much straping it to a computer, and would make all my work useless.

I know that right now i can avoid a lot of the problems people are having. I'm that i can get the framerate, global shutter, dynamic range, and solve a lot of the problems people are having with sensors, but i just can't get the data stored. What i really need is something like the reelstream andromeda modified for my camera design.

Keep posting in here..I do all the time..we all read but don't have alot to say as it's all been said and you can read it in the threads...just keep at it like myself...

I would like to FIRST have a NON GG no 35mm lenses...I think that 2/3rd inch cmos will be enough..then later on we can do GG when someone has a REALL good one on the market..I like the Drake style box..but better can be done in CAD...

we are now having trouble with the timing in our software..working that out now...

Where I am with your design for the unit is kind of mixed right now obin. I've done some preliminary designs for the body of the unit along with doing some research for pl mount and c mount lense and for the cine style gear. Amazingly it is harder than i though to get really accurate information on the lens mounts and stuff.

I know your mainboard and i have it mocked up in solidworks and i'm working to build an enclosure around, but right now the positioning of the parts seem to be the most difficult part. Its likely perferable to keep as small as possible.

Thanx for the encouragement obin.

As for my own design I am part way through designing the camera head to output digital bayer from the ccd and have the head board partially mocked up in solidworks. I also developed a flow chart and "word" programming if i'm going to do demosaic in camera and have it output component and hd-sdi. The parallel smpte 274 to serial smpte 274 (smpte 292 defines the serial transfer mode, not the format) can be done in a chip made by national semiconductor (clc030). Amazingly the chip isn't as expensive as i though, 65 CAD and most fpga's can handle parallel smpte 274 like spartan 3 or virtex II, and right now i have the development enviroment for designing fpga's.

I also have to say, from my research, the component to hd-sdi convertors can be made with little work and could cost about $200 to make, yet companies charge 2k -3k, talk about mark up. (adc + fpga or bufferes + clc030 ic = component to hd-sdi convertor). The Cb and Cr needes to be buffered and switched between to go into the clc030 and that is all that is too it, plus maybe a microcontoller and switch to tell the clc030 what format to expect.

I've tried to setup some of those cheap online hosting sites, but they are really poor quality and make it hard to upload sites. I think I'm going to piggy back my site on one of the sites of a team i'm on at my university until my account is fixed.

I would like to FIRST have a NON GG no 35mm lenses...I think that 2/3rd inch cmos will be enough

Drake does that, and Rai has real good GG solution somewhere in Pipe line.



I also have to say, from my research, the component to hd-sdi convertors can be made with little work and could cost about $200 to make, yet companies charge 2k -3k, talk about mark up. (adc + fpga or bufferes + clc030 ic = component to hd-sdi convertor). The Cb and Cr needes to be buffered and switched between to go into the clc030 and that is all that is too it, plus maybe a microcontoller and switch to tell the clc030 what format to expect.

Look at my home camera thread (link is on the first page of the technical thread). You will find a link to a Russian camera that uses open source FPGA designs that are available on open cores (I think).

The cost would be $200, sounds right with markups you are looking around $1-2K. I think the Australian one might be one of he cheapest (around $1K) I forget the name, but "blackmagic" is the name of one of their products.

There are a number of cameras outputting better grade signal from their component output (the JVC HD100, and Sony HDV cameras being some of them). A really cool product would be some thing that could take cameralink, HDSDI (dual link), or component, output and translate it into an industry standard format signals (4:4:4, 4:2:2 but any resolution and bit depth) on one or two Gigabit (or usb2, Firewire, or Gigabit version of Universal Wide Band) to input directly to the computer/hard dive, and have it translate industry standard commands to the camera the other way. Then you could even use freeware products like cinerella (how do you spell that) to control any camera. It might not be much more complex then a HD-SDI on it's own.

Well, hd-sdi (single and dual link) are really the industry standard for high end work so going to that format and using proper smpte standards are likely the best way to go in my opinion, even if those standards have some really stupid issues (smpte 274 which defines 1920 x 1080 60i/30p/24p is 2200 pixels per line with 1920 active, making an fpga necessary for my design for all the useless black before and after the usable signal).

I have looked at the russian fpga camera, but it wasn't as helpful as i thought it would be because most of what they are doing is realitivly more involved and images are moving at a slower speed and being compressed in the chip.

I'm working on finishing up the schematic for the camera block, but the timing chip is giving me a little headache. So many outputs and documentation on the thing is really poor. I migh look for another timing device that won't require me to have a micro controller just to control the thing. I want a timing chip that i set to 24p with 1 electronic shutter per frame and never have to change it. Maybe i'm just not understanding the KSC-1000 timing chip docs properly.

Fpga programing, not as hard as i thought but the speed concepts and how it works are what are hard to master, I'm a little confused on the debayer right now, so if i can get the code to simulate outputting the bayer to the luma channel then i think i will be happy. I know it sounds simple but because of the dual output of the KAI-2093 I have to write code to output black then the active line from one output, then reverse and output the active line from the second output then output some more black, along with sync.

Building the fpga simulation model is going to be a pain.

It doesn't seem easy to model gigabit ethernet and unless you use a virtex-II or virtex-II pro with rocketIO then you will need a phy layer, meaning a gigabit controller, and then you will need to know how to control that controller. So right now that is beyond me, same with anything else involving a phy layer (usb, 1394, ata[i'm still waiting to hear back on ata code from a company, and it might be embedded or it might just be a phy layer interface], sata).

I'm not 100% sure but I thought the sony FX1's component output was after compression so it was pointless because it is decompressing the mpeg2 stream to analog so your actually gettting lose. I'm pretty confiden that the JVC 100U is not after compression.

Hi Keith

That's not quiet what I meant. I was suggesting to keep the video industry file/data uncompressed formats (with some extensions for higher bit depth resolution and frame-rate and 4:4:4/Bayer) but being able to capture from any camera interface by standard GigaE converter box. For the industry it might not mean much, for us it means we can capture from any camera interface cheaply to a computer/laptop and use standard software to edit the file. There are numerous HD SDI's and they don't allow access to cheaper machine-vision cameras (and the laptop card-bus HDSDI cards won't do dual link data rate, but dual GigaE will). So rather than do what everybody else is doing you could do something different.

Anyway back to the HDSDI. I think Elektor (or it's rival in the UK) had a SDI kit last year or two (don't know if it was a HD one or not). I'm sure somebody is working somewhere on a kit for dual link HDSDI (Open core and he open source repository might have something).

I have looked at the russian fpga camera, but it wasn't as helpful as i thought it would be because most of what they are doing is realitivly more involved and images are moving at a slower speed and being compressed in the chip.
That's only his present public design, I would recommend emailing him privately and asking about his next system he is working on.

I'm working on finishing up the schematic for the camera block, but the timing chip is giving me a little headache. So many outputs and documentation on the thing is really poor. I migh look for another timing device that won't
I can't see the doc, but sometimes these people assume a lot of experience to "connect the dots" so to speak. So it might require a lot of figuring out to get to grips with the information.

I want a timing chip that i set to 24p with 1 electronic shutter per frame and never have to change it. Maybe i'm just not understanding the KSC-1000 timing chip docs properly.
I would recommend 25 and 30fps as well.

It doesn't seem easy to model gigabit ethernet and unless you use a virtex-II or virtex-II pro with rocketIO then you will need a phy layer, meaning a gigabit controller, and then you will need to know how to control that controller. So right now that is beyond me, same with anything else involving a phy layer (usb, 1394, ata[i'm still waiting to hear back on ata code from a company, and it might be embedded or it might just be a phy layer interface], sata).
I see. I think using a third party circuit and programming manual is way easier than designing half these interfaces fresh.

I'm not 100% sure but I thought the sony FX1's component output was after
One of the Sony HDV cameras, at least, is supposed to have uncompressed output (but seems to be a bit poor). There was much talk, and testing (links in technical thread and it's own thread a few months back). The JVC HD100 is before compression (4:2:2 upto 60fps). I have heard of higher end cameras before compression too.

Okay, i know exactly where you are going now with the standards idea. Gige would be the best for the easy to use, but right now that is beyond my experience :( I do feel confident with the recoding of the bayer and possibly debayering, and when i do the programming for that maybe i'll be experienced enough to take a look at gige.

Actually, i spent most of yesterday trying to figure out that stupid timing chip and now i think i'm warming up to it. The problem i was having was trying to figure out how to connect it to the ccd, (ccd only has 2 vertical and 2 horizontal registers and this thing outputs 6) but then once I realize that the programming aspect just needed a more deep read through i began to figure it out. So, its looking up (again, everything is on paper so far) but unfortunately the timing chip needs to be reprogrammed everytime the frame rate changes, which makes changing framerate a little hard to do. But i'm thinking i can incorporate the timing chip programming with some button interfaces to the fpga and some programming.

I moved the website to indiehdp.0catch.com (the cjb one now has a link to it)but be warned, use firefox or somthing that stops popups, i didn't think it was bad until i tested it in IE. At least i can update it via ftp now, unlike with cjb.net.

Hmm, all this stuff is tricky and requires some hard work and learning.

I have had a look at the Kodak sensor and compared it to the Ibis5a and tried to compare it to the Micron. Problem is that Ibis uses a lot of basic noise values, I could only find one of them on he Kodak chip, and Micron roles them up into db values (but not in the high speed sensor). It looks like that the Ibis has over 50% more latitude (well capacity) and less noise, but I don't know how to interpret these noise values to find how they interfere with effective true latitude. In comparison with the Micron it appears better, but again, I couldn't compare overall noise factors. Maybe you can have better time at it.

http://www.fillfactory.com/htm/products/datasheet/IBIS5A_1300_5.pdf

http://www.fillfactory.com/htm/products/htm/ibis5/ibis5a.htm


Forgot to mention this:

Based on the Kodak sensor:

http://www.imperx.com/cameras/megapixel_digital_cameras/2meg_high_definition/index.html

All these camera has embedded RISC processor and FPGA.

Their is a lot to try and consider when trying to compare cmos and ccd's.

The full well capacity may be higher on the cmos, but you will normally only get full well in super bright conditions, and for that amount of charge to build up in a photosite your going to need a lot of light energy. The full well capacity is related to the latatude, but not as much as you might be thinking. More how well it works in very bight conditions, but as most people know, we don't always have very bright conditions.

The dynamic range and the s/n ratio are much more important. If the s/n ratio is higher that means that the signal is cleaner and the difference between one level of brightness to another will be greater. But even still, that plays second to the actual light gathered.

But what you also need to look at is really how much light is getting to the sensor, This will determine a lot. The kodak has larger imaging sites which means they can gather more electrons. So lets do a comparision and say the ibis5 gathers 10000 electrons @ 30% qe. Because the kodak has larger pixels it gathers [(6.7x6.7)/(7.4/7.4)x10000] so it gathers about 12200 electrons. But the kodak has higer QE so now it gathers (0.36/.3) 14600 electrons. In black and white.

Now lets make it really bad, at 450nm wavelength (blue) the kodak has absolute QE of over 36%, so lets leave it for 14600 electrons. The IBIS has .42 relative, so relative to peak it only gathered 4200 electrons.

Green (550nm ) : IBIS = 8000 vs kodak = 13400
Red (650 nm): IBIS = 10000 vs kodak = 12200

As you can see the kodak sensor in the same lighting will have over anywhere from 1.2 - 3.5 times more electrons gathered. so the ibis will be about 1/2 as bright as the kodak. Do you really think that full well will really mean anything if takes 2 times more light just to get near the kodak full well or 4 times more light just to fill its well to max.

Also, did you look at the ibis colour filter , the ibis colour filter response is poor at best. When blue filter picks up a green light wave on ibis it is about 1/2 a blue so will affect the blue brightness even though it is green that is striking the sensor, but with kodak is about 1/9. The kodak filters are clearly superior - unfortunately for most people.

I'm not ragging on the ibis, its a good chip that when used properly and it can really give a nice picture but the colour filters remain poor at best and this is where the IBIS gets it poor colour. In a 3 cmos setup the ibis would be amazing because you could control the filters.

I'm not saying that the ibis is no good and throw it away, Just when i was doing my research and checking availability the numbers i crunched showed kai-2093 was a better sensor, but was going to prove very hard to work with.

If i took an ibis right now i could literally jump to fpga programming and not have to worry about the issues that i do now like timing, but when the numbers show that the kodak will give more accurate colours and a better s/n ratio because it needs less light that was where i decided to start.

I did see that imperx camera before along with one from red lake. I'd love to get my hands on one but I just don't have the money. The redlake one was about 3500 euros, so that would be about 5k in canada plus a cameralink card. I'd assume the same for the imprex one also and i'm really trying to avoid cameralink.

I'll be honest, a production KAI-2093 is 1200 USD, while a ibis is somewhere around 300 USD. It might cost just as much to build a 3 cmos setup or be cheaper than what i have designed so far. That really makes me sad now that i think on it.

Wonder if their are and 3 cmos ibis cameras around, that would be cool.

why don't you just make a 3 sensor CMOS using IBIS.Add pixel shift.
So we can end up with a great Global Shutter CMOS camera with any possible resolution from 1280x1024 upto 2560x1024.....:)

Ok, I was thinking. Wouldn't it work if you just hook one of these HD cameras to a PC and use a NLE like Vegas or whatever would capture that to the HDD? I know you would have a 2 piece system and not very practical for location work, but would that work? Would that maybe solve many of the problems people are having with trying making a camera?

Michael, I think a lot of people here started with this line of thought. If you take one of our gigabit cameras, use a 20m cat-6 cable, power and a buffered VGA for a viewfinder going back to the camera, you have a very small, tethered camera head. With a VGA splitter, the director can see the shot also. Maybe use a Shuttle or Epox (?) mini enclosure and a small RAID and you are there. The rest is just software. Simple. (OK, I ducked when I typed that in case anything was thrown at me).


Ok, I was thinking. Wouldn't it work if you just hook one of these HD cameras to a PC and use a NLE like Vegas or whatever would capture that to the HDD? I know you would have a 2 piece system and not very practical for location work, but would that work? Would that maybe solve many of the problems people are having with trying making a camera?

Juan, that is what finally occured to me at the end of writing my giant comparison speal. I've spent a few weeks now working out schematics for the KAI-2093 and it seems almost a waste when i wrote that one sentence.

One problem is the alignment of the sensors, this would be a pain without special equipment, or could just do a "good enough" job and sort or the offset with software.

Focus is the other problem, its harder to get the sensors onto the right focal plane with the extra glass blocks in the way.

But beyond that, well, it shouldn't be so bad so maybe i'll start considering it. Since i'm doing fpga anyway, i'm also debating doing the timing for the ccd in that, since the vhdl program only has to define a few timings rather than the infinite timings on the KSC-1000.

Michael, your right in you assumption that connecting it to a computer would work and Steve is right with his quick summary (minus the software aspect).

I'm just going another route, and many will think, a hughly stupid route and way to complicated, but then i have a lot of control. What i'm doing is pretty much doing what SI does, build the camera head, but i'm trying to get to component and hd-sdi output rather than cameralink.

So i'm trying to build a POV camera like ikegami hdl-40, just for less than 20 grand and then deal with the computer aspect

if it's a computer, so you could use maybe Vegas to capture. What type of file those cameras out put?

What most are outputting are cameralink, which is not compatible with nle's and that is what obin and rob s. are working on, software to use cameralink cameras.

Even the firewire cameras will not work with nle's because the aren't using any variation of minidv, they are using dcam (IIDC) which is a protocol for uncompressed raw data transport. Same goes for usb.

And beyond that their is the camera issues, but that is just a whole different discussion.

Well, my design kind of had some changes and i'm trying to work out what exactly I'm trying to output. Since i'm programming an fpga solution for my camera I can almost have it output whatever i want, within my skill (essentially nothing that requires a protocol[This means i can't do usb, firewire, ata, sata, gige]).

So, i'm thinking I might try and go for both component and HD-sdi out of the camera, and then work on an fpga capture solution. (HD-sdi hard drive capture deck? That would be cool). Right now I don't have any idea how to do debayer in the camerahead without some ram connected to it, then I'm really stretching my abilities.

The sumix altasens based camera is going through testing at the end of this month, so maybe in a couple of months they might ship a couple and then we could have a camera that could be easily put together and rival stuff like kinetta.

Well about the positioning don't think it is so difficult.
You can buy intrumental/tools for that at Edmund optics.Just a simple device using ball screws or even a Palmer's Screw ;) (BTW micron accuracy).They cost less than 1 K.
Then just need the prism and some adhesive + a clean environment.
Focus doesn't need positioning itself because that is given by the prism surfaces themselves.
I also guess that Monochrome IBIS are probably cheaper than the color one.

And beyond that their is the camera issues, but that is just a whole different discussion.

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.

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.

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

Their is a lot to try and consider when trying to compare cmos and ccd's.

The full well capacity may be higher on the cmos, but you will normally only get full well in super bright conditions, and for that amount of charge to build
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.

But what you also need to look at is really how much light is getting to the sensor, This will determine a lot. The kodak has larger imaging sites which means they can gather more electrons. So lets do a comparision and say the ibis5 gathers 10000 electrons @ 30% qe
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.

Also, did you look at the ibis colour filter , the ibis colour filter response is poor at best. When blue filter picks up a green light wave on ibis it is about 1/2 a blue so will affect the blue brightness even though it is green that is striking the sensor, but with kodak is about 1/9. The kodak filters are clearly superior - unfortunately for most people.
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.

I'm not ragging on the ibis, its a good chip that when used properly and it can really give a nice picture but the colour filters remain poor at best and this is where the IBIS gets it poor colour. In a 3 cmos setup the ibis would be amazing because you could control the filters.
Actually Sumix is hoping to attempt one.

If i took an ibis right now i could literally jump to fpga programming and not have to worry about the issues that i do now like timing, but when the numbers show that the kodak will give more accurate colours and a better s/n ratio because it needs less light that was where i decided to start.
I have not seen an SN for the Ibis, what is it?

I did see that imperx camera before along with one from red lake. I'd love to get my hands on one but I just don't have the money. The redlake one was about 3500 euros, so that would be about 5k in canada plus a cameralink card. I'd assume the same for the imprex one also and i'm really trying to avoid cameralink.
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.

I'll be honest, a production KAI-2093 is 1200 USD, while a ibis is somewhere around 300 USD. It might cost just as much to build a 3 cmos setup or be cheaper than what i have designed so far. That really makes me sad now that i think on it.
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)).

Wonder if their are and 3 cmos ibis cameras around, that would be cool.
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.