https://bugs.kde.org/show_bug.cgi?id=526793
Bug ID: 526793
Summary: Digikam face tagging bug
Classification: Applications
Product: digikam
Version First 9.1.0
Reported In:
Platform: macOS (DMG)
OS: macOS
Status: REPORTED
Severity: normal
Priority: NOR
Component: Faces-Workflow
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Greetings the below entry was produced using Claude for troubleshooting and
then provided the below summary
## Summary
Manually drawn face regions do not persist: the box is visible while dragging,
but disappears immediately on mouse-release, with no name-entry prompt, no
error dialog, and no output in a Terminal-launched session. This has been
present since relocating the database folder using the official migration tool,
and persists after fully repairing an unrelated, separately-caused database
corruption issue. All underlying face/tag data has been verified intact via
direct SQL queries.
## Environment
- digiKam version: 9.1.0
- OS: macOS (Apple Silicon MacBook Pro)
- Database backend: SQLite (QSQLITE)
- Database location: relocated from the collection root (`~/Documents/Photos/`)
into a dedicated subfolder (`~/Documents/Photos/~digikam/Database/`) using
digiKam's built-in **Database Migration Tool**
## Related issue: People view shows no faces despite intact data
Separately from (but possibly connected to) the drawing issue above: the
**People** sidebar view shows completely empty — no names, no face thumbnails —
despite all underlying data being verified present and well-formed via direct
SQL queries (see "Confirmed intact" section below). This has persisted through
every maintenance/rebuild action tried. Regular **Tags** browsing (non-People
sidebar) works correctly and shows all tagged photos for a given person,
confirming the tag-to-image linkage itself is sound — it's specifically the
People view's own rendering/indexing that's not reflecting the data.
## Steps to Reproduce
1. Open any photo containing one or more faces in the main view (Preview mode).
2. Manually draw a face region box (Add a Face Tag).
3. Release the mouse button.
**Expected:** Box persists, a name-entry field appears for assignment.
**Actual:** Box disappears immediately on release. No name field appears. No
error or dialog is shown.
## What's been ruled out
Before raising this, I worked through the following to isolate the cause (a
separate, now-resolved database corruption issue muddied the timeline
initially, so I want to be clear about what was and wasn't related):
**Unrelated, already-fixed issue:** An interrupted "Scan for new items" left
`digikam4.db` with genuine SQLite corruption (`PRAGMA integrity_check` returned
multiple "out of order" / "2nd reference to page" errors across several
B-trees). This was resolved using `.recover`, and verified clean
(`integrity_check` → `ok`) after rebuilding. I also discovered the migration
tool had left a stale `recognition.db` (2.8 MB, pre-corruption) behind in the
old collection-root location, separate from the near-empty 32 KB one in the new
`~digikam/Database/` path — swapping the correct file back in restored face
*matching* functionality, but **not** manual face *drawing*.
**Confirmed intact via direct SQLite queries (not just the UI):**
- `PRAGMA integrity_check` → `ok` on `digikam4.db`, `recognition.db`
- `ImageTagProperties` — 6,280 `tagRegion` rows total; 6,054 correctly resolve
via JOIN to `Images.id` (226 orphaned, pre-dating this issue and not the
current blocker)
- Sample `tagRegion` values contain well-formed rect geometry (e.g. `<rect
x="627" y="412" width="765" height="539"/>`)
- `TagProperties` — 24 tags correctly flagged `property='person'`
- `Tags` — People root tag intact (`id=4`), 35 person-tags correctly nested
under `pid=4`
- Tag `icon` / `iconkde` references present and well-formed for sampled rows
- Regular **Tags** browsing (non-People sidebar) correctly displays all photos
for a given person-tag — confirming the underlying tag-to-image linkage works
**Tried and did not resolve the issue:**
- Tools → Maintenance → Face Engine Management → "Rebuild all training data"
(completed in ~2 seconds — suspiciously fast, but unrelated once the real
`recognition.db` was restored and this still didn't fix drawing)
- Tools → Maintenance → Rebuild Thumbnails
- Swapping in a larger, pre-corruption `thumbnails-digikam.db` found left
behind in the old collection-root location
- Full app restart, full macOS restart
- Confirmed write permissions on `digikam4.db` are correct (`rw-r--r--`, owned
by the active user)
- Confirmed no relevant stale path references in
`~/Library/Preferences/digikamrc` or `digikam_systemrc` (Database paths and
`facesEnginePath` all point to current, correct locations)
- Checked `~/Library/Application Support/CrashReporter` for a digiKam crash log
— one exists but is an empty stub (date only, no stack trace)
## Additional observation
At launch (via Terminal, `./digikam`), the following repeat in the console
output and may be related to a broader rendering issue:
```
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setCompositionMode: Painter not active
QPainter::end: Painter not active, aborted
```
These also did not correlate with a specific user action in my testing, so may
be incidental, but are included in case they're relevant to the face-box
rendering/commit path.
## Why I believe this is migration-related
Face box drawing has not worked at any point **since** relocating the database
via the migration tool — including before the unrelated corruption occurred.
This suggests a possible stale reference or state specific to the face-tagging
UI's save/commit path that isn't covered by the Database Migration Tool's
handling of the main collection path, separate from the (correctly updated)
paths in Settings → Configure digiKam → Database.
Happy to provide any further diagnostics, database excerpts, or test additional
scenarios on request.
--
You are receiving this mail because:
You are watching all bug changes.
