[digikam] [Bug 431797] Face recognition <1% despite extensive training data of up to 300 occasions of faces
https://bugs.kde.org/show_bug.cgi?id=431797 --- Comment #13 from iain --- (In reply to caulier.gilles from comment #12) > @iain, > > > This problem still reproducible with the new digiKam 8.2.0 pre-release > Windows > installer available at usual place: > > https://files.kde.org/digikam/ > > This new bundle is based on last Qt framework 5.15.11 and KDE framework > 5.110. > > Thanks in advance > > Gilles Caulier Hi @Gilles, I've tested 8.2.0 (revision 6ab20bb9162eba8823081cb7fc15597286c1001b) and it is much much better, I'd say it is about 50% accurate now. Still not as accurate as Picasa/Facebook manage. Iain -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 473846] New: Screen Grab not working correctly with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=473846 Bug ID: 473846 Summary: Screen Grab not working correctly with multiple monitors Classification: Applications Product: kdenlive Version: 23.04.3 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: w.iain.morri...@gmail.com Target Milestone: --- Created attachment 161238 --> https://bugs.kde.org/attachment.cgi?id=161238&action=edit screen grab showing captured video SUMMARY I have 4 monitors attached to my PC and I want to grab the screen from one monitor however KdenLive grabs all the screens simultaneously STEPS TO REPRODUCE 1. in screen and grab configuration select 'rectangular region' in 'region to capture, and set size to 1920x1080 2. in screen and grab select any screen (0, 1, 2, 3) and press record 3. review captured footage and you will see all screens have been captured as a single output, not a 1920x1080 regions, or a specific monitor. OBSERVED RESULT all screens captures EXPECTED RESULT able to capture single screen SOFTWARE/OS VERSIONS Windows: 23H2 b 22631.2191 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Video card - nVidia GeForce GTX 1080 Ti onboard - Intel UHD 630 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 431797] Face recognition <1% despite extensive training data of up to 300 occasions of faces
https://bugs.kde.org/show_bug.cgi?id=431797 --- Comment #10 from iain --- I still face this issue with v8.0.0. I did not manually draw any of the face rectangles. As described in 472031 my observation is that it worked well with 4-5 faces for a person but when I re-trained with hundreds the accuracy reduced massively. Also worth noting a lot of my faces where tagged with previous digikam versions (6+). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472031] New: Faces detection gets worse with lots of faces to train on
https://bugs.kde.org/show_bug.cgi?id=472031 Bug ID: 472031 Summary: Faces detection gets worse with lots of faces to train on Classification: Applications Product: digikam Version: 8.0.0 Platform: macOS (DMG) OS: macOS Status: REPORTED Severity: normal Priority: NOR Component: Faces-Detection Assignee: digikam-bugs-n...@kde.org Reporter: iain+...@cardnell.co.uk Target Milestone: --- I believe that using the "Clear and re-build all training data" for face detection makes the detection worse with the more faces you have tagged. Initially I manually tagged 4-5 faces of a few people and detected faces (I have around 1). The initial scan went well and I'd say it was 80% accurate. As I tagged more people manually and rebuilt the training data the new Recognise Faces runs got worse. I now have 2000+ faces tagged over 50+ people and the accuracy is almost 0. I believe that it now has too much training data and the faces are too different across all the images to train a model properly. I'm not sure how other engines cope with this problem. (e.g. I am now tagged over 1000 times in my albums). What might be a simple workaround is to allow a user to choose 4-5 good images for each person and use those as the training set rather than trying to use every example. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 410669] KStars High CPU macOS
https://bugs.kde.org/show_bug.cgi?id=410669 --- Comment #10 from Iain --- Seems alot better to me using version 3.5.5 stable. I only did a cursory check and although the CPU usage spiked soon after startup it soon settled to single digits. Seems this should be resolved and re-opened with more specific details if it reoccurs. Thanks -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425902] Update digiKam information on the fly to XMP metadata from HEIF files
https://bugs.kde.org/show_bug.cgi?id=425902 iain changed: What|Removed |Added CC||iain+...@cardnell.co.uk --- Comment #5 from iain --- Hi, with 7.3.0 should metadata for HEIF files now be written to the file itself rather than XMP sidecar? I still see the sidecar being created (but I might have a setting wrong). I have "Write to XMP sidecar for readonly item" selected. -- You are receiving this mail because: You are watching all bug changes.
[kolourpaint] [Bug 424354] Program Progressively Slows Down To Point of Being Unusable
https://bugs.kde.org/show_bug.cgi?id=424354 --- Comment #2 from Iain --- Hi Martin, Update on the program slowing down the longer I used Kolourpaint. I uninstalled the Deb package & installed the more recent snap package, and I am not experiencing the slow down, with the bonus, I have more options. Iain ... ***“To the dumb question "Why me?" the cosmos barely bothers to return the reply: why not?”* On Sat, 18 Jul 2020 at 15:43, Martin Koller wrote: > https://bugs.kde.org/show_bug.cgi?id=424354 > > Martin Koller changed: > >What|Removed |Added > > > Status|REPORTED|RESOLVED > Resolution|--- |UPSTREAM > CC||kol...@aon.at > > --- Comment #1 from Martin Koller --- > > Shutting it down and starting again, makes no difference. > > when even this does not help, then it's not the fault of kolourpaint. > > I assume you'll see the same problem with any other program (try with any > other > graphics program like gimp or krita, etc.) > I suggest to try a different graphics driver, since llvmpipe renders in > software. > I'm no expert here but check > https://docs.mesa3d.org/gallium/drivers/llvmpipe.html > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[kolourpaint] [Bug 424354] New: Program Progressively Slows Down To Point of Being Unusable
https://bugs.kde.org/show_bug.cgi?id=424354 Bug ID: 424354 Summary: Program Progressively Slows Down To Point of Being Unusable Product: kolourpaint Version: unspecified Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kolourpaint-supp...@lists.sourceforge.net Reporter: iain.bon...@gmail.com Target Milestone: --- SUMMARY After starting Kolourpaint for the first time, it's quick and responsive, but after using it for an hour it is noticeably slow to respond, this continues until you reach a point at which it's unusable. Shutting it down and starting again, makes no difference. The only solution is to restart my pc. Logging out and back in has no effect. STEPS TO REPRODUCE 1. extended use, an hour is more than enough. 2. 3. OBSERVED RESULT Takes anything up to a minute to switch function, i.e. change from line drawing to circle drawing. EXPECTED RESULT Should switch function within seconds SOFTWARE/OS VERSIONS Ubuntu 18.04 LTS Processor: AMD® Ryzen 3 2200g with radeon vega graphics × 4 Graphics: llvmpipe (LLVM 10.0.0, 256 bits) Gnome 3.28.2 OS: 64 bit Memory: 16GB ADDITIONAL INFORMATION Kolourpaint version: 17.12.3 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 424049] After the import, some metadata was not read from the image.
https://bugs.kde.org/show_bug.cgi?id=424049 --- Comment #5 from iain --- Maik - "Item-> Reread Metadata From File". This fixed the issue. Thanks! "My guess is that the file is blocked by another program during the scanning process and digiKam cannot read the metadata." - I'd agree. Gilles - I've developed application on Windows for years that aren't in the windows store and never seen them denied access to files, once you have said they can run. Files being locked is definitely a problem, in fact I used to see this in Lightroom before I switched to Digikam :-) Thanks you both for your help. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 424049] New: Date is coming from CreatedDate rather than Exif date on some images
https://bugs.kde.org/show_bug.cgi?id=424049 Bug ID: 424049 Summary: Date is coming from CreatedDate rather than Exif date on some images Product: digikam Version: 7.0.0 Platform: MS Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Metadata-Date Assignee: digikam-bugs-n...@kde.org Reporter: iain+...@cardnell.co.uk Target Milestone: --- Created attachment 130013 --> https://bugs.kde.org/attachment.cgi?id=130013&action=edit Screenshots and image SUMMARY On some images Digikam is not recognizing the date from the metadata and instead defaulting to the Created Date. This results in: 1. Image being grouped into the wrong month in thumbnail view (see screenshot) 2. Image not being renamed correctly when renaming based on `[date]` STEPS TO REPRODUCE Attached example which produces this behaviour on my computer. This photo was taken on 20-June but imported onto the computer on 09-July. OBSERVED RESULT When grouping by month the image is listed under July When renaming by date, the date chosen is 2020-07-09 (I named the file manually to get the correct date) EXPECTED RESULT When grouping by month the image is listed under June When renaming by date, the date chosen is 2020-06-20 SOFTWARE/OS VERSIONS Windows: 10 Digikam 7.0.0-rc ADDITIONAL INFORMATION - I believe this is a digikam problem. exiv2 reports the correct date (see attached screenshot) - I haven't been able to determine what is the problem with this image. I have other examples taken on the same day with the same camera that are dated correctly. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 397440] Add possibility to store originals and previous versions in a sub-directory
https://bugs.kde.org/show_bug.cgi?id=397440 iain changed: What|Removed |Added CC||iain+...@cardnell.co.uk --- Comment #1 from iain --- Is this under consideration? I have the same problem where in other applications I have to see the original files before edits. A way to save original files to a sub directory or different folder hierarchy would be really useful. This is a duplicate of https://bugs.kde.org/show_bug.cgi?id=271672. Still valid on 6.4.0 and 7.0.0 beta 2. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 420081] Load and save align points automatically on connect/disconnect for eqmod driver (and others?)
https://bugs.kde.org/show_bug.cgi?id=420081 --- Comment #2 from Iain --- Yes but that would be good to automate, no? Keep up the great work! Iain Sent from my iPhone > On 14 Apr 2020, at 14:55, Jasem Mutlaq wrote: > > https://bugs.kde.org/show_bug.cgi?id=420081 > > --- Comment #1 from Jasem Mutlaq --- > So this is not a KStars bug per se, it's INDI. At any rate, if you go to INDI > Control Panel, and save the points, and disconnect/reconnect, can't you load > them again from the INDI Control Panel? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 420081] New: Load and save align points automatically on connect/disconnect for eqmod driver (and others?)
https://bugs.kde.org/show_bug.cgi?id=420081 Bug ID: 420081 Summary: Load and save align points automatically on connect/disconnect for eqmod driver (and others?) Product: kstars Version: 3.4.1 Platform: Other OS: macOS Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: i...@mrmelville.co.uk Target Milestone: --- SUMMARY Hi Jasem It would be great to load and save the align points automatically - maybe add a button to clear on the align tab as well? Clear would delete all points and save the empty file. Just a thought as I would expect the driver to behave this way (as in EQMOD for example). Great product I am enjoying using it immensely. STEPS TO REPRODUCE 1. Start KStars and connet to INDI with eqmod driver 2. Alignment points are gone from previous session 3. OBSERVED RESULT Have to realign every time you connect EXPECTED RESULT Keep the align points SOFTWARE/OS VERSIONS Windows: macOS: 3.4.1 Build: 2020-02-23T17:20:33Z Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 419908] KStars forgets the time when running for a while
https://bugs.kde.org/show_bug.cgi?id=419908 --- Comment #2 from Iain --- Created attachment 127452 --> https://bugs.kde.org/attachment.cgi?id=127452&action=edit Better attachment showing time drift. I started KStars this morning. It's drifted by nearly 2 hours. Macbook has been closed most of the day. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 419908] KStars forgets the time when running for a while
https://bugs.kde.org/show_bug.cgi?id=419908 --- Comment #1 from Iain --- Created attachment 127420 --> https://bugs.kde.org/attachment.cgi?id=127420&action=edit Screenshot showing start of time drift - 2 seconds compared with system clock -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 419908] KStars forgets the time when running for a while
https://bugs.kde.org/show_bug.cgi?id=419908 Iain changed: What|Removed |Added CC||i...@mrmelville.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 419908] New: KStars forgets the time when running for a while
https://bugs.kde.org/show_bug.cgi?id=419908 Bug ID: 419908 Summary: KStars forgets the time when running for a while Product: kstars Version: 3.4.1 Platform: macOS Disk Images OS: macOS Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: i...@mrmelville.co.uk Target Milestone: --- SUMMARY If I leave kstars running on my mac for a while (maybe a day or two), when I return it often loses several hours. If I do not notice/forget to restart the client and connect to the mount, this messes up the pointing model as kstars is set to update time on everything by default. STEPS TO REPRODUCE 1. Start Kstars on mac 2. Wait/suspend mac - several hours or days 3. Come back and check the time in kstars OBSERVED RESULT Kstars loses time (it always loses time so I suspect some level of suspension is pausing the internal clock). EXPECTED RESULT Kstars should not lose time. SOFTWARE/OS VERSIONS Windows: macOS: 3.4.1 Build: 2020-02-23T17:20:33Z Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Workaround 1 - untick Time from Kstars INDI settings pane - 'Kstars updates all devices' Workaround 2 - Go to time settings and click 'Now' before connecting to INDI Workaround 3 - restart kstars for each session -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 410669] KStars High CPU macOS
https://bugs.kde.org/show_bug.cgi?id=410669 Iain changed: What|Removed |Added CC||i...@mrmelville.co.uk --- Comment #6 from Iain --- I also see this issue. Mostly when images are being received as a remote client. Minimising kstars reduces the load significantly. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 394576] Video preview screen freezes only audio
https://bugs.kde.org/show_bug.cgi?id=394576 --- Comment #1 from Iain Sykes --- It started working for a while, but now exactly the same thing has happened. Any ideas? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 394576] New: Video preview screen freezes only audio
https://bugs.kde.org/show_bug.cgi?id=394576 Bug ID: 394576 Summary: Video preview screen freezes only audio Product: kdenlive Version: 18.04.1 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: i...@iainsykes.co.uk Target Milestone: --- Hi, This has just started happening, I'm using Windows 10 64 bit edition. The video preview screen will play the video and audio of the first clip on my timeline, but if you then drag the timeline bar to another clip, it will only play the audio and not the video of the other clip, almost like the preview screen has frozen. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374684] New: Crash in Digikam when importing from SD card via reader
https://bugs.kde.org/show_bug.cgi?id=374684 Bug ID: 374684 Summary: Crash in Digikam when importing from SD card via reader Product: digikam Version: 5.2.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: digikam-de...@kde.org Reporter: r...@doctors.org.uk Target Milestone: --- Application: digikam (5.2.0) Qt Version: 5.6.1 Frameworks Version: 5.26.0 Operating System: Linux 4.4.36-8-default x86_64 Distribution: "openSUSE Leap 42.2" -- Information about the crash: digikam 5.2.0 starts fine, but whenever I attempt to import photos from SD or CF cards via my USB 3.0 reader it crashes The crash can be reproduced every time. -- Backtrace: Application: digiKam (digikam), signal: Bus error Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fb3b053f9c0 (LWP 4981))] Thread 17 (Thread 0x7fb257fff700 (LWP 5051)): [KCrash Handler] #6 0x7fb3ab934fc0 in __memmove_ssse3 () at /lib64/libc.so.6 #7 0x7fb3a7558553 in Exiv2::DataValue::read(unsigned char const*, long, Exiv2::ByteOrder) () at /usr/lib64/libexiv2.so.14 #8 0x7fb3a754b4cc in Exiv2::Internal::TiffReader::readTiffEntry(Exiv2::Internal::TiffEntryBase*) () at /usr/lib64/libexiv2.so.14 #9 0x7fb3a7536187 in Exiv2::Internal::TiffDirectory::doAccept(Exiv2::Internal::TiffVisitor&) () at /usr/lib64/libexiv2.so.14 #10 0x7fb3a754158c in Exiv2::Internal::TiffParserWorker::parse(unsigned char const*, unsigned int, unsigned int, Exiv2::Internal::TiffHeaderBase*) () at /usr/lib64/libexiv2.so.14 #11 0x7fb3a7541633 in Exiv2::Internal::TiffParserWorker::decode(Exiv2::ExifData&, Exiv2::IptcData&, Exiv2::XmpData&, unsigned char const*, unsigned int, unsigned int, void (Exiv2::Internal::TiffDecoder::*(*)(std::string const&, unsigned int, Exiv2::Internal::IfdId))(Exiv2::Internal::TiffEntryBase const*), Exiv2::Internal::TiffHeaderBase*) () at /usr/lib64/libexiv2.so.14 #12 0x7fb3a74ba16b in Exiv2::Cr2Parser::decode(Exiv2::ExifData&, Exiv2::IptcData&, Exiv2::XmpData&, unsigned char const*, unsigned int) () at /usr/lib64/libexiv2.so.14 #13 0x7fb3a74ba79f in Exiv2::Cr2Image::readMetadata() () at /usr/lib64/libexiv2.so.14 #14 0x7fb3aedd86dd in Digikam::MetaEngine::load(QString const&) const () at /usr/lib64/libdigikamcore.so.5.2.0 #15 0x7fb3aee21076 in Digikam::DMetadata::load(QString const&) const () at /usr/lib64/libdigikamcore.so.5.2.0 #16 0x7fb3aee210f2 in Digikam::DMetadata::DMetadata(QString const&) () at /usr/lib64/libdigikamcore.so.5.2.0 #17 0x7fb3afd811c6 in () at /usr/lib64/libdigikamgui.so.5.2.0 #18 0x7fb3afd5ea15 in Digikam::CameraController::executeCommand(Digikam::CameraCommand*) () at /usr/lib64/libdigikamgui.so.5.2.0 #19 0x7fb3afd60615 in Digikam::CameraController::run() () at /usr/lib64/libdigikamgui.so.5.2.0 #20 0x7fb3ac1fb9e9 in () at /usr/lib64/libQt5Core.so.5 #21 0x7fb3a7fbc734 in start_thread () at /lib64/libpthread.so.0 #22 0x7fb3ab8edd3d in clone () at /lib64/libc.so.6 Thread 16 (Thread 0x7fb2a1ffb700 (LWP 5027)): #0 0x7fb3a7fc1458 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7fb3ac1fc5a8 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib64/libQt5Core.so.5 #2 0x7fb3ac1f89a0 in () at /usr/lib64/libQt5Core.so.5 #3 0x7fb3ac1fb9e9 in () at /usr/lib64/libQt5Core.so.5 #4 0x7fb3a7fbc734 in start_thread () at /lib64/libpthread.so.0 #5 0x7fb3ab8edd3d in clone () at /lib64/libc.so.6 Thread 15 (Thread 0x7fb2a3fff700 (LWP 5022)): #0 0x7fb3a7fc1458 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7fb3ac1fc5a8 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib64/libQt5Core.so.5 #2 0x7fb3ac1f89a0 in () at /usr/lib64/libQt5Core.so.5 #3 0x7fb3ac1fb9e9 in () at /usr/lib64/libQt5Core.so.5 #4 0x7fb3a7fbc734 in start_thread () at /lib64/libpthread.so.0 #5 0x7fb3ab8edd3d in clone () at /lib64/libc.so.6 Thread 14 (Thread 0x7fb320ff9700 (LWP 5000)): #0 0x7fb3a7fc10af in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7fb3a0aae6e3 in () at /usr/lib64/libQt5WebKit.so.5 #2 0x7fb3a0dd0341 in () at /usr/lib64/libQt5WebKit.so.5 #3 0x7fb3a7fbc734 in start_thread () at /lib64/libpthread.so.0 #4 0x7fb3ab8edd3d in clone () at /lib64/libc.so.6 Thread 13 (Thread 0x7fb3217fa700 (LWP 4999)): #0 0x7fb3a7fc10af in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7fb3a0aae6e3 in () at /usr/lib64/libQt5WebKit.so.5 #2 0x7fb3a0dd0341 in () at /usr/lib64/libQt5WebKit.so.5 #3 0x7fb3a7fbc734 in start_thread () at /lib64/libpthread.so.0 #4 0x7fb3ab8edd3d in clone () at /lib64/libc.so.6 Thread 12 (Thread 0x7fb321ffb700 (LWP 499
