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.

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

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

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?

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?

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.

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?
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

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.

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.

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

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/prod_cam_sci_Harrier447.htm

Interesting 1" Chip camera (150fps):
http://www.photonfocus.com/html/eng/products/products.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.

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.

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.

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.

Update:

The design was getting pretty big and bulky, but because of some corrospondance with kodak I've found that I can get 30P that is compatible with SMPTE 274 without having to use asyncronous FIFO's. I'm crunching the numbers now to see if i can do that same for 24p because that is all that really matters to me right now, and all a single hard drive could handle in 10bit. (keep in mind only one channel, CbCr channel is empty)

Fpga will still be used for timing and appending the dual outputs together and controlling the commands to the serializer, but I feel that i'm really close to having a HD-SDI bayer camera design finished. Now i just need to get the couple of thousand dollars for all the parts to start testing.

Since i'm only a student I'm going to get some of the electronics guys in my university to look over my final designs in a week or two. Make sure i didn't miss anything.

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

I was re-reading this post of yours Obin and I was thinking, isn't the Drake using this very same sensor? It doesn't look like a 1 CCD spy camera to me.

I would guess it's early to make any decisions on the Drake as they have not shot any outdoor sunlit stuff yet...but I would bet the color is not that good as you would have to pump the color in post so hard for a ibis chip..I have seen the images from Ibis...but then again maybe they have found a way....don't think anyone knows yet...

one more thing..maybe FillFactory has a NEW IBIS chip that is better...

Keith you are telling us your FPGA design is done?!?! do you have RAW record-to-disk a viewfinder and camera control?

christ that would be GREAT news..I am not sure how you could have done it that fast..are you working with 12bit 1080x1920 images at 24fps?

I think the HD-SDI idea is REALLY great! good work Kieth, keeping a signal on a HD-SDI path works well because you can hook that to many professional decks, cards, etc...and I see how a bayer image could go over sdi as it's really just LUMA!!!!! amazing! that is great! and like you say we can just de-bayer it in post and or compress it!


so what is left to get camera control and images out for a viewfinder or monitor?

I am not sure how you could have done it that fast...


well where i work, the hardware guys would do it in 15 days with compression on a fpga ... they just have to add a ATA interface or something to some design they already have. Too bad their products don't have much in common with cinema.

I don't have the major parts yet, and by that i mean the sensor. I need about 1500 usd to get a quality sensor and an eng grade sensor, i'm still gathering money for that,i hate being a student.

I had this elaborate chain of programs started on. The flow chart was huge, and involved all sorts of FIFO's and buffers and stuff. But that all got scraped because I found out i could read fake lines, so even though the sensor only has 1092 real lines, i can read 1125 and then config line timings. I reduced the design to just 2 programs. A timing program and a line append program.

But now I have the timing program pretty much done. Doing simulation on it is all that is left and setting a method to enable switching its modes, which are 24p, 25p, 30p that still all complies with smpte 274 right of the chip. I have a poor program right now that interleaves both dual output channels together instead of the complete line append, but that is only for testing. Would result in a really stupid picture and lots of post processing to get it normal.

So one program is practically done, just making sure that everything works perfectly and i can switch modes. It also incorporates timing pulses for connecting to an rgb monitor, which means that you can monitor the bayer in b/w. Not a great solution but it should work. Just have to finish a line buffer program that i started because the sensor is dual output.

I stress, this is only the head design and isn't built - yet, you need a computer with hd-sdi to capture so far or a dvcpro or hd-cam deck. The hard drive deck design is still in its infancy because I need to get NDA's sent out to the companies I want to get IP cores off of for ata and sata. But from some of the companies it sounds that this can be pretty easy to do what i want and record directly to LBA's.

HD-sdi specs out 10bit per channel, but it is possible to expand this, just need to use the 2nd channel which i have left empty for now. Could go as high as 20bit then and you would have a lot of data.

Sure a company could do this in 2 weeks, but i'm a student with only a little fpga background and very little money. Also i took down the website recently, I was having problems with it and i really hated the free server. Shouldn't complain, it was free.

I had the design looked over by some people in know in the faculty and they are fairly confident that it will work as soon as i get the sensor as long as my support electronics are tested. which right now are kind of a jumble and mess of wires and stuff.

So to summary:
No sensor means no pictures, just fpga programs and simulations and electronic designs and testing.
The deck is waiting for an ip core and documentation.

Sorry if i sounded offensive, it was just a quote for Obin to say that with the right guys, you could do it really quickly. I'm a student too, and perfectly understand the problems you're facing, and i'm still impressed (and pleased) by the quick progress you're making.

For the sensors price, well that's why i proposed this kodak cmos sensor, 18$ is much more affordable than 1500 for a student ;)

Keith can you call me or I call you?

910.262.3434

Steve I wasn't really retaliating i was more joking around. I knew what you meant and i knew you didn't mean any offense to me at all.

The problem for me is that it i can control the timmings for a ccd (as long as i got some documentation on the clock signals) but with a cmos it is harder to do that and doing things like increasing vertical clock time and waiting times for a cmos is much harder because you need to program registers and stuff like that and will make it much to hard to get the smpte 274 compliance without having to use asyncronous fifos, which I'm so happy that i can avoid.

I'd purchase an eng sample right now, but in order to do that i need to purchase an evaluation kit or at least one production sensor. I haven't asked if they would sell just one eng because i'm a student, but maybe i should asked, or see if i can get a few eng samples instead of a production one.

Obin:
I can't call you today because i'm on the road later today and I won't be home until 10 pm my time which is gmt -3.5. Is that to late to call you? I'll try then, if not i'll do it tomorrow if you don't see this in time.

no problem call when you can

I feel like I've been watching a miniseries only to find that it's been canceled just as our heroes are starting to get the upper hand!

What happened with your development platform, Kieth?

Dan

Project direction changed and were going good for a while off the boards - then I had an accident recently which has put a complete stop to anything i've been working on but I'm working on it again. Not a development platform anymore, but can't give away much on what it is.

I'll just say this: We don't need no stinkin' computers! and thats a fact.

I can tell the sound of a guy getting serious.

You go!

Good luck.

Dan

Just keep an eye out and hopefully we'll surprise some people.

and no stinkin tiny flat lifeless 8bit 1/3rd inch ccd chips...and that's a fact

but the biggest "fact" of all: we don't need no STINKIN HDV CRAP!!!


LOL

I really wish I remembered what movie the whole "we don't need no stinkin' (insert stuff here)" pharse came from

blazing saddles

I'll just say this: We don't need no stinkin' computers! and thats a fact.

I agree with that, it was only a means to a quick end, before we went to FPGA hardware (now done thanks to people like Juan and Andrey). Unfortunately it didn't happen, except in various bunches like Cinelerra.

Please keep us informed Keith, we are still waiting for cheap cameras.

blazing saddles

"We don't need no stinkin badges" is from The Treasure of the Sierra Madre.