More options in metadata paste dialog (file window)

[lbo]

Hi All,

IMatch has a very convenient method to copy metadata between files: In the file window, Ctrl-C copies, Ctrl-Shift-V pastes metadata to the destination image.

Currently, the paste dialog allows to select several single items (e.g. Bookmark/Flag/Dot/Pins/Rating/Label) and some large blocks (e.g. whole XMP/EXIF/IPTC/GPS)

My suggestion is to add three more options for often used information sets:

• Description: Description, headline, (hierarchical) keywords.
• Location Created: Coordinates, country, state, city, sublocation. Useful for people who don't distinguish between camera and target position
• Target location: Same as above for "destination" aka "target" aka "shown" coordinates. Should calculate also image direction (if camera position is known).

Use case example: If you work on a new image showing an e.g. the Matterhorn summit and you have an existing image of the Matterhorn already with rich metadata, you might want to copy the describing data from the old image to the new image. Since you took the two photos from different camera positions, you don't want to overwrite the camera coordinates of the new photo but just the "shown" location.

Part of this request can be done also with custom metadata panels, but the copy/paste option in the file window provides "ad hoc" selection of the tags to be copied which is much simpler and natural. Besides, "Image direction" is not calculated if the "shown" coordinates are set this way.

BTW: GPSDestDistance is not even calculated by the map app. Not that important, IMO.

Oliver

[hluxem]

+1

[sinus]

+1

[Carlo Didier]

+1

[Mario]

I was just thinking...

What about a new way to apply metadata templates? In addition to the current "fill the data of these files like this" we get a "fill the data of these files like this, using that file as the data source for variables".

Consider a metadata template that uses the focused file as the source and then updates all selected files as defined in the template.
Or maybe some sort of "pick/apply" or 'metadata brush' concept. If have something like this on my to-list, but just today came up with the idea to use the established metadata template functionality for it.

Example

The 'new' metadata template sets title, description, headline from the corresponding variables. No change here. Just tick the new "Copy" option.
When run, the template checks for a focused file and at least one additional selected file and then updates the selected file(s) from the variables filled from the focused (source) file.
Or, similar, a pick source file, pick target files, apply template.

This would give us a very controlled way to copy data from one source file to n other files. Including variables, formatting functions. Fill, Append, Replace etc.

[lbo]

interesting idea, this would add a lot of flexibility.

The pick/apply or brush concept you mention seems to be more flexible since I don't need to have source and target in my focus at the same time.

Thinking more about this: It could be even useful to use the windows explorer to "copy" the information from the source image. I already do this with Geosetter using a batch file in my "sendto" folder: The cmd file invokes ExifTool to create a XMP file in Geosetter's template folder.

Could I do this also with IMatch, IOW use a XMP file (in a know location) as data source in a metadata template?

Since I can invoke "Send to" also from IMatch, this would result in maximum flexibility.

Using the windows explorer enables copying even from files not known to the IMatch database.

Oliver

[sinus]

Very interesting, very good idea.
If I understand this correct, then we could overcome with this the "limitation", that we cannot add categories to metadata templates?

So we could add all stuff from the template and copy also the categories and other things from the source!? Would be cool!

[Mario]

If I understand this correct, then we could overcome with this the "limitation", that we cannot add categories to metadata templates?

Metadata Templates cannot copy IMatch categories. Except for @Keyword categories of course.
The Paste Attribute command can copy categories between files.

Making Metadata Templates do that would require a larger extension. I assume the people who would have use for that would also need to select the categories they want ti copy, recursive options, options for merging, adding, replacing. Quite a lot of work.

Could I do this also with IMatch, IOW use a XMP file (in a know location) as data source in a metadata template?

I doubt that such a feature would be used by more than a handful of users.

[lbo]

Could I do this also with IMatch, IOW use a XMP file (in a know location) as data source in a metadata template?

I doubt that such a feature would be used by more than a handful of users.

If you name it differently (not that technical), it should be useful for many users.

The point is that I can "copy" metadata from any image with the Windows Explorer context menu and than paste part of the data to images in IMatch.

To me, this sounds rather "natural".

Oliver

[hluxem]

I think that's a great idea.

Metadata Templates cannot copy IMatch categories. Except for @Keyword categories of course.
The Paste Attribute command can copy categories between files.

Could the copy attribute function be expanded? Like add lines with a list of meta data copy templates to check. That would allow to copy categories as well as specific meta data tags defined in templates.   

Heiner

[Mario]

The point is that I can "copy" metadata from any image with the Windows Explorer context menu and than paste part of the data to images in IMatch.

