I think I can make things easier for you on this front. Let me see what I can
throw together. Stay tuned.
In the mean time, I think you can probably make headway by compiling OIIO with
a simple modification to src/libOpenImageIO/CMakeLists.txt -- just comment out
line 123 that adds the two exr*.cpp files to the embedded list. Then it should
find your plugin just fine (although it's not a "stock" libOpenImageIO at that
point).
-- lg
On Jun 17, 2013, at 3:17 PM, Jonathan Egstad wrote:
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
