Version: 1.4.0 (using KDE 4.5.1) OS: Linux When using the auto-lens correction, this tool doesn`t recognize the very lens always correctly. In one special case (panorama-like images), it does not recognize anything. IDEA: if there were profiles, one could use thes profiles to overcome this gap indirectly: the tooljust hats to know, which lens was mounted for a picture. Besides, if there are several digicams in use, each of these could get its own profile. Even in the case, that several photographers worked in one business, one could personalize everones need. Reproducible: Always Actual Results: in many case up the 40% wrong contribution of lenses to pics (and vice versa). Expected Results: Hope for better "fit" between auto-lens correction and the selected lens-profile.
With digiKam 1.5.0, lensfun is included in digiKam core. The last code from svn trunk of lensfun project... I recommend to test this version, where lens database have been improved... Anyway, for your request, it's a wish for lensfun project, not digiKam Gilles Caulier
Actually it is also for digiKam. From my understanding of this wish, you create a Camera profile, which will be globaly used in digiKam (although there is currently no other use than the lensfun) and that profile would set some kind of lens related settings automatically, for example the correct lens type. Then if you want to work with set of images taken by another lens, you simply switch the profile and all the settings are then adjusted. It is an interesting idea...
that is my basic intention.
What would information about the lens used being available in Digikam achieve that is not achieved by adding camera and lens profiles to lensfun?
I guess you mean I want to produce superflous information? Please keep in mind my intention, described at the very beginning: DK does _not_ always recognize lenses and camera types correctly (compared to the enormous amount of existing type I would wander about, if)) Instead of of slowly searching the stored database, I suggested to use predefined individual sets of lenses/camera(s). In this case it should be easier for DK to guess, if it deals with profile I, profile II and so on. I believe, it is a matter of time, ressources and, even more important, reliablity. I hope I could explain my wish
Axel, This file still valid using digiKam 2.x serie ? Gilles Caulier
Am 17.12.2011 20:24, schrieb Gilles Caulier: > https://bugs.kde.org/show_bug.cgi?id=256466 > > > > > > --- Comment #6 from Gilles Caulier <caulier gilles gmail com> 2011-12-17 19:24:23 --- > Axel, > > This file still valid using digiKam 2.x serie ? > > Gilles Caulier > Gilles, As much as I can see up to digiKam V. 2.1, my wish still applies. Axel
Git commit 6b07fcfc298729a5a05ffd9a4ef6f428e43b30e3 by Gilles Caulier. Committed on 08/01/2013 at 10:21. Pushed by cgilles into branch 'master'. Remove internal LensFun library code and xml lens database. Set only an optional and external dependency to last 0.2.6 release. This will spimply internal code and maintainance. Related: bug 311295 M +36 -58 CMakeLists.txt M +1 -0 NEWS M +47 -39 cmake/modules/FindLensFun.cmake M +0 -1 data/CMakeLists.txt D +0 -90 data/lensfun/6x6.xml D +0 -3 data/lensfun/CMakeLists.txt D +0 -5 data/lensfun/README D +0 -1261 data/lensfun/compact-canon.xml D +0 -204 data/lensfun/compact-casio.xml D +0 -614 data/lensfun/compact-fujifilm.xml D +0 -31 data/lensfun/compact-kodak.xml D +0 -347 data/lensfun/compact-konica-minolta.xml D +0 -81 data/lensfun/compact-leica.xml D +0 -586 data/lensfun/compact-nikon.xml D +0 -465 data/lensfun/compact-olympus.xml D +0 -423 data/lensfun/compact-panasonic.xml D +0 -178 data/lensfun/compact-pentax.xml D +0 -110 data/lensfun/compact-ricoh.xml D +0 -48 data/lensfun/compact-sigma.xml D +0 -702 data/lensfun/compact-sony.xml D +0 -106 data/lensfun/generic.xml D +0 -187 data/lensfun/mil-olympus.xml D +0 -122 data/lensfun/mil-panasonic.xml D +0 -83 data/lensfun/mil-samsung.xml D +0 -55 data/lensfun/mil-sony.xml D +0 -154 data/lensfun/rf-leica.xml D +0 -1282 data/lensfun/slr-canon.xml D +0 -36 data/lensfun/slr-contax.xml D +0 -31 data/lensfun/slr-hasselblad.xml D +0 -106 data/lensfun/slr-konica-minolta.xml D +0 -1110 data/lensfun/slr-nikon.xml D +0 -326 data/lensfun/slr-olympus.xml D +0 -17 data/lensfun/slr-panasonic.xml D +0 -419 data/lensfun/slr-pentax.xml D +0 -30 data/lensfun/slr-samsung.xml D +0 -45 data/lensfun/slr-schneider.xml D +0 -497 data/lensfun/slr-sigma.xml D +0 -317 data/lensfun/slr-sony.xml D +0 -285 data/lensfun/slr-tamron.xml D +0 -108 data/lensfun/slr-tokina.xml D +0 -136 data/lensfun/slr-ussr.xml M +1 -1 digikam/utils/config-digikam.h.cmake M +3 -3 imageplugins/enhance/CMakeLists.txt M +2 -2 imageplugins/enhance/imageplugin_enhance.cpp D +0 -25 libs/3rdparty/lensfun/README D +0 -620 libs/3rdparty/lensfun/auxfun.cpp D +0 -100 libs/3rdparty/lensfun/camera.cpp D +0 -44 libs/3rdparty/lensfun/config-lensfun.cpp D +0 -32 libs/3rdparty/lensfun/config-lensfun.h D +0 -168 libs/3rdparty/lensfun/cpuid.cpp D +0 -1293 libs/3rdparty/lensfun/database.cpp D +0 -1646 libs/3rdparty/lensfun/lens.cpp D +0 -2165 libs/3rdparty/lensfun/lensfun.h D +0 -539 libs/3rdparty/lensfun/lensfunprv.h D +0 -369 libs/3rdparty/lensfun/mod-color.cpp D +0 -1167 libs/3rdparty/lensfun/mod-coord.cpp D +0 -350 libs/3rdparty/lensfun/mod-subpix.cpp D +0 -163 libs/3rdparty/lensfun/modifier.cpp D +0 -73 libs/3rdparty/lensfun/mount.cpp M +5 -7 libs/dialogs/libsinfodlg.cpp M +1 -1 libs/dimg/filters/dimgfiltermanager.cpp M +7 -7 libs/dimg/filters/lens/lensfuniface.cpp M +6 -6 libs/dimg/filters/lens/lensfuniface.h M +2 -2 tests/CMakeLists.txt M +2 -2 utilities/queuemanager/CMakeLists.txt M +2 -2 utilities/queuemanager/manager/batchtoolsmanager.cpp http://commits.kde.org/digikam/6b07fcfc298729a5a05ffd9a4ef6f428e43b30e3
Alex, In First, happy new year... 1/ digiKam now depand at least of LensFun 0.2.6. 2/ Back from your original post, i suspect that Lens information from metadata are not preserved by Panorama tool during assembling. 3/ It's probably the same problem with ExpoBlending tool, which assemble image together (can you confirm please) I re-assign this entry to Panorama tool about metadata preservation. Note that if you try to apply a lens correction to a un-assembled shot from your pano serie, and if camrea/lens is not recognized, it's probably a lensfun database problem. Gilles Caulier
Gellis, Thank you happy New Years! Thank for Info! Axel P.S.: NOT "Alex"... Am 08.01.2013 10:31, schrieb Gilles Caulier: > https://bugs.kde.org/show_bug.cgi?id=256466 > > --- Comment #9 from Gilles Caulier <caulier.gilles@gmail.com> --- > Alex, > > In First, happy new year... > > 1/ digiKam now depand at least of LensFun 0.2.6. > 2/ Back from your original post, i suspect that Lens information from metadata > are not preserved by Panorama tool during assembling. > 3/ It's probably the same problem with ExpoBlending tool, which assemble image > together (can you confirm please) > > I re-assign this entry to Panorama tool about metadata preservation. > > Note that if you try to apply a lens correction to a un-assembled shot from > your pano serie, and if camrea/lens is not recognized, it's probably a lensfun > database problem. > > Gilles Caulier >
First of all, happy new year to all. I will only address the problem of panorama images and expoblending output. When Hugin (and therefore the panorama plugin) (and any other panorama stitching program) stitches images, it finds the right lens correction to apply to the photos before stitching them. So apply lens correction on a panorama made by stitching photos doesn't make sense. More specifically, lens correction parameters of lensfun are found by stitching adjacent photos with Hugin and extracting from this process the parameters. As for the expoblending tool, this is not true because images are stacked (instead of stitched), hence there is no lens correction, and metadata about the lens should be preserved in order to be used by lensfun for further lens correction. Gilles: as a consequence this bug has nothing to do with panorama.
Benjamin, I agree about the non-sense to use Lensfun after Panorama. But it's have a sense to found original Lens information in target image metadata. In fact all camera capture info must be transferred or preserved to target pano image. It's really the case ? Anyway this file must be moved to ExpoBlending tool later... Gilles
I see your point and I partly agree in the case of a panorama. Using the same metadata about the lens and camera for both regular photos and the result of a stitching will result in lensfun applying lens correction which doesn't make sense. That's why I would rather have different metadata for the lens and camera identification in the panorama. As for other metadata such as aperture / exposure time / ISO (and maybe other), it's just impossible to put this in the final panorama because of possible differences between images (although for very good results, those should be identical, it's not always possible to fix those parameters, e.g. with a compact or a phone). I guess I can add a checkbox to allow the user to copy those data, though. Note that this last argument about aperture / exposure time / ISO also apply to expoblending. Anyway, I would rather have a separate bug in the bugzilla for this because the current title doesn't correspond to the current issue...
Git commit a6f2ee48a668d18f5fa30bfa6314de93b1f8bd6c by Gilles Caulier. Committed on 30/07/2014 at 20:16. Pushed by cgilles into branch 'master'. Panoram tool : if GPS info exists in original images which are stiched, plug these info in target pano image. M +3 -3 panorama/importwizard/importwizarddlg.cpp M +5 -4 panorama/importwizard/lastpage.cpp M +7 -3 panorama/importwizard/lastpage.h M +24 -2 panorama/tasks/copyfilestask.cpp M +0 -1 panorama/tasks/copyfilestask.h http://commits.kde.org/kipi-plugins/a6f2ee48a668d18f5fa30bfa6314de93b1f8bd6c
Git commit fe279dc1be18b57854fae4476f2a10e7c4cc9c7f by Gilles Caulier. Committed on 02/08/2014 at 05:10. Pushed by cgilles into branch 'master'. Panorama Tool : Store common metadata info as ExpoBlending tool M +60 -29 panorama/tasks/copyfilestask.cpp http://commits.kde.org/kipi-plugins/fe279dc1be18b57854fae4476f2a10e7c4cc9c7f diff --git a/panorama/tasks/copyfilestask.cpp b/panorama/tasks/copyfilestask.cpp index 0e4f51c..66db952 100644 --- a/panorama/tasks/copyfilestask.cpp +++ b/panorama/tasks/copyfilestask.cpp @@ -44,49 +44,31 @@ CopyFilesTask::CopyFilesTask(QObject* parent, const KUrl& workDir, const KUrl& p const KUrl& ptoUrl, const ItemUrlsMap& urls, bool savePTO, bool addGPlusMetadata) : Task(parent, COPY, workDir), panoUrl(panoUrl), finalPanoUrl(finalPanoUrl), ptoUrl(ptoUrl), urlList(&urls), savePTO(savePTO), addGPlusMetadata(addGPlusMetadata) -{} +{ +} CopyFilesTask::CopyFilesTask(const KUrl& workDir, const KUrl& panoUrl, const KUrl& finalPanoUrl, const KUrl& ptoUrl, const ItemUrlsMap& urls, bool savePTO, bool addGPlusMetadata) : Task(0, COPY, workDir), panoUrl(panoUrl), finalPanoUrl(finalPanoUrl), ptoUrl(ptoUrl), urlList(&urls), savePTO(savePTO), addGPlusMetadata(addGPlusMetadata) -{} +{ +} CopyFilesTask::~CopyFilesTask() -{} +{ +} void CopyFilesTask::run() { - QFile panoFile(panoUrl.toLocalFile()); - QFile finalPanoFile(finalPanoUrl.toLocalFile()); + QFile panoFile(panoUrl.toLocalFile()); + QFile finalPanoFile(finalPanoUrl.toLocalFile()); QFileInfo fi(finalPanoUrl.toLocalFile()); - KUrl finalPTOUrl(finalPanoUrl); + KUrl finalPTOUrl(finalPanoUrl); finalPTOUrl.setFileName(fi.completeBaseName() + ".pto"); - QFile ptoFile(ptoUrl.toLocalFile()); - QFile finalPTOFile(finalPTOUrl.toLocalFile()); - kDebug() << "Copying GPS info..."; - - // Find first src image which contain geolocation and save it to target pano file. - - double lat, lng, alt; - - for (ItemUrlsMap::const_iterator i = urlList->constBegin(); i != urlList->constEnd(); ++i) - { - kDebug() << i.key(); - - KPMetadata metaSrc(i.key().toLocalFile()); - - if(metaSrc.getGPSInfo(alt, lat, lng)) - { - kDebug() << "GPS info found and saved in " << panoUrl; - KPMetadata metaDst(panoUrl.toLocalFile()); - metaDst.setGPSInfo(alt, lat, lng); - metaDst.applyChanges(); - break; - } - } + QFile ptoFile(ptoUrl.toLocalFile()); + QFile finalPTOFile(finalPTOUrl.toLocalFile()); if (!panoFile.exists()) { @@ -95,6 +77,7 @@ void CopyFilesTask::run() successFlag = false; return; } + if (finalPanoFile.exists()) { errString = i18n("A file named %1 already exists.", finalPanoUrl.fileName()); @@ -102,6 +85,7 @@ void CopyFilesTask::run() successFlag = false; return; } + if (savePTO && !ptoFile.exists()) { errString = i18n("Temporary project file does not exist."); @@ -109,6 +93,7 @@ void CopyFilesTask::run() successFlag = false; return; } + if (savePTO && finalPTOFile.exists()) { errString = i18n("A file named %1 already exists.", finalPTOUrl.fileName()); @@ -116,8 +101,51 @@ void CopyFilesTask::run() successFlag = false; return; } + + kDebug() << "Copying GPS info..."; + + // Find first src image which contain geolocation and save it to target pano file. + + double lat, lng, alt; + + for (ItemUrlsMap::const_iterator i = urlList->constBegin(); i != urlList->constEnd(); ++i) + { + kDebug() << i.key(); + + KPMetadata metaSrc(i.key().toLocalFile()); + + if(metaSrc.getGPSInfo(alt, lat, lng)) + { + kDebug() << "GPS info found and saved in " << panoUrl; + KPMetadata metaDst(panoUrl.toLocalFile()); + metaDst.setGPSInfo(alt, lat, lng); + metaDst.applyChanges(); + break; + } + } + + // Restore usual and common metadata from first shot. + + KPMetadata metaSrc(urlList->constBegin().key().toLocalFile()); + KPMetadata metaDst(panoUrl.toLocalFile()); + metaDst.setIptc(metaSrc.getIptc()); + metaDst.setXmp(metaSrc.getXmp()); + metaDst.setXmpTagString("Xmp.tiff.Make", metaSrc.getExifTagString("Exif.Image.Make")); + metaDst.setXmpTagString("Xmp.tiff.Model", metaSrc.getExifTagString("Exif.Image.Model")); + + QString filesList; + + for (ItemUrlsMap::const_iterator i = urlList->constBegin(); i != urlList->constEnd(); ++i) + filesList.append(i.key().fileName() + " ; "); + + filesList.truncate(filesList.length()-3); + + metaDst.setXmpTagString("Xmp.kipi.PanoramaInputFiles", filesList, false); + metaDst.setImageDateTime(QDateTime::currentDateTime()); + metaDst.applyChanges(); kDebug() << "Copying panorama file..."; + if (!panoFile.copy(finalPanoUrl.toLocalFile()) || !panoFile.remove()) { errString = i18n("Cannot move panorama from %1 to %2.", @@ -143,6 +171,7 @@ void CopyFilesTask::run() if (savePTO) { kDebug() << "Copying project file..."; + if (!ptoFile.copy(finalPTOUrl.toLocalFile())) { errString = i18n("Cannot move project file from %1 to %2.", @@ -153,6 +182,7 @@ void CopyFilesTask::run() } kDebug() << "Copying converted RAW files..."; + for (ItemUrlsMap::const_iterator i = urlList->constBegin(); i != urlList->constEnd(); ++i) { if (KPMetadata::isRawFile(i.key())) @@ -160,6 +190,7 @@ void CopyFilesTask::run() KUrl finalImgUrl(finalPanoUrl); finalImgUrl.setFileName(i->preprocessedUrl.fileName()); QFile imgFile(i->preprocessedUrl.toLocalFile()); + if (!imgFile.copy(finalImgUrl.toLocalFile())) { errString = i18n("Cannot copy converted image file from %1 to %2.",