Tif file not recognized?

Nik Collection Nik Viveza topics
42

That means you’re writing data to the raw file. Have a look in iMatch. I think you can write keywords to the iptc section solely. The iptc section is a section that just describes the content. I shoot with a Nikon. Up to the D700 I could use CaptureNx to add keywords directly to the raw file. For the D750 I tried to use Exiftools but then I learned here that ViewNx is still doing it with the D750. So when I download the images to my pc I open them first in ViewNx, rename them and add some keywords if I want.
PL reads those keywords but refuses them to write in a iptc section. PL stores them together with the keywords I add in PL in the xmp section. A pity.

George

43

From iMatch:

“By default, IMatch uses MWG-compliant options. It reads and writes IPTC, EXIF, GPS and XMP metadata for these formats: JPG, PSD, DNG, GIF, PNG, TIFF, THM, PDF, DJVU (XMP only). For all other file formats, IMatch stores XMP data in external . XMP sidecar files and does not write IPTC, EXIF, or GPS data.”

Wouldn’t that mean an XMP sidecar only for ARW files?

44

Interesting. You just have to check whether this sidecar file exists (look for a file with the same name as the ARW file and with the XMP extension in the same folder as your RAW file) and what’s inside. If the RAW file is not modified and if the iMatch metadata are stored in a sidecar file, this means that DPL adds the contents of the sidecar file to the TIFF file metadata when exporting to Viveza. If confirmed, this would have to be discussed.

45

Yes, all the ARW files have an .XMP file with the same name.

Earlier I was fooling around with other applications deciding which one to go with. Stuff like RawTherapee, ACDSee, PhotoSupreme and one or two others. That _DSC0371 file that has caused problems also has some other, I assume, sidecar files like PP3 and DOP in addition to XMP. They must be from one of the other apps I tried out. Maybe that has caused some problems?

46

Tom,

I’d like to have a look at _DSC0371.xmp. The mere existence of this file seems to demonstrate that the problem could be (partially) on the DPL side, as suggested by George. It doesn’t seem to be very picky about which metadata should be imported from the XMP file when creating the TIFF file. I also need to look at _DSC0371.arw once it has been imported into iMatch. just to make sure that the metadata created by it are not also stored in the RAW file (that is, to make sure that this file is still the same as the one you have on your SD card).

Thanks.

47

Hi Patrick,

Here’s a link to _DSC0371.arw and I attached the _DSC0371.xmp file.

https://drive.google.com/file/d/1WbYZJb-lfOWxEOsdZXitHtrK9daSvEvu/view?usp=sharing

I wonder if it might make sense for me to shoot a new RAW file since this _DSC0371 has been touched by several different applications.

Thanks,
Tom
_DSC0371.xmp (5.9 KB)

48

The xmp file causes the problem.
DP is just copying the data to the tiff but the tiff is another file.

George

49

Sorry, I’m lost here. What’s DP? IMatch creates the xmp so it’s the problem?

50

Tom,

OK. Thanks, this makes it easier to understand/explain what’s happening.

So, we have to ARW files : one coming directly from your SD card and one stored on your disk and imported by iMatch : they are both strictly identical (I have done a binary comparison). Which means that iMatch doesn’t touch your ARW files. Instead, the metadata created by iMatch are added to a sidecar file (XMP file). Since the image had already been processed by Photoshop and Lightroom, we also find in that XMP file metadata created by these programs. Normally not a problem. But…

When an image processing application adds metadata to an XMP file, it normally does this within what’s called a namespace in XMP parlance. That is, these metadata are identified by a special tag in the XMP file : the xmlns tag (xmlns standing for XML namespace). So, in your XMP file, you can see different xmlns sections like xmlns:photoshop or xmlns:lr, indicating that the metadata in this section have been inserted by Photoshop and Lightroom respectively. You can open an XML file in any text editor like Notepad to check this. It’s pure text.

