Wayne Morellini wrote:
The hotspot, can you get rid of it by reducing it just below max pixel value, by reducing the gain or putting it in reverse, or just using ND or iris, or is it a contrast thing with surrounding pixels?I haven't done a lot to try to reduce the smearing, but your idea of reducing the gain is a good one. I'll try it.

Lets thinking on differnt ways.

@Robs FPGA problem list:

1. it would need cameralink or gigabit ethernet in (Juan gets other kind of signals)

a.) Why not? But...
b.) Take the next step. Look inside camera heads. Most CMOS Sensors have digital, par. out, so why not connect the CHIP direct to a FPGA. (Okay, if you can do this, you need only a sensor and a few parts, not a camera head form manufactor xxxx)

2. it would need firewire 800 out (which Juan's FPGA solution seem to have)

If you can build a FPGA system, it will be easy to build also firewire ports or others. There are lots of chips for this work. But, look at point 5...

3. we need a viewfinder/monitor out (Juan already has this since it is on the host camera), since there is no host camera.

a) optical viewfinder?
b) second FPGA or PC based system for that job

4. we need controls to choose settings (Juan already has this since it is on the host camera), since there is no host camera

Write software on PC, test it out and translate the ini and control function to a MC.

5. we would need some form of RAID support either in the FPGA (either make it ourselve or have it builtin) or in the harddisks attached (ie, the Lacie RAID 0 drives??)

Take your brain free from all PC stuffs. The A/D Unit, inside (or outside the CMOS Sensor) have 10, 12 or more output pins (each pin is one BIT). The output rate is 33-66MHz. FPGAs can handle those data speeds in realtime. Shift or translation to 16Bit words are simple works. Next part is the Harddisk. Not a controller or interface, you can write direct to disk. A HDD needs words, not bytes. There are 16Pin (one pin = one byte) and you can connect it also direct to the FPGA or MC.
Also you can split the datas to more than one hdd. (First word to first HDD, second to second...)
But some sensor chip manufactors do the work for you. Most chips (2M pixel, or more) have two, or more output ports. Your FPGA can handle this and you can write to multiple HDD, without software logic. (First chip output go to first HDD, and so on)

Okay, FPGA is a new world. But since i thinking about a 3 chip, 1920x1080 camera, i think its the only way we can do it now. Also there are a lot of people with FGPA know how in special forums.

Regarding FPGAs ... When we discussed this a few months ago, Steve Nordhauser indicated he'd be interested in embedding a FPGA solution inside of the "box" camera. In this case, the FPGA would be connected directly to the sensor and would output a compressed signal, period. Presumably the "box" camera would output Firewire, CameraLink or Gigabit Ethernet, which a separate system would them capture and stored onto hard drives. This "capture" system could be simpler than before, however; for example, a single hard would presumably be enough to store the compressed data stream. (The viewfinder would be a bit more challenging, since it would have to decompress the stream in real-time.)

Eric: Progressive scan is the sequential reading of the image from top to bottom. Interlaced is doing a frame of the odd, then even lines. All the sensors discussed in this forum are progressive. The only global shutter sensors discussed are the IBIS-5A for 720p.

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.

Marin:
We are shipping GigE cameras *now*. 100MB/sec of continuous video in 8 bit, 12 bit packed and 12 bit normailized formats. We haven't seen the need for direct connectivity to a hard drive since you need the camera control, the preview and other features.

Hm
thats not crazy at all, but there is a lot of money involved I do guess. It is exact the way the big ones are thinking and if it would be easy to do this as DIY, Arri or Dalsa would have done this as they are not stupid at all and Dalsa is nothing else as a Philips child, so FGPA knowhow, the chips, emulators, tools all is with Philips. A nice idea but like with all the boyz in the Audio world nice discussions lot off fun, a year or so and then, nothing.
going Pc components is not so sexy at all, but do get the Data in and out at disk is not all and not as easy as it sounds with an FGPA

Ronald Biese wrote:
thats not crazy at all, but there is a lot of money involved I do guess. It is exact the way the big ones are thinking and if it would be easy to do this as DIY...Well, you know what they say ... if it was easy, everyone would be doing it :-)

What I had thought about is a FPGA camera head outputting to Gigabit Ethernet; this connects to an embedded PC capture body with a single swappable hard drive. The head and capture body could be dockable for a one-piece system. The FPGA would compress the signal to a standard open-source codec such as Dirac (wavelet-based near-lossless).

Of course, this is a pipe dream at the moment, and may never be worth it since the Kinetta camera is already doing similar things.

<<<-- Originally posted by Wayne Morellini : Very good, as long as it is a good alternative to Mpeg2 50Mb/s stream (or was that 36Mb/s) I think this will give everybody some excitment.

From what you said the comrpession for Bayer is ^-4:1 and 3chip 4:4:4 6-10:1, is that right?-->>>

Yes.

