According to the ASC-CDL standard "To maintain intended behavior of signs under exponentiation, we limit the Slope and Offset combined value to 0 to 1 (inclusive)..... out = Clamp((in*slope) + offset)^power." Internally OCIO implements the CDL transform by a ScaleOffsetOp (MatrixOp) followed by an ExponentOp followed by a SaturationOp (Matrix). The ExponentOp only clamps data less than zero and does not clamp data greater than one. The ExponentOp also has the behavior that if the exponent is one then no clamping is done (NoOp). The extended range of the ExponentOp in this case becomes a problem when the CDL saturation is not one.

How do address this problem with minimal disruption? How many pipelines depend on OCIO implementation of the CDL SOP returning extended range?

Adding some sort of strict compliance parameter to the CDLTransform would be pretty easy to implement.  We would either have to add a ClampTransform or add a parameter to the ExponentTransform to clamp.

How would we address adding a strict compliance parameter to .cc and .ccc files? FileTransforms already have a "cccid" parameter that is only used for .ccc files. It seems like we could get in trouble if we keep adding specialized parameters to the FileTransform. Could some sort of generic string->string dictionary parameter be added to FileTransform that would be passed to each of the readers? If OCIO adds a FileTransform plugin API in the future then the dictionary could be useful.