However, the other plugins don’t seem to care about these data and everything is going well. So, it is logically rejected since the Nik plugins cannot load RAW files.
#Viveza 2 save file problems software#
The software is loading a 16-bit uncompressed TIFF file but there are indication in the metadata that this is actually a compressed RAW file. Not a big surprise that this generates a bit of confusion in Viveza. So, it seems that all these metadata that are only valid for a RAW file are transmitted to the TIFF file created by DPL.
The XMP-tiff:compression tag added by iMatch indicates Sony ARW compressed.This is also confirmed by the Exif:Compression and Exif:Bits per sample fields. The TIFF file provided by Tom was obviously seen as 16-bit uncompressed in Photoshop.This can possibly indicate a bug in iMatch. Given the export options that are used by Tom when sending the file to Viveza, the TIFF file is also uncompressed (but here, we are talking about internal TIFF compression, not about internal RAW compression). But once it is loaded in DPL, it has been decompressed. As explained below, the initial RAW file is a compressed RAW file. But the image itself isn’t decompressed yet and now Viveza can read it? That would mean the tiff was uncompressed and the compression tag showed wrong info, isn’t it? I understand you removed xmp-tiff:compression tag. Just to confirm the above : if I remove the XMP data added by iMatch from your _DSC0371_Nik.tif file, Viveza can load it without a hitch.
These added metadata are likely to put Viveza into trouble, I guess. In other words, the RAW file that you have made available to us is not the RAW file that has been submitted to DPL The latter has been touched by iMatch and this is probably the cause of your problem. Since they cannot be added by DPL, it seems that the file that has been submitted to DP元 is not actually the original RAW but a RAW that has been handled by iMatch which added a lot of metadata to it. Note that these data are not present in the original RAW file. So, I looked at these data and I observed that they have been apparently created by iMatch. Mine had no data in the XMP section of the metadata and yours had a lot of data there. Normally, these files should be (almost) identical. So, I had 2 _DSC0371_Nik.tif files : the one that I had just created and yours, that I had just downloaded. Starting from the very same RAW file, I exported to Viveza using the same export settings as you : 16-bit uncompressed TIFF. Since this is a very interesting case to investigate, I did the following :
So, I can’t understand why DPL would create 2 different files starting from the same RAW. This is very strange because when I export your original RAW to Viveza from DPL 3, there’s no problem. From what I see, this file has been exported in 16-bit uncompressed mode. I downloaded this file and indeed, I cannot load it in Viveza 2 (just to be sure : I’m assuming that you are using the current DxO version, not an older Google version ?). I also attached the screenshot of the Viveza rejection message. Here’s a link to that TIFF file that P元 creates.
0 kommentar(er)
