I'm interested in contributing code for the Quicktime Reader/Writer. Will do it anyway for my current project and it would save me some time to do it through OIIO. Can't we just begin with the standard API and see how far we get? Mikael
On Sat, Mar 24, 2012 at 8:47 AM, Larry Gritz <[email protected]> wrote: > A guiding principle of OIIO's design has been to limit complexity of the > APIs and the apps by *NOT* supporting every possible permutation of the > file format on the app side of the interface, only on the plugin side. The > fact that you think we support the whole of all the formats shows that we > chose what to exclude wisely, but we certainly do exclude. :-) > > For example, there's no way to ask OIIO for uncompressed raw data from a > file, even though you could get that from libtiff. There's no way to ask > for channels in BGR order, even for a format that natively stores in that > order. There's no way to get 10 bit per pixel data -- it will > automatically translate to 16 bits (though it leaves a clue in the > "oiio:bitsperpixel" metadata that your 0-65535 data was derived from a file > with fewer bits actually stored). You can't even read palette images > directly, it will always expand to full color upon read. > > So in that vein, it seems natural to start by glossing over things like > audio, multiple video tracks, and nonlinear time. Even with those > restrictions, allowing an oiio reader that is capable of pulling individual > image frames out of a movie file seems awfully useful, much more so than > the current state of not being able to do it at all. > > If those restrictions get in the way down the road, we can of course try > to address it. But I'm very curious to see how far we get without any > changes to the APIs at all. > > -- lg > > > On Mar 23, 2012, at 5:02 PM, Jonathan Gibbs wrote: > > > Regarding adding movie formats to OIIO: > > > > I think it's a great idea, and it will be very useful to do things one > > is prepared to do to images directly to the frames of a movie. The > > sub-images notion does map well to frames. However, movie formats like > > Quicktime generally also support any number of video tracks, so it's > > not just a 1-d array of images, and their notion of time is a bit more > > complex. They also support audio. It would be annoying to use a tool > > which claimed to support Quicktime via OIIO to drop so much stuff on > > the way through. > > > > One thing which has impressed by about OIIO is when you support a > > format there is every effort to support the whole format, not just the > > commonly used variants of it. It would be a shame for movie formats to > > break that trend. > > > > I'm not sure how to deal with these conflicting comments, so I'm just > > saying them. :) > > > > --jono > > -- > 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