So, normally, we should find xmlns:imatch tags (or something equivalent) in that XML file. This is not the case. When reading or writing metadata in XML files, most major applications use their own code. The iMatch developers don’t seem to have written code to do this. Nor they have used a specialized code library that they could have embedded in their code. Instead, for all these operations, they are using an external program called EXIFTOOL. This is a very popular free program specialized in such operations. Maybe there’s no option in EXIFTOOL to identify data with a custom namespace or maybe the iMatch don’t care about maintaining their own XML namespace but the final result, as I already mentioned in a previous message, is that the iMatch metadata are not “isolated” and cannot be identified as application specific metadata. They belong to the generic XML namespace. IMHO, this is a problem but this is not the cause of the problem you reported as I first thought.

When DPL 3 is asked to send an image to a Nik plugin (or to another external application), it creates the TIFF (or JPEG) file according to the user’s export settings. It doesn’t touch the metadata already present in the RAW file and copy them to the TIFF file metadata. If an XML file is present, it also reads the contents of that XMP file and adds the contained metadata to the TIFF file.

You now have a TIFF file containing the initial metadata from the RAW file and all the metadata added by the external programs to which this image has been submitted. There’s normally no problem with this. When the TIFF file is submitted to any Nik plugin, the plugin reads the TIFF file metadata and extracts the data it needs. The Nik plugin is also able to isolate data written by third-party apps thanks to the xmlns:xxxx tags. It seems to be also able to ignore unknown metadata fields added to the standard xmlns namespace. So, nothing problematic happens.

So why is there a problem with Viveza ? My first conclusion was that the metadata coming from iMatch were the culprit. But it’s not the case because just removing the XMP-tiff:compression metadata entry is enough to fix the problem. I was wrong and the answer is more simple : Viveza is sensitive to this metadata entry (which doesn’t come from iMatch) and it thinks that the file is compressed in a Sony specific format while the other plugins just ignore it. So, it just rejects the file.

So, there’s a problem at 2 different levels :

  • As mentioned by George, is the non-filtered transfer of all the metadata contained in the initial RAW file to the TIFF file legitimate ?
  • Should Viveza behave like the other plugins and ignore that problematic metadata entry which is not relevant for a TIFF file ?

The second approach makes it easier to fix the problem. I have posted a request for making Viveza consistent with the other plugins. The first approach is globally preferable but requires a very sophisticated analysis of the RAW file metadata. I really doubt that the DxO team will ever try to implement this approach.

51

Note that the Sony Compressed RAW information is initially in the Exif section in the RAW file but in the XMP-tiff section in the TIFF file. It never appears in the XMP file. Thus, this entry is generated by the TIFF creation routine in DPL. This is questionable. Also, this information should be inserted in the Maker section of the metadata by the camera, not in the EXIF section. This is also questionable.

52

As far as I understood iMatch creates a xmp-file out off data from the arw file.
https://www.photools.com/help/imatch/content/en/topics/md_writeback.htm.
If one can prevent iMatch from copying/duplicating that data that’s already in the raw file, then the problem might be solved.
So easy to just add keywords in a dedicated iptc section. Why is that called old fashioned??

@thusband
DP should be DPL or PL: photolab.

George

53

Whew, you’ve done a lot of investigating.

It must be one or more of the other programs I tried that added xlmins tags to the ARW file as I don’t have Photoshop or Lightroom.

I believe it’s iMatch policy to not make the metadata proprietary so you’re not locked into iMatch.

What puzzles me still, though, is how come I can take _DSC0371.arw open it in Affinity, process it to a TIFF and then open it in the same Viveza2 without any problem? What would Affinity do differently?

We could probably try to beat this thing to death but I’m just going to not use Viveza in PL3.

Thanks again for all your sleuthing, I’ve leaned quite a bit.

54

I investigated the case further and noted another interesting thing.

If I send the ARW file to Viveza in DPL 3 without having the XMP file present, there’s no problem. The TIFF file is opened in Viveza and its metadata do not contain the XML-tiff:compression/Sony compressed RAW tag/value pair (probably because the RAW file itself stores this information in the Maker section of the metadata, not in the XMP section).

Now, if I add the XMP file to the folder where the RAW file resides (still using the _DSC0371 files), Viveza rejects the TIFF file because of the XML-tiff:compression tag although the XMP file itself does not contain this information.

