Version: 2.3.0 (using KDE 4.7.2) OS: MS Windows Crop a picture with four face tags attached. Saved as a new version. The face tags still exists but the representing rectangles do not match the faces. Reproducible: Always Steps to Reproduce: Take a picture with face tags attach Start image editor Perform aspect ratio crop Save image a new version View the new file Actual Results: The face tag exists but the rectangle does not match the face anymore Expected Results: The face tag rectangle matches the face OS: WindowsNT (i686) release Windows 7 64bit German Compiler: cl.exe
It's a known issue. Will be fixed when metadatagroup's specifications will be fully implemented. So far only rotation adjust face tags.
Veaceslav, Any progress on this file ? Gilles Caulier
No, still have a lot of other reports on my list...
Veaceslav, It still valid with current implementation from git/master ? Gilles
If nobody worked on it, then probably is still valid.. :)
Similar thing happens on linux with RAW photos which are vertical and presented this way because of the exif information. The thumbnails of automatically recognized faces are shown correctly, but when you show them on the photo they're marked in wrong positions and their aspect ratios are wrong. Also manually tagging faces on vertical photos (at least in RAW format) tends to create misaligned thumbnails of faces, even though they show correctly on the photos in question.
digiKam 4.11.0 Windows installer is available for download : http://download.kde.org/stable/digikam/digiKam-installer-4.11.0-win32.exe.mirrorlist
I am witnessing a similar issue on Linux (Ubuntu LTS 14.04) and Digikam 4.14 (from PPA). A RAW (RW2 Panasonic) file which has been rotated into portrait mode during import has two face rectangles. When I rotate this image using the buttons in the previewer, the face rectangles are (once) moved to a different location on the image - and after this first incorrect displacement they stick to the location on the image even with further rotations. Can you please double check whether this issue exists in 5.x? Thanks!
*** Bug 391477 has been marked as a duplicate of this bug. ***
*** Bug 388169 has been marked as a duplicate of this bug. ***
Given this is 7 years old, isn't the interim answer to remove all the face regions after crop? I'd rather have no face regions than incorrect face regions.
(In reply to hardy.public from comment #11) > Given this is 7 years old, isn't the interim answer to remove all the face > regions after crop? I'd rather have no face regions than incorrect face > regions. As long as the face tags would remain assigned to that image (i.e. only the regions would be invalidated/deleted), that might be a reasonable interim solution.
7.0.0-beta1 is out with new Face Recognition algorithm based on Deep Learning/Neural Network API from OpenCV https://download.kde.org/unstable/digikam/ Please test and give us a feedback Thanks in advance Gilles Caulier
Problem still present. Cropping does not remove face regions which are wholly or partially outside the new image after crop. Meaningless ghost face regions are still displayed in Preview.
Created attachment 124743 [details] Preview Before Crop Of Test4 Test4, 5 and 6 face regions correctly displayed.
Created attachment 124744 [details] Preview After Crop of Test 4. Test4 face region not displayed correctly. Test 5 and 6 should have the regions deleted in my opinion.
*** Bug 428021 has been marked as a duplicate of this bug. ***
Added bug 429219 which is related to this issue. Essentially the MWG Guidelines provide a way to identify a photo containing mismatched face regions. When a crop, resize or rotation operation occurs the values, if correct to begin with, must be updated along with the existing face regions.
*** Bug 437353 has been marked as a duplicate of this bug. ***
*** Bug 460047 has been marked as a duplicate of this bug. ***
Maik, I remember that some works have be done around this topic in the past, but i don't remember when exactly... Gilles
For some tools yes, flip, rotate. Not yet for the crop or resize tool. Maik
I signed up to this bug tracker to report this issue. I am quite stunned to find that it was first reported in 2011. This is a very common part of my workflow, having tagged hundreds of thousands of images and now doing some edits. Wish I'd done it the other way round now.
In 8.3.0 pre-release, the cropped image now doesn't contain any face regions which is good as an interim solution. Ideally though, I think a cropped image should have its face regions recalculated where possible. Perhaps this should be a separate feature request?