- Welcome to photools.com Community.
Recent posts
#71
Solved Bug Reports (for next version) / Re: Face Arrangement
Last post by Tveloso - July 17, 2024, 07:35:17 PMQuote from: Mario on July 17, 2024, 06:31:23 PMWhen this depends (apparently in some way) on propagation, what do you propagate, exactly?I included a ScreenShot of the Relation Rue for this Version set in the email I sent, but it didn't show everything that's Checked to propagate (and only showed that propagation of Annotations was selected). The following items are checked in the What to propagate list:
And from which to what, with which file name patterns?
This will help me to setup the same for testing.
- Annotations
- Rating
- Label
- XMP Title
- XMP Description
- XMP Headline
- XMP Author
- XMP Keywords
- XMP Location Data
The FileName Patterns are:
Master Expression . . . : ^(img_)*[0-9_-]+.(jpg|jpeg|heic)$
Replacement Expression : <empty>
Link Expression . . . . : {name}_v0\.(jpg|jpeg|heic)$
The FileNames I have been testing with are (I included these files in the email as well):
Master . . . : 2024-07-05_112223_620_01.HEIC
Version . . : 2024-07-05_112223_620_01_v0.HEIC
(*Note: the Master Expression includes zero or more instances of the string "img_", because these files start out with FileNames of the form IMG_nnnn.HEIC and IMG_nnnn_v0.HEIC when they're first indexed, and I want them to be detected as a version set both before and after they have been processed by the Renamer)
Quote from: Mario on July 17, 2024, 06:31:23 PMAlso:Import XMP Face Regions and Automatic Face Recognition were both No during the test.
- State of XMP Face Region import (E > P > Metadata 2) for this test?
- Automatic face recognition enabled?
Quote from: Mario on July 17, 2024, 06:31:23 PMYou also disable XMP face region import - why?I have had this off since the early days of Face Recognition in IMatch...it used to be just one flag that controlled whether or not IMatch "processed" existing Face Regions, and at some point early on, you separated the options for Import and Export of the Region Data - and I have had the Import side disabled ever since.
This is on by default so IMatch can use work done by smart phones or other software. It also ensures that faces are restored ween an image is re-added after having been removed from the database - or after the user does a force update for some reason. Or after a propagation of XMP data from master to version!
I did this because I didn't like the Annotations that my iPhone had created, and preferred Annotations created by IMatch's Face Recognition. In many cases the Phone-created Annotations were just too large, and when there were two faces very close together, it was sometimes hard to tell exactly which face a given annotation was actually enclosing.
But I guess I can achieve the same results if I let the iPhone Regions get imported, and then if I don't like them, run Face Recognition in IMatch, and uncheck the Ignore Images with Existing Face Annotations option.
So I'll turn that option back on...(it's been a few years since I have tried letting the original iPhone Annotations into the Database - so maybe things are better there now)...
#72
Solved Bug Reports (for next version) / XMP::iptcExt\PersonInImage is ...
Last post by mlavicka - July 17, 2024, 06:54:54 PMPersonInImage is imported after a reload of the database, and IMatch incorrectly sets it to pending metadata writeback, even though it has not changed. Also, the pen icon does not display, which may be further indication that it is the same value. Here are my steps:
0) Ensure all metadata is written to files in existing DB and also export People json file.
1) I delete existing DB and create new empty DB.
2) I import previously exported IMatch_People.json file so IMatch can match up the people when reloading images
3) I reload images and compact DB
4) Everything looks good with the photos, but somehow all of the files with PersonInImage are marked as "Pending Metadata Write-back". The viewer does not show the pen icon, and the Metadata values all match what is in actual files.
Preferences:
- Protect "unwritten metadata", "Rating and Label", & "existing XMP" all set to "No"
- "Import XMP Face Regions" set to "Yes"
- "Import IPTC PersonInImage" set to "Import tag value as-is"
0) Ensure all metadata is written to files in existing DB and also export People json file.
1) I delete existing DB and create new empty DB.
2) I import previously exported IMatch_People.json file so IMatch can match up the people when reloading images
3) I reload images and compact DB
4) Everything looks good with the photos, but somehow all of the files with PersonInImage are marked as "Pending Metadata Write-back". The viewer does not show the pen icon, and the Metadata values all match what is in actual files.
Preferences:
- Protect "unwritten metadata", "Rating and Label", & "existing XMP" all set to "No"
- "Import XMP Face Regions" set to "Yes"
- "Import IPTC PersonInImage" set to "Import tag value as-is"
#73
Solved Bug Reports (for next version) / Re: Face Arrangement
Last post by Mario - July 17, 2024, 06:31:23 PMWhen this depends (apparently in some way) on propagation, what do you propagate, exactly?
And from which to what, with which file name patterns?
This will help me to setup the same for testing.
Also:
- State of XMP Face Region import (E > P > Metadata 2) for this test?
- Automatic face recognition enabled?
Face regions are part of XMP and IMatch writes them.
When you propagate XMP, faces will be propagated from the master to versions.
In your case, you say the master becomes pending, with the XMP face region tags when you do a force-rescan of a version! But this process has no impact on other files, until they are a version.
If a version comes new into the database (or a forced update is done), IMatch must propagate from the master to the new version to ensure the data in the version is correct. This involved the master being written, then data being propagated from the master to versions. Maybe a side effect of this.
You also disable XMP face region import - why?
This is on by default so IMatch can use work done by smart phones or other software. It also ensures that faces are restored ween an image is re-added after having been removed from the database - or after the user does a force update for some reason. Or after a propagation of XMP data from master to version!
I guess this is somehow caused by face annotations being propagated, XMP face region import being disabled or something. There are always combinations of things to propagate and options people choose that I have never anticipated or which would be to complex to support.
Maybe I can reproduce this somehow using your setup.
And from which to what, with which file name patterns?
This will help me to setup the same for testing.
Also:
- State of XMP Face Region import (E > P > Metadata 2) for this test?
- Automatic face recognition enabled?
Face regions are part of XMP and IMatch writes them.
When you propagate XMP, faces will be propagated from the master to versions.
In your case, you say the master becomes pending, with the XMP face region tags when you do a force-rescan of a version! But this process has no impact on other files, until they are a version.
If a version comes new into the database (or a forced update is done), IMatch must propagate from the master to the new version to ensure the data in the version is correct. This involved the master being written, then data being propagated from the master to versions. Maybe a side effect of this.
You also disable XMP face region import - why?
This is on by default so IMatch can use work done by smart phones or other software. It also ensures that faces are restored ween an image is re-added after having been removed from the database - or after the user does a force update for some reason. Or after a propagation of XMP data from master to version!
I guess this is somehow caused by face annotations being propagated, XMP face region import being disabled or something. There are always combinations of things to propagate and options people choose that I have never anticipated or which would be to complex to support.
Maybe I can reproduce this somehow using your setup.
#74
Solved Bug Reports (for next version) / Re: Face Arrangement
Last post by Tveloso - July 17, 2024, 05:39:49 PMQuote from: hluxem on July 17, 2024, 05:54:13 AMIf I understand this correct, you delete the face annotation in the viewer. I used right click - Face Annotation & People - Delete Faces - Delete All Faces. It's easier as you can select multiple images and it may be different than deleting the face annotation squares.Thank you. I tried this, and the "No Faces" condition was fixed once I disabled the Relation Rule.
You may also want to see if you can fix the versions by temporary pausing the relation rule.
I first tried deleting the Faces via the File Window Delete All Faces command (without making any other changes), and following the Force Update, the File returned to its "No Faces" State. But After I disabled the Relation Rule, and set Import XMP Face Regions to Yes, another Delete All Faces, followed by a Force Update now had the variable reporting "Two Faces"
Interestingly, after I reactivated the Relation Rule (and did an F4,R on the Master to re-establish the Version set), a forced propagation from the Master (F4,P) once again changed the Version to reporting "No Faces". So it does seem that propagation is one cause of this.
Quote from: Mario on July 17, 2024, 09:01:22 AMYes, exactly right. It is at this point that the Master is set to needing a Write-Back. The Pencil appears on the Master immediately - even while the Version is still being processed by the Shift+Ctrl+F5, Force Update.QuoteFollowing a Force Update of the Version File:With"forced update" you mean you used Shift+Ctrl+F5 and forced IMatch to wipe out all metadata for the version in the database and then re-import what's in the file?
Quote from: Mario on July 17, 2024, 09:01:22 AMDoes the version in your case contain XMP face regions? Is the import of XMP face regions enabled in E > P > Metadata 2 (default).The Version File does contain Face Regions (as originally written by IMatch), but I keep Import XMP Face Regions set to No in E > P > Metadata 2...(I turned it on momentarily, only during the first test described in Post #11).
Quote from: Mario on July 17, 2024, 09:01:22 AMWhen you slightly move a face annotation in the version, does the variable correct itself?Yes, moving even just one of the face annotations slightly causes the variable to now return "Two Faces". If I propagate again from the Master, the Version returns to reporting "No Faces".
Quote from: Mario on July 17, 2024, 09:01:22 AMSince thew master (!) metadata changed when you forced an update of the version, it seems that there are some issues with your file relations - e.g. the master sometimes becoming the version?I hope that's not the case...I feel like my File Relations have been working well.
Quote from: Mario on July 17, 2024, 09:01:22 AMI don't see how face regions in a master can change when you perform a forced update on a version.It does seem that this is definitely happening though. Doing a Force Update on the Version (even without first deleting the Face Annotations there), causes the master to be set to needing Writeback.
I recorded a Debug Log while I was performing the subsequent tests in Post #11, and sent that to the support email. So hopefully there will be something there that will explain how the Master gets updated that way.
#75
Solved Bug Reports (for next version) / Re: CSV Import
Last post by Mario - July 17, 2024, 02:58:49 PMQuote from: thrinn on July 17, 2024, 01:50:20 PMIs it possible that the OP refers to the old 8.3 "short filenames" in Windows? Would the CSV import work if the CSV contained 8.3 filenames? I think IMatch always uses the "real" (long) filename, right?Good point!
IMatch does not perform conversions of the shortened 8.3 file names in the CSV importer. Modern Windows versions also don't support the 8.3 shortening anymore by default.
#76
Solved Bug Reports (for next version) / Re: CSV Import
Last post by thrinn - July 17, 2024, 01:50:20 PMIs it possible that the OP refers to the old 8.3 "short filenames" in Windows? Would the CSV import work if the CSV contained 8.3 filenames? I think IMatch always uses the "real" (long) filename, right?
#77
General Discussion and Questions / Re: how did you change your Li...
Last post by Mario - July 17, 2024, 01:18:52 PMThe "Smart Collections" in the blog post can be done in IMatch easily using categories.
IMatch automatically keeps track of which images have e.g. no headline or rating and more in the IMatch Workflow Categories.
You can let IMatch assign new and updated files to a category (Edit > Preferences > Indexing).
If you color-code these categories, you automatically have visual clues about the state of an image.
If you need stages in your workflow (new, reviewed, edited, delivered, archived and whatnot) you can do that via a corresponding category hierarchy.
For example:
Workflow
| New
| Reviewed
| ...
| Archived
Give each category a color code so you can always tell in the File Window in which state an image is in. Very simple.
But there is more: IMatch categories have very neat feature called Assignment Action. When enabled, assigning a file to a category (e.g. Reviewed) un-assigns the file from all sibling categories, e.g. from "New".
This makes it very easy to implement a staged workflow.
1. When an image comes into the database, it automatically gets assigned to Workflow|New.
2. When you have reviewed it, you assign the file to "Workflow|Reviewed" (e.g. via a Favorite). This automatically un-assigns the file from "Workflow|New". The color shown in the category color bar changes accordingly.
3. When you have edited the image you assign it to "Workflow|Edited". It is automatically removed from "Workflow|Reviewed".
Rinse and repeat.
Name the stage categories in any way you want and create as many stages as you need.
You can then always see how many files are in which stage and files show a visual indicator of their stage.
Such a workflow / staging concept is easy to implement in IMatch, when you need it.
IMatch automatically keeps track of which images have e.g. no headline or rating and more in the IMatch Workflow Categories.
You can let IMatch assign new and updated files to a category (Edit > Preferences > Indexing).
If you color-code these categories, you automatically have visual clues about the state of an image.
If you need stages in your workflow (new, reviewed, edited, delivered, archived and whatnot) you can do that via a corresponding category hierarchy.
For example:
Workflow
| New
| Reviewed
| ...
| Archived
Give each category a color code so you can always tell in the File Window in which state an image is in. Very simple.
But there is more: IMatch categories have very neat feature called Assignment Action. When enabled, assigning a file to a category (e.g. Reviewed) un-assigns the file from all sibling categories, e.g. from "New".
This makes it very easy to implement a staged workflow.
1. When an image comes into the database, it automatically gets assigned to Workflow|New.
2. When you have reviewed it, you assign the file to "Workflow|Reviewed" (e.g. via a Favorite). This automatically un-assigns the file from "Workflow|New". The color shown in the category color bar changes accordingly.
3. When you have edited the image you assign it to "Workflow|Edited". It is automatically removed from "Workflow|Reviewed".
Rinse and repeat.
Name the stage categories in any way you want and create as many stages as you need.
You can then always see how many files are in which stage and files show a visual indicator of their stage.
Such a workflow / staging concept is easy to implement in IMatch, when you need it.
#78
General Discussion and Questions / Re: how did you change your Li...
Last post by sinus - July 17, 2024, 12:11:14 PMWell, such ideas and workflows exist in a lot of DAMs. And they are sometimes equal or different, like you have changed some things for your personal workflow.
Such and a lot other ideas/workflows you can realise very good also, of course with IMatch.
Some ideas are in the workflow-thread, long ago I had also a thread there
https://www.photools.com/community/index.php/topic,10752.0.html
But workflows are very different for users, from very simple ones to very complicated.
And workflows usually changes over some time a bit, because the user sees simpler or better enhancements (like John did).
Such and a lot other ideas/workflows you can realise very good also, of course with IMatch.
Some ideas are in the workflow-thread, long ago I had also a thread there
https://www.photools.com/community/index.php/topic,10752.0.html
But workflows are very different for users, from very simple ones to very complicated.
And workflows usually changes over some time a bit, because the user sees simpler or better enhancements (like John did).
#79
General Discussion and Questions / Re: how did you change your Li...
Last post by Mario - July 17, 2024, 09:12:52 AMI'm not sure if there is a question in your post.
I do that all the time. My normal workflow when I use Lr.
You just need to remember: Both Lightroom and IMatch update metadata in files only when explicitly told so (in Lr this is a context menu command) and in IMatch it's the write-back command.
When you really have to edit metadata both in Lightroom and IMatch, note that the "other" application only sees metadata changes when you let the originating application write-back the metadata.
IMatch automatically detects when Lr changes a file and re-import it and reloads the metadata.
In Lr you have to explicitly tell it to re-import the metadata from the file again. Else you will only see the metadata Lr has in its catalog. This is not IMatch-related, it is just how Lr works. Lr is not designed to be cooperative.
You can configure both IMatch and Lr to write-back changed metadata immediately - (in IMatch: Edit > Preferences > Background Processing) but that's bad for performance and may impact your workflow. See the Lr help for details.
Most users leave it to their DAM and edit metadata only in IMatch. IMatch produces metadata that is as good or even better as Lightroom. And it produces much better metadata than other DAM products.
Editing metadata only in IMatch solves all these problems.
Else you have to live with how Lr works and tell Lr to write metadata to the file to make it available in IMatch. Else the data only sits in the Lr catalog, where it is inaccessible for other applications.
QuoteAnd I know that iMatch and Lightroom can't be running at the same time.You are mistaken. What makes you think that?
I do that all the time. My normal workflow when I use Lr.
You just need to remember: Both Lightroom and IMatch update metadata in files only when explicitly told so (in Lr this is a context menu command) and in IMatch it's the write-back command.
When you really have to edit metadata both in Lightroom and IMatch, note that the "other" application only sees metadata changes when you let the originating application write-back the metadata.
IMatch automatically detects when Lr changes a file and re-import it and reloads the metadata.
In Lr you have to explicitly tell it to re-import the metadata from the file again. Else you will only see the metadata Lr has in its catalog. This is not IMatch-related, it is just how Lr works. Lr is not designed to be cooperative.
You can configure both IMatch and Lr to write-back changed metadata immediately - (in IMatch: Edit > Preferences > Background Processing) but that's bad for performance and may impact your workflow. See the Lr help for details.
Most users leave it to their DAM and edit metadata only in IMatch. IMatch produces metadata that is as good or even better as Lightroom. And it produces much better metadata than other DAM products.
Editing metadata only in IMatch solves all these problems.
Else you have to live with how Lr works and tell Lr to write metadata to the file to make it available in IMatch. Else the data only sits in the Lr catalog, where it is inaccessible for other applications.
#80
Solved Bug Reports (for next version) / Re: Face Arrangement
Last post by Mario - July 17, 2024, 09:01:22 AMQuoteThe Master of the Version File that I manipulated for the test in Post #9 became pending for WriteBack also (even though it was not touched), showing the following to be in need of WriteBack:How can this happen? IMatch does not modify face regions in a master when you propagate versions.
The MWG::RegionInfo is the ExifTool name for the XMP face regions, and when these are modified, I wonder by what.
QuoteFollowing a Force Update of the Version File:With"forced update" you mean you used Shift+Ctrl+F5 and forced IMatch to wipe out all metadata for the version in the database and then re-import what's in the file?
This breaks metadata propagated from the master in the database. To set things straight afterwards you need to manually propagate from the master to the "forced update" version manually.
Does the version in your case contain XMP face regions? Is the import of XMP face regions enabled in E > P > Metadata 2 (default). In that case IMatch will re-import the face regions from the XMP in version during the forced update and maybe this does not update the previously wiped face arrangement data?
I tried that here and the face arrangement data was still correct. Even removing a file from the database and adding it again (XMP face region import enabled) restored the correct face annotation info.
When you slightly move a face annotation in the version, does the variable correct itself?
Since thew master (!) metadata changed when you forced an update of the version, it seems that there are some issues with your file relations - e.g. the master sometimes becoming the version?
I don't see how face regions in a master can change when you perform a forced update on a version.