Check out the SiliconImaging site. The SI-3170-CL and the SI-3300-CL are different cameras.

SI-3170-CL:

• 2048 x 1536 Resolution
• 1/2” Imaging Format, 3.3um Pixel
• 12 Bits per Pixel (Dual-Tap)
• 100Mpixels/sec Throughput
• 30 FPS Sequence Capture at full resolution

SI-3300-CL:

• 2048 x 1536 Resolution
• 1/2” Imaging Format , 3.2um Square Pixel
• Rolling Shutter, Progressive scan
• 10 Bits per Pixel, 48MHz Sampling
• QXGA(12fps), UXGA(20fps), SXGA(27fps) & XGA(43fps)

Note that the 3300 can get only 12 fps at its full resolution.

So?

There comes my confusion.....

Steve wrote a couple of times 3300, then appears the SI-1920HD and so on..

And I still can't understand why we aren't talking about the SI-3170CL

I accidentaly posted to the wrong thread before:

It should be a lot easier to extend this to 10+ bits in code or FPGA, then design a new one.

I agree with Jaun, with MMX, SSE etc and all maybe Huffy canbe made to work (impresive it gets so far without it).

It is best to keep it in bayer for master accuracy aswell.

Thanks

Wayne.

Perhaps Steve accidentally said 3300, because it really is not suitable at all.

We have talked about the 3170 a lot, and Obin was considering it. The problem is that scaling from 2048 -> 1920 is not a simple pixel "binning" proces, it requires interpolation. Or else you have to "window" it -- losing some pixels, but worse, you have a smaller chip area so your DOF is worse as well.

For HD, the AltaSens (SI-1920) is definitely a better choice.

Oh, thank you Rob, indeed.I was really lost :).

I've been testing the Elphel's camera 313 wich uses the same Micron sensors, and it is very sensitive, really.
If you set an exposure higher than 10 ms, everything gets blown out!!!!.

What would be the problem of using it at 2048x1536?
Anyway we need to apply heavy processing on the images after capture to De-Bayer them, so adding to this a simple crop and a Lanczos resize to 1920 won't be bad.
The other advantage is we could use an anamorphic adapter anytime!!!!! ;)


hahahahaha, sorry.I see the problem now!!
It would give as at least 108 MB per second (suppossing we get only 12 bits and not 16) @24 fps.

Yes, the data rate would certainly be higher. The image quality might be marginally better since you'd be downscaling from a higher resolution after the Bayer filter. But I suspect that the AltaSens chip is going to be better quality overall anyway.

<<<-- Originally posted by Juan M. M. Fiebelkorn : A question to anybody who knows about the topic:

What could happen if I store Luma info with 10-16 bit depth and U and V with 8 bit depth?

What could be the final bit depht when converted back to RGB?? -->>>

This can be a good approach -- I'm considering it myself. Increasing luma bit depth without chroma increase in precision will result in cleaner gradients and better dynamic range in shadows and hightlight where chroma subtly is less import. 8 bit chroma will limit you a small amount for color corrections that involve increasing the saturation.

David,
But when we go from YUV to RGB, U and V planes are merged again with some portion of the higher bit depth Luma, to get the Red and Blue channels again.
So from this very moment, Red and Blue can't be 8 bit depth anymore......My thought..

There is no direct effective bit depth due to this conversion, but you are correct that red and blue will gain additional precision is luma precision is improved. Increasing luma alone does provide more quality increase than increasing chroma alone.

Do we have to go with compression? Can't we compress after the fact so that those who want uncompressed high-bit depth can have it?

If I wanted compression I'd shoot tape! :-)

Jason, you can record on tape without compression.......
Go buy a SDLT600. :)

36 Mbytes/s (72 with its internal 2:1 LOSSLESS compression)

Not trying to be agressive, but you are not the only person in this forum, so if you want it pure big and RAW, there is no problem.
That's the funny thing about this system, if you build it you can have it the way you like!!
But please let others discuss what they want. (Did I overreact :) )

So far, the two projects (Obin's and mine) are talking strictly raw, uncompressed data to disk. Period. Any talk of compression on-the-fly is for the future. (Though possibly near-future.) And I believe there will always be an option to capture raw and process offline.

Yep :-)

