4:4:4 10bit single CMOS HD project

[Steve Nordhauser]

Obin on clock rates:
The direct answer to your question is that we only qualify the cameras to 60MHz clock but I just tested mine at 80 and 85MHz and it was happy. I got 32 and 34fps. To do this in the XCAP GUI, you need to send strings with the serial peek and poke. These are the same strings as the SDK will use.
80MHz is lc346882
85MHz is lc31c00f

Now for the indirect answer - you will need to go to a 64 bit grabber and bus or get a grabber with a big buffer (full frame of storage) or dynamic byte packing. The Epix, and many others do not pack data. Any bit depth above 8 bits uses two bytes per pixel. 60MHz is 120MB/sec - right at the max of the PCI-32 bus.

[Obin Olson]

that means we are stuck at 60mhz with the rolling shutter stuff at 1080p?? I have spent enough time and money at trying to get the epix working I cannot switch cards now unless the epix 64bit is out soon( I talked with Epix and they are saying about 2 months!)

Steve I don't care about 35fps on the 3300 all I want is the high mhz to correct for the rolling shutter..can this be done?

why does the pci buss have to deal with 35fps at 80mhz? can't we use the blanking to cut that down to a datarate of 24fps 12bit @ 80-85mhz?

[Joshua Starnes]

<<<-- Originally posted by Rob Scott : Yup, it's at ObscuraCam.
I know you were asking Obin, but I've used it too ... and I'm not overly impressed. It seems to work OK, but it's cryptic and complicated. Not easy to use. It does work in Windows and Linux (haven't tried Linux yet). -->>>

Speaking of ObscuraCam, it hasn't been updated in a while. Have you been busy with other stuff Rob? If not, can you give us a short run down on how the convert app is going?

[Obin Olson]

what would the datarate be from the 3300 @:

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

[Rob Scott]

Joshua Starnes wrote:
Have you been busy with other stuff Rob? If not, can you give us a short run down on how the convert app is going?

I have been distracted for the past few weeks, yes. Work, family, Olympics ... the usual :-)

I am continuing to make progress, however. The Convert software (which will soon be released under the GPL) is operational, though it only has a Nearest Neighbor Bayer filter at the moment. Here's a sample frame from the system:

TIFF, 16-bit (5.4 MB)
JPEG, 8-bit (133 KB)

This is a picture of my dog (who is appropriately named Pixel). I'm sure it is badly focused and exposed. It has only been Bayer filtered (Nearest Neighbor -- you'll see definite zippering along the edges of objects) and has not been processed in any other way.

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.

[Steve Nordhauser]

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.

[Gary McClurg]

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.

[Obin Olson]

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?

[Gary McClurg]

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.

[Jason Rodriguez]

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.

[Juan M. M. Fiebelkorn]

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

[Rob Lohman]

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

[Rob Scott]

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

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.

[Steve Nordhauser]

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.

[Rob Scott]

Steve Nordhauser wrote:
I'm not sure 10 bit packing is too useful because it is so much more difficult to do than 12 bit.

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