4:4:4 12-bit Uncompressed DVX100

Juan P. Pertierra · March 28th, 2004, 12:09 AM

Well, since the firewire interface is fast enough to handle full quality, i will probably include an option to do filtering on the software driver end so if you don't have that fast a drive, you can still record 4:2:2 or 4:1:1 uncompressed. However, for the full 4:4:4 you need a fast drive that can handle sustained 40MB/s. I know if at least one external drive that can do this: the LaCie FW800 external big drives. The new versions are even faster. I have an old version, and in all benchmarks it can do 67MB/s sustained, so it is more than enough.

My laptop drive is also fast enough according to benchmarks, but it is kinda cutting it close, so i'm not sure how other OS operations slow everything down.

Juan

Juan P. Pertierra · March 28th, 2004, 12:29 AM

Oh so close!

All wires hooked up, captured data, now i'm writing a small proggie to unpack the 30 relevant bits(10bit RGB) packed in the 32bit chunks, into a 16-bit RGB file.....

Juan

Obin Olson · March 28th, 2004, 12:38 AM

awesome, so your almost to get color eh? god this rocks man! so glad your doing it!!

Eduardo Soto · March 28th, 2004, 12:46 AM

Hmmm..so then, I would need a lacie with fw800 interface and that's it? or would I still need the laptop to control the hard disk recording.... that's great that I could get 4:2:2 though, no sour grapes there...

you're almost there, man! woo hoo! rootin for ya!

es

Juan P. Pertierra · March 28th, 2004, 01:10 AM

Yes, assuming you have power nearby, you can hookup the firewire directly to the drive. I am implementing a FW host on the programmable chip that's in the box mounted under the camera, so it will directly control the drive like a PC would.

However, if you're using the camera on batteries, you might need some battery for the drive itself.

Juan

Isaac Brody · March 28th, 2004, 01:25 AM

Wow. Can't wait to see your results. Great job so far Juan. Keep it up.

Jason Rodriguez · March 28th, 2004, 01:27 AM

<<<-- Originally posted by Ben Syverson : With all due respect, I totally disagree. Creating a 10-bit DPX/Cineon log file would require reprocessing the image to fit into the log color space (and probably correct for "white balance")-- which probably can't be done in real-time while capturing.

The ideal situation would be to capture to raw 12 bit files, and then develop a converter application which could export 16bit TIFFs, DPX/Cineon, OpenEXR or whatever you like...

- ben -->>>

Then why is 10-bit log DPX the SMPTE standard for Digital Cinema? Also for digital intermediate, film scanning, etc.?

Yes, that would be ideal to just capture RAW files, but then you're going to have to create a non-linear curve to expand it into a 16-bit file. If you've ever looked at a 12-bit linear file directly dumped into a 16-bit file, it's going to look very, very dark-my Canon D60 does this, and you have to then apply a LUT or color profile to the image to get it to look right. That would be A LOT of unecessary rendering in post IMHO, when you could simply apply a LUT to a DPX or Cineon file and go on from there. Also the file sizes are a lot smaller too, which means less hard-drive muscle, and more space for your dollar. Again, I don't think the DPX file format is simply there for kicks. Also there is a huge metadata header in the DPX format, where you can embed timecode, userbits, etc. That may not be something to sneeze at when you've recorded 2 hours+ of image sequences and you're trying to make heads or tails of your footage.

Jason Rodriguez · March 28th, 2004, 01:31 AM

<<<-- Originally posted by Juan P. Pertierra : Oh so close!

All wires hooked up, captured data, now i'm writing a small proggie to unpack the 30 relevant bits(10bit RGB) packed in the 32bit chunks, into a 16-bit RGB file.....

Juan -->>>

I thought the A/D converter was 12-bits-per-pixel. What happened to the other two bits?

Ben Syverson · March 28th, 2004, 02:33 AM

<<Then why is 10-bit log DPX the SMPTE standard for Digital Cinema? Also for digital intermediate, film scanning, etc.?>>

You're missing the point entirely. I wasn't dissing DPX/Cineon in general -- sure, it's a great format, and it's there for a reason. The point is: why convert to DPX in realtime as you're recording? It doesn't make any freaking sense -- the easiest thing to do is dump the data coming in off the A/D directly into a raw file. Then you can write an application (as Juan is doing right now) to convert the data into any format. If you simply must have your image in Cineon format, you can convert to it.

