https://bugs.kde.org/show_bug.cgi?id=528456
Bug ID: 528456
Summary: Face boxes saved outside image boundaries, with
duplicate named and unknown regions
Classification: Applications
Product: digikam
Version First 9.1.0
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Faces-Workflow
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Title: Face regions saved outside image boundaries; duplicate named and unknown
regions in digiKam 9.1.0
Environment
- digiKam 9.1.0
- Windows 11
- SQLite database, WAL mode disabled
Summary
After weeks of identifying faces, I ran another recognition pass for about 30
remaining unknown faces. Unknown then contained hundreds of entries, including
photos I had already identified. Examining one photo revealed multiple named
and unnamed face boxes, including boxes outside the picture that were only
visible after zooming out.
The scan settings shown afterwards were Recognize faces only, 17 albums
selected, and Unknown as the only selected tag. Ignored and other tags were
deselected. I cannot establish whether the last scan created all the misplaced
boxes: I had noticed a few extra boxes previously but had not zoomed out to
inspect them fully.
Example
A single-person HEIC photo, reported as intact (not cropped or rotated),
contained two regions for the correct person, one for an incorrect person, and
blank regions. Its actual HEIC dimensions are 816 x 828, matching
ImageInformation in the database, orientation 1. Before manual cleanup, saved
named regions included:
- Correct person: <rect x="1709" y="609" width="81" height="98"/>
- Correct person: <rect x="1550" y="2126" width="126" height="158"/>
- Incorrect person: <rect x="1695" y="444" width="82" height="101"/>
These regions are wholly outside this image.
I removed stray boxes and moved a correctly named box onto the face. The moved
region persisted after navigating away and back. A subsequent database snapshot
contains the corrected region <rect x="314" y="130" width="221" height="238"/>,
but also a leftover zero-width region <rect x="816" y="609" width="0"
height="175"/> for the same person. Both have faceToTrain entries. The
corrected valid region is also present in the photo's embedded MWG and
Microsoft face metadata.
Scope of read-only inspection
Inspection was performed on separate database copies. In the initial backup,
160 named regions on 49 photos lay wholly beyond both possible image
orientations. In a later snapshot, including zero-width/height regions in the
check yielded 176 suspect named regions on 54 photos. These are different
criteria and snapshots, not evidence of 16 newly created boxes. Of those 176,
58 have another fully in-bounds named region for the same person and image, and
118 do not. An in-bounds region has not been visually verified as correct.
These checks miss misplaced regions that are still inside the image. SQLite
quick_check passed on the initial copy.
Other observations
Some identical region coordinates appear on differently sized files sharing a
base filename. This is only an observation; it does not establish the cause. I
sometimes edit pictures in Windows Photos while digiKam is open, but the
single-person example is reported as intact. Face Tags (including face areas)
writing is enabled; Rescan file when files are modified is disabled.
Expected result
Confirmed face assignments and positions should remain stable. Recognition-only
processing should not leave unusable face regions outside image boundaries.
Questions
1. Is this a known coordinate/metadata or face-region persistence issue?
2. What additional diagnostics would establish the cause?
3. Is there a supported way to repair invalid regions while preserving
confirmed identities, without resetting weeks of tagging work?
Exact reproduction steps are not yet known. I have preserved a database backup
and stopped further scans. No database reset or bulk cleanup has been
performed.
Related reports to check (not confirmed duplicates): KDE bugs 516934 (face
areas after DPI change), 524202 (repeated matches), and 519915 (scan selection
constraints, reportedly fixed in 9.1.0).
--
You are receiving this mail because:
You are watching all bug changes.
