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?
Created attachment 126313 [details] screenshot2 second screenshot
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
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?
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°.
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
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?
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
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
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
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.
Created attachment 126326 [details] first the screensho after import of the pic i guess the rectangle was transformed by 90 or 270°
Created attachment 126327 [details] original picture before import
is there any "other application" that can read also that face rectangle? That would help to answer this question too.
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