Cool thanks I will do that I will pop some small steps PRs into github.
I have the Cmake changes, and the iinfo stuff working here so I will present those out to you. Thanks On Mon, Jul 29, 2019 at 6:38 PM Larry Gritz <[email protected]> wrote: > Alex, I think we should handle it much like the other formats for which we > use external libraries -- assume it's installed on the system somewhere > (don't embed it), provide CMake variables (e.g. R3D_ROOT_DIR) to hint or > override the location where it should be found, and if not found the > warning might be nice if it said the URL for the red.com web page where > users can find the SDK to install it themselves. > > Another task that will need to be done is to find a minimal r3d file that > we can use as a test case, preferably as small as possible, and also not > containing any proprietary info or licensing requirements that would make > it bad to check into testsuite. > > I encourage you guys to keep this discussion going right here on the mail > list. And don't be afraid to break it into many incremental PR's. For > example, maybe the first one is just the FindR3DSDK.cmake and changes to > externalpackages.cmake to look for it and either print where it was found > or that it wasn't. Then the next PR might be just the skeleton of > r3d.imageio/r3dinput.cpp that is capable of merely opening the file so that > "iinfo foo.r3d" would correctly report it as a r3d file and know the > resolution. Then the next might be able to have "iinfo -v" report all the > relevant metadata. Then the next might be able to correctly read the frame > for whatever the most common configuration is. And so on. Breaking into > small pieces will make them easy to review, and also easier for multiple > people to share the work and collaborate (as opposed to the whole thing > being done outside our visibility and then presented as a single completed > PR that does everything). And if I can see the progress along the way in > this manner, I can also help steer you to the right idioms before you're > too far down any wrong roads. > > -- lg > > > On Jul 26, 2019, at 1:06 PM, Alex Hughes <[email protected]> wrote: > > That `target_compile_definitions` > Is a clever way of doing the runtime linking that R3D requires. > > Question for LG though... > Do we want to provide the R3DSDK redistibutables with OIIO, in which case > I would set the R3DSDK initializer to look relative to itself. > Another option could be environment variable based so at runtime when the > R3DSDK needs the path to the libraries, it could pull from the environment. > The way will was doing it in his demo was using the preprocessor > directives to define the redist path. Which I think may cause problems > because I doubt people are compiling against the live libraries in their > environment. > Also, the "add_oiio_plugin" macro doesn't seem to set the passed > "DEFINITIONS" in a way that would allow the compilation of the plugin to > have the preprocessor directives applied. > I played around with modifying the "libOpenImageIO" CMakeLists file and > added a "target_compile_definitions" call with my required definitions but > having plugin specific logic in the core lib CMakeLists file doesn't seem > like the right way to approach this. > > So I guess, to simplify the above, the R3DSDK requires runtime linking of > the sdk and requires a path in there. I am inclined to try to read an > environment variable and fallback to looking in the same directory for the > libraries. > Does that seem like a good way to do it? > > I've got a working R3DInput plugin working I think and am just getting the > test cases up. But I hopefully will have a PR open soon. > > -Alex > > > > On Fri, Jul 26, 2019 at 5:15 PM Alex Hughes <[email protected]> wrote: > >> Thanks Will, >> >> I would love to include that in my PR if that's ok with you, with credit >> of course. >> >> -Alex >> >> On Fri, Jul 26, 2019 at 8:18 AM Will Rosecrans <[email protected]> >> wrote: >> >>> I recently started making a CMake find module for the R3D SDK. It's >>> uhhh... not quite production ready, (I think it won't work on a Mac yet, >>> and I haven't tested it on Windows) but it might be a handy starting >>> point. Feel free to use it or crib from it, etc. It has a trivial example >>> that makes an OIIO image buf. >>> >>> https://github.com/wrosecrans/ImageTypes >>> >>> >>> >>> On Thu, Jul 25, 2019 at 1:38 PM Alex Hughes <[email protected]> >>> wrote: >>> >>>> I could take a look at it since I brought it up. >>>> >>>> I've never taken a stab at an OIIO plugin but there are lots of >>>> examples and the docs seem reasonable. >>>> I would be tackling it on my own time without company support at this >>>> point because we don't have an immediate need for it here. >>>> >>>> Is the FFMpeg plugin a decent example to base work off of? At least for >>>> the ImageInput? >>>> >>>> -Alex >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ > 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
