4:4:4 10bit single CMOS HD project

[Laurence Maher]

I've got a severely older copy of Speed Razor (from about 6 years back), and I gotta tell ya . . . man, nothing but problems. Of course, things have come a long way in that time, but I got one word of advice . . . MAC

[Jason Rodriguez]

Obin,

Here's a great 10-bit 4:4:4 editing system that you can use:

Dual 2.0Ghz G5 (or go for the higher-end 2.5Ghz, but dual 2's will do you fine if you're trying to save money). Also pack it with at least 2GB of RAM.

Atto UL4D - SCSI U320 dual-channel card

Huge MediaVault U320-RX, their dual-channel MediaVault hard-drive, which can easily keep up with the data rate of 10-bit 4:4:4 RGB

Then download the Decklink HD Pro driver, and just install the 10-bit RGB codec. You'll have to convert all your file sequences over to the 10-bit codec, but once you do that, you'll have real-time 10-bit RGB 4:4:4 editing within FCP no problem.

BTW, you'll also probably going to need the Decklink HD Pro to output your stuff back to tape, so you might want to include that in the price too, but it's a fairly cheap card, at $2495.

For monitoring your signal, get the HD-Link from Blackmagic. You can hook it up to a second 23" Cinema Display for 4:4:4 HD-SDI ouput on that LCD as a second monitor. Saw them at NAB, and they look absolutely fabulous. And they cost a whole lot less than a Sony 24P HD Monitor!

For color-correction I suggest nothing less than Synthetic Aperture's Color Finesse. Go check it out at www.synthetic-ap.com. This app is amazing, and it works in a 32-bit-per-channel color space for impeckable quality. It's also very fast for what it does. Not RT, but you want this app, especially version 2.0.

So:

Mac G5 - $3000 + RAM = $3300
FCP - $1000
Decklink HD Pro - $2495
Huge MediaVault U320-RX 1.2TB - $6789
Atto UL4D - $450
2x 23" Cinema Displays - $4000
HDLink - $1295
Color Finesse - $575

Total Cost: $19,904

Expensive, but not bad considering you're going to be editing in Real Time (not RT effects though) 10-bit 4:4:4 RGB which runs around 215MB/s. If you take off the monitoring stuff, you'll save $3295, but you'll proababy want a monitor, and a NTSC display is not going to cut it!

The only other system I know that does this reliably is Discreet Smoke and Fire, but I don't think you can afford a quad-proc SGI Tezro and Smoke 6.0.

[Obin Olson]

that is all fine and dandy Jason BUT I want the stuff compressed so that we can cut out the Media Vault..I can compress with a 10bit codec down around 15-20megs a sec...BUT what codec supports that and what editor can do it/? can FCP work wiht SHEERVIDEO 10bit yet? or?

I don't care at all about true 4:4:4 because it's not needed when you have a great codec that is 2:1 or 3:1 compression .. with NO artifacts @ 10bit

[Ben Syverson]

Why not create our own codec? I haven't been able to get to it, but I'm looking at making a simple lossless QuickTime Component that would deal with bayer images... Should be able to get down at least to 18 or 20 MB/sec at 10bit 4:4:4, 100% lossless. Possibly as low as 15MB/sec...

720p 24fps bayer images are only 26MB/sec anyway... not sure why you'd need such serious gear for under 30MB/sec.... Even if we don't develop our own codec, you'd still be able to edit in black&white. Not the worst thing in the world...

