Color Temperature Correction... available?

[manuelsongokuh]

sorry if i can ask, there is correction for "balance white"?

[manuelsongokuh]

in kdenlive have it , easy to use..if you want to show how kdenlive use or no?

[manuelsongokuh]

see example

[olear]

Saturation?

[manuelsongokuh]

not, is not saturation, it's temperature color..see example: https://userbase.kde.org/Kdenlive/Manual/Effects/Colour_Correction/White_Balance

[manuelsongokuh]

it's problem from light hot (yellow)and light cold (white) this is correction temperature particula..

[manuelsongokuh]

see example information "color temperature" https://filmcameracourse.wordpress.com/2012/05/31/720/

[olear]

Grade node?

[manuelsongokuh]

here information details: http://www.scantips.com/lights/whitebalance.html

[manuelsongokuh]

problem is from error light neon and light halogen, so needs "automatic to correction" in kdenlive has it. you can try kdenlive and white balance and try slider mouse ok?

[manuelsongokuh]

from RED (profesional camera) http://www.red.com/learn/red-101/color-cast-tutorial

[manuelsongokuh]

i'm upload video screen record, please wait for upload, you can see my video screen record ok? not close issue a moment ok?

[manuelsongokuh]

here video record screen: https://mega.co.nz/#!XxkFBYRA!T1fnl344HRqTC8jUNi7vu4IrPZLCVLEjnbqaQMxp4-I

[manuelsongokuh]

@olear DId you see my screen record?

[manuelsongokuh]

there is good information for code in colour temperature: http://www.tannerhelland.com/4435/convert-temperature-rgb-algorithm-code/

[sobotka]

This isn't as simple as one would like to believe given the underlying architecture.

Color temperature is an adjustment along chromaticity.

RGB, the internal tristimulus model that Natron and other imaging tools leverage, only communicates intensity, while communicating absolutely nothing about the chromaticity of the primary lights. That is, the chromaticity is based on assumptions and is never communicated directly. OpenColorIO, the library that Natron leverages for color management, also follows this design theory in its current implementation.

If you examine the default Nuke OCIO configuration, you will see a simple 1D LUT for the sRGB transform. That is, it assumes the artists wishes for a display linear representation of the image in question, and inverts the display referred image to display linear based on the canonized sRGB transfer / tone response curve.

As such, it is impossible to provide an accurate means to change colour temperature via a Bradford, Von Kries, CIECAT02, XYZ scaling, or like approaches as there is no fundamental way to know what the chromaticity coordinates of the individual RGB channels are. Further still, there is no method within OCIO's current API to glean the chromaticity information required.

It is feasible that a node could be implemented with the appropriate chromaticity coordinate input values for any given colour space, however it would likely break many pipelines where the information is incorrect.

One viable approach is to implement an OCIO role of "XYZ" that provides matrix transform for XYZ within a given pipeline, which Natron would be able to leverage for a proper chromatic adaptation.

[MrKepzie]

Hi Troy,

Can you point us to any white paper(s) explaining the reasoning behind your statements so that our minds are a bit clearer on this ?

Thank you,

Alex

On 24 Oct 2015, at 20:46, Troy James Sobotka notifications@github.com wrote:

This isn't as simple as one would like to believe given the underlying architecture.

Color temperature is an adjustment along chromaticity.

RGB, the internal tristimulus model that Natron and other imaging tools leverage, only communicates intensity, while communicating absolutely nothing about the chromaticity of the primary lights. That is, the chromaticity is based on assumptions and is never communicated directly. OpenColorIO, the library that Natron leverages for color management, also follows this design theory in its current implementation.

If you examine the default Nuke OCIO configuration, you will see a simple 1D LUT for the sRGB transform. That is, it assumes the artists wishes for a display linear representation of the image in question, and inverts the display referred image to display linear based on the canonized sRGB transfer / tone response curve.

