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 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