We could even give a lossy option for less fussy people (after all, visual effects firms routinely pass around frames as JPEG files, and they aren't always 100% quality). Like a JPEG-style thing but in 10-bit...

I should add that converting bayer-originated images to 4:2:2 is pretty close to lossless, since red and blue are sampled every other pixel. However, keep in mind that green also affects chroma, so 4:2:2 will make your colored edges slightly blockier...

[Jason Rodriguez]

For what you're trying to do the Media Vault isn't that expensive. I don't see why you'd want to cut it out.

Monitoring HD is going to cost you a whole bundle too. And if you edit with Sheer Video or your own compressed codecs, you're going to have no way to edit back to tape. For that you're going to need a card, and those cards use specific uncompressed codecs that your hard-drives aren't going to handle without dropping frames.

How are you planning to get your HD-shot material out to the mass-market/broadcasters or deliverable to clients who want to edit it on their own/have backups on the shelf? Why edit in HD if you not going to an HD-tape of some format?

And again, if you're going back to tape, you're either have to use the DVCProHD codecs and a AJ-1200A Tape Deck ($25,000) if you don't want the Media Vault, or you'll have to get a Decklink HD Pro card and rent yourself HDCAM, D-5, DVCProHD, or HDCAM-SR decks, and with that you will need the MediaVault.

[Obin Olson]

Ben your idea is awesome: Jpeg type codec with 10bit! I don't care about jpeg as long as we keep it at 10bit for color work! the bit depth is the most important thing IMHO...and the most lacking from the NLE people

Well for us Jason all we need is the highquality codec...everything we master is SD so if we can work in HD and do effects in HD and color work in HD then the last step is SD..I don't want or need all that gear..not yet anyway

[Jason Rodriguez]

If you're doing everything to SD, then you might want to try out the PhotoJPEG codec from Apple or the DVCProHD codecs from Apple/Panasonic.

FCP should be able to edit with Sheer Video, unless of course Sheer doesn't really support HD frame-sizes in FCP (which I think was our problem).

I don't know of any 10-bit JPEG codecs our there except for something based of JPEG2000.

At 720P sizes you could also probably make your own HD array with 4 SATA drives-that might be enough.

the bit depth is the most important thing IMHO...and the most lacking from the NLE people

The reason it's the most lacking is because almost every tape format is 8-bit except for D-5, HDCAM-SR, D-6 Voodoo and Digibeta. Everything else is 8-bit.

[Juan M. M. Fiebelkorn]

Well, that is what I was saying the last time I talked about JPEG2000 (open source projects JASPER, Libj2K, etc) and most of the people here condemned me.
Jpeg2000 supports all the way up to 16 bit depth.
Ben, wasn't you the guy that always talks against compression??
It looks to me things are changing very fast here, hehehe :)


BTW, if anybody is interested about this, the nearest colorspace for a Bayer pattern is YUV 4:2:0

[Ben Syverson]

Juan, I just think there should be a 100% lossless pathway for people who want to maintain everything. However, realistically, this isn't necessary for most people. So something like JPEG at a high quality in 10bit is enough.

I agree with Obin -- I don't want a bunch of high-end gear that depreciates hundreds of dollars every minute. I have absolutely no idea how I'll be producing an HD master in the future, but I'm not concerned. For now, no one I know (including me) has an HD display (besides a computer monitor), so what's the point of producing an HD final product? I'm interested in finishing on SD DVDs. When HD DVDs are available, that will be my output option of choice.

The point is flexibility. With uncompressed 10bit 720p, you have tons of options. But I won't be outputting to HD tape until there's a good, inexpensive option (better than HDV anyway), or someone with lots of money wants to see my movie on the big screen. :)

- ben

[Les Dit]

I think I've mentioned before I've used Jpeg 12 bit for years for feature work. It's close enough to lossless. Not gunna be real time. See the jpeg public domain code, it's free for you to compile however you want.
-Les

[Jason Rodriguez]

How hard would it be to adapt DCRAW?

Juan and I were talking, and this seems like the best conversion out there that already has the source-code available.

you can find the source code here: http://www.cybercom.net/~dcoffin/dcraw/dcraw.c

I was testing this out on some images, and they look really good.

I've also emailed David to see if he won't implement converting TIFF files that are greyscale bayer to color files. He might, and he might not, so we'll see.

[Jason Keenan]

Ok, here I go again putting forward info I know little about.

Just found a multimedia library, unfortunately only for windows, which seems to include bayer conversion. It's here http://www.gromada.com/mcl.html

