Jonathan, did you get a chance to look at this pull request? Does that solve
any problems for you?
-- lg
On Jun 22, 2013, at 9:49 AM, Larry Gritz wrote:
> Check out this pull request, and try it out if you have a chance. I'm
> curious if it solves the problem for you.
>
> https://github.com/OpenImageIO/oiio/pull/621
>
>
> On Jun 17, 2013, at 4:54 PM, Jonathan Egstad wrote:
>
>> Thanks!
>>
>> -jonathan
>>
>> On Jun 17, 2013, at 4:22 PM, Larry Gritz wrote:
>>
>>> 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
>>
>> _______________________________________________
>> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
