Adding URL-style non plain files texture path system

[Etienne Sandré-Chardonnal]

Hi,

Sorry if the title is somewhat confusing...

I can now somewhat manage to read ImageBuf's from non plain file resources (such as texture images embedded in material libraries) with IOProxy. Now, I would like to seamlessly support these resource textures inside the associated shaders, with code like:

//Reads from an embedded texture


color tex = texture("res://diffuse.png", u, v);




//Reads from a plain file


color tex = texture("file://diffuse.png", u, v);

color tex = texture("diffuse.png", u, v);







I can do it by subclassing ImageCache but this would be a huge work as most of ImageCache magic has to be rewritten. Is there a simpler way?

The most easy would be if ImageCache could be passed a "url resolver" object, that given a url string returns an IOProxy. Even the resolve_filename function could be modified to return an IOProxy instead of a path. Does that make sense?

Cheers,

Etienne

[Larry Gritz]

Yes, that's already easy to do. There is no need to subclass the ImageCache.

If the renderer does not already have direct access to the underlying ImageCache, you can retrieve it from the TextureSystem: texturesystem->imagecache()

Then you can declare a "file" ahead of time to the cache, and give it the hints it needs to use your proxy if and when it needs to "open" the file. That looks like:

ImageSpec config;
config->attribute ("oiio:ioproxy", TypeDesc::PTR, &my_ptr_to_my_ioproxy);
imagecache->add_file (filename, nullptr /*input creator*/, &config);




That's all there is to it. Then, when a shader asks for texture from the file that matches what was in the `filename` variable in the example above, it will end up using the proxy for all the I/O.

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/CAM-xo92BDzy2W_1o9OBGZsyUqQRyFwqqaP1sDLs9rON9KPtwXw%40mail.gmail.com.

--

Larry Gritz

l...@larrygritz.com

[Etienne Sandré-Chardonnal]

Hi,

I have tested, it works great.

One question though, I have to add an extension to the file name, while in the current libraries formats we only have a GUID for embedded textures. The current implementation in the renderer was auto-detecting image formats from first bytes (magic bytes). With OIIO I have to manually add the proper extension, otherwise it won't load the file and issue errors.

Normally, with files, OIIO can open images of unknown extension, by testing the plugins one by one, but in this case, it seems it will not. Is this because we use a IOProxy?

Another question, I have been playing with imageCache()->add_file creator parameter. Despite having potential, it seems to me that this parameter is almost unusable, as the creator function takes no argument. So we can't pass it any context (such as a file name, resource name, or class pointer). It would at least require to take a void* argument in order to be useful. Or am I missing its proper use?

Cheers,

Etienne

[Larry Gritz]

On Apr 6, 2020, at 8:02 AM, Etienne Sandré-Chardonnal <etienne...@m4x.org> wrote:

Hi,

I have tested, it works great.

One question though, I have to add an extension to the file name, while in the current libraries formats we only have a GUID for embedded textures. The current implementation in the renderer was auto-detecting image formats from first bytes (magic bytes). With OIIO I have to manually add the proper extension, otherwise it won't load the file and issue errors.

Normally, with files, OIIO can open images of unknown extension, by testing the plugins one by one, but in this case, it seems it will not. Is this because we use a IOProxy?

Is this still a problem after the jpeg reader fix?

That's interesting, I hadn't tried this before. I'll need to give this a try, since many format readers don't support proxies, I'm not sure what would happen. Or, also, it could be a problem if one starts to read from the proxy, fails, but leaves the "current position" somewhere in the middle. I'll need to do some investigation.

Another question, I have been playing with imageCache()->add_file creator parameter. Despite having potential, it seems to me that this parameter is almost unusable, as the creator function takes no argument. So we can't pass it any context (such as a file name, resource name, or class pointer). It would at least require to take a void* argument in order to be useful. Or am I missing its proper use?

Well, an ImageInput Creator is only supposed to make a raw ImageInput that can read a particular format. There are no arguments, because it doesn't know what image to read yet.

Can you bundle up information by using a lambda here?

--

Larry Gritz

l...@larrygritz.com