[FEATURE REQUEST] Extend I/O proxy support to more plugins

[jreichel-nvidia]

As far as I can see, I/O proxy support works only for openexr, jpg (import only), png and tiff (edit: plus heif and dpx). We would like to migrate from FreeImage to OpenImageIO, but the very limited reader/writer abstraction is a road block for us (compared to FreeImage which has that for all plugins).

I'd like to see I/O proxy support extended for many more plugins, e.g., (roughly in the order of decreasing priority):

• JPG (export)
• HDR (import/export)
• GIF (import)
• DDS (import)
• PSD (import)
• BMP (import/export)
• WEBP (import/export)
• JP2 (import)
• P?M (import/export)
• TGA (import)

[lgritz]

I'm very supportive of adding ioproxy support across the board.

Can you, or anybody else, help out? It's not especially hard. If I do one or two as examples, are there others who can pitch in to help knock out some more?

[lgritz]

Downpayment: #3179

This adds IOProxy support to hdr.

(This one isn't a good example for others to follow because it turned out to be a very intrusive set of changes.)

[lgritz]

Add IOProxy to GIF: #3181

This one was pretty simple.

[lgritz]

JPEG output was also straightforward: #3182

[lgritz]

DDS, simple: #3184

[lgritz]

@jreichel-nvidia I just realized, after getting about halfway through all this work, that there's an alternate design that intrigues me because it would eliminate a lot of the redundant code where I'm doing the same thing to all these classes. But I feel like it's a little more intrusive and riskier, and so I'm hesitant to backport it to the current 2.3 release family. So I have a question for you:

1. If I finish adding IOProxy support in all formats, would you tend to build and use OIIO from "master" anyway, in which case I think I will go with the more radical approach and probably designate it a "2.4+ only" feature, allowing me freedom to break ABI compatibility and also giving us many months to test it thoroughly before it's in a guaranteed stable release?

2. Or, do you need IOProxy support in the current supported release family (2.3), in which case I will mostly stick with my current approach, backport to 2.3 and release it relatively soon, and then maybe go back and do a big cleanup pass with my new ideas only in master (future 2.4)?

Guidance from you would be appreciated. If you are happy to work from master when this lands, I'll probably take the first approach and maybe not bother backporting this to 2.3.

[jreichel-nvidia]

We are not under time pressure and wouldn't mind waiting for a master/2.4+ feature if that's the implementation your prefer. Just curious: could you sketch what you have in mind for that approach?

[lgritz]

It's not that dramatic -- I just realized after doing 3 or 4 of these conversions that I was making mostly the same changes in all the plugins, but a bit error-prone to cut and paste mistakes, and if I decide later that there are better ways to do these things, I would have to change them in a dozen places. So I've restructured it to have a kind of a thin mixin class, so for example, HDRInput would drive from IOProxyMixin<ImageInput>, rather than directly from ImageInput, and that would add the data members and a bunch of utility methods that tend to be needed from any plugin that wants to support IOProxy.

If you are not under any pressure to need it in 2.3, then I think what I will do is:

1. Merge my original first try (without the mix, backportable) at least for the couple of the most-used formats (probably only JPEG and GIF), so that they may be backported to 2.3 in case they are immediately useful to anybody else.

2. Open a PR for the mixin class so everybody can see what I prototyped. And assuming nobody thinks it's a terrible idea...

3. Close the PRs I made for the less widely used formats (DDS and HDR, so far), and assume those are likely 2.4 features.

4. PR for the new (mixin class enabled) implementations of everything I've done so far (including the simplifying modifications to JPEG and GIF), as well as completing the rest of the items on your list.

[lgritz]

IOProxyMixin implementaton is here: #3196

[lgritz]

I had a re-think of this over the weekend, abandoned #3196, and my new take on the whole thing is #3203.

If that looks acceptable, I already have ready to go a series of follow-up PRs that implement IOProxy for several more formats: DDS, HDR, PSD, Targa, PNM.

[lgritz]

Next instalments:

DDS: #3217
HDR: #3218
PNM: #3219

[lgritz]

PSD: #3220
Targa: #3221

[lgritz]

BMP: #3223
Webp: #3224

[lgritz]

JPEG-2000: #3226

I think that when these are all merged, they will fully complete your checklist.

[lgritz]

IOProxy support has landed in master (and therefore will be in OIIO 2.4) for all the formats you mentioned.

There are a few miscellaneous others that you didn't list, which still need support added, but we'll take care of them over time.