Questions around the usage of ioproxy (ImageSpec attributes and introspection)

[jessey-git]

With the recent ioproxy changes to enable support for nearly all the plugins (much thanks for that :)) I've begun looking into using them in a preexisting application. I've run into a few problems though that I'm not sure how to work through.

For context, the application likes to manage its own in memory buffers necessitating the need for ioproxy in the first place. It also has its own "search loop" which would attempt to find the proper low level library capable of loading the memory buffer (think direct usage of libpng, tiff, etc.)

Some questions from the initial work I've attempted to do:

• I'd like to make use of OIIO's "plugin search" mechanism if possible to eliminate the app search machinery almost entirely - and this does mostly work with very little effort I've found. However, for this to fully work in the context of the larger app, I need to know which plugin was ultimately found which performed the load. I don't believe this information is queryable right now is it? The codepath in question doesn't have access to a filename either, just an opaque set of bytes.

• Dreaded PNG issues are afoot. When using ioproxy, it doesn't seem possible to also use an ImageSpec in the ImageInput::open call. That parameter must be nullptr or the ioproxy isn't used. As such, I'm not sure how to pass in the oiio:UnassociatedAlpha attribute so that premult doesn't happen. Any thoughts on if this might be a bug?

• The app effectively stores all image formats in a unified 4-channel buffer (RGBA) regardless if the incoming file is just 3-channel RGB data or smaller. What's the most efficient way to get incoming ioproxy data into that format? If the 4th channel isn't present it's typically filled in with either 255 (int formats) or 1.0 (float formats) to make it effectively fully opaque, though the 1 and 2 channel formats sometimes differ on how their data is splatted in the buffer. The ImageBufAlgo::channels api seemed useful at first but is there a way to do the transform "in place" (iterating from the end to the beginning to not trample data) without allocating a separate memory blob?

[Edit]
Following up for the 1st issue since yesterday. I suppose I could check the ImageInput::format_name that's returned but it turns out I may need to stick with the custom search loop because Saving images are anyhow format specific so I'd already need to have the ability to do per-format things. In that case, can I rely on ImageInput::open("png", nullptr, nullptr) to always return a PngInput etc? It's not strictly documented but that's what the code will do if the incoming filename is the same as a supported format.

[Edit 2]
Following up for the 2nd issue, I've worked around it for now by manually calling set_ioproxy before I open the input myself with the exact config I'm after.

Following up for the 3rd issue, I guess the best I can do is adjust the x-stride parameter a bit and then fill in the missing data myself after the read_image call?