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.

This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

Robert,

Although we can conform to anything For our on-set tools we have made a match to how Nuke's OCIOCDLTransform node works.  This made the most sense because our main goal with CDL is to allow VFX facilities to match the look the cinematographers dials for dailies.  Additionally the ACES workflow does not clamp values above 1.0.

We are not using OCIO but we do try to closely match OCIO implementation for VFX integration as we capture and color a significant amount of footage that goes to vfx. 

Adding the clamp and a flag should not be to troublesome but the default  behavior, if the tag is absent, should be the current non-clamping behavior.

-Joseph

Joseph Slomka

Color Scientist

Fotokem Industries

On Fri, May 23, 2014 at 10:07 AM, Robert Minsk <Robert...@methodstudios.com> wrote:

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.

This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.