Compatibility with Nikon ViewNX2

[scw2wi]

I am testing IM 5.5.7 if I can use it as a replacement for VNX and it works really fine.

Most of the things I could solve easily, thanks for the perfect online help.
Some things are still strange to me, maybe someone can give me valuable additional hints.

I have chosen the recommended settings to stay compatible to Nikons TAG handling.
I have also gone thru the postings here related to this Nikon topic.
The issue in this thread https://www.photools.com/community/index.php?topic=1582.msg9841#msg9841 I could not reproduce,
sync of metadata between IM and VNX is working in both directions, as far as I have tested it.

These are my IM Preference settings.

As Buddy-Files I have added Nikons NEF and NKS Files.

In "Metadata 2" I have not changed the Basic Settings,
but in Configure File Formats I have changed the settings for NEF and NRF to
XMP sidecar file = Embed XMP in file

the other settings I did not touch.
Write IPTC = Yes
Write EXIF = Yes
Allow create IPTC/EXIF/GPS = No
Use XMP Crop = No
Use data in THM files = No

I hope, these settings are good so far. At least they are working for me.

Here the topics I could not solve.

1. How to configure the Metadata panel to look similar to ViewNX, which I am used to.
I know how to solve this issue, because IM is highly flexible in configuration, but it seems as if this configuration change might take at least some hours for me. So if anybody has configured IM in that way already and could send me such a panel layout export it would be really helpful.

2. Why are not all corresponding XMP/IPTC metadata fields synchronized in IM,
is this a wrong setting in my configuration or any other reason?

e.g.
If I change the XMP Dublin Core Description   in IM
{File.MD.XMP::dc\description\Description\0}

this change is reflected to corresponding fields like
{File.MD.XMP::tiff\ImageDescription\ImageDescription\0}
{File.MD.XMP::exif\UserComment\UserComment\0}

but is not reflected to corresponding fields like
{File.MD.IPTC::ApplicationRecord\120\Caption-Abstract\0} (updated by VNX, but not by IM)
{File.MD.Exif::Main\37510\UserComment\0} (updated on import, but not on change)
{File.MD.Exif::Main\270\ImageDescription\0} (updated on import, but not on change)

Is there any additional description in the online help that I did not found,
how such additional sync can be achieved?

Walter

[Mario]

I haven't used Nikon VIewNX2 for years so I cannot really comment on that.

But I'm sure that it will not take hours to create a custom metadata panel, even for a new IMatch user.
At least IMatch offers you all the data, which is more than can be said about other DAM software.

When I look at the ViewNX2 manual, Nikon displays mostly standard fields, which are already included in the IMatch 'Default' or 'Image Info' metadata panel layouts. You can switch the layout with the drop-down box in the Metadata Panel toolbar. The 'Browser' layout shows all metadata IMatch has imported from your files.

If you want to add some Nikon-specific maker notes, duplicate one of these panel layouts and add the tags you want to see in addition.

Should not take more than 10-15 minutes. The IMatch help system has full details on all aspects of the metadata panel. Let us know if you need help with specific features.

Note that IMatch by default does not import all Nikon maker notes, because Nikon literally stores hundreds of metadata tags in their files, and importing them all would only fill the database with unwanted data not intended for humans to read. If the maker notes you want to see in the IMatch Metadata Panel are not visible in the 'Browser' layout, you can configure IMatch to import these tags under Edit > Preferences > Metadata 2: Tag Manager. See Tag Manager in the IMatch help for details.


IMatch by default synchronizes XMP with IPTC, according to the rules defined by the metadatas working group. If only does this when the file already has legacy IPTC data, because for new files the MWG and IPTC do not recommend to create legacy IPTC data anymore. This is a standard that has been abandoned 10 years ago! You can force IMatch to create new legacy IPTC data by setting the "Allow create" option for your NEF files.

[scw2wi]

Hi Mario,

thanks for your fast answers.

You are right, since I'm only using about 20 Fields in ViewNX, configuration might not be that time consuming.

What is more important to me now is the investigation, what fields are touched by IM in what way.

e.g.

On importing a picture XMP.Description is copied to some other fields e.g. Exif::Main\270\ImageDescription\0
I have verified that also with ExifTool, this copy was not done by ViewNX.

But on updating XMP.Description in IM the new value is not copied to all corresponding fields, e.g. Exif::Main\270\ImageDescription\0

This behavior will result in having the Description value in 6 fields totaly,
3 of them are kept in sync by IM during import and update,
2 are getting the value during import but not the updated value, ending up having an old value,
1 is not kept in sync by IM (neither on import, nor on update) but kept in sync by ViewNX.

My goul is to keep all 6 fields of the original post in sync
or to prevent the copy during import if they are not kept in sync during update.

What would you recommend for these 6 XMP/EXIF/IPTC fields:

