Yes, my error earlier about the TIFF not being created
As a quick check, I tried Digikam -> PL3 -> Viveza (failed) and then Digikam -> PL3 -> SilverEfex (worked)
I found the following line in the xmp file:
tiff:Compression=“6”
Changing the 6 to 0 and then the process works and Viveza opens.
Examining where this compression comes from, it seems to be from Digikam, and NOT PL3.
Simple test was to close PL3 and then delete the dop and xmp files. Make some changes to the tags in Digikam and then “Apply”. A new xmp file is created and it is this that contains the compression value that is causing the issue.
Using an old file I haven’t yet sorted with Digikam:
FastRawViewer -> PL3 -> Viveza is no problem.
In short, something is happening with the way Digikam creates the xmp files that is causing the problem and NOT PL3 as I thought.
Hope this helps.
Doesn’t help me though, I have now to try and work out what the hell Digikam is doing! But that is another story.
Stephen
tiff:compression=6 means JPEG compression. Other recognized values are as follows :
1 = No compression
2 = CCITT modified Huffman RLE
32773 = PackBits compression, aka Macintosh RLE
3 = CCITT Group 3 fax encoding
4 = CCITT Group 4 fax encoding
5 = LZW
6 = JPEG
Obviously, there’s a problem with Digikam.
0 not being recognized, I guess that’s equivalent to 1. That’s why there’s no problem in Viveza.
In your case, there’s a good reason for Viveza to reject the file since it doesn’t support compression and the TIFF file (which has probably incorporated the XMP contents in its metadata) wrongly claims to be JPEG compressed. So, only tiff:compression=1 (or 0, obviously) are accepted.
1 Like
As far as I can see the main problem is wrong info in the xmp section added to the tiff by dxo. So why not changing that in the first place?
A second thought is what will happen when there’re two equal values in the exif and the xmp. Which one is to be used?
George
This is true for the case reported by thusband. What tilltheendofeternity describes is a bug in Digikam. Regarding the former, I explained above that we have 2 ways of fixing the problem. Quoting myself :
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.
Given the lack of real metadata standardization, I’m not sure that safely analyzing the metadata in the original RAW file in order to determine what information should be transferred to the TIFF file is merely possible. Of course, adding the Sony compressed RAW information to a TIFF file is a mistake but this is just an example. If I had to write code to clean the RAW file metadata before exporting to a TIFF file while safely preserving data that could be important for the external program, I would be embarrassed.
So, IMHO, since the other Nik plugins to not suffer from these issues, the short term solution is to make Viveza consistent with the other plugins regarding the metadata handling. It’s just a matter of replacing a block of code with another.
It depends on the software used. Some applications allow you to specify if XMP has priority over embedded metadata or reversely. Some applications allow you to sync metadata between XMP and RAW file (one-way or two-way). Capture One is the most flexible in this area. DPL has a single option allowing to preserve the XMP metadata.
Oooooooops ! Wait a minute…
If I disable this option, the test file provided by thusband is loaded in Viveza without any problem even when the XMP file is present. In that case the metadata in the XMP file are not embedded in the TIFF file.
@thusband
Maybe it’s a simple solution to your problem. I should have remembered this option sooner.
The tiff file is created by dxo. It’s a new created image and dxo is adding a value to that file, compression, that should never be there.
And as you said the compression value isn’t in the old xmp.
Doesn’t disabling xmp in dxo also means keywords aren’t added to the tiff since it doesn’t write iptc?
George
Agreed. And I admit that it’s a problem/bug. But if you read my explanations, you’ll understand that fixing this is not necessarily very easy, to say the least. Meanwhile, the short term solution is to make a few changes in Viveza OR to disable the XMP option in DPL if this doesn’t generate too much trouble.
Yes, Patrick, that works! However wouldn’t I want to keep XMP information like ratings from other applications?
Thanks a lot.
Your choice. You shouldn’t have to chose between not being able to launch Viveza and discarding valuable metadata but currently Viveza doesn’t behave as the other plugins. Until this is fixed, you’ll have to chose between unsatisfactory solutions, I’m afraid.
George is correct when saying that the bug is with DPL because it transfers wrong/unnecessary data to the TIFF file. However, the other Nik plugins are not affected, which means that they ignore these data. Viveza should do the same.
Thanks. At least I have some idea what I am looking for with the Digikam issue 
I don’t know what the rules are. It could be that Viveza is acting in the right way and the others not.
But what is for sure is that the tiff export of dxo must be corrected. Both have the same owners.
George