Pre-iMatch workflow

[Sir Nameless]

Hi all,

I have been using iMatch as the hub of my workflow. Images go right from the SD card to the library managed by iMatch, where I do initial culling, initial tagging, file renaming, etc. Metadata changes are set up to write back to the RAW (actually DNG, thank you Pentax) files (I understand the pros/cons) but that's generally done at the end of the workflow before archiving.

I am considering using FastRawViewer for an initial culling (due to the raw histogram, under/over exposure tools, and other aids). It can be used to apply XMP color labels, star and reject ratings, and a title. All helpful things to do on ingest. Data is written to an XMP sidecar file.

When bringing these into iMatch, however, the ratings, color labels, and title are not imported.

What I would like is for iMatch to read the side car file on import, and then ignore it after that. All further metadata changes will be managed by iMatch as I do now. No other software I have needs to use that XMP sidecar. (I could/would delete it after import).

Is there a setting that makes this possible? Any drawbacks to this approach?

Thanks in advance!

[Mario]

IMatch automatically reads XMP sidecar files. And the embedded metadata in your files.

[JohnZeman]

I also use FastRawViewer to cull my new photos and I can confirm what Sir Nameless is experiencing.  I just ran multiple tests using new DNG images where FastRawViewer sends the DNGs and XMP sidecars to IMatch.  Maybe 10% of the time IMatch will read the FastRawViewer created XMP sidecars for rating, label, title and description.  The other 90% of the time IMatch seems to ignore the XMP sidecars.

That said, I never use FastRawViewer that way.

Since I apply an IMatch metadata template upon the import of new images some the metadata entered by FastRawViewer or any other program could (and/or would) be overwritten during import.

In other words I use FastRawViewer for visual culling only.  Then I send the keepers to IMatch where ALL metadata is entered.

[Mario]

IMatch reads XMP sidecar files. The XMP sidecar file must have the same name as the associated image ("beach.jpg" and "beach.xmp").

Things to check:

1. IMatch log file for warnings or errors
2. FRV maybe keeping the XMP files locked?
3. XMP files not in standard format (see 1.)

[Sir Nameless]

Thanks for the responses.

IMatch automatically reads XMP sidecar files. And the embedded metadata in your files.

Well, sure, understood. But it wasn't working, so I'm trying to figure out why. I did spend time in the documentation before posting here.

IMatch reads XMP sidecar files. The XMP sidecar file must have the same name as the associated image ("beach.jpg" and "beach.xmp").

Things to check:

1. IMatch log file for warnings or errors
2. FRV maybe keeping the XMP files locked?
3. XMP files not in standard format (see 1.)

1. File names are correct.
2. Closed FRV to release any file locks.
3. Switched to full log mode and added  new files to database. Viewed the log. Found the entries where the files were being added, and there was no indication of an error. Also searched the file for "error" and "warning" (tried capitalized, and all caps too for completeness sake) with no results.

Since I apply an IMatch metadata template upon the import of new images some the metadata entered by FastRawViewer or any other program could (and/or would) be overwritten during import.

Thanks for corroborating my issue. I'll add that I don't use any automatic templates on import at this time, so at least that isn't what's blanking out the FRV ratings, etc. Also, I have the metadata working group compliance flag to 'yes'.

I'm sure I could use a different workflow, but I'd rather get it to work as expected.

Any other ideas?

[Mario]

Please attach (or provide a download link) of an original image and the XMP file FRV has created.

You may also want to check the original image in the the Metadata Analyst to check the metadata in the image and the sidecar file for problems.

[Sir Nameless]

I took a look at the Metadata Analyst, and the warnings shown were all unsurprising (GPS- my camera is not equipped, XMP- dates and times, copyright (added by camera) and orientation).

Metadata Analyst Results: https://www.dropbox.com/s/p0bc0nouf6silf0/Metadata%20Analyst%20Results%20-%2037612.json?dl=0
DNG: https://www.dropbox.com/s/2uxof3bgprfypkg/IMGP7508.DNG?dl=0
XMP: https://www.dropbox.com/s/egvlcm8am5cs8po/IMGP7508.xmp?dl=0

Thanks for taking a look.

[Winfried]

Sorry, no Problem on my system.

Winfried

[Mario]

The DNG file has embedded EXIF and XMP metadata written by  Adobe Photoshop Camera Raw 12.2.1 (Windows).
There is also a rudimentary XMP sidecar file, which does not even specify which software has produced it.

DNG files must contain embedded XMP data. This is clear from the DNF file format specification and the XMP standard.
Having a sidecar file for DNG files is not recommended. Most applications will ignore it.
Having a sidecar file with XMP metadata for a DNG file which also has embedded XMP metadata is even worse. Because you have created two sources of truth for the metadata in this file.
What if both the embedded XMP and the sidecar XMP have different rating, label, title, keywords?
This is not covered by the standard, which requires XMP metadata to be embedded in DNG files. And JPG, TIF, PSD, PDB, PNG, GIF, ...

IMatch reads the XMP from the sidecar, but by default, favors the XMP data in the image itself. This is recommended.

When I understand you correctly you are using a software for viewing the DNG file and this software allows you to edit metadata? And then produces a separate XMP sidecar file instead of updating the existing XMP data in the DNG itself? I would not recommend that. Maybe you can configure the other software do to the standard things?

Having two XMP records for the same file is not standardized and every application will do different things with that. Not all are as flexible as IMatch, where you can even force the external XMP to override the embedded XMP (not recommended).

Besides this, I see the same as Winfried. The metadata embedded in the DNG is shown. Which is correct.

When I change the data in the XMP file and set a new title, it is not shown. Because the XMP embedded in the DNG has a title, and it has higher priority.
When I force IMatch to prefer XMP data in the sidecar via Edit > Preferences > Metadata 2: File Formats (not recommended), the title from the XMP sidecar overrides the embedded title.
During write-back, IMatch now updates the XMP in the sidecar, not the XMP in the DNG. Which is why this is not recommended.

Recommendation: Only use software to work with metadata which supports the standard. Adding a XMP sidecar file for DNG files is not standard and the results you get will vary between applications. For example, Adobe products will ignore the XMP data in the sidecar.

Hope this helps.

[Sir Nameless]

This does help. Thanks for the detailed explanation of what is going on and why it's not working as expected. It seems like it would be best to do what John Zeman does if I use FRV for culling going forward.

Thanks again!

[Mario]

Proper metadata handling is complex. And often neglected, to the disadvantage of the user.

Unfortunately, this then often boils up in IMatch, where users for the first time see the sad state their metadata is in.
Tip: don't let software touch metadata in your files unless you are sure that the software does the right thing. Ask the vendor.
Processing metadata correctly is complex, a lot of work and totally unsexy. This is why so many applications don't do it right. And the user has the problem.

[Carlo Didier]

This does help. Thanks for the detailed explanation of what is going on and why it's not working as expected. It seems like it would be best to do what John Zeman does if I use FRV for culling going forward.

Thanks again!

Check the configuration of FRV. Maybe you can configure it to write XMP to the image files.