Below is a dump of my notes made while reading the document:
Section 3 should probably include a definition of a Log transform
3.6 “An IndexMap in its simplest form…” suggests more complex IndexMaps may be used. In fact is CLF not now limited to 2 entry IndexMaps, which simply define a range?
3.7 Could be taken to suggest that the output is based only on the index below that corresponding to the input value, when in fact the pair either side are used. 5.3.2 defines it more clearly.
3.10 Should be clearer that not only 3x3 matrices are supported? Section 4 refers to 3x4, but this section appears only to reference 3x3.
4 “To accomodate irregular spacing, a halfDomain 1DLUT should be used.” Firstly “accommodate” is incorrectly spelled. Also since the paragraph is discussing the regular spacing of 3D LUTs, perhaps the sentence should read “To accommodate irregular spacing, a halfDomain 1DLUT or Log node should be used as a shaper prior to the 3D LUT.”
4.1 ACEStransformID. Do we include the ability to identify an individual node, or sequence of nodes as performing a transform equivalent to an ACES transform, such as CSC?
5.3.2 “For a 1D LUT, one value per entry is used for each color channel”. I think “…used for all color channels” would be clearer.
5.3.2 “<IndexMap dim=2>64@0 940@1</IndexMap>” is not a good real world example. It suggests that 940 maps to the second entry in the array. 940@1023 would be better. Or are 0 and 1 now taken to mean the first and last elements in the array? If so, I beleve this is a change from the previous spec, which used integer indices.
5.3.3 “NOTE: Interpolation methods are specified in D.” Appendix D?
5.3.5 “The Range element can also be used in to clamp values.” Remove “in”?
5.3.5 “While intinct might be that this scale should be a clean bit-shift factor (i.e. 2x or 4x scale), testing with a few example values plugged into the formula will show that the resulting non-integer scale is the correct and intended behavior.” This is true for full range integer data, but for legal range a bit shift is preferable, so that e.g. 8-bit 235 maps to 10-bit 940. Are we concerned about this? The correct conversion could of course be implemented as:
<Range inBitDepth="8i" outBitDepth="10i">
<Description>8-bit to 10-bit legal range</Description>
<minInValue>16</minInValue>
<maxInValue>235</minInValue>
<minOutValue>64</minInValue>
<maxOutValue>940</minInValue>
</Range>
5.3.7 sRGB EOTF example. I have mentioned previously that this does not in fact exactly match the sRGB spec, and the break point and slope given in the spec are not a perfect solve.
6.1 I feel the bit depth behaviour explanation should go into more detail, perhaps with some examples. When I first began work on my Python implementation, I misunderstood how bit-depth handling was supposed to work. @doug_walker and others kindly set me straight. I think more explanation is merited in this section.
6.5 “…a transform designer and/or the application should insure that output floating-point values do not contain infinities and NaN codes.” Should there be a comment that half-float 1D LUTs are an exception to this? Presumable an identity half-float LUTs which passes NaNs and infs through unmodified is permissible?
6.9 “Conversions from float to integer if required must be done by rounding.” Should we specify a rounding method, or at least note that there are different ones?
9.9 “<CR><LF> vs. <CR>.” Should this read “<CR><LF> vs. <CR> vs <LF>”?
Appendix C notes that IndexMaps with more that two elements are considered an extension to CLF, but then goes on to describe in great detail such an IndexMap. This feels unnecessary and potentially confusing.
or the definition changed and the way the Matrix case is specified updated accordingly.