Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TSL: Add CDLNode #29510

Merged
merged 7 commits into from
Oct 3, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/nodes/Nodes.js
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,7 @@ export { default as UserDataNode } from './accessors/UserDataNode.js';

// display
export { default as BumpMapNode } from './display/BumpMapNode.js';
export { default as CDLNode } from './display/CDLNode.js';
export { default as ColorSpaceNode } from './display/ColorSpaceNode.js';
export { default as FrontFacingNode } from './display/FrontFacingNode.js';
export { default as NormalMapNode } from './display/NormalMapNode.js';
Expand Down
1 change: 1 addition & 0 deletions src/nodes/TSL.js
Original file line number Diff line number Diff line change
Expand Up @@ -84,6 +84,7 @@ export * from './accessors/VelocityNode.js';
// display
export * from './display/BlendMode.js';
export * from './display/BumpMapNode.js';
export * from './display/CDLNode.js';
export * from './display/ColorAdjustment.js';
export * from './display/ColorSpaceNode.js';
export * from './display/FrontFacingNode.js';
Expand Down
83 changes: 83 additions & 0 deletions src/nodes/display/CDLNode.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
import TempNode from '../core/TempNode.js';
import { Fn, nodeObject, vec3, vec4 } from '../tsl/TSLBase.js';
import { max } from '../math/MathNode.js';
import { LinearSRGBColorSpace } from '../../constants.js';
import { ColorManagement } from '../../math/ColorManagement.js';
import { Vector3 } from '../../math/Vector3.js';

/**
* Color Decision List (CDL) v1.2
*
* References:
* - ASC CDL v1.2
* - https://blender.stackexchange.com/a/55239/43930
* - https://docs.acescentral.com/specifications/acescc/
*/
class CDLNode extends TempNode {

static get type() {

return 'CDLNode';

}

constructor( inputNode, slopeNode, offsetNode, powerNode, saturationNode ) {
donmccurdy marked this conversation as resolved.
Show resolved Hide resolved

super();

this.inputNode = inputNode;
this.slopeNode = slopeNode;
this.offsetNode = offsetNode;
this.powerNode = powerNode;
this.saturationNode = saturationNode;

// ASC CDL v1.2 explicitly requires Rec. 709 luminance coefficients, without input conversion to Rec. 709.
this.luminanceCoefficients = ColorManagement.getLuminanceCoefficients( new Vector3(), LinearSRGBColorSpace );

}

setup() {

const { inputNode, slopeNode, offsetNode, powerNode, saturationNode, luminanceCoefficients } = this;

const cdl = Fn( () => {

// NOTE: The ASC CDL v1.2 defines a [0, 1] clamp on slope+offset output,
// and another on saturation output. As discussed in ACEScc specification
// notes on CDL application, the limits may be omitted to support values >1
// if negative inputs to the power expression are avoided.
//
// We use `max( in, 0.0 )` for this reason, but the lower limit may not be
// required in all cases.

const luma = inputNode.rgb.dot( vec3( luminanceCoefficients ) );

// clamp( ( in * slope ) + offset ) ^ power
const output = max( inputNode.rgb.mul( slopeNode ).add( offsetNode ), 0.0 ).pow( powerNode ).toVar();
Copy link
Collaborator

@WestLangley WestLangley Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed offline, this should be implemented in log space, and then converted back to linear.

See https://www.mdpi.com/2313-433X/3/4/40 where is says:

This conversion (to log space) is necessary because the CDL Equations (1) and (2) encode meaningful color-correction metadata only if operating on CVs (code values) of a “log” color-space.

This can be corrected later if you want.

EDITED for clarity.

Copy link
Collaborator Author

@donmccurdy donmccurdy Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some doubts about this rule (see introduction to https://blender.stackexchange.com/a/55239/43930), but, all usage I have in mind for future PRs would indeed be within a log space. That said — I don't think we can put the conversion inside of CDLNode, as the particular choice of log space may vary, and further color correction operations may follow in the same log space. If we're implementing looks for AgX we'd likely use AgX Log (Kraken), and for ACES Filmic we'd perhaps use ACEScc. #29450 may eventually need to be extended to handle the common log spaces.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was basing my comment on Filament's implementation and the assumption that log space was the correct space. I am not sure if the particular choice of log space is important for our purposes.

Since we have a node-based system -- and not a fixed pipeline -- I would convert to log and back inside the CDLNode so the calculation is correct.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CDL spec and the ACES document above disagree about this; the former is very clear that application in linear spaces is allowed, so long as you're consistent in communicating the color space expected for any particular set of CDL coefficients.

The ACES pipeline can of course be more opinionated about what to allow, as can we... But I don't think we can embed a particular color space transform into the operation and still call it a CDL, it will be impossible to compare results with other software, and that's the real point of using a CDL.

If we are offering an artist-friendly color grading API like Filament’s ColorGrading.cpp (perhaps we should!), then embedding the log conversion would be entirely appropriate. The CDL would be a single step, in log space, within that process. But the CDL is a mathematical operation, low-level and not particularly artist-friendly, and it must be possible to compose different pipelines around it... which I feel that an internal log conversion will block.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

linear spaces is allowed, so long as you're consistent in communicating the color space expected for any particular set of CDL coefficients.

In that case, I would argue the color space should be added as a parameter, and the algorithm modified to honor it.

That parameter would include the current working color space, in which case no color space transform is applied.

Copy link
Collaborator Author

@donmccurdy donmccurdy Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I'm afraid I don't see how this can work. Other common color operators (like contrast) may receive comparable benefit from using a log space, and I think it will be impractical (for performance, numerical precision, and creative intent) to enforce a color space conversion within low-level operators.

Note that the CDL is not itself a "Look" (or LMT as in the ACES literature), a CDL might be just a component of a look. Or one CDL might be applied before tone mapping, and another after. For that reason, we also cannot require that the input to a CDL must be in the global working color space.

To your points — if we wanted to say that a Look should always be done in a log space, I'm aware of no issues with that statement, and I have no plans to do otherwise!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CDL spec ... is very clear that application in linear spaces is allowed

You are correct. Both linear and log space are allowed.

Just so I understand your point, are you planning to add a log-conversion Node of some sort, so users who prefer to apply the CDL in log space can do so?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you planning to add a log-conversion Node of some sort ...

Yes, certainly! Or maybe log conversion could be supported by THREE.ColorManagement and the existing ColorSpaceNode directly... but I'm nervous about getting that right, and inclined to start with 1-2 dedicated log space nodes instead.

I am also hoping to find a simpler higher-level abstraction so that most users do not need to interact with the CDL node directly, but I am not sure, yet, what that will mean.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I see we are not quite sure where this is headed... So I think this is OK, and we'll see what happens! :-)

An example would be awesome. 🙏


// clamp( luma + sat * ( in - luma ) )
output.assign( max( luma.add( saturationNode.mul( output.sub( luma ) ) ), 0.0 ) );

return vec4( output.rgb, inputNode.a );

} );

const outputNode = cdl();

return outputNode;

}

}

export default CDLNode;

export const cdl = ( node, slope, offset, power, saturation ) => nodeObject(
donmccurdy marked this conversation as resolved.
Show resolved Hide resolved
new CDLNode(
nodeObject( node ),
nodeObject( slope ),
nodeObject( offset ),
nodeObject( power ),
nodeObject( saturation )
)
);