Hi Larry -
FWIW the semantics of having to create and then open never seemed right - it
always felt like an input should be something that already exists and is usable
once created, so 1. seems fair.
2. is nice, and at some point I would argue it should be required by all
plugins.
colin.
On 2012-04-03, at 2:56 AM, Larry Gritz wrote:
> Anybody have opinions on this?
>
> Good idea? Bad idea? You like?
>
> -- lg
>
>
> On Mar 27, 2012, at 1:10 AM, Larry Gritz wrote:
>
>> In the continuing quest to make create/open more efficient, here are two
>> minor API changes:
>>
>> 1. In almost all uses, an app calls ImageInput::create() to get an II*, then
>> immediately calls in->open() to open the file, which, if you think carefully
>> about the fact that create() does an open to verify that the II is capable
>> of opening the file, means that open() ends up getting called twice. Very
>> wasteful. So the first change is that we change the ImageInput::create()
>> function prototype to include a do_open flag -- if true, it returns the file
>> already opened, not needing a separate call to open(). If false (and this
>> is sometimes useful), it behaves as before, returning an ImageInput* that
>> can be opened, but is not presently. This also simplifies the source of
>> apps just a bit, since the common "create & open" sequence can now be
>> accomplished with just a call to create.
>>
>> 2. To further streamline, we add a new optional method,
>> ImageInput::valid_file(filename), which returns true if the named file
>> appears to be a valid file of that format (in a way that's less expensive
>> than doing a full open and header read -- for example, just checking the
>> first few bytes that contain a "magic number" or whatever). Not all plugins
>> supply this function, and it's not required; the ones that do must return
>> true for supports("valid_file"). I've included implementations for OpenEXR
>> and TIFF that are considerably less expensive than a full header read.
>>
>> The combination of these should reduce a lot of the overhead for identifying
>> which type of ImageInput is appropriate for a given file and creating it,
>> generally avoiding at least one redundant open and header read for exr and
>> tif files.
>>
>> Note that this is a break in ABI compatibility. It will not be merged into
>> 1.0, only master, and so will be a 1.1 feature. I believe that it should be
>> source-back-compatible, however.
>>
>>
>>
>> You can merge this Pull Request by running:
>>
>> git pull https://github.com/lgritz/oiio lg-validfile
>>
>> Or you can view, comment on it, or merge it online at:
>>
>> https://github.com/OpenImageIO/oiio/pull/265
>>
>> -- Commit Summary --
>>
>> * Change ImageInput::create() to allow the caller to request the file to be
>> returned already opened.
>> * Make OpenImageIO::geterror() return a thread-specific error, so multiple
>> threads calling ImageInput::create() can't clobber each other's error
>> messages.
>> * Add ImageInput::valid_file() and supports("valid_file") -- test whether a
>> file is a valid file of that format, cheaper than a full open.
>>
>> -- File Changes --
>>
>> M src/doc/imageinput.tex (162)
>> M src/doc/imageioapi.tex (3)
>> M src/doc/writingplugins.tex (17)
>> M src/iconvert/iconvert.cpp (2)
>> M src/igrep/igrep.cpp (13)
>> M src/iinfo/iinfo.cpp (16)
>> M src/include/imageio.h (52)
>> M src/libOpenImageIO/imageio.cpp (25)
>> M src/libOpenImageIO/imageioplugin.cpp (51)
>> M src/libtexture/imagecache.cpp (2)
>> M src/oiiotool/printinfo.cpp (13)
>> M src/openexr.imageio/exrinput.cpp (20)
>> M src/python/py_imageinput.cpp (4)
>> M src/tiff.imageio/tiffinput.cpp (34)
>>
>> -- Patch Links --
>>
>> https://github.com/OpenImageIO/oiio/pull/265.patch
>> https://github.com/OpenImageIO/oiio/pull/265.diff
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>> https://github.com/OpenImageIO/oiio/pull/265
>>
>> --
>> Larry Gritz
>> [email protected]
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> 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
