On Jun 29, 2007, at 8:15 PM, [EMAIL PROTECTED] wrote:
but readers should recognize other reasonable
versions, like r/g/b/a, red/green/blue/alpha, etc..
This is the part I was referring to. The abundance of reasonable
alternate R G B channel names. There are a lot of them. I completely
agree with everything else you said.
-Jim
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