Not quite correct!
I have a description of naming conventions here, along with some
fine coder art example images:
https://github.com/openexr/openexr-images/tree/master/Beachball
Specifically:
- Do not assume layers/views are encoded in the 'name'
attribute. It is arbitrary, and there is no convention how
things are encoded in it. It only exists to support
'position-independent' access to parts in tools such as
exrmultipart
- If there is no multiView or view attribute, the file is not
stereo, regardless of what other attributes may contain the
words "left" or "right" (or what the writer actually intended!)
- If there is more than one part, the multiView strategy should
not be used. Instead all the channels in a given part are for
the same view
- Layer names are encoded in channel names, but
multipart files do not store view name in channels
I guess you want "original" in your example to be the RGB that gets
read by default, so there should be no layer name in those channels
and you get this.
part 0: name: original/l, view: left
channels: R,G,B
part 1: name: original/r, view: right
channels: R,G,B
part 2: name: processed/l, view: left
channels: processed.R, processed.G, processed.B
part 3: name: processed/r, view: right
channels: processed.R, processed.G, processed.B
We are missing a RgbaInputPart class from the API, so you will
likely have to use the General Interface for Reading images, as
described in the docs.
(You could also check out the implementation of
RgbaInputFile::setFrameBuffer in ImfRgbaFile.cpp - you only need
another four lines to read the channels you want compared to the
Rgba interface)
Another 'gotcha' is that the channels of a single layer in a single
view may be spread across different parts. This is why the layer
names have to go in the channel names, rather than using some other
part-specific attribute such as name. The Beachball sequence stores
RGBA in one part and Z in another, even though they are the same
'layer' as EXR defines it. This is because (presumably) you don't
always want to see the Z channel so there's no sense in slowing down
RGBA read performance by including it in the same part. You could
also use a different compression scheme for Z
Cheers,
Peter
On 18/06/14 10:00, Gonzalo Garramuno
wrote:
On 18/06/14 06:04, Paul Miller wrote:
On
6/17/2014 12:55 PM, Gonzalo Garramuno wrote:
On 17/06/14 13:56, Paul Miller wrote:
I'm adapting some code (which
previously used RgbaInputFile) to
support MultiPartInputFiles and InputPart objects.
But there is no InputPart::setLayerName(). Once I have
identified a
part, how am I supposed to request the "left" or "right"
view for
instance, assuming the part has both left and right channel
descriptors?
Each part has a header with both a view() and a name() call
for that
header. The name tells you what you are dealing with and the
view()
what left or right eye you are dealing with. However note
that
supporting view() is optional (hasView()), so it is a good
idea to check
for "left" or "right" string in the name().
So it appears that parts would be taking the place of the old
"multi-view" system in this case?
Previously, I might see a stereo multi-view file with a "left"
and "right" view, and channel names like: left.R, left.G,
left.B, and right.R, right.G, right.B.
I was assuming that multi-part files would keep this idiom, but
allow multiple versions/images in the same file, so I might see
this:
part 0: original
left.R, left.G, left.B, right.R, right.G, right.B
part 1: processed
left.R, left.G, left.B, right.R, right.G, right.B
But without a way to target specific "layers" in the InputPart
class, should I be expecting this instead?
part 0: original.left
R, G, B
part 1: original.right
R, G, B
part 2: processed.left
R, G, B
part 3: processed.right
R, G, B
Thanks for the input!
Correct.
Albeit you should be expecting also the A and Z channel for deep
compositing too.
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
|