Tif file not recognized?

Tom,

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 ?). From what I see, this file has been exported in 16-bit uncompressed mode.

This is very strange because when I export your original RAW to Viveza from DPL 3, there’s no problem. So, I can’t understand why DPL would create 2 different files starting from the same RAW. Since this is a very interesting case to investigate, I did the following :

  1. Starting from the very same RAW file, I exported to Viveza using the same export settings as you : 16-bit uncompressed TIFF. So, I had 2 _DSC0371_Nik.tif files : the one that I had just created and yours, that I had just downloaded.

  2. Normally, these files should be (almost) identical. But this was not the case. Mine had no data in the XMP section of the metadata and yours had a lot of data there. Which is rather strange.

  3. So, I looked at these data and I observed that they have been apparently created by iMatch. Note that these data are not present in the original RAW file. Since they cannot be added by DPL, it seems that the file that has been submitted to DPL3 is not actually the original RAW but a RAW that has been handled by iMatch which added a lot of metadata to it. 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. These added metadata are likely to put Viveza into trouble, I guess.

Please confirm.

[EDIT]
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.

1 Like

Strange. My messages are posted immediately. I’m not aware of any approval mechanism. Maybe for new users ?

Quoting the forum rules :

In order to maintain our community, moderators reserve the right to remove any content and any user account for any reason at any time. Moderators do not preview new posts; the moderators and site operators take no responsibility for any content posted by the community.

See the Forum Management section.

George

OK. I see. I have escalated the problem.

1 Like

My posts most certainly go through an approval loop. So far I’ve made thirty or so posts and all had to be approved which can, sometimes, drag on for days.

Wow, thanks @Pat91! That’s it. I took a new RAW image and opened it in PL3 right from the camera SD Card. Then opened Viveza2 which loaded the TIFF without issue. If I then add some keywords in iMatch and try again Viveza chokes. However I can move that RAW file with the modified XMP data from PL3 to Affinity, convert to TIFF and it opens just fine in Viveza. So is problem with the PL3 conversion to TIFF since it’s OK in Affinity?

Irregardless, I’ll stop using Viveza in PL3 since I want to continue to use iMatch.

Thanks so much for all your time.

Actually, just removing the XMP-tiff:compression field in the metadata is enough to fix the problem. In your file, it is set to “Sony ARW compressed”.

So, I guess that you are launching DPL 3 from iMatch. In this process iMatch adds its own metadata to the RAW file. I’m not an iMatch user but I think that you have an option to prevent iMatch from touching the RAW files. More generally, RAW files should always be left untouched. At least, you should have an archive containing your unmodified original files.

I’ll report the problem anyway. Viveza should be able to handle this as it does for the other Nik plugins.

Oooops ! I posted my answer before yours was available for reading.

No, the problem is not with DPL 3, it’s with Viveza and iMatch. This plugin doesn’t belong to the same generation as the other Nik plugins. It’s a very old one. The other plugins don’t care about the additional metadata added by iMatch. So, Viveza should be made consistent with the other plugins (there are also other inconsistencies between Viveza and the other plugins, by the way. But, if not absolutely necessary, you should not let iMatch alter your RAW files.

Glad to have this issue fixed.

@Pat91
I understand you removed xmp-tiff:compression tag. 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?

Windows file browser shows not compressed to me.

George

I think what I’ll do is shoot uncompressed. I just tested it out and iMatch, PL3 and Viveza all work together. Double the file size but that’s OK.

Many thanks.

Yes, there’s a bit of confusion there. As explained below, the initial RAW file is a compressed RAW file. But once it is loaded in DPL, it has been decompressed. 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).

This can possibly indicate a bug in iMatch. I checked again and I observed this :

  • The TIFF file provided by Tom was obviously seen as 16-bit uncompressed in Photoshop. This is also confirmed by the Exif:Compression and Exif:Bits per sample fields.
  • The XMP-tiff:compression tag added by iMatch indicates Sony ARW compressed. This obviously indicates that the original file uses a RAW compressed format but this has nothing to do with internal RAW compression. And there’s anyway nothing compressed in that TIFF file.
  • The XMP-exif:Compressed bits per pixel field says : 8.
  • The Sony:Quality maker field says : RAW and the Sony:RAW file type field says Compressed RAW which is irrelevant for a TIFF file.