I don't think this will be useful for many.
IMatch users using Windows Explorer with a Geosetter shell extension required to save XMP data to a file? And then importing this data into a different file? That's special.
Who guarantees that the data is consistent? What with timestamps, digest information? Metadata Working Group compliance and mapping?
Thinking about this, hacks like this explain a lot of the out-of-sync metadata IMatch encounters with users. Assuming the users used software which only dealt with XMP, and maybe only half-way.

You can easily do this with a small ExifTool command script, if you really need that. No GeoSetter needed, no extension for IMatch needed, ExifTool keeps control over the process and can even consolidate between the XMP data to write to the target file and existing IPTC/EXIF/GPS data in that file. Copying only XMP data is not all that needs to be done.

Location Created: Coordinates, country, state, city, sublocation. Useful for people who don't distinguish between camera and target position
Target location: Same as above for "destination" aka "target" aka "shown" coordinates. Should calculate also image direction (if camera position is known).

This is also more difficult than one thinks.
If you copy GPS location data between files, separately for created/destination, what data needs to be copied and where depends on the target file.

If a file has no destination coordinate pair, the GPS coordinates go into the standard (shown) coordinate set, and the location data goes into location shown.
If the file has normal and destination coordinates, the normal coordinates and location goes into "created", the dest goes into "shown".
If the file has only destination coordinates, the data goes into the "shown" set.

This logic can be implemented when the GPS is copied as a block or filled by IMatch (e.g. in the rev. geocode) but not when the user is allowed to copy individual sections of the GPS record as you mention in your comment. At least that needs a lot of thinking to understand all the implications and find ways to do that. Copying the entire XMP GPS record and synching it into the EXIF GPS record is safer.

[Mario]

Could the copy attribute function be expanded? Like add lines with a list of meta data copy templates to check. That would allow to copy categories as well as specific meta data tags defined in templates.   

Copy Attributes also can copy categories.
I'm rather thinking of removing the Copy Attributes completely. It is not used by many (telemetry). Enhancing MD Templates for the next major IMatch version perhaps, combining copy Attributes and MD Tempates into a global "metadata brush" concept.

[Mario]

Small enhancement for next version:

The Paste Attributes mechanism is rather flexible, it is based on an XML file which holds the info which tags to copy.
I have added two new 'container' attributes to the list which cover two sets of tags: Description and Rights. Each container attributes copies several tags (similar to the already existing Keywords attribute, which copies hierarchical, flat and IPTC keywords).

To make it easier for the user to understand which data is copied, the dialog now shows a list of the tags copied:



Description copies:

-xmp-dc:title
-xmp-photoshop:headline
-xmp-dc:description
-xmp-photoshop:captionwriter
-xmp-photoshop:category
-xmp-photoshop:supplementalcategories

Rights copies:

-xmp-photoshop:credit
-xmp-xmprights:marked
-xmp-dc:rights|
-xmp-xmprights:webstatement
-xmp-xmprights:usageterms

New container attributes like this can be easily created. Let me know if you have specific requirements, we can then discuss them here.

Note: As I've explained a a few comments above, copying GPS location information (Country, City, ...) is not so easy. Because here the existing data in the target file needs to be considered and then the data must be either copied go "shown" or "created". I'm not sure yet if this can be managed in a general way. I will look into this next year. This year is already full.

[lbo]

The point is that I can "copy" metadata from any image with the Windows Explorer context menu and than paste part of the data to images in IMatch.

I don't think this will be useful for many.
IMatch users using Windows Explorer with a Geosetter shell extension required to save XMP data to a file? And then importing this data into a different file? That's special.
Who guarantees that the data is consistent? What with timestamps, digest information? Metadata Working Group compliance and mapping?
Thinking about this, hacks like this explain a lot of the out-of-sync metadata IMatch encounters with users. Assuming the users used software which only dealt with XMP, and maybe only half-way.

I'm afraid you misunderstood.

This is no hack and there is no out-of-sync potential since it is just copying metadata data from an image. That's already possible in the metadata panel.

The difference is only that I don't need to have the source image in the IMatch database but can retrieve (copy) the metadata from any image via the context menu.

Oliver

[lbo]

This logic can be implemented when the GPS is copied as a block or filled by IMatch (e.g. in the rev. geocode) but not when the user is allowed to copy individual sections of the GPS record as you mention in your comment. At least that needs a lot of thinking to understand all the implications and find ways to do that.

Using the Map Panel, I already can change individually

• the camera coordinates
• the target coordinates

My suggestion is nothing else than doing the same individual setting of camera and target position with a copy/paste operation.

Of course, this includes setting the direction.

Copying the entire XMP GPS record and synching it into the EXIF GPS record is safer.

