Storing plain integer IDs without any auxiliary data is already possible;
no additional work is required for that. What I am proposing would be a
way to associate those integer IDs with additional information; I don't
think it would interfere with storing IDs that aren't mapped to lists of
strings. The two types of data would simply be stored in separate channels.
Florian
Scott Squires wrote:
I'm thinking of cases where the numeric values are processed and manipulated
where necessary.
This makes it useful for other things than user ID of 3D objects such as
segments or or other aux data.
Scott
On Apr 14, 2011, at 5:04 PM, Florian Kainz wrote:
Hi Scott,
Our use case for the object IDs would be kind of like this: "the skin on that
CG creature doesn't move right. What is the creature's name, and which version
was used when this picture was rendered?"
Storing object IDs directly in the pixels, without a lookup, seems to imply
that your production process identifies assets using 32-bit integers instead
of names. 10-digit numbers aren't very user-friendly. Do artists really
refer to "asset number 3780456321" instead of "Davy Jones, version 3.4?"
Florian
Scott Squires wrote:
Yes, this would be useful.
I'm assuming it might also be useful to have a simple version of this where a
ObjectID is simply saved as a UINT for each pixel without being
forced to go through the lookup/remap process.
That's doable now but if you're standardizing on ObjectID formats for EXR it
would it should probably be covered as well.
Scott
On Apr 14, 2011, at 3:13 PM, Florian Kainz wrote:
Hi,
At ILM we want to implement a workflow where a computer graphics artist
can bring up an OpenEXR image of, say, a scene from Rango on his or her
screen, point to a pixel, and be find out that the object seen at that
pixel is called "Beans/dress/button3."
This will require storing per-pixel object identifiers in an OpenEXR file.
In order to avoid re-inventing the wheel, I would like to find out if any
OpenEXR user have done something like this already. If you have done it,
would you be willing to share how you did it?
Also, is there any interest in per-pixel object identifiers outside ILM?
Florian
Unless somebody has a better idea, we'll probably do something like this:
Add a channel called objectID, of type UINT, to the image.
If the image has multiple views, then add an objectID channel
to every view.
Add an attribute called objectID to the header. The type of the
attribute is a map from unsigned integers to lists of strings.
If the image has multiple views, then add multiple attributes
with names of the form <view name>.objectID.
For each unsigned integer value that occurs in one or more pixels
in the objectID channel, a corresponding map entry in the objectID
attribute contains a list of all objects that are visible in those
pixels. More than one object may be visible in a given pixel because
of transparency, motion blur, reflections, or anti-aliasing.
To find out which object or objects cover a given pixel, application
software first looks up the value stored in the objectID channel for
that pixel, then it looks up the corresponding list of object names
in the objectID attribute.
In images with lots of transparency or motion blur any given object
name may occur multiple times in the map from unsigned integers to
string lists. In order to save disk space the objectID attribute
could be compressed by using a two-stage lookup, where the attribute
contains two maps, one from pixel values lists of integer object
identifiers, and one from object identifiers to object names.
With 32-bit UINT pixel values this scheme could run out of object
identifiers for images with more than four Gigapixels, but in VFX
production images that large are rare.
_______________________________________________
Openexr-user mailing list
openexr-u...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-user
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel