<<<-- Originally posted by Eduardo Soto : Provided that one is able to save these the data as TIFF or similar format, what are the steps to actually editing for video/film purposes? -->>>

Juan should be easy to write a program to assemble these into uncompressed avi. Or, alternatively, you could just use automation to assemble the tif/bmp/whatever series in combustion or some other compositing program of your choice.

<<<-- Originally posted by Adam Burtle : <<<-- Juan should be easy to write a program to assemble these into uncompressed avi. -->>>

Why AVI? Is there a 16-bit AVI codec out there? I know there's a free cross-platform 16-bit Quicktime codec call None-16 available from Digital Anarchy. You can't beat free, and basically it's an uncompressed "None" codec file, but expanded to use 16bpp instead of the default "none" codec's 8bpp.

I'd much prefer an sequence such as .exr or cineon which have their own lossless compression. Would be smaller than an uncompressed 16bp QT, and if capturing should be interrupted you'd have the previous captured frames instead of a corrupt QT movie.

I haven't checked the specs for AVI yet...but does it allow 12-16 bit per RGB channel(i.e. 36-48bit RGB)? I see some people talking about 16bpp, and afaik 16bpp RGB is 4-bit per channel and a 4-bit transparency channel. Also many specs talk about 16-bpp and they do have 16bits per pixel for color, but it is paletted color...

I read the TIFF spec and it does not specify what is the max bits per channel in RGB mode..it only provides an example with 24-bits(8,8,8). The format should theoretically support everything, but the software you are using(ex. photoshop) has to recognize it...

Juan

Oh and at the very least, there is Cineon...i know that format supports linear 12-bit per channel RGB.

Normally, when I have a bunch of frames i drop them into Apple Shake and it composes them into whatever I want.

AFAIK Juan there has not been a greater than 8 bit per pixel codec developed for the AVI format as of yet.

Juan, trust me, there IS such a thing as 16bit pcc (per color channel) TIFF. It's not 4 bit. It's not 16 bits per pixel. It's not palletted. It's TRUE, FULL, 16bit per color channel, for a total of 64bits per pixel. I'm fairly certain PS 6 can export 16bit TIFFs, but it might have only been added in PS 7. I know for a fact that CS (version 8) supports many 16bit filetypes.

OpenEXR is another possibility, but TIFF or RAW files would be much faster to write in realtime. (OpenEXR has a sophisticated lossless compression algorithm that wouldn't be very efficient with DVX100 footage, since it relies on film grain to compress the data.)

Cineon is not 12 bit, it's 10 bit, and I believe it only supports log space, not linear. There are only 1024 values pcc in Cineon space as opposed to 32768 (signed 2byte) or 65535 (unsigned 2byte) in 16bit space.

Saving to a QuickTime movie (or god forbid an AVI) is probably a bad idea, as QT movies do have a way of turning out corrupted if you interrupt the writing process.

- ben

Cineon can do 1, 8, 10, 12, 16, 32, 64bit per image component(R,G,B,Y,C,etc). It can do linear or log transfer characteristic in any of these modes, along with a bunch of other standards.

Juan

Well, maybe in the same way that I can write a 128bit TIFF file that no one can read... Film digitizers and recorders only work with 10bit log Cineons, so most software only supports this implementation of the format... You could generate a linear 12 bit cineon sequence, but the only software able to read it will start at $5000...

IMHO using Cineon for a raw CCD read is ridiculous -- even if it can technically do linear data, it is explicitly designed as a log format for the handling of motion picture film.

16 bit TIFFs are ideal because the format is so simple. You could cache a generic header for the sequence and then cat the header with the raw image data as it comes in to generate TIFFs...

- ben

BTW, 16bit pcc (64bit) PNGs are also an option...

- ben

Ben:

I'm inclined to agree. Cineon is awkard format to handle, while 16-bit TIFFS are very straightforward to handle on my system.

Photoshop and After Effects in their current versions smoothly handle these files.

Additionally, I just verified that Vegas 4.0d handles the 16-bit tiffs natively (drap and drop onto timeline), so I could edit them natively out the cam. Vegas lists it's internal color support as "32-bit" but not exactly sure how they define that.

Yah, after reading all these posts, I'd say a 16-bit file is the way to go.

But, should you make the file non-linear, or linear (number padding)? A linear file with number padding will appear very dark, but if you decide to stretch 12-bits over 16-bits so that the image appears "normal", aren't you doing some sort of "transform" on the image that "modifys" the data? In otherwords, the 12-bits don't align perfectly with the 16-bits, so it' a nonlinear relationship in that some number rounding will have to occur or LUT be applied for the bits to be stored to properly produce a "correctly exposed" image. In that case the image is no longer truley "RAW".

Right now the bits not being captured are the low-order bits, so the scales should be spread evenly, just loose precision. Apparently, doing an auto-levels(spread the values so they cover the entire range) does the trick as shown on the second image.

Update:
Today i got full frames in continous capture. I still have those two bits missing which are causing the dots but i am going to post complete frames/clips before i try to fix the connection.

I'm also going to attempt to get a DV duplicate of a frame for direct comparison, although i'm not sure if it's a good idea to do a comparison since the frames are still partial and noisy..i am still not sure if not having those 6 low-order bits has a large impact on the overall image....

Juan

Well, think of it this way. A 12 bit image can represent 4096 distinct values per channel. A 16 bit image can represent 65536 (or 32768, depending on the format). If there are rounding errors, they will be within one value in the 16 bit image -- that's a margin of error of 0.000015% or 0.00003%.... I think that's close enough to call lossless. :)

Actually, maybe there's a 100% lossless way to convert the data with bitshifting? I've never dealt with 12 bit values before...

- ben

Hi Juan,

Count me as very (more like extremely) interested in your project.
You get this to work and I'll be one of your first customers.

Two questions to start:

1. Are you planning on making this a product?

2. I often capture the dvx100 s-video out to a uncompressed 4:2:2 DDR. Where in the dvx video pathway is the s-video? Is it after it's been down sampled to 4:1:1? Is it post DV compression?

Thanks and good luck,
Pete