Don't force "preserved filename" writing (make it optional)

[akirot]

Starting with IMatch 2019.1.4 a rename forces "preserved filename" to be written.

This is counterproductive in many cases:

1.) I produce jpgs for web (with the batch processor) containing only a limited/restricted set of metadata.
As a last step before uploading the files I rename them.
This generates "preserved filename" - I don't want this information in files I upload to the web.
It also (since metadata is changed) forces a write-back - this costs time and interrupts my workflow.
Here I don't want "preserved filename" written at all.

2.) After ingesting my raws I firstly rename the files giving them unique names (which never change).
This first (and only in the lifetime of these files) rename preserves the filename as produced by the camera.
If I want a filename to be preserved it would be the one I initially have given (but not the camera produced filename).

Personally I could live without "preserved filename" written at all.

The feature request is:

1.) either (at least ;-) ): make "perserved filename" writing optional via "preferences". I.e. if set to "on" it behaves as started with Version 2019.1.4, if set to "off" it behaves as before

2.) or: add an option field to the renamer dialogue which asks for filename preservation.
Depending on user's choice the filename is preserved or not.

I prefer the second option because it provides the opportunity to write sensible information into this field when I want it (on a case by case basis).

[ubacher]

I like the idea of preserving the filename when renaming. I think many accidental/unwanted renames could be reversed that way
helping many users in such a bind.


However: I too am bothered by getting a yellow pencil after a rename.

My suggestion would be:
- option in renamer to preserve filename (at any rename)
and
- option to enable filename preservation as now. (Only first rename on the file)
       (that's needed only if you rename via a script like I do)

(Caution: I have not fully thought this thru!)

What about the photools:cameraname tag which is set at the same time as the preserved filename?
(which I can not find listed among the tags!)

[Mario]

The preserved file name is updated by a central routine used by the IMatch engine when a file is renamed. This is not only used by the Renamer, but also by the normal file rename, renames performed by IMWS (apps), renames performed when copying and moving files etc. It makes no sense to add an option to the Renamer.

The only way would be a global option. But Lightroom and many other RAW/DAM processors also store this data and have no option to disable it. I hence guess that most users don't care or know about and hence adding yet another option to IMatch is not needed. We have too many options already. I always try to remove options to simply things, not add more complexity.

The camera name is a photools.com tag that is set when a file is ingested. See Metadata Panel, Browser mode.
The tag is accidentally added when a file is to be written back (in your case, when the preserved file name is set).

As I said in several posts (https://www.photools.com/community/index.php?topic=8717.msg61339#msg61339), I will look into this small glitch with camera name for one of the next releases. It does not really cause any problems, just a warning from ExifTool about an unknown tag.

When the preserved file name is set, the metadata in the database no longer matches whats in the file and hence a pending write-back is indicated correctly. No difference between this and other tags.

[ubacher]

Would it not save the rewriting if the preserved file name is filled when the file is ingested? After all it will
always be that value. I can see no negatives doing it this way.

After ingesting many new files and renaming them having to rewrite them once again does cause a lot of
inconvenience/time loss.

[Mario]

Would it not save the rewriting if the preserved file name is filled when the file is ingested?

This tag is to be filled on the first rename. At least this is how I interpret the standard documents and how other applications handle this.
If the tag does not exist this means that the file has not been renamed.

For your workflow: IMatch usually has to write-back all files after ingest, because it produces a much richer metadata than cameras or other software. Just rename before writing back the first time and you fine.

[ubacher]

Is it worth burdening all users with the extra metadata rewrites (even though they are much faster now)
to follow this standard? Was there a request for this - i.e. a good reason to add this?

[Mario]

Basically IMatch was missing support for this until now. I should have added that earlier. It's more standard and fits into all standard workflows better.
A write.-back after renaming files is not that bad, really. Especially if you ingest and rename your files and then, when finished, do a write-back once. Not much of a burden.

[akirot]

Using a Metadata Template to copy file.NameExt to XMPMM:PreservedFileName to me looks like a much easier and straightforward approach.
Everybody who needs the PreservedFileName in the workflow can save the name when suitable (plus decide what to save).

Once it's stored no further care needs to be taken.

Definitely there is no need to create the field if it's not yet there and/or needed (especially if one creates files which by intent have the least possible metadata content for web).

Please, Mario, provide an option to switch it off (or roll back this "enhancement" since Metadata Templates are much easier).

To me the additional write-backs are a real burden.

BTW where do you find any "official" description of this tag? I know Adobe uses it - but it is not mentioned in the XMP Specs (from 2016, also from Adobe).

[Mario]

I think I will keep it as it works now. Its a requirement in professional workflows and does not get in the way.
If more than 1 / 2 users (say 10) ask for an option, I will of course reconsider. And there would then be again two possible options: a) Set but do not flag as write-back or b) Don't set.

