In favor of a Wisiwyg Metadata entry panel

[cytochrome]

The best metadata entry panels I know are that of IM3.6, but it does only IPTC, and that of PhotoMechanic which does IPTC + XMP.

What is so nice. They work!! Once the different fields are filed and verified one click on "Apply" and what you see is what is written, to the sidecar, or the image file or both, depending on your settings. No fuzz, no questions asked, no verification if it has really functioned. It is fully predictable and reliable.

In IM5 it is not fully predictable and reliable. In fact one has to sacrifice a chicken and explore its intestine or make an exiftool dump to try to guess what will happen. This is in my view a serious design flaw.

Yesterday it happened again:

- metadata panel looked fine (see capture A)
- then I spot a misspelling in City name, correct it (for the whole folder, 91 files)
- click green hook and yellow pencil
- after lot of activity I have it fine the City is OK, all the rest is gone (see capture B)

Capture C shows my metadata settings.

Of course I had a backup, but it is frustrating. The tooltip is of no help because it says it will write City but does not warn it will erase all the rest.

IM5 CAN write the full metadata to my files: if I copy it (icon) and paste it again (icon). This effectively writes what is shown into the file. But this is on a per file basis, I really need a "copy what you see to where you want" button.

So for now I do all metadata entry to new photos in PhotoMechanic, works like it should. But IM can do a lot that PM cannot. Like group files from different folders etc.. It is a pity that all this power cannot be used without fearing to loose hours of work.

So this is my demand: if the actual Metadata panel can be made to work Wisiwyg, please do it. If not built an extension (IPTC + XMP) of the IM3.6 IPTC panel.

Francis


[attachment deleted by admin]

[Mario]

You are version 5.0.114, right?
This is important!

The Metadata Panel is WYSIWYG. I don't understand your complaint, really. What you see in the metadata panel is exactly what ExifTool has extracted from your image files.

You have set IMatch to ignore XMP sidecar files when importing data. May be the cause of this problem.
You have set IMatch to write XMP data to all supported formats (which includes RW2 files). This is also not the default setting.

As far as I can see from your screen shot, you are working with RW2 RAW files. These files may have an external XMP file and embedded XMP metadata.
Did you write the original (now removed data) in another application?
If so, it may be in the XMP sidecar file, not the RW2 file.
Since you forbid IMatch to read from XMP files, it will write XMP to the RW2 file, and then re-import the data. The XMP data in the sidecar is ignored and invisible for IMatch.

[cytochrome]

The metadata panel is not wisiwyg: it shows only, as you said, what exiftool extracted, not what it will write!!

- I used 5.0.114

- I imported into IM my folders of rw2 (same for the NEF) files with xmp sidecars with Import : "Favor sidecars" and Export : Mode 1

- I expected the metadata to be read from the sidecar and copied to the rw2. This is a reasonable expectation?

- the metadata was imported alright = it was shown in the Metadata panel

- then I set Import to "Ignore sidecars" because I want to make away with and be sure IM writes to the file and not sidecar

- despite the mode 1 selection, the metadata was not written to the RW2 (this I discovered only afterwards) it existed only in IMatch.

In this situation, if you make a change in ONE field and commit the change this unique change will be written to the RW2 and the panel will only show this field because IM no longer uses the sidecar. This is logical, what is not logical is that the complete panel as shown on screen is not copied to the file: this would be wisiwyg, I would get what I see, and not see what I get 

What I noticed: once metadata has been written to the raw, everything works.

So now I am going through all my folders, use the ECP to force writing of xmp to the raw. Still, when i make a change in the metadata panel I have no confidence that it is written to the raw, so I open ExiftooGUI and check. Big waste of time.

I reproduced it many times, easy: import a virgin raw file with metadata in a sidecar, then set import to Ignore sidecars et export to mode 1, do any change in the panel, commit the change (green hook and yellow pencil) and see what happens;

When I copy and paste metadata with the icons the whole panel is copied to the recipient file. I would like to apply this on the whole selection.

Francis

[Mario]

- I expected the metadata to be read from the sidecar and copied to the rw2. This is a reasonable expectation?

No. Misconception.

When you change metadata in IMatch, IMatch records which data was changed.  For example, you change the title and some keywords.
When you write back the data, IMatch instructs ExifTool to update the title and the keyword with the new data.
This pattern ensures that only minimal changes are made to the metadata in the file and that existing metadata remains unchanged.

