[Inconsistency] Viveza problems with iMatch


It seems that Viveza has problems when loading TIFF files that have been generated by DPL 3 when DPL 3 has been called from iMatch. In that case, iMatch adds its own metadata to the RAW file and this can cause trouble in Viveza.

For example, with Sony RAW files, iMatch adds to the RAW file an XMP-tiff:compression field that contains the following value : Sony ARW compressed. This metadata field is transmitted to the TIFF file generated by DPL 3 when calling Viveza. This is enough for Viveza to reject the file as an unsupported file type.

Here again, we have an inconsistent behavior of Viveza in comparison with the other plugins which do not have this problem.

See this related thread :

It’s also a bug in PL. It’s just copying old xmp data to a new file during the conversion.


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.

Other similar reports involving Digikam instead of iMatch indicate that the main problem appears to be the inconsistency between Viveza and the other Nik plugins. It should not be that difficult to make Viveza in sync with the rest of the collection.