Sorry, I'm not really sure if this is a group software thing going on, or little side discussions. Sometimes it has felt from the traffic that group consensus was moving towards a compressed solution, but if we can do whatever we want, then that's good.

How much Jaun, any links? I have been considering the use of backuptape to archive footage (and maybe record it). One of the biggest problems with broadcast tape, is that the broadcast manufacturers control it and price it out of reach.

Thanks.

Wayne.

Wayne, I'm pretty sure an uncompressed tape system is out of your reach. :)

- ben

Google, search for SDLT.
It is a well known standard with support of the biggest computer companies.
Every new generation is backwards compatible and tapes cost around $ 45.

Is tape back-up fast enough to record to?

I think you'll have to use it as offline, and even then, it's only 130GB a tape for AIT-2, and you need SCSI for most DLT's ($$$).

SDLT600. :)

36 Mbytes/s (72 with its internal 2:1 LOSSLESS compression)
300 GB/ 600 GB that's why it is SDLT "600".

Anyway, an ultra 160 card at $400 is ridiculous against its price :) , hahahahaha....

Why? It's only $7,750.95!

It doesn't matter, just another option for people. It is more about saving and reusing a $1000 dollers of Hard disks per major production (we are aiming for 1080 and eventually SHD in the future) many of thousands per year, and it might be very cheap compared to buying a broadcast/digital film tape mechanism. For some professional people and indies, that is going to be a major bonus.

I posted a good Toms hardware review of tape backup on one of the threads, I think that the stats were even more impresive than the one above (I think they were way over 200Mb/s=SHD). I think they might be a lot cheaper than that device to. They are doing a Raid 5 8 drive review at the moment.

On compression/raw, they are only doing what we can do for the moment, pie in the sky, fantasy etc etc compression comes latter.

<<<-- Originally posted by Obin Olson : I guess maybe a cheap shuttle will do for now untill that board is out..>>>

Don't forget the PCI-E one.

i have a question:

..a camera that shoots at a resolution of 2048x1536 would obviously require a great deal of bandwidth and storage... however, if you were going to crop the image in post to a cinemascope format closer to 2048x900, would it be possible to design the software to only capture a window of that size??

Absolutely. These sensors support "windowing," where you can choose the area of the sensor that you are retrieving. Since you are retrieving less data, you reduce the required bandwidth. (Of course, you could also choose to speed up the frame rate.)

have those people who have worked with these cameras noticed a considerable amount of strobbing when panning or tracking?

To everybody.

Another big question came to my mind.
Why Steve Nordhouser and many other people are so concerned about Sensor's seneitivity (I mean the sensors we discuss here)???
From the specs I've seen the sensors we are discussin or using here are far more sensitive than a normal e.g. Sony 3 CCD Broadcasting camera.
What am I missing here?

I need some help I will post a RAW file from our capture software and I need to know if it's full RAW as in 10bits? or is it 8bits? we don't know because we don't know what the SDK is doing it's DOCS suck..
www.cameralink.greatnow.com/raw_file.rar

The first thing I can tell you is that if it is one frame, it has been written as 16 bit.

Juan,

If you have a Mac, open up the file from within GraphicConverter. Set the filter to RAW, and then use these settings:
Grayscale, Unsigned Short, Black is $00, Intel Number Format, and then click "Guess." Voila.

