[digikam] [Bug 399600] Inconsistent metadata in pictures and database when some albums are read-only
https://bugs.kde.org/show_bug.cgi?id=399600 --- Comment #13 from MarcP --- Hi, yes, I think this behavior has not changed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416213] People tags appear duplicated after having moved them in the tag tree, if the tag was already present at /People/
https://bugs.kde.org/show_bug.cgi?id=416213 --- Comment #19 from MarcP --- Hi. Yes. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416743] Face rectangle tool gets deselected if changes are being written to file
https://bugs.kde.org/show_bug.cgi?id=416743 --- Comment #11 from MarcP --- Yep, still happens. It depends on how long it takes for the system to finish saving changes to the image. If you start working on another face rectangle before it has finished saving changes, it will get deselected. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416071] Saved searches that include tags are altered after tags are reorganized
https://bugs.kde.org/show_bug.cgi?id=416071 --- Comment #9 from MarcP --- Hi, yes, merging tags still changes the tag ID and breaks any saved search that referred to it. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 420658] Tag location suggestion not visible if string is too long.
https://bugs.kde.org/show_bug.cgi?id=420658 --- Comment #13 from MarcP --- Hi. I can confirm this behavior is still present in today's 8.4.0 Qt6 appimage. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 --- Comment #9 from MarcP --- I just tested using exiftool to change the date, and I get the following error: "Error: Writing of MTS files is not yet supported". https://exiftool.org/commentary.html#AVCHD So I guess I'll have to use sidecars for MTS files then. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 --- Comment #8 from MarcP --- Another thing I noticed, is that even if that DateTimeOriginal date is in the exif info, I can´t edit it using the Edit Metadata tool. Not sure if it's related. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 --- Comment #7 from MarcP --- Hi Maik, I can confirm it's working perfectly now. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 --- Comment #6 from MarcP --- Great! I'll test it in a couple hours when I get home. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 --- Comment #2 from MarcP --- Here's the link to a sample MTS file I recorded earlier today: http://158.101.198.126:9011/share/Hd_I2d7r Let me know if the download doesn't work for you and I'll use a less exotic sharing method. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485981] "Open in File Manager" causes 100% CPU usage in process: kde-open5 file://
https://bugs.kde.org/show_bug.cgi?id=485981 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485981] New: "Open in File Manager" causes 100% CPU usage in process: kde-open5 file://
https://bugs.kde.org/show_bug.cgi?id=485981 Bug ID: 485981 Summary: "Open in File Manager" causes 100% CPU usage in process: kde-open5 file:// Classification: Applications Product: digikam Version: 8.4.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY I noticed that when I right click on a picture, and select Open in File Manager, instead of Dolphin showing the contents of the folder where the picture is located, nothing happens. Upon inspecting the running processes, I noticed that there's a stuck process that is using all the CPU: kde-open5 file:// I don´t know when it started. I'm currently using the digiKam-8.4.0-20240421T104710-Qt6-x86-64.appimage, but it used to work in previous versions. I thought it might have something to do with the folder path having spaces or special characters, but it doesn't seem to matter. Also, running that kde-open5 command directly on a bash console seems to open Dolphin to that folder. STEPS TO REPRODUCE 1. Right click on a picture. Open in File Manager. OBSERVED RESULT Nothing happens EXPECTED RESULT File browser should open at that location. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS digiKam-8.4.0-20240421T104710-Qt6-x86-64.appimage (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485973] New: Metadata (DateTimeOriginal) not read from MTS video files
https://bugs.kde.org/show_bug.cgi?id=485973 Bug ID: 485973 Summary: Metadata (DateTimeOriginal) not read from MTS video files Classification: Applications Product: digikam Version: 8.4.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Metadata-ExifTool Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- Created attachment 168809 --> https://bugs.kde.org/attachment.cgi?id=168809=edit Screenshot showing that digikam uses file modification date rather than exiftool's creation date. SUMMARY Hi. I noticed that the .MTS videos that my Sony camera films, when imported into Digikam, the creation date (dateTimeOriginal) is not read. Instead, the file modification date is used. I have attached a screenshot as a reference. STEPS TO REPRODUCE 1. Import MTS video file 2. Check date of file in digikam 3. Check date of file in exiftool. OBSERVED RESULT - Digikam uses modification date rather than date in the metadata. EXPECTED RESULT The date in the metadata should be used instead. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS digiKam-8.4.0-20240421T104710-Qt6-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 479629] Feature request: better integration of Auto-tags with the UI
https://bugs.kde.org/show_bug.cgi?id=479629 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 479629] New: Feature request: better integration of Auto-tags with the UI
https://bugs.kde.org/show_bug.cgi?id=479629 Bug ID: 479629 Summary: Feature request: better integration of Auto-tags with the UI Classification: Applications Product: digikam Version: 8.3.0 Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: Tags-AutoAssignement Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY Hi, as I mentioned in the mailing list, I'm excited about the new autotags feature. I love being able to categorize pictures without depending on any external service. However, when I tried the latest weekly build, it took me a while to find where and how to trigger the auto-tagging feature, and I would have completely missed it if it weren't for a reddit post that showed it. So, my feature request here is a better integration of this feature with the user interface. For instance, just being able to select a bunch of pictures and right click -> Auto-tag would really make a difference. Or from the main menu too. The possibility of running auto-tag on newly found items after the initial scan would also be helpful, just like how running face detection is currently an option. Let me know if it's feasible. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 476863] Faces in People panel do not respect the sort order
https://bugs.kde.org/show_bug.cgi?id=476863 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 476863] New: Faces in People panel do not respect the sort order
https://bugs.kde.org/show_bug.cgi?id=476863 Bug ID: 476863 Summary: Faces in People panel do not respect the sort order Classification: Applications Product: digikam Version: 8.2.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-Sort Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY Hi. I believe there has been some kind of regression. In the latest appimages (including the 2023-11-11), the sort order for faces seems to be random. It does not respect the Sort Items. I can confirm it is working fine in the digiKam-8.2.0-20231029T182058.appimage. STEPS TO REPRODUCE 1. Go to the People panel. 2. Click on any person. 3. Try to change the sort order (e.g. View, Sort Items, By Creation Date) OBSERVED RESULT Nothing happens. EXPECTED RESULT The sort order should be respected. SOFTWARE/OS VERSIONS digiKam-8.2.0-2023T124740-x86-64.appimage in Kubuntu 22-.04 LTS -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 471183] Face recognition, see and edit references
https://bugs.kde.org/show_bug.cgi?id=471183 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416988] Objects / Forms / Monuments / Context detection and recognition using Deep Learning
https://bugs.kde.org/show_bug.cgi?id=416988 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406583] Cannot write special characters (è, í, ó) in Tag search box
https://bugs.kde.org/show_bug.cgi?id=406583 --- Comment #48 from MarcP --- Hello again Gilles, I did a clean install on a Windows 10 computer, and the special characters work perfectly there. So there's definitely something wrong with my Kubuntu installation/configuration. I'll try to figure it out. Thanks though! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406583] Cannot write special characters (è, í, ó) in Tag search box
https://bugs.kde.org/show_bug.cgi?id=406583 --- Comment #47 from MarcP --- That's strange, maybe it's my particular installation/configuration. I will try later today from a Windows 10 computer and possibly a MacOs computer as well, see if I can replicate this issue there too. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406583] Cannot write special characters (è, í, ó) in Tag search box
https://bugs.kde.org/show_bug.cgi?id=406583 --- Comment #45 from MarcP --- Hi. I'm sorry to disappoint, but the issue is still present, at least on my end. I tested it on the digiKam-8.2.0-20231007T150049-x86-64.appimage version, under Kubuntu 22.04 LTS. However, something changed. Until now, I couldn´t type special characters when the popup was present, but now I'm unable to write any kind of accented character. So I cannot write something like "María" under any circumstances. I can write it on a notepad and paste it, though. I tried it both in the Tag search and in the People search fields. I'm using a US keyboard with the "English (US, intl., with dead keys)" variant to be able to type special characters, but I have also configured the standard Spanish layout just to test if that special US variant was interferring, but the result was the same. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 --- Comment #11 from MarcP --- Hi Maik, I have been trying the latest appimage (digiKam-8.2.0-20230907T053317-x86-64.appimage) and it is definitely a big improvement. With this change, I can keep scrolling down to a person's list of faces without having to wait the previous ones to generate, making the whole thing much smoother. I still get little freezes in the interface from time to time, particularly when some files are being read or written, like during the initial scan, but this is probably an unrelated issue. In any case, at least in my opinion, now it feels much better to browse faces. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 --- Comment #8 from MarcP --- Hi Maik, thanks for your time and effort. Yes, i usually tend to use the lastest appimage available. I will try it as soon as I can and let you know, probably tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 --- Comment #5 from MarcP --- (In reply to Maik Qualmann from comment #4) > I already understand the problem. If you scroll down, the thumbnails are > requested according to the view model. If there are any in between that are > not yet in the DB, they will be generated first and the loading of the other > thumbnails will stop. This is of course particularly noticeable on a slow > system. However, we cannot start a separate process for each thumbnail, as > this would overload memory. There are many image formats that need to be > fully loaded. What would be conceivable are 2 processes, one that loads and > generates and one that only loads from the DB. > > Maik Exactly. Yes, being able to immediately see all the available thumbnails, and then sequentially generate the missing ones would be perfect. Currently, when you are browsing faces, the moment you encounter one missing thumbnail, nothing else is shown (even for other people) until that thumbnail finished generating. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 --- Comment #3 from MarcP --- Hello Maik, thanks for your quick response. Iḿ not sure we are talking about the same thing, though. I can verify that the behavior I describe happens even when digikam is not importing or processing anything. I have attached a simple diagram that will help illustrate my point. Image you have tagged the face of a person in 48 photos. These face thumbnails have already been generated and are in the database (thumbnails-digikam.db I presume). When you browse that person's faces, these load immediately. So far, so good. Now, imagine you tag that face in two additional photos. So, 50 in total. Chronologically speaking, the two new pictures are the 13th and 16th respectively. Now you browse to that person's faces, and what you see is the following: 1) faces from 1 to 12 load immediately, but 13 to 50 are invisible. 2) When after a few seconds face 13 is generated, 14 and 15 appears immeidately (since they were already in the database). 16 to 50 still invisible. 3) Next, 16 is generated. Once it's done, the rest of the pictures will be visible again (16-50). So what I'm proposing here: 1) Load faces already in the database first (so 1-12, 14-15, 17-50). 2) Then, start generating the missing ones (13 & 16). I hope I made it clearer this time. Thanks for your time! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 --- Comment #2 from MarcP --- Created attachment 161381 --> https://bugs.kde.org/attachment.cgi?id=161381=edit Simple diagram to illustrate behavior -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] New: Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 Bug ID: 474105 Summary: Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated Classification: Applications Product: digikam Version: 8.2.0 Platform: Appimage OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Thumbs-IconView Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY Ok, this is regarding a possible optimization when loading face thumbnails. Face thumbnails only load when you scroll through them (Bug 395241), and as such, it is pretty common that when you see the faces for a specific person, many thumbnails still need to be generated. Now, the most common scenario will be one in which a person already has many of these thumbnails already generated in the database plus some new thumbnails that still need to be generated (e.g. let's say someone has 40 face regions, 30 with thumbnail in the db and 10 which need to be generated). The issue is the following: Face thumbnails load sequentially. That is, if thumbnail #2 is needs to be generated, but thumbnails 3-15 are already present, thumbnails 3-15 won't show until 2 has finish generating. This is specially relevant when using a NAS or other slow network, since each thumbnail can take 4-5 seconds to generate, so most of the thumbnails for a person won't be visible until the few missing ones have been generated. I think the ideal would be to first show all the available thumbnails, regardless of the order, and then generate the missing ones. Let me know if you need more details or it's not clear what I'm asking. Thanks! STEPS TO REPRODUCE 1. Tag a person tagged with multiple face regions across many pictures. 2. View that person in the Face panel to generate the face thumbnails. 3. Tag some more faces for the same person. 4. View that person in the face panel once again OBSERVED RESULT Notice how the faces tagged in #1, already in the database, don't show the thumbnail until the faces tagged in #3 have their thumbnail generated. EXPECTED RESULT First show the already generated thumbnails immediately, and then generate and show the remaining ones. SOFTWARE/OS VERSIONS digiKam-8.2.0-20230902T115106-x86-64.appimage Linux/KDE Plasma: Kubuntu 22.04 LTE (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION This is related to bug reports bug 395241, bug 461838, bug 444767 (is this a duplicate?), and bug 395241. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474105] Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated
https://bugs.kde.org/show_bug.cgi?id=474105 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474047] When an album is refreshed in thumbnail view, the focus goes to the previously selected item
https://bugs.kde.org/show_bug.cgi?id=474047 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474047] New: When an album is refreshed in thumbnail view, the focus goes to the previously selected item
https://bugs.kde.org/show_bug.cgi?id=474047 Bug ID: 474047 Summary: When an album is refreshed in thumbnail view, the focus goes to the previously selected item Classification: Applications Product: digikam Version: 8.2.0 Platform: Ubuntu OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Albums-IconView Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY This is something I have been noticing for a few months. In Thumbnail view, when a file is selected (there's a little dotted line around it), and you scroll somewhere else in that view, if that view is refreshed (e.g. a new picture is imported, or a new face is detected), the view automatically scrolls back to the selected picture. This also happens when working on the People panel. When a new panel for someone is found, the view scrolls back to the previously selected item. This can be quite annoying because it makes you lose your focus. Let me know if you need more details. STEPS TO REPRODUCE 1. Go to thumbnail view, or People view. 2. Select one of the pictures. 3. Move far away from that picture (but to not select anything else) 4. Import some new pictures (or scan faces for the active person). OBSERVED RESULT The focus of the view goes to the previously selected item. EXPECTED RESULT The focus should stay wherever the user is at any given moment. SOFTWARE/OS VERSIONS digiKam-8.2.0-20230724T132443-x86-64.appimage Linux/KDE Plasma: Kubuntu 22.04 LTE (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 251357] SCHEMA : add time zone support as properties of items
https://bugs.kde.org/show_bug.cgi?id=251357 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377857] Ideas to improve usability of image properties sidebar tab.
https://bugs.kde.org/show_bug.cgi?id=377857 --- Comment #45 from MarcP --- I'm glad to see that the Properties tab is getting some love! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416743] Face rectangle tool gets deselected if changes are being written to file
https://bugs.kde.org/show_bug.cgi?id=416743 --- Comment #9 from MarcP --- Yes. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 444767] All face thumbnails in a picture refresh each time a face is confirmed
https://bugs.kde.org/show_bug.cgi?id=444767 --- Comment #11 from MarcP --- Yes. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 460134] Properties tab does not display the full caption of a picture
https://bugs.kde.org/show_bug.cgi?id=460134 --- Comment #6 from MarcP --- > Your string as paragraph separated by endl ? I think in this case it's a single paragraph. >The "..." before the text is the squezzed text label used to display long >strings. It used everywhere on the right side of the properties tab to display >contents. Couldn't we automatically fit the text, and limit it to the first X lines (or whatever amount of words fit according to the panel width and font size)? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 460134] Properties tab does not display the full caption of a picture
https://bugs.kde.org/show_bug.cgi?id=460134 --- Comment #4 from MarcP --- Mmm, that is not my experience. For instance, I have a photo with this caption (53 words): "During circle time, our inventors engaged with some sensory books. Each page has a different texture of fabrics for them to explore with their senses. They enjoyed touching the soft smooth fur and the rough glittery pages. Our inventors engaged with their fine motor skills by practicing flipping, opening, and closing the pages." But in the Properties panel, I can only read "...flipping, opening, and closing the pages." I'm using the 8.1.0 preview build date 22/4/23 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 460134] Properties tab does not display the full caption of a picture
https://bugs.kde.org/show_bug.cgi?id=460134 --- Comment #2 from MarcP --- Hi Gilles, I don't see a difference in v8.0.0. I just tried it, and only the last few words of each paragraph are shown on the Properties tab. This is also visible in the screenshot you just posted. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416213] People tags appear duplicated after having moved them in the tag tree, if the tag was already present at /People/
https://bugs.kde.org/show_bug.cgi?id=416213 --- Comment #17 from MarcP --- Yes, this is still relevant. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 443827] Clicking on a person with unconfirmed suggestions does not always focus on these suggestions
https://bugs.kde.org/show_bug.cgi?id=443827 --- Comment #6 from MarcP --- Yes, the behavior is still the same. If previously a picture from that person had been selected, when clicking on the person on the People panel, the focus will go to that selected picture instead of going to the top if there are new suggestions. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459194] OpenStreetMap looks blurry on default zoom level
https://bugs.kde.org/show_bug.cgi?id=459194 --- Comment #7 from MarcP --- Yes, I just tested it and it's still relevant. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406583] Cannot write special characters (è, í, ó) in Tag search box
https://bugs.kde.org/show_bug.cgi?id=406583 --- Comment #42 from MarcP --- Yes, this is still an issue. (Although it was solved in that preview for the next version of qt) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462413] Map view freezes when viewing large number of elements
https://bugs.kde.org/show_bug.cgi?id=462413 --- Comment #5 from MarcP --- No, this problem is no longer present, you can close it. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395241] Faces in the "People" panel load slowly, and only when you scroll through them
https://bugs.kde.org/show_bug.cgi?id=395241 --- Comment #18 from MarcP --- Hi, This is not my experience. After new pictures are found, they are scanned for faces and recognized (I have checked the option to scan them automatically on startup on the settings). Then, I usually go to Unconfirmed o Unrecognized sections in the People panel to tag them. At that point I think the face thumbnails for the new faces area already generated. But then, when you confirm any of these new faces, all the face thumbnails in that picture will need to be recreated, so you have to go to each one of the persons in that picture and scroll through that specific picture to have it generated. My network is rather slow, so that process is very noticeable because it takes several seconds per face. Ideally, the face thumbnails created when the faces are first detected shouldn't need to be recreated unless the image is edited (just modifying the metadata should not trigger the regeneration of the thumbnail). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395241] Faces in the "People" panel load slowly, and only when you scroll through them
https://bugs.kde.org/show_bug.cgi?id=395241 --- Comment #16 from MarcP --- Yes, this is still valid for v8.0. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 392008] Inconsistent behavior of "People" Tag
https://bugs.kde.org/show_bug.cgi?id=392008 --- Comment #13 from MarcP --- Hi Gilles, Kind of. It's not a bug per se, but a result of the way Digikam treats face regions and regular keywords. Face tags and regular tags are "merged" (shown as a single element) in Digikam if they have the same name. But not all picture managers also write a regular tag when a face is added, and this can lead to inconsistencies. So basically the problematic behavior here is that some face tags might end up outside "People" when importing pictures with new people in it. That will happen if: 1) The first picture that contained that name only contained it as a regular tag. 2) Subsequent pictures also (or only) contain that same name as a face tag. In that case Digikam will first place that tag outside the People hierarchy (because it wasn't a face tag at first), but then, when scanning more pictures, even if they contain face regions with that name, will continue to place them on the already created tag, outside the "People" hierarchy. It's a rather minor thing once your library has been curated in Digikam, but it can be a bit annoying when importing pictures edited in another picture manager. And I don't see an easy solution either. If digikam automatically realized that that new tag is indeed a face tag, it could move it inside "People", but that is a very dangerous move, because you don't know if the user had previously placed that tag somewhere else on purpose. Anyway, feel free to do what you want with this report. I still think I'd like to see regular tags and people tags being treated as independent things, but this is not how digikam has been working until now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466412] Feature request: option to manually generate face thumbnails
https://bugs.kde.org/show_bug.cgi?id=466412 MarcP changed: What|Removed |Added Platform|Other |Appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 444767] All face thumbnails in a picture refresh each time a face is confirmed
https://bugs.kde.org/show_bug.cgi?id=444767 MarcP changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=466412 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466412] Feature request: option to manually generate face thumbnails
https://bugs.kde.org/show_bug.cgi?id=466412 MarcP changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=444767 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461838] All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise
https://bugs.kde.org/show_bug.cgi?id=461838 MarcP changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=466412 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466412] Feature request: option to manually generate face thumbnails
https://bugs.kde.org/show_bug.cgi?id=466412 MarcP changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=461838 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395241] Faces in the "People" panel load slowly, and only when you scroll through them
https://bugs.kde.org/show_bug.cgi?id=395241 MarcP changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=466412 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466412] Feature request: option to manually generate face thumbnails
https://bugs.kde.org/show_bug.cgi?id=466412 MarcP changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=395241 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466412] Feature request: option to manually generate face thumbnails
https://bugs.kde.org/show_bug.cgi?id=466412 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466412] New: Feature request: option to manually generate face thumbnails
https://bugs.kde.org/show_bug.cgi?id=466412 Bug ID: 466412 Summary: Feature request: option to manually generate face thumbnails Classification: Applications Product: digikam Version: 8.0.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Maintenance-Faces Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY Hi, it's me again with another feature request. Let's see what you think. Currently, face thumbnails are only generated by demand, as they are displayed when you select a person in the People panel. That means that, even in a computer with fast storage, the retrieval of the faces thumbnails is rather slow, and there's no way around it. This issue is mentioned here: Bug 395241 What about adding an option to the Maintenance tool to generate missing face thumbnails for a person/album? There is already one called "Rebuild Thumbnails", so a similar one could be implemented for faces. That would allow pre-caching a person's faces so when you see their faces in the menu they would load much faster. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 418380] Use different checkbox for 'must not have this tag'
https://bugs.kde.org/show_bug.cgi?id=418380 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[baloo-widgets] [Bug 341288] No Exif-data shown, if pictures are accessed from remote drives (NAS)
https://bugs.kde.org/show_bug.cgi?id=341288 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462464] Cannot play video files: "An error has occurred with the media player..."
https://bugs.kde.org/show_bug.cgi?id=462464 --- Comment #2 from MarcP --- Ok, done, it works now. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 415999] Progress bar goes backwards when tagging faces (from (100% to 0%)
https://bugs.kde.org/show_bug.cgi?id=415999 --- Comment #5 from MarcP --- Hi. Just to confirm this still happens in the 8.0.0 preview appimage. I have tagged lots of faces these days, and the progress bar goes backwards. Apparently it's just for faces, for normal tags, it goes from 0 to 100%. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462464] Cannot play video files: "An error has occurred with the media player..."
https://bugs.kde.org/show_bug.cgi?id=462464 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462464] New: Cannot play video files: "An error has occurred with the media player..."
https://bugs.kde.org/show_bug.cgi?id=462464 Bug ID: 462464 Summary: Cannot play video files: "An error has occurred with the media player..." Classification: Applications Product: digikam Version: 8.0.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-MainView Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY I am not sure if it's an issue that has already been reported, but I can't seem to play video files in the 8.0.0 preview appimage (videos that play fine in 7.9). The view area is grey and shows the message "An error has occurred with the media player...". However, I can hear the sound of the video. I have tried both with .mov files in the h264 codec, and .mp4 files with the hevc codec. In the console, this is what I see: QtAV::AVDecoder::setCodecContext: Can not copy codec properties when it's open QtAV::AVDemuxer::setStreamIndex: invalid index 0 ( valid is 0 ~ 0 ) for stream type 2 QtAV::audioFormatToAL: OpenAL audioFormatToAL error (null context): 0xa004 QtAV::audioFormatToAL: AudioOutputOpenAL Error: No OpenAL format available for audio data format flt stereo. QtAV::audioFormatToAL: OpenAL audioFormatToAL error (null context): 0xa004 QtAV::audioFormatToAL: AudioOutputOpenAL Error: No OpenAL format available for audio data format s32 stereo. QtAV::audioFormatToAL: OpenAL audioFormatToAL error (null context): 0xa004 QtAV::AudioResamplerFF::prepare: src audio parameters 'channel layout(or channels),sample rate and sample format must be set before initialize resampler QtAV::AVPlayerCore::Private::setupVideoThread: "Video codec not found" QtAV::AudioDecoderFFmpeg::decode: [AudioDecoder] got_frame_ptr=false. decoded: 6, un: 0 Error number 6 occurred QtAV::AudioDecoderFFmpeg::decode: [AudioDecoder] got_frame_ptr=false. decoded: 369, un: 0 Error number 369 occurred STEPS TO REPRODUCE 1. In digikam 8.0.0 appimage, double click on any video file. OBSERVED RESULT Only audio is heard, no image. EXPECTED RESULT Videos plays. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS with digiKam-8.0.0-git-20221124T104306-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462413] Map view freezes when viewing large number of elements
https://bugs.kde.org/show_bug.cgi?id=462413 --- Comment #2 from MarcP --- That's a cool feature. I sometimes record .gpx tracks when I go hiking, and use them to correlate the coordinates for these pictures without geolocation. But yes, it's possible that having to recursively look into directories might be the source of that slowdown I experienced. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462413] Map view freezes when viewing large number of elements
https://bugs.kde.org/show_bug.cgi?id=462413 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 462413] New: Map view freezes when viewing large number of elements
https://bugs.kde.org/show_bug.cgi?id=462413 Bug ID: 462413 Summary: Map view freezes when viewing large number of elements Classification: Applications Product: digikam Version: 8.0.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Geolocation-Marble Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY I have noticed that, in the 8.0.0 preview, when I select a tag or an album and I select the Map view, the interface can freeze for a while, depending on the number of pictures. For instance, it can freeze for 2 or 3 minutes for 3 pictures (most of them without gps data). I have tried in a 7.9 version and that doesn't happen (takes 5 seconds at most to load the exact same items), so it's likely a regression. STEPS TO REPRODUCE 1. Select an album root containing a few thousand pictures. 2. Select Map view on the top panel 3. Wait until digikam is responsive again OBSERVED RESULT It can take several minutes. EXPECTED RESULT It should only take the time needed to place the items on the map. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS and digiKam-8.0.0-git-20221124T104306-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461838] All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise
https://bugs.kde.org/show_bug.cgi?id=461838 --- Comment #3 from MarcP --- Ok, I have checked the traffic on my NAS, and yes, a single picture will be transferred as many times as faces there are in the photo (so, 100MB for a 5MB photo with 20 faces on it). Couldn't digikam get the photo just once, and recreate all the face-thumbnails from that info? That would greatly improve the performance. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461838] All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise
https://bugs.kde.org/show_bug.cgi?id=461838 --- Comment #2 from MarcP --- But the thumbnails are reloaded from the picture iself, not from the thumbnail already existing in the database, aren't they? In a NAS, that would mean that a single picture would need to be transferred 20 times if there are 20 faces in it. Or am I getting it wrong? Couldn't all the faces in a picture be refreshed from a single transfer? Anyway, it's a pity. Would it be possible to have two kinds of refresh, one that just refreshes the metadata, and another one that also refreshes thumbnails and face-thumbnails? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461838] All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise
https://bugs.kde.org/show_bug.cgi?id=461838 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461838] New: All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise
https://bugs.kde.org/show_bug.cgi?id=461838 Bug ID: 461838 Summary: All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise Classification: Applications Product: digikam Version: 8.0.0 Platform: Appimage OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY I believe it was already mentioned in another bug report, but today I had to face-tag a series of pictures of a family reunion which included more than 20 people each, and it reminded me that I could mention this to you developers. During the face-tagging process, I had to wait minutes between each tagging because digikam reconstructs all the face miniatures in a photo after any modification. And I'm not sure if the picture file needs to be accessed for each miniature, but they are generated one by one. That means that if there are 20 faces on a picture, and it takes 3 seconds to recreate the thumbnail, I will have to wait a minute to tag a face in the same picture. Moreover, this inconvenience is aggravated by what was described in bug 395241, in which faces only load as you scroll through them. I'm sure there's a reason why this is done this way, but wouldn't there be a more efficient way? Face positions or content is not something that change when a face is tagged, so previously existing faces wouldn't need to be refreshed. Or if the refresh is compulsory, why not temporarly show the "old" face before re-generating it, so it doesn't appear blank all that time? I've seen that what other pictures managers do, is to temporarly use a zoomed-in fragment of the main picture before loading the high-resolution face, in order to prevent blank thumbnails while they are being constructed. What do you think? PS: sorry if it came out as a bit of rant, it wasn't my intention, I was just brainstorming for possible improvements. Keep up the good work! STEPS TO REPRODUCE 1. Take a picture with multiple people in it, and scan it for faces. Wait for the scan to finish 2. Go to the People panel, "Unknown" category, so the faces on the picture are ready to be tagged 3. Tag one of the faces. OBSERVED RESULT - All the rest of the faces in that picture become "blank" for a while, and they are regenerated one by one, taking some time for each one (depending on the file access speed). EXPECTED RESULT - The rest of the faces don't need to be re-generated since the content of the picture hasn't changed, only the metadata. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS digiKam-8.0.0-git-20221108T185710-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461799] No progress is shown for second face recognition process
https://bugs.kde.org/show_bug.cgi?id=461799 --- Comment #3 from MarcP --- Wouldn't a better option be queueing the pictures to be scanned for faces, so they don't run in parallel but in series? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461799] New: No progress is shown for second face recognition process
https://bugs.kde.org/show_bug.cgi?id=461799 Bug ID: 461799 Summary: No progress is shown for second face recognition process Classification: Applications Product: digikam Version: 7.9.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY I noticed that if a second (or more) face recognition task is started when some other faces are being recognized, the second (and subsequent) tasks are not shown in the progress bar. However, it will continue in the background, although there's no visual feedback of the process completion. STEPS TO REPRODUCE 1. Select a picture folder/album, right click, "Scan for Faces". 2. Observe how a progress bar is shown at the bottom right. 3. Select another picture folder/album, right click, "Scan for Faces". OBSERVED RESULT Nothing apparently happens. The second album is actually being scanned, but without any indicator of its progress. EXPECTED RESULT A second progress bar should appear showing the progress of that second task. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS digiKam-7.9.0-20221030T175249-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461799] No progress is shown for second face recognition process
https://bugs.kde.org/show_bug.cgi?id=461799 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 391435] Feature request: show loading indicator when loading picture
https://bugs.kde.org/show_bug.cgi?id=391435 --- Comment #1 from MarcP --- I know this is an old suggestion, but have you given any thought at this? I am currently using digikam with a library that is behind a relatively slow network. Some pictures take 5-10 seconds to load, depending on the size. When I double click on a picture, I have no feedback that it is being loaded, until a few second later when the picture suddenly appears. Sometimes it feels non-responsible and it makes me double-click again, just in case. Maybe the progress bar could be used as an indicator that something is being done? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461710] Extra click required to confirm faces when face tagging a picture
https://bugs.kde.org/show_bug.cgi?id=461710 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461710] New: Extra click required to confirm faces when face tagging a picture
https://bugs.kde.org/show_bug.cgi?id=461710 Bug ID: 461710 Summary: Extra click required to confirm faces when face tagging a picture Classification: Applications Product: digikam Version: 8.0.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY In the 8.0.0 beta version of digikam (appimage), I noticed a little regression. When selecting a face from the drop down list, you still have to manually confirm that face. Until now, just clicking on the face was enough to assign it. Seems to be analogous to bug #372761 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS digiKam-8.0.0-git-20221108T185710-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 351987] Allow to search by Country, City, Town when appropriate geo-location tags exist in database
https://bugs.kde.org/show_bug.cgi?id=351987 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461366] Missing face thumbnails/icons on people are not assigned automatically
https://bugs.kde.org/show_bug.cgi?id=461366 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461366] New: Missing face thumbnails/icons on people are not assigned automatically
https://bugs.kde.org/show_bug.cgi?id=461366 Bug ID: 461366 Summary: Missing face thumbnails/icons on people are not assigned automatically Classification: Applications Product: digikam Version: 7.9.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY I have noticed that many of the people in my People list do not have a face thumbnail/icon assigned to their face, despite several faces being available. I believe that happened because these people were not added inside digikam, but instead they were imported from pictures that already had that metadata with people in it (or a folder was temporary unavailable and then rescanned again). In that case, the person is left without a face thumbnail. Another case would be when the face that corresponds to the face icon is deleted, and that person is left without a face. I believe in these cases, there should be some kind of process that checks for faces with missing icons and assign one among the available ones. STEPS TO REPRODUCE 1. Tag a face rectangle in a picture not using digikam (or using another database). 2. Import that picture into digikam. 3. Observe the icon for that person in the People list. OBSERVED RESULT That person does not have an icon for their face. EXPECTED RESULT If the person does not have yes icon, assign one among the available ones. SOFTWARE/OS VERSIONS digiKam-7.9.0-20221030T175249-x86-64.appimage Linux/KDE Plasma: Kubuntu 22.04 (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 460134] Properties tab does not display the full caption of a picture
https://bugs.kde.org/show_bug.cgi?id=460134 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 460134] New: Properties tab does not display the full caption of a picture
https://bugs.kde.org/show_bug.cgi?id=460134 Bug ID: 460134 Summary: Properties tab does not display the full caption of a picture Classification: Applications Product: digikam Version: 7.9.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability-Ergonomy Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- Created attachment 152648 --> https://bugs.kde.org/attachment.cgi?id=152648=edit Captions in the Properties panel SUMMARY This is a visual/usability issue. When adding a long caption to a picture, that caption is not fully displayed in the Properties tab, which only shows the start of the first line. Hovering the mouse over it shows the full caption as a popup, but the panel has more than enough empty space to display the full caption. This could be one of the possible improvements for the Properties menu that were proposed in bug 377857 STEPS TO REPRODUCE 1. Add a relatively long caption to a picture (e.g. 30 words). 2. Switch to the Properties panel. OBSERVED RESULT See how only the first words of the caption are shown there. EXPECTED RESULT The full caption could be shown if there's room for it. SOFTWARE/OS VERSIONS digiKam-7.9.0-20220924T122331-x86-64.appimage in Kubuntu 22.04 LTS -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459874] Feature request: being able to filter or search pictures without a date in the metadata
https://bugs.kde.org/show_bug.cgi?id=459874 --- Comment #2 from MarcP --- I see. I wasn't sure if that info was in the database. Anyway, I'll keep using exiftool for that purpose. You can close this request if you want. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 155384] Easily copy properties from one image to another one
https://bugs.kde.org/show_bug.cgi?id=155384 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459874] New: Feature request: being able to filter or search pictures without a date in the metadata
https://bugs.kde.org/show_bug.cgi?id=459874 Bug ID: 459874 Summary: Feature request: being able to filter or search pictures without a date in the metadata Classification: Applications Product: digikam Version: 7.9.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Searches-Dates Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY The advanced search and the filter panels are already quite complete, but I have a user case which I cannot carry out using digikam right now. I would like to be able to find which pictures do not have an EXIF or XMP date. Sometimes I (or someone else using the picture library) receive pictures via instant messaging, which do not contain any metadata. I usually use the Adjust Time Date tool to set the date (otherwise the date ends up being the file creation or modification date), but I know there must be hundreds of pictures without a date in the metadata, and need to be fixed. I don't know exactly how could that be carried out in digikam. Maybe an "Images without date" in the Filters panel, and then inside a list of checkboxes for the different dates (EXIF creation, original, digitized, and the same for ITPC and XMP). Or maybe adding a "Date" section in the Advanced Search, I don't know. On the other hand, I don't even know if these specific fields are saved in the database or are read from the picture on the go. For the moment, I use a exiftool script that lists pictures without date in a given folder. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459537] "Ignored" face regions should not be saved into XMP metadata
https://bugs.kde.org/show_bug.cgi?id=459537 --- Comment #3 from MarcP --- Thank you, Maik! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459537] "Ignored" face regions should not be saved into XMP metadata
https://bugs.kde.org/show_bug.cgi?id=459537 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459537] New: "Ignored" face regions should not be saved into XMP metadata
https://bugs.kde.org/show_bug.cgi?id=459537 Bug ID: 459537 Summary: "Ignored" face regions should not be saved into XMP metadata Classification: Applications Product: digikam Version: 7.9.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: iwannaber...@gmail.com Target Milestone: --- SUMMARY Whenever you click to "Ignore" a face, a face region and a keyword with the name "Ignore" is saved into the picture metadata. As if it was a person called "Ignored". When you open one of these pictures, said person will have a rectangle over their face with the word "Ignored". I believe in this case, that info should only be saved into digikam's database, but not in the metadata, as the only purpose for that function is to hide that face from the suggestions and avoid it being detected again by the face recognition engine. What do you think? STEPS TO REPRODUCE 1. Run face detection on some pictures 2. Ignore some pictures 3. Check the metadata on these pictures OBSERVED RESULT 4. "Ignored" is saved as a face region and as a keyword in XMP metadata EXPECTED RESULT Ignored faces are just hidden in the interface under their own category, nothing is written to the image metadata. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 LTS (available in About System) KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432537] Improve face-recognition accuracy by visually de-selecting "bad faces" to be used within the faces-engine
https://bugs.kde.org/show_bug.cgi?id=432537 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 428187] first user experience scares (non technical) people away and picasa3 faces imported but not as faces
https://bugs.kde.org/show_bug.cgi?id=428187 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[marble] [Bug 437216] Maps on HiDPI are blurry
https://bugs.kde.org/show_bug.cgi?id=437216 --- Comment #3 from MarcP --- Digikam internally uses Marble to show geolocated oictures on a map. I noticed that problem too. I reported it with more details and some screenshots in this Bug #459194. I hope it helps. -- You are receiving this mail because: You are watching all bug changes.
[marble] [Bug 437216] Maps on HiDPI are blurry
https://bugs.kde.org/show_bug.cgi?id=437216 --- Comment #2 from MarcP --- Digikam internally uses Marble to show geolocated oictures on a map. I noticed that problem too. I reported it with more details and some screenshots in this Bug #459194. I hope it helps. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459194] OpenStreetMap looks blurry on default zoom level
https://bugs.kde.org/show_bug.cgi?id=459194 --- Comment #5 from MarcP --- I see, I didn't know they were separate products. -- You are receiving this mail because: You are watching all bug changes.
[marble] [Bug 437216] Maps on HiDPI are blurry
https://bugs.kde.org/show_bug.cgi?id=437216 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[marble] [Bug 296149] OpenStreetMap : map blur problem
https://bugs.kde.org/show_bug.cgi?id=296149 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457072] Refined map feature
https://bugs.kde.org/show_bug.cgi?id=457072 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 184833] Add support of drag and drop images over MapView
https://bugs.kde.org/show_bug.cgi?id=184833 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459160] Geolocation Editor maps don’t zoom enough
https://bugs.kde.org/show_bug.cgi?id=459160 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459194] OpenStreetMap looks blurry on default zoom level
https://bugs.kde.org/show_bug.cgi?id=459194 MarcP changed: What|Removed |Added CC||iwannaber...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459194] OpenStreetMap looks blurry on default zoom level
https://bugs.kde.org/show_bug.cgi?id=459194 --- Comment #3 from MarcP --- Created attachment 152088 --> https://bugs.kde.org/attachment.cgi?id=152088=edit Zoom out -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459194] OpenStreetMap looks blurry on default zoom level
https://bugs.kde.org/show_bug.cgi?id=459194 --- Comment #2 from MarcP --- Created attachment 152087 --> https://bugs.kde.org/attachment.cgi?id=152087=edit Zoom in -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 459194] OpenStreetMap looks blurry on default zoom level
https://bugs.kde.org/show_bug.cgi?id=459194 --- Comment #1 from MarcP --- Created attachment 152086 --> https://bugs.kde.org/attachment.cgi?id=152086=edit Default zoom level -- You are receiving this mail because: You are watching all bug changes.
