This case is where we’re checking for the texture in a preflight stage prior to full graph evaluation to throw the error early (which was discussed in a pervious thread).
A new “robustexists” could work or even a flag to pass to the texture system/image cache, but I wonder if it might be better to provide a global helper: bool valid_input(string filename, std::string &error, ImageCache* cache = NULL) that wraps a lot of this up into a tidier more concise call. I’m not too sure if this is breaking with convention though. Thank you > On Jul 7, 2019, at 11:49 PM, Larry Gritz <[email protected]> wrote: > > I see. > > Truth be told, I was thinking about it from the point of view of a shader, > where you just wanted a fast yes/no answer and probably weren't interested in > parsing error messages or trying to be subtle in handling the failure cases. > "Is this texture present? Then do this thing. Otherwise, skip it." > > Maybe it makes sense to have a second existence query that is "less binary", > including returning the full error message? > > >> On Jul 6, 2019, at 2:52 PM, Colin Doncaster <[email protected] >> <mailto:[email protected]>> wrote: >> >> I specifically mean with “exists”. >> >> For example, if it’s a jpeg2000 file and OIIO isn’t compiled with jpeg2000 >> support the file can be there in that it exists and it’s a valid jpeg2000 >> file, but the get_texture_info query will return false (in that the call >> itself will return true, as it always does for “exists”, but the actual >> query value will be false). >> >> In this instance OIIO reports that it’s an unsupported format, but that >> error never makes it to the end user when it maybe should? ie. rather then >> “it can’t be read” we can report “it can’t be read because we don’t support >> this format”. >> >> This is more explaining myself then arguing it needs to be changed, happy to >> keep the default. >> >>> On Jul 6, 2019, at 4:06 PM, Larry Gritz <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> We might be talking past each other. >>> >>> For any get_texture_info query OTHER THAN "exists", I do expect that any >>> failure will have a decent error message that will be propagated up. Is >>> that not the case? >>> >>> For "exists" queries alone, merely checking for existence of an image, even >>> if it is not found, is never supposed to be an error (that's by design). >>> Though if you are saying that in the case of an "exists" case that fails, >>> you want the error message anyway... then I guess we can add a >>> TextureSystem option that will make this behavior, and you can turn it on, >>> though I think I'll keep the default off unless there's a consensus that I >>> chose wrong originally. >>> >>> >>> >>>> On Jul 6, 2019, at 1:01 PM, Colin Doncaster <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> The current behaviour works great, we did have an issue where a file >>>> existed but get_texture_info with “exists” was returning a false (0) value >>>> on a jpeg file and there was an error being generated that helped to debug >>>> but wasn’t initially being passed back to our logging system. >>>> >>>> I’m nit picking here but if there’s a chance something can fail, whether >>>> it’s get_texture_info returning false or setting the data value to false, >>>> I think it would be nice to know why it failed? >>>> >>>> We’re also happy to concede that just keep the lines commented out in our >>>> build. :) >>>> >>>> Colin >>>> >>>>> On Jul 6, 2019, at 1:49 AM, Larry Gritz <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> The "exists" query is special -- it's documented as NOT being an error >>>>> (in the usual sense of propagating error messages) if the file doesn't >>>>> exist, so we try to intercept and bury any messages that happen as a >>>>> result. >>>>> >>>>> >>>>> >>>>>> On Jul 5, 2019, at 2:58 PM, Colin Doncaster <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hello - >>>>>> >>>>>> I’ve been doing some debugging and potentially found a few little issues >>>>>> with how errors are propagated when using get_texture_info with the >>>>>> “exists” data name. >>>>>> >>>>>> On line 2553 of imagecache.cpp it calls geterror() to “eat any errors >>>>>> generated by find_file”, is there a specific reason it does this? We >>>>>> were ending up with 0 being returned but geterror() wasn’t returning any >>>>>> information about it until we commented this out. >>>>>> >>>>>> The second issue was in texturesys.cpp at 568, the error is only >>>>>> propagated from the image cache to the texture system if ok is false - >>>>>> but when using “exists” this is always true. Couldn’t the error always >>>>>> be passed if not “”. >>>>>> >>>>>> Thank you, >>>>>> Colin >>>>>> _______________________________________________ >>>>>> Oiio-dev mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>>> >>>>> -- >>>>> Larry Gritz >>>>> [email protected] <mailto:[email protected]> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Oiio-dev mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> >>> -- >>> Larry Gritz >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] <mailto:[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
