No, sorry Larry, unfortunately it's gotten bogged down in third-party-install-purgatory, so I'll likely need to just hack together a test myself.
I'll try to get to it this week. -j 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
