DV Info Net

DV Info Net (https://www.dvinfo.net/forum/)
-   Alternative Imaging Methods (https://www.dvinfo.net/forum/alternative-imaging-methods/)
-   -   New DIY HD Cinema Camera Project (https://www.dvinfo.net/forum/alternative-imaging-methods/96349-new-diy-hd-cinema-camera-project.html)

Wayne Morellini July 13th, 2007 10:12 AM

Quote:

Originally Posted by Steven Mingam (Post 710820)
Well you are not "overclocking" any hardware device, you are just forcing windows to look more often at the USB port if something's happening... By decreasing the time you react to usb activity you gained a bit of fluidity but nothing will burn because of that. The hardware is still running at the same frequency...

[edit] err, in facts that's totally wrong. The usb master is polling the bus every 1ms (1000Hz)(that's why it sux btw ;)) so that's why they overclock their usb mouses : to get the refresh rate of the mouse at something better than 125Hz, but you are not concerned by this kind of hack, you're not using a mouse . I wonder why you gained something by doing so...

If it is polling, then it maybe that synchronisation with the PC is better, and more close to the data issue on the camera. This would result in an little increase in efficiency, and less wastage of bandwidth (in case anybody is wondering what this means, frames are rolled out after shutter and other processes, this means that the data has to come out in an peak, for 180 degree shutter, it will likely double the bandwidth requirement, then 10bit words often take up 16bits, and is not packed fro transmission, you can start kissing 720p goodbye if this is the case as well). Cameras without memory buffer and packing are the problem.

Jose A. Garcia July 13th, 2007 11:17 AM

To be honest, Wayne, I didn't understand a thing of what you just said. I increased the frequency, now it goes faster (it reads more times per second) and my biggest concern was if that process could damage the camera in time, at least faster than normal use.

Also I have bad news. I just received an email from Micron. They say they apologize for the mistake but framerate cannot be fixed. I just can't believe it. That basically means the board can't be used to shoot movies. The only way to decrease framerate if it goes faster than 24fps is by decreasing electronic shutter frequency, and that means a more noticeable rolling shutter.

In a few weeks I'll have here the Omnivision board for testing but I seriously doubt it's better than the Micron.

Juan M. M. Fiebelkorn July 13th, 2007 08:11 PM

I think it would be better for you to start experimenting with an Elphel camera instead of trying any propietary solution out there.
Maybe at first the learning curve may be harder, but seeing how much progress you have obtained up to now I believe it would be the best path.

Jamie Varney July 13th, 2007 10:32 PM

Quote:

Originally Posted by Juan M. M. Fiebelkorn (Post 711818)
I think it would be better for you to start experimenting with an Elphel camera instead of trying any propietary solution out there.
Maybe at first the learning curve may be harder, but seeing how much progress you have obtained up to now I believe it would be the best path.

Sorry Juan but I think that this is kinda a dim view. Jose is showing some serious progress, and If we don't keep experimenting how will we evar know what is going to work best for us?

Jose A. Garcia July 14th, 2007 04:09 AM

Hi Juan,

If you read through the post, you'll see the Elphel has always been one of my options. In fact, the new 353 uses exactly the same 5mp micron sensor I have and you can set the fps you want.

There're 3 points I don't really like about the Elphel:

- First, it's a complete already made product.

- Second, it compresses the image. It does it very well, but even the RAW Jpeg is compressed. You cannot choose to extract a RAW Bayer sequence from it.

- Third, and I know this sounds bad, Linux. I've got Windows and OSX Tiger installed in my computer and, if possible, I don't want to need to boot Linux everytime I want to shoot something. In fact, if I have to choose between both systems, I'd choose OSX, cause I'll end up compositing in Shake and editing in Final Cut.

Now, I decided I want to stay with the demo board if possible. I really like the image, motion and ease of use so,

Take and Steven, if you really want to help this project, what do you need to develop:

- A very simple recording tool that can control gain, resolution, shutter, binning, gamma, contrast, clock, white balance... and VERY important, FPS.

- A converter from RAW bayer to any usable lossless codec.

I'll try to find everything you need. Datasheets, manuals, actual software... I'll record RAW sequences for you. I can test Windows and OSX software here. Anything to get this project done. Just ask.

Jose A. Garcia July 14th, 2007 04:27 AM

Here is the first RAW sequence. 159 frames captured in Micron RAW format. It was debayering in real time when capturing (Laroche-Prescott) so I think it will just need RAW decoding. It also has a txt file with all sensor info and settings during the capture. If you need another one in Bayer format, just ask.

I'm also adding another file with all the PDFs that came with the board. All schematics, manuals, datasheets...

http://www.cus-cus.net/dvinfo/capture.rar

http://www.cus-cus.net/dvinfo/doc.rar (Not active)

It's uploading right now. It'll finish in about 10-15 min.

Jose A. Garcia July 14th, 2007 04:32 AM

Hey! I also found many C++ code samples! They explain how to program simple capture tools and things like that.

I think I'll just compress the whole Micron CD so you can have everything you need.

I'll post a link when it's ready.

Jose A. Garcia July 14th, 2007 05:12 AM

http://www.cus-cus.net/dvinfo/microncd.rar

Here it is.

Ivan Hamer July 14th, 2007 06:49 AM

Quote:

Originally Posted by Take Vos (Post 709087)
Why do you want to do lossless encoding?
A single 7200 rpm SATA harddisk is fast enough to sustain bayer 1920x800@24fps,14bits uncompressed.

Take,

I am not getting how this is possible...
1920 x 800 x (4 x 14 / 8) x 24 = 258048000 Bytes/sec or about 246MB/s.
The "(4 x 14 / 8)" in the calculation is two Green, one Red and one Blue channel per pixel at 14 bits converted to Bytes.
The best sata drives (15K rpm) can sustain about 130MB/s. For regular 7200rpm, about 60-70 is all you can count on.

Ivan

Take Vos July 14th, 2007 07:20 AM

Hello Ivan,

Your calculation is off by 4; on a bayer sensor the green 1, green 2, blue and red, each occupy a separate pixel, with some fancy interpolation algorithm you can reconstruct all the three color components per pixel. Effectively there is a 1:3 compression ratio.

Also, as my own camera has firewire 800 connections my limitations are different. 1800 x 750 x 14bit @ 24fps or 1920 x 800 x 12bit @ 24fps. Actually I could do a little more height in 12 bit or wider with an larger sensor.

Ivan Hamer July 14th, 2007 07:52 AM

Quote:

Originally Posted by Take Vos (Post 711983)
Hello Ivan,

Your calculation is off by 4; on a bayer sensor the green 1, green 2, blue and red, each occupy a separate pixel, with some fancy interpolation algorithm you can reconstruct all the three color components per pixel. Effectively there is a 1:3 compression ratio.

Also, as my own camera has firewire 800 connections my limitations are different. 1800 x 750 x 14bit @ 24fps or 1920 x 800 x 12bit @ 24fps. Actually I could do a little more height in 12 bit or wider with an larger sensor.

Oh, this is good news for me, then. My plan was to put a sensor and an FPGA on a mini PCI board which would go into a Via's nano ITX with RAID support. I figured it would only be possible by doing at least a 2x compression in the FPGA, but now I am thinking that it might be doable with no compression.

Steven Mingam July 14th, 2007 08:13 AM

Quote:

Originally Posted by Jose A. Garcia (Post 711935)
If you need another one in Bayer format, just ask.

Please, i want to test my debayer algorithm ;)
(in fact, the best would be to have the same sequence in bayer and debayered by micron so i can compare... it might be difficult but there is no point to continue to work on my algorithm if it's bad :))

And for the elphel compressing video, well you could by-pass almost everything but the huffman compression in the FPGA and get lossless bayer compressed video. That's why it's a good start : you got the right hardware and the source of the camera, you just need the skills to modify it a bit.

Jose A. Garcia July 14th, 2007 08:24 AM

http://www.cus-cus.net/dvinfo/captureRawBayer.rar

Here it is. RAW and Bayer. Uploading now. May take 10 min or so.

Jose A. Garcia July 14th, 2007 06:08 PM

But Steve, wouldn't it be even better if we develop specific software for the demo board? We already have working hardware and the results look better than I thought. We just need to control fps and develop a simple tool to read and convert raw sequences (and even debayer them using the best possible algorithms) and we've got our camera! I mean, there're few cameras out there that can deliver 2k and the image and motion feeling on this one's just great.

We're almost there!

Jose A. Garcia July 14th, 2007 06:51 PM

Going back to the optical part of the camera, I'd like to know where to buy very sharp c-mount lenses. Don't get me wrong, I like the soft movielike look the camera has now but when the adaptor is added, the image will pass through 3 lenses (c-mount, achromat and 35mm lens) and the ground glass so if final image is a bit soft I want the 35mm lens to be responsible for that. The rest must be as sharp as possible.

I don't care if the c-mount lens I choose is a second hand one as long as it's very sharp. In fact, it will be much cheaper if it's used.

Where can I look for it?


All times are GMT -6. The time now is 05:26 AM.

DV Info Net -- Real Names, Real People, Real Info!
1998-2024 The Digital Video Information Network