{File.MD.XMP::dc\description\Description\0}  ..... "Master-Field for manual updates"
{File.MD.XMP::tiff\ImageDescription\ImageDescription\0}   ..... syncronized by IM on import and updates
{File.MD.XMP::exif\UserComment\UserComment\0}   ..... syncronized by IM on import and updates
{File.MD.Exif::Main\37510\UserComment\0}  ..... syncronized by IM only on import and not on updates
{File.MD.Exif::Main\270\ImageDescription\0} ..... syncronized by IM only on import and not on updates
{File.MD.IPTC::ApplicationRecord\120\Caption-Abstract\0} ..... syncronized by IM neither on import nor on update

Walter

[Mario]

IMatch automatically propagates changes done to XMP into EXIF and IPTC, applying the rules of the Metadata Working Group.

This means on import EXIF and IPTC (if existing) are copied into XMP, and on write-back IMatch / ExifTool copy from XMP back into IPTC and EXIF. This is the default behavior and copies the XMP description into the EXIF ImageDescription. Do you have made any changes in the Metadata settings or the metadata settings for the NEF format? I use NEF myself and many other users too, and this usually just works.

[scw2wi]

Hi Mario,

I understand your answer in that way, that IM should propagate any change in {File.MD.XMP::dc\description\Description\0} to all the other 5 fields.

That was also my assumption. At least to the 2 ImageDescription fields, but why not also to the 2 UserComment fields, if this is best practice.

I have not changed any such propagate setting, because I even do not know, where this could be changed.
I have not even added any Nikon Tags in the Tag Manager, all my preference changes I have summarized in the first post.
If you could give me a hint, where I find this propagate setting, I will have a look.

Since the behavior of propagation is different on importing pictures and updating metadata, at least this is strange to me.
I was not expecting that this could be configured independently.

What do you mean with "this usually just works"?
I am not expecting that all users are cross checking the propagate behavior via ExifTool field by field.
If you are not doing this manuall cross check, you might not find such inconsistency between related fields in an easy way.
I have only done this cross check, because I wanted to avoid side effects for ViewNX.

Walter

[Mario]

I understand your answer in that way, that IM should propagate any change in {File.MD.XMP::dc\description\Description\0} to all the other 5 fields.

No. Which 5 fields?

The MWG mapping is defined as:

Exif ImageDescription (270, 0x010E)
IPTC Caption (IIM 2:120, 0x0278)
XMP (dc:description["x-default"])

No mapping or handling is specified for the UserComment field in EXIF.

You can see how ExifTool maps between IPTC, EXIF, GPS and XMP in the configuration files shipped with IMatch. You find these in the IMatch Program Files folder, in the arg_files sub-folder.

[scw2wi]

Hi Mario,

thanks for the mapping information in arg_files, this was what I was searching for.

Since the mapping I found in arg_files looks correct, maybe there is an error in my testing workflow.
May I tell you the steps I am doing.

1. Import of a NEF with description made in ViewNX into IMatch
2. Checking the description in the Metadata panel in setting "Image Info"

In ViewNX there is only 1 description field, in IMatch there are 6 (or 4 if we leave out UserComment fields)
so lets scroll down the Metadata paneel and have a look at these fields.

In area Exif / field ImageDescription I can see the value that was written in ViewNX.
"re-mouse / Copy as variable" tells me the name of this field: {File.MD.Exif::Main\270\ImageDescription\0}
A tooltip tells me: This field is mapped to an XMP field and cannot be edited directly.

Scrolling down there is a 2nd field "Exif / UserComment" or  {File.MD.Exif::Main\37510\UserComment\0} with the same value.

Scrolling down there are more areas with other fields,
"IPTC ApplicationRecord / Caption-Abstract" = {File.MD.IPTC::ApplicationRecord\120\Caption-Abstract\0}
"XMP Dublin core / Description" = {File.MD.XMP::dc\description\Description\0} (this might be the master field where the tooltip references to)
"XMP TIFF / Image Description" = {File.MD.XMP::tiff\ImageDescription\ImageDescription\0}
"XMP exif / User comment" = {File.MD.XMP::exif\UserComment\UserComment\0}

All these fields are having the same content, so far so good.

3. Now I'm modifying the ImageDescription in ViewNX and call RescanNow in IMatch.
I would expect, that IMatch shows the modified content in all these 6 fields now,
but only the following 2 fields are having the new value
"IPTC ApplicationRecord / Caption-Abstract" = {File.MD.IPTC::ApplicationRecord\120\Caption-Abstract\0}
"XMP Dublin core / Description" = {File.MD.XMP::dc\description\Description\0}
the other 4 are still showing the old value. This is definitely an error in ViewNX.

4. Now I'm modifying the field "XMP Dublin core / Description" in IMatch and check, which other fields are beeing propagated.
In this case, another 2 fields are propagated
"XMP TIFF / Image Description" = {File.MD.XMP::tiff\ImageDescription\ImageDescription\0}
"XMP exif / User comment" = {File.MD.XMP::exif\UserComment\UserComment\0}
and there are 3 other fields keeping an old value.

