Hi Larry, I've finally have a buildable oiio install that I can modify and test.
Your patch does work as advertised and allows me to successfully modify the order of the plugin searchpatch and force my custom plugin to be found first by changing the 'plugins_override' value. This is with oiio built with embedded plugins. Unfortunately my custom plugin still wasn't being instantiated properly and it took a bit of digging to figure out why - the embedded plugins contain global symbols that get incorporated into libOpenImageIO.so and override the symbols in my externally loaded plugin. For example, the class 'OpenEXRInput' is present in libOpenImageIO.so so the static creator routine creates an instance of the embedded class rather than my plugin's class, even though the creator routine is being executed in my plugin. So, I needed to change the names of the classes in the exrinput.cpp & exroutput.cpp files to avoid this (I also tried namespacing which worked as well.) I also needed to change the declared format name from 'openexr' to 'my_openexr' so that it didn't conflict with the map of input_formats from the embedded plugins. I did try changing the dlopen flags and removing RTLD_GLOBAL, but this didn't work since the embedded plugins aren't dlopened… I think namespacing the file plugins or not having their symbols get incorporated into the lib would be a cleaner solution, but how to best manage that is a bit over my head. Cheers, -jonathan On Jul 29, 2013, at 11:25 AM, Larry Gritz wrote: > 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 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
