Version: 0.9.1-rc1 (using KDE KDE 3.5.6) Installed from: Gentoo Packages Compiler: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3) OS: Linux When I load a RAW photo (.CR2 file) to edit it with Digikam, it takes a several minutes whereas the progress bar displays 80% after some seconds but it slows down after 80%. If I load the photo with Gimp/UFRaw, it takes 10-15 seconds.
The progress value used for raw loading is faked, as we do not have any progress information from the dcraw process. (In fact it is works well for my machine ;-) ). It takes so long on your machine that the progress is slowly asymptotically closing to 90%. It is on my TODO list (with very low priority) to make it adapt to the actual speed of the machine. The real question is why dcraw is taking minutes. Do you have a very slow computer?
SVN commit 639734 by cgilles: digiKam from trunk : digiKam 0.9.2 implementation is started with a by change here (:=)) !!! The first new feature is to add a depency to libkdcraw shared library to decode RAW pictures instead to use a dcraw part from digiKam core. libkdcraw include dcraw 8.60 instead the old dcraw 8.41 from digiKam core. It support more recent camera RAW file formats and provide a new wavelet noise reduction filter. If you want more informations about libkdcraw, take a look into my blog : http://www.digikam.org/?q=node/208 To packagers : please update your packages rules about this new depency BUG: 138744 CCBUGS: 142568 M +1 -0 README M +11 -0 configure.in.bot M +28 -0 configure.in.in M +1 -1 digikam/Makefile.am M +4 -1 digikam/albumfiletip.cpp M +5 -2 digikam/albumiconview.cpp M +4 -1 digikam/albumsettings.cpp M +7 -4 digikam/digikamapp.cpp M +4 -1 digikam/digikamview.cpp M +12 -1 digikam/main.cpp M +1 -2 kioslave/Makefile.am M +35 -23 kioslave/digikamalbums.cpp M +7 -4 kioslave/digikamthumbnail.cpp M +1 -1 libs/Makefile.am M +10 -10 libs/dimg/Makefile.am M +9 -6 libs/dimg/dimg.cpp M +6 -3 libs/dimg/dimg.h M +1 -1 libs/dimg/loaders/Makefile.am M +48 -360 libs/dimg/loaders/rawloader.cpp M +18 -52 libs/dimg/loaders/rawloader.h M +0 -167 libs/dimg/rawdecodingsettings.h M +2 -3 libs/dmetadata/Makefile.am M +7 -3 libs/dmetadata/dmetadata.cpp M +1 -1 libs/imageproperties/Makefile.am M +1 -1 libs/imageproperties/imagepropertiescolorstab.cpp M +4 -1 libs/imageproperties/imagepropertiestab.cpp M +1 -2 libs/threadimageio/Makefile.am M +5 -6 libs/threadimageio/loadingdescription.h M +5 -2 libs/threadimageio/previewtask.cpp M +1 -2 showfoto/Makefile.am M +1 -1 showfoto/setup/Makefile.am M +1 -1 showfoto/setup/setup.cpp M +9 -6 showfoto/showfoto.cpp M +1 -2 utilities/cameragui/Makefile.am M +4 -1 utilities/cameragui/cameraui.cpp M +5 -2 utilities/cameragui/umscamera.cpp M +1 -1 utilities/imageeditor/canvas/Makefile.am M +5 -2 utilities/imageeditor/canvas/iofilesettingscontainer.h M +1 -1 utilities/imageeditor/editor/Makefile.am M +6 -7 utilities/imageeditor/editor/editorwindow.cpp M +1 -2 utilities/setup/Makefile.am M +1 -1 utilities/setup/setup.cpp M +14 -12 utilities/setup/setupdcraw.cpp M +1 -1 utilities/setup/setupmime.cpp
Fred, Now digikam (0.9.2) use libkdcraw instead an internal dcraw implementation. dcraw source code verion is 8.60 (instead 8.41). I have improved how the progress bar run in digiKam image editor... But RAW decoding process can take a while, especially in 16 bits color depth. In gimp, 8 bits color depth is only used ! this is not the same thing. Also, check all raw decoding settings, especially the noise reduction witch increase the raw decoding time. Use widgets tooltips for more info in RAW setup page of digiKam Gilles
Actually ufraw can be used as a stand alone tool as well (it works internally as 16 bit as well)... There is a significant difference in loading times... Ufraw can do this because it loads a preview of the raw file which is detailed enough to do colour correction on but not for detailed editing (which it doesn't do)... When the file is saved the proper conversion takes place.... I would say that it largely makes sense to take the same approach in digikam. Digikam doesn't really handle detailed editing in the way that Krita or the Gimp does so having being able to get up to incredibly high levels of detail is usually not necessary... In order to make these changes the editor would have to handle raw files in a fundementally different fashion to other file types... Digikam already generates previews for raw images in the viewer mode... The editor would have to be written to operate the preview image rather than a converted raw file. (for raw files and only raw files) Operations would also be written as a list and saved as a file (or in the database) this operation list would be called upon when converting the file to another file format. A converted file can be used to do more detailed editing (the same way as raw files are handled now) except this would be more consistant because as things stand you can't save a raw file.
Dany, I'm not agree with you. The RAW files are handle in digiKam like a JPEG file as well, excepted of course than the image is in 16 bits color depth... All tool in digiKam support 16 bits color depth. This is why digikam handle the image like this. On my computer, to load a RAW file time around 5 secondes (PIV 3.4Ghz or Laptop double core 1.6Ghz). In other words, if you want to work with RAW files use a fast computer... This problem is the same with Aperture, LightRoom and others program witch handle RAW files. Preview image in RAW file in a simple 8 bits color depth reduced JPEG/PPM/TIFF file. Working on preview in a non sence to edit a RAW picture. Gilles Caulier 7 Mar 2007 06:27:14 -0000, Danni Coy <danni.coy@gmail.com>: [bugs.kde.org quoted mail] Dany, <br><br>I'm not agree with you. The RAW files are handle in digiKam like a JPEG file as well, excepted of course than the image is in 16 bits color depth... All tool in digiKam support 16 bits color depth. This is why digikam handle the image like this. <br><br>On my computer, to load a RAW file time around 5 secondes (PIV 3.4Ghz or Laptop double core 1.6Ghz). In other words, if you want to work with RAW files use a fast computer... This problem is the same with Aperture, LightRoom and others program witch handle RAW files. <br><br>Preview image in RAW file in a simple 8 bits color depth reduced JPEG/PPM/TIFF file. Working on preview in a non sence to edit a RAW picture.<br><br>Gilles Caulier<br><br><div><span class="gmail_quote">7 Mar 2007 06:27:14 -0000, Danni Coy < <a href="mailto:danni.coy@gmail.com">danni.coy@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">------- You are receiving this mail because: ------- <br>You are the assignee for the bug, or are watching the assignee.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=142568">http://bugs.kde.org/show_bug.cgi?id=142568</a><br><br><br><br><br>------- Additional Comments From danni.coy gmail com 2007-03-07 07:27 -------<br>Actually ufraw can be used as a stand alone tool as well (it works internally as 16 bit as well)...<br>There is a significant difference in loading times...<br><br>Ufraw can do this because it loads a preview of the raw file which is detailed enough to do colour correction on but not for detailed editing (which it doesn't do)... When the file is saved the proper conversion takes place.... <br><br>I would say that it largely makes sense to take the same approach in digikam. Digikam doesn't really handle detailed editing in the way that Krita or the Gimp does so having being able to get up to incredibly high levels of detail is usually not necessary... <br><br>In order to make these changes the editor would have to handle raw files in a fundementally different fashion to other file types... Digikam already generates previews for raw images in the viewer mode... The editor would have to be written to operate the preview image rather than a converted raw file. (for raw files and only raw files) Operations would also be written as a list and saved as a file (or in the database) this operation list would be called upon when converting the file to another file format. A converted file can be used to do more detailed editing (the same way as raw files are handled now) except this would be more consistant because as things stand you can't save a raw file. <br>_______________________________________________<br>Digikam-devel mailing list<br><a href="mailto:Digikam-devel@kde.org">Digikam-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/digikam-devel">https://mail.kde.org/mailman/listinfo/digikam-devel </a><br></blockquote></div><br>
SVN commit 683093 by cgilles: libkdcraw from KDE3 branch: update internal dcraw version from 8.60 to 8.76. New digital still camera supported are given below : Apple QuickTake 100 Apple QuickTake 150 Canon PowerShot A630 Canon PowerShot A640 Canon PowerShot A710 IS Canon EOS-1D Mark III Casio QV-R41 Fuji FinePix S5Pro Hasselblad CFV Kodak C330 Mamiya ZD Nikon D2Xs Nikon D40X Olympus E-410 Olympus E-510 Olympus SP510UZ Olympus SP550UZ Panasonic DMC-FZ8 Pentax Optio 750Z Samsung GX-10 Sigma SD14 The current implementation of libkdcraw for KDE3 do not break binary compatibility. RAW decoding settings still the same. Only private methods have been fixed, especally the settings widget. I will break binary compatibility of libkdcraw with KDE4 port where i will add new settings like chromatic aberration correction for ex. CCBUGS: 142568 CCMAIL: kde-imaging@kde.org CCMAIL: digikam-devel@kde.org CCMAIL: ach@mpe.mpg.de CCMAIL: boud@valdyas.org M +21 -0 CAMERALIST M +4 -4 README M +1010 -554 dcraw.c
SVN commit 683107 by cgilles: libkdcraw from trunk (KDE4): update internal dcraw version from 8.60 to 8.76 (backport from KDE3 branch). New digital still camera supported are given below : Apple QuickTake 100 Apple QuickTake 150 Canon PowerShot A630 Canon PowerShot A640 Canon PowerShot A710 IS Canon EOS-1D Mark III Casio QV-R41 Fuji FinePix S5Pro Hasselblad CFV Kodak C330 Mamiya ZD Nikon D2Xs Nikon D40X Olympus E-410 Olympus E-510 Olympus SP510UZ Olympus SP550UZ Panasonic DMC-FZ8 Pentax Optio 750Z Samsung GX-10 Sigma SD14 I will add later new settings like chromatic aberration correction for ex. CCBUGS: 142568 CCMAIL: kde-imaging@kde.org CCMAIL: digikam-devel@kde.org CCMAIL: ach@mpe.mpg.de CCMAIL: boud@valdyas.org M +2 -0 AUTHORS M +6 -0 NEWS M +21 -0 dcraw/CAMERALIST M +1010 -554 dcraw/dcraw.c M +40 -10 dcraw/kdcraw.1 M +42 -34 libkdcraw/dcrawsettingswidget.cpp M +4 -2 libkdcraw/rawdecodingsettings.h
Fred, If i remember your post in Linufr.org entry about photography, i suspect than you use an old computer (slow/small memory). Right ? To perform digital photography, i recommend to use a recent computer (:=))) Gilles
Gilles, I just had a look at this thread: indeed having a faster computer helps a lot (I still remember how much slower digikam felt on a PIII with 1.2 GHz), however, I like the approach taken by ufraw (as discussed by Dany #4) because it is really fast for interactive usage (the actual save itself then takes of course longer). On the other hand, a solution like in #4 sounds non-trivial to implement ... Best, Arnd
> To perform digital photography, i recommend to use a recent computer (:=))) And, now, it's the case (Core 2 Quad 2.4GHz + 2 Go RAM) :-) But, about RAW files, now, I'm using Bibble which is better for color management and white balance management in 16-bit. But, I'm still using Digikam for albums management and to make small modifications (like noise, crop or B&W). I think, you can close this report as it's not a Digikam problem (or you have to change the Digikam philosophy for solution #4 like Gimp or Bibble ;-)
I have a fast PC (Athlon X64 DualCore 4800+ with 4GB RAM and a RAID5) but the problem is an other: LightZone works with JPEGs and execute the manipulations later on the RAW. It would be great, if digikam can do it in the same way.
As a lots of work have be done here, especially to : - port libkdcraw to libraw (http://www.libraw.org) instead to use dcraw. - use multithreading instead a process: initialization is faster, fork to another CPU is better managed. - support of libgomp to parallelize demosaicing. - code factorize and simplification everywhere when it's possible. All these remark are true for KDE3 and KDE4 version of libkdcraw. To resume : all future speedup improvements will be done in libraw, not in libkdcraw. I close this file now. Gilles Caulier