First ~very~ partial color frame
 

Ok, so let me first explain what this is.

This is a section of a frame, and of a very uninteresting scene, basically what my cannibalized DVX sees from it's test location. I know it is a bad test image, but you have all been waiting so i decided to release it.

This image ONLY contains about 77% of the complete color information. This is because 6 bits i can't fit into my current test card, and two bits seem to be disconnected for some reason.

There is also a hefty amount of obvious 'noise', which i am almost completely sure is caused by the disconnected bits. The noise is clearly seen as harsh black/red/etc dots peppered around specific areas.

It is slightly off focus, because i simply didn't :) Surprised i can even tell what i'm looking at....once again, no LCD no viewfinder.

I put the R,G,B layers together in photoshop. I used the default layer settings in photoshop, so this might not be the correct way of putting them together. If someone is a photoshop guru and knows how to combine three grayscale images into a color image perfectly, let me know.

Finally, a clear green hue can be seen which i beleive is normal of just about every image i have seen captured straight from CCD's, including the Thomson Viper.

I will be working this week on capturing a complete video clip, and somehow move my test setup to the balcony so I can capture a more interesting and hopefully colorful image.

Also, be sure to see it in an actual paint program like Photoshop, because browsers and preview programs perform smoothing:

http://expert.cc.purdue.edu/~pertierr/DVXcolorcap.bmp

This is the same image, but after doing an 'auto levels' on each color layer independently.

http://expert.cc.purdue.edu/~pertier...olorcap_AL.bmp

I think there is going to be remarkable freedom to manipulate the colors in every frame, pull detail from dark areas, etc. And this is only at 9 1/3 bits. :)

wow..very cool...i see what you mean about color depth with this "RAW" file.....this is VERY exciting! dv is such a HUGE limitation for a really GREAT camera and creative project shooting just because of the compression...I love the dvx100 and hate DV ;)....Juan you may find this kinda cool:

http://www.dv3productions.com/upload...low-focus-.jpg

I just got done building that unit...I will be selling it shortly...

when it comes time to build your "box" for the bottom of the camera feel free to talk with me if you want about the design and manufacture of your unit..

Yowsers! (okay, sounds like Woody Allen, anyways)

There is a TON of latitude in those blacks!!! Dang!

BTW, I will agree that the best way to record these images is just save the RAW data-with a converter program convert them to whatever format you want later. That way you perserve the RAW data, and if better algorithms, noise suppression, etc. come out later, you can take advantage of those improvements without any of the potential loss that a specific file format might incur-even if it is 16bits-per-pixel.

I still don't think that Log encoding is as antiquated as you might believe. Thomson is doing it, Kinetta will be doing it, Dalsa is doing it-all the big boys are doing it. Even panasonic is psuedo-"doing it" with their F-REC mode in the Varicam's cinegamma, at least by the indications from a white paper released at this year's HPA tech retreat. But again, I will agree with you that the best place for any of those conversions is after the fact, after the RAW data has been recorded-then like you said, we can do whatever we want.

Oops! The images are actually 8-bit/channel! None of the programs I have can save TIFF or BMP in more than 8-bit color per RGB channel, so the file format is actually cutting precision down.

Anyone have any suggestions for standard graphics formats that support at least 12-bits or 16-bits per RGB channel i.e. it would be something like 36-bit color.

Juan

16 bit tiff
 

16 bit tiff should be fine!

- ben

afaik TIFF can only do up to 24-bit color(8-bit RGB). 16-bit tiff would be 4-bit RGB with a 4-bit alpha channel...

Check again... 16bit/pcc TIFF is an export option in Photoshop.

It's been a few months since I looked at the TIFF file format spec, but I think the TIFF file format itself supports *any* color depth. Of course, the specific TIFF implementations in most commercial software only support 8bit and under, since other color depths are so rare.

- ben

Try professional image standards, I don't know all their names (one of them is RLA). You can find them in After Effects, Combustion and so on. Most of them could be 10 or 12 bit.

On my Photoshop CS (and I'm pretty sure 7 and maybe 6) I've got 16-bit TIFF option.

Here's one of my 48-bit scans (it's raw corrected tunsten film shot in daylight) saved as a 16-bit TIFF. Note it is 32 MB in size.

http://www.sevensmilingsharks.com/cat.tif

I will check...but i have photoshop 6 and photoshop elements and neither of them allows me to specify bit depth in TIFF....

It might have been added in Photoshop 7.

PS. My upload barfed - I just restarted it. Should be done in 30 minutes.

You don't specify the bit depth when you're exporting the TIFF -- you just open a 16bit document (or convert an 8bit one by going to Image->Mode->16 bits/channel) and then go to "Save as" and you'll see TIFF listed alongside Photoshop in the save options. It won't tell you it's saving as 16bit, but it is.

PS has been 16bit (in some capacity) since at least 6.0, so it shouldn't be a problem...

- ben

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?



es

Hi Jaun,

There are a number of image formats that allow for greater bit-depths. These include .HDR, OpenEXR (.EXR, open-source format developed by ILM that supports float, a plugin is available for photoshop and most compositing applications), Maya .IFF files, Cineon (.CIN, .KDK), .DPX, .RLA, .RPF, .SGI , and of course 16 bit and floating-point .TIF.

Not all of these are supported by Photoshop, but some do have plugins that enable photoshop to read them. Let me know if you'd like any specific information on any of the formats.

