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

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

Ben I love your plugin! but in the end after all is said and done I got a much better key from y/c capture direct to disk then I ever could from your plugin....and I really really tried to make yours work...for many shots your plugin is great but some the y/c capture just worked better...you don't have to challenge anyone, I KNOW dv is "better" but sometimes it's keys are not...

Ben, y/c out has no chroma blockies like dv does..that is the ONLY reason I could pull a better matte...i'ts not that y/c suppresses them,,they just dont exist period...i talked with Panasonic and they also told me that y/c does NOT hit dv compression on the way out... Peter y/c sucks Juan's 4:4:4 digital out is MUCH MUCH better then Y/c.....

Since all the Svideo capture is doing is massively smearing the chroma, one thing to try when dvmatte is not working out is increasing the chroma blur. You should never see the "blockiness" of MiniDV chroma after dvmatte is done with it. Besides blurrier chroma channels, there are really no other reasons why keying Svideo would work better than MiniDV.

Especially if you're using dvmatte pro, you should have no trouble getting a better key from MiniDV than with Svideo footage....

Sorry, I know this is OT -- I'll shut up about y/c capture now. :)

- ben

There's a new forum Chris has but up (Alternative Imaging) and I'm wondering if that might be a better home for this thread for several reasons:

(1) Due to it's popularity and longevity, most DVX100 users here are quite familiar with it. Juan could post results later.

(2) The technology he's developing could apply to any camera (e.g. XL1s with mini35, JVC HDV etc).

(3) Input from other "alternative imagers" might enhance the thread

What does everyone (esp. Juan) think?

Stephen,

I think it's a good idea, either way I will post results in this forum later.

Update:

That last complete frame i posted had much less precision than 9-bits, at least in the blue and green channels...you can tell from the color shades on my hand that it's pretty decimated. The partial frame i posted before had a bit more precision.

Today I am working on fixing this problem to get the full 10-bits out of each channel, it's only a physical contact problem, but these are pins less than 0.5mm in width, so it takes some time to work with them.

The continous capture is working, so this is the only hurdle to getting the full quality video my capture card can handle. A second capture card would allow me to capture the full 12-bits per channel, but it costs ~$700 so this will have to do for now....

Will update again tonight.

Juan

Got really quiet suddenly. Did I miss something and this topic was moved?

Looking forward to seeing the continuous capture.

Run into any problems?

Pete

I just moved it to it's new home here.

I don't understand. Is there any new location of this thread?

Peter:

I've reset the chip probe and will hook it all up again tonight to see if I got all 30 bits this time. I've been slowed down a bit by a nasty toothache...

Milosz:
This thread is now in the Alternative Imaging Methods forum, it used to be in the DVX100 forum.

Juan

Milosz: yes, the thread was moved to another forum. It is now
in "Alternative Imagine Methods". I think it was in the Film Look
forum.

The thread identifier hasn't changed. So if you have the thread
bookmarked for example or have notifications on the thread,
those will still be in place and working! So no problems.

juan, any news? any pictures? movies?


filip

Sorry for the lack of updates, i have been working on a better solution to the probing problem, and i'm almost done with it...now it's just snap-and-go, and hopefully all intermittent bit connections will be fixed.

I have also been working simultaneously on my software which now spits out 16-bit/channel RGB individual frames in a new directory, takes care of flipping over the blue channel, etc.

more to come soon.

Juan

Allright! So after much time experimenting i designed a new method of easily probing the pins. The good news is that i'm pretty sure I am getting all 30 bits(10-bit RGB). The not so good news is that there is still some noise, which must either be related to the bad cables I am using, or somehow related to the missing lower bits. However, i beleive it has less noise than the images i've posted so far.

Right now the whole thing sits in the same place, so if you'd like to see some boring frames, let me know what you'd like to see(coke can, magazine cover, etc.) as well as lighting.

Tomorrow i'm going to finally move it all to the window and take a decent clip of a car driving by. If it's sunny, it's bound to be a good test, there's plenty of color around. Right now because of my setup i don't have control over exposure(controller disconnected) so everything is at full open, hopefully the ND's will do the trick.

Another note:
While working on the camera I was amazed once again at how much space there is behind each CCD chip, and I realized that an incredibly easy and useful mod would be to mount thermoelectric coolers on each chip! These are only about $15 a piece, and I can adhere one to each chip, run them off a battery. This should have a great effect on the S/N ratio, it's a similar technique to what is used in astrophotography, to reduce the thermal noise to a minimum...i'm not even sure why some manufacturer hasn't included it.

Juan

Interesting!

Ok, let me see how to explain this...

While looking through the viewfinder in my current scene, there are clearly areas in the scene which are overexposed(allwhite).

Now, i would expect this to be the point at which the CCD's clip, and like so i would expect to get white or close to white in those areas in the RAW feed...

HOWEVER, i am getting values in those areas as if the A/D's actually topped off the 12-bit but instead of giving me the max 12-bit value(i.e.white), it's going around and starting over at the bottom, giving me a dark value, but which really reflects what is in that white area! I'm not sure what is going on, but the way it looks now i think i can use this to pull detail out of the areas that clip out in standard DV footage...

Juan

glad to hear from you again! are you talking about Peltier coolers? how much would that effect the s/n do you think?

keep at it..I am sure you will figure it out....I would love to see a pic or 2 of your setup on the test probe and how it connects to the chips...not that I would ever do it but just to see how it works ;)

<<<-- Originally posted by Juan P. Pertierra : I'm not sure what is going on, but the way it looks now i think i can use this to pull detail out of the areas that clip out in standard DV footage...

Juan -->>>

Great. Expecting to outfit at least 3 XL's with your mod (whenever finished), and the only remaining problem i have with emulating/duplicating film quality, is the lack of latitude in exposude on digital.. so if you can improve that, all the better!

So, Juan? It seems that my prediction was right? The same as in my friend's Canon D300 the RAWs give more dinamic than standard pictures. And I'll tell you I think this would be the biggest advantage of RAWs among all (4:4:4, no compression).

Suggestion on how to prepare the test situation to shoot. You dont need to move your dvx to the window to obtain some movement, you just may use your hand to move something. Put a doll or something in front of the camera with a lot of colorful things. And the most importatnt: light it with much contrast: put a light to the side of the scene and light to overexposion: we would like to see what is the behaviour of this RAW thing in such conditions.

Just rememer to film not a planar thing (wall, book) but a real 3D something that could give shadows and so on.

Good luck.

Adam: what makes you think this will work with an XL1S? Juan
is building this with a DVX100 as you can see from the thread
title. I would not assume (automatically) that:

1) the XL1S has 12 bit stuff in it (I don't know it if has)

2) someone knows how to get to it

3) someone has tested whether it will work

4) someone will ever do any of the previous points

etc. A better question might be to ask whether someone knows
if this will work with an XL1S and/or can test that....

wrangle him rob ;)

how much more dynamic range does film still have over the current crop of cmos and ccd cameras/video cameras?