1. Ocio-Dev
  2. Topics

Academy CTF LUT Format Support

Ben Doherty <benjdo...@...>
 

Hello all,

My name is Ben Doherty, and I'm a developer working for CBS Digital. We’re interested in addiing support in OCIO for The Academy's Color Transform File (CTF) LUTs. This additional functionality will benefit us here at CBS and hopefully encourage more studios to adopt the LUT format.

Allow me to outline my ideas and development steps so far.

As I understand it, each LUT file format is abstracted via an anonymous FileFormat which is registered with the FileTransform class.

I've done the following:

  1. Created FileFormatCTF.cpp
  2. Registered the new format with the FileTransform class via registerFileFormat(CreateFileFormatCTF())
  3. Began implementing the GetFormatInfo(), Read(), and BuildFileOps() methods for the LocalFileFormat.
  4. Created a LocalCachedFile class
  5. Created a XMLTagHandler class (explained below)
  6. Created a CachedOp class (explained below)

The CTF format is specified with XML. The bulk of a CTF LUT is sequential "Operator" elements (not to be confused with the OCIO Op class, though they are similar). A few examples: <matrix>, <gamma>, <range>, <lut1d>, etc.

The Read() function parses the XML. For every Operator tag (<matrix>, <gamma>, etc) it comes across, it will instantiate the appropriate XMLTagHandler subclass. For instance, for every <matrix> tag, the class will instantiate a MatrixTagHandler. The job of a TagHandler is to read the specifics of the XML element and cache the salient data in a CachedOp subclass (e.g., MatrixCachedOp). Each tag, then, is converted to a CachedOp. A vector of these CachedOps is stored in the LocalCachedFile class.

When the time comes to BuildFileOps(), the function iterates in order through the CachedOps within the LocalCachedFile, asking each one to create whichever OCIO Op is appropriate and adding it to the ops vector.

Please let me know if I have overlooked anything. At the moment, I’ve successfully implemented the <matrix> tag, which seems to be working as expected. I’m more than open to design / implementation suggestions; I can post my code if necessary.

Thanks!
Ben

Mark Boorer <mark...@...>
 

Hi Ben,

That sounds great! What you've described sounds like you're heading down the right track. If it's possible, could you post the code to a github account? That way we could better collaborate, and would make it easier for when the code is finally merged with OpenColorIO properly :)

Very keen to see what you've got so far.

Cheers,
Mark

On Tue, Dec 9, 2014 at 11:08 PM, Ben Doherty <benjdo...@...> wrote:

Hello all,

My name is Ben Doherty, and I'm a developer working for CBS Digital. We’re interested in addiing support in OCIO for The Academy's Color Transform File (CTF) LUTs. This additional functionality will benefit us here at CBS and hopefully encourage more studios to adopt the LUT format.

Allow me to outline my ideas and development steps so far.

As I understand it, each LUT file format is abstracted via an anonymous FileFormat which is registered with the FileTransform class.

I've done the following:

  1. Created FileFormatCTF.cpp
  2. Registered the new format with the FileTransform class via registerFileFormat(CreateFileFormatCTF())
  3. Began implementing the GetFormatInfo(), Read(), and BuildFileOps() methods for the LocalFileFormat.
  4. Created a LocalCachedFile class
  5. Created a XMLTagHandler class (explained below)
  6. Created a CachedOp class (explained below)

The CTF format is specified with XML. The bulk of a CTF LUT is sequential "Operator" elements (not to be confused with the OCIO Op class, though they are similar). A few examples: <matrix>, <gamma>, <range>, <lut1d>, etc.

The Read() function parses the XML. For every Operator tag (<matrix>, <gamma>, etc) it comes across, it will instantiate the appropriate XMLTagHandler subclass. For instance, for every <matrix> tag, the class will instantiate a MatrixTagHandler. The job of a TagHandler is to read the specifics of the XML element and cache the salient data in a CachedOp subclass (e.g., MatrixCachedOp). Each tag, then, is converted to a CachedOp. A vector of these CachedOps is stored in the LocalCachedFile class.

When the time comes to BuildFileOps(), the function iterates in order through the CachedOps within the LocalCachedFile, asking each one to create whichever OCIO Op is appropriate and adding it to the ops vector.

Please let me know if I have overlooked anything. At the moment, I’ve successfully implemented the <matrix> tag, which seems to be working as expected. I’m more than open to design / implementation suggestions; I can post my code if necessary.

Thanks!
Ben

--
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.

Ben Doherty <benjdo...@...>
 

Certainly. Here's CBS Digital's fork of OCIO:

You can see my latest commits. The bulk of the code is in FileFormatCTF.cpp.


On Tuesday, December 9, 2014 3:08:29 PM UTC-8, Ben Doherty wrote:

Hello all,

My name is Ben Doherty, and I'm a developer working for CBS Digital. We’re interested in addiing support in OCIO for The Academy's Color Transform File (CTF) LUTs. This additional functionality will benefit us here at CBS and hopefully encourage more studios to adopt the LUT format.

Allow me to outline my ideas and development steps so far.

As I understand it, each LUT file format is abstracted via an anonymous FileFormat which is registered with the FileTransform class.

I've done the following:

  1. Created FileFormatCTF.cpp
  2. Registered the new format with the FileTransform class via registerFileFormat(CreateFileFormatCTF())
  3. Began implementing the GetFormatInfo(), Read(), and BuildFileOps() methods for the LocalFileFormat.
  4. Created a LocalCachedFile class
  5. Created a XMLTagHandler class (explained below)
  6. Created a CachedOp class (explained below)

The CTF format is specified with XML. The bulk of a CTF LUT is sequential "Operator" elements (not to be confused with the OCIO Op class, though they are similar). A few examples: <matrix>, <gamma>, <range>, <lut1d>, etc.

The Read() function parses the XML. For every Operator tag (<matrix>, <gamma>, etc) it comes across, it will instantiate the appropriate XMLTagHandler subclass. For instance, for every <matrix> tag, the class will instantiate a MatrixTagHandler. The job of a TagHandler is to read the specifics of the XML element and cache the salient data in a CachedOp subclass (e.g., MatrixCachedOp). Each tag, then, is converted to a CachedOp. A vector of these CachedOps is stored in the LocalCachedFile class.

When the time comes to BuildFileOps(), the function iterates in order through the CachedOps within the LocalCachedFile, asking each one to create whichever OCIO Op is appropriate and adding it to the ops vector.

Please let me know if I have overlooked anything. At the moment, I’ve successfully implemented the <matrix> tag, which seems to be working as expected. I’m more than open to design / implementation suggestions; I can post my code if necessary.

Thanks!
Ben

1 - 3 of 3