Although I can't see a good reason to convert
this stuff to Cineon. The whole point of the Cineon format (and log colorspace) is to protect the dynamic range of motion picture film. The idea is that you trade off image data in the darks and brights for way more dynamic range. You can protect those overbrights and sub-blacks that film can record.

But we're dealing with a strictly linear digital readout of a CCD. It exists in 10 (or 12?)bit linear colorspace. Why on earth you would throw away that data to use a file format designed by Kodak in the early nineties for a now-defunct compositing system is totally beyond my comprehension. High end compositing isn't even done in log-space anymore -- it's done in linear floating point. You may get Cineon files for input, but you have to do a log->linear conversion to even work with them.

A much more logical approach is what Juan seems to be doing, which is outputing the data in 16bit linear RGB files. There are two ways to accomplish this: padding (which would mean all of your images would seem "dark" in 16bit space) and "expanding" the 10/12bit range to 16bits, so that 100% white at 10/12bits becomes 100% white in 16bit. That's clearly the best (but slower) option. You would *NOT* need any "non-linear curve" to convert to 16bit.

And I must, must take this opportunity to point out that there is absolutely NO speed advantage to working in 10 or 12 bit over 16bit. Because processors can't work with 10 or 12 bit values (there's no data type for "10 bit"), they'll get padded to 16bits anyway -- so the speed will be identical. This is beside the fact that many image processing operations occur internally in 32-bit floating point space anyway -- regardless of whether the destination is 8bits or 16bits.

And although 16bit files do take up more room than 10bit files on disk, these files are so huge that it kind of doesn't matter after a while. If you can handle 2.5gigs/minute, you can handle 4gigs/minute.

- ben

Juan P. Pertierra · March 28th, 2004, 04:12 AM

Jason:

A/D's are 12-bit, but my test capture card can only do 32-bits at one time, so i am doing 10-bit RGB.

Juan

Milosz Krzyzaniak · March 28th, 2004, 05:51 AM

To Jason Rodriguez:

Jason. I asked my question about "tonal ranges" because my friend owns Canon D300 and there are 2 modes in it:

* TIFF mode - produces standard 8-bit images
* RAW mode - which, as my friend told me, produces 10 or 12 bit raw files that are just created by READING OFF THE CCD DIRECTLY.

Now. He opened one of the RAW files in Photoshop. The image itself looked bad - it was TOTALLY overexposed, there were absolutly no details in the middle and highlites. And now, the magic, one move with a slider - and he was able to recover the picture with (almost) all of the details that were previously unvisilbe (were beyond the white point of TIFF image)! Something of course completly imposssible with any TIFF 8-bit image.

So, isn't the same apply here?

Bartholomew Boge · March 28th, 2004, 08:24 AM

Are we potentially looking at the birth of a new recording format here?

Steven Zu · March 28th, 2004, 09:26 AM

<<<-- Originally posted by Juan P. Pertierra : Jason:

A/D's are 12-bit, but my test capture card can only do 32-bits at one time, so i am doing 10-bit RGB.

Juan -->>>

Is money a stumbling block? If you need capital to buy equipment, raw materials, etc., perhaps all of us who are following your work with such great anticipation could donate to the effort.

If 20-40 of us could pitch in $50 that would raise $1000-$2000 for you, would that help build a prototype?

We would assume some risk the final product would never actually materialize perhaps in return for an "at cost" unit if/when you are able to create working ones.

Michael Struthers · March 28th, 2004, 10:37 AM

I believe home-grown camera's (one or two man companies) have started to spring up and a couple of these cams will be shown at nab. These are film guys who have wrapped a body around some chips and a lens.

Juan P. Pertierra · March 28th, 2004, 03:27 PM

Just an update,

A lot of prgress! I've got pretty good quality R, G, B images out of it, but i did run into a small snafoo....apparently because of the way the prism is setup, the green frames come out inverted, so i have to modify my proggie to isolate and invert the frame before building the RGb file...i also have some bits that don't seem to be what they should, but i'm figuring it all out....

Juan

March 28th, 2004, 01:25 AM	#231
Isaac Brody New Boot Join Date: Mar 2004 Location: New York, NY Posts: 5	Wow. Can't wait to see your results. Great job so far Juan. Keep it up. __________________ The enemy of art is the absence of limitations. -Orson Welles