Afterwards IMatch re-imports the metadata to incorporate the changed metadata into the database. Changing an XMP title will not only change the XMP title but also the IPTC headline, IPTC digest, modification timestamps etc.

You read metadata from the sidecar but write metadata to the RAW file. This process does not copy the XMP data from the sidecar file into the RAW file.
Such an "Import data from the XMP sidecar file into the RAW file" is not implemented in IMatch.

If you need to switch from sidecar data storage into embedded storage for your RAW files, you can do that by running ExifTool manually, using the copy syntax to copy the XMP data from the sidecar file into the RAW. Then delete the sidecar file and configure IMatch to read and write from/to the RAW file.

[cytochrome]

- I expected the metadata to be read from the sidecar and copied to the rw2. This is a reasonable expectation?

No. Misconception.

......................
If you need to switch from sidecar data storage into embedded storage for your RAW files, you can do that by running ExifTool manually, using the copy syntax to copy the XMP data from the sidecar file into the RAW. Then delete the sidecar file and configure IMatch to read and write from/to the RAW file.

OK, I thought it will work because it works this way in PhotoMechanic, but I gave up.

Now, I do it the IMatch way since 3 days. I went back to all my files that still had sidecars, (essentially several thousand  RW2 because in IM3 I wrote metadata direct to the NEF and sidecars for the RW2), I copied the metadata to the files with the ECP (works well), checked with ExiftoolGUI that it was effectively written to the raw and then deleted all sidecars from these folders (I have a complete backup).

For new files I ingest with PM, it writes to the files very quickly (metadata to 130 files in about 8 seconds) and it has a gpx to GPS data function as good as that of geosetter (updates GPS data in a folder in a few seconds). Then I import into IM5, no problem at all apart from the time it takes IM to read the metadata and write it back to the database, but this sis a one time thing, so OK.

The problems in IM5 came when I selected categories that included many files with infile xmp and some still with sidecars (that I did not see): gave the results I complained for.

Now I have a solid workflow, very cautious, and all is well. Only complaint is speed. Part of the problem came from delaying the write back to gain in speed, but as a result the panel and what was in the files was out of synchrony.

Speed is the biggest problem in this beta. All internal IMatch activity (categories etc) is very fast and fine. Metadata handling is a burden, I am afraid at the idea I could some day be forced to use keywords!!

Francis

[Ferdinand]

You read metadata from the sidecar but write metadata to the RAW file. This process does not copy the XMP data from the sidecar file into the RAW file. 

Now that Francis is satisfied for the moment - can I ask a question of ignorance?  If I have IMatch configured to read from the sidecar but write to the file, how will this work?  Is there a risk of data loss?  E.g., say I set a rating of 1 star, which will get written to the file.  But if I do a rescan of the metadata, won't it read from the sidecar and wipe the rating?  I have no intention of working this way, but it's always puzzled me how this would operate.

[Mario]

If I have IMatch configured to read from the sidecar but write to the file, how will this work?

You are deliberately created two sets of metadata for the same file. Do you have a reason for doing this?

If IMatch reads from the sidecar file, but writes to the image file, changes made in IMatch are only in the image.
The next time IMatch has to re-read the data, it will read it again from the XMP file. And your former changes to XMP data will be lost of course, because as per your configuration, only the data in the sidecar file counts.

IPTC, EXIF and GPS data will aways written to the image file itself (it can only exist there). But XMP data can come from either the sidecar or the image file. You must decide which one to use.

[Mario]

OK, I thought it will work because it works this way in PhotoMechanic, but I gave up.

PhotoMechanic is perhaps always writing all the IPTC, EXIF, XMP, GPS and other metadata? I don't know if it supports all the MWG protocols and all the metadata. I've found that changing existing metadata in images only where needed is best. This ensures the best metadata quality and also minimizes the risk of damage by moving EXIF maker notes around in files (especially in RAW files).

Or do you mean PM has a separate feature which allows you to deliberately re-import XMP data kept in a sidecar file into the RAW file?
The better way is usually to not modify the RAW file at all, and always keep the XMP data in the sidecar file...

the write back to gain in speed, but as a result the panel and what was in the files was out of synchrony.