[ubacher]

Code Select Expand

Using a Metadata Template to copy file.NameExt to XMPMM:PreservedFileName to me looks like a much easier and straightforward approach.
Everybody who needs the PreservedFileName in the workflow can save the name when suitable (plus decide what to save).

How about a provided metadata template which is preset to run on indexing. The user would then have the chance to turn this off.

(Or those who need it can be told to run this template on indexing)

[akirot]

@ubacher: You got the idea and it's quite easy.

@Mario: It definitely gets in my way - that's why I started this thread.
Please could you provide an official source where this tag is specified?

[mastodon]

I like the way it is now. I think a lot a people (even not pros) will look for the old filename (from the camera). I wanted it to do a lot of times before.

[Carlo Didier]

I like the way it is now. I think a lot a people (even not pros) will look for the old filename (from the camera). I wanted it to do a lot of times before.

Just curious, but why would you be interested in how the camera named the file? For me, that's the most useless and irrelevant information imaginable, so I'm interested in which workflow this could be useful.

[mastodon]

There are only personal photos in my database, but from lot of sources. From may cameras and phone, from family members and from colleagues. And with the original file names it is much easer and faster to find out, which ones I have in the collection.

[sinus]

I like the way it is now. I think a lot a people (even not pros) will look for the old filename (from the camera). I wanted it to do a lot of times before.

Just curious, but why would you be interested in how the camera named the file? For me, that's the most useless and irrelevant information imaginable, so I'm interested in which workflow this could be useful.

People are different.
In the last time I have more and more clients, who wants see the image during the shooting in my cam.
I do not like it, but it is very hard, to avoid this (some wants even take a pic with the handy from the monitor, what want you do, if your client asks for this?)

Hence some people aks me LATER, that they want have the image with the number .... what they have spottet on my camera - monitor.

I personally do this since ages, I copy with IMatch in the very first step this cam-name into a (free) Metadata-field. Helped me sometimes.

[PaulS]

I like the idea of having this optional.

This is because I have IMatch configured in my current workflow to not write any metadata to the files when I ingest them.  Of course this means that my files are not MWG compliant but I have also avoided a lot of the issues I observe in the forum related to conflicting metadata.

The only standard metadata changes I make are to add EXIF GPS information using GeoSetter for files that don't have it.  When I tested IMatch some time ago for adding GPS coordinates it wrote a lot of additional XMP metadata and so I abandoned that approach.

I am planning to look into making my files MWG compliant at some point in the future.  Most likely when I also figure out the best way to add Picasa facial recognition metadata to the files.

[herman]

I support this request.

The first thing I do after ingestion of my out-of-camera images is to make them read-only.
I don't want them to be touched.
If anything needs to be written it has to be done in sidecars, even if the standards say sidecars are not the way to do it (i.e. for DNG and JPG files).

That is the very reason I even don't use star ratings or labels.

I do know that makes the metadata of my images non-compliant in MWG-standard terms, but it works for me.

[Mario]

(....)
This is because I have IMatch configured in my current workflow to not write any metadata to the files when I ingest them. 

1. IMatch does not write to files when you ingest them. It only writes the new metadata produced at this stage to the database (unless you explicitly enable the immediate write-back option).
2. IMatch will always produce new metadata, not only for MWG reasons. Keywords are merged, timestamps are updated, digest information is generated, specific tags are set as per standard.
3. MWG compliance must be the rule, not an option. Turning it off is whats causing problem.
4. It hence does not make a difference if IMatch preserves the old file name when you rename a file. This change only goes into the database and will be flushed to the file with all other modified metadata only when you write back.

[Mario]

