Yes and No. The initial problem is that iMatch doesn’t identify the XMP data that it adds to the image metadata as iMatch specific. It should because these data are generated for its own use. So these data are received as general XMP data by external applications and this obviously a source of problems. The DPL export routine used to send an image to a Nik plugin is the same as the routine used to export to any other third-party application. I doubt that they have written 2 different routines. DPL is “third-party application agnostic”, so to say. It’ doesn’t know what will be done to the image file in that external app. So, it has no good reason to remove whatever metadata are present in this file.
Now, on the plugin side, we know that all Nik plugins with exception of Viveza are ignoring the iMatch data and accept the TIFF file. Viveza obviously reads these data and gets into trouble. So, there’s here an obvious consistency problem that should be fixed. Viveza should behave like the other plugins.
Actually, there’s a shared responsibility between iMatch (which doesn’t identify its own metadata as such), DPL (which exports to the Nik plugins without verifying that the file doesn’t contain metadata that could generate trouble in the plugins that DxO is also owning) and the user who has to decide whether he lets iMatch modify the RAW files (a practice that is well known for generating trouble when using multiple image processing applications).
The simplest solution is to make Viveza consistent with the other plugins.