So, it seems that all these metadata that are only valid for a RAW file are transmitted to the TIFF file created by DPL. Not a big surprise that this generates a bit of confusion in Viveza. 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. So, it is logically rejected since the Nik plugins cannot load RAW files.

However, the other plugins don’t seem to care about these data and everything is going well.

This is another opportunity to recommend not altering original RAW files. This is always a source of trouble. Companion/sidecar files are much better. I’m wondering whether iMatch gives the choice between storing data in the RAW file or in a companion file or in its own database. If this is the case, the first option should be avoided.

I have had a quick look at the iMatch documentation. It is apparently possible to instruct iMatch to write metadata in an XMP companion file instead of writing them into the RAW file itself. I recommend this. I have noticed that iMatch doesn’t identify the XMP data he writes to the RAW file as being iMatch specific. This can generate confusion. Photoshop, Mediapro, Microsoft, ACDsee… create XMP-Photoshop, XMP-Mediapro, XMP-Mirosoft and XMP-ACDsee metadata sections respectively. So, their specific data can be isolated and safely ignored by other software. iMatch is not as cautious. So, probably Viveza considers these data as standard XMP data and fails to correctly interpret them.

There’s another reason for which RAW files should be left untouched. Cautious photographers use to make frequent backups of their images (I do this automatically every day). Many of them use an incremental backup mechanism in order to only backup the files that have been changed. When using such a mechanism, touched RAW files will be backed up. Since they are usually big, this can lead to unnecessary heavy and lengthy disk activity. If the RAW files are left untouched and if the metadata are stored in a companion file, only these small XMP files will have to be backed up. This will make incremental backups much faster. Long backups discourage the user to launch them, fast backups are usually done more regularly.

My two cents.

1 Like

I’m new with all of this so will have to look into separate XMP sidecar files in iMatch. To tell the truth I’m not even sure what I’m using now. Probably whatever the default was in iMatch. I really don’t want to leave the RAW files without any metadata written back or down the road it’ll be impossible to find anything after I accumulate a couple thousand files.

edit: Checking it looks like iMatch uses separate XMP sidecar files for the RAW images. All my ARW files have XMP sidecar files. I believe it’s the default unless the file doesn’t allow it then it embeds the XMP data.

I really appreciate all the effort you’ve put in on this.

Hi Tom - - The following is somewhat of a tangent from your situation, but I am intrigued …

Since PL introduced Local Adjustment capability (some while ago) I no longer use Viveza - because anything I used to achieve with Viveza, I can now do within PL (and without all the hassle of having to pass an intermediary file between the two, etc).

So, I’m interested to understand; what is Viveza doing for you that you cannot achieve within PL ?

Regards, John M

Hi John,

Truthfully I’m not sure but I wanted to find out. I’m new to PL3 and the Nik plugins. I’ve been out of photography for several years but it’s pulled me back in. I didn’t, however, want to go back to Lightroom/Photoshop so I settled on PL3, Nik and Affinity. There have been a few videos where Viveza was used so I wanted to try it out. That’s when I went down the rabbit hole.

You showed 2 different arw files. The one you did have trouble with, post 17 or 18, and the one you uploaded for us.
The last one didn’t give trouble.
If the one that you used in post 17 does contain keywords, then they must have been added to the arw file by iMatch and thus the total xmp section.
How many examples of that arw file doe you have on your pc?

George

I use exactly the same 3 tool-sets, Tom … but I stay in PL for as much as I can, because stepping outside creates extra hassles (such as you’ve encountered) and disrupts the ideal of a non-destructive workflow (making it harder to come back at any time and take-up where you left off without having to redo any steps).

Of the Nik collection, I use Color Efex Pro only for “special” images that warrant the extra attention, and Silver Efex Pro for mono/B&W images … otherwise, in my opinion, I reckon all other capabilities are well covered from within PL.

I use Affinity just for panorama stitching and focus stacking - it does both very well.

John M

I only have one RAW file right now but I’ve been playing around with all my applications so much that I could have easily created a duplicate.

Tom

Right. PL seems to be easy to use and the raw converter is supposed to be the best. I find Affinity very interesting for its layers and masking capabilities. The one Nik application I really like is Silver Efex Pro 2. Lots to learn though.