i am working on a technical evlauation of a workflow, one of the partners sent me this note;
I figured I should let you know that there is some negative values in the files you provided me.
For example the filename:
ISO_500_F_7_1_SS_30_T_3200_Comp_6_Cam_top_ND_0_CS_01.exr
pixel at position 204 4027 in the blue channel has a value of -4.4823e-05. Obviously negative light values does not exist…
Something wrong must be happening during the export.
.
i am used to sorting negitive pixel values when gradeing in ACES, and have not looked at the options -or- how to avoid in the first place, i just work around it
the camera is RED Dragon, it was debayered in Resolve 12.5.3 with ACES 1.02 , exported camera default + metadata = exposure/temp with no ODT to EXR half float
any thoughts would be apreacated and will forwarded on to the other folks involved.
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.
So, for example, the pixels projecting to the top right of the diagram - outside the AP0 triangle (and also the spectrum locus) - would have a negative blue channel.
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 use clipper / shadows when negitive pixels showup, at the minimum value the software allows - sorts the issue, harder part is finding them all, they can be pretty subtle on screen
i do see this more with RED camera’s than with ArriRAW or SonyRAW, but nothing scientific - only impressions
And it seems it should be confined to linear data only? if the source is display referd already like LogC then they could not exist?
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.
1) 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.
That is right, I noticed that with various cameras.
I have a question about that, especially for ACEScct. Would it make sense to clip below zero (or even slightly above this) before applying a color correction?
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’.
Hi @sdyer,
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.
You are seeing the negative pixel values on output?
To figure out what’s going on, I’ll need to know the starting values. Any chance you can send me either this frame or the neon crop of this frame as the original S-Log2 or as ACES OpenEXR?
@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?