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 texture 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 <l...@larrygritz.com> wrote: > > On Jul 3, 2019, at 12:04 PM, Colin Doncaster <co...@peregrinelabs.com > <mailto:co...@peregrinelabs.com>> 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 > l...@larrygritz.com <mailto:l...@larrygritz.com> > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
