Import Metadata for NEF files

[UdoL]

I encountered a problem with metadata import for NEF files:

I exported the records of a category in my old MediaDex database, containing 95 pictures of several folders on my HD and containing genuine jpg's, NEF's and jpg's processed from the NEF's using Nikon Capture.

• First I imported the pics of a folder with only genuine jpgs. Then I made an csv import of the keywords of all 95 pictures. This went very well, the hierarchical keywords were correctly imported for the pics of this folder
• Then I imported the pics of a folder (and sub folders) with NEF files and jpg files created with Nikon Capture out of the NEF's. Again I did a csv keyword import but this failed - no keywords here.
• After some guessing and trying I retried the import of pics and keywords of another folder containing only genuine jpg's. This again worked perfectly!

Having read in the help your notes and configuration examples regarding embedded metadata in NEF files with Nikon Capture I assume this could be the problem (I used standard configuration for NEF and jpg) because only NEF's and derived jpg's were affected. But firstly I don't understand why this would be a problem in my case, secondly I don't understand why it didn't work either with the derived jpg's.

Thirdly I don't work any more with Nikon Capture. So I wouldn't like to follow your recommendation "XMP sidecar file: Embed XMP in file" because the problem only exists for older but never for newer files. Can you help me out of this metadata jungle?

[Mario]

IMatch automatically imports keywords from existing legacy IPTC metadata and XMP metadata. I don't know what you are doing with CSV here?

JPEG files may contain keywords in legacy IPTC data embedded in the file. They may also contain keywords and/or hierarchical keywords in the XMP record embedded in the file. By default IMatch automatically imports all this data, merging IPTC into XMP as specified by the metadata working group.

NEF files may contain an embedded legacy IPTC record (with keywords).
If you have used Nikon Capture, they also may contain an embedded XMP record.
If you have used other software on the NEF files, the probably have an external XMP record. This is the standard for RAW files, only Nikon ever was so dumb as to embed XMP in RAW files.
If you have used both Capture and other software which works with external XMP files, you may end up with two XMP records for the same file. Solutions for this case etc. are detailed in the IMatch help.

The default settings in IMatch are based on the recommendations for metadata processing by the Metadata Working Group, and also compatible with standard DAM and imaging workflows. This means that IMatch favors metadata in XMP sidecar files for RAW files, and expects JPEG to have embedded XMP. IMatch detects and imports existing legacy IPTC, EXIF and GPS in RAW and JPEG files.

[UdoL]

Thanks for your answer, Mario. Today I found out that my assumption was completely wrong. I believed that it had to do with Nikon Capture embedded metadata because only such files and their jpg derivates were affected. The truth is that in MediaDex for some reason the case sensitivity for one folder of the path was wrong exactly for these files by chance but for the other files was right. Having corrected this all went fine during import to IMatch.

Why I mess around with csv import at all instead of extracting embedded metadata? Because in my old system I only had a category tree without writing the categories into the metadata. And now I don't get MediaDex to write the categories in the metadata retrospectively. So now I export txt and import the former categories into the hierarchical keyword tag with IMatch.

Sorry for the wrong assumption and thanks again for your effort - I appreciate that very much!

[Mario]

Make sure that you set the options for repeatable tags correctly when running the CSV import. Then the CSV import script should handle the keywords correctly. Check in the Keyword panel that all keywords are indeed imported as individual items, not just as one long string.