[FEATURE REQUEST] Need expanded queries about formats

[lgritz]

Since the very earliest days of OIIO, the ImageInput and ImageOutput classes have had supports() methods that let you test whether the reader or writer has a particular capability. For example,

if (imageoutput->supports("tiles")) {
    // we know the format writer supports tiles
} else {
    // only scanline output is supported
}

The list of tokens denoting capabilities has expanded over the years, but we still just return a bool: it supports the feature or it doesn't.

A concrete example where this is inadequate is if an app wants to know the list of compression methods available for a certain format. Here, an array of strings (or maybe one string that is a comma-separated list) would be much better. There's not much we can do with a bool here.

Anyway, I don't yet have a specific solution to propose. But maybe we can use this issue to discuss or have people propose a solution? What we want is something akin to supports(), but capable of more general queries about formats and their features, supporting arbitrary data types (with shades of getattribute, perhaps). And maybe it would be useful to be able to ask about formats by name, without already needing to hold a created instance of a reader/writer?

Suggestions welcome.

[lgritz]

Design 1

I'm just spitballing here, but one approach might be to hijack the current global OIIO::getattribute() by recognizing query tokens of the form formatcaps:formatname:feature. So maybe

bool tiles_ok = OIIO::get_int_attribute("formatcaps:tiff:tiles");

is the equivalent of

auto f = ImageInput::create("tiff");
bool tiles_ok = f->supports("tiles");
f.reset();

but you can also do more complicated things like:

std::string comps = OIIO::get_string_attribute("formatcaps:openexr:compression");
for (auto method : Strutil::split_sv(comps, ","))
    OIIO::print("supports compression {}\n", method);

Hmmm, needs a little revision, we probably want a way to ask for reader and writer capabilities separately. But you get the gist.

I'm glossing over how this would be implemented so that each format plugin would provide its own knowledge of its capabilities.

[lgritz]

Design 2

Another approach might make new global API calls that return a reference to a ParamValueList that lists all the capabilities of a format:

// New global-level API calls:
const ParamValueList& reader_capabiities(string_view formatname);
const ParamValueList& writer_capabiities(string_view formatname);

// Example use:
auto& caps = reader_capabilities("tiff");

And so you'd get a PVL& that contains entries like:

    "tiles" (int) 1
    "exif" (int) 1
    "compression_methods" (string) "none,lzw,zip"

You could get the whole list and walk it looking for things, or do one specific query with a more abbreviated:

    std::string compressions = writer_capabilities("openexr")["compression_methods"];