Home Made HD Cinema Cameras - Technical Discussion

[Wayne Morellini]

At last an professional. Take, thanks for turning up and doing this, if you know of other people that might like to do an open camera capture format feel free top invite them. The only professionals we have had here have done commercial products we can't afford (SI and Cineform).

To answer your question on preprocessing, what about both. Some people will want to leave it to last, some will want noise processed out for optimal compression first, others will want it all left to last. I think that, for optimal quality at optimal compression, that pre-processing out the noise is best. For those that want to do it cheaper, pre-processing the colors on the shoot might be desirable (documentary). Cineform allows the colors to be nominated separately from the data (they have lookup table I think) which is an strategy that could also work rather than pre-processing them. AS you are, assumably, using the latest OpenGL GPU acceleration, you should have significant reserves of power to do this, particularly if Apple supports next generation chips in up and coming products.

I would like to point you to an few people that you might like to communicate with: Rob Scott, who is back here developing his own capture program, Keith Wakeham, that has been developing an HDSDI film recorder (with an Bayer mode in mind) and the Elphel 333 camera thread, where we have been discussing a number of bayer compression techniques, including FPGA compression.

http://www.dvinfo.net/conf/showthread.php?t=63677

An interesting side note, Intel has an Direct X 10 part for Ultra Mobile PC's, and some rumor that Apple has an ultra-mobile PC concept. The Intel stuff is coming from Power VR technology.

Wayne.

[Wayne Morellini]

If you look at machinevision.org (I think) they would probably be able to refer you to GIG-E protocol, or people like Silicon Imaging.

[Steve Nordhauser]

Hey, Steve from Silicon Imaging here. Still keeping an eye on this forum since there is some guts and gore development being talked about.

Take, some thoughts for you. First, watch the rolling shutter artifacts if you run the camera at 24fps. Second, consider your edit workflow. A quick look at the Cineform RAW workflow will show you what I mean.

And lastly, your camera will only be as good as the sensor. On this forum, SI started with Micron sensors which at the time were better than the Cypress/FF IBIS parts. We have moved to Altasens now and there is no going back. The latitude goes from 7-8 stops on the Micron to 11+ on the latest Altasens. True 12 bit capture, low noise. If your goal is a basic camera at a basic cost, a cheap firewire camera can get you going for an amazing price. If you are going to shoot your first feature, do you want to be limited in quality by the capture?

Right now we have set the entry level at $12500 for a Mini with recording software. The edit suite is $2400 with Prospect 2K, Premiere and OnSet. You can use low cost c mount lenses. We are discussing the cash poor indie market - maybe we can announce something at NAB. We will see.....

Sorry, that got sales pitchy - I'm just excited about what we are doing. Last suggestion - don't try to make your software be everything to everyone at first. Pick a resolution, workflow and interface that is doable and focus on completing that.

Steve

[Take Vos]

Hello everyone,

Thank you all for your comments.

Steve, I can certainly understand your excitement. I seem to want to get in a little bit lower price market than you.

From what I understand the Pike 210 has a progressive CCD chip, it doesn't say anything about a rolling shutter (I thought rolling shutters was only on CMOS).

As for the workflow I think: capture -> openexs(bayer) -> proxy -> editing -> EDL -> openexs(RGB) -> color grading. But I would love to take away the proxy and edit directly in a RGB format, I have to find out how, I have a little bit of experience in writing QuickTime components.

As for CPU time, right now I am reading an 8bit 640 x 480 @ 30 fps greyscale image and displaying it, it takes 1.8 % CPU time.

I am using libdc1394 to capture the image and call glTexSubImage() to update the illumination texturemap. A texturemap in OpenGL can now have any size (not just power of two) and I am using that. I am hoping I can simply send a raw16 bit image to an opengl texturemap without doing any conversion or copying on the CPU.

Next step will be creating a small fragment program to change the picture.

Cheers,
Take

[Steve Nordhauser]

Take,
I checked the Pike data sheet - they don't say what CCD sensor technology so I don't know if you will have issues with shuttering or not - ask them.
I'm glad to see you understand the workflow issues.
If you go to the full sensor size it can be hard to find 1" lenses that don't vignette. Try either a 35mm adapter and SLR lenses (you will get a magnification factor) or these Fujinons:
http://www.fujinoncctv.com/lenses/index5.shtml
Another thing to check is whether, when you go from 8 bit to 12 bit on the data path whether the 12 bit data is packed or sent as 16 bit. Even Firewire 800 will be tight on bandwidth above 8 bit.
Sounds like a great project.
Steve

[Take Vos]

Hello Steve,