Now I've checked the propagate info in arg_files folder.

xmp2exif.args line 28:
-EXIF:ImageDescription < XMP-dc:Description
This works only when a new picture is imported, when modifying XMP-dc:Description im IM, EXIF:ImageDescription is keeping the old value.

xmp2iptc.args line 38
-IPTC:Caption-Abstract < XMP-dc:Description
This works only when I modify Description in viewNX, modifying it in IM will keep the old value in IPTC:Caption-Abstract.

It seems to me, that at least these 2 propagate rules are not working as I would expect.

Maybe I am modifying the wrong field in IMatch or is there anything else wrong with my testcase?

Walter

[Mario]

Your test may lead to the wrong result because IMatch by default protects unwritten metadata. See Under Edit > Preferences > Metadata 2 and the corresponding help (press <F1> while the dialog is open) for details.

Don't import a file into IMatch and then change the metadata again in ViewNX and then rescan the file in IMatch. This will not give proper results. Always write back the file first in IMatch.

Also, ViewNX has issues with metadata handling when I recall. Do you use the version which writes XMP, or is this the version which only does legacy IPTC and EXIF?

The only description you should care for in IMatch is the tag named "Description" (xmp-dc:description) because this tag is mapped back to legacy IPTC and EXIF when IMatch writes the data. For import, the only mapping defined by the MWG is the EXIF::ImageDescription which has a mapping to XMP. It can be overridden by a caption-abstract in IPTC, depending on what ViewNX writes into your files.

UserComment or the even older ImageDescription in the JPEG IFD0 block are not covered by the MWG and whatever information is stored in these tags is to be considered volatile and proprietary. These tags are/were used by soiftware which does not support any of the proper metadata standards like (legacy)IPTC or XMP. But XMP is around for almost 15 years, legacy IPTC has been declared legacy by the IPTC committee 10 years ago, so all applications now should get the hint and use an 'XMP first' workflow. Like IMatch. Or other major applications.

In general: When you plan to edit metadata in multiple applications, including IMatch, make sure that all your applications are aware of how XMP and EXIF, IPTC, GPS need to be synchronized. That all your applications update the digest information after writing so other MWG compliant applications can tell what has been changed etc.

I don't think Nikon ViewNX does any of these things. I have not used it for a long time, but when I recall it correctly, View NX's metadata handling was 'basic' at best. As long as you 'finalize' your files in ViewNX and then import them into IMatch and let IMatch handle the metadata updates from then on, you're good. If you continue to add/edit metadata in ViewNX and IMatch, you may get into trouble.

[scw2wi]

Thanks a lot Mario for your very good explanation of Metadata propagation.

I am using the latest ViewNX2 Version that was available, but I know that even this version has many bugs (like all Nikon SW).
Nevertheless I have to find a solution how I can use both SW in my workflow, at least for a period of migration.

Based on your hint I will now forget about the fields UserComment and ImageDescription
and will only focus of the following 2 fields.

{File.MD.XMP::dc\description\Description\0}  ..... "Master-Field for manual updates"
{File.MD.IPTC::ApplicationRecord\120\Caption-Abstract\0}  .....  "IPTC ApplicationRecord / Caption-Abstract"

Additionally I will also make further changes only in IM.

The flag "Protect unwritten metadata" I have set to No,
although for my understanding, it should only make a difference if I
first change a Tag in IM database and not write it to the file,
than change the same Tag in the file via another SW (this was not part of my testcase).

With this new defined testcase I made a new fresh import,
made some changes in IM and saved the changes to DB and to file.

All these tests are successfull now!

Propagation works perfect, even the fields UserComment and ImageDescription are propagated fine now,
and also when I reset the flag "Protect unwritten metadata" to Yes it is still working.

All my changes are visible in ViewNX and the only restriction ist, that I shall not use ViewNX any longer for changing Metadata.

Thanks for your help and I will try to change my workflow to use only IM so that I can forget about ViewNX in future.
But this might take some time because ViewNX is quite simple and IM is quite complex.
So I have to learn a lot now, with the very good Online Help supporting me in this task.

Walter

[Mario]

It's usually a good idea to change metadata only in one application. Or at least use applications which support a proper XMP/IPTC/EXIF workflow and metadata synchronizing - and ViewNX does not do that. You can use it for editing and viewing and what else ViewNX can do, and if you manage your metadata in IMatch only, you have a safe workflow. And 'compatible' metadata which also works with non-Nikon products and services.

Which parts of IMatch do you find especially complicated?

[scw2wi]

I did not say that IMatch is too complicated, it's the perfect SW for my needs.

I have gone thru approx. 25% of the Help now and I will start asking my questions when I've finished with the rest.

I will start configuring the Layout of the File Window and the MetaData Window according to my needs (the Camera Dashboard looks really good).
Next I will define my Categories and Collections (I still do not fully understand the main difference between them).
I have configured NEF as Buddy File but not as Version (also this difference is not yet clear to me).

