Hey, Jono!
If you're just starting to investigate OIIO, please make sure you're working
from the 1.1 branch. It's got lots of recent fixes that you won't find in
earlier stable branches.
OpenEXR 2.0 has "multi-part", but it's very limited -- all "parts" must have
the same data window/resolution (though channel sets may differ), and a few
other attributes are shared among all the parts. It's ok for storing stereo
images in one file, or multiple AOV sets corresponding to the same view (better
than the old "layers" hack, IMHO), but not well suited to storing separate
texture maps for different objects (or faces) in one file, because obviously
you'd want those not to be restricted to the same resolution. I'm a little
sorry now that we didn't go the extra mile on OpenEXR 2.0 and support multiple
images in full generality.
TIFF allows multiple images, but we hijack that in order to allow MIP-mapping.
It would be tricky to support both in the same file.
Ptex is one possibility. Right now, OIIO can read Ptex images, with each
"face" as a separate subimage, and you can use those subimages for texture
mapping individually, but I haven't yet gotten the texture system to understand
how to filter across the shared edges of the faces. Ptex is not just storing
multiple images in the file, it's also capable of understanding the topology of
those faces, to filter properly across the edges. I've been meaning to get to
that, just haven't yet. But you don't have to do it that way -- you can use the
Ptex as a container for multiple images, not worry about the uvs or
connectivity at all.
Another possibility is just to write an imageio plugin for your "map" format --
OIIO can dynamically link separately compiled plugins that read and write
custom formats. You already have all the tools at your facility for handling
your format, unless you get better performance from one of the public formats,
I don't see why you shouldn't stick to it. It should take you practically no
time whatsoever to write the custom ImageInput/ImageOutput subclasses for map.
-- lg
On Nov 28, 2012, at 9:36 AM, Jonathan Gibbs wrote:
> Hello OIIO folk!
>
> We've had a side project to look at OIIO and it's texture sampling abilities
> as an alternate to our in-house library. It's been kind of hard to compare
> them as the algorithms are different, but I will share some results when we
> can bang them into a reasonable form.
>
> Our in-house library supports two in-house formats. One is called "map" and
> it's really nothing special - a tiled mip-map format which supports 8/16-bt
> ints and 16/32-bit floats. I don't imagine this has any real value over what
> OIIO already supports.
>
> We also have a format called "multimap" which stores a dictionary of named
> maps. We like this for models where many texture maps are used to cover the
> model and having one file instead of many is easier to deal with and actually
> reduces I/O load quite a bit.
>
> Are there good open alternatives for this? Does anyone else do something
> similar?
>
> * EXR2 has this ability, but it's pretty new and is only HDR.
> * I think TIFF has this ability (because it does everything), but I'm not
> sure how well it's supported.
> * It's been floated that we could use a PTex file in this manner even if we
> end up sampling the images using UVs.
>
> Any recommendations?
>
> --jono
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
