TSL: Add CDLNode #29510
TSL: Add CDLNode #29510
Conversation
📦 Bundle sizeFull ESM build, minified and gzipped.
🌳 Bundle size after tree-shakingMinimal build including a renderer, camera, empty scene, and dependencies.
|
src/nodes/display/CDLNode.js
Outdated
| 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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 🙏
|
@sunag I notice the nodes defined in https://github.com/mrdoob/three.js/blob/dev/src/nodes/display/ColorAdjustment.js are simpler, just a |
|
Sounds like a good idea, if you use |
|
I think we can move this node for addons too? #29511 |
|
I think my preference would be to move it into |
|
Reimplemented as a simpler function and moved to |
I think it would be better to use It would be better remove the names from |
|
@sunag done and done! I did find |
Implements ASC Color Decision List (CDL) v1.2.
I'm not ready to do an integration with the TSL tone mapping nodes quite yet, but here's an early comparison, configuring the CDL to emulate the AgX “Punchy” look, with higher saturation and contrast:
The goal is to provide configurability for our current hard-coded tone mappers.
Related:
/cc @WestLangley @sunag