Version: 0.10.0-rc2 (rev.: 917004) (using 4.2.00 (KDE 4.2.0), Arch Linux) Compiler: gcc OS: Linux (x86_64) release 2.6.28-ARCH This is grave, you do not really support PNG images as long as this is not fixed. Even after restarting digiKam, the album and its slideshow shows the old, supposedly overwritten files. Where does it get them? Also, it looks like the exif files have gone, but opening in the editor shows them. Are they there or not? I tried to export one of the images to flickr, an that at least exported the new file. There is no exif data in the exported image, though, but that looks like a separate bug. My guess is that the new PNG does have the exif data. But it is a guess :(
Anders, I use PNG evertime in my RAW workflow to save as lossless image my corrected photo. PNG is certainly the better format supported in digiKam (in fact i'm a fan) PNG save EXIF, IPTC and XMP. Gilles Caulier
Hi Gilles, I use PNG too, but it is quite frustrating because of the mysterious behavior. It makes it difficult for me to know where I got to, and in some ways I can not use my images, ie. I can not show them inside digikam after editing them. It does not happen allways, but mostly, and I have not been able to establish a pattern. I convert from raw -> png, then I select an image, makes some adjustments, save, press pgdown in editor. File saved, but digiKam mainwindow refuses to realize that. I'm using trunk from today, but I had the same problem with the latest release.
What the messages from the console ? Gilles Caulier
Here is a sample saving an image, it is not updated in digiKam: digikam(15963)/digikam (core) Digikam::CollectionManager::locationForPath: Testing location 1 "/home/anders/Pictures/RAW/2009-01-31" "/home/anders/Pictures" digikam(15963)/digikam (core) Digikam::DImgInterface::saveAs: Saving to : /home/anders/Pictures/RAW/2009-01-31/H15963.digikamtempfile.tmp ( "PNG" ) digikam(15963)/KEXIV2 KExiv2Iface::KExiv2::setImagePreview: JPEG image preview size: ( 1280 x 853 ) pixels - 120279 bytes digikam(15963)/KEXIV2 KExiv2Iface::KExiv2::setExifThumbnail: Thumbnail temp file: /tmp/kde-anders/digikamT15963KExiv2ExifThumbnail digikam(15963)/digikam (core) Digikam::PNGLoader::writeRawProfile: Writing Raw profile: type= exif , length= 9287 digikam(15963)/digikam (core) Digikam::PNGLoader::writeRawProfile: Writing Raw profile: type= iptc , length= 120344 digikam(15963)/digikam (core) Digikam::PNGLoader::writeRawProfile: Writing Raw profile: type= xmp , length= 2728 digikam(15963)/digikam (core) Digikam::AlbumManager::slotDirWatchDirty: KDirWatch detected change at "/home/anders/Pictures/RAW/2009-01-31" digikam(15963)/digikam (core) Digikam::EditorWindow::slotSavingFinished: renaming to "/home/anders/Pictures/RAW/2009-01-31/2009-01-31T12:12:34-000086.png" digikam(15963)/digikam (core) Digikam::DImg::load: "/home/anders/Pictures/RAW/2009-01-31/2009-01-31T12:12:34-000086.png" : PNG file identified digikam(15963)/digikam (core) Digikam::ThumbnailCreator::loadImagePreview: Use Exif/IPTC preview extraction. Size of image: 1280 x 853 digikam(15963)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation => 1 digikam(15963)/KDCRAW KDcrawIface::KDcraw::loadEmbeddedPreview: Failed to load embedded RAW preview digikam(15963) Digikam::ScanControllerLoadingCacheFileWatch::slotImageChanged: 34067 "/home/anders/Pictures/RAW/2009-01-31/2009-01-31T12:12:34-000086.png" digikam(15963)/digikam (core) Digikam::PreviewLoadingTask::loadImagePreview: Use Exif/IPTC preview extraction. Size of image: 1280 x 853 digikam(15963)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation => 1 digikam(15963)/KDCRAW KDcrawIface::KDcraw::loadEmbeddedPreview: Failed to load embedded RAW preview digikam(15963)/digikam (core) Digikam::PreviewLoadingTask::loadImagePreview: Use Exif/IPTC preview extraction. Size of image: 1280 x 853 digikam(15963)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation => 1 digikam(15963)/digikam (core) Digikam::AlbumManager::slotDirWatchDirty: KDirWatch detected change at "/home/anders/Pictures/RAW/2009-01-31" timeChanged void SunLocator::update()
Nothing special here. All is fine Which Exiv2 library you use ? Which libpng ? Go to Help/components Info for details... Can you send me in private by mail a corrupted PNG file ? Gilles Caulier
Here is the component information: digiKam version 0.10.0-rc2 (rev.: 917004) Exiv2 can write to Jp2: No Exiv2 can write to Jpeg: Yes Exiv2 can write to Png: No Exiv2 can write to Tiff: No Exiv2 support XMP metadata: Yes LibCImg: 129 LibExiv2: 0.17.1 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.2.00 (KDE 4.2.0) LibKExiv2: 0.5.0 LibKdcraw: 0.4.0 LibLCMS: 117 LibPNG: 1.2.34 LibQt: 4.4.3 LibRaw: 0.6.9-Release LibTIFF: LIBTIFF, Version 3.8.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble widget: 0.7 LibGphoto2: 2.4.3 LibKipi: 0.3.0 The libraries are installed by archlinux, which should be resonably well up to date. I will send a png file in a moment, one that i edited but that was not updated in the album view. The PNG file did appear to contain exiv data after conversion, and after loading the changed file into the editor, the exif data appears there too, also after restarting digiKam. I can send too a file that have lost its exif data - after I did exactly the same steps as with the others.
I too use Archlinux, but as a dev I always have the latest libraries from trunk of course. Current Exiv2 is 0.18, but Arch delivers 0.17... this can be the reason.
You can try to modify the /var/abs/extra/exiv2/PKGBUILD file and build your own 0.18 package. Maybe your problems will be gone.
Using Exiv2 0.17 is fine, but i recommend to use 0.18 : PNG metadata can be written on the fly (like JPEG). Change Rating in albumgui, and PNG metadata will be automatically adjusted (I have personally implemented PNG metadata writting mode in Exiv2 library) Gilles Caulier
My Archlinux specs: digiKam version 0.10.0-rc2 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 support XMP metadata: Yes LibCImg: 129 LibExiv2: 0.18 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.2.00 (KDE 4.2.0) LibKExiv2: 0.6.0 LibKdcraw: 0.5.0 LibLCMS: 117 LibPNG: 1.2.34 LibQt: 4.4.3 LibRaw: 0.7.0-Alpha5 LibTIFF: LIBTIFF, Version 3.8.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble widget: pre 0.7 SVN LibGphoto2: 2.4.3 LibKipi: 0.4.0
The absolutely worst problem is that the digikam main view does not update the images, after I save them using the editor. The old files are displayed in the thumbnails, view and slideshow. Where does digikam cache them? Can I delete the cache? In fact I do not know what to do about it. If I rotate them in the main window, they are updated but that is extremely slow, because that needs to load the image. I consider trying to move the images away from digikam, and then reimport them, but it is an absurd workaround. I hope it will work though, since otherwise I do not know what to do.
I cannot see any similar problem on my computer. - Cache is located to ~/.thumnails - Which file system you use to host your collection ? - Look in ~/.xsession-errors if error message appear. - Use F5 in album GUI to refresh thumbs. It works ? Gilles Caulier
I can try to remove .thumbs, but does digiKam cache images for the album view? or use a preview? My filesystem is jfs There are many, many messages from digikam. I do not know what to look for, but I did put a sample in this report, and the image saved in that sequence was *not* updated. F5 does cause digikam to clear and rebuild the thumbs, but it still uses the overwritten image, where can it find that???????
Anders, is maybe all this caused by: > Exiv2 can write to Png: No as you wrote in #c6 above? (Compare with Andi's specs in #c10)
Arnd, no. if PNG is generated by editor, libpng is used and metadata are inserted in PNG file by this way. Exiv2 0.18 is able to writte PNG metadata ont the fly without to re-encode PNG data as libpng do. This is the way used by Caption & Tags for example when you apply comment, rating or keywords. So, with editor, this is not the problem... Gilles
Arnd, Look trace : digikam(15963)/digikam (core) Digikam::PNGLoader::writeRawProfile: Writing Raw profile: type= exif , length= 9287 digikam(15963)/digikam (core) Digikam::PNGLoader::writeRawProfile: Writing Raw profile: type= iptc , length= 120344 digikam(15963)/digikam (core) Digikam::PNGLoader::writeRawProfile: Writing Raw profile: type= xmp , length= 2728 Exif, Iptc and Xmp png metadata chunk are created properlly using libpng Gilles
I can try to update libexiv2, that can not hurt at least. But how can that cause the digikam main view to keep old, nonexisting files????
Moving or copying a changed PNG image inside digikam (to another album) does not work, it insists on keeping the overwritten file. Kinda broken.
Could you please add a function that rereads the image file and updates everything without doing any checks?
Gilles has fixed an important longstanding bug in this area, see bug #151552. I suspect this is your problem - the embedded previews that are taken for thumbnails and preview mode were in a still mysterious way not properly updated. You need current SVN.
Anders, Please, checkout last code from svn and try again. It will be better now. Thanks in advance Gilles Caulier
Hi Gilles, Will do, later tonigt or tomorrow, ASAP! Sounds just good!!
Hi Gilles, This appears to be fixed using latest trunk - very nice!