ocio-dev@lists.aswf.io | ASC .ccc files

Home Messages Hashtags Subgroups Calendar

Date Date 1 - 8 of 8

ASC .ccc files

Malcolm Humphreys <malcolmh...@...> #895 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. -- Jeremy On Mon, Mar 26, 2012 at 9:57 AM, Jeremy Selan <jeremy...@...> wrote: Thanks, we'll go with #INT then. https://github.com/imageworks/OpenColorIO/issues/244 -- Jeremy On Sat, Mar 24, 2012 at 1:41 PM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On Sat, Mar 24, 2012 at 1:46 AM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On 24/03/2012, at 2:53 AM, dbr/Ben wrote: >> 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" > > On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: > >> 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
More
Jeremy Selan <jeremy...@...> #893 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 toggle quoted message Show quoted text On Mon, Mar 26, 2012 at 9:57 AM, Jeremy Selan <jeremy...@...> wrote: Thanks, we'll go with #INT then. https://github.com/imageworks/OpenColorIO/issues/244 -- Jeremy On Sat, Mar 24, 2012 at 1:41 PM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On Sat, Mar 24, 2012 at 1:46 AM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On 24/03/2012, at 2:53 AM, dbr/Ben wrote: >> 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" > > On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: > >> 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
More
Jeremy Selan <jeremy...@...> #891 Thanks, we'll go with #INT then. https://github.com/imageworks/OpenColorIO/issues/244 -- Jeremy toggle quoted message Show quoted text On Sat, Mar 24, 2012 at 1:41 PM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On Sat, Mar 24, 2012 at 1:46 AM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On 24/03/2012, at 2:53 AM, dbr/Ben wrote: >> 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" > > On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: > >> 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
More
Malcolm Humphreys <malcolmh...@...> #889 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 On Sat, Mar 24, 2012 at 1:46 AM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On 24/03/2012, at 2:53 AM, dbr/Ben wrote: >> 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" > > On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: > >> 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
More
Jeremy Selan <jeremy...@...> #886 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 toggle quoted message Show quoted text On Sat, Mar 24, 2012 at 1:46 AM, Malcolm Humphreys <malcolmh...@...> wrote: 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 On 24/03/2012, at 2:53 AM, dbr/Ben wrote: >> 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" > > On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: > >> 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
More
Malcolm Humphreys <malcolmh...@...> #884 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 toggle quoted message Show quoted text On 24/03/2012, at 2:53 AM, dbr/Ben wrote: 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" On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: 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
More
dbr/Ben <dbr....@...> #887 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" On 24/03/2012, at 5:15, Jeremy Selan <jeremy...@...> wrote: 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
More
Jeremy Selan <jeremy...@...> #880 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
More

1 - 8 of 8

1

Previous Topic Next Topic

Home Hashtags Subgroups Calendar Terms