Re: XML Profile Format
Malcolm Humphreys <malcolmh...@...>
Ok, I'm convinced. Let's give YAML a shot.Ok, so there is a initial go at this in the other mail. In terms of broad technical strokes, I think either YAML or XML would * I agree that Yaml-cpp seems like our best option of the ones you'veI have added a local copy of yaml-cpp and a patch to make it build static. Once we get a little further down the road, we can work with the yaml-cpp project to get a customisable namespace for our purpose. * For the OCIO:Config implementation, the list of display devices andSo the yaml is slightly different to the demo's I sent through before displays and colorspace are now YAML sequences so order is preserved. (there is a !!omap tag for doing ordered maps but a sequence matches nicely to the current OCIO structure http://www.yaml.org/spec/1.2/spec.html#id2761292) eg. displays: - !<Display> ... colorspaces: - !<ColorSpace> ... Roles are a map but could be a sequence also depending on preference. roles: default: !<Role> {colorspace: raw} Both roles and displays get emitted in the Flow style (all on one line) but could be emitted in the Block style if thats more legible. Note. -- this -- displays: - !<Display> {device: sRGB, name: Raw, colorspace: raw} -- and this -- displays: - !<Display> device: sRGB name: Raw colorspace: raw -- Will parse the same, but it's nice to choose a style that makes sense for emission. Another thing which might be nice is having the following 'detail:' and 'gpu:' fields to make the profile not so vertically challenged. --snip-- ocs_profile_version: 1 resource_path: strictparsing: false luma: [ 0.2126, 0.7152, 0.0722 ] roles: default: !<Role> {colorspace: raw} displays: - !<Display> {device: sRGB, name: Raw, colorspace: raw} colorspaces: - !<ColorSpace> name: raw detail: { family: raw, bitdepth: 32f, isdata: true } gpu: { gpuallocation: uniform, gpumin: 0, gpumax: 1 } description: | A raw color space. Conversions to and from this space are no-ops. --snip-- * Keeping the serialization code internally as statics - not on theI have some ideas but I thought it would be better to just do a swap out replacement first, then tackle plug-able Transform() serialization later. Thanks for all your work on this issue,No problem. .malcolm
|
|