As such, it is impossible to provide an accurate means to change colour temperature via a Bradford, Von Kries, CIECAT02, XYZ scaling, or like approaches as there is no fundamental way to know what the chromaticity coordinates of the individual RGB channels are. Further still, there is no method within OCIO's current API to glean the chromaticity information required.

It is feasible that a node could be implemented with the appropriate chromaticity coordinate input values for any given colour space, however it would likely break many pipelines where the information is incorrect.

One viable approach is to implement an OCIO role of "XYZ" that provides matrix transform for XYZ within a given pipeline, which Natron would be able to leverage for a proper chromatic adaptation.

— Reply to this email directly or view it on GitHub https://github.com/MrKepzie/Natron/issues/829#issuecomment-150840506.

[sobotka]

Greets @MrKepzie, we met at SIGGRAPH 2014.

There aren't any white papers per se as this pertains to basic colour management theory.

Natron would need to handle any number of colour spaces due to the varying number of cameras, working spaces, etc. present in motion picture work. These are all modeled under a tristimulus approach.

Take a display referred value such as RGB(0.8, 0.7, 0.4). The values may be identical given an ACES, sRGB, AdobeRGB, or like space, but represent radically different colours based on the space they reference; we are communicating nothing about colour (chromaticity) through this triplet, only intensity. The exact same applies for a scene referred value such as RGB(32.8,1022.5,384.1); intensity is communicated, but nothing about colour in an absolute sense.

Consider RGB(3.0,0,0). What colour red is it? It is an identical colour as RGB(18.7,0,0), but we still don't know what colour it is!

OCIO provides no mechanism to glean the chromaticity coordinates of the underlying RGB primaries, leaving the transformation space selection up to a particular pipeline. This is relevant because in order to perform a colour temperature transform, one must know the underlying chromaticity coordinates for the RGB primaries and white point.

Natron cannot simply hard code values for say, an sRGB based set of primaries, as the entire pipeline would break should a pipeline choose to use a different OCIO config set with DCI-P3 based primaries as the reference space, for example.

There are a few potential methods to work around this, such as providing a role for XYZ which could a well documented transform matrix to XYZ under a given colour temperature for white. From here, Natron could seek out the role in a set of OCIO configs and leverage it to properly adapt between the arbitrary base primaries.

I hope this helps to shed a little light on an otherwise confusing topic.

[manuelsongokuh]

hi @sobotka

good information, but i ask you: why many software video-editors,compositors, have function "White Balance" ? kdenlive has it "White Balance" adobe-AE has it "White Balance" adobe-premiere has it "White Balance" apple finalcut pro has it "White Balance" apple motion has it "White Balance" sony vegas has it "White Balance" openshot has it "White Balance" MAGIX Video Pro has it "White Balance"

so if natron will new node "White Balance" then people (new user) can use as fast to fix video.. so if natron will new node "White Balance" then it is fast ro use it in natron..

@sobotka did you see my link video example? https://mega.co.nz/#!XxkFBYRA!T1fnl344HRqTC8jUNi7vu4IrPZLCVLEjnbqaQMxp4-I i make with kdenlive very fast for find good color...instead natron long long time.. there is different a lot..(compare kdenlive vs natron..)

this mean EAST TO USE IT AS READY TO USE NODE "WHITE BALANCE"..this is for NEW USERS. instead for user expert: use from "..need to handle any number of colour spaces due to the varying number of cameras, working spaces, etc...." this is long long time long time for "HANDLE" or not?

you information is right but it's for expert user.. and not for newbie user.. i'm doubt pf this for NEWBIE USER...uhmm..

[MrKepzie]

@manuelsongokuh We aim to provide a solution for expert users, implying doing research and innovating with technologies not necessarily present in other software packages. Please do not use caps lock if you want people to read through your messages. You can use the grade node which already allows you to control White point.

@sobotka Thank you for the explanation, it made it a bit more clear. So If I get this right, we need the user to input the color temperature for white, and process everything in XYZ space and then convert back to the original colorspace. What I’m missing is why the current XYZ Lut in the Blender OCIO config not sufficient for such conversions ?

