Without getting into too much detail we've codec modifications to the OpenEXR
format that (hopefully soon!) will get rolled in to the standard distribution.
Until then we do need a customized plugin that has small modifications to the
codec enumerations and is linked against our OpenEXR build.
So it sounds like our near-term solution is to build oiio without embedded
plugins.
However I do think it would be a worthwhile fix if it's trivial enough to do as
it would make plugin management more flexible.
If you don't want to change the API you could trap for a token in the search
path like '<builtins>:/tmp/oiio/plugins' that would determine where to insert
the embedded paths.
-jonathan
On Jun 17, 2013, at 2:06 PM, Larry Gritz wrote:
> 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
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
