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]> 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 > > _______________________________________________ > 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