Anyway we will look into it whenever we get the time for it (or if someone wants to contribute it;))

Edit: Oh and I remember meeting you at Siggraph last year;) Nice to see you again around here;)

[manuelsongokuh]

@MrKepzie ah i'm sorry for CAPS LOCK.. i want to caps like important argument and not emotion (angry or abuse. ok?) i'm stupid when i write..ok, i'm sorry..

[sobotka]

@manuelsongokuh All of the examples you gave are non linear editors, not image manipulation tools, and many are consumer / hobby grade tools at that. Further, a good number of those tools suffer from well documented colour deficits, including an outright ignorance of colour management.

You will have to accept that I have a bit of experience on this front and if you read through precisely what I wrote above, you would be able to see where KDEnlive's colour handling will fail miserably, even with the entry level imaging that it affords.

As you likely well know, colour transforms are of absolutely critical importance to maintain pixel fidelity through a pipeline. If you would like to review some of your knowledge regarding colour theory, the Visual Effects Society's white paper "Cinematic Color: From Your Monitor to the Big Screen (PDF 6.6M)" at CinematicColor.

@MrKepzie OCIO doesn't enforce protocols or mandates in the architecture, other than the fact that there is a "Reference Space."

In the case of Nuke for example, the 1D LUT present for sRGB is simply an inversion of the display referred tone response curve. That is, there is no change in assumed chromaticity, and as such, we can say that the default Nuke reference space has primaries that are sRGB / REC.709. Assuming that the imagery that comes in is based on the specification of sRGB, we can also infer that the white point is the canonized D65.

The only method to perform chromatic adaptation on tristimulus RGB values is to transform the RGB data through XYZ and back to RGB. This is impossible to achieve without knowing the positions in XYZ of the primaries, which as discussed, is unknown and not enforced with OCIO.

Providing an OCIO role for XYZ would permit such operations, and Natron could quietly issue an error when a configuration doesn't have the provided XYZ role. It must be remembered that various artists / pipelines will be replacing the default OCIO configuration and all of the implied assumptions / transforms within it.

Regarding the Blender OCIO configuration, a healthy dose of skepticism regarding that configuration is in order, considering the hand crafted ACES transforms and other workarounds that were required for their Tears of Steel project.

If we examine the XYZ transform, we don't know much about where the original white point is, nor if it is even correct. The transforms points to an srgb_to_xyz.spimtx, which tells us it is a matrix. It is this matrix:

0.4124564  0.3575761  0.1804375  0
0.2126729  0.7151522  0.0721750  0
0.0193339  0.1191920  0.9503041  0

The second line shows us the canonized sRGB luminance values (the Y position) and therefore we can see that it is a pure sRGB / 709 primary to XYZ transform under D65.

This would be sufficient information for performing a chromatic adaptation, however in the bigger picture, Natron would need to have something akin to this piece of information for every potential OCIO configuration. Hence why providing a mandatory XYZ role would be an easy check from within Natron, and assert that the color temperature node would work properly, assuming any given pipeline adds the correct XYZ transform and role entry into the configuration file.

Given the XYZ transform, a chromatic adaptation can be accomplished by converting to the LMS domain via a Bradford matrix. Further information can be found here.

It should be noted that colour wheels / pickers will also likely be incorrectly rendered if they aren't colour managed, and as such, it is worth reviewing the Natron code for these issues. I prepared an OpenColorIO configuration test with a test image to demonstrate OCIO colour management breakage that as been used to test several OCIO applications. You can find the configuration here. It will quickly reveal breakages in any colour managed system simply by loading the included sample EXR.

If I could get Natron to compile, I might be able to help diagnose these things, but sadly there isn't a CMake based configuration and the existing configuration has already taken up more time than I would like to get a working compile out of it. Perhaps this will be addressed in the future.

[manuelsongokuh]

@sobotka thank you for big clarity and information very helpfully.. thank you

[devernay]

This issue was moved to NatronGitHub/Natron#110