FPGA
 

Cores
OK as I said before, you can go to Opencores (or other) ask people there if anybody would like to be involved. You can ask in the opensource community too, but mainly programmers. I'm sure people would love to do this just for he fun of it. You can also ask on FPGA newsgroups (many pro's) who should also be able to tell you of pro mailing lists and web forums stack full of bored eager FPGA'ers. Opencores may have half the circuit designs you need (where ever they all work perfectly I don't know.

Opensource
Whatever FPGA core that is created should be opensource so any manufacturer can use it but not own/control/pricing it. Steve has allready offered to use it. You will need to break the design down into theree parts, front end, so different sensor heads/manufacturers be used, processing middle end, and rear end so that different capture interfaces canbe used. With this stratergy new sensors and interfaces canbe supported, it also is not very difficult to do. lots of flexibility that stops us getting tied down.

Cost
As I say before it takes tiem and money, more than software PC should,

How easy
I understand some of the programming langauge for FPGA is easy, and people here should be able to do, but you need to learn what your doing and have knowledge for circuit board design and interfacing in a high speed environment (that introduces niose factors that make design tricky). But my "guess" is that you can mostly black box the FPGA in isolation from real hardware and get somebody else to do the interfacing, aslong as you are sure of what data and format is going to come in and what data is needed to come out. My guess is that it will take upto 6 months to learn all this. A few people here indicated they would do it and started a thread (look it up).

Manufacture
The problem you then face is manufacture, unless somebody else pickup the tab (like SI) low volume costs are much higher than high volume costs, so you might find board is as expensive as PC system until sales hit at least 1-10K. But I'm not being completely negative, I think it canbe done.

The www.untratechnology.com forth processor chips section has links o a number of projects. Some people in this level of the forth community tend to be very good programmers and like community initiatives also.

Cheaper more flexible alternative/hybrid
I would suggest that it maybe better to put a small processor in the core fort the control functions etc (or get a processor with a core, they are out there but I don't know if they have big enough core). If you go to ultratechnology forth ciips link above you will find probably thee smallest/fastest cores available (I'm talking much less than 16K gates). Once you go down this path and also use functions from open compression cores on the web you can make parrallel arrays of processors (preferably in sequence, as parrallel to external memory is way difficult for a FPGA or in Silicon). Now you can reprogram any time, any thign you want, just like a PC (except you willhave to get Forth programmers to do it, because it is queit a leap in logic from C or even assembler). Still maybe you can get some cheap embedded processor to do it (AMD MIPS or Arm) and mostly scap the FPGA (though there might be ARM/MIP with FPGA). Still low volume cost still comes into it, but I'm sure people will start doing Windows devices on 2 Ghz Arms sometime, or embedded controller, that could be bought bulk OEM (rather than consumer) discount, or just buy the design and get it network (contract manufacture out) manufactured like Nintendo manufactured. Still make you own and network manufacture it. Or just say to camera/sensor manufacturers "here, opensource", or how muchh for oem and we add the baord, or whatever, speculative.

Others
You will probably find that somebody is allready down this path, but you face the problem that A PC is extremely flexible and code modifiable compared to FPGA. Also what codec and software you can support is more flexible on a PC (as I said elsewhere) so you could even boot the PC cqamera up as an editor and add monitor and drive and pheriphals by VGA and One usb port on motherboard for portable feild work after shooting.

Rolling shutter and mechanical shutter and others
 

<<<-- Originally posted by Steve Nordhauser :
..
Wayne:
The Altasens can read out at up to 60fps for a full frame, letting you drop every other frame at 24 or 30fps. It is still rolling shutter.-->>>

Steve, I was just quoting what I read that the actual read out time is many times faster than he frame rate without dropping frames, which is how they deal with rollign shutter and many times superior to what canbe done with present rollign shutter cameras.

David,
Thanks for that

Rob
I forgot not only reducing gain, but also clock speed as that might has something to do with it. I veiw it as feed of oversatutared pixels (which also works on satuation inside clock periode, faster clock might make it more leaky, or less, depending on the design problerm causing it). Steve?

Mechanical shutter
The problem is that the rolling shutter chips tend to readout in parralel with acquiring the image, we have tried to reduce this by putting readback back in the blanking part of the frame and speeding up the clock (is that right?). But still you get the readout going accross to much of he frames acquisition time. So the mechanical shuter is going to have to be shut for a big periode of he frame greatly darkenignthe image. With Ibis global shutter, from what I understand, you also lose substantial light (but probably not anywhere near as much), but you start with less fill facor (= lower light) to start with.