Only when you mix XMP data with IPTC or EXIF data. IMatch migrates from XMP to EXIF/IPTC only when the data is written, so you may see some values out-of-synch when you mix data from different standards. But that's rarely a need to mix IPTC, EXIF and XMP metadata in the Metadata Panel - all relevant IPTC and EXIF tags have counterparts in XMP. If you only view and modify XMP in the Metadata Panel you'll never see out-of-synch tags.

IMatch 5 gives you an enormous flexibility about which data you display in the Metadata Panel, the File Window, tooltips, App Panels and elsewhere. If you stick to the basic XMP, you'll be fine and you'll never see temporarily out-of-synch values for linked tags from different standards.

Speed is the biggest problem in this beta. All internal IMatch activity (categories etc) is very fast and fine. Metadata handling is a burden, I am afraid at the idea I could some day be forced to use keywords!!

My tests show that IMatch 5 performs faster than IMatch 3. Importing metadata is slower and writing is also slower. But IMatch does it in the background while IMatch 3 was blocked.

I could speed up reading and writing by limiting metadata support to the minimum of tags, e.g. like LR is doing. One of the key points in IMatch 5 was that it should exceed all other applications in both metadata versatility and quality. That it takes a bit longer to write metadata is due to ExifTool and the way ExifTool updates files. ExifTool always uses the safest way, which means it works on a copy of the original file until it is sure that the result is safe and sound. This is slower than in-line updates other software performs.

When I understand you correctly, you are forcing IMatch to update the metadata in the RAW file. This is 10 to 100 times slower than just updating XMP metadata in a sidecar file.

The fastest metadata workflow is to disable MWG compliance and to not update EXIF, GPS and IPTC data at all. Only work with XMP, and always use sidecar files except for standard formats. IMatch / ExifTool can update XMP data in sidecar files very fast. Rewriting 20 to 50 MB RAW files every time to update some XMP records is slower. The same is true for the extra logic required to migrate between IPTC, EXIF and XMP.

[cytochrome]

Mario,

As the owner and programmer of IM you know the program a

[Mario]

Your post seems to be incomplete...?

[cytochrome]

Yes it is, I am generally less concise . Here it is

Mario,

You are the owner and the programmer of IM, so you know the product a zillion times better than me. I don't discuss this at all.

On the other hand as a user and buyer (I'll buy it when it goes commercial ,no doubt) I want to adapt it to my workflow  and not the other way around.  I don't like sidecars and will set them aside. I remember you said that you ditched all Nikon software and switched to Adobe, but you cannot ask from every user to follow you there. There will be (few) people like me who prefer the metadata in the image file, raw included.

To me IMatch is much more than simply entering of metadata, and it is this "much more" that I like, why I use IM and will continue to use it.  Given my options, I want simply to do it in the most sensible way.

At this time I ingest new files and populate metadata in PM. I know nothing of the internal working of PM and don't care, its just an (expensive) ingester. It has a metadata2-like panel with lots of options, but basically you tell from where it must read the metadata and where it must write it. It does it reliably, fast. They don't use Exiftool (does not appear in the Task manager when PM updates files), perhaps SDK like you did in IM3?

On the other hand PM has none of the possibilities of IM to group files on different criteria, it works on a file/folder basis. And this is why I also use IM5 to correct metadata on file groupings, and of course I would prefer to have it running faster. But I can live with the actual speed (although I am a quite old guy, so my personal timer is running towards its end too ).

So 1) I will continue my infile_metadata_no_sidecar way and 2) I will cease to bring up the subject on this forum unless I stumble on something that is of general interest.

Francis

PS I re-read your post:

-I don't use any exotic metadata tag, in fact my personal panel uses the same tags than the standard panel shipped with IM

- yes I "force" IM to write to the raw file, but since I don't use ratings or labels, exclusively  author, headline, description and full location (+ occasional GPS data) this does not change often. I have an impression that IM writes more than needed. It is not me that decide that xmp-headline goes also to the iptc, in fact I have no choice at all for what is xmp or iptc with my settings (no sidecar and write mode1). This is IM doing its thing...

-     If I have IMatch configured to read from the sidecar but write to the file, how will this work?

You are deliberately created two sets of metadata for the same file. Do you have a reason for doing this?