<<<--How does your codec compare to the Avid codec used in the Ikegema camera, it is something like 145-220Mb/s. Is it true lossless or just megp2 like with about the same editable quality as your cinform codec (but at much bigger daya rates)?-->>>

The Avid DNxHD codec is a DCT based solution much like MJPEG. It will have higher bit-rate than the CineForm codec for the same quality. I have not had access to that codec for testing.

<<<-- Originally posted by Rob Lohman : Marin: most
3. we need a viewfinder/monitor out (Juan already has this since it is on the host camera), since there is no host camera
aboard DVInfo.net! -->>>

Rob,

Juan has a vga output on his mod.

The pana lcd gives a "so far from truth" picture since he bypasses the pana processing so he (we ?) need to know the picture look like.

huh
What Juan does
and somebody wrote here, have a disk to get the frame out of the camera, drive me totally mad.
network storage device, it's bulky but I do guess there are smaller ones, Steves cam with Gig ethernet out or Camaralink to Gig ethernet, and than something like this

GIG Ethernet storage device http://www.iomega.com/na/products/product_detail.jsp?PRODUCT%3C%3Eprd_id=18275701&FOLDER%3C%3Efolder_id=20982807&ASSORTMENT%3C%3East_id=63191&bmUID=1100189941751

with the rolling shuter for god's sake take the Vance Cam idea, a mechanical shutter like good old S16 and 35mm days.
for the viewfinder maybe another crazy thing pops up
The Steve Altasens wits an Argus taht's poor mans 35mm

voila found the pipe dream!
http://www.broadcom.com/collateral/pb/91125E-PB01-R.pdf

that's a evaluation board has 2 GIG Ethernet a chip with realtime OS and Hyper transport only to tell you that's a very fast I/O and that could take the data out to a disk controler chip I do guss

http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_4699_4741^4752,00.html

imagine a very tiny motherboard there something runs to control the cam one PCI slot such a card in from this card to
a, or an disk array sound not so crazy and no FGPA could take the full bandwith.

<<<-- Originally posted by Rai Orz : Lets thinking on differnt ways.
1. Take the next step. Look inside camera heads. Most CMOS Sensors have digital, par. out, so why not connect the CHIP direct to a FPGA.

2. optical viewfinder?

3. Take your brain free from all PC stuffs. The A/D Unit, inside (or outside the CMOS Sensor) have 10, 12 or more output pins (each pin is one BIT). The output rate is 33-66MHz. FPGAs can handle those data speeds in realtime. Shift or translation to 16Bit words are simple works. Next part is the Harddisk. Not a controller or interface, you can write direct to disk. A HDD needs words, not bytes. There are 16Pin (one pin = one byte) and you can connect it also direct to the FPGA or MC.

4. Also you can split the datas to more than one hdd. (First word to first HDD, second to second...) -->>>



All good points. But you missed mine. I (and others) KNOW this
can be done, that is not the problem. The problem is DOING it.

1. I don't know how to do this, neither do I know of someone here who does (except perhaps Juan [who is busy with is mod])

2. I don't want an optical viewfinder. I want a digital one with B&W option, zebra stripes and histograms, but I guess an optical (although I'm wondering what kind of optical engineering that would take) solution would be okay to start with

3. Are you saying hook an SATA or IDE harddisk DIRECTLY to an FPGA design? I don't think this is going to work without some sort of controller since the harddisk needs all sort of commands being send before it will read/write

4. Yes, that is a software "RAID" solution we have already implemented. I was only saying this also needed to be done in FPGA which is harder to do

I think most of us know what the possabilities are and how such
systems could be designed. We just lack the specifics for much
of the realtime embedded hardware design.


Ronald: "with the rolling shuter for god's sake take the Vance Cam idea, a mechanical shutter like good old S16 and 35mm days"

Yes, that was one of my questions as well. I've asked it multiple
times but never got a clear answer from anyone whether this
will work, will remove the artifacting and how this would be
connected to a camera head (the chip and shutter would be
needed to sync I think). So unless someone has some realworld
info on that....


Flax: hmmm, interesting. Thanks!

Hm
Vance has done this on his PAL cam
do google for Vance Cam

Yes I know. I've read all I can about the VanceCam. However,
what works for him might not work for us. Remember that his
head had an external shutter option. And it still doesn't say
whether it will actually REMOVE the effect (he wasn't using
CMOS technology I think). We need to hear about this from
the guys who make these CMOS chips and camera's. However,
Vance is also a member on this board, so I'll shoot him an e-mail.

Also on your "pipe dream solution". Do you know a price? From
what I've seen thusfar those systems are very expensive
(think $5-10K easily).

Rob L.
Thank you for the warm welcome!

Steve, Thank you for that information-it's important

Originally posted by Rob Lohman:
-----------------------------------------------------------
So unless someone has some good answers FPGA wise for these
kind of "issues" I don't see this happening for now.
-----------------------------------------------------------