Next chip please! If they replaced these chips with more Altsens like versions we would be doing well.

Optical veiwfinder VS Electronic
I too would like a more professional electronic solution, no light loss and an objective version of what the sensor can see (pluss I can replay it and decide if the scene needs another take and the old take needs to be kept or not).

About Vance and Jaun
I think Vance knows about this project, he has been over in my Homemade Camera design thread before, adn I have posted details on Jauns thread. Maybe Jaun might like to do a free (or probably commercial) FPGA/capture device for us. I'm not all for integrating methords, unless it reduces cost.

I hate this board...can't post anything long at all/....

BTW check this out: www.dv3productions.com/pub/Obin Test3.mov

that is HEAVY compression for the internet..the original looks REALLY good....VERY soft and "filmy"

holy crap, that looks good...

how much did that setup cost you obin? i mean if you weren't getting the camera for free for testing it :)


btw.. i just realized something cool.. if you're shooting full letterbox 2.35:1 aspect ratio, the bending of the image you get when panning quickly with the rolling shutter would be less of a problem because there's less vertical image..

I need help.

WIth our 8bit captures right now I have to WAY under expose to get the range out of the camera I want. The bad thing is that when I shoot like this and bring the gamma up in post the images are falling apart really bad. Lots of banding artifacts. I am doing this in Combustion and Digital Fusion. Both have the same results. Is the nature of 8bit captures or can somthing be done about this that I don't know about?

Please if someone knows the answer to this let me know.

I am sure that 10/12bit will be much better..but 8bit is AWESOME if the contrast of the scene like the above post is not too high.


"bending" or rolling shutter will not be an issue at or above 67mhz..I have run that with the camera in 8bit mode and it is almost gone..as soon as I can get a 64bit FG card I can run at a very high mhz and kill the rolling shutter issue.

WOW 1080p!

Oh the above image has been resized to 1280x720 so that you guys on the list could see it on your monitors...unless you have a monitor that is above 1024x1280 this mov file should playback just fine..if you have a high res CRT I could encode a full-on 1080p file ;)

I should have 1080p 12bit files soon..I will need a faster set of disk drives but I will do some tests at 15-20fps to see how the banding is from an under exposed 12bit capture

CPU load is now at 20% in black and white and about 50-60% with color display...we killed the multi-threading of the save. That was the issue with 100% CPU load before

Eric the camera costs about $2500 and I have put 3 months of work into this system to get it working with my programmer who I have hired for this project.

Yes Obin, what you're describing is the nature of 8-bit LINEAR images.

Your good video cameras, Varicam, F900, etc. may record 8-bit images, but they're receiving 10 and 12-bit images off their A/D converters before video processing begins. For our project here we're doing video processing inside of a post app like Combustion, but in order to get the same results that you'll get out of a high-end camera, you'll need 10 to 12-bits to prevent that banding, etc.

Hope this helps.

BTW, sweet images!! (and no more jerkies!)

thank you Jason..that's what I was thinking but not sure...so at 8bit you really can't shoot high contrast stuff at all...hmmm if you do you have to expose for lots of blowout to get an image that will work or shoot the same scene in 10/12bit and under expose a great deal for later gamma work in post

I am waiting for the "convert" part of cinelink to be updated with 16bit tiff output

The shot of my face was very low-contrast lighting and it worked well. Just expose what you see and it's fine

Ok I am looking at 94MB/sec datarate off the 3300rgb @ 12bit/24fps 1080p..David have you made any progress with the realtime CineForm Codec? now would be the time to start working with it in CineLink..let me know what your thoughts are about this..thanks

Obin,

How hard would it be to make your system fully contained and portable?

Obin,

Yes we've made lots of progress on the codec. But unfortunately limited time and and some technical issues with Camera Link have slowed down a ready to go solution. I would be concerned but the 94MB/s over standard PCI, I found it would drop frames occassionally due to bus saturation. Email me for followup on codec details.

[Vader]Impressive.[/Vader]

