Negative values can occur in ACES files (and other floating point formats where they are allowed). Seeing negatives can be unnerving, but they are actually quite common to see in floating point image formats and IDTs from most camera manufacturers will result in some negative values even with “normal” images.
There are two main contributors that can cause cameras to produce negative ACES values from an IDT:
It is common for camera manufacturers to set the mean of their camera noise floor to map to zero. This means roughly half of all “black” noise will make pixel values with negative components.
Another cause is simple colorimetric error in the camera mapping of tristimulus inputs. Camera images are captured through color filter arrays that have spectral curves different from the color-matching functions. The mapping to colorimetry will thus have residual errors and can create one or more negative channels. In a camera’s native RGB space, these may or may not be negative, depending on the encoding primaries used. In any RGB encoding space, negative values simply indicate that a pixel value projects outside of the triangle formed by the RGB primaries of the encoding gamut.
To help illustrate, below is a CIE 1931 x,y chromaticity diagram showing values sampled from a real image (the “SonyF35.StillLife.exr” image from the ACES developer ‘images/aces’ directory). You can see there are pixel values that project outside of the AP0 encoding primaries. I’ve labeled each area of the diagram to show whether the RGB’s would be positive or negative for each section defined by extending a line along the sides of the encoding gamut triangle.
it’s as i suspected, but i’m only a humble colorist not a color scientist… so can only make guesses with no real foundation other than “feel”
I see much more of this with Epic and Dragon sources than in ArriRAW sources
i have not seen negitive pixel’s in the film i’m gradeing currently with ArriRAW sources, this also the first film with 1.02, and i was not sure if somehow the negitive pixel values had gone away magicly wit the release of 1.02, but it seems it’s down to the Alexa being an Alexa, and the Dragon used for this test being a Dragon…
In the second situation you describe, do you agree that these negative colors can be safely clipped? They represent impossible colors and are the result of errors.
I loaded the SonyF35.StillLife.exr in Nuke, converted from ACES to CIE-Yxy and ran a CurveTool on it to find the highest and lowest pixel values. I got (0.005, 389.187, 411.856) for the highest and (0.004, -758.278, -387.636) for the lowest. These values are so far way from the locus, they wouldn’t even show up on your graph!
I can use a levels effect in Vegas Pro to ‘lift’ it into range, but of course the rest of the footage it all white now:
Is there a way to cut out or clips that button end out completely? How would one deal with this kind of issue? When I turn off ACES and just use standard 32-bit floating point, these just disappear. Thanks for your time.
Okay, I may have resolved my issue by using a new ACES RRT (Rec. 709) transform instead of the Standard Rec. 709 transform. I’m still curious why the other transform seems to show these super black values from a Rec. 709 camera, but I’ll have to experiment with this new RRT and so far the resulting output is the same, minus the bad black areas!
I’m new to this ACES thing, but I can see the benefits are huge. I just hope 3rd party NLEs continue to support new versions of ACES. It’s the Academy’s best kept ‘secret’.
I’m working on a project that’s going be broadcast on tv, and one of the shots has neon lights (orange and blue/teal), i’m seeing these negative values on brightest parts of the neon lights.
@sdyer I think i might found a solution at the moment, i changed the IDT to Sony S-Log3, although it was shot in S-Log2. Somehow i don’t see the negative values on the neon lights. Am i doing it right?