SUMMARY When viewing face thumbnails from Fujifilm RAF files in Digikam in the People tab, the thumbnails are not of people's faces. There seem to be two versions of the issue I am seeing, one where it picks a similarly sized spot elsewhere in the frame, and one where it instead shows the full image. Both are demonstrated in the linked screenshot. https://www.flickr.com/photos/193282201@N06/shares/3X6a13 With a fresh install on Fedora KDE, it appears to be triggered by enabling “Read from sidecar files” while “Write to XMP sidecar for read-only item only” is enabled in Metadata->Sidecars, even when writing facetags is not enabled in Metadata->Behavior STEPS TO REPRODUCE 1. Enable “Write to XMP sidecar for read-only item only” in Metadata->Sidecars 2. Enable “Read from sidecar files” in Metadata->Sidecars 3. Scan collection for faces - Detect faces 4. Scan collection for faces - Recognize faces 5. View the thumbnail of a newly scanned image OBSERVED RESULT Thumbnails of the whole image or of a part of the image other than the person's face. EXPECTED RESULT Thumbnails of the person's face. SOFTWARE/OS VERSIONS Windows: 10 21H1 macOS: Not tested Linux/KDE Plasma: KDE Fedora Workstation 34 fresh install (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
For clarity, the tags are on the proper locations. Only the thumbnails are wrong.
Additionally, seems like it may be specific to Fujifilm's RAW files. Issue does not appear in testing with Canon CR2 files.
I had already written to you that I cannot reproduce it. Please provide a RAW file that shows the problem. Maik
(In reply to Maik Qualmann from comment #3) > I had already written to you that I cannot reproduce it. Please provide a > RAW file that shows the problem. > > Maik Hi Maik, I've tried replying to you multiple times over Nabble and direct email on the mailing list over the past couple months, but my comments have not been showing up. The below link is an appropriately licensed (Creative Commons 0) RAW sourced from https://raw.pixls.us/ which demonstrates the issue on both machines on digikam 7.3.0 with a Fujifilm X-T10. https://raw.pixls.us/getfile.php/1192/nice/Fujifilm%20-%20X-T10%20-%2014bit%20uncompressed%20(3:2).RAF https://flic.kr/p/2m7Xxg1 Additionally, the following link is a sample RAW file from DPReview that demonstrates the issue with an X-T2 https://www.dpreview.com/sample-galleries/3430551079/fujifilm-x-t2-samples-gallery/2217667956 https://flic.kr/p/2m7UtzZ Additionally, the following link is a sample RAW file from https://www.photographyblog.com/previews/fujifilm_x_t3_photos that demonstrates the issue with an X-T3 https://img.photographyblog.com/reviews/fujifilm_x_t3/photos/fujifilm_x_t3_86.raf https://flic.kr/p/2m7PPS6
(In reply to Maik Qualmann from comment #3) > I had already written to you that I cannot reproduce it. Please provide a > RAW file that shows the problem. > > Maik Out of curiosity, do you still have a link to the Fuji RAFs that are failing to reproduce the issue? It would be interesting to test if the same result appears with those ones on these machines and OSes.
How you automatically found faces in the first two sample examples is a mystery to me. Neither with YoloV3 nor with changed sensitivity settings, I can find the faces here. And yes, my digiKam is still okay. In the third example, the face is naturally found without any problems. No problem occurred. What I noticed about your screenshot is that the entries for Unconfirmed, Unknown and Ignored are no longer available. If you have deleted it (which is prevented with current digiKam versions) your database is no longer in a clean state. Maik
Decided to test again on another machine with a fresh install of Linux with no modifications beyond what is listed below (including not enabling “add information to files” during install). It appears I missed a critical step in the original instructions: tagging the face. Steps are as follows: 1. Install Kubuntu 21.04 on an x86-64 machine 2. Install digikam (7.1.0) via Discover or apt in default config 3. Enable “Write to XMP sidecar for read-only item only” in Metadata->Sidecars 4. Enable “Read from sidecar files” in Metadata→Sidecars 5. Enable “Image Tags” in Metadata→Behavior→Write This Information to the Metadata 6. Download https://img.photographyblog.com/reviews/fujifilm_x_t3/photos/fujifilm_x_t3_86.raf 7. Scan collection for faces - Detect faces / manually select face area 8. Scan collection for faces - Recognize faces / manually enter name tag 9. Accept face match / apply a tag 10. View the thumbnail of the newly tagged image Interestingly, disabling “Update file modification timestamp when files are modified” in Metadata→Behavior→Reading and Writing Metadata seems to also stop the bug from appearing with new files, but does not fix previously tagged files. (In reply to Maik Qualmann from comment #6) > How you automatically found faces in the first two sample examples is a > mystery to me. Neither with YoloV3 nor with changed sensitivity settings, I > can find the faces here. And yes, my digiKam is still okay. The bug is reproducible with manual face tags (was going to use the following image for #1 originally and just manually tag a square: https://raw.pixls.us/getfile.php/865/nice/Fujifilm%20-%20X-T2%20-%2014bit%20compressed%20(3:2).RAF ). > In the third example, the face is naturally found without any problems. > No problem occurred. In the third sample (Sample Person for Testing #1), the thumbnail is offset from where the facetag is, as per the screenshot. Both the jpg and RAF facetags are in the same spot, but the thumbnails are not. > What I noticed about your screenshot is that the entries for Unconfirmed, > Unknown and Ignored are no longer available. digiKam has a search function. https://flic.kr/p/2m7WLdP > If you have deleted it (which is prevented with current digiKam versions) > your database is no longer in a clean state. > > Maik This was tested with a fresh install of Fedora 34 Workstation KDE with a fresh install of digiKam.
I cannot reproduce your problem here with a digiKam-7.3.0 version. You seem to be using an older version of Fedora. Your screenshot definitely shows a broken people tree, with no unconfirmed, unknown and ignored tag entries. Maik
Another thing, they write under (1.) that Kubuntu should be installed. At the end they write that Fedora 34 was used. What exactly? When we talk about *buntu, is it even a native digiKam version or a Snap or Flatpak package? Since we just had the problem and there are probably no current native digiKam versions for *buntu, only snap packages with sandbox will be available. Problems are inevitable, as digiKam's rights to the file system are severely restricted. Maik
(In reply to Maik Qualmann from comment #8) > I cannot reproduce your problem here with a digiKam-7.3.0 version. You seem > to be using an older version of Fedora. This was tested with 7.1.0, 7.2.0, or 7.3.0 across multiple OSes, including being tested with the latest stable release of Fedora (34). I can switch to testing with the Fedora 35 development builds if you would like. >Your screenshot definitely shows a broken people tree, with no unconfirmed, unknown and ignored tag entries. > > Maik digiKam has a search function. https://flic.kr/p/2m7WLdP When the search function is used, the unconfirmed, unknown and ignored tag entries do not show up if they are not valid results for your search. https://flic.kr/p/2majxEG Also, as you stated, recent digiKam versions block you from deleting them, and this was tested with a fresh install on multiple OSes. (In reply to Maik Qualmann from comment #9) > Another thing, they write under (1.) that Kubuntu should be installed. At > the end they write that Fedora 34 was used. What exactly? Yes, the latest test was on a fresh install of Kubuntu. The original testing (that you were making an assumption about in that section that I was replying to) was with Fedora. I also tested with Windows. I think I might try openSuse or Arch next, but haven’t decided yet. >When we talk about *buntu, is it even a native digiKam version or a Snap or Flatpak package? On Kubuntu it was installed via apt (and via Discover) for testing. I believe that would be this one. https://packages.ubuntu.com/hirsute/digikam > Since we just had the problem I had an old computer lying around with 5.8 on it, so I decided to test there and can confirm that in (limited) testing the issue did not appear there. Interestingly, when upgrading that computer to 7.2, the thumbnail remained correct, however the facetag ended up being offset from actual. 5.8 Thumbnail: https://flic.kr/p/2mapcdF 5.8 Facetag: https://flic.kr/p/2marTNW 7.2 Thumbnail: https://flic.kr/p/2maodHp 7.2 JPG Facetag: https://flic.kr/p/2matrks 7.2 RAF Facetag: https://flic.kr/p/2matrkh > and there are probably no current native > digiKam versions for *buntu, only snap packages with sandbox will be > available. Problems are inevitable, as digiKam's rights to the file system > are severely restricted. > > Maik Per the above testing, this problem appears in Kubuntu, Fedora, and Windows on different machines. Are the Windows builds on the digiKam website using snaps? Even if it is snap related, wouldn’t that still be a bug?
>Are the Windows builds on the digiKam website using snaps? >Even if it is snap related, wouldn’t that still be a bug? SNAPS ??? Windows installer is cross compiled under Linux using MXE environment (MinGw based). https://mxe.cc/ Gilles Caulier
Ok, after a long time I can reproduce it. It is independent of the sidecar. Fuji RAF reports an incorrect pixel X / Y dimension in the Exif metadata. Only in the Makernotes is the correct RAW image size without having to decode the image. In my opinion, Fuji should correct this. I'll see if we can get the original RAW size without reading the Exif metadata at Fuji. Maik
(In reply to Maik Qualmann from comment #12) > Fuji RAF reports an incorrect pixel X / Y dimension in the Exif metadata. > Only in the Makernotes is the correct RAW image size without having to > decode the image. I believe the Fuji EXIF Pixel X/Y is based on the size of the embedded JPG preview (it looks like all the information categorized under File in digiKam's ExifTool output relates to the JPG preview for Fuji). Looking at the ExifTool output in digiKam under RAF, I believe RawImageFullHeight, RawImageFullWidth, RawImageFullSize, and RawImageCroppedSize would have the RAW size (in addition to the RawImageHeight and RawImageWidth you mentioned in MakerNotes).
There is this older bug report for Exiv2, which has probably not been fixed yet. https://dev.exiv2.org/issues/1076 Maik
If I look at other camera makes, Nikon, Canon, Sony then Pixel X/Y Dimension contains the raw image size. Maik
Git commit a2b1ddc4d9d5c12736acdedfc5a36a9e3b139456 by Maik Qualmann. Committed on 10/07/2021 at 17:22. Pushed by mqualmann into branch 'master'. add workaround for Fujifilm to get a better original RAW size FIXED-IN: 7.3.0 M +19 -2 core/libs/threadimageio/thumb/thumbnailcreator_engine.cpp https://invent.kde.org/graphics/digikam/commit/a2b1ddc4d9d5c12736acdedfc5a36a9e3b139456
(In reply to Maik Qualmann from comment #15) > If I look at other camera makes, Nikon, Canon, Sony then Pixel X/Y Dimension > contains the raw image size. > > Maik To be clear, I'm not saying Fuji is right to do it that way. I'm just saying that it† appears to be what they are doing. († "it" being "using the embedded JPG image dimensions for their PixelXDimension and PixelYDimension fields") That being said, upon further investigation I think Fuji's handling may actually be consistent with Canon's handling. The CR2 files I have here pull the size of the embedded JPG preview rather than the RAW size for their PixelXDimension and PixelYDimension (or rather ExifImageWidth and ExifImageHeight by ExifTool’s naming). The difference is that Canon’s embedded JPG preview is the same as the slightly shrunken RAW Cropped Size (or “CroppedImageHeight” in Canon’s case), rather than using a substantially reduced size embed like Fuji does. So, I downloaded some Nikon, Sony, Pentax, Panasonic, Olympus, Sigma, Hasselblad, and Phase One RAW files to see if it was consistent. Findings are as follows: Fuji: Uses embedded JPG size. Embedded JPG is shrunken in size (1920x1080). Canon 80D: Uses embedded JPG size. Embedded JPG is slightly shrunken in size (equivalent to the cropped RAW size). Nikon Z6 II: Field left empty. digiKam Image Length and Image Width uses 120x160 on the image I was testing with, and lists the RAW image size under SubImage2. Sony A7C: Uses cropped RAW size. Embedded JPG is (1616x1080). Pentax K-1 II: Field left empty. digiKam Image Length and Image Width uses 120x160 on the image I was testing with, and splits the RAW image size and embedded TIF image size into SubImage1 and SubImage2 respectively. Panasonic DC-S5 and DC-GH5 II: Uses embedded JPG size. Embedded JPG is shrunken in size (1920x1280 and 1920x1440 respectively). Olympus M10 IV: Field left empty. digiKam pulls ImageHeight and ImageWidth which are the uncropped RAW size. Embedded jpg is 3200x2400. Sigma fp L: Uses embedded JPG size. Embedded JPG is slightly shrunken in size (equivalent to the cropped RAW size). Hasselblad X1D: Field left empty. digiKam Image Length and Image Width uses embedded TIF size. Embedded TIF shrunken in size (1440x1080). Phase One IQ4 150MP: Equivalent to cropped RAW size (but looks like digiKam can’t read it yet). Not seeing the same issue in testing for the other ones however (with the possible exception of the DC-GH5 II, for which so far it is failing to generate face thumbnails for the samples I have downloaded). Looking at the spec, I think we may not be able to rely on PixelXDimension and PixelYDimension existing (columns MV and MW when exported to CSV via ExifTool, which renames them as ExifImageHeight and ExifImageWidth), as the spec indicates that they should be omitted for uncompressed RAWs. The EXIF 2.32 spec indicates on page 30 that the ImageWidth and ImageLength tags should be used instead (columns UX and UM when exported to CSV via ExifTool). All of the above mentioned files list their cropped or uncropped raw sizes in those columns, except for Fuji (which instead lists them in RawImageFullWidth, RawImageFullHeight, RawImageWidth, and RawImageHeight which can be found in columns AIF, AID, AII, and AIG). They also all list their cropped or uncropped raw sizes in ImageSize, including Fuji (column UR when exported to CSV via ExifTool).
We introduced ExifTool in digiKam-7.3.0 and are already using it for the Makernotes for DNG images. We can also use it in the future to get the correct RAW image size. But we can also generally remove the use of the preview image for the face rectangle. We are currently doing this for speed reasons. In the case of RAW images whose preview image is significantly smaller than the original RAW, the preview image is also discarded. Maik
(In reply to Maik Qualmann from comment #14) > There is this older bug report for Exiv2, which has probably not been fixed > yet. > > https://dev.exiv2.org/issues/1076 > > Maik Looks like it may have been addressed after moving to github in issue #755 and pull #810 https://github.com/Exiv2/exiv2/issues/755 https://github.com/Exiv2/exiv2/pull/810 (In reply to Maik Qualmann from comment #16) > Git commit a2b1ddc4d9d5c12736acdedfc5a36a9e3b139456 by Maik Qualmann. > Committed on 10/07/2021 at 17:22. > Pushed by mqualmann into branch 'master'. > > add workaround for Fujifilm to get a better original RAW size Fantastic. Looking forward to testing it.