I'm such a geek. Very nice clip. Doesn't play very smoothly on my Athlon 1700+ with 32mb video card or my Athlon 3200+ with 8mb video card (don't ask). Still, it looks very nice. I'll have to check it out at school on the Dual G5's to get a real good idea, but congrats on your breakthrough.

David, was there anything else on the PCI bus? Seems like PCI should be capable of capturing @ 94MB/s without any problems when the theoretical limit is 133MB/s.

Or is this another problem with the framegrabber not having a buffer on-board an it's in fact using up 16-bits per pixel with padded zeros for a 12-bit signal. Or each pixel is using 2 bytes. That would give you 124MB/s for 30fps at 1920x1080, and yes, at that rate I'm sure you would drop some frames from time to time.

But again, I'm thinking that 24fps at 12-bit being 77MB/s and 30fps being 94MB/s shouldn't be any problems for the PCI bus, again, only if you're actually transfering 12-bits over the bus and not 16-bits.

I was trying for 1920x1080 @ 24p = 95MB/s. Yes there are other things on the PCI bus but nothing active at the time. The theoretical 133MB/s is not reachable. 100MB/s is more likely what you will get. 95MB/s was occassionally too close to that limit.

BTW, just curious, how are you guys getting 95MB/s for 1920x1080?

with 2 bytes per pixel (16-bits), 1920x1080x24 = 99MB/s
with 1.5 bytes per pixel (12-bit), 1920x1080x24 = 74.6MB/s

So if that's the case, then 99MB/s is right underneath your 100MB/s limit, and you'd probably run into some problems. BTW, I'm not doubting your numbers, I'm just trying to see what I'm overlooking for that 4MB/s difference.

:)

1920x1080x24x2 = 99532800 Bytes/s

Divide 1024 = 97200 KB/s

Divide 1024 again = 94.9 MB/s

"Divide 1024": Doh! ;-)

http://www.dv3productions.com/pub/fr...color look.jpg

this image even got our programmer aroused..trust me thats not an easy task. ;)

as the frame says 1080p converted to 720p and CC capture from 12bit

wow.

BTW just so you guys know this 3300rgb has more dynamic range then the Panasonic dvx100 that we have .. I find this really nice ;) the face photo was much darker on the dark side with the dvx100 then the raw file from the 3300rgb

how much latitude would you estimate your camera has?

not sure without a professional test..but it's more then standard DV 3ccd cameras

Another thought on the frame rate calcuations. Unless the capture board has a full frame of buffer (the Epix doesn't), you get the peak, not the average data rate over the bus. Average is the way you are calculating. For the peak value, look at the clock rate you are using - I'm guessing around 60MHz. In 12 bit, unpacked transfers, that is two bytes per pixel so 120MB/sec for the active readout and then quiet during the blanking.

Obin, I'm really impressed with your 3300 images.

Do you think you could run a few tests? I'm not sure how you would go about that exactly but it would be very interesting.

I'm also VERY impressed by that image. Very well done.

Obin, what type of lenses are you using for these shots? Are you still using those c-mount lenses from a 16mm camera?

<<<-- Originally posted by David Newman : I was trying for 1920x1080 @ 24p = 95MB/s. Yes there are other things on the PCI bus but nothing active at the time. The theoretical 133MB/s is not reachable. 100MB/s is more likely what you will get. 95MB/s was occassionally too close to that limit. -->>>

David, as Steve said, but there would be another additional problem when going so close to maxinum trasnfer values, That even though the extra periphials on he PCI bus might no be used, the system might be still polling them (interegating there existence or some other minor activity) that will interrupt capture work flow.

Jason:
I think you can get away with 8 bits, if you do the gamma curve and some setup on board the camera itself, as Sumix and Drake does. I don't know if SI allows you to do this setup though, but I imagine a firmware upgrade might. Actually what embedded processor does the SI cameras use, if it is a regular type of processsor (ARM or maybe Mips, and Nec or Samsung had one too) then this canbe upgraded in future design to a chip with 1-2 megabyte embedded ram on chip (I think they go to at least 16MB nowdays). With some innovative programming the ram could be used as a circular buffer, never even having to store a full frame, just enough (less than 50% to average out 24fps). I realise that certain memories don't like a speed of 50MBs but I image they can work a lot faster, especially if we are talking about 32bit memory. Those Cameralink card I pionted out recently had a 2MB buffer chip, which is also another route.

Cinelink
I have 1920 Monitor (everybody should have, so cheap now, even Phillips). Mutlithreading on save causing problems, that sounds right. Congradulations on getting this far.

We could get away with 8bit if the camera head could gamma correct the images BEFORE save..this would be a very nice feature..Steve??

thanks for the good words Steve...I myself am impressed by the images! I do want a chip that has no checkerboard though ;)