<<<-- 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

<<<-- Originally posted by Juan P. Pertierra : 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.

Juan -->>>

Just watch out that whatever image transformations you do on the RAW data that you're not inducing the potential for banding artifacts. If you run a levels filter on the image when the camera is recording and writing to disk, and then we run another levels filter when we try to color correct our images, that might be enough to start some banding artifacts, which IMHO defeats the whole purpose of getting RAW data at 16-bits.

Peter, your s-vhs or y/c out is before the compression hits the video..so its 4:2:2...that is why you get a better key off y/c out..I used it for a spot I did that I needed a really good greenscreen key

Ok, i have found the source of my confusion...i am using photoshop 6 and whenever I change mode to 16-bits/channel, it won't let me do layering. This is why the files where 8-bit, not because of limitations of the TIFF format.

Is this a limitation of PS6 only? I'm going to try and do it in Shake....

Jason, bitshifting or multiplying the data isn't going to introduce any banding, because you maintain the number of color levels. You go from 4096 to at least 32768, so you're not losing any of that information. When Juan talks about a Levels call, he just means bringing in the In White Point, which is equivilent to multiplying the data.

Also, 4096 values (68.7 BILLION possible colors) gives you a TON of leeway in terms of banding. You'd have to be applying a very extreme levels call to be able to make it band. Keep in mind that 10 bit Cineon only has 1024 values (1 billion colors), and only a fraction of those values are used on the "normal" image range.

Also, any levels call would probably happen in 16bit space, not 12 bit space, which means a value that was 16000 before the levels call could wind up as 15999 or 16001. 16bit space has no fewer than 35 TRILLION colors for you to play with. So those initial 4096 values will be preserved as much as possible.

Basically, data loss resulting from upping the bitdepth is not something to be concerned with...

- ben

Juan:

In Photoshop CS, I can do all layer operations with 16-bit TIFFs. I think 7 does as well, but not sure. Many filters and plugins don't support 16-bit operations, but standard PS adjustments (levels, contrast etc.) work fine.

I'm trying to provide as many updates as I can, so here's another one. I have uploaded a complete frame so you have an idea of what frame size i'm getting out of it...important to note is that the CCD has 0.9 NTSC aspect ratio pixels, so in order to see the correct image you would need to use a viewer that can compensate for this.

This image, however, is an extremely bad one not only because of the noise you all know about, but because somewhere along the line I am getting a serious problem with two of my channels...some areas that come out black in the raw file are coming out shifted to a different level, and it has to be a problem with my code, cause the capture is fine.

This is 9-bits/channel at the most, probably very innacturate in the green and blue. Also, i had trouble getting an exact match of the blue layer position-wise, because it comes out inverted from the prism and it's very hard to see and move exactly to match.

http://expert.cc.purdue.edu/~pertierr/ScottsBook.tif

I hope i am not doing something illegal by posting the book cover...it just makes a good test image. :)

Oh and the yellow blotch on the paper is not a highlighter spill, it's actually one of the bits i mentioned before, just went to zero in that whole area....same situation with the noise in the rest of the image....i know where the problem is, i just want to test as much as possible before i start breaking it apart again.

Juan:

I edited your post to make the URL easier to download using the tags...

Thanks Stephen!

About the clips: I am getting continous frames(say what about slow hard disks? :) ), but since the camera is sitting on my test bench there's no motion going on, so there's no point in putting together a clip.

I'm going to try and move it to the window and record something moving this afternoon or tomorrow morning.

Juan

Y/C Out
 

Obin... you're saying that if you record the signal coming out through the s-video connection using a video card that supports uncompressed video direct to disk, that the video isn't gonna be 4:1:1 re sampled to 4:2:2 but just clean 4:2:2? If that's the case then Juan's prospect of pulling 4:4:4 video off the chips is really the only exciting feature of this work, right? Don't get me wrong, it's EXTREMELY exciting, but this thread started out by saying that this process could most practically be used to turn the DVX100 into a camera with the kind of recording power as the 900. If you can already record the signal as 4:2:2 before it's gone through the DV downgrading process then wouldn't that be the same recording power as the 900? Excuse me if I sound naive... I may be missing something.

John

I've never agreed with the practice of capturing through Svideo to get a better image. First of all, Svideo is much lower resolution than MiniDV, so you lose a ton of your image right there. Secondly, the image may technically be "4:2:2", but if you look at the chroma channels, they are actually very blurry, and *less* detailed than the MiniDV footage. Furthermore, you have the classic problem of analog video, chroma drift. This is where the chroma is smeared off to one side, so that it's not quite aligned with the Luma.

The blurry chroma channels are why people think this method is better for chroma key -- but really, you can get a far superior key (and image) by capturing normally to MiniDV and blurring your chroma channels moderately before keying. The advantage here is that you have control over how much blurring is going on, and you don't have to worry about Luma/Chroma alignment.

Of course, maybe I'm biased because I wrote a plugin called dvmatte, specifically designed for keying with DV footage... ( http://www.dvgarage.com ) It handles all the chroma blurring internally, and includes special techniques for re-introducing detail into the key...

I challenge anyone to post a "4:2:2" frame of a blue/greenscreen shot next to a MiniDV frame of the same shot. It should be clear to the naked eye which is the superior image...

- ben