Different ACES color rendering in various software packages

(Colorful Penguin) #1

Hello friends,

I have footage from RED Dragon 6K camera. I debayered it using latest Redcine-X using ACES color science to linear OpenEXR files. Inside Redcine-X you cannot specifiy to which ACES color space it debayers the footage, but I assume it is be linear ACES AP0.

My problem is that different software packages render this frame in different way. In the background there is a bluescreen which contains multiple negative values and various software packages handle these negative values in a different way. It is even more visible when I raise the exposure.

This is how it look inside Krita:

This is how it look inside mrViewer:

This is how it looks inside Nuke:

This is how it looks inside Nuke, when I clamp negative values to 0:

As you can see, Nuke displays it the same way as mrViewer, but when clamped it looks the same as Krita.

So now this problem leaves me wondering which software is displaying this image correctly. Is it Krita or mrViewer/Nuke?

Thank you very much for any help or advice :slight_smile:

Have a nice day

(Colorful Penguin) #2

Here is the original debayered frame from Redcine-X (downscaled to Full HD) :slight_smile:

(Scott Dyer) #3

But you are comparing the ACES OpenEXR unrendered, correct? So it’s not going to look like that when put through a rendering anyway. The differences you’re seeing are due to how the different software packages decide to show negative pixel values. Some clamp to zero and others may do other things. What do negative pixel values in your ACES image even mean? (See this post.)

On my MBP, Apple Preview renders the OpenEXRs like this:

OpenEXR Normal (Apple Preview)

OpenEXR +2 stops (Apple Preview)

OpenEXR +4 stops (Apple Preview)

What you really should care about is what the image looks like through an ACES rendering. Negative pixel values should be handled consistently by the rendering. I took your original file and the 2 stop increments and sent them through the RRT/ODT to sRGB.


ACES (+2 stops) thru RRTODT for sRGB

ACES (+4 stops) thru RRTODT for sRGB

As you can see the blue screen is pretty consistently blue.
You do get a little bit of purple fringing on the car door and around the head in the +4 shot but you also have a ton of noise.

(Colorful Penguin) #4

Scott thank you very much for your reply, I read throught that thread before, but to be honest I am not sure what these negative values mean. I got this frame straight from Redcine-X without any modifications, do you think I can clip them?

And all the screenshots I posted were viewed through RRT and sRGB ODT (as you can see in the top left corner of Nuke), that’s why I don’t know what to do since I think this is how would they look even when rendered out.

And these images you posted in ACES thru RRTODT for sRGB are beautiful. I get the same results for all parts of the image, but in the bluescreen area I always get these weird artifacts.

My images look nearly the same as yours in “ACES (+2 stops) thru RRTODT for sRGB” except for the bluescreen.

(Colorful Penguin) #5

Sorry, the previous images do not look the same, here is correction:

my version of ACES (+2 stops) thru RRTODT for sRGB:

my version of ACES (+4 stops) thru RRTODT for sRGB:

as you can see they look pretty similar to yours, except for the bluescreen areas. What kind of magic did you do that it looks such great? :slight_smile:

(Scott Dyer) #6

Simple answer - I didn’t use LUTs. My images are processed through the CTL reference.

I sampled the “blue” values from a couple of places (e.g. outside rear window, region between his arms, above his head, etc.) and plotted the chromaticities of the values. As you can see they fall outside the spectrum locus. Without a rendering these are either being colorimetrically clipped in to the blue corner of the sRGB triangle or more likely is that most of the tools are just naively showing “RGB” data without any smarts about the encoding.

There is extreme noise in this image as evident from this chromaticity plot of all your image data points. I don’t know what clipping would do to this noise.

(Colorful Penguin) #7

Thank you very much, that is pretty interesting. How do you think could this happen? Do you think it could be some bug of Redcine-X software? Is there some way how I can correct it?

But to be honest bluescreen areas are not really that important to me rendering-wise, they would have to be removed. I was just worried that there can be more errors like that present in the color pipeline. Do you think these negative values can have some negative impact on keying process?

(Scott Dyer) #8

The noise or the blue/purple issue? If noise, to me this looks like the camera was under-exposed.

I would think that depends on what color space you’re using to generate your key. I’m not sure whether these keying tools use the rendered image or the underlying data. Perhaps someone who has more bluescreen experience can weigh in?

(Colorful Penguin) #9

Thank you very much for your answers :slight_smile: I was aware that underexposed camera raises amount of noise in image but if I understand correctly it also causes that the pixel values “run” outside of the spectral locus?

I am 99% sure that the keying tools use the underlying data. In that case I assume I need to hope that they would also work fine even with negative values… :slight_smile:

And do you think there is some way how I can display this image in softwares such as Nuke, Krita etc. the same way as you did? Without these artifacts in bluescreen?

(Thomas Mansencal) #10

Absolutely, and your frame is here highly under-exposed, like 3 stops to get everything in a sensible range.

Most of them use LUTs in a way or another so they will likely be subject to the same artefacts.

(Nick Shaw) #11

Can you post a single frame R3D of the image?

It looks like the entire blue screen area has CIExy coordinates of about [0.12, 0.02] which is outside the spectral locus, as @sdyer said.

Can you say what was used for the blue screen, and how it was lit?

(Colorful Penguin) #12

Thank you all for all the insight I really appreciate it.

Here is the R3D file:

To be honest I am not sure what type of bluescreen was used and how it was lit. We shot it few months ago and our DOP took care of all the lighting but I don’t know the details. Could inappropriate bluescreen and lighting cause such an issue?

(Gavin Greenwalt) #13

Just loaded the R3D with the r3d metadata settings in Redcine 50.43 and rendered off an EXR. No negative values.

Ran it through the ACES OCIO 1.0.1 pipeline and it rendered properly. Did you modify the metadata? It also doesn’t render nearly as dark as the provided EXR?

(Nick Shaw) #14

The values are negative in ACEScg (Nuke default working space) not ACES2065-1

(Colorful Penguin) #15

I did not modify the metadata. As @nick said, they are negative in ACEScg color space (inside Nuke using OCIO 1.0.3). Do you think there is something what can I do to fix it?

(Nick Shaw) #16

When I down-scale the image, to reduce the number of points to plot, it has the effect of reducing noise as well. This makes me think that the majority of points outside the spectral locus on @sdyer’s plot may be in the noise in the shadows, which is not unexpected on an underexposed image like this.

So the significant out of gamut pixels are all in the blue screen. Depending on how the keyer handles these, they may not cause a problem. I haven’t tested, but it might be worth trying the key in ACES2065-1 instead of ACEScg, so everything stays positive. It could also be worth trying a matrix which moves the primaries, like the “neon highlight fix” @sdyer has posted elsewhere.

Negative values, although they don’t actually represent the real world scene colours, can often occur with digital cameras, as no 3x3 matrix based IDT is perfect, and the matrices tend to be optimised to minimise errors in skin tones. This results in larger errors in other colours. Clamping early in the pipeline is not advisable, as the negative values, although not “correct” still contain useful image data, which the user can decide how to handle. Clamping as a last step before the output transform is reasonable, but make sure you are only clamping negatives (the default clamp node settings in Nuke also clamps >1.0).