4:4:4 10bit single CMOS HD project

[Obin Olson]

good stuff..today we have found our problem with the SDK and are now on a goo dpath to a capture programm...ill keep you posted...automatic GAIN in teh darks!?!?!?!? that scares me bad

[Juan M. M. Fiebelkorn]

Obin, could you give ame a three frame RAW capture to work on?

[Jason Rodriguez]

automatic GAIN in teh darks!?!?!?!? that scares me bad

Yah, they have to do this because of their trying to cram 10-11 stops on an 8-bit tape. Not only do they add gain to the shadows, but 18% grey is suppose to lye at 24IRE!! So all your images are SUPPOSE to look really underexposed, but then with certain images when you try to restore the contrast range (like you would with any "dark" file like the linear files we're working with), you always end up adding even more gain to the blacks (I've tried my best to isolate the values under 12 IRE and it becomes a really big PITA), and getting some real, real nice large compression macro-blocking. Looks so good ;-)

I would only shoot Panasonic if I didn't have enough money for Sony post production. For off-speed shooting I would try to get an uncompressed recorder for the Panasonic, like maybe the RaveHD, that would solve a lot of the problems of F-REC cause then you're recording a 10-bit uncompressed output from the camera.

[Jason Rodriguez]

BTW Obin,

Are you able to get locked frame-rates with your capture app (this question also applied to Rob too)? At least at 24fps acurately so that there's sound sync?

[Rob Scott]

Jason Rodriguez wrote:
Are you able to get locked frame-rates with your capture app? At least at 24fps acurately so that there's sound sync?

I cannot answer your question directly, because I have not yet used it in any sort of production. I do anticipate being able to get a very accurate frate rate.

Also: update to my development blog.

[Wayne Morellini]

<<<-- Originally posted by Jason Rodriguez : BTW Wayne, those small enclosures you're talking about have big AMD or P4 processors in them, so they are going to be very loud.

Try something with Pentium M, that should be quiet. -->>>

I didn't say I agreed with it, but some people want this sort of thing (but now Pent M is here maybe that will change, but even then the M&M combination of good Pent M may be outweighed by processing hungry Microsoft Windows or C). I can backtrack it, I'm running a fairly low niose system for hometheatre (and I find it a lot easier to work with low niose). I think it is likely to be around the same as mine if a 2.4Ghz Pent M was available, still too loud but tolerable for a transportable case) around 23-26db , and you really need 17db or less for shoulder mount.

Bingo, a tansportable case with in built 720p/1080i capable lcd. I forgot about them, BSI computers was a top maker, but there are others (I think Dolch was one). With a modern LCD it could be very good. They can fit standard MB's and cards, they are around the size of a small desktop (not as small as cube), you would sit a reference monitor for shooting (this is not a portable solution but for those with big rigs). If anybody wants to do lot's of res, and lots of drives (or just flash disks) then you can go better with the YY (Yeong Yang) legendary Cube Case (something like a 43cm square black cube server case). And before anybody says so, thats not most of us.

