That would be nice, I would assume if it failed to open then it would return
NULL in that it failed to create and open.
To back up my argument a little more, I really like the idea of being able to
test if a file is valid in this way - but I don't like the idea that it only
works on some formats. It feels like an API should work the same for all
formats vs. leaving it up to someone using the API to know if a format supports
valid_file or not, even if it's just checking the extension ( which could be
the default way of handling it if no one has implemented a more robust means ).
- colin.
On 2012-04-03, at 12:46 PM, Larry Gritz wrote:
> 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
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
