New <Log> Process Node

Discussions - ACESNext VWG – Common LUT Format (CLF)
1

This process node is on the list to be added to the revised spec.

The node is intended to allow for achieving both simple log/antilog conversions as well as matching cineon-style log and most current “camera log” formulas.

Needs from the group:

  • agreement on the name for the node - is it Log?
  • decision on styles (and their names!)
    • basic logarithm - base 2 and base 10
    • cineon-style
    • OCIO style?
    • camera-style
    • do we add another option to mirror? (e.g. to support Canon Log 3)

As of now, this node will have sub-elements:
<Description> - (optional)
<LogParams> (required - if “style” other than a pure log) contains the attributes:

  • if style="logToLin" or "linToLog"
    • gamma, refBlack, refWhite, highlight, shadow
    • linSideSlope, linSideOffset, logSideSlope, logSideOffset, base
  • if style="cameraLogToLin" or "cameraLinToLog"
    • linSideSlope, linSideOffset, logSideSlope, logSideOffset, base, lineSideBreak, linearGain

The node will have attribute(s):

  • style - specifies the type of log function
    Options for style are "log10" , "log2" , "antiLog10" , "antiLog2" , "logToLin" , "linToLog", "cameraLogToLin" , "cameraLinToLog"

The initial proposal from @doug_walker will be reposted below.

2

For convenience, reposting initial proposal by @doug_walker for the Log node

2 Likes
3

This would be great, when will it be implemented?

4

A group of interested community members are updating the specification now and targeting its inclusion in ACES 1.2, to be released late fall 2019.

1 Like
5

Apologies if it’s documented somewhere already, but how does bit depth factor into the above example? In most cases in CLF, the implementation does not apply a bit depth based scale to the values, because that is supposed to be factored into e.g. the values in a LUT table. But in the above example (I realise it’s not supposed to be a completely real one) the outBitDepth of the lin2log is “10i” and the logSideSlope is 1.0.

This would give output ranged 0-1 for input ranged 1-10 according to the equation given. That is clearly not 10-bit values. Is the intent that an implementation should scale the output according to bit depth (which seems inconsistent with how CLF works in other nodes)? Or should a real version of this in fact use e.g. logSideSlope="1023.0"?

6

Hi Nick,

Yes, excellent point. We need to make sure the spec covers that aspect.

I think that for the two new process nodes we are adding (Log and Exponent), that the parameters should strictly be in normalized form. In other words, they are independent of the bit-depth settings. The ASC_CDL process node already works that way, so there is already a precedent for that behavior.

Doug