If anything needs to be written it has to be done in sidecars, even if the standards say sidecars are not the way to do it (i.e. for DNG and JPG files).
That is the very reason I even don't use star ratings or labels.
(...)
I do know that makes the metadata of my images non-compliant in MWG-standard terms, but it works for me.

How peculiar. JPG and DNG files must use embedded XMP to make them compatible with other applications. Legacy IPTC, EXIF and GPS data is always embedded in the image file, and as a copy also in the XMP. Hence it is paramount to keep the EXIF/legacy IPTC/GPS data synchronized with the XMP in all cases.

In principle, whatever works for you is good. I strongly recommend not doing this, though.
But please always include the information about your peculiar workflow when you report issues with metadata some day. This will save us all a lot of time searching for the reason of the problems.

[PaulS]

3. MWG compliance must be the rule, not an option. Turning it off is whats causing problem.

After investigating my preferences, I recognized that I was wrong.  I do have MWG compliance = Yes.  The only changes I have made to the Metadata 2 Defaults are:  Protect unwritten metadata = No, Preserve date/time of original file = Yes, Keep existing XMP = No, Keywords Base = Faces.

My workflow has worked well for me and I haven't had metadata problems until this change. 

Honestly, I do like the feature and can see why others would as well.  But I'm concerned that I will have an issue because renaming now creates metadata with pending write-back to the file and nothing else in my workflow has done this in previous IM versions.

2. IMatch will always produce new metadata, not only for MWG reasons. Keywords are merged, timestamps are updated, digest information is generated, specific tags are set as per standard.

After ingesting files I rename them, make changes to timestamps in ECP if needed (very uncommon) and add GPS metadata with GeoSetter if needed (very common).  After any changes, I rescan the files to keep the metadata in sync.

I don't write keywords or add ratings or descriptions to files.

At no point did I get the yellow pencil, so it seemed that IMatch did not identify a need to write any new metadata to the file prior to 2019.1.4.

Since I haven't updated yet, I can't test if reloading the metadata will clear this pending update.  If it does, I may have a work around.

1. IMatch does not write to files when you ingest them. It only writes the new metadata produced at this stage to the database (unless you explicitly enable the immediate write-back option).

Yes, you're right.  I have immediate write-back disabled. 

Currently when I see the yellow pencil it is a sign to me that I have accidentally changed metadata and need to investigate and fix.  But the yellow pencil will now be shown on every image after renaming.

Clearing pending write-backs was a feature in the past (IM3.6?) but it doesn't seem it is possible anymore other than by reloading metadata from the file.

4. It hence does not make a difference if IMatch preserves the old file name when you rename a file. This change only goes into the database and will be flushed to the file with all other modified metadata only when you write back.

As mentioned above, I don't ever have any metadata write-backs from IMatch.

At some point I will update my workflow to bring Face Annotations in from Picasa and store hierarchical keywords in the files and then this will become a non-issue since I will then have a reason for write-back.

[Mario]

(...)

As I always say, whatever works for you is good.
Just keep the consequences in mind when you change the proven and safe defaults in IMatch. IMatch it flexible enough to fit into many workflows. But this necessarily also means that IMatch allows you to shot yourself in your own foot.

For example: "Preserve date/time of original file = Yes" => This may trick your backup system to think that a modified file has not been changed.
And makes no sense really these days. This was a feature that was added in the old times for users who work with files without EXIF data and who wanted to retain the "last modified" timestamp. Not really needed this days, and may even be dangerous.

[PaulS]

Thanks for the warning about "Preserve date/time of original file = Yes".

I haven't had issues with this since my changes always either change the file size and/or date.  I use Beyond Compare for my primary backup method and compare file size and date.  And from time to time I also do file content comparisons.

This approach makes it easy to recognize when another program changes the file without me expecting it, whether accidentally or without my knowledge.  I can restore a valid version from a backup.  Unfortunately this does happen from time to time.

[Mario]

This feature request thread has unfortunately been used to discuss many other topis...

Anyway, I have added a new option to the next IMatch release which allows to disable the preserve original file name feature. See the release notes for details.

[PaulS]

Thanks Mario!

[akirot]

Thank you!!!!!!!!!!!!!!

[Carlo Didier]

Excellent!