"Jim Hourihan" <[EMAIL PROTECTED]> wrote: >> - For consistency, "<channel>" should, if possible, be chosen from >> the list of main channels: R/G/B/A/Z/Y/RY/BY. This works for layers >> that represent colors. Writers should be strict about using the >> recommended channel suffixes, but readers should recognize other reasonable >> versions, like r/g/b/a, red/green/blue/alpha, etc.. > > This is what I was hoping to avoid in my code but cannot. Obviously > if you throw non-english languages possibly represented as UTF-8 or > possibly transliterated to ASCII in the mix you've got a lot of > permutations to deal with.
I'm not sure I follow ... just to recap my previous message, what I was suggesting is that full channel names beyond the standard ones be formatted "<layer>.<channel>" where "<layer>" could be freeform, including UTF-8 if desired (would be up to the application), but "<channel>" be rather strict, consisting of only R/G/B/A/Z/Y/RY/BY/AR/AG/AB (all previously defined in the spec except for Z) or plain integers. Readers could be flexible and also recognize lowercase or full words for "<channel>" (e.g. "red") or possibly other cases, but wouldn't be required to in order to be compliant. Do you think anything about a system like that would be unfriendly in regards to usage of UTF-8? For example this is what the full channel names could look like for a file comprising main output, a diffuse layer, a spec layer saved as luminance/chrominance (a contrived example), a scalar noise layer, a uv layer, a normal layer, and then everything duplicated for a left-side stereo image: R G B A Z diff.R diff.G diff.B spec.Y spec.RY spec.BY noise.0 uv.0 uv.1 N.0 N.1 N.2 left.R left.G left.B left.A left.Z left.diff.R left.diff.G left.diff.B left.spec.Y left.spec.RY left.spec.BY left.noise.0 left.uv.0 left.uv.1 left.N.0 left.N.1 left.N.2 The key idea here is the consistency of a) using <layer>.<channel> for all non-standard channels, even scalar channels and b) having the <channel> part in <layer>.<channel> conform to a standard. -Jonathan _______________________________________________ Openexr-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/openexr-user
