There ia a great discussion under the same topic but using IMatch 2020 and PL4. Refer to the link https://www.photools.com/community/index.php?topic=10751.0 (https://www.photools.com/community/index.php?topic=10751.0)
As there is now a new updated version of DxO being PL5 and IMatch 2021 I thought I would add a few warnings following my experiance the last few days. My workflow includes as follows:
Open files in the camera with FastRawViewer to view the RAW image (not the JPEG) to rate (using stars) and marking for keeping or deletion.
Copy the "keep" files into IMatch under a folder yyyymmdd_Place and once I am sure nothing got corrupted in the copy process I delete and reformat the camera disc.
In IMatch I add the keywords I want under a hierarchical structure that allows me to find the photo again. RAW files are my master copies and I never delete these as I have already culled those I don't like or want.
Now I open DP5 and process my 5-star and 3-star RAW files saving as a JPEG that gets stacked in IMatch. (My 1-star and 0-star files are kept for a rainy day when you are bored and stuck indoors). Often I export as a TIFF into NIK Collections and do a bit more tweaking but then still save the final output as a JPEG. I don't delete the TIFF as you can go back and re-edit later if you want to.
When viewing files in IMatch I turn on the filter and view JPEG only (also filtering star ratings) which then hides the RAW and TIFF files cleaning up the screen for viewing.
Easy and simple until DP5 came along with its DAM version. So this is where the warning is:
Processing from RAW to JPEG keeps the keywords perfectly unless you have synonums. DP5 turns the synonum to a parent keyword so when reading back into IMatch you now have your keyword still under the hierarchical structure but you also have a new seperate parent keyword.
Processing from RAW to TIFF using NIK Collections takes the parent keyword in your hierarchical structure and turns it into a parent keyword being a seperate keyword with the same result as above.
I would therefore suggest turing off the keywords in DxO for now until they solve this issue. I have raised this with them and am awaiting a response.
In the meantime keep up the great work Mario. Still to find a better DAM software out there that can compete with what you have.
Regards
Andre
Quote from: Andre on October 29, 2021, 12:20:18 AM
I would therefore suggest turing off the keywords in DxO for now until they solve this issue. I have raised this with them and am awaiting a response.
In the meantime keep up the great work Mario. Still to find a better DAM software out there that can compete with what you have.
I use PL5 also. For anyone using IMatch, I would
strongly recommend avoiding any use of PhotoLab's metadata management at this time. DxO has taken some initial steps toward metadata management, but as IM users are well aware metadata is a very complicated mess with many pitfalls. The things DxO has implemented so far may be fine for users who haven't dipped their toes into the metadata ocean, but they aren't in the same league as a real DAM like IMatch.
I very much agree with John (jch2103). I've been using IMatch since 2006 (I think that's about when it was) and DxO PhotoLab since version 2. I've stayed with IMatch all these years while upgrading from PL2 to PL3 to PL4 and now PL5.
I use PhotoLab for its strengths which is raw processing.
And likewise I use IMatch for its strengths which is image and Metadata management.
By using file relation versions and stacking in IMatch it doesn't matter to me what PhotoLab does with metadata while exporting images. Upon import IMatch updates the newly exported from PhotoLab (and Affinity Photo) JPG images to ensure the metadata, including keywords, is exactly as it should be.
QuoteProcessing from RAW to JPEG keeps the keywords perfectly unless you have synonums. DP5 turns the synonum to a parent keyword so when reading back into IMatch you now have your keyword still under the hierarchical structure but you also have a new seperate parent keyword.
I don't understand. Can you elaborate?
Synonyms are a concept of the IMatch thesaurus. When you assign synonyms to a keyword in the thesaurus and you later assign this keywords to a file, IMatch adds the keyword and additional keywords produced from the synonyms. XMP has no concepts for synonyms, it only knows flat and hierarchical keywords.
For example, a keyword
Location|beach with the synonyms
Strand and
playa produces the following
keywords:
Location|beach
Location|Strand
Location|playaThis is what will be written to the file.
IMatch still
knows which of these keywords are synonyms via your thesaurus and will indicate them as such.
What does DxO change here?
Hi Mario
The best way to explain this is if you have an @Keywords structure as follows:
LOCATION (parent)
beach (child keyword) with the synonym (strand)
and you process with DxO and Nik Collections and then read the final JPEG back into IMatch you then have the following @Keywords structure:
LOCATION (parent)
beach (child keyword) with the synonym (strand)
BEACH (new parent)
STRAND (new parent)
LOCATION (new parent)
but if you process with DxO only (not use Nik) and then read the final JPEG back into IMatch you then have the following @Keywords structure:
LOCATION (parent)
beach (child keyword) with the synonym (strand)
STRAND (new parent)
DxO needs to do a lot of work to correct the way their software reads and writes keywords as I also tried to read some of my photos into DAMINION after adding keywords in IMatch and found it correctly read my keyworsd and added the synonyms correctly exactly as it was in IMatch. (I used to use DAMINION as my DAM software until I found IMatch). Hence my warning to all IMatch users not to get DxO to write keywords yet as you will constantly need to clean up the @Keyword structure. This is not a fault of IMatch but rather DxO having a lot still to do.
Hope this explains things better.
Hm, that's not really that good.
There are many, many things with metadata processing which can cause issues.
But hierarchical keywords is a quite simple tag, basically a bag of strings using | to indicate hierarchy levels.
I wonder what else they do.
Can you send me an original and an image processed with DxO and Nik Collection so I can do a comparison? You can send the files to support email address (https://www.photools.com/support/) (please also include a link back to this thread, because I get many emails per day).
The problem is that XMP has two sets of keyword (flat) and hierarchical. Which must be synchronized somehow.
And if the file also has legacy IPTC metadata (and many older images have), you have to deal with a 3rd set of keywords (which even has length limits).
IMatch internally uses hierarchical keywords, because the the most flexible variant.
And when it flattens the keywords in the "XMP subject", it offers several ways to do this (See Edit > Preferences > Metadata).
These options allow users to best match the requirements of their other applications.
When importing metadata from images, IMatch uses it's universal thesaurus and some smart algorithms to cross-reference and import hierarchical and flat keywords. To avoid producing duplicates or accidentally creating additional top-level keywords from flat hierarchical keywords. This is tricky and requires care...probably here your other software has some work to do.
Dealing with this (and the many, many other metadata pitfalls) is hard. Really. And requires constant changes and additions.
it is also totally unsexy.
It is never tested in magazine reviews or examined in the cool YouTube hype videos.
It cannot be shown in ads or comparison tables with other products - which is what product marketing cares about (https://www.photools.com/community/Smileys/photools/ashamed03.gif)
Hence, even prominent products skimp in this area or even totally disrespect standards, to make things easier for them. Or to look customers in to their product or service.
Users often only notice this when they look at their files in other software. And then find metadata missing, wrong or damaged.
Since IMatch is using the awesome ExifTool and actually cares for all this metadata stuff, I recommend only using IMatch or an equally complete and capable software to modify the metadata in your images.
Your advise is sound and I fully agree.
Hi Andre,
Thanks for the heads up. I use a similar approach: in FastRawViewer I scan my SD-Card and copy the files with a shortcut to the target folder where iMatch is importing it. When I want to edit a file in DXO, I use an automation favorite: save metadata + open in DXO, to make sure Metadata is up to date before sending it to DXO.
Another issue with DXO PL5 I found:
it seems that on export the TimeZone tag "OffsetTimeOriginal" is (always?) written with = 00:00 instead of the correct time zone (like +02:00). In some cases PL5 did also not write "XMP-photoshop:Main:ID-DateCreated" parameter (the first one iMatch uses for Date/Time taken) and then IMatch falls back on other date time parameters (involving OffsetTimeOriginal) which then results in a timeshift of date taken date in iMatch.
On DXO PL4 this was working without issues. I have opened a bug report at DXO here: https://feedback.dxo.com/t/pl5-wrong-timezone-on-export/21935 (https://feedback.dxo.com/t/pl5-wrong-timezone-on-export/21935), so hopefully this will be solved with one of the next patches.
Until this is fixed I won't be using PL5 because I fear that PL5 will mess up the date/time settings and it's no fun to detect and fix those afterwards...