Steve how am I getting 60mhz from the 3300rgb @ 12bit with no FIFO overflow on the 32bit EPix card?

You should be fine (or at least right on the edge) with 60Mhz, as PCI 32-bit is capable of 133MB/s (theoretical).

But as David pointed out, max sustained you should expect from PCI 32-bit is around 100MB/s.

lots of people have LCD screens that max out at 1280x1024 like all the edit stations in the office.. that is the reason for the downsize

The Epix 64bit card will be nice. With that card I could sleep at night without the worry of FIFO overflow and complete system lockups from the massive amounts of data we have to move around with this system ;) and maybe even start to think about doing overcranking!

8-bit would be nice, but even if the gamma is corrected before going to disk, I'd love to see 10-bit images written to disk. There's just so much more to work with in postproduction (colorgrading in particular), that I think it's really worth the extra expense.

So are we waiting for PCI-X 64 bit framegrabbers to get the required bandwidth?

Bar3nd

No I am not waiting but it will allow the speed we need to capture 24fps 12bit files on-disk. At the moment I am on the edge of the limit from the pci buss and I am not sure how the new motherboard will deal with that much data. I will have to wait and see how it goes with the new microATX board I am waiting for.
I also need to order the 74MB/sec SATA disk drives so we can get upto 148MB/sec datarate going into the disks

Obin , if by "overcranking!" you mean "overclocking!" I would say-YES!!! EXACTLY!!!

As a "HardCore" overclocker I can share some digits: A PCI Voodoo3 2000 VGA work at 50MHz PCI buss -no problems. A HighPoint UltraATA RAID controller work at 48MHz -no Problems -at 50MHz and above the information on the disk array is killed, so you need to lower the freq and build the RAID again...

...usualy a 44 MHz PCI buss is a 99,99% safe value... ONLY on intel chipsets!!!

A BIG WARNING - DON'T do that if you use *SATA* HDD's - you'll lose your data!!!

Also 5 years ago I've killed the partition of my C: drive at 44 MHz PCI ,but I think today's PATA HDD's are much better in that aspect (I mean HDD's from Maxtor and NOT from Seagate!...Don't know about WesternDigital)

Tell me if you are interested -I have to say more...

Best Regards!

Marin

"Overcranking" and "Overclocking" are two different things.

Overcranking describes a process in traditional film cameras where you "crank at over" 24fps for slow-motion effects.

BTW, the other thing that can prevent these overflows, etc. is something with an on-board memory buffer, i.e., the GigE interface.

But doesn't GigE max out at 100MBS the same as pci? I am really interested in the GigE interface but if it is riding the edge of 1080p 12bit and is unreliable at that rate it wont work for me. Steve is this problem solved with bit-packing? If so what hurdles need to be jumped in software to unpack the bits and access the files?

Rob:
The GigE is 100MB/sec after derating - that is the real, continuous rate as long as the system bus can handle it. It does packing - 2 12 bit pixels in a 3 byte sequence. It can be stored to disk packed so the cost is when you pull it out to do Bayer and the rest of the processing. And it does have frame buffers so you can use average rates. *However*, overcranking will not happen since 1920x1080x24fps x 1.5B/frame = 75MB/sec. You could go up to maybe 35fps. Camera link (64 bit) removes that limit.

Obin:
We do analog gain control in real time in the camera head since you need this to get the full dynamic range from the sensor (R,G,B filters have different responses, lighting may have difference spectral intensity). Unless we are convinced otherwise, we probably won't do any other real-time processing in the CL and USB cameras. Possibly in the GigE since it already has and FPGA and memory in the data path. CL will probably always deal with pristine data.

Marin, I was just about to post on that too. I think there is enough latitude to allow for 30fps capture at least on PCI (I hope). I wonder, how much can you overclock a Gige signal ;) (double would solve most of our problems). I wonder what would happen if we did, isolating and Pelter cooling the Gige interface accross high quality tr4ansmission lines, or maybe converting to a optical format and then converting back {:) .

