Moreover, I think for the most part, FUSE would let you do an okay job instead of trading off the "Oh yeah, and now libtga is busted". For example, both s3fuse and gcsfuse, let you mount S3/GCS like a "real" filesystem. There's overhead, but honestly for those examples, you'd need to change more than just open and seek.
On Thu, Sep 8, 2016 at 1:30 PM, Larry Gritz <[email protected]> wrote: > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