But it is not what a user needs because the "entire GPS record" holds also information not to be re-used. Two examples:

• The camera position may already be present in the new image and different from the old image (see my OP).
• The GPS time stamp.

Oliver

[Mario]

1. When you copy metadata in IMatch, IMatch takes care for the synching and MWG compliance.

2. It's not the GPS coordinates, it's the location data that's the problems.

[hluxem]

It's not the GPS coordinates, it's the location data that's the problems.

Why are the location data a problem?
Should I not copy the country, state, city and location tags. I was going to use the meta data panel to copy these certain tags as suggested in another thread. I do often have images with GPS coordinates and it just makes more sense for me to copy these 4 tags rather than reverse geocode.

Heiner

[Mario]

Se my explanation about where the location data must go, depending on whether or not the target file has source coordinates, destination coordinates or both. The shown/dest coordinate differentiation was added by the standard bodies after the fact and since then we have to deal with created/shown locations and how to write them.

[lbo]

If you copy GPS location data between files, separately for created/destination, what data needs to be copied and where depends on the target file.

If a file has no destination coordinate pair, the GPS coordinates go into the standard (shown) coordinate set, and the location data goes into location shown.
If the file has normal and destination coordinates, the normal coordinates and location goes into "created", the dest goes into "shown".
If the file has only destination coordinates, the data goes into the "shown" set.

Can you provide a source for this rule(s)?

I searched in the MWG guidelines, but found only the proposal for manually entered coordinates in chapter 5.8.

I think that reading the standard(s) will show that copying data according to my proposal is not subject to any automatic routing.

Oliver

[Mario]

Maybe I've explained it wrong above. I repeat.
If a file has both, the "dest" coordinates control the location data for "shown" and the normal GPS coordinates control the location data for created.
If your source file has only the standard GPS coordinates it will have location data in "shown". If you copy this to a file which has both dest and normal GPS coordinates, the data must be copied from shown in the source file to dest in the target file when I'm not mistaken. This requires additional logic and cannot be performed easily with the ExifTool-based mechanism used now.

As I said, I will think about this for a while. And look into this next year, some time.
Let it rest for now.

Maybe I come up with a solution. Or I hard-code 1:1 copying (shown => shown, created => created, no matter what) and put a warning in the help file to be on the safe side. This will work for many cases, but not for all, where it may break the metadata. Hence the warning in the help file would be required.

[lbo]

As I said, I will think about this for a while. And look into this next year, some time.

no problem, it's neither important nor urgent.


Regarding your already implemented solution:

Description copies:

-xmp-dc:title
-xmp-photoshop:headline
-xmp-dc:description
-xmp-photoshop:captionwriter
-xmp-photoshop:category
-xmp-photoshop:supplementalcategories

You might consider not to include dc:title since this is often not a description of the image content but related to the file name or similar. IMO the IIM tag name "Object Name" was more meaningful than "Title". The whole tag naming is a big mess, anyhow.

https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#title

Oliver

[Mario]

In the workflows I know, semi-pro, commercial and institutional, title is a most important tag.

[Ger]

When reading this:

Small enhancement for next version:

The Paste Attributes mechanism is rather flexible, it is based on an XML file which holds the info which tags to copy.
I have added two new 'container' attributes to the list which cover two sets of tags: Description and Rights. Each container attributes copies several tags (similar to the already existing Keywords attribute, which copies hierarchical, flat and IPTC keywords).

I got a thought of creating one or more custom containers where the user can select any set of tags to be stored in that container for copying these tags. Not sure whether easily feasible, but would probably give additional flexibility.

ger

[lbo]

In the workflows I know, semi-pro, commercial and institutional, title is a most important tag.

You might notice that I did not write that dc:title is not important, but that it might not be related to the other fields you chose to be in this block.

From the link I provided: "Title provides a short human readable name which can be a text and/or numeric reference. It is not the same as Headline. [...] Many use the Title field to store the filename of the image, though the field may be used in many ways"

IOW "Title" has often a similar meaning as the file name. At least you can't exclude this.

The other fields describe the image content.

dc:title my be set long before a content description is added.

So if somebody wants to copy the description, he would overwrite dc:title (not describing the image content in his case).

Oliver

[Mario]

I have extended the Paste Attributes command to support more tag sets and to allow copying GPS coordinates and location data as 'sets'.

[sinus]

I have extended the Paste Attributes command to support more tag sets and to allow copying GPS coordinates and location data as 'sets'.

Thanks, very cool!

[jch2103]

Thanks; should be quite useful.

[hluxem]

Thanks,

That will be very helpful!

Heiner