Summary: | reproducible crash when bilding fingerprint | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Axel Krebs <axel.krebs> |
Component: | Searches-Similarity | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | axel.krebs, caulier.gilles |
Priority: | NOR | ||
Version: | 1.2.0 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 7.0.0 | |
Sentry Crash Report: |
Description
Axel Krebs
2010-06-12 12:45:22 UTC
- A similar crash happened with previous digiKAM-Version under Ubuntu 9.4 - digikam4.db has 351,5 MB size - thumbnails-digikam.db has 1.2 GB size There is a known crash with panorama images in our scaling code. Just that the code is complicated, I dont even know where the problem is. *** This bug has been marked as a duplicate of bug 207710 *** (In reply to comment #2) > There is a known crash with panorama images in our scaling code. Just that the > code is complicated, I dont even know where the problem is. > > *** This bug has been marked as a duplicate of bug 207710 *** So, if "you dont know where the problem" is (why are you sure for failure-duplicity?): 1.) what would/could be a straight target oriented attempt to exclude wrong, to include possible failure? 2.) can I do further testing on my machine? (In reply to comment #2) > There is a known crash with panorama images in our scaling code. Just that the > code is complicated, I dont even know where the problem is. > > *** This bug has been marked as a duplicate of bug 207710 *** So, if "you dont know where the problem" is (why are you sure for failure-duplicity?): 1.) what would/could be a straight target oriented attempt to exclude wrong, to include possible failure? 2.) can I do further testing on my machine? I can fully reproduce the crash on my computer, in 100% of cases with certain panorama images. dimgscale.cpp is 2000 lines of manually optimized scaling code, without comments of meaningful variable names, not written or completely understood by anyone of us in the team. Probably, a few hours of careful study would be needed to understand and fix what's wrong here. Am 13.06.2010 15:22, schrieb Marcel Wiesweg: > https://bugs.kde.org/show_bug.cgi?id=241536 > > > --- Comment #5 from Marcel Wiesweg<marcel wiesweg gmx de> 2010-06-13 15:22:26 --- > I can fully reproduce the crash on my computer, in 100% of cases with certain > panorama images. > dimgscale.cpp is 2000 lines of manually optimized scaling code, without > comments of meaningful variable names, not written or completely understood by > anyone of us in the team. > Probably, a few hours of careful study would be needed to understand and fix > what's wrong here. > If "only" a few hours where needed to find the failure cause, wouldn't this be worth? It looks to me, dimgscale.cpp might be quite a bottleneck for DigiKam <http://digikam.sourcearchive.com/documentation/2:0.9.2-2ubuntu2/files.html>. --- Question: if hardware is _not_ the reason, makes it sense to narrow the very files: type, versions, sizes e.g.? --- I published my database statistics from DigiKam; the statistic seems complete, but does _not_ distinguish several fine variations: is there a better detailed statistic available? --- I know there are many "dialects" for gif, tif(f), raw (nef, cr2, crw,..) and so on. And I know from an older (cheap) Canon Powershot A710 IS, and, less, from Canon Powershot A720 IS, that these models mistake exif-data (wrong date and time in raw, correct date and time in jpg, e.g.) Besides, exif standard changed themselfes within the last couple of years: <http://de.wikipedia.org/wiki/Exchangeable_Image_File_Format> <http://www.exif.org/specifications.html> So I ask myself, how should DigiKam handle "old" exif-data right? --- I am afraid, I (would like but) cannot helf do programming work. *** Bug 243136 has been marked as a duplicate of this bug. *** Not reproducible using digiKam 7.0.0 beta1. |