Looked them up, www.bsicomputer.com, styling looks worse, not 16:9, not stereo speakered ;(. But they do have singleboard computers (aroudn the size of a full length add in card, rugged portables, and panel PC's, if that interests anybody. The tabvlet model looks really nice. Some of the models almost looks like pro video equipment in styling. Ohh yes, an Award from Nasa, that sure blows hopes of it being as cheap as a laptop, at least when you see an astronaut float by with one on TV you can tell your family it might be a BSI model ;):)

You know there is a local tender center (Cairns) that has to compaq SCSI2-Wide raid drive towers (I was offered one for something like $30). Are these things any use for us, and anybody interested near me interested?.

[Jason Rodriguez]

and you really need 17db or less for shoulder mount

Not really true.

The Aaton S-16 XTRProd is rated at 19db, while the A-minima is 29db, and those are both sync-sound cameras, and used for sound shooting all the time.

[Wayne Morellini]

I am not familiar with those products. I know if you can shoot the niose away from the user (which I plan to do) then it shouldn't do too much to the ambient niose level and also be suitable for shoulder mount. As a mounted camera, or box on the floor, there shouldn't be any problems with 19db, even 29db will fade in a niosy environment or open space, but I would like to aim for good natural sound sampling in quiet areas for film and doco's.


Wayne.

[Joonas Kiviharju]

I wrote a little program the other day. It does debayering in the way described by rob, or was it ben?
It is written in C++ and it's probably very slow (this isn't because of C++, but because of bad/fast coding). I don't really know, because my computer is 500MHz.
It works on 8 bit TGA files, so no 16 bit at the moment. Sorry about that-

The interesting bit is that it can open Obins .RAW files, debayer them and save them to .TGA. I'm not quite sure about Obins RAW files, but I used chars to open the data and to my knowledge chars are 8 bit. So maybe I'm missing something here...

Also the program works from the commandline, and it has this totally useless SDL/OPENGL preview, which you can disable ofcourse.

The downside to all this is the fact that, since my computer broke down I haven't had Windows. So I wrote it in Linux, but it should be totally portable and compile fine on any compiler, and a person who knows how to use one. The only external library you need to compile it for Windows is LibSDL <http://www.libsdl.org>

So if someone could get it to compile, you could use it.

When you get it to compile you can use it on a sequence of files named picture0001.raw, picture0002.raw...

When you run it you get some kind of a help, describing the syntax of the commandline instructions.

You can get the GPL:d sourcecode from
<http://pupuedit.sourceforge.net/camera/pihlajadeb.zip>

And remember that GPL means that you can't use the source code in your proprietary programs, but you can use it for anything, as long as you make the result GPL.

The code could be a lot faster, but the debayering looks quite good to me. It doesn't have any softening so it has some jagged pixels (or what do you call them...). But I actually think the result is exactly the same as Ben's method.


Another thing is the mounting of cameras. I found this interesting future thing: <http://www.four-thirds.org/en/index.html>
It could be the future sensor size, and the mounting system of choise in a couple of years.

Joonas Kiviharju

[Steve Nordhauser]

I finally did some testing with the SI-3300. I put some images in this directory:

http://www.siliconimaging.com/Samples/SI3300/

This includes a 10 frame raw sequence at 1920x1080, 12 bit. This was done with Epix so the camera is 10 bit, padded two to the right, 4 to the left with zeros.

Some warnings: I'm not too sure about the number of bits of the images - PaintShop pro seemed confused by them but opened them as 8 bit. The file sizes seem to indicate larger files for the 12 bit files. The color images were colorized by the Epix software - no promises for what Bayer algorithm used. The lens was a Canon zoom. OK but not great. There was no correction done on these at all - no white balance, black offset or gain. I purposely left some hot spots in the image so you could see the lack of smearing.

The Epix software was smart enough to know this camera doesn't come in monochrome so I switched to a different model after setting up the image. This gave me less control (OK, no control). The monochrome images have some trash around the 1920x1080. I also posted a couple of 3.2Mpix images.

Remember all, this is a 1/2" format camera with small (3.2Micron) pixels. It will run at a *max* of 24fps at 1920x1080.

[Rob Scott]

Koonas Kiviharju wrote:
It does debayering in the way described by rob, or was it ben?

That was Ben.

So you're using linear interpolation? If I can get it to work with a REAL (floating point) data type I might try using it in the Convert app (which I am also releasing under the GPL). Interestingly, I was planning to use libSDL for that one too.

Thanks!

--- EDIT ---
By the way, my comment about a real data type wasn't meant to be insulting. I just meant real numbers vs. integer (I can hear it now -- dang it, we use REAL numbers, not those toy "char" things! :-)

[Les Dit]

Steve, I took a quick look at the 3Mpix 16 bit uncorrected, and it looks like it may have less than 8 bits. Does this camera have 2 taps? The reason I ask isi that the histograms for rgb have 2 distinct and seperate shapes to them, like we are looking at 2 pictures interlaced or something!

I like the resolution. Maybe the image can be flattened with software, but leaving how many bits is the question.

-Les



<<<-- Originally posted by Steve Nordhauser :
Some warnings: I'm not too sure about the number of bits of the images - PaintShop pro seemed confused by them but opened them as 8 bit. The file sizes seem to indicate larger files for the 12 bit files. ->>>

[Juan M. M. Fiebelkorn]

I'm with you Les Dit.
I was expecting a dark image like the ones from SLR (just debayered not gamma corrected or anything else)

Steve ,Do you remember the example Jason posted a long time ago of a Digital SLR image?

[Joonas Kiviharju]

<<<-- Originally posted by Rob Scott :

So you're using linear interpolation? If I can get it to work with a REAL (floating point) data type I might try using it in the Convert app.
...
By the way, my comment about a real data type wasn't meant to be insulting. I just meant real numbers vs. integer (I can hear it now -- dang it, we use REAL numbers, not those toy "char" things! :-) -->>>


Yes, I understood you about the real data type. I think it is very easy to just make the internal data floats, and maybe get an external library to write 16 bit TIFFs. I might be doing that myself, if I'll get the time... Later on I plan to put it all in my pre-alpha non-linear editor called Pihlaja. It will propably be using GStreamer, so it will be a plugin for that. But this is propably a couple of years from now (because I don't do it professionally)...

I don't really know about linear interpolation. I'm really not a programming professional so I don't know the terms. (I think I used linear interpolation when I was making a 3d engine that filled polygons.) As hinted in the Bens wiki entry about debayering, I just averaged the 2 nearest neighboring pixels to get the values for RGB for every pixel. First horizontally, then vertically. I'm not sure if there is some kind of a better method than just pure averaging: [i-1] + [i+1] / 2. And I'm not sure if Ben's method in the plugin actually is this simple. So I meant that, my method is the same as in the wiki.

[Rob Lohman]

This includes a 10 frame raw sequence at 1920x1080, 12 bit. This was done with Epix so the camera is 10 bit, padded two to the right, 4 to the left with zeros.

Are you sure of this?

The file is 62.914.560 bytes long. Or 31.457.280 pixels. If you
divide this by 10 (for frames) you get 3.145.728 pixel image. That
is much more than 1920x1080 (which is only 2.073.600 pixels).

The math doesn't add up any way I try it. If you divide the filesize
by 1920 x 1080 x 2 (4.147.200) you get 15.17 frames which is
fractional ?!

Also, I looked in the file with a hex-editor and I find numbers that
have their last bit turned on! The first row is:

A9 00 8B 00 A9 00 95 00 - 9F 00 95 00 A9 00 8B 00

That's:

0x00A9 = 169 (?)
0x008B = 139 (?)
0x0095 = 149 (?)
0x009F = 159 (?)

How can this be two bits shifted to the left? It can't be 0xA900
either because that would mean the high 4 bits are set as well
which can't be either.

So neither the encoding format nor the filesize seem to match up!