Bug 418061 - Position of faces copied when rotating an image
Summary: Position of faces copied when rotating an image
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Maintenance-Faces (show other bugs)
Version: 7.0.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-22 22:02 UTC by Rico
Modified: 2020-02-23 08:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Attachments
screenshot1 (440.92 KB, image/png)
2020-02-22 22:02 UTC, Rico
Details
screenshot2 (440.92 KB, image/png)
2020-02-22 22:03 UTC, Rico
Details
original pic2 (1.83 MB, image/jpeg)
2020-02-22 22:29 UTC, Rico
Details
first the screensho after import of the pic (312.24 KB, image/png)
2020-02-23 08:10 UTC, Rico
Details
original picture before import (654.71 KB, image/jpeg)
2020-02-23 08:12 UTC, Rico
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rico 2020-02-22 22:02:22 UTC
Created attachment 126312 [details]
screenshot1

SUMMARY
Face areas copied when rotating an image

STEPS TO REPRODUCE
1. Open a picture
2. Set in preview an face tag (screenshot 1)
3. press 4 times CTRL+SHIFT RIGHT to rotate picture (screenshot 2) 

OBSERVED RESULT
tags are copied 3 or 4 times


EXPECTED RESULT
should not be copied

SOFTWARE/OS VERSIONS

I used the latest appimage of digikam (beta3 from 20200220) on opsensuse thumbleweed

ADDITIONAL INFORMATION
I'm useing digikam sinces some years and discover from release to release problems with the position of tagged faces. It is hard to create a reproducable example because I don't know whether it was an error with a earlier version (when the tag was created) or this one (when the tag was read).

I'am pretty sure that there is/was an similar error with the postition face areas in combination with the oriantation of the picture.
All the positions from my older, tagged pictures (2017/2018/2019); taken from my mobile phone in potrait mode seems to rotated by 90° with that release. Maybe in combination of rotating meta data? Tags are not copied, seems to be moved by 90°
Do you know something that goes into that direction in the past?
Comment 1 Rico 2020-02-22 22:03:05 UTC
Created attachment 126313 [details]
screenshot2

second screenshot
Comment 2 Maik Qualmann 2020-02-22 22:10:58 UTC
I cannot reproduce the problem. Which metadata settings do you use exactly? Metadata is written in the image? Sidecars?

Yes, we have changed the behavior of the face rectangles in relation to the rotation and have now adapted them to other programs. This step was necessary to meet the standard. DigiKam used to save the face rectangles to the aligned image, now to the non-aligned image.

Maik
Comment 3 Rico 2020-02-22 22:29:45 UTC
Created attachment 126314 [details]
original pic2

Hi Maik,
thanks for the fast response. 
I attached now the original picture, not the screenshot (the tags should be saved 4 times in the pic). Maybe it helps to answer your question. If not let me know where I can get the info you need.

Regarding the older pics:
It is a good thing to align with standards. Maybe one day face tags can be interpreted by other apps too.
Do you think it is stable now and I can fix the position final?
Comment 4 Rico 2020-02-22 22:37:14 UTC
metadata was written in preview of the picture, directly in the image, one time by drwing the rectangle, entering top and confirmed pushbutton with ok.
Afterwards (directly I rotated the image in the preview. Each time, the tag was copied on time. The position was shifted also somehow by 90°.
Comment 5 Maik Qualmann 2020-02-22 22:39:06 UTC
In principle, the problem can only occur if the writing of facial rectangles in images is activated and a facial rectangle is in the metadata of the image. If the image is now read-only, the existing face rectangle is added again. It is also good to see on your image as the face rectangles are different (almost square / rectangle). Image or folder must be read-only.

Maik
Comment 6 Rico 2020-02-22 23:45:20 UTC
Hi Maik,
I played now around for a while and confused now. I was not able to reproduce it 100% now. Onetime it happened directly on start up, often not. 

First thouhgt was also it happens in combination with the preview in dolphin, or when the folder is just open but later  it happened also with closed dolphin and worked somethimes with opened.

I think it is also file related. One time only for one file the tag was copied. For other it worked in the same session. 

I cannot say how to reproduce but somethimes it happens.
Could digikam lock somehow itself? I was wondering about the statusbar text " x fiels waiting for sync" (rough translated from german) .
Could that be something combined with the lazy sync option maybe in combination with writing directly in the file?
Comment 7 Maik Qualmann 2020-02-23 06:22:35 UTC
The cause is active lazy synchronization AND the activated option to re-read the images when changes are made. That will be interesting to fix.

Maik
Comment 8 Maik Qualmann 2020-02-23 06:40:56 UTC
Git commit 7305b39277502e9ad3d2422d7a109013dd666d5e by Maik Qualmann.
Committed on 23/02/2020 at 06:39.
Pushed by mqualmann into branch 'master'.

ignore lazy synchronization for transform actions
FIXED-IN: 7.0.0

M  +2    -1    NEWS
M  +1    -1    core/libs/fileactionmanager/fileworkeriface.cpp

https://invent.kde.org/kde/digikam/commit/7305b39277502e9ad3d2422d7a109013dd666d5e
Comment 9 Maik Qualmann 2020-02-23 06:46:39 UTC
One more word about the face rectangles. The face rectangles are still saved to the aligned image within the digiKam DB so that all old created face rectangles are retained. If you write all the metadata from the DB into the images using the maintenance tool, you should no longer have any problems re-read the metadata from the images.

Maik
Comment 10 Rico 2020-02-23 08:08:32 UTC
Hi Maik,
that was really fast! When there is a appdata build out, including that fix, i will retest.
Regarding the last point, do you have an idea when it was changed?
The face rectangles came not from db. I imported the files on a new installation. Infomration came from the file. I will attach a picture last change about 201810. ( I guess with a at that time latest stable on a unbuntu system) But I don't know whether I added at that time the face rectangle.

Maybe it help to find out, whether it was stored wrong or imported wrong.
Comment 11 Rico 2020-02-23 08:10:36 UTC
Created attachment 126326 [details]
first the screensho after import of the pic

i guess the rectangle was transformed by 90 or 270°
Comment 12 Rico 2020-02-23 08:12:18 UTC
Created attachment 126327 [details]
original picture before import
Comment 13 Rico 2020-02-23 08:16:57 UTC
is there any "other application" that can read also that face rectangle?
That would help to answer this question too.
Comment 14 Maik Qualmann 2020-02-23 08:46:42 UTC
If the facial rectangles were written into the images with a digiKam version prior to 7.0.0, then they will now be imported incorrectly if the images are only rotated according to the orientation flag. Images whose pixel data has been rotated will be correct. Unfortunately, but we have to make a cut here to be compatible with other programs in the future and to be the standard.

Maik