I made another pass through the whole document and here are a few more small issues I found and suggestions for how to fix them:
Section 3.1
The latter part of the sentence “For simplicity, the CLF does not track color spaces, nor does it require an application to convert to a particular color space before use.” does not make sense. A CLF does assume that an image is in the intended input colour space. I find that whole paragraph confusing and don’t feel it adds anything not already covered better elsewhere. I propose removing the paragraph.
Section 3.2.1
The phrase “A series of operations may be rolled into a single 3D LUT process node” is misleading. In reality, doing that conversion accurately may not be possible and I’m not aware of any published algorithms for doing so that actually work in general. I would remove that whole paragraph since it is confusing and the topic is better covered elsewhere.
Section 4.2
I would remove Note 3 from the “id” attribute. If an ACEStransformID is present, then the separate element must be present. The note implies that someone could put it in the “id” instead and that would be more difficult for applications to handle. (There is nothing preventing someone from setting the “id” to the same as the element, but it should not be a substitute for the element.)
The ACEStransformID section should add: “This element is mandatory for ACES transforms and may be referenced from ACES Metadata Files.”
You may want to put the Info element at the end of the section since otherwise one has to look carefully at the indentation to see that the following elements are siblings rather than children of Info.
4.4.4 Matrix
Please add the following to the dim attribute section:
Note: Previous versions of the specification used three integers rather than two for the Matrix Arrray dim attribute. In order to facilitate backwards compatibility, implementations should allow a third value for the dim attribute and may simply ignore it.
4.4.5 Range
Change the sentence: “The Range element can also be used in to clamp values.” to “The Range element can also be used to clamp values on only the top or bottom end.”
4.4.6 Log
OCIO has historically used a default of 2 for the base, so if no one objects I would prefer to use that here too. Also, it simplifies implementations a bit to require that the same base be used for all channels. So please change the default for the ‘base’ attribute on pg 19 and on pg 20 as the second to last sentence of the ‘channel’ paragraph add: “However, the same base value must be used for all channels.”
In the ‘logSideSlope’ and the next 3 attributes, the word “segment” is confusing since all 4 of those apply to the log segment. Perhaps “log side of the log segment” and “linear side of the log segment” would be more accurate.
In the ‘linSideBreak’ attribute paragraph, add that it is also required for cameraLogToLin.
In Note 3 change “continuous in slope” to “continuous in value” and “derivative of the logarithmic portion” to “value of the logarithmic portion”.
In the section about Eq. 4.19, change “Then, the value” to “Then, if linearSlope was not provided, the value”. Also remove the second “the” from the start of the next sentence. And in Eq. 4.19 add a multiply sign after logSideSlope.
In Example 6, remove the ‘linearOffset’ attribute.
4.4.7 Exponent
Add ‘monCurveMirrorFwd’ and ‘moncurveMirrorRev’ to the list of styles.
From the ‘exponent’ attribute you could remove the sentence “The nominal value is 1.0.” since there is no default and it doesn’t make sense to use that value in practice.
In Example 8, change the style from monCurveRev to monCurveFwd. In Example 9, change the style from monCurveFwd to monCurveRev.
4.4.8 ASC CDL
For the “Fwd” style, please add that it is the default (since the attribute is listed as optional).
As previously noted, I would suggest changing the valid range values to match what is in the ASC’s spec. Specifically, this means: slope >= 0, power > 0, sat >= 0, (offset unbounded). For example, change slope from “The valid range is [0.0, 100.0].” to “Valid slope values must be greater than or equal to zero.”
5.3 Efficient Processing
I find the existing section misleading and not helpful. I propose replacing it with:
The transform engine may merge some ProcessNodes in order to obtain better performance. For example, adjacent Matrix operators may be combined into a single Matrix. However, in general, combining operators in a way that preserves accuracy is difficult and should be avoided.
Hardware implementations may need to convert all ProcessNodes into some other form that is consistent with what the hardware supports. For example, combining all ProcessNodes into a single LUT3D. Using a grid size of 64 or larger is recommended to preserve as much accuracy as possible. Implementors should be aware that the success of such approximations varies greatly with the nature of the input and output color spaces. For example, if the input color space is scene-linear in nature, it may be necessary to use a “shaper LUT” or similar nonlinearity before the LUT3D in order to convert values into a more perceptually uniform representation.
5.4 Interpolation Types
This contradicts information provided elsewhere in the spec and should be removed.
5.5 Extensions
Please change “Unrecognized values” to “Unrecognized elements that are not children of the Info element”. And at the end of that paragraph add: “Applications that need to add custom metadata should place it under the Info element rather than at the top level of the ProcessList.”
6 Examples
I find example 12 to be more confusing than helpful. I’ll start another thread for proposing examples.
Appendix B
Revise IndexMap references.
Mention change to Matrix Array dim attribute.