On Apr 11, 2012, at 10:37 AM, Colin Doncaster wrote: > Hi Larry - > > By QT I meant Quicktime, not the QT GUI toolkit.
Oh. Well, I hope you can see how I was confused. There's an ongoing detailed discussion about building Qt the GUI toolkit, and you had participated in that discussion just a couple days ago. (I hope you knew it was Qt, not Quicktime, that you were discussing.) Quicktime has barely been mentioned at all over the years... a couple months ago somebody said they'd like to write a format reader that can pull frames out of a Quicktime file, and I replied that I suppose it could all fit into the API as long as the plugin made a movie file look rather like a multiple subimages in the file. I don't think we've heard back on this list since. But I can see it being useful, so my thinking is that as long as the plugin simply skips building if Quicktime is not found, it obviously can't break any other parts of OIIO, so I'd be inclined to accept it (assuming a patch is forthcoming and meets our usual quality threshold). > The way I was looking at it was more rolling your 1-4 into "core" with a > baseline of image formats, any new images formats or less common formats > along with Quicktime or Mpeg or other additions could end up outside of Core. > I'm not sure I understand how this helps you. If you wanted to use the new format, you'd need to get and build both projects. If you didn't want to use the new format... well, it already wouldn't be a burden to you, right? What am I missing? > Although port install qt4-mac does work, this isn't ideal when you're > building a product that needs to integrate with multiple versions of QT ( > Maya 2011 and Maya 2012 ) as well as making sure the binaries built are > usable on all of our users system, on Windows, Mac and Linux. I'm confused again. In this paragraph are you talking about Qt GUI toolkit, or Quicktime? "qt4-mac" is Qt GUI. > The reason I brought up varying OIIO builds is that it's likely that are > product might be loaded along with Arnold, which links against it's own OIIO > and may not support the desired formats etc. I understand we can wrap ours > up with a unique namespace but it would be nice to be in a position to use > the shared libraries. Aha, this might be the meat of the matter. But help me discern the main problem. The OIIO embedded in Arnold would be properly namespaced, so should not conflict with any other OIIO use in different apps, or different releases of OIIO elsewhere on your systems. Are you worried that you would have a custom format reader that would not be read by Arnold's embedded OIIO because it's a different version? I think that Arnold's use of OIIO is only in two areas: the texture system (and there is a very limited number of formats suitable for use as textures), and for output. Is there a specific format that you're worried about? Or are you worried about shared library use on your systems generally? Shared libraries are the devil's work, I'm convinced. I'm all ears if you have any ideas about how we can mitigate any shared library problems. Is there a specific current dependency you want us to eliminate? Or a proposed future dependency that has you worried? To bring this back to the original topic, I'm not aware that any of the submitted GSoC proposals pull in any new dependencies or shared libraries that we aren't already using, so I'm not sure how they affect the shared library problem. Sorry if I'm having trouble locking on to exactly what your concerns are. I really do want to help. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
