Impossible Color matching FX shots outputted in DPX?

[Blair Erickson]

I have 3 FX shots that were sent to the production house and returned to me as DPX frames. When I try to match them back into the sequence, by importing them into Color (since FCP doesn't natively import DPX what the heck) I find a whole new nightmare. Matching the Red footage natively shot, the ISO, the temperature, etc seems impossible. It's always "close" but never exactly the same. It doesn't look at all the same and since some of these FX shots are 30 frames in a sequence lasting two to three minutes, what is left is a jarring color pop during moments of special effects.

If I output the raw files in the entire sequence as DPX and try importing them all into Color, the frames that have been CGd all appear black. For some reason they WILL load in After Effects but not in Color. Ultimately I'm left with a lot of pieces and a lot of work trying to re-insert a few frames back into my FCP edit.

Is there any way to resolve this challenge?

 

[Ben Brainerd]

FX matching is always kinda tricky. Depending on the software used, and color profiles, and any number of other features, it's possible that you'll get some subtle gamma/color shift.

My first bit of advice probably isn't helpful, since you've already received the FX shots, but here goes: Test first, test always. Little "gotchas" like this are why you want to run tests through all the parts of your workflow, so you can catch issues and resolve them or find workarounds.

Since you've already taken delivery of the shots, um... Buy your Colorist a case of beer and a couple dozen cookies? A decent Colorist should be able to eliminate, or at least minimize, the color differences you're looking at.

 

[Dan Hudgins]

Gone

Gone

I have 3 FX shots that were sent to the production house and returned to me as DPX frames. When I try to match them back into the sequence, by importing them into Color (since FCP doesn't natively import DPX what the heck) I find a whole new nightmare.

...


Is there any way to resolve this challenge?

If the FX shots have had their original R3D data clipped off during CC for the FX work, then you cannot get the lost data back, its gone.

Then the only way to match is to clip the other R3D shots to match the clipped FX shots by clipping the other shots in the same way.

If the FX shots have not been clipped, then my software's CC or any good program that lets you adjust the curves in detail should let you match the two, but if the FX shots were filtered, those filters can change pixel groups rather than just single pixels, so in that case the other footage would also need to go through the same filters to match, do you know what was done to the FX footage? Even just chroma adjustments can filter more than one pixel in some software, and you cannot match pixel group filters with single pixel CC adjustments.

Also if they used a 3D-LUT to remap the color gambit you may need to use that 3D-LUT and the same software since using 3D-LUT in another program may not match exactly as has been shown, because there are small differences in the way 3D-LUT are interoplated in various programs that use them.

 

[Rui Xavier]

Dear sirs,

FX or not FX what Blair is referring to is a far simpler although deeper problem in Apple's Color that me and a friend have bumped into a couple of days ago while trying to finish a job, and still couldn't find a workaround...

Let's say you've done a color grade of R3D files (using a 3D LUT for film out) and export your clip as DPX. Then try to import the DPX files back into Color. As soon as you import the Color originated DPXs, and then you import the same 3D LUT you had before, the same image looks darker!!!
Something is not behaving properly when Color is exporting R3Ds as DPX... Try it with any other material other than R3Ds and you'll find that it works ok. The DPXs go in and out and look the exactly the same as they're supposed to.
Now what we found more intriguing is that once you turn of the Red Tab in Color (and in doing so loosing the ability to choose a white balace, gamma space, color space, iso setting etc.) and only work with primary and secondaries to do your grade of the R3Ds, than you can export and import the DPXs and it all works properly... So to our knowledge and observations the problem seems to be an error on the implementation of the R3D SDK on the Red Tab in Apple Color... This issue was briefly discussed on this thread

http://www.reduser.net/forum/showthread.php?t=35242

and some numbers of gamma correction were given to reverse the error induced, in our opinion, by the Red Tab. We tried them out but none of them really worked. The image came close but not quite there... and for us this is not good enough...
It doesn't seem to be only an error of bad gamma on the header of the DPX or something that you can reverse only by inputing an inverse gamma.
We urge you to try it out with any of your R3Ds and share your thoughts with us.

 

[Dan Hudgins]

Cineon

Cineon

There is a problem with DPX/CIN files in general.

DPX files can be saved in two ways for the 10 bit log,

A) Do not clip and range data black to white as 0 to 1023 data values.

B) Clip black at 95 and white at 685 data values.

So in addition to the gamma shift, you need to know does the gamma adjustment start a level 0 or level 95 and does the gamma adjustment end at level 1023 or 685!

What a mess, that's way I started using video gamma TIF 48bpp files, no uncertainty about there the tones are, and no shifts on load or save.

Some progams may clip or scale DPX on save to avoid the shadows and highlights being off the ends of the curve when loaded into a program that expect black at 95 and white at 685.

One way the image looks gray and the other it looks blasted, adjusting the gamma will not fix the problem since you need to adjust THREE values, black level, white level, and gamma, and in some cases break points.

I am working on DPX support for my de-Bayer program that will also CC output from REDCINE etc, so I have been checking these issues.

To make it more complex, it seems some programs reverse the red and blue, and get the endian wrong in in the header or data or both!

I know people like the 10 bit log DPX because they are smaller than 48bpp TIF, but for digital images the range of 95 to 685 is not enough for heavy grading, it was to give film scans more range in the old days of high cost storage, today I still think video gamma 48bpp TIF make ones life easer since everyone will see the same thing more or less from the same file.

See these links,

http://en.wikipedia.org/wiki/Cineon

Quote: [Conversion to computer displays or to video typically involves the notion of the "black point" and "white point" used for conversion to more limited range video signals. Conventionally, these points are 95 and 685 on the 0-1023 scale (but should be adjusted based upon actual negative content). Pixel values above 685 are "brigher than white", such as the sun, chrome highlights, etc. The concept of a 'soft clip' was introduced to make the rolloff of whites more natural. Pixel values below 95 represent black values exposed on the negative (the clear base of the film). These values can descend in practice as low as pixel values 20 or 30.]

http://en.wikipedia.org/wiki/Digital_Picture_Exchange

http://www.cineon.com/ff_draft.php

http://www.imagemagick.org/script/motion-picture.php

Quote: [For a 10 bit logarithmic image where each color component value ranges from 0 to 1023 the black and white points are normally set at 95 for black and 685 for white. What this means is that the logarithmic file stores color values that are lighter than what the linear version will display as pure white and darker than what it will display as pure black. This extra information therefore remains available for an effects artists who might wish to alter the brightness of the image after it has been stored as a DPX file.]