March 28th, 2004, 01:27 AM	#232
Jason Rodriguez Trustee Join Date: Mar 2003 Location: Virginia Beach, VA Posts: 1,095	Re: DPX/Cineon == badness <<<-- Originally posted by Ben Syverson : With all due respect, I totally disagree. Creating a 10-bit DPX/Cineon log file would require reprocessing the image to fit into the log color space (and probably correct for "white balance")-- which probably can't be done in real-time while capturing. The ideal situation would be to capture to raw 12 bit files, and then develop a converter application which could export 16bit TIFFs, DPX/Cineon, OpenEXR or whatever you like... - ben -->>> Then why is 10-bit log DPX the SMPTE standard for Digital Cinema? Also for digital intermediate, film scanning, etc.? Yes, that would be ideal to just capture RAW files, but then you're going to have to create a non-linear curve to expand it into a 16-bit file. If you've ever looked at a 12-bit linear file directly dumped into a 16-bit file, it's going to look very, very dark-my Canon D60 does this, and you have to then apply a LUT or color profile to the image to get it to look right. That would be A LOT of unecessary rendering in post IMHO, when you could simply apply a LUT to a DPX or Cineon file and go on from there. Also the file sizes are a lot smaller too, which means less hard-drive muscle, and more space for your dollar. Again, I don't think the DPX file format is simply there for kicks. Also there is a huge metadata header in the DPX format, where you can embed timecode, userbits, etc. That may not be something to sneeze at when you've recorded 2 hours+ of image sequences and you're trying to make heads or tails of your footage.

March 28th, 2004, 10:37 AM	#239
Michael Struthers Major Player Join Date: Jul 2003 Location: SF, Ca Posts: 421	I believe home-grown camera's (one or two man companies) have started to spring up and a couple of these cams will be shown at nab. These are film guys who have wrapped a body around some chips and a lens. __________________ Michael Struthers www.buzzdigital.com

March 28th, 2004, 12:09 AM	#226
Juan P. Pertierra Major Player Join Date: Jul 2003 Posts: 479	Well, since the firewire interface is fast enough to handle full quality, i will probably include an option to do filtering on the software driver end so if you don't have that fast a drive, you can still record 4:2:2 or 4:1:1 uncompressed. However, for the full 4:4:4 you need a fast drive that can handle sustained 40MB/s. I know if at least one external drive that can do this: the LaCie FW800 external big drives. The new versions are even faster. I have an old version, and in all benchmarks it can do 67MB/s sustained, so it is more than enough. My laptop drive is also fast enough according to benchmarks, but it is kinda cutting it close, so i'm not sure how other OS operations slow everything down. Juan

March 28th, 2004, 12:29 AM	#227
Juan P. Pertierra Major Player Join Date: Jul 2003 Posts: 479	Oh so close! All wires hooked up, captured data, now i'm writing a small proggie to unpack the 30 relevant bits(10bit RGB) packed in the 32bit chunks, into a 16-bit RGB file..... Juan

March 28th, 2004, 12:38 AM	#228
Obin Olson Trustee Join Date: Jan 2003 Location: Wilmington NC Posts: 1,414	awesome, so your almost to get color eh? god this rocks man! so glad your doing it!!

March 28th, 2004, 12:46 AM	#229
Eduardo Soto New Boot Join Date: Mar 2004 Posts: 13	Hmmm..so then, I would need a lacie with fw800 interface and that's it? or would I still need the laptop to control the hard disk recording.... that's great that I could get 4:2:2 though, no sour grapes there... you're almost there, man! woo hoo! rootin for ya! es

March 28th, 2004, 01:10 AM	#230
Juan P. Pertierra Major Player Join Date: Jul 2003 Posts: 479	Yes, assuming you have power nearby, you can hookup the firewire directly to the drive. I am implementing a FW host on the programmable chip that's in the box mounted under the camera, so it will directly control the drive like a PC would. However, if you're using the camera on batteries, you might need some battery for the drive itself. Juan

March 28th, 2004, 01:31 AM	#233
Jason Rodriguez Trustee Join Date: Mar 2003 Location: Virginia Beach, VA Posts: 1,095	<<<-- Originally posted by Juan P. Pertierra : Oh so close! All wires hooked up, captured data, now i'm writing a small proggie to unpack the 30 relevant bits(10bit RGB) packed in the 32bit chunks, into a 16-bit RGB file..... Juan -->>> I thought the A/D converter was 12-bits-per-pixel. What happened to the other two bits?

