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
