Hi Larry - By QT I meant Quicktime, not the QT GUI toolkit.
I guess when I refer to feature creep I mean how some of the GSOC additions are implemented and rolled into the library - I understand that there is a level of mentorship included in this process but much of the proposed projects are something I wouldn't be interested in adopting. 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. 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. 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. My initial emails wasn't meant to point out that everything is wrong, I'm just trying to look at it from the standpoint of support it within a product for the next year or so. We could, of course, lock to a version but I guess I'd prefer to be able to move forward when need be. Thanks -- Colin Doncaster Peregrine Labs http://peregrinelabs.com On 2012-04-11, at 1:07 PM, Larry Gritz wrote: > On Apr 11, 2012, at 7:18 AM, Colin Doncaster wrote: > >> Who is the target audience for Open Image IO? > > The primary target audience for OIIO is VFX studios and tool developers > (tools being renderers, compositors, viewers, and other image-related tools > you'd find in a production pipeline). Of course it's fine for other > audiences, but our focus is on the things that VFX and animation production > needs. > > There are four "layers" to OIIO, from inner to outer, each building on the > last: > > 1. Core ImageInput & ImageOutput APIs and the plugins that handle individual > image formats -- reading and writing images in a format-agnostic manner. > 2. An ImageCache and TextureSystem -- the ability to reference huge amounts > of (read-only) image data in limited RAM without the app needing to worry > about memory management, file handle management, or anything like that. > 3. ImageBuf and ImageBufAlgo functions -- a simple class for storing and > manipulating whole images in memory, and a collection of the most useful > computations you might want to do involving those images. > 4. A basic set of the most obvious command line utilities that wrap, > demonstrate, and allow easy access to, the ImageBuf/ImageBufAlgo > functionality (oiiotool, iv, maketx, idiff, etc.; Note that we're rapidly > getting to the point that all important functionality is in oiiotool and iv, > the others are single-purpose tools that are approaching redundancy). > > Item #1 is the bulk of the code, most of the build time, and nearly all the > dependencies (with the sole exception of Qt, needed for iv). In my mind, the > gap between each of 1-4 is very small, so they belong together unless a > compelling reason is giving for divorcing them. In contrast, I would view > the gap between 1-4 and a hypothetical #5 (say, a full compositing app) as > much much larger -- such a thing would suddenly be the bulk of the code, and > pull in many more dependencies, and therefore would be deserving its own > project. > > >> I agree that QT is a format that many use and rely on for image processing > > You lost me here. Qt is not a format, it's a library that we use for iv's > GUI, and nothing else. If Qt is missing, the build will merrily continue, > skipping iv but building everything else just fine. If you don't need the > viewer, you don't need to worry about Qt. Nothing else in OIIO touches Qt. > > I apologize if Qt adds difficulty. That was not the intention. For me, a > "port install qt4-mac", and I was done. I assumed it would be as easy for > everyone else, if there is a need for better instructions or CMake fixes, it > is just an oversight and I would like to have fixed (but it may need to be > fixed by somebody other than me; I have Qt installed easily on all my > systems, so I have no way to test the difficult cases). > > >> I guess it just feels like there's potential for aspects of OIIO to end up >> with feature creep and I wonder if there's any merit for OIIO Core and then >> OIIO Extensions or something similar to differentiate between the raw core >> implementation of loading images and texture caching vs. IV and QT formats? > > There has been occasional debate among the senior developers about whether > this all belongs in one project, or should be split into multiple projects. > Which begs the question of *where* the dividing line should be. Should iv be > split off? Should all the utilities and image processing be split off? > Should the IC/TS be split off? > > At the moment, I'm in favor of keeping what we have together. Splitting the > existing project into multiple parts would certainly be a lot more ongoing > work for me (I need them all, and I need them to stay in sync), and I haven't > heard anybody articulate a good explanation for how a split would help > anybody. It is possible that at some point, ImageBufAlgo/oiiotool or iv > could grow to be so large as to dominate the project (and arguably diffuse > our core mission), at which point I'll be the first to advocate splitting > into two projects. But I don't think we're there yet, and may never be. > > I'm still unclear on what the perceived problem of the "feature creep" is. > Are you worried that we're neglecting the core by working on other parts? > (The core is extremely stable; there's really not much to neglect.) Are you > worried that the project is too big a download, takes too much disk space, or > takes too long to compile? That there are too many dependencies? (Qt is the > only additional dependency beyond the core, as far as I know, and only needed > for iv.) > > If you had a compile-time "core only" flag that would only build the basic > I/O stuff and ignore everything else, would that 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