So, DPL behaves differently regarding metadata transfer from the RAW file to the TIFF file depending on whether an XMP file is present. If it’s not, DPL seems to ignore at least partly the contents of the Maker section (which is logical since these data are normally not necessary and used only by the maker software). But if the XMP file is present, DPL seems to change its behavior and is obviously retrieving info from the Maker section of the RAW file.

No idea why they need to do this but this is causing the problem in case the called plugin or external application doesn’t know how to handle this situation (as described in previous posts).

Yet another demonstration that metadata handling in images need more standardization.

I can’t do more about this issue which I have forwarded to the support with a reference to this thread. But this was interesting.

You have the explanation above. Affinity probably doesn’t use any data from the Maker section of the RAW file. I’ll check this.

55

Confirmed.

56

Some info about IMatch behaviour on RAW files without reading the whole thread.

IMatch might change the metadata of a RAW file, if IMatch (or Exiftool in the background) find some information, which needs to be mapped to fields already existing in the RAW file.
It might be GPS coordinates or a star rating.
Almost all IMatch user report, that this behaviour is not causing problems for them.

IMatch might also do this if you change its settings not to do so (but leave MWG conformity=Metadata Working Group conformity on). Using IMatch with this setting off not supported by the developer.

I use IMatch with this setting on, but I make my RAW files filesystem read-only before importing them, so only the XMP files will be changed (but my CR3 would be changed if not read-only).

This MWG also defines tags from EXIF to get mapped to XMP.

All this is written to the documentation as “IMatch is MWG conform” and in some paragraph writing to RAW files is also mentioned, but it is not obvious to most user.

As already said, it is not a problem for most user, but there is a minority (depending on the used RAW format) who has a problem with this behaviour.

57

I have just had this problem with using Digikam. I switched to this a few days ago in preference to FRV so I can tag my images better. Even when the Digikam box is ticked “Write to xmp only” (ie no writing to any part of the CR2 file) it fails.

I tag as needed in Digikam and then send it to PL3 do what I need and then try and send it to Viveza. If the xmp file is present it fails, and no tiff file is created.

If I don’t tag it with anything, then Digikam->PL3->Viveza works fine.

Like you, Digikam->PL3->Affinity->Viveza is no problem with the xmp file preset.

Not a real killer for me as my workflow is usually Digikam->PL3->Affinity and then Nik plugins anyway, but occasionally I have no need to have the Affinity step. Guess now I have no choice!

Still a nuisance though.

58

Thanks, glad to know I’m not the only one.

59

That’s interesting because this might reveal another (different) problem, especially because no TIFF file has been created. If you could make the RAW file available along with the corresponding XMP file, I’d spend some time looking at this. When you say “it fails”, could you please describe what’s exactly happening ? Do you receive an error message from DPL ? Which one ? Please also mention your export settings when sending the image to Viveza (bit depth and compression option).

Also, could you please confirm that you have this problem only with Viveza, not with the other plugins ? From what you explained, since the crash occurs before any TIFF file has been created, I understand that the problem should occur when sending the image to any plugin or to any external application. In this case, this would mean that this is a problem completely different from the one reported by thusband.

1 Like
60

Ran a few tests earlier. Here are the results.

File sent from Digikam to PL3 and then on to Viveza.
image

No compression of any kind used, just normal settings from PL3 to Viveza.

Result is it fails.
image

The TIFF files is created by PL3 as normal.

image

Deleted the TIFF file and then sent to CR2 from Digikam to PL3 and then on to ColorEfex4.
Xmp sidecar file is present as before. Work perfectly

image

TIFF file is created by PL3 as normal too.

image

Final test. Close PL3, delete dop and xmp sidecars and TIFF.

Resend CR2 from Digikam to PL3 and then from PL3 to Viveza.

Viveza opens fine.
image

As the process works for ColorEfex4 with an xmp file present but not Viveza when an xmp file is present, but does work for Viveza when the xmp is absent, it seems logical to conclude that Viveza is having an issue with xmp sidecars.

kind regards
Stephen

61

So, it seems that we have to disregard your statement about the TIFF file not being created ?

If possible, I’d like to have a look at the XMP file. All of this confirms the idea that making Viveza consistent with all other Nik plugins would solve many potential problems.