No, nothing deliberate. IM3 could not read/write metadata to the RW2 so it created sidecars (and PM got this capability only recently). So nolens volens my Pana metadata were in sidecars. When I imported in IM5 the sidecars went along, were read, and I "simply" tried to transfer the metadata to the RW2 since iM5/exiftool can read/write to the raw. So it was not deliberate to have 2 sets, it is a transient and obligate stage (unless I recopy everything by hand!!). Now I ditched the sidecars and there is only one set left, in the raw file where I like it and feel it is safe and transportable.

[Mario]

I have an impression that IM writes more than needed. It is not me that decide that xmp-headline goes also to the iptc, in fact I have no choice at all for what is xmp or iptc with my settings (no sidecar and write mode1). This is IM doing its thing...

IMatch by default applies the rules and guidelines published by the Metadata Working Group (see http://www.metadataworkinggroup.com/). The recommendations are designed to improve interoperability between applications and consistency of metadata between IPTC, EXIF and XMP metadata.

For example, if you update the XMP description, the MWG requires that the corresponding IPTC tag Caption/Abstract is set to the same value. There are about a hundred or so tags which have been assigned rules on how to migrate data between standards. There are also some super tags, timestamps and so-called digests to maintain in order to allow other software to detect metadata changed by other applications.

This is what IMatch is doing when you enable the MWG compliance under Edit > Preferences > Metadata 2. It requires quite a lot of shuffling data around, but ExifTool does it reliably and right. Whatever other applications you use in your workflow, the metadata generated or modified by IMatch is compatibly with a wide range of applications on all platforms, operating systems and web services.

When you disable MWG compliance and you update only XMP metadata, IMatch will also update only the XMP metadata in your files. This will require less data shuffling and can improve overall performance considerably. But I would always go for MWG compliance because that is the best standard we have now and it gives you the best data quality for the future.


My reply about reading from XMP and writing to the RAW was in response to Ferdinand's question.

[cytochrome]

You read metadata from the sidecar but write metadata to the RAW file. This process does not copy the XMP data from the sidecar file into the RAW file. 

Now that Francis is satisfied for the moment - ............

Hopefully for more than a moment! I had no seen your post.

From what I learned (the hard and confuse way)it  is safe to set metadata2 to read from sidecar, once the info appears in the MP set metadata2 to ignore sidecar, don't edit anything in the MP and first commit the change to the file (write mode 1).

Once it is in the file (check with exiftoolGUI or similar), one can edit etc... Then the rules and MWG compliance come into play but you know all this better than me.

I use from time to time Nikon software, and never ACR, so it makes sense (I believe). For Adobe users it must be very difficult, sidecars are the evident choice.

Francis

[cytochrome]

I have an impression that IM writes more than needed. It is not me that decide that xmp-headline goes also to the iptc, in fact I have no choice at all for what is xmp or iptc with my settings (no sidecar and write mode1). This is IM doing its thing...

IMatch by default applies the rules and guidelines published by the Metadata Working Group ...

Thank you Mario for the explanation. I had a confuse view of the MWG and only got an inside view yesterday when I set up my ECP scipts for direclty writing some tags into the files (I still dont understand the error message Error using module xmp2iptc.args I reprot here: https://www.photools.com/community/index.php?topic=866.0 )

I am collecting all your answers in a special file, helps me when the Help is not enough.

I will do a speed test with/without MWG, but I'll stay on the safe side and keep it ON for "real" work

Francis

[Mario]

It would be helpful to see the timing information IMatch writes to the ExifTool Output Panel (<F9>,<O>) for some of your RAW files. This tells us how long ExifTool needs to write back data to your RAW files.

I've made a test with a few RW2 files (write back to the image file).
To warm the system up and to load ExifTool I first set a rating to one RW2 file.

I then change the title, description, rating, label and some keywords for another RW2 file (file size is about 15 MB).
ExifTool reports 0.6 seconds to update the file (MWG compliance is ON).

The line to look for in the output panel is

----- Runtime: 0,6 s.

On your system, how long requires ExifTool to update a file?

[cytochrome]

I did a test with just one file (and no warm up -reminds me of my first motorbike!!)

The RW2 had a version, hence the update of the P1004404-B5_web.jpg file.

I checked with exiftoolgui that the data was effectively written to the files (rw2 and jpg).

What do you think?

----- Runtime: 0.1 s.

Code Select Expand

-overwrite_original
-m
-use
MWG
-ex
-sep


-XMP:Label=
-XMP:CreatorTool=photools.com IMatch 5.0.0.114 (Windows)

-xmp:InstanceID=xmp.iid:367f51a6-80a2-452a-b70e-a712bbcbfea4

-MWG:ModifyDate=now
-XMP:MetadataDate=now
D:\Images\GF1\Septembre_2011\Web\P1004404-B5_web.jpg
-execute9999

    1 image files updated

----- Runtime: 0.1 s.

[Mario]

That's the time for the JPEG.  1/10 of a second is fair.

What's the time for the RAW?

[cytochrome]

OK, this time  i chose a rw2 without any version. It is 0.8 sec

I include the whole output. Is all this needed? I mean all this writing, I chnged only 5-6 tags

Francis

Code Select Expand


-overwrite_original
-m
-use
MWG
-ex
-tagsfromfile
D:\Images\GF1\Novembre-2012\P1005173.RW2
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\exif2xmp.args
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\iptc2xmp.args
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\gps2xmp.args
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\pdf2xmp.args
-sep


-Composite:City=Pr
-Composite:Location=Bl
-Composite:State=Prov
-XMP:Creator=
-XMP:Creator=Franci
-XMP:Description-x-default=4 novemb
-XMP:Headline=Couleurs sous
-XMP:ImageDescription=4 novemb
-XMP:CreatorTool=photools.com IMatch 5.0.0.114 (Windows)

-xmp:InstanceID=xmp.iid:9badb8f6-8171-4842-834d-add62bfccdde

-MWG:ModifyDate=now
-XMP:MetadataDate=now
D:\Images\GF1\Novembre-2012\P1005173.RW2
-execute
-overwrite_original
-m
-EXIF:ImageDescription=
-EXIF:Software=
-EXIF:Copyright=
-EXIF:Artist=
-IPTC:By-line=
-IPTC:Caption-Abstract=
-IPTC:CopyrightNotice=
-IPTC:Keywords=
-IPTC:ObjectName=
-IPTC:By-lineTitle=
-IPTC:Writer-Editor=
-IPTC:Category=
-IPTC:City=
-IPTC:Country-PrimaryLocationName=
-IPTC:Credit=
-IPTC:DateCreated=
-IPTC:TimeCreated=
-IPTC:Headline=
-IPTC:SpecialInstructions=
-IPTC:Source=
-IPTC:Province-State=
-IPTC:SupplementalCategories=
-IPTC:OriginalTransmissionReference=
-IPTC:Urgency=
-IPTC:Country-PrimaryLocationCode=
-IPTC:Sub-location=
-IPTC:DigitalCreationDate=
-IPTC:DigitalCreationTime=
-PDF:Title=
-PDF:Author=
-PDF:Subject=
-PDF:Keywords=
-PDF:Creator=
-PDF:Producer=
-PDF:CreateDate=
-PDF:ModifyDate=
-PDF:Trapped=
-tagsfromfile
D:\Images\GF1\Novembre-2012\P1005173.RW2
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\xmp2exif.args
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\xmp2iptc.args
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\xmp2gps.args
-@
C:\Program Files (x86)\photools.com\IMatch5\arg_files\xmp2pdf.args
D:\Images\GF1\Novembre-2012\P1005173.RW2
-execute9999

    1 image files updated

    1 image files updated

----- Runtime: 0.8 s.
Warning: Error converting value for ExifIFD:SubSecTimeOriginal (ValueConvInv) - D:\Images\GF1\Novembre-2012\P1005173.RW2


[Mario]

0.6 to 0.8 seconds is also the times I get here.
The number of tags modified does not cause much of a change.

Write-back for 60 to 80 RAW files per minute, a lot more JPEG files per minute. Not bad. Thanks.

[cytochrome]

Yes, this is not bad, but it is only the fast part of the process.

In a mixed folder of 35 rw2 nef + 2 jpg I changed metadata (author, location, description), clicked green hook ==> after less than a minute IM says All activity etc... Then I have to click the yellow pencil ===> after about 2 minutes Im says All activity etc, but now it says (red at the botoom of the screen) metadata 31% etc... after 2 more minutes it is done (the CPU in Taskmanager goes to zer0).

So it is at least 4 minutes during which IM is lost to the world: it goes all white if I try to do something.

Well anyway, this is it, I can live with it because I like the program and the overall concept.

Francis

[Richard]

Well anyway, this is it, I can live with it because I like the program and the overall concept.

Hi Francis,

That statement sounds is if IMatch 5.0.116 is the final version. In the last twelve years IMatch development has been a nonstop process and I don't expect that to change much. Several times a year Mario would release a new version and each one had an improvement somewhere. Very few were simply bug fixes. Often a new version would add a new feature and often included speed enhancements in some feature. What we see today is not what we will have a year from now. When it comes to IMatch, if we have to live with  anything, it is frequent updates with new improvements. Every complaint, feature wish, bug report does get Mario's attention and I have seen many, many user driven changes. At this time Mario has to prioritize and bugs are going to top his list but that doesn't mean that many other items are removed from his list. Speed improvements are likely closer to the bottom of the list but they will come when Mario has time and can do so.

As users we also have to take time into account. Many users knew that 3.x would take a long time to complete a task so they would simply plan on doing something else once they started such a task. I can get impatient when I have something in the microwave but I know that will take nn minutes so I plan accordingly. If I don't like to wait I could spend some money on a microwave with higher wattage but it is cheaper to plan how to use my time while I wait.

[Mario]

In a mixed folder of 35 rw2 nef + 2 jpg I changed metadata (author, location, description), clicked green hook ==> after less than a minute IM says All activity etc...

Do you have the log file from that test? I need the timing information in the log file to see what took so long.

Storing metadata changes for 35 files in the database should be instantaneous.

For a test I changed title, description, rating and label in the Metadata Panel for 1,000 files. IMatch performed the required database update in 6.2 seconds, then it was available again for user input. My computer is five years old, 46,000 files database on normal hard disk.
(It updates the search index in the background afterwards, but that does not interfere - except your system has only one processor).

Write-back and the following metadata import, index updates, category updates, collection updates and will require more time and depends on many factors.

The log file will help me to understand why updating 35 files takes 'less than a minute' (it should be barely more than a short blib).

[Ferdinand]

If IMatch reads from the sidecar file, but writes to the image file, changes made in IMatch are only in the image.
The next time IMatch has to re-read the data, it will read it again from the XMP file. And your former changes to XMP data will be lost of course, because as per your configuration, only the data in the sidecar file counts.

Let me restate that I have not intention of working this way.

But it worries me that someone who doesn't fully grasp all this could leave themselves vulnerable to data loss.  I don't know what to suggest to prevent it.  The help file can only do so much.  I wonder if a warning could be shown when pressing OK to inconsistent preferences like this?

[Mario]

But it worries me that someone who doesn't fully grasp all this could leave themselves vulnerable to data loss.  I don't know what to suggest to prevent it. 

You cannot prevent a user shooting in his own foot. All the messages, info tips, help topics can do only so much.

The metadata defaults are safe. They are MWG-compliant and in line with Adobe software and other major applications. I think that the majority of users will never need to change them. And should not, especially if they work with Adobe software.

As soon as a user starts to fiddle with the metadata settings, he is responsible for his actions. I just assume that he/she has read and understood all that's in the help file, read and understood the MWG documentation and also the documentation of his/her other applications. Maybe posted a question here in the community to ask if and how he/she needs to change these settings to implement a specific workflow or make IMatch cooperate with some exotic application.

[cytochrome]

In a mixed folder of 35 rw2 nef + 2 jpg I changed metadata (author, location, description), clicked green hook ==> after less than a minute IM says All activity etc...

Do you have the log file from that test? I need the timing information in the log file to see what took so long.

.................

I don't have a log file now, but I will repeat it this evening and send you the log file.

I have thought a bit about all this:

- PM writes metadata to the files very fast, but it does only this, no catalog etc... so it is normal that it is fast

- IM writes quite fast also, a bit slower but this is exiftool doing it the safe way, so OK with me

- what really takes time in IM is the cataloging, at the minimum the file is opened, written to and closed twice but my impression is maybe 3 or 4 times??

I am not  a programmer so this will  sound utterly naive to you:

is it not possible to trick exiftool when it writes to the file (I understand it makes the sensible choices of what to write where) to write at the same time to a dummy file in memory, that would represent the content of infile metadata as written by ET? It would be ultra fast to write it to the DB without going through a new cycle of opening/reading/closing the file.

Francis

OK, her it is. 35 files, took this time around 80 sec to get into the files, maybe yesterday I had pending activity in the background.

[attachment deleted by admin]