Data Rates
 

Obin,
What you are banging into is peak vs average data rates. Average is fine for calculating storage. Unless every step of the way (camera to FG, FG to memory, memory to disk controller) has its own FIFO, you have to look at peak data rates with bus loading.

The whole point of using higher clock rates is to read out the frame as fast as possible. That means that the entire frame will be transferred from the camera to the memory buffer at 80MHz clocking if that is what you selected. If there is no packing (and ther is none on Epix), then you will move two bytes per pixel or 160MB/sec during readout - exceeding the PCI-32 limit (132MB/sec theoretical, 100-120MB/sec realistic).

I think your options are:
- Go to the 64 bit FG when Epix has it available - should be almost no software changes
- Go to a fancier (much more expensive) 32 bit FG with on-board storage to stream the video frame to memory at 24th sec
- Go to GigE to use the data packing (3:2)

This is why the Altasens is being released with the 64 bit interface as the main interface. The SI-1300/3300 are low cost cameras - 64 bit is an option but not standard. It is only an issue for >8 bits and overclocking for RS artifact removal.

A simple question what is your time frame to have the camera hit the market?

I know you need to make tests but in small simple statement what do you want the camera to do?

And what will it have, interchangeable lens, etc.

Gary are you asking me about my project or Steve N?

So your Saying Steve that 60mhz is the MAX I am going to get on the PC? with 32bit? what if I capture 8bit images what mhz could I run?

Are you looking at this with 1080x1920? or the full 3megapixel size?

I haven't read through all the posts. I wasn't sure if they're two groups or not.

So tell me simply what are you trying to do. I think at the beginning you were taking apart a 16mm Russian camera and turning into a HD camera.

Also is there a web site or is that too soon?

Can I just import the footage into for example FCPHD?

Gee, it'd also be nice to record variable frame rates. So we can get a slow-mo in the camera and then still play with it in post.

I think waht we're all looking for is a low cost camera that will put out outstanding images to give us outstanding production values. I've seen footage from the posts here and other places that their is talent out there. We just need a great camera to match that.

And if Steve wants to do a short bit about his that's fine also. Thanks.

BTW Juan, there's going to be some non-linearity in the darks, these sensors are still analog devices, so while they may expose linearly for most of the image range, there's still going to be a portion in the darkest regions that will not expose linearly. I think a lot of that has to depend on noise and where you set the internal black point on the chip, but I'm not too sure about that.

Also Obin is "over-exposing" his images, but here's the thing: If you try to go for "nice" looking images, you're only going to get around 2-2 1/3 stops of over-exposure. You can set as much over-exposure as you want, but if you want that 5 stops over that film gives you, you're going to have to underexpose quite a bit to simulate the overexposure headroom that film gives you. For instance, on the Altasens, to get 5-6 stops over, we were having to underexpose the chip so that the white patch on the Macbeth chart was at 10IRE instead of 90IRE! That's a long way down, and the image must be normalized after that. Also the dark linear image look depends on which way the bits are packed. It won't look so dark if the bits are packed at the bottom intead of the top (or the other way, I forget which way is which).

Anyways, real-life tends to have many areas over 2-2 1/3rd's of a stop over 18% grey, so if you expose the chip in that manner, you going to get some clipping.

Hey Jason, it´s been a long time..... :)
So you´re saying that the outdoors image is right?
Or the opposite?

<<<-- Originally posted by Obin Olson : what would the datarate be from the 3300 @:

1920x1080
24fps
85mhz?
12bit/10bit -->>>

Your programmer should have no problem calculating that, but here goes:

1920 x 1080 @24 fps 10 bit:
datarate unpacked from camera: 94.92 MB/s
full RGB datarate: 284.77 MB/s
packed datarate: 59.33 MB/s

