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?
Did do something like that, but hadn't thought of using custom
attribute(s) to store the related data at the time, so I ended up
storing the (integer) references in the EXR and using an external store
for the mapping, using the integers (one per pixel) as record ids. Each
(externally stored) record could list one to many items.
If I read correctly what you intend to do, then I suggest you provide an
option to page-align the attribute data: that way you can memorymap the
metadata and smartly employ any page-oriented tree storage algos. When
you think of the pixel to objectID collection mapping (N:M relation) as
a database relation/table, the memorymap/align suggestion becomes pretty
obvious: when you've got that data page-aligned you can just point your
b- or r-tree at the attribute data space and have a field day. :-) (fast
retrieval of arbitrary large sets of objects per pixel. When OpenEXR can
provide the handle and a pointer/reference at the (aligned) start of the
attribute space, anyone can do what they want (think of it as a
attribute acting as 'blob', the rest of this stuff can be done
application side. No need to load OpenEXR with the peculiars.)
Also, is there any interest in per-pixel object identifiers outside ILM?
If you plan to do something like the above (which would be only an
augmentation of the attributes as far as OpenEXR itself is concerned, I
suppose -- I assume the knowledge how to relate the pixel int32 to
attribute X is kept at the application side), then yes, I'm interested!
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.
Nitpicking: wouldn't that rather imply a limit of 2^32 max 'references'
and no limit on the number of pixels themselves? (in your case: 2^32
sets of objects, each unique set having it own reference int32, so
multiple pixels can have the same reference int32 value when they are
covered by the same set of objects in your scene. Only when you don't
want to spend the effort of combining identical sets for multiple pixels
does this translate to a 2^32 pixel limit.)
Or am I completely off track here?
(2^32 is okay with me, unless you want to provide for hash-based indexes
and then I'd _hugely_ favor a 64-bit int per pixel, instead. But that's
just picking the right type of pixel channel, anyway. Could even map
float to attribute. I had just never considered storing such a load of
data in an attribute and that's the idea here if I read it correctly.
Cool!! Now I hope AE/PS are already capable of ignoring such large
attributes; then I can keep on using them for visualization while
storing some other interesting tidbits in the EXR, as well.)
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: address@hidden <mailto:address@hidden>
mobile: +31-6-11 120 978
--------------------------------------------------