To all:
People have been overclocking the PCI bus for years, now days it is a bit more complicated, but this is what I can remember. That the PCI bus clock maybe used for some other system timing, like AGP, memory (or maybe even ATA) clocks may all use subdivision of some master clock (can it be subdivision of subdivision too ??), therefore all linked, and increasing master clock could max out some other system, so changing clock multiplier is the best way, and whatever on the master clock you can get away with over extended uses (without random crashes). System overclocking tolerances, what happens and how the clocks are arranged can change from baord to board. Now the card itself may also have different tolerances from card to card. I think I rember something about increasing PCI speed also producing greatly increased power draw on the card. Anyway there should be stacks of overclocking stuff on the issue on the web.

The not to distant future and the way out there:
What we really need is to think of the future, that means cameras with on camera buffers, on camera compression (lossless to visual lossless to quality of HDV2) and twin Gige (1GB's) links to get descent frame rates off of cameras with 12bit depth. Something not thought of is the edit Iris controll. When we have cameras that have a latitude to match big bit depths (16bit+) then a wider latitude canbe shot with more ability to play with in post. Such a shot (maybe with more than 16bit latitude) maybe my actor standing infront/to side of the sun with details of both clearly seen (though obviously the actor looking murky from the squashing of his contrast involved). Finally we will get the ability to film and show accross a large light range where the audience contracts their iris's depending on what they are focusing on. I have been thinking about this for a year or two. There is more, but I think it is possible to deliver today, if any camera had the bit size and SN ratio to match.

After some surfing' guess what i find!! OK OK THIS may be OLD news but its bloomin new to me!! How the hell did i miss these?

(1) Olympus 8-Megapixel HD Camera
http://www.cinematography.com/index.asp?newsID=3342

(2) 3840 x 2160 Hi-Res Box Camera
http://www.cinematography.com/index.asp?newsID=2714

come someone comment

i know a few months ago we talked about RECORDING TO RAM as an option for high-speed capture... will that not allow you to record whatever resolution and color depth you want?

how about stuffing a server with 20gb or ram?

Anhar

Yes those SHD cameras, I want one with that res, I mention them a few times, that is the one with the prism that spilts the image accross 4 chips to get 8MP. The IGS ssytem is the company with that capture card I put up for everybody to evaluate and comment on a few weeks ago. They are also interested in Cinema camera stuff, and I pointed them here.

<<<-- Originally posted by Eric Gorski : i know a few months ago we talked about RECORDING TO RAM as an option for high-speed capture... will that not allow you to record whatever resolution and color depth you want?

how about stuffing a server with 20gb or ram? -->>>

the problem is the maxinum speed the capture card can get accross the PCI bus to disk or memory. Also 20GB (try 200GB-2TB) * $ then it has to be stored. We have a intermediate scheeme of using max onboard ram to smooth things out.

Thanks

Wayne.

<<<-- Originally posted by Wayne Morellini : Marin... I wonder, how much can you overclock a Gige signal ;) -->>>

I know nothing about the nature of the GigE signal ,but there is a HUGE potential for overclocking (in our case)-it's obvious-the difference in cable length! If we can put together the camera head and the motherboard-the GigE cabel should be about 30 cm and not 100meters!

At the years of i386-i486 processors there was a small button on every computer case,called "TURBO" :))) ! So what about same thing here - Not pushing TURBO -you are safe,GiGE compatible,able to reach 100 m and even 110 m ... and on the other hand -Pushing TURBO you are uncompatible,limited to 30cm, but deadly fast? :)

If this is possible ...then the "mini computer" could stay realy mini- with the GigE chip on board,VGA on board,RAID on board the overall height is close to 1inch ! Also If I remember correctly on intel 865-875 chipsets, there is a separate buss for the onboard Ethernet adapter and if we use RAID 0 with the help of South Bridge (ICH5R-separate buss too), then the need of overclocking PCI become unduly!

Best Regard!

Forgive me but I still cannot get the word "Overcranking". Is the word "cadence" similar?

Thank You!

No not really. Cadence refers to a specific rythme. Overcranking is different.

With a film camera to achieve slow motion it is necessary to shoot more frames per second than usual so that when you play back at normal speed the motion is elongated - hence slow motion.

For example you may shoot at 48fps and then play that back at 24fps effectively creating slow motion.