Bug 511159

Summary: Rejecting or ignoring faces writes to image metadata, causing unwanted file modifications
Product: [Applications] digikam Reporter: MarcP <iwannaberich>
Component: Faces-WorkflowAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: minor CC: iwannaberich, metzpinguin
Priority: NOR    
Version First Reported In: 8.8.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: https://invent.kde.org/graphics/digikam/-/commit/66cdcb7867a34931feb94f0a3fa5a1728c262a0e Version Fixed/Implemented In: 8.9.0
Sentry Crash Report:

Description MarcP 2025-10-26 14:28:04 UTC 
SUMMARY
Rejecting or ignoring detected faces in Digikam updates the original image files’ metadata instead of only changing the database, causing unnecessary file modifications.

STEPS TO REPRODUCE
1. Run face detection on a set of images.
2. In the People view, reject or mark some detected faces as "ignored."
3. Observe that the image file's last modified timestamp changes.

OBSERVED RESULT
Each time a face is rejected or ignored, Digikam modifies the image file itself (metadata changes). This happens even though no new face tags or user-visible metadata should be added or removed.

EXPECTED RESULT
Rejecting or ignoring a face should only affect Digikam’s internal database. The original image files should remain untouched, preserving their timestamps and avoiding unnecessary metadata writes.

SOFTWARE/OS VERSIONS
Windows: Windows 11 25H2
Digikam 8.8.0 Stable

ADDITIONAL INFORMATION
This behavior causes significant overhead when images are stored on a NAS or network drive, since marking many faces as ignored triggers many metadata write operations over the network.

The modification date changing confirms that Digikam is writing to the files even when it shouldn’t.
Ideally, “ignored” or “rejected” status should be stored exclusively in Digikam’s internal database.

I believe this behavior already happened in the past, was fixed, and reappeared sometime around the 8.7.0 release.
Comment 1 Maik Qualmann 2025-10-26 14:56:59 UTC 
No, no metadata write operation is taking place. I can't reproduce it.
It's also easy to test with Lazy Sync, as you can see right away in the status bar whether a job is pending.

If a confirmed face is ignored or rejected, a write operation will of course take place.

Maik
Comment 2 Maik Qualmann 2025-10-26 15:18:01 UTC 
Ok, after trying for a while, I can reproduce something, it seems a flag is not being deleted.

Maik
Comment 3 Maik Qualmann 2025-10-26 15:43:12 UTC 
Git commit 66cdcb7867a34931feb94f0a3fa5a1728c262a0e by Maik Qualmann.
Committed on 26/10/2025 at 15:42.
Pushed by mqualmann into branch 'master'.

not use FaceUtils() across multiple jobs
FIXED-IN: 8.9.0

M  +1    -1    NEWS
M  +4    -2    core/utilities/facemanagement/pipelines/edit/facepipelineedit.cpp
M  +0    -2    core/utilities/facemanagement/pipelines/edit/facepipelineedit.h

https://invent.kde.org/graphics/digikam/-/commit/66cdcb7867a34931feb94f0a3fa5a1728c262a0e
Comment 4 MarcP 2025-10-26 16:31:10 UTC 
Well, I don't think I explained myself very well. No actual metadata changes are saved in the picture, but the picture file is "touched" and the last modification time changed to the current time. For instance, I see how any face suggestion that is rejected triggers Nextcloud to update that picture and send it over the network, and for my daily scheduled backup to backup that file again as if something had changed, even if the file itself remains unchanged and it's only the last modification time.

Thanks for looking into this!