Rob:
FPGAs are not too expensive if you don't have engineering costs. That is why I keep fishing for someone to hand me a working design. Bayer needs a couple of lines of internal buffering, depending on the algorithm. Many compression algorithms require tables - also in internal RAM. Noise reduction usually requires a big slower external RAM.

I wouldn't worry about the gates. I know of products that use Virtex II Xilinx FPGAs that sell for $500 in volume. That is a gob of gates. And yes, 'gob' is my WAG.

Obin:
The Altasens does interlaced out of the box. All of our other cameras are progressive only, as far as I know. That data rate was at 150Mpix/sec. Even in 8 bit mode that is a 64 bit system.

As Steve said, the AltaSens can produce interlaced if you want it, though since you can produce 1080i60 out of 1080p30 or 1080p24, I'm not sure why you'd want to.So you're saying that a currently available FPGA should have enough gates for such an implementation? But that you might need external RAM to implement some things? Give me six months and I may be really interested in this.

Not so Polific Steve ;), there getting smaller and smaller all the time as things work out (except for the vacume energy stuff).

Yes that is what worries me about FPGA compared to Memory Stick PIM's, Clearspeed, and DSP. Some of that DSP stuff is cheap, but I think the reason that there are custom compression chips (probably hardwired DSP's) is that normal DSP might have a struggle.

My markup example was on the highend of the ratio of cost to retail, that manufactures desire (10:1) to have enough profit to share around the distrbution chain. Apparently at less than 5:1 they stop talking to you.

Vissually lossless is good (20-50:1 better for non cinematic work), but that stream of codec options again, for any cinematic blow up I would like lossless to play up with very detailed upscaling. Also I think you are much more likely to do lossless than 6:1 on a low powered PC, but each to their own method.

I understood that Altsens chip is a lot cheaper than $700, pretty dissapionting, that explains why nobody wants to do a 3 chip version. I suspect that next year single chip 8MP will be a lot cheaper, call it a feeling of the SLRD market.


<<<-- Originally posted by Rob Scott : For a lossy-but-visually-lossless codec -- as I hope Dirac would be -- it seems like it wouldn't really matter what exact bit depth you started with. Even if the current Dirac is 8-bit, we should be able to create a 16-bit version; then you store everything as 16-bit, whether you start with 10, 12, 14, or 16 bits. Does that make sense?
-->>>
Pack, Pack Pack ;)


Thanks

Wayne.

Sure, I understand the need to pack. But I am just wondering aloud whether it makes any sense if you're going to compress it losslessly anyway?

<<<-- Originally posted by Obin Olson : Steve I jsut spoke with a broadcaster and they will NOT take any 720p stuff... -->>>

Not good, over here, locally, they only want 3 chip. Have you showed them processed footage, are they likely to change there mind next year?

Maybe they want want more temporal information and less blur, pitty.

OK, I think we were both thinking about different things.

why 1080i60? because they want the fluid motion of 60fps but the format they use is interlaced..SO they need 1080i

our 32bit grabvber board will not wrork for that will it?

OK, I guess my question was, why do they want the fluid motion of 60 fps?

And no, the 32-bit/33 MHz board will not work for that. At least 64-bit, possibly 64bit/66MHz.

Shoot, the 32-bit board I have doesn't even seem to be able to handle the 60 fps on the SI1300. I get a PCI buffer overflow when I crank up the pixel clock over about 55 MHz. Steve, does that sound right? What clock rate should I be able to get?

Rob:
That would be in 10/12 bit mode. PCI-32 is rated at a max transfer rate of 132MB/sec. Sustained is between 80-110MB/sec (windows likes to mumble to itself using bus bandwidth). The frame grabber output is unpacked so in 10 bit mode is two bytes, 55MHz is 110MB/sec peak.

FIFO overflow means that the PCI bus FIFO on the frame grabber lost data because the bus fell too far behind the camera output.

OK, that makes sense -- I didn't realize it was sending unpacked. So if I really want 48-60 fps with this camera, it sounds like I may need the 64-bit grabber. 24-30 is fine for now, but I was hoping to be able to capture 48 fps and skip every other frame to get the 24-fps @ 1/48 sec "cinema" shutter effect.

What I'm hoping to do is to translate the pixel clock frequencies, blanking, etc. and provide a simple frame rate/shutter speed interface which will be more understandable to the typical user. I'm still reading and trying stuff to understand all those relationships. I won't bother you any more about it until I've done more homework :-)

why can't we get 1080 60i? I thought that interlaced was 1/2 the datarate of progressive? it should be the same datarate as 30fps progressive right?

Steve tell me about the 1080P chip and what it outputs?

so in 8bit mode it will output the full on 60mhz without FIFO overflow?

Yeah it should, since going to 8 bits would halve the data rate.I don't think the SI1300 supports interlaced. To get 60i we'd have to put it in 8-bit mode, 60 fps and then toss every other line to fabricate interlaced in software.

work-for-hire needs 1080i as that is a standard that alot of the national networks use...lots will accept conversions from 720p and some even 480p...but we NEED 1080i even if it's 8bit..

I think I misinterpreted your question. The AltaSens can do interlaced up to 120 fps (possibly 240fps @ 720i), but the SI1300 can't, unless you simulate it in software.

1080i will certainly be a goal of the project down the line. (Though honestly it's not a personal goal :-)
OK, now I've confused myself again. If I multiple it out: 1280 x 720 x 2 bytes x 48 fps = 105 MB/sec, it looks like I should be able to get this data rate.

Plus the Silicon Imaging specs on the camera indicate that a pixel clock rate of 55 MHz should allow 49 fps. Is this at 8 bits or 10 bits?