My major workflow for tagging is to double-click an Icon in ViewNX so that it opens fullscreen on the 2nd screen.
Then I'm writing my metatags and navigate to the next picture.

In IM double-click starts the slideshow, the viewer starts with enter (I'm sure this can be configured somewhere).

In ViewNX the Viewer is synchronized with the Icons, if I'm going to the next picture, the viewer shows the next picture and the next icon is selected for metadata handling.
In IM the default configuration seems to be "unsynchronized", which means, I have to navigate to the next Icon in the file window and to the next fullscreen picture in the Viewer separately.
I'm still locking for a setting where I can change this.

I love all that new features that IM offers but it just takes time to learn about all that and as I said, it makes no sense to ask silly questions in the forum as long as I'm not thru the provided help file, because that's why this Help was written.

Walter

[Mario]

Next I will define my Categories and Collections (I still do not fully understand the main difference between them).

Collections are mostly automatic, they group files for you. The manual collections like bookmark, dot, pins  are for you perusal. Use them when you want to (temporarily) group files and have a visual clue in the file window.

You usually don't make .NEF a buddy file. A .NEF file may have buddy files (depends on your RAW processor or your camera).

In IM double-click starts the slideshow, the viewer starts with enter (I'm sure this can be configured somewhere).

Edit > Preferences > File Window

You send the files you want to work on to the Viewer using <Enter>. Then you cull, rate, label, assign to collections, categories etc.

To work with metadata and keywords, it's much easier to use the Quick View Panel, which 'follows' the selection in the file window (you see the files you edit). Note that you can make the Quick View Panel very big, un-dock it to move it freely, even on a second monitor.

[scw2wi]

Yes, of course NEF is not the buddy file. I have choosen the default setting for Nikon NEF Relation,
so that jpg and others are defined as buddy for NEF. When I learn more about Versioning, I can decide if and how to use this feature also.

If the Viewer cannot be synchronised with the file window, I will use the quick view panel as full screen viewer, that should also work.

I have added all my XMP/IPTC and EXIF fields now to a userdefined Metadata panel, and it was really easy as you said.
Nevertheless I found 2 issues but since there are workarounds it's not a big thing.

When I call edit|layouts in Metadata viewer the dialog opens where I can add/remove/move my tags.
First I tried to add, move and remove tags here but recognized that removing a tag reorders already ordered tags.
My workaround was to close the dialog and reopen it, if I had moved a tag up and needed to remove another tag next.

The second issue is a little bit worse.
I have added some Nikon specific data [Nikon, Nikon LensData00, Nikon LensData0204, Nikon VRInfo].
So I had to add these 4 Groups in the Tag Manager. On closing I got the message:
"If you have included new groups you need to rescan the files (or re-load metadata) to import these tags into the database."

I called "Rescan now" for single files as well as for the hole directory but the Nikon tags where not loaded.
I had to remove the files from database and made a fresh import to get the Nikon tags loaded.
What was my error here or is this a known issue of V 5.5.7 ?

Walter

[Mario]

I called "Rescan now" for single files as well as for the hole directory but the Nikon tags where not loaded.

A normal rescan just checks for new and updates files. This does nothing in your case because none of the files is new or has changed.
You need to use the Advanced Rescan option (see help for details).

Press <Shift>+<Ctrl>+<F5> when one or more folders are selected or in a file window. In the dialog that opens, choose "Reload Metadata!". This will unconditionally reload all metadata from your files, even if they have not changed. This is required when you make changes in the Tag Manager or other options which affect how IMatch imports metadata.

[scw2wi]

Thanks a lot, the Advanced Rescan Option was exactly the solution I did not found.

Would it make sense to change the message
from
... you need to rescan the files (or re-load metadata) ....
to
... you need to reload metadata via the Advanced Rescan Option ...

I am continuing to configure the tool to my needs and it's more and more the tool I love.
There are so many features I was missing before and I'm sure there will be many more to discover.

I have one special case which I cannot handle as of now, but not because it's not possible, only because I did not read the scripting part yet.
I'm not sure if it's ok when I ask this question now, but maybe you have a solution out-of-the-box.

I would like to propagate the Labels 1..9 to the field Urgency.
When I'm setting the Label 1 (e.g. with shift 1), Urgency shall be set to 1.
Label 9 shall set Urgency to 9, deleting the Label shall delete Urgency.
There is no need for a propagation in the other direction.

If somebody has solved such a propagation already, it would be very helpful to share such a code.

Walter

[Mario]

This can be easily done with a Metadata Template, no need to write a script.
Just use the label tag as the source and copy it into the urgency tag.

If you need that often, create a Favorite from the Metadata Template, then you can run it for any number of files with a single mouse-click or a keyboard shortcut.

[scw2wi]

You are right, with a Template I can do that very easily, but I have to do it and shall not forget to do it (even if it's just a click)
I thought with a script I could do it automatically, without the chance to forget it.

Walter

[Mario]

You can do that. But then you have to write a script and don't forget to run it.
And event-driven scripts, which react on database events, are possible but complicated and may cause performance issues. And I' considering if I will support these in the future at all.

[scw2wi]

I was thinking about an event-driven script since I've read about that.
Is there really such a big performance issue that you need to deprecate that feature?

The template is just copying the value of the label but I need to copy the corresponding Label-Nr (1..9) not the value.
So I will need a script since a template might not be able to handle that translation.

I was thinking about the best workflow since I tried the feature "Write-back changes to metadata immediately".
In my opinion this feature is not working in the most efficient way.
If I'm changing e.g. 10 metadata fields without changing the focus on the selected picture(s),
this features writes every single change back to the file(s).
I would like to write back all 10 changes in 1 step after I set the focus to another picture.

If this is not possible, I am considering to write a short script which calls the write-back function
and define a key (e.g. <F3>-S for save) and a button in the Favorites-Panel.
With such a save-script I can also handle the label propagation and other things.

By the way, I found a folder MSIa458b.tmp on my picture drive after IM crashed.
The crash of IM might be because I opened ExifToolGUI and this SW crashed also.
Could be a conflict between both.

Walter

[Mario]

Even-driven scripts are complex and a user who does the wrong things can not only ruin the database performance or even damage it. For the potential 10 users world-wide who may have use for such complex scripts it's just not worth the effort to keep all this running, compatible and documented.

My general direction is also to slowly replace Basic Scripting (which is really old now) by JavaScript.

[scw2wi]

Ok, I understand the arguments against event-driven scripts.

If JavaScript will have higher performance, such a change would be nice.
If it's just for better readability I'm not sure, if it's really worth.

What do you think about my idea, to write a script,
which propagates all changed Labels and calls the write-back function at the end.
If I'm always calling that one function before I close IM, I will not forget it (at least not too often).

Do you think such a script could work as expected?

Walter

[Mario]

If JavaScript will have higher performance, such a change would be nice.

The performance of the Basic engine is excellent.

Do you think such a script could work as expected?

I suggest you write it and try it out.

By the way, I found a folder MSIa458b.tmp on my picture drive after IM crashed.

MSI... indicates that this folder has been created by Microsoft Installer. I doubt this has something to do with IMatch.

[Ferdinand]

The performance of the Basic engine is excellent.

Agreed.

[scw2wi]

I've gone thru the Help File with all it's descriptions (some of them twice, because IM is a really powerfull Tool).
Now I'm starting to solve my little Label => Urgency issue.

I found a good solution how to propagate the Label-Index (not the Label-Name) to the Urgency field via a metadata template.

Code Select Expand

Tags: XMP::photoshop\Urgency
Fill the tag from this data:
{File.MD.XMP::xmp\Label\Label\0|replace:LabelName1==1;replace:LabelName2==2;replace:LabelName3==3;replace:LabelName4==4;replace:LabelName5==5;replace:LabelName6==6;replace:LabelName7==7;replace:LabelName8==8;replace:LabelName9==9;default:}

This also works if a Label-Name has blanks, brackets and so on.

There are just 2 disadvantages.
1.) If I ever change a Label-Name I also have to change this template (I can handle that).
2.) I always have to call this template (e.g. via Favorites or Short-Key) manually.

I should be able to solve the second issue via an event-driven database script (I did not forget the warning about performance).
Database_CollectionUpdated should be the correct procedure.
If I just call the template from here I should not face any performance issue, but I'm facing another issue.

Every time I'm opening the Script Editor for Database Scripts, I can select the Object "Database" only on the very first time after a fresh start of IM.
If I'm opening the Script Editor for Database Scripts a second time, I can only select the Object (General).
I do not face the same issue with Application Scripts, only with Database Scripts. I am toggling to the Design Mode as requested.

Is there a known bug and maybe also a better workaround than closing IM and restarting it again?

Walter

[Mario]

Try closing and re-opening the database instead (File menu).
As I said, event-driven script processing is not on my to-do list and may vanish in a future IMatch version. Don't create a workflow based on it.

Note: The Urgency field has been deprecated by the IPTC long ago (see: https://www.iptc.org/std/photometadata/documentation/GenericGuidelines/index.htm#!Documents/iimmetadatadeprecatediniptccore.htm)

[scw2wi]

Thanks Mario, closing and reopening the DB is a good workaround.

I know that Urgency is deprecated, but with this small concession I am fully compatible with ViewNX - even in both directions.
I will use this compatibility only in one direction, based on your hints, but I cannot migrate my hole workflow in one single step.

If you really need to deprecate event-driven scripts I will still have the solution with the metadata template placed in favorites, so my workflow is not really broken.
But of course I would prefer the automatic solution over the manual one, please think about that before you are making a decision.
Such scripts can be really helpful if they are used in a proper way.

After reading the hole Help File there are only two open questions left.

First is about the Sort Profiles, the help file is a little bit short on this one topic.
I did not understand what sorting by Similarity, Stack and Version means, maybe I tried with wrong testcases.

The second open question is more about the usage of stacking.
I have defined JPEG as buddy and as version for NEF, this is working fine.
Then I have used Version Stacks and manual Stacks and combinations of both.

The best way I found to toggle Version Stacks for all pictures is to first mark all pictures and then select "Toggle Version Stack".
Although this is working fine even if some are already stacked and some are not, I'm not sure
if I missed any direct function to "Toggle version stack of all pictures", because I know such a feature from many other Tools.

I also tried to use manual Stacks to stack pictures that shall automatically always get identical metadata,
but I could not find a good workflow for that because only the top most picture gets selected.
Maybe I have to write a script to get a good solution for my requirement.

If someone has written such a script already, it would be more than welcome if it could be shared.

Walter

[Mario]

I did not understand what sorting by Similarity, Stack and Version means, maybe I tried with wrong testcases.

Exactly what the name says. Similarity is useful when you sort result windows, after searching visually similar images, sketch match etc.
Sorting by stacks and versions sorts the files by their stacks and versions. If you have not used stacks and versions yet, check out the corresponding help.

if I missed any direct function to "Toggle version stack of all pictures", because I know such a feature from many other Tools.

I can't follow.
The Toggle version stack command works on all selected masters.
What would a "Toggle version stack of all pictures" you know from other software do?
If you want to toggle the stack for all files in your database, select the database node, mark all files, use the Toggle command...

[scw2wi]

Thanks, I got the points.

Sorting by Similarity does not have any influence, as long as the selected window is not the result window, that's why I could not see any change.

Sorting by Stack or Version does not have any influence, as long as my pictures are stacked.
If I unstack them I can choose, if I want to see the Top picture of a stack first or the Master of buddy files.

I have choosen as my default sorting:

1. Similarity  descending
2. File Name (without extension)
3. Version
4. File Extension

Ordering 4 is just in case I have more than 1 buddy file.

Selecting the database node, marking all files, using the Toggle command
is a good practice to toggle all pictures, but needs 3 or 4 clicks.
I was looking for a 1 click solution, so maybe I will try to create a Script for that.

I am fully motivated to learn how to add my own workflow features via scripts,
so I have started to look at all the provided examples and also the scripts of other users.

Walter

[Mario]

is a good practice to toggle all pictures, but needs 3 or 4 clicks.
I was looking for a 1 click solution, so maybe I will try to create a Script for that.

How often doe you need to toggle the Version stacks of all files in your database?

IMatch is not a toy DAM. Many users manage 200,000 or 300,000 files with it. All commands and features in IMatch have to be designed to work with such large 'Enterprise-scale' databases, considering databases on slow network storage etc. This is why IMatch uses a concept like the current scope and also the reason why you need to select the files you want to toggle. Of course it is possible to toggle the version stacks for an entire database at once - but I'm quite sure that users with 300,000 files don't do that regularly.

Using scripts is usually only the last resort. IMatch has so many features and fits into so many workflows, it is usually better to first use what's there before starting to write scripts.

[scw2wi]

You are right, I did not consider these consequences with that many files.

Usually I'm working only with stacked Version-Files,
and if I want to have a short lock at the buddy files,
I can also use the Versions panel.

Walter

[scw2wi]

I found a solution now for copying label-index to urgency without the usage of an event-driven database-script.
I took the write-back script of JohnZeman and added my code for label propagation, this works so good now, I'm happy. (Thank you John for sharing your script!)

I also found one reason why my original propagation to IPTC was not working.
After disabling "Metadata Working Group Compliance" in the Configuration I could see in ExifTool Output no more calls to arg_files\xmp2iptc.args and so on.
Now I've set some related XMP, IPTC and other fields to dedicated values and overruled these values via script during write-back.
This code is working fine, but there are some unexpected observations.

Here are the values that I used:

Column 1: Tag-Name, Column 2: Value in Application, Column 3: Value overwritten in script.

"XMP::dc\description\Description\0"  _____________ "1" ... "**Desc1**"
"XMP::tiff\ImageDescription\ImageDescription\0" ___ "2" ... "**Desc2**"
"XMP::exif\UserComment\UserComment\0"  _______ "3" ... "**Desc3**"
"IPTC::ApplicationRecord\120\Caption-Abstract\0" __ "4" ... "**Desc4**"

I could see in Application that "1" was replaced by "**Desc1**" and so on - but just for 1 sec, and after auto-reading-back from file it changed again,
and when I had a look at the ExifTool output, I could see why it changed twice.

-XMP-dc:Description-x-default=**Desc1**
-XMP-tiff:ImageDescription-x-default=**Desc1**
-XMP-exif:UserComment-x-default=**Desc1**
-XMP-exif:UserComment=**Desc3**
-XMP-tiff:ImageDescription=**Desc2**

The values Desc2 and 3 were overwriten by Desc1 in both cases, and I thought that tag propagation was totally turned off, but obviously there is another effect.

This leaves 2 questions:

1.)
Why is the IPTC field not sent to ExifTool at all, it was marked as changed in Tool and overwriten in script.
Even if it's only changed and not overwriten or only set in script without changing in Tool it is not writen to ExifTool.
I have checked all switches if I have accidentally disabled the dedicated writing of all IPTC data, but I could not find a proper switch.

2.)
What is the meaning of x-default here. Is this a kind of language code?
If yes, where does this come from and how can I change that? It is overwriting the values I have set.
I have tested with Tool language setting german and english, it's not changing this unexpected behavior.

