API to know what format the importer/converter is importing/converting to?

API to know what format the importer/converter is importing/converting to?

[mosra]

Hi,

sorry, should have told you about this limitation sooner -- I completely forgot that this would hit you very early in the process of creating the converter plugin. It's on my TODO list (and currently also part of mosra/magnum#108). Yes, you are basically on the right path, there's unfortunately some missing parts that I need to put into the plugin manager in order for it to work. The workflow should be then like this (in case of the stb_image_write plugin):

1. There's just one plugin binary, named StbImageConverter, and it has aliases like StbPngImageConverter, StbTgaImageConverter etc.
   • For the general "any converter" case it would of course also provide aliases like PngImageConverter etc. The StbPngImageConverter alias is there in case you want to explicitly use this plugin without any other aliases mixing in (more on that in my reply to #25).
2. The StbImageConverter class has a constructor that takes either a std::string (in case the plugin is loaded through plugin manager) or some enum that specifies which format the plugin should convert to (in case the plugin is linked in the executable and instantiated directly).
3. The enum constructor is obvious, the std::string constructor gets a name under which the plugin was instantiated via PluginManager::Manager::instance() / PluginManager::Manager::loadAndInstantiate(). So in case it was instantiated as StbPngImageConverter or PngImageConverter, it would provide conversion to PNG.
4. In order to output to a different type than PNG, you would load another instance with another alias name.

I think this design is pretty usable, though it has a limitation that you need to have different plugin instances in order to output to different file types. But on the other hand this could be exploited to squeeze some additional performance out (for example precalculating some compressor state in the constructor and then reusing it for the whole plugin lifetime instead of recreating it from scratch in every doConvert*() implementation). So I would keep it this way.

What needs to be done in the plugin manager is:

• The std::string passed to the constructor is currently the real name of the plugin, not the alias. It should be the alias in order to make this feature work, but I have to check that this doesn't clash with any other use case.
• It should be also possible to create every instance with a different alias passed to the constructor. Also not sure, maybe there is something that prevents this.
• For convenience the alias name should be available through some function. The plugin manager code dates back to 2007 and I have a blurry memory that there once was such function, but then I removed it because (as you discovered) it was also available through the metadata and thus seemed redundant. Now it wouldn't be redundant anymore.

Another thing is -- the user might want to specify some options to the converters (such as compression quality). I have an idea how that could be done in a general way, I'll open another issue for that in the corrade repo.

Will keep you updated on the progress (though as I said in other place, I don't have much time right now).

[mosra]

Okay. Done! Sorry it took so long.

The required change in the PluginManager library is done in mosra/corrade@834ea41 and the StbImageImporter plugin was reworked to handle also other formats in 332ba6c, you can look there to see how I tried to handle the format distinction. Nothing (except time, hah) should prevent creating the DevIL image converter now :)

@mosra I'll probably get to it in due time, maybe closer to Valentines day or something. Thanks a lot!