Preserving Superwhites Of Dv Footage

[user_deleted]

I'd like to color correct some DV footage that has quite a bit blown out bits in Shake ... examining the footage in FCP i can see that some more detail is preserved in the superwhites (over 100%, ie 235+ values), but if i load the quicktime files into shake those parts get clamped (probably by the quicktime loader) and i cant get them back. (as a side note, the same thing happens in AE).

anybody has an idea how to access those values in shake?
or how to map 16-235 DV values to 16-235 RGB?

the best i have managed to do is pull the highlights down in FCP in a DV sequence to sub-100% values (with a 3way corector) and then export as uncompressed 4:2:2 10bit movie.
however, this is a) cumbersome and b) it changes the pixel structure slightly, which i'd like to avoid since i want to use the 4:x:x enhancer in shake.

btw, exporting as an image sequence creates 235 clamped 8bit RGB files (png and tiff) and obviously i'd like to avoid that too. i've also tried the None16 QT codec (which is lossless 16bit) but got weird brightness/gamma shifts.

++ christoph ++

[user_deleted]

Hey Christoph,
I think you are doing it in the correct way. There are many confussion about passing from the RGB to the YUV color space, superwhites, gamma, etc in QT, Final Cut, Shake, etc, but the think is that you can not map16-235 YUV to 16-235 RGB. This is nothing to do with QT or any other software. Is a matter of the specs of the Digital Video. The people of the CCIR, SMTP, UER, etc (the ones that have developped the international standars) have decided that. I do not now the technical reasons. Is not dificult to understand: 0 in RGB is 16 in YUV, and 255 in RGB is equal to 235 in YUV. Forget about superwhites. There is not room for them in a video system.
We talk about digital video, but don't to forget that video is an analogic signal and this imposes its constrains.
Another wide spredded missunderstanding is about the bitdeepth. Many people think that working in 16 or 32 bits will give you the chance to manipulate a wider signal keeping the superwhites etc. When you work with 16 or 32 you can make more accurate calculations. You get more intermediate values, but the higher and the lower value you are manipulating are the same. If you have a potatoe, you can cut it in 8, 16 or 32 pieces, but in the end you have got the same potatoe.
In the oder hand I've been reading a lot of message in forums where the people talk about those problems, the people is very scare of color correcting in Final Cut. I think is a mistake, mostly when you can enjoy the only realy essential too to control your video signal: The videoscope.
Sorry for my English.
Rafal

[user_deleted]

hi rafal,

thanks for your comments but i think you missunderstood what i want...
i'm not trying to broadcast the superwhites, i just want them available to color correct instead of just throwing them away... the final clip would only have leagal values in it.
problem is, that once outside of fcp i cant access the values anymore because the quicktime engine clips them upon import... btw it is possible to map 16-235YUV to 16-235RGB. AVID (as much as i dislike it) has a checkbox fo exactly that in it's import and export functions.

color correcting in fcp would be an option for me (although a cumbersome one), if there was a way to keep the DV compression intact, but unfortunately it will try to smooth the chroma, which i dont want because i'd like to have the original data to manipulate in shake.

from some discussions and comments from gav in other threads, it seems that this is a fundamental limitation in the way shake interacts with YUV quicktime files and there's not much we can do about it (but hope it will be fixed in shake mark II

++ christoph ++

[user_deleted]

You want to access details in the blown out footage? Any chance you can get is as OpenEXR sequence? This format is designed to exactly what you want to do. Getting your source footage re-exported with all the fstops in it may not be possible however.

hope this helps,

jon a

[user_deleted]

QUOTE(phosvfx @ 07/17/06, 11:16 PM) [snapback]242698[/snapback]
You want to access details in the blown out footage? Any chance you can get is as OpenEXR sequence? This format is designed to exactly what you want to do.

hey john,
not sure if my original post was very clear, so let me try to explain again:

the so-called superwhites in video is the range 235-255 (in 8bit YUV values) which is actually "illeagal" for broadcast because a value of 235 will be already 100% white (ie 255 RGB). but some cameras (specially DV) let you record data over 235, meaning that they won't just clip any data over 235 but keep extra detail up to 255.
now, if color correcting in fcp (and most other editing systems) you can access those values and bring them down to "leagal" numbers, which means that highlight areas which are usally just flat clipped white spots get a more gentle roll-off and keep more highlight detail.

problem is that the quicktime importer in shakes clips YUV footage at 235 in the file-in, which means no matter what you do you cant access the superwhites. bringing them down in another app (like fcp) will work, but is a lot of hassle and introduces chroma smoothing that i don't want (yet).

anyway, it seems that it just wont work in the current form of how shake and quicktime interacts, which is understandable because the program clearly wasnt designed for crappy DV footage, but on the other hand it's a pitty because it's quite important to get the most out of said footage if you want to make a film-out.

++ christoph ++

[joojaa]

Cant you ask fcp to export a sequence of rgb images such as TGAs or something instead of qt?

[user_deleted]

QUOTE(Joojaa @ 07/18/06, 08:34 AM) [snapback]242734[/snapback]
Cant you ask fcp to export a sequence of rgb images such as TGAs or something instead of qt?

you can, but as said in the first post, this will clamp it to 16-235 before output as well...
as said, you could bring down the superwhites with a color correction filter in fcp before export, but unfortunately fcp does all RGB processing in 8bit only, which means you'll have to cramp a 0-255 range into a 16-235 range, which then gets expanded to 0-255 again, all in 8bit. not exactly what i'd want to do.
++ christoph ++

[joojaa]

Hmm... sounds like this is a problem of fcp realy more than shake. Have you tried using some other programs to export the images to a sequence. Atleast it works fine on a qtpro on windiows, now that i try.

Personaly i allmost never deal with video footage myself.

[user_deleted]

QUOTE(Joojaa @ 07/18/06, 12:01 PM) [snapback]242747[/snapback]
Atleast it works fine on a qtpro on windiows, now that i try.

hmm.. i very much doubt this.. QT pro clips the super whites as well, even on display - that might actually be the reason why you think it works, you'll never see the superwhites unless you have an app which handles YUV files natively. so yes, a app which bypasses quicktime altogether might be a solution.. i just havent found it yet (AVID comes to mind, but it's kinda expensive and i dont like it).

++ c.

[joojaa]

Nope superwhites are there, but to be honest the footage never gets turned to yuv when i capture it as i appear to have asked it to capure rgb directly. But hey im not on mac so... BUt yes i know the superwhites i get arent entirely reliable just because the camrea isnt realy trying to capture them ite more of a fluke anyway altogh ccds cameras realy work in rgb space.

Still i dont have the entire rgb range. but far more than normal yuv, but i supect its more my crap camera than anything else