March 28th, 2004, 02:33 AM	#234
Ben Syverson Major Player Join Date: Mar 2004 Location: chicago Posts: 434	<<Then why is 10-bit log DPX the SMPTE standard for Digital Cinema? Also for digital intermediate, film scanning, etc.?>> You're missing the point entirely. I wasn't dissing DPX/Cineon in general -- sure, it's a great format, and it's there for a reason. The point is: why convert to DPX in realtime as you're recording? It doesn't make any freaking sense -- the easiest thing to do is dump the data coming in off the A/D directly into a raw file. Then you can write an application (as Juan is doing right now) to convert the data into any format. If you simply must have your image in Cineon format, you can convert to it. Although I can't see a good reason to convert this stuff to Cineon. The whole point of the Cineon format (and log colorspace) is to protect the dynamic range of motion picture film. The idea is that you trade off image data in the darks and brights for way more dynamic range. You can protect those overbrights and sub-blacks that film can record. But we're dealing with a strictly linear digital readout of a CCD. It exists in 10 (or 12?)bit linear colorspace. Why on earth you would throw away that data to use a file format designed by Kodak in the early nineties for a now-defunct compositing system is totally beyond my comprehension. High end compositing isn't even done in log-space anymore -- it's done in linear floating point. You may get Cineon files for input, but you have to do a log->linear conversion to even work with them. A much more logical approach is what Juan seems to be doing, which is outputing the data in 16bit linear RGB files. There are two ways to accomplish this: padding (which would mean all of your images would seem "dark" in 16bit space) and "expanding" the 10/12bit range to 16bits, so that 100% white at 10/12bits becomes 100% white in 16bit. That's clearly the best (but slower) option. You would NOT need any "non-linear curve" to convert to 16bit. And I must, must take this opportunity to point out that there is absolutely NO speed advantage to working in 10 or 12 bit over 16bit. Because processors can't work with 10 or 12 bit values (there's no data type for "10 bit"), they'll get padded to 16bits anyway -- so the speed will be identical. This is beside the fact that many image processing operations occur internally in 32-bit floating point space anyway -- regardless of whether the destination is 8bits or 16bits. And although 16bit files do take up more room than 10bit files on disk, these files are so huge that it kind of doesn't matter after a while. If you can handle 2.5gigs/minute, you can handle 4gigs/minute. - ben

March 28th, 2004, 04:12 AM	#235
Juan P. Pertierra Major Player Join Date: Jul 2003 Posts: 479	Jason: A/D's are 12-bit, but my test capture card can only do 32-bits at one time, so i am doing 10-bit RGB. Juan

March 28th, 2004, 05:51 AM	#236
Milosz Krzyzaniak Regular Crew Join Date: Mar 2004 Location: Germany Posts: 64	To Jason Rodriguez: Jason. I asked my question about "tonal ranges" because my friend owns Canon D300 and there are 2 modes in it: * TIFF mode - produces standard 8-bit images * RAW mode - which, as my friend told me, produces 10 or 12 bit raw files that are just created by READING OFF THE CCD DIRECTLY. Now. He opened one of the RAW files in Photoshop. The image itself looked bad - it was TOTALLY overexposed, there were absolutly no details in the middle and highlites. And now, the magic, one move with a slider - and he was able to recover the picture with (almost) all of the details that were previously unvisilbe (were beyond the white point of TIFF image)! Something of course completly imposssible with any TIFF 8-bit image. So, isn't the same apply here?

March 28th, 2004, 08:24 AM	#237
Bartholomew Boge New Boot Join Date: Mar 2004 Location: Lombard, IL Posts: 5	Are we potentially looking at the birth of a new recording format here?

March 28th, 2004, 09:26 AM	#238
Steven Zu Tourist Join Date: Mar 2004 Posts: 1	<<<-- Originally posted by Juan P. Pertierra : Jason: A/D's are 12-bit, but my test capture card can only do 32-bits at one time, so i am doing 10-bit RGB. Juan -->>> Is money a stumbling block? If you need capital to buy equipment, raw materials, etc., perhaps all of us who are following your work with such great anticipation could donate to the effort. If 20-40 of us could pitch in $50 that would raise $1000-$2000 for you, would that help build a prototype? We would assume some risk the final product would never actually materialize perhaps in return for an "at cost" unit if/when you are able to create working ones.

March 28th, 2004, 03:27 PM	#240
Juan P. Pertierra Major Player Join Date: Jul 2003 Posts: 479	Just an update, A lot of prgress! I've got pretty good quality R, G, B images out of it, but i did run into a small snafoo....apparently because of the way the prism is setup, the green frames come out inverted, so i have to modify my proggie to isolate and invert the frame before building the RGb file...i also have some bits that don't seem to be what they should, but i'm figuring it all out.... Juan