I have repeated my test with MWG setting ON again.
The ExifTool output of the 5 lines above are the same but the result was of course the propagation according to the MWG rules,
and in Metadata window, the IPTC tag is disabled now, so in this case it is (nearly) as expected.
Why nearly, well propagation is not working identical for NEF and JPEG, but this seems to make sense, because
for JPEG the "Exif::Main\37510\UserComment\0" is overwriten with the description, for NEF it is not touched.

Walter

[scw2wi]

I have made a simpler test now to find out which fields are written back if propagation is turned off.
I'm not using any script now and just modifying a field and writing it back via IM tool function. (And I've used another picture)

setting the field: XMP::dc\description\Description\0 to **Desc1**
sends this to ExifTool:
-XMP-dc:Description-x-default=**Desc1**
-XMP-tiff:ImageDescription-x-default=**Desc1**
-XMP-exif:UserComment-x-default=**Desc1**
(It's still not clear to me why 3 values are written - maybe a kind of mandatory propagation that cannot be turned off?)

setting the field: XMP::tiff\ImageDescription\ImageDescription\0 to **Desc2**
sends this to ExifTool:
-XMP-tiff:ImageDescription=**Desc2**   (ok, this is 1:1 identical to the value set, no propagation to other fields)

setting the field: XMP::exif\UserComment\UserComment\0 to **Desc3**
sends this to ExifTool:
-XMP-exif:UserComment=**Desc3**      (again 1:1 identical to the value set)

setting the field: IPTC::ApplicationRecord\120\Caption-Abstract\0 to **Desc4**
sends this to ExifTool:
-IPTC:Caption-Abstract=**Desc4**   (perfect, it's working now, and so simple!)

I knew that there is no error in IM (to many people are using it) and that I'm making some kind of error.
But since I still did not know, what was the error yesterday, I've done some more tests.

I repeated the same test with the picture from yesterday,
same result for Desc1..3 but now Desc4 is not written to IPTC field.

So my idea was, maybe the IPTC record of this picture is damaged?
But then I should see in the ExifTool Output window at least the attempt to write this field.
So if IM does not even try to write this field into just this one picture, what can be the reason for that?

Any idea what investigations I can do to find the reason for the different behavior and the meaning of x-default?

Walter

[Mario]

(It's still not clear to me why 3 values are written - maybe a kind of mandatory propagation that cannot be turned off?)

Yes. Metadata Working Group recommendations, IPTC standards etc. require these tags to be synched.
The way IMatch reads and writes metadata was developed over many,many months, incorporating known standards, frequently encountered 'special cases', working around buggy metadata written by cameras or other software etc. Nothing is done without a good reason. And my blood pressure still rises every time I have to deal with metadata. It's such a mess.

[scw2wi]

Thanks Mario for your explanation, I understand the reason now.

I'm sorry for letting your blood pressure rise, I will try to find my errors at my own.
At the moment I am only testing with about 10 pictures and only 2 are having this error.
Maybe I have damaged these 2 files with too many silly tests, I restored a fresh backup and started from zero now.

I hope your blood has come down again and you will not stop giving me such a premium support.
Without your hints I would not be able to answer many of these questions, so your hints are always very welcome.

I have a rough idea, what error I am making.
If there are e.g. 4 fields for City or 5 fields for Description I am maybe using the wrong ones to write in.
2 of them are usually disabled and marked as "do not modify".
So I have to find out, if I should better modify the Composite fields or the XMP fields.
It seems I did not read the Helpfile carefully enough.

Walter

[Mario]

In general: Always update XMP data in IMatch. IMatch/ExifTool take care which XMP field needs to be mapped to which legacy IPTC field on write-back, or on import.
The legacy IPTC urgency field has been abandoned 10 years ago, it's only dragged along for historical reasons.
Updating legacy IPTC data manually, or via a script, works against IMatch and the Metadata Working Group mappings. Not a good idea, unless you work only with legacy IPTC fields which have no mapping to XMP data and you know what you are doing. And this means knowing the XMP standard, the legacy IIM3 IPTC standard, the new IPTC XMP standard, the mapping rules recommended by the MWG and, if you use Adobe software, the different ways camera vendors, Adobe and other software vendors followed, or failed to follow or plainly rejected to follow, these rules and standards...

[scw2wi]

Thanks Mario,

I have done several errors at the beginning so that I couldn't find a good workflow for my exeptional usecase.
Now I have learned a lot in the meantime so that I know better, what I can do and what I should avoid.

Error 1:
I did not know, what was the aim of the Composite fields (e.g Composite\City\City\0)
Now I know, that they are automatically generated from the related fields (e.g. XMP::iptcExt\LocationShownCity\LocationShownCity\0)
but they are not written to Metadata (only used internally).
I could not find a description about that in Help File so I needed some time for investigation but I think it's clear now.

Error 2:
I did not realize, that there is a difference between an empty field and a not existing field.
My first script showed me the difference via proper error messages.

Error 3, or shall I say Error 0 because that was my biggest error.
My first approach was to disable "Metadata Working Group Compliance" and to handle propagation manually.
Now I know that this was not my best idea. It's much better to let IMatch & ExifTool do the job and just modify the few changes I need.
I have commented out these 2 lines in iptc2xmp.args and xmp2iptc.args (I know that I have to repeat this step after every upgrade)
#-XMP-photoshop:Urgency < IPTC:Urgency
#-IPTC:Urgency < XMP-photoshop:Urgency
and are handling Urgency via script as needed by ViewNX - and this is working fine now,
although there are some default values like "1 (most urgent)" or "9 (least urgent)", but this can be handled by ViewNX.

Many errors from my side, many helpful hints from your side and finaly a good solution and that's the only thing that counts at the end.
I can now start importing all my pictures and start adding Categories.
I have created a thesaurus already with many animal species and have many more ideas what to do with IMatch.

There is just one very minor question open.
MWGC setting ON is copying all tags as expected with 3 exceptions.

"XMP::photoshop\City\City\0", _______to_ "XMP::iptcExt\LocationShownCity\LocationShownCity\0")
"XMP::photoshop\State\State\0", _____to_ "XMP::iptcExt\LocationShownProvinceState\LocationShownProvinceState\0")
"XMP::photoshop\Country\Country\0", _to_ "XMP::iptcExt\LocationShownCountryName\LocationShownCountryName\0")