They indeed talk about having slight vignetting, my plan is to capture a 2:35.1 image which will me slightly smaller than the full 1920 width. In the same paragraph they say that you can ask for something other than a C-mount (maybe a direct F-mount?).

Firewire can only send padded 16 bit data, so it is not packed 14 bit data. The Pike has a 14 bit AD converter.

They also allow adding multiple images together to lower the noise, but I have not calculated the internal bandwidth if it would allow such a thing at 24 fps. Of course I have no idea if an image that is build up like this is acceptable for a moving image.

Firewire 800 is indeed pretty tight, in isochronus mode you do not even get the full 800 Mbit/sec, more something like 700 Mbit/sec.

The technical manual you can download from their site shows how to do all the calculations, the FAQ of libdc1394 shows the same calculations. I am not sure how fast the camera reacts on mode changes, but it may allow smooth transitions from over to under cranking.

As for the advice to start simple, that is the same thing I did with Boom Recorder, start with the minimum feature set to record audio. The video recorder may be even easier.

Well, I am off to read the OpenGL orange book (GLSL) and implement a simple bayer decoder without interpolation (grey scale -> red only, green only and blue only pixels)

Cheers,
Take

[Solomon Chase]

Hey Take,
Go with c-mount, especially for testing. You can use Nikon F, PL mount, Canon FD lenses and many more with mount adapters. If you special order Pike 210 with f-mount you are stuck with that. You'd also miss out on some cool lenses like the 1-inch F0.85 Fujinon c-mount I have (blazing fast!)

Steve, the AVT Pike 210 uses a kodak KAI-2093 CCD sensor. It has global shutter. It's actually recomended for use in "Video Production".

Nice to see someone new involved here. Looks like you are fairly knowledgable in programming, best of luck in your project.

- Solomon

[Solomon Chase]

Also, I would prefer capturing 8-bit with LUT instead of 14-bit. Mainly because of the sensors usable dynamic range, increased framerates, easier post production and some other considerations. 2.35:1 aspect at 14-bit sounds nice though if it is possible.

- Solomon

[Wayne Morellini]

I think packing would be an special arrangement outside of the standard. Cameras with memory buffering is another way to bring the interface bandwidth requirements down, in this way you can adjust the exposure, readout time without it affecting the data rate.

IBIS will outperform Micron, and also offer many more stops, but only if implemented properly, and not using the internal DAC. But, there are too many Ibis cameras poorly designed or with only some of the refinements.

The two sensor companies I recently mentioned (27 stop latitude, and that high sensitivity through quantum effect) are probably worth looking at (as well as that firewire Foveon X3 one).


Re-edit:
Take, Kodak is an nice sensor company.

[Take Vos]

I've read the documentation, stacking of two images @ 48 Hz to reduce noise is only possible with this sensor with a maximum of 600 lines. A 1920 x 600 image is 1:3.2 aspect ratio, I think that is a little bit too wide.

[John Wyatt]

Take -- welcome. I don't recall a Pike camera being used on here, so this is a useful addition to these efforts towards low cost (but ambitious) HD solutions. When you get going you might like to start your own thread for it. Is it easy to get Firewire 800 into a Windows laptop: I haven't seen it specified -- though I haven't looked lately. Or does the camera use an onboard frame grabber?

All the best,
John.

[Take Vos]

Hello John,

I will be using a MacBook Pro for capture, it has a firewire 800 port. I will use the ExpressCard/34 slot to put in a eSATA card to connect to a nakid harddisk.

The camera only has a small internal buffer to for just a couple of frames.

I will look into creating my own thread abut the camera.

Cheers,
Take

[Solomon Chase]

Originally Posted by Take Vos

Hello John,

I will be using a MacBook Pro for capture, it has a firewire 800 port. I will use the ExpressCard/34 slot to put in a eSATA card to connect to a nakid harddisk.

The camera only has a small internal buffer to for just a couple of frames.

I will look into creating my own thread abut the camera.

Cheers,
Take

Yeah, I would recommend starting a new thread. There are separate threads for most projects on here, like the Sumix camera, Elphel 333 camera, etc.

[Take Vos]

I'll start a new thread for my own camera system.

But one more thing which is more generic. Has anyone experimented with cooling their camera? Most astronomers who buy a camera head for their sky photography try to cool their camera to below freezing point.

A couple of degrees will remove a lot of noise from the CCD sensor. The fan needed for this makes noise which the sound person wouldn't like, but maybe you can disable the fan and peltier during the take and cool the camera in between takes.

http://www.outcastsoft.com/AstroImag...Cooler_MJA.pdf

Cheers,
Take

[Wayne Morellini]

See other digital cinema camera thread, but it went nowhere.