The idea of the plugins was to extend the set of supported file formats at
runtime. An example would be if an application that uses OIIO wanted to
support for GIF files (we don't, natively), they could write their own
gif.imageio.so (or .dll) to extend support, rather than create a customized
libOpenImageIO. Another example would be if there was a truly proprietary
format (internal to one company, or one application), they could easily extend
OIIO to support it just by writing that one DLL/DSO without cluttering the
public distribution or without revealing to the world the details of their
proprietary format.
(Aside: In truth, although I always thought of the plugin mechanism as an
important feature in an image library, it's not clear to me whether anyone at
all uses the ability to extend format support at runtime. I started out with
*all* formats supported via DSO/DLL's, even the ones that come with OIIO. It
was user demand that led to format support being embedded in the library rather
than DSO's. People overwhelmingly found the build and distribution simpler
with one library rather than a dozen or more plugins.)
I admit that I never really considered the case of somebody who wanted to
*replace* an existing format module, rather than extend the set of file
formats. So it's not surprising that the library always considers the built-in
(embedded) implementations first, and only checks the DSO/DLL's if none of the
embedded readers are able to open the file.
If it's important to you, I think we could fix this pretty easily. I'm not
sure I'd want it to be the default, but we could certainly make it an option to
check for DSOs first, i.e., reverse the priority.
Out of curiosity, what does your OpenEXR reader do that the standard one does
not? Is a more productive route to propose an improvement to the built-in exr
reader?
-- lg
On Jun 17, 2013, at 12:54 PM, Jonathan Egstad wrote:
> Sorry if this has been answered before, I can't find a relevant mail.
>
> We've built oiio with embedded plugins and now we're attempting to override
> the exr plugin with a customized one.
> Unfortunately the plugin_searchpath string passed to ImpageInput::create()
> does not appear to take precedence during the cataloging of available plugins
> which means the embedded openexr plugin appears to always be found first.
>
> Is this the expected behavior or am I doing something wrong?
>
> The custom exr plugin is handicapped so the plugin's open() method will
> produce an assert error, but no assert is occurring so I'm assuming the
> embedded openexr plugin is getting called instead.
>
> From my reading of imageioplugin.cpp the catalog_all_plugins() method first
> calls catalog_builtin_plugins() before the searchpath string is being parsed
> (I haven't yet built oiio with debug prints to see what's going on in there,
> but that was going to be my next step.)
>
>
> Thanks for any help,
>
> -jonathan
>
>
> #include <OpenImageIO/imageio.h>
>
> using namespace OIIO_NAMESPACE;
>
> const char* plugin_searchpath = "/tmp/oiio/plugins";
> const char* read_path = "/tmp/oiio/plugins/test.exr";
>
> int main(int argc, char* argv[]) {
> ImageSpec spec;
> ImageInput* reader = ImageInput::create(read_path, plugin_searchpath);
> if (!reader) return 1;
> if (!reader->open(read_path, spec)) {
> std::cerr << "Unable to open file '" << read_path << "'" << std::endl;
> return 1;
> }
>
> std::cout << spec.width << "x" << spec.height << std::endl;
>
> return 0;
> }
>
> _______________________________________________
> 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