1920 x 1080 @24 fps 12 bit:
datarate unpacked form camera: 94.92 MB/s (remember, it's 16 bit!)
full RGB datarate: 284.77 MB/s
packed datarate: 71.19 MB/s

Keep in mind that the 3300 can't do 1920 x 1080 without reducing
the field of view. So it would be better to capture at the full
horizontal resolution with the approriate 16:9 vertical resolution
and scale that back in realtime to 1920 x 1080. Which I'm hoping
we'll implement in Obscuracam one day.

Gary, Steve Nordhauser is with Silicon Imaging, the company that makes the "box" cameras that we are working with.

Obin is using the SI-1300 and SI-3300 box cameras to build a complete PC-based camera system, the "head" of which is in a Russian-built K-60 16mm film camera. Obin has hired a developer to write the "firmware" for the camera.

There is a second group (myself and Rob Lohman) independently working on "firmware" and an offline "Convert" app which will be released under the GPL. My hope is for both camera efforts to contribute to this project.

Rob L:
I'm not quite sure what this means: "Keep in mind that the 3300 can't do 1920 x 1080 without reducing
the field of view. " It is a half inch sensor at 2048x1536 so the 1920x1080 is slightly less than 1/2" where the SI-1300 is 1280x1024 native so a 1280x720 window is a full half inch. Is that what you mean? Or that both the sensors are less than the 2/3" of the IBIS-5 and Altasens?

Rob L on packing:
Your numbers are correct. I'm not sure 10 bit packing is too useful because it is so much more difficult to do than 12 bit. I think that an important point is that full RGB data derived from a Bayer filter doesn't have any new information - it is just a data expansion. To me, this is exactly why we shouldn't use RGB for storage unless it is a precursor to compression.

Really? It's a little tricky, sure, but I didn't think it was that bad. And I can see someone finding it useful to do a 12-bit linear to 10-bit log lookup to reduce disk bandwidth during capture. (Or, naturally, using it with the SI-1300, which is native 10 bits. But then again, I think the AltaSens is going to be the preferred platform.)

Totally agree on RGB expansion. No-one seems to be doing that
and I can testify Rob S. and myself ARE NOT doing this. It's just
there to see what scale raw and packing are on.

I think 10 bit packing is very useful, it offers almost 40% reduction
of the datastream without any futher need to do anything else.
Rob S. and myself didn't have too much trouble implementing
that. I've got a bit shuffling engine running for my compression
anyway.

Regarding compression. The first test to compress a 16-bit still
frame from the SI-1300 @ 1280x720 resulted in a futher 38.72%
datasize reduction using my compression "engine". This is with
plane splitting. Optimizing the compression per plane increased
this to 39.13%. This is on top of the packing which gave me a
total compression ratio of 61.70% and 61.95%.

Regarding the 3300 and FoV. If the full width of the chip is 2048
and you only sample 1920 you will loose a bit of the fiel of view.
Depth of Field will slightly change as well. Or was this the chip
with fractional row skipping or am I mixing up the AltaSens. One
of these had fractional skipping so to not reduce FoV, the other
didn't. And you would have to scale in software to keep the FoV.

System bandwidth
 

Here is some bandwidth information that may clear things up a bit. When dealing with video transfer using a PC, every step of data movement must be understood as part of a system.

Into the PC:
USB 2.0 can transfer data at about 320Mbps (with the wind at its back and the sun shining). Spec is 480Mbps. Remember, all bps are bits and Bps are bytes. You need to know if the data is packed or not. 12 bit data can take 2 bytes unpacked (16 bits) or 1.5 bytes packed (12 bits). (Peak vs average - below- applies here also)

Someone else can suggest real world numbers for firewire.

Gigabit ethernet is 200Mbps with windows drivers, 800Mbps (100MB/sec) with custom drivers.

Camera link is pretty much unlimited.

PC buses:
PCI-32 theoretical is 132MB/sec, realistic is between 100-120MB/sec. There are some PCs with a split PCI bus that can move data independently on each half.

PCI-64/66MHz is 4x the bandwidth of PCI-32/33MHz

PCI-64-133MHz is 8x the bandwidth of PCI-32/33MHz

If you put a 32 bit board in a 64 bit bus, the whole bus slows to 32 bits. Same with clock rates.

Some operations, like moving incoming data to system memory, take bus bandwidth at a peak rate that must be available, others can use an average rate (like moving compressed data to RAID). Some, like display to a monitor might not take any bus bandwidth since the pathway to an AGP slot does not cross the PCI bus. Some of the new chip sets show a two drive serial ATA pathway off the bus (the southbridge is an ICH5R). This might be very important but I haven't seen any benchmarks.

Mass storage:
(someone correct any numbers that they feel are incorrect please)
ATA drive - highly dependent on drive size, RPM, interface but maxes out around 25MB/sec continuous per drive
SATA (serial ATA drive) - around 40MB/sec continuous
UltraSCSI 320 - about 50MB/sec continuous

Drives start putting data on the outer rim where access times are quicker (fixed rotational speed, more data in a circumference) and slow as you go further in. Be sure to watch benchmarks to see if they are really putting data on at least 2/3 of the drive.

CPU speed:
Some operations take no CPU time just bus time, using DMA transfers. Others, like USB 2.0 drivers, take CPU time that must be available. Real time packing, compression and preview display all take CPU time.

Clock rates
 

Steve, a while back you posted a link to a page which would calculate the pixel clock command for a given rate. I cannot find it now -- can you please post again?

Thanks.

the bottom line
 

Obin, do you definatly think it is feasible to shoot a large project with the 3300? (By feasible I mean big screen potential)

What is the deal with this rolling shutter artifact?

Does this make it unuseable?

Is any of the mechanical shutters on the silicon site useful?

After looking at the streampix software information on the silicon website it claims that it can stream to hard drives compressed or uncompressed. How much compression are we talking about here?

Does this still mean that a RAID is necessary or is there a possible external hard drive solution?

Lastly, what is going the most straight forward NLE? If we are staying with PC is Vegas Video 5 practical?

Is there anyway we could use the ethernet option to get the images into Final Cut Pro?

I ask these questions because the arrival of altasens has still not been confirmed. I have heard rumours that cineform may develop a codec for use with adobe premiere pro, but again there is no indication of when this will arrive. Also no news from sumix either.

As I am based in the England (about 100miles from London) any order I make will have to be shipped across the ocean to me. I have a project I wish to shoot within the next two months so knowledge of any further developments is crucial right now. If you can shed any light on these matters at all I would be very grateful.

I will see today how bad the rolling shutter is @ 60mhz 1920x1080 on the 3300

Adrian,

It is hard to tell how long it will take.

I will have a product but I am still in R and D on the whole thing...stay on the board and keep reading

Adrian: personally I would not calculate on using these camera's
on such a short term (2 months). As Obin indicated both teams
are in R&D stages and developing a product. There is no 1.0
release yet. When we reach that there are other things to work
out like casing and how well these systems will work. And we
haven't even touched on things like audio synchronizatione etc.

ROb what one of the 12 are you using from that paper?

This one:

Linear Interpolation with Laplacian second-order correction terms I ??


I am currently working on an implementation of the "Color interpolated image using Laplacian second-order color correction I" algorithm which can be found here. It seemed like a good compromise between CPU load and image quality. -->>>

Yup, that's the one. In that paper, it's also referred to as "Interpolation with color correction I" and "Laplacian color correction I".

Have you tested it yet? can you show me a still from it?

It's not quite working yet. I'll post a sample image as soon as I have one.

that would be cool...Rob we are saving RAW files on the disk..would it be a good idea to send you one so you can test your convert app?

Once I release the Convert app source code, your developer will be able to add support for your file format -- or you can use the IHD format if you prefer.

These are linear sensors (for the most part). That means that ANY exposure is "right". The only limiting factor is noise. If you want a "filmic" image, then you're going to have to underexpose a whole lot to get enough head-room to simulate the highlight compression that film can do (or simulate a logarithmic respose to light instead of linear). Enough head-room compression so that the eye can't see the clip-point, just like with film. It's the same thing as with digital audio trying to sound like Analog-you have to go way under 0db (like 20db for the tone), and allow that top 20db to be used as headroom so there's no digital overload, the same thing to us as "clipping". I'm sure you've heard when somebody doesn't watch the DAT and lets that overload-it doesn't sound good. Same thing with digital imaging. So anything is "right", but that doesn't mean it'll look good. Now if there weren't any bright hot-spots in that image, say in a studio somewhere, then he'd have no problems, no clipping, and we'd probably be saying great things.

But again, our only limiting factor with how far we can underexpose these chips is noise, and that's why it seems the Altasens will be such a great chip, because we can underexpose a WHOLE LOT, hardly much noise, great color saturation, etc.After talking to Steve about this, I'm not really sure that's going to be a problem, because with the camera-link cameras we have very fine control of the frame rate through partial Hz frequencies and vertical blanking. In other words, trying to hit 23.976 or 24fps won't be too hard (and both those frame-rates are VERY important, along with 25fps-for PAL-29.97 and 30fps). Only those frame-rates need to be spot-on with audio sync, the others are for MOS-type stuff only.

ok I have CineLink with full color display 24fps and GAIN, RGB GAIN, SHUTTER SPEED control with the 1300rgb...looking good...now if we could just get the 1300rgb without the smear factor this would be at the point that I could start thinking about a box design and buy all the rest of the stuff we need!

I am stuck right now...seems the smear is bad enough to halt production with that chip and the 3300rgb datarate is so high that I can't even do what I want with it unless I have a 64bit pci card..I can't get a 64bit pci card because I have been working with the 32bit card from Epix and the whole project is wrapped around that brand..Epix does NOT have a 64bit card out that may take 2-3 more months. The only other thing is the Altasense running at 720p untill the 64bit card comes out...as you all know even the Altasense is NOT out yet!...would any of you guys think it wise to go ahead and use the 1300rgb smear and all?

arrgg

Obin,
If you are already going to use the ground glass for DOF, can you use the SI-3300 in 1280x720 windows? It would run at the same speed as the SI-1300 (same clock speed and frame rate) without the smear. Less sensitive, of course, due to the smaller pixel size. Less DOF without the ground glass. The reason the data rate is so high on the 3300 is that you are using it in 1920x1080 mode and that is a lot of data.

Also, Epix swatted their last bug on the 64 bit board last night and will be going out for new boards very soon. I'm expecting 6-8 weeks for production boards.

Software update
 

Check out the development blog -- I got the LCC1 ("Color interpolated image using Laplacian second-order color correction I") algorithm working! I put a sample image up that you can download, plus the same image as a pre-Bayer TIFF.

Re: Software update
 

<<<-- Originally posted by Rob Scott : Check out the development blog -- I got the LCC1 ("Color interpolated image using Laplacian second-order color correction I") algorithm working! I put a sample image up that you can download, plus the same image as a pre-Bayer TIFF. -->>>

It looks good, but it's awful green. It seems like you're using the LCC1 as your Bayer filter? Is the green normal when the image has only been Bayered?

Re: Re: Software update
 

Yes, that image is using LCC1. I'm guessing the green cast is normal and it just needs color correction, but I don't know that for sure.

I don't see the image what is the name Rob?

also Steve:

Steve I would be very happy to do that with the ground glass BUT..this chip is so much less sensitive then the 1300 I am really not sure we would get anything that could be used professionaly from it..if it was the same as the 1300 it would work...argg ;)

