| Summary: | Thumbnail's album can't be displayed | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | dc |
| Component: | Thumbs-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | caulier.gilles, dc, mitrovicsara, roger.larsson, thorbenk |
| Priority: | HI | ||
| Version: | 1.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.2.0 | |
| Sentry Crash Report: | |||
|
Description
dc
2010-05-12 10:58:20 UTC
Marcel, Another critical entry relevant of DB i think. I can reproduce here... but only with 1.3.0-svn, not 1.2.0... Gilles Caulier It would be nice to have a workaround until it's fixed in the final 1.3.0. I can reproduce this error on many different installations, but all with 1.2.0 (kubuntu 10.4). One of my colleague just installed digikam a few minytes ago... and has the problem too. Daniel I've got a hint... I converted one of my JPG image to a PNG format... and I can see it ! It seems that jpeg images can be made visible. What's wrong with jpeg ? Everything seems to work fine with jpeg images (Lonqueror, Dolphin, Gwneview...) except Digikam... Which constantly complains about an unknown default thumbnail size; despite having its value set in the configuration. Daniel Sound like a problem with libjpeg which have been updated to 8.0 version recently. Perhaps your digiKam binary package have not been recompiled with this version. Since a long time, libjpeg have been frozen to 6.b version (since more than 10 year now). with new release 7.0 and 8.0, binary compatibility have been broken. The only way to check this point is to really recompile digiKam and co, including libkdcraw, libkexiv2, libkipi, and finaly kipi-plugins. Look there for details : http://www.digikam.org/drupal/download/KDE4 Gilles Caulier Gilles: how do you reproduce this problem? The "No thumbnail size specified. Refusing to load thumbnail." has been fixed some time ago in SVN. May be a red herring here. dc: Only JPEG files affected? Marcel, I remember to have seen this messages on the console, about the famous DB lock problem during first run... Now, i confirm that it disappear. Gilles yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy yo se wen i tach leytter box ,writer bord the yyyyyyy tyake over whayyyyyyyyyyyyyyyyyyyyy.somting i bad on compyuter, wen i open it no icon are there. so i can not se if there is problem, it yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyjust blu, bakgrund noting ather. i have tryyyyyyyyyyyyyyyyyyyyyyyyyyy to reset computer . wen i tuch boter yes to restart,computer went black and stop to do comando, turn down,and start up agen.but noting are there. just superperformenc. eee storge boten kl and sos botom,ee pc -tips .yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy 'yyyyyyyyyyyyyyyy yyyyyyyyyyyyyyyyyyyyyyy (In reply to comment #5) > dc: Only JPEG files affected? Yes, I confirm, only JPEG files are affected. I tried to convert a complete directory in PNG and eveything works fine then. I can't really get the SVN/compile version on all affected systems as I don't have access to all of them. Users I know can barely launch KpackageKit... Daniel Marcel, I don't know if you get mails from de bugs.kde.org (as I haven't seen your email in the cc list), but here is what I sent a few minutes ago : Best regards Daniel In reply to comment #5) > dc: Only JPEG files affected? Yes, I confirm, only JPEG files are affected. I tried to convert a complete directory in PNG and eveything works fine then. I can't really get the SVN/compile version on all affected systems as I don't have access to all of them. Users I know can barely launch KpackageKit... Daniel What is your libjpeg version? As Gilles already said, I really suspect a libjpeg incompatibility/problem now that you say only JPEGs are affected. > What is your libjpeg version? Here are the two jpeg libraries installed on my system (and others). libjpeg62 6b-15ubuntu1 libopenjpeg2 1.3+dfsg-4 > As Gilles already said, I really suspect a libjpeg incompatibility/problem > now that you say only JPEGs are affected. I agree, but there is no error/warning at any time. Anyway, which version is really required ? Is this a bad package's dependency ? Daniel OpenJPEG is JPEG2000 library. It's not standard JPEG lib. libjpeg 6b is old version of the famous standard JPEG lib. Are you sure to not have 7.0 or 8.0 version installed on your computer ? Gilles Caulier (In reply to comment #12) > OpenJPEG is JPEG2000 library. It's not standard JPEG lib. OK, but it's installed anyway (certainly used by another application on my system). > libjpeg 6b is old version of the famous standard JPEG lib. Are you sure to not > have 7.0 or 8.0 version installed on your computer ? Yes... That's rather old... But it's the only version I get with the standard repos for kubuntu 10.04. I don't mind messing up my personal system with tarballs or SVN, but I can't really apply this to the other systems I manage. Well... requesting SVN software on production systems is not something I'd like to popularize... :-) Daniel Hi, I've got a few hints... Since there is no error message, I kept thinking... I have thousands of pictures and digikam worked perfectly wit them before, besides, even though the ligjpeg is pretty old, an old lib should be able to handle old picture... No ? I wanted to prove that jpeg picture could still be handled by digikam, but I used a small trick ! I ran the following commands : convert NIK_0037.JPG NIK_0037.jpeg convert NIK_0037.JPG NIK_0037.jpg And... digikam is able to display the thumbnails of NIK_0037.jpeg and NIK_0037.jpg ! It's not simply a matter of suffixes or lower case letters ! It's clearly related to the format of the file. All my Initial files are in format : JPEG image data, EXIF standard 2.21 While, after using the conert command, they are in the following format : JPEG image data, JFIF standard 1.01 This seems to imply that the current digikam/*lib* is unable to handle 'EXIF 2.21' inside a JPG file... The installed library on my system is : libexif12 What do you think about this ? Daniel I am experiencing the same bug. when I do 'convert image.jpg image_converted.jpg', the image I converted with image magick suddenly appears in the digikam album. I also looked at 'identify -verbose image.jpg' and 'image_converted.jpg' and cannot see any meaningful differences: "exif:ExifVersion: 48, 50, 50, 48" is the same for both images. My system is a Gentoo ~amd64 system. The problem is still there with the latest digikam svn (I built the digikam-9999 from the kde git overlay). libkdcraw, libkexiv2, libkipi are from kde 4.5 release candidate. I have the media-libs/jpeg-8b version installed. ldd /usr/bin/digikam | grep jpeg libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fb876632000) Any other information that might be useful? this is also seems to be relevant: http://forums.gentoo.org/viewtopic-t-819004-highlight-digikam.html Thorben, I also use all code from trunk. converting a JPEG file to another one work fine here. libjpeg 8a is also used there (Mandriva 2010.1) Gilles Caulier Daniel, Any news there ? Can you try to use digiKam 1.4.0 ? Gilles Caulier digiKam 1.6.0 is out: http://www.digikam.org/drupal/node/550 Please update and check if this entry still valid. Thanks in advance Gilles Caulier On Wed, 6 Oct 2010 15:27:10 +0200 (CEST) - Gilles Caulier <caulier.gilles@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=237357 >... > Any news there ? Can you try to use digiKam 1.4.0 ? Gilles, sorry for the delay... Yes, the probleme still exist with digikam 1.4.0 and KDE 4.5.4. Daniel ... (:=)))... few day ago, digiKam 1.7.0 is out... please update to last stable and try again. Best Gilles Caulier We need feedback using a recent version. 2.0.0 RC is out, please test... Thanks in advance Gilles Caulier Never seen this bug before but got hurt by it this week. digikam 1.9.0 (OpenSuSE Tumbleweed) Dumping and comparing databases - no clue... Recreating miniatures (simple) - can see the images processing - does not show up after processing... Console output is a bit different - so this might be another problem. IOSlaves does not start... KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. Time elapsed: 10 ms Model: Time elapsed: 0 ms TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms Time elapsed: 0 ms Model: Time elapsed: 0 ms TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms digikam(9896): couldn't create slave: "Kunde inte skapa I/O-slav: Klauncher sa: Fel vid laddning av "kio_digikamdates". " digikam(9896)/digikam (core) Digikam::AlbumManager::slotDatesJobResult: Failed to list dates digikam(9896): couldn't create slave: "Kunde inte skapa I/O-slav: Klauncher sa: Fel vid laddning av "kio_digikamalbums". " digikam(9896)/digikam (core) Digikam::ImageAlbumModel::slotResult: Failed to list url: "Kunde inte starta processen Kunde inte skapa I/O-slav: Klauncher sa: Fel vid laddning av "kio_digikamalbums". ." digikam(9896)/KIPI (general) Plugin_DebianScreenshots::setup: virtual void Plugin_DebianScreenshots::setup(QWidget*) Time elapsed: 1 ms Model: Time elapsed: 0 ms TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms Time elapsed: 0 ms Model: Time elapsed: 0 ms TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms Time elapsed: 1 ms Model: Time elapsed: 0 ms TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms digikam(9896)/digikam (core) Digikam::StateSavingObjectPriv::getGroupFromObjectName: Object name for Digikam::ImagePropertiesSideBarDB(0x46b6310) is empty. Returning the default config group digikam(9896)/digikam (core) Digikam::StateSavingObjectPriv::getGroupFromObjectName: Object name for Digikam::ImagePropertiesSideBarDB(0x4d163e0) is empty. Returning the default config group my comment 23 was some other problem... After logout/login cycle it works again. so, this file can be closed ? Gilles Caulier > --- Comment #25 from Gilles Caulier <caulier gilles gmail com>
> 2011-09-28 10:54:18 ---
> so, this file can be closed ?
Yes... all my old pictures are handled properly.
Thanks
Daniel
|