I noticed that when I export all the person records to JSON (Exporting People (https://www.photools.com/help/imatch/#people.htm#a_the_people_view?dl=h-95)) and import the same, unchanged, file to the database (Importing People (https://www.photools.com/help/imatch/#people.htm#a_the_people_view?dl=h-96)) then all the faces for the persons disappear in People View. That's probably by design as it is clearly written in the help file that the import process is for _new_ databases.
It would be great however if one could export all the person records, do some editing of person properties in the JSON file, and import the file again without loosing all the face assignments.
Is there any chance for a process like this?
This import/export feature is intended to see new databases. The persons some in new, unlinked to any face. The file format does not include binary face fingerprints, links to files and files or cover images.
The cover files automatically created when the person is assigned to the first face. Or when the user sets the cover image manually.
You did not explain what your process does that you cannot do in the Person Editor.
OK, I will try to explain what my problem / need is.
In my collection of family photographs I have photos of probably well over 1200-1400 people.
It is not necessarily family or close friends - many of these people have passed through my or my family's life (friends from work, colleagues from work, their parents, etc.) and at some stage appeared in photos, perhaps received photo prints, etc. Since I once marked the photos with information about these people and I already have this information in the database, I don't want to delete it. In view of such a large number of these people, it is important for me to be able to organize these people into certain groups/categories/contexts. To do this, I need the following items:
- information which person has been assigned which categories, keywords, gender and other properties available in the Person Editor
- information about which people have already been "organized" by me (I assigned them categories, keywords and other properties) and which entries remain to be reviewed / corrected
- the ability to efficiently introduce changes (assigning categories, keywords, etc.) to individual people, in particular correcting many entries at the same time.
It would probably be ideal if People View would be able to display records for many people at the same time in the form of a grid view, sorted and filtered by individual columns (as in MS Excel), with some possibility of editing many entries at the same time. If this is not possible, I can implement points 1 and 2 by exporting entries to JSON and viewing / processing this file. However, I miss the point 3: the ability to smoothly import changed properties back to the database. I would imagine that if there is an existing person's id in the imported JSON file, then the properties for that person (keywords, categories, group, etc.) would be entered into the database from that file.
This sounds like a rather special/custom workflow.
I doubt many users will ever have this large number of persons to manage. When I recall telemetry correctly, the average number of persons is about 100...
Writing a specialized batch person editor with analysis functions etc. you outline is possible.
But it will take probably several weeks to design, implement, test and document. And then to maintain forever.
Which means - time and money.
Upgrading the simple export/import format to include file and face links would also be doable. But this could of course work only for a specific database and would thus negate the reason for having the import/export format.
We could possible introduce additional options or a more detailed layout for the People View, to show categories and keywords for the person. If there is sufficient demand...
Feel free to add a feature request so we can see how many users have the same issues.
I realize that writing an advanced editor for person records is a big undertaking so if there is not many people interested I absolutely do not ask for it. Although it must be said that as new, important functionalities (persons, events) are added, IMatch not only manages information about photos, but also about people and events - both people and events become separate resources that will need to be managed in future I think.
As for data import, I wouldn't want any advanced functionality - I would only be able to fill basic information (available as fields in the Person Editor) with information from the JSON file. Currently, the import function replaces the entire Person entry with the data from the file (if the ID matches), thus losing information about associated faces. It would be nice if there was an import function that would work as follows:
- if JSON contains a person with an existing id, then the entry of the person is supplemented with fields from the JSON file (only those fields that are available in the Person Editor, so that the user does not accidentally destroy the data like face assignments whose consistency is ensured by IMatch)
- if the JSON contains a person with no id, then a new entry is created.
I will add a feature request for a such function.
Quote from: Mario on January 25, 2022, 02:48:31 PM
I doubt many users will ever have this large number of persons to manage. When I recall telemetry correctly, the average number of persons is about 100...
What exactly do you mean by that number "100"? 100 persons in the "People" view? I have zero there, but just because I have >1000 persons in my Categories tree under "Personen" (german) and I'm still not sure if I'm able to handle this when running Face detection/recognition. Therefore I haven't started using Face detection/recognition...
I meant real "Persons" created in the People View.
The average is 119 persons managed in the People View, and the maximum number of persons is 10,607 ::)
IMatch has no idea what your "Personen" category means ;)
Quote from: axel.hennig on January 25, 2022, 06:04:55 PM
What exactly do you mean by that number "100"? 100 persons in the "People" view? I have zero there, but just because I have >1000 persons in my Categories tree under "Personen" (german) and I'm still not sure if I'm able to handle this when running Face detection/recognition. Therefore I haven't started using Face detection/recognition...
Recently introduced feature of linking persons to files is a great start to migrate from category or keywords based persons management to "real" management using the People View. You can select all photos in a given "person" category and link them to a person visible in the People View and then slowly convert the "linked" annotations to the full face tags. There are several drawbacks though:
- You have to create the persons in the People View first. If you have nothing there you're lucky because you can export your person categories to a text file, convert it somehow to a JSON file and import persons to the People View - once they are there you can use these persons to link files to them. I had already invested a lot of time into Face Recognition so when I wanted to link all remaining still-not-face-tagged photos to persons I had to create several hundred persons manually.
- Once you decide to manage people in the People View there is no good way to categorize persons and use this categorization in the Category View. The problem is: when you are managing persons using categories it is normal that you create category tree and assign photos to the "leaf" categories corresponding to specific persons, like:
family A
-person AA
-person AB
family B
-person BB
-person BC
and then, browsing Category Tree, you can clearly see who is in which category etc.
It would seem that when managing people using the People View and Person Editor it should be enough to assign categories to people on the "family A" and "family B" level and then using data driven categories you would be able to recreate the category tree in the Category View to view persons by category as before. Unfortunately, this is not the case. If we confine ourselves to assigning categories at the "family A" and "family B" levels in the Person Editor then trying to build a data driven category showing photos of all people from "family A" we will see under "family A" also all people from "family B" who were in the photos with people from "family A". This is because there is no way to tell the data driven category that it should build a category level grouping only from persons that have that very category assigned in the Person Editor - and so the data driven category will group photos by every person in the photos.
So, unless something is changed if you would like to browse people in Category View using precise category assignment you would have to maintain separate category for every person and assign that category to a person in a Person Editor - and that's a lot of work...
That said after much hesitation I recently decided to make the switch to fully utilize the People View. I am starting small family archive project and decided that the ability to better describe persons using data like description, date of birth and death etc. is worth the effort. And my "person" category tree was a mess anyway. ;)
Quote from: Pawel on January 25, 2022, 09:14:05 PM
This is because there is no way to tell the data driven category that it should build a category level grouping only from persons that have that very category assigned in the Person Editor - and so the data driven category will group photos by every person in the photos.
Not completely sure, if this is really true. Let's assume your two families (just as an example) have as last names
Miller and
Powell and there exists the following persons within each family:
Miller, John
Miller, Carol
Miller, Silvia
Powell, Bernd
Powell, Deborah
Powell, Anja
Let's assume you've got these names (exactly as I wrote them) in the People view. I think it would be possible to create a data-driven category to group them (1st level) by family name and then (2nd level) by first name, using the following setting:
- Value splitting (enabled) separators: ~;
- Hierarchy (enabled) separators: ,
That's a neat idea and it will work indeed as long as the complete "category tree" is encoded within a field in a person record. I'd rather assign categories to persons because category assignments are more flexible (I can rename a category and still have the assignment working without having to manually edit all the person records involved, I can assign several categories to a person etc.) however as a workaround or temporary solution your idea is definitely something to consider! :)
Just a question out of curiousity:
Do you have a json grid(!) editor (not only viewer) recommendation based on your experience?
It might come in handy for updating the data before importing it.
There are quite a few JSON editors.. to be honest - I often just use any of the free online editors but since I'm coding within Visual Studio quite often - I use an extension within the editor too. Enjoy!