ASC .ccc files

[Jeremy Selan]

Right now, when you use OCIO FileTransform to point at a .ccc file (a color correction collection) you must also specify the id of which to use.

Example .ccc file:
<ColorCorrectionCollection>
        <ColorCorrection id="ab101">
            <SOPNode ... />
            <SatNode ... />
        </ColorCorrection>
        <ColorCorrection id="ab102">
            <SOPNode ... />
            <SatNode ... />
        </ColorCorrection>
</ColorCorrectionCollection>

The cccid is explicitly required because all .ccc files may contain multiple transforms.
This is why - at SPI - we invented the .cc format, which is just a <ColorCorrection> element from a .ccc file in isolation.

But sometimes you're handed a .ccc file that contains only a single correction, and it's annoying that ocio cant handle it without the user picking the right cccid.  And, sometimes the "id" is omitted!

I'd like to solve this.

What would people think, of allowing ocio to always load the first color correction, when an empty id is specified? Too scary? Too error prone?

I'm not sure what the right answer is, but I think we're too strict in loading 'ccc' files, and I'm interested in options...

-- Jeremy

[dbr/Ben]

> always load the first color correction, when an empty id

If the .ccc only contains a single ColorCorrection, and no cccid is specified, using the first/only CC seems reasonable

Alternatively, would being able to specify a numeric index help this? E.g cccid: "idx:0"

[Malcolm Humphreys]

This does feel a bit dangerous to me where a .ccc file might be resolved in multiple locations. What happens when you have a global .ccc file and a few sequence / shot ones. It wouldn't be uncommon to easily fallback to the global .ccc which you might want to have multiple id for different grades.

Maybe some kind of config option to enable this and/or a default id to search for?

I would hope once we implement the plugin API I would hope that we could write a (reference) database transform to store most of this in. Leaving .ccc as a serialisation format of this data.

.malcolm

[Jeremy Selan]

Hm...  good points.

Ok - so let's drop the idea of using a default cccid.  Too dangerous.

But I'm starting to really like being able to also specify a <ColorCorrection> by index.   Such as cccid = 'idx:0' to pick the 0th cc, or even ccid = '#0'.  This way one is still explicit about which cc to use, but it also allows the use .ccc files where the internal cccids are omitted.

Good idea or bad idea?

Which syntax?  'idx:INT' or '#INT'?

-- Jeremy

[Malcolm Humphreys]

On 24/03/2012, at 5:37 PM, Jeremy Selan wrote:

Hm...  good points.

Ok - so let's drop the idea of using a default cccid.  Too dangerous.

But I'm starting to really like being able to also specify a <ColorCorrection> by index.   Such as cccid = 'idx:0' to pick the 0th cc, or even ccid = '#0'.  This way one is still explicit about which cc to use, but it also allows the use .ccc files where the internal cccids are omitted.

Good idea or bad idea?

Which syntax?  'idx:INT' or '#INT'?

#INT

[Jeremy Selan]

Thanks, we'll go with #INT then.

https://github.com/imageworks/OpenColorIO/issues/244

-- Jeremy

[Jeremy Selan]

I started implementing the index option, and now I'm wondering why to require the '#' character at all?

How about just allowing plain integers as cccids?
cccid=0
cccid=1
etc.

In my current working implementation, I first see if the cccid string is defined in the file, and if so I obey it.  But if it's not a valid id, I see if it's a valid integer, and if so I load that index.  (Note that an empty cccid string always fails so let's exclude that case).

Any objections or downsides I'm not seeing?

-- Jeremy

[Malcolm Humphreys]

On 26/03/2012, at 9:50 PM, Jeremy Selan wrote:

I started implementing the index option, and now I'm wondering why to require the '#' character at all?

How about just allowing plain integers as cccids?
cccid=0
cccid=1
etc.

In my current working implementation, I first see if the cccid string is defined in the file, and if so I obey it.  But if it's not a valid id, I see if it's a valid integer, and if so I load that index.  (Note that an empty cccid string always fails so let's exclude that case).

Any objections or downsides I'm not seeing?

Nope sounds fine with me.