Negitive pixel values?

workflow
Tags: #<Tag:0x00007febccc869b8>

(Dermot Shane) #1

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.


(Scott Dyer) #2

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:

  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.

  2. 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.


(Dermot Shane) #3

Thanks very much Scott,

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…


(Francois Lord) #4

Hi Scott,

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!


(Dermot Shane) #5

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?


(Jonathan Lantz) #6

Hey Scott. I think I am dealing with negative/super black. In the screenshot below I can see artifacts:

They appear to be the line circled below:

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.


(Cary Knoop) #7

Scott, you write:

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?


(Jonathan Lantz) #8

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’.


(Qusai Nofal) #9

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.

I’m using:
Resolve 12.5 in ACEScct
Sony a7s ii in S-log2 as an IDT and Rec709 as ODT

Any help, thanks.


(Scott Dyer) #10

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?


(Qusai Nofal) #11

Thanks for the reply, the frames i provided earlier were screenshots from DaVinci color page, i’ll attach the OpenEXR files below:


(Scott Dyer) #12

I’ve received the files, but so far haven’t been able to reproduce the issue with CTL.

It appears the OpenEXRs you sent are S-Log2, so here is my processing chain:

OpenEXR data > IDT.Sony.SLog2_SGamut_Daylight_10i.ctl >
RRT.ctl > ODT.Academy.Rec709_100nits_dim.ctl

My neons are not showing negative values. They also seem to be less “blocky” than yours do. Any idea why that might be?


(Qusai Nofal) #13

Hi @sdyer, not sure why my neons are showing negative values.
Here’s my processing:

Color Scienece: ACEScct

The ODT: REC 709

The IDT: S-Log2


(Qusai Nofal) #14

@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?