not bad Rob not bad...

What camera are you using?

I think I have made my mind up.

I am going to use the 1300chip for now and make a working prototype camera with case LCD screens software etc as a proof-of-concept and use it as much as I can to work all the real-world bugs out for production work...maybe even shoot a short film with it..by this time the Altasense will be out and I can buy that camera/chip and upgrade from 32bit pci ->64bit pci-x. I will buy the micro board now that has 64bit so that it is ready when the new chip and 64bit grabber are out..does anyone see any problems with this plan?

This will give me :

A: a working camera less the smear factor
B: keep things moving along even though it is not the final hardware so that I will be ready when the stuff is on the market from Silicon Imaging

You are on the right direction!!!!
The pentium M motherboard you mean?

Obin, sounds like a good plan. It will also solve a big question for the group - is the 1300 smear managable in a real shoot? The only value in the 1300/3300 is in cost. Certainly people who can afford to move to the Altasens when it is out should do so. You will be doing the people who need to build a <$5K system a big service.

When I have real ship dates on the SI-1920HD and 64 bit Epix FG, I'll let everyone know.

I'm using the SI-1300.

what is that hefty pricetag on the Altasense Steve?

<<<-- Originally posted by Steve Nordhauser : Obin, sounds like a good plan. It will also solve a big question for the group - is the 1300 smear managable in a real shoot? The only value in the 1300/3300 is in cost. Certainly people who can afford to move to the Altasens when it is out should do so. You will be doing the people who need to build a <$5K system a big service. -->>>

This is what a lot of people on the board are looking for. As nice as working with an Altasens, a lot of people watching this thread are prosumer camera users (like me) who are looking for a way to increase production value without increasing our costs. For people like that, a sub $10,000 just isn't a practical reality. A sub $5,000 camera is just about doable, with a lot of scrimping and saving. If the smear problems turn out to be managable, that's something a lot of us will be willing to deal with.

BTW, Just for pricing info,

I'm blocking out $12,000 for a proposal I'm putting together to build a camera around the Altasens-based SI-1920/EPIX 64-bit card and a custom-built enclosure that should be somewhat ergonomic.

As of right now though, there's a very real possiblity that I'll be directing a project in October, which will require quite a bit of pre-production this next month-and-a-half, so I won't be building anything till this shoot is over-which seems good, because it seems as though the parts won't be available till then either!

Steve: in response to your question regarding my field of view
note on the 3300 I wrote the following which I think you missed:You wrote earlier in the thread:So I assume my point from above is valid in that the 3300
can't do the fractional skipping but the AltaSens can?