Basically, the file is an array of unsigned shorts (it's 16bit) -- but I think the data is 10bit (padded).

- ben

You can put an 8 bit image into a 16 bit file. Just because photoshop shows it as mode 16 bit is not a guarantee that you have X number of bits. To be absolutely sure, look at the histogram of the image after brightening it ( multiply X 4 ). You should be no missing values.
I hope this isn't too confusing.
-Les

Les, it looks like that's what's happening. I thought the data might be 10-bit, but it seems to be 8-bit data in a 16bit file. Why the programmers/developers would let you double the file size for no gain is strange.

And you have to multiply 8 bit by a lot more than 4 to get a full-range image -- try multiplying by 256. (65536/256 == 256)

I think I made a mistake -- the file seems to be 12bit after all. You can open the file directly in Photoshop by setting the format in the open window to "Photoshop Raw", setting the bitdepth to 16, byte order to IBM PC and w/h to 1280x720. Then if you apply a Levels with the input white set to 16, you should get the whole range. If it were 8 bit, you'd have to set the input white much much lower.

After doing some tests, it looks like we have all 4096 values.

- ben

4096 values out of a 10 bit camera?
Interesting.
-Les

The data is 12 bit. I believe the camera is as well.

- ben

Sorry, not to change the subject (too much),

but I was thinking about Hard-drives needed for the Altasens camera. I'm estimating around 3MB per frame for the 12-bit 1080p HD stuff in RAW Bayer format. Now at 24fps that's around 72MB/s for throughput, and at 60fps, it's going to be a whopping 180MB/s. Even 48fps is going to be a pretty hefty amount of throughput.

So will 2 SATA drives in an RAID 0 have the capabilty of recording this stuff? The Kontron board that we were looking at with PCI-X, I'm not sure how many PCI-X slots it's going to have. We'd need at least two slots, one for the frame-grabber card, and another for something like the RocketRAID 1820a to support all those hard-drives needed for that amount of throughput.

Hmm, this will be interesting.Then how come Steve has said that the Micron has a 10bit A/D? Is this something in the framegrabber that's expanding the bit range to 12-bits?

I have no idea. All I know is that the data in this file goes from 0 - 4096.

hey ben,
when are you getting your camera? i want a review.

Eric, I got the camera yesterday -- I would have been all set up, but my ancient Iomega USB cdrom drive bit the dust. So I had to go out today and get a new drive to install XP with (instead of an optical drive on the recording laptop, I'm putting a second hard drive in the bay).

You can see a photo of the cam here

It's seriously teeny! Check out its tiny C-mount lens here! I'm used to C-mount lenses for 16mm which are about twice as big.

The lens and the camera both are really well put together -- 100% metal construction. The optics in the lens are exemplary -- it looks like a mini Nikkor. :)

Hopefully I'll be able to post some images in an hour or two -- once Windows XP is done vaccinating itself with 7,692 critical security updates ;)

awesome,
did it come with that lens?.. if so, what's the focal length (in 35mm terms)?

No, I bought the lens separately. I'm not sure exactly what it would be in 35mm terms, but it has about a 60 degree HFOV. It's 8mm -- I would put it at maybe a 30 or 35mm in 35mm terms.

So Ben, how does everything look?

If you can post some footage that would be very cool :-)

I bought a cool 8-51mm zoom for mine..nice glass..gota tell you guys today was HELL.....never again will I try and shoot a "real" project with such a beta - no alph level product - if you can even call it a product!! I about lost it today trying to get everything setup for the shoot - after about 2 hours of dicking around I gave up and shot the scene with the dx100....!!! this is in NO WAY SHAPE OR FORM ready for production..NOT EVEN CLOSE AT ALL!!!


BTW this chip SUCKS! I was shooting a scene with lots of windows in the background and the smear from the hot windows was REALLY BAD...I don't think any of you could shoot professional stuff with this chip - I know I will never try again,,,I am sure the Altasense will be great but the Micron is bad

the whole computer on a cable is bad...I can see that I need to really focus on the camera-as-one-unit design and get that made...

O well I guess I learned somthing today atleast!

good news is that the capture software is moving along at a good pace..


anyone want to poke at making a proggy that converts the RAW format I sent you guys into a tiff/jpeg/avi/quicktime/some new codec? that we can edit from? in maybe 10bit? David? Rob?

BTW David does Combustion support your codec in 10bit? what about AfterEffects? how does color work in AfterEffects if your using the 10bit file and AfterEffects is 8bit OR 16bit but not 10??

I will now use this camera as a TEST camera only...when Altasense comes out I hope it's a "real" product ;)

Obin,

The CineForm codec can be used within Combustion, but only as 8bit RGB (limitation of VfW.) AfterEffects is the same today but we are finishing up the IO module for AE to support the 16bit RGB (per channel) mode. This is only a couple of weeks away. I assume that combustion would need a similar IO module -- I haven't got their SDK.