I see. Thanks for the info Larry. My question about HDF5 in general was whether or not OIIO was using it as a generic container for adding image data (through some provided protocol) in a similar fashion as FBX or GTO (which aren't necessarily image containers but do support it). But I should have checked the plug-ins in the src before asking, because obviously there isn't one for HDF5. I'm just taking a second look at our dependencies for building OIIO and wanted to make sure I wasn't missing out on something.
----- Original Message ----- From: Larry Gritz <[email protected]> To: Stephen Parker <[email protected]>; OpenImageIO developers <[email protected]> Cc: Sent: Friday, November 11, 2011 3:42 PM Subject: Re: [Oiio-dev] Field3D/HDF5 On Nov 11, 2011, at 11:02 AM, Stephen Parker wrote: > Out of curiousity, to what extent is Field3D supported and is HDF5 simply a > dependency for Field3D or is it supported separately as well? Currently, HDF5 is only a dependency for the sake of Field3D. I'm not aware of any other image formats that use it, are you? Field3D is partially supported -- you can open an ImageInput for it, find out about the file via its ImageSpec (it looks like a "3D" file with width, height, and depth>1), and read the 3D texels. ImageCache will work, caching 3D volumetric tiles. And TextureSystem::texture3d will do volumetric texture lookups, though currently they are just trilinear interpolations. Not yet supported: * Writing F3D files. * There's no ImageBuf support for 3D images/volumes. * texture3d lookups with better interpolation (tri-cubic seems obvious) or any kind of filtering (that'll be hard since F3D doesn't currently allow multi-resolution volumes like we use MIPmaps for 2D textures). * a variety of corner cases of F3D files, even for reading, aren't properly supported quite yet. I did the initial work on the OIIO side as we were getting started on some volume rendering here at SPI (I also added 3D texture lookups to OSL, which defaults to just calling OIIO's texture3D). As it turns out, we have, at least for the time being, decided that Arnold's volume lookups needed to be a bit closer to the metal, so we go directly to F3D through other means, rather than with OIIO as an intermediary. It goes through OSL, but we override the defaults so it uses certain SPI Arnold internals rather than OIIO. IIRC, the issue was that for certain caching operations, and some weird transformation and motion blur reasons, it was hard to directly map what we needed to OIIO's interface, and rather than trying to figure out the "right" idioms, we just talked to f3d directly with full ugliness. I'd hoped to patch it all up later, but once it was working "good enough", we haven't had a particular reason to go back to make it nicer on the OIIO side. (The Arnold volume rendering and its direct talk to f3d are Chris Kulla's brilliant work, BTW.) I don't know if the status quo is permanent or not, but at the moment, it means that OIIO's f3d support is without a major customer so nobody is currently working on beefing it up. It would be most welcome, of course, and I bet Chris and Magnus would be happy to answer questions about what they learned along the way. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