I'm not sure if this will work in this case though.

(ok, I just downloaded their app and it doesn't convert automatically. That's not to say that the library couldn't be made to do it)

I was also mucking around at home and had a look at the raw_cap.bin file in a hex editor and the same file converted to an uncompressed tiff. It's just a matter of cutting the header and end section from the tiff and applying them to the bin file. I was going to put together a very basic windows assembly tool but I'm a bit rusty. (don't get excited, my 'programming' skills come from cracking in my younger years. Anything more than a hack job is beyond me)

Obviously, this is just the bayer greyscale image. I'm still trying to get my head around bayer but I found a site that explains it a bit. Here, tis http://www.siliconimaging.com/RGB%20Bayer.htm with some formulas. This one is better with matlab scripts http://www-ise.stanford.edu/~tingchen/main.htm

In windows you can put the following in a .bat file

COPY /B header.bin /B + raw_cap.bin /B + tail.bin /B file.tif

header.bin - being a binary file containing the start of the tiff
raw_cap.bin - being the still capture
tail.bin - being the tail bit from the tiff

You will of course need to generate your header and tail bins.

Do this by getting your image file, open it in photoshop, save it as an uncompressed tif.

Open the raw image and your tif in a hex editor. Search for the first 5 or so bytes from the raw image in the tiff file. Delete from there on then save the result as header.bin, open the tiff again and search fro the last 5 or so bytes from the raw file and delete all ahead of it. Save as tail.bin

In theory, this should make your raw bayer file into a bayer tiff.

You can do a similar thing in a Unix script so OSX users can do it too.

I can post the binary files somewhere if you like, but until then you can give it a bash yourself.

Raavin :)

[Jason Rodriguez]

Hey Guys,

I'm not sure if this is a problem or not,

But as of right now, if you're trying to convert (especially from the Altasens) the RAW images to a color 16-bitt TIFF, etc., even if it takes 1 second per frame (which is pretty quick), it's going to take 24 hours to process 1 hour of shot footage!

Another thing to consider is that you can't edit with TIFF sequences, so you'll have to render some offline format, and again, that's going to take at least 1 second per frame to shrink the HD down to SD resolutions for editing (or to encode to Sheer, etc.), meaning again, at least another full 24 hours for 1 hour of shot footage.

2 seconds per frame would take 48 hours, etc.

I'm trying to think if that will be a problem, namely a minimum of 48 hours on some of today's fastest gear (I have a dual 2Ghz G5, so it's no slouch) to get your frames output, unless you invest in a render farm. Also that render farm is going to need some very fat networking pipes, because simply hooking up ethernet (if it's not Jumbo Frames on gigabit, and those switches cost $5,000) through a cheap hub, the amount of information you'll be passing around will eat up processor cycles and ruin the effectiveness of the render farm. That's why I mentioned a good switch with jumbo frames, which again can easily cost $5K or more.

Anyways, I'm just wondering how this would apply to shooting a film. I guess you would develop as-you-go? Also be ware that the uncompressed footage converted to RGB will take up around 1.2TB at 12-bit-per-channel for the 1920 Altasens and 1 hour of shot footage. Compressed RAW greyscale should be about a third that amount, actually it'll be 432GB for an hour of RAW bayer footage from the Altasens at 24fps (considering it'll be 72MB/s).

Not a no-show, but I guess bayer image processing and offline processing time-frames are going to be some things that need to be considered for a film production workflow.

[Ben Syverson]

You could process footage way, way, way faster than 1fps on reasonably decent hardware. Even if you're doing pretty sophisticated de-Bayering. Especially if the code is optimized (possibly with vectorization/SIMD).

Totally unoptimized, it would probably run at about 2-3fps. Vectorized, your main bottleneck becomes the drive speed. I'm sure you could get between 10 and 15fps.

[Jason Rodriguez]

With LinBayer I'm only getting around 1.2fps on my dual 2Ghz G5