If I do not copy these 3 fields in my script, the composite fields (City/State/Country) are not updated.
Maybe there is an Error 4 and I am still doing something wrong.
It's not a problem, I can handle that perfectly via Script. But I was just not expecting it.

I know it's not very likely, but if anyone looks for a solution that works together with the old ViewNX SW, I can provide my script for that.

Mario, you have developed a unique Tool and you are providing premium support for it.

Thanks a lot

Walter

[scw2wi]

Just a short update, if there is anybody interested in my solution of the Nikon ViewNX Workflow.

I have now imported about 100.000 images NEF+JPEG without any problems.
At the moment I am mainly using 3 scripts.

These are the steps I'm following.

1.) Import
2.) Do some short manual checks
3.) Script to propagate tags not handled correct by ViewNX (needs about 50% of import time)
4.) Write back, also this is done via a script. (needs about the same time like the first import)
5.) Check script, if there are no more metadata out of sync. (needs about 10% of import time)

After that, IMatch/ExifTool takes care that all metadata stays in sync.
I am following the advice of Mario, not to use ViewNX on these images again.
A short test showed, that even if I would do that, a short run of the propagate script would solve it again.

If someone is also working with ViewNX and interested in these scripts, please send me a message.

Walter

[Carlo Didier]

You can do that. But then you have to write a script and don't forget to run it.
And event-driven scripts, which react on database events, are possible but complicated and may cause performance issues. And I' considering if I will support these in the future at all.

Sorry to intrude on this thread Mario, but PLEASE don't take out the event scripts! It's a very important part of my workflow ... 

[scw2wi]

Originally I thought it's a good solution to start my propagate script via an event, but now I'm starting it manually.

Nevertheless I'm using another event at the moment.

Before I'm closing the database I want to make sure that all changes are written back to images.
Since I did not find a proper setting in IMatch I have written a short script
which is called from the database close event, asking if I want to write back open changes.
On NO, the script exits and database closes,
on YES, the script calls my write-back script and so I cannot accidently forget to write back.

This is working fine and I would not like to miss this feature.
So I also ask for PLEASE do not remove these event triggers,
they can be very helpful if they are used with special care.

Walter

[Mario]

The Basic language I introduced in 2003 is now becoming very, very old.
The annual license fees I have to pay are very expensive (more than all my other software + a MSDN subscription together).
To upgrade to a 64 bit version would be ridiculously expensive.
What can be done in the UI department is laughable.

In short: I'm looking for a replacement.

Something more modern, powerful and more open.
This is also linked closely with some other technology I'm developing right now.
I will announce more information about this at some later time.