Re: OCIO Configuration Reference Values
Malcolm Humphreys <malcolmh...@...>
Hi,
toggle quoted messageShow quoted text
Sorry I have been a bit busy getting up to speed with a job. I have been musing some ideas with Robert Molholm about this separately and wanted to mention it to see what you think. The basic idea would be to add a header chromaticities field and retire the luma field along with adding metadata fields per ColorSpace for both chromaticities and luminance (as cd/m^2). Then add a CATTransform which can read this metadata. I would also like to add a find colorspace by chromaticities to help support image files that have this metadata. The main advantages to this are you have control on where chromaticities are used within the transform list per colorspace and it also allows you to have ColorSpaces with chromaticities metadata but are just extra descriptive data (so you don’t have to have messy flags to respect them or not). For example it could look something like this in a profile: … reference_chromaticities: red: [0.6400, 0.3300] green: [0.2100, 0.7100] blue: [0.1500, 0.0600] white: [0.3127, 0.3290] … - !<ColorSpace> name: AdobeRGB bitdepth: 8ui metadata: chromaticties: red: [0.6400, 0.3300] green: [0.2100, 0.7100] blue: [0.1500, 0.0600] white: [0.3127, 0.3290] luminance_max: [160] luminance_min: [0.5557] description: | AdobeRGB blah allocation: uniform allocationvars: [-0.125, 1.125] to_reference: - !<ExponentTransform> {value: [2.2, 2.2, 2.2, 1]} - !<CATTransform> {method: “bradford”} … Things I am still pondering are about the goal of having a plugin support in terms of what the api and format looks like. ie. to support plugins the Ops would need to be exposed and the Transform interface needs to be generalised so a plugin could expose it’s paramaters (ie. you wouldn’t have a explicit interface CDLTransform.setSlope(foo) vs Transform(“CDL”).set(“slope”, foo)). If this was done to expose Op and Transform parameters it would make sense to do this for ColorSpace as well to make the api consistent. That is not likely to happen anytime soon but it begs the question should chromaticties and luminance be either: (a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now. or instead (b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields. .malcolm
On 25 Oct 2016, at 9:32 pm, Troy Sobotka <troy.s...@...> wrote:
|
|