Oops, thanks for the tip on the docs being out of date. I will guess that at some point we realized that this call needed to work for certain cases.
> On Jul 4, 2019, at 1:18 PM, Colin Doncaster <[email protected]> wrote: > > Thank you for clarifying, I think this suits our needs jut fine fine and > keeping get_texture_info the more robust option seems fair, as long as it’s > clear. > > After posting yesterday I did find this in the UDIM section of the docs and > felt a little bad for asking, but I guess it’s changed? > > "Please note that most other calls, including most queries for get > <page181image17295104.png>texture <page181image17301248.png>info(), will > fail with one of these special filenames, since it’s not a real file and the > system doesn’t know which concrete file you it corresponds to in the absence > of specific texture coordinates." > > I appreciate the detailed response. > > Colin > > >> On Jul 4, 2019, at 4:05 PM, Larry Gritz <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Jul 3, 2019, at 12:04 PM, Colin Doncaster <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> Hello - >>> >>> I’m curious to know what the expected behaviour is when using >>> TextureHandles with filenames that include UDIM’s? >>> >>> ie. if I create a texture handle with myTexture.<UDIM>.tif and >>> myTexture.1000.tif exists will this handle be successfully created and >>> good(myHandle) return true? I realize that without knowing what >>> coordinates might potentially be sampled there still could be an out of >>> range UDIM value, but I’m looking for a first line of defence. >> >> Yes, if it's a special UDIM name, the initial >> get_image_handle/get_texture_handle will always succeed and appear to be >> good. It's not clear what it means to fail, until you give it specific >> coordinates that resolve to a specific real live file that can be present or >> missing or somehow broken. >> >> Up for debate: should merely asking for the handle do a *search* >> (potentially expensive) for files that could match any u,v range with that >> filename template, and succeed if any one is found and fail if none at all >> are found? (See below, that's what get_image_info does.) >> >> >>> Would this also be a valid way of testing to see if a texture exists and if >>> it’s usable by OIIO? Or would using get_image_info on the image cache be >>> better? If so would filenames with <UDIM> pose a problem? >> >> get_image_info/get_texture_info has the behavior described above -- it has >> to get the data you ask for from somewhere, but you haven't supplied a u,v. >> So it will look real files matching the template and return the information >> for the lowest-numbered one it can find. It assumes that you understand that >> if asking for the template name (like "foo_<UDIM>.exr") instead of a >> concrete specific name, any one file will do, and probably you will be in >> trouble anyway if important things like number of channels is not the same >> on all the udim tiles. But if NO files are found matching the template, the >> get_image_info/get_texture_info call will fail. >> >> So you could use get_image_info to check for any metadata that will always >> be present, like number of channels, just to find out if any udim files >> exist at all based on that naming template. >> >> >> If this is missing something important you need, please do let me know. None >> of this is set in stone, I'd be happy to beef up udim support. >> >> >> -- >> 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
