Several of the underlying libraries allow you to inject your own methods to do the low-level I/O, but the problem is that they each have a *different* way of doing it, ugh.
Making this work across all the file types would be a big job. > On Sep 8, 2016, at 6:22 AM, Chris Foster <[email protected]> wrote: > > On Wed, Sep 7, 2016 at 5:35 AM, Larry Gritz <[email protected]> wrote: >> But I don't think I can give any kind of accurate count of true I/O because >> I'm letting the underlying format libraries (such as libtiff or libIlmImf) >> handle all the decompression. Neither the TIFF nor OpenEXR libraries have a >> way for an app to find out the compressed size of a particular tile that is >> read, let alone also account for the fact that to read the tile, some amount >> (how much, exactly?) of other I/O is necessary to read headers, seek around, >> etc. > > A reasonable way to do this is to abstract away the underlying > filesystem IO operations into an object containing open, read, seek, > etc. There are other raster libraries which do this, gdal being an > example with its "virtual file system" abstraction. > > This would be an insanely huge job for the sake of a few stats, but > there's other interesting benefits. For example, if you're reading > texture from a cloud service like Amazon S3, being able to hit the S3 > API directly for texture data would be quite interesting. > > The more heavily used image libraries generally have a way to swap out > raw C IO functions for something custom in a reasonably > straightforward way (eg, I've done this for libjpeg before). For many > of the other plugins, I'm afraid it'd just be a big job... > > ~Chris > -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
