Hello - Sorry for the Quicktime/Qt confusion - in my last email, once I corrected myself, I was using Quicktime for the Apple Quicktime Movie format and Qt for the Nokia Qt application framework. I do understand the differences, it's probably a bad habit to refer to them both as Qt ( though, developing OSX applications you use QTkit for quicktimes - maybe that's where it stems from ).
In reference to the Qt discussion, the Qt that Maya uses is Nokia's Qt Application Framework - Maya 2011 links against Qt 4.5.3 ( or more confusingly the qtsdk-2009.04 ), Maya 2012 links against Qt 4.71 and rather annoyingly 2013 now uses an Autodesk customized version of 4.7.1 with Nuke, Katana and all of the other common VFX tools possibly using different versions. I understand the only iv requires Qt, but as far as installation instructions and integrating it into a pipeline it might be clearer to point out what version of Qt ( the application and GUI framework ) is compatible/minimally required. This is also why I wasn't in favour of 'port install qt4-mac', but I guess if developers are using OIIO and working with all the different Qt flavours they'll be able to sort it all out. This leads to your last point about how OIIO is integrated into multiple products and across multiple platforms/systems. Is the assumption that each product will manage their OIIO needs individually and the recommended deployment method is to always use a namespace? Although OIIO doesn't apparently have many dependencies, it does rely on specific versions of OpenEXR, libtiff, libjpeg, libpng and others ( which are usually already available on most unix installations including OSX but not Windows ) - so in general, a safe means of deployment to avoid symbol clashing and version skew with other products is to statically link all dependencies into a static library using a namespace? I'm not looking for a long answer, but more "yes - that would be the best way of handling it" and to also hear from other product developers on their thoughts how to best handle this? Right now we wrestle with various versions of Python, boost etc. and it would be good to know what versions of OIIO product developers are looking at supporting and why? I apologize if my initial email wasn't to the point, maybe the initial question should have just been - "how are commercial developers integrating OIIO into their products for mass release on multiple platforms and for varying pipelines?". Thanks -- Colin Doncaster Peregrine Labs http://peregrinelabs.com On 2012-04-12, at 1:32 AM, Larry Gritz wrote: > 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
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