This someone could be Juan! I hope! I've never seen an FPGA chip ,so I just assume it's a programable "many pins device"...

...and start dreaming:

1. You get from Juan a little metal(not plastic! :)) box with the following ports: 2xUTP - 1GigE-in(to connect to Steve's camera) ,1GigE-out for camera control (see Rem#), 1xSATA (or PATA) a HDD for Recording images, 1xVGA - Originally posted by Flax Johnson: "Rob,Juan has a vga output on his mod.", 1xPower connector -Battery

Rem#: (a part? of the FPGA should act as GigabitNetWork Switch)

2. You get from Steve a Camera with GigE out

3. You get 2 very very fast HDD's - WD Raptor (10000RPM, 16MB cache ...or similar) when the disk is full a "Camera Reloading" is occurred and the assistent swap the drives and the full one is attached to host computer (near the video village) and then copy files to host- then delete them :) from the Raptor.

Some clarifications:

The "1xVGA" is for a view finder(LCD) and this device (a wireless PC->TV convertor): http://www.grand.com.tw/en/product_form.asp?lwk_series=45&lwk_product=a-090&lwk_page=

To the "1GigE-out" is connected a small WireLess Access Point(BRIDGE) with a 100Mb UTP connector-
this is for camera control from the host computer

Best Regards

Marin

It's always good to dream (mechanical shutter, optical viewfinder etc.)

But at the same some of us need to keep both feet on the ground, and make it work. That's what Rai and Markus apparently achieved, and that's what Obin and the Rob's are working so hard at.

Of course there are many ways to skin this cat (no harm intended...), but with all these ideas about FPGA's and other solutions, there's nobody around here that can actually build a camera that way.

On the other hand, the solution of working with a small PC connected with a cable to the camera seems to be very feasible, although difficult enough. But if the two Robs would get a reliable application that can write lossless RAW 24p1080 sequences to a PC with 2 disks, I'd be willing to put up with the limitations of having a cord connected to the camera. Probably a dual cord: one for the cameralink/ethernet from the camera to the PC (in the video-assist cart), and one back with a VGA signal so the cameraoperator can see what he's doing. I tend to have cables running to the camera anyway, video-assist etc. Not a big deal. And 9 times out of 10, I'll have power on set - so that's not a big deal either.

If this results in a clean 10 - or 12 bit uncompressed HD image, I'd personally be happy as a clam :-)

On another note: an optical viewfinder needs a prism to split the beam of light in two beams. Thus only half the amount of light hits the CMOS. Not good. Same goes for groundglasses etc. A 1-chip bayer image is not ideal, but if we get it to disk without compression, or other image polution it should be more than sufficient.

Just my way of supporting the efforts here - since I'm no good at programming or any other useful skills.

Bar3nd

Bolex did it 80% to 20% 20 to the viewfinder

<<<-- Originally posted by Barend Onneweer : It's always good to dream (mechanical shutter, optical viewfinder etc.)
...
............. but with all these ideas about FPGA's and other solutions, there's nobody around here that can actually build a camera that way.-->>>

Those things i love so... ... Noboy? Will see...

<<<--On another note: an optical viewfinder needs a prism to split the beam of light in two beams. Thus only half the amount of light hits the CMOS.-->>>

Not at all. Think on mirrow-shutters. No light loss.
And you will also need some kind of (external) shutter for the altasens. Thats true.

Dont think i love optical viewfinder over all. No, i only say, its one thing that work.

Last thing for today (no more spam :)) !

This document could be very interesting-there is a chapter inside "ATA Interface Dissection":Since I wanted to interface a hard drive directly to the Internet,
speed and buffer storage were of significant importance.
source: http://www.timothyjordan.com/portfolio/tech/seniorthesis/netapp.pdf

...and is this chip similar to "FPGA"? http://www.st.com/stonline/books/ascii/docs/10350.htm

Best Regards

Marin

<<<-- Originally posted by Ronald Biese : Hm
Vance has done this on his PAL cam
do google for Vance Cam -->>>

Vance has used an LCD shutter with a light loss of ~2+ stops. You can see the diagrams (http://home.teleport.com/~gdi/25pscha.htm) to sync the shutter with camera. It would be nice to drag him back into this forum.

HUGE BREAKTHROUGH TODAY!

we can now capture 8bit 24fps with no dropped frames AND it looks like 10bit 24fps with NO dropped frames on pci 32!

FULL 1080p!!!!!

more to come later!

@Marin: Yes, indeed, its what i said: The pdf show a simple example for "direct to disc" solutions. You need nothings between HDD and CPU. No controller, no extra parts, nothing.
But for HD Camera the MC RCM3200 in this shematics is to slow. It runs only at 44,2MHz. But you are on the way.

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.

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

Impressive.

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.

I found it would drop frames occassionally due to bus saturation.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! ;-)

www.dv3productions.com/pub/frame0140-1280-downsize-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