Does this mean that I should also make a variety of ImageOutput::create that
fully opens, avoiding the need for a second call to ImageOutput::open?
Does anybody else think that #2 (supplying a valid_file method) should be
required of all plugins?
-- lg
On Apr 3, 2012, at 4:52 AM, Colin Doncaster wrote:
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
