When creating a panorama, the date/hour of the resulting image should be the same than the one of the images used to create the panorama. That was the behaviour previously. However, in digikam 4.6.0, it seems that the date/hour is now the date of creation of the panorama. Reproducible: Always Steps to Reproduce: 1. Create a panorama 2. Check date/hour 3. Actual Results: The date is the creation of the panorama Expected Results: Date at wich the image has been taken
Do you talk about file time stamp or metadata date tags ? Gilles Caulier
Hello, I do not know exactly what is the difference, but I mean the «date created» value used in the exif and iptc fields, which is also used by digikam to sort the image by date in the display. Previously, when we created a panorama, it was dated and displayed with the original images, and now it is dated at the creation time, and therefore (if images are sorted by date) is displayed at the top of the page, and no more with the original images. The date then needs to be set manually...
Metadata can be enough. We have a method in KPMetadata to set same date everywhere (Exif, IPTC, and XMP) Gilles Caulier
Created attachment 92728 [details] patch to set metadata time-stamp to pano file Benjamin, This simple patch set date to metadata of target pano using first image from sets of stitched photos. Done against KDE4 code, and can be backported as well to KF5 port Gilles Caulier
Git commit dee9052c91e773b4992bc691c670d888f8a188f4 by Gilles Caulier. Committed on 30/05/2015 at 22:01. Pushed by cgilles into branch 'master'. apply patch #92728 to set date time-stamp to target file with original first file of set images used to make pano. FIXED-IN : 4.11.0 M +1 -0 panorama/tasks/copyfilestask.cpp http://commits.kde.org/kipi-plugins/dee9052c91e773b4992bc691c670d888f8a188f4
Hello, I change the status to «unconfirmed», as in digikam 4.11 under Ubuntu, it does not work. The panorama now has the tags from the pictures it is made, which is fine, but the panorama timestamp is still the creation date, and not the date at which the pictures where taken.
Note that there are specific XMP properties for panorama images. exiv2 0.25 supports these properties: http://www.exiv2.org/tags-xmp-GPano.html Specification is here: https://developers.google.com/photo-sphere/metadata/
Hello Alan, thanks for this informations. It is convenient, as currently digikam stores some of the panorama information (fov, projection, number of images, etc...) in the «Description»/«Legend» field, in a text format, which is not really usable. However, concerning the date, I see that this xmp properties can store the date of the first/last image used for the pano, but it does not say what is the date assigned to the resulting pano. In my sense, the pano must be at the same date than the images it is made from. It is how it was working previously, and when sorted by date, the pano and the images where displayed side to side. I think that «processing» individual images to create a pano is like processing them in Photoshop. The creation date must be kept, and the modification date is updated. T
(In reply to Alan Pater from comment #7) > Note that there are specific XMP properties for panorama images. > > exiv2 0.25 supports these properties: > http://www.exiv2.org/tags-xmp-GPano.html > > Specification is here: https://developers.google.com/photo-sphere/metadata/ Google did indeed publish a panorama-oriented XMP namespace. However (and I stress here the however), this was not meant as a standard. This is merely a namespace meant to ease the 3D rendering of a panorama by Google's javascript API, and initially implemented in Android's photo app. From my point of view, and what I read of your discussion on the Digikam-users ML, there is a need to be clear on the meaning of all dates in the tags supported by exiv2 (meaning exif, iptc, and xmp). The extra tags describing the parameters of a panorama is a far more complex question since there is no standard. I tried a few month back to fill out the GPano XMP namespace and make it work this Google API, without success (its still on my todo list though). On a side note, the plugin panorama is heavily relying on Hugin to do the computations and process the final image, including filling out the exif/iptc/xmp tags. Phillipe: If you process your panorama solely with Hugin, how does the date show up in digiKam? is it the one you expected? (In reply to philippe.quaglia from comment #8) > [...] currently > digikam stores some of the panorama information (fov, projection, number of > images, etc...) in the «Description»/«Legend» field, in a text format, which > is not really usable. This is set by Hugin. > In my sense, the pano must be at the same date than the images it is made from. There is no such "same date", but rather "one of the date". This was the aim of the patch from Gilles (pick one date of the original images and copy it to the stitched image). Did you try stitching a new panorama since the version 4.11.0? was the date showing up correct?
Hello Benjamin, thanks for your input. To answer your questions, i did a test with Digikam 4.12 using 3 pictures, taken the 02/08/15 19h03. I did the panorama with Digikam, and the assigned date is the creation date, i.e. 14/08/15 9h24. I did the panorama with Hugin, and I get the same result. See the screen copy, with original picture with their date, and the pano, the one in blue created by digikam, the one on left by Hugin. I'm sure that previously, Digikam was assigning the date of the source pictures, i.e. 02/08/15 19h03 in that case. For picture sorting and grouping, it is really annoying to have different time, the pano is never displayed next to the original picture, and I need to manually change the date.
Created attachment 94027 [details] Screen copy, original pictures, with date
Created attachment 94028 [details] Screen copy, panos, the one in blue is digikam (note the legend line) the other one is hugin. See the attached date.
Thanks for the tests. As far as I know, there hasn't been any modification in the panorama plugin code source dealing with date and time metdata for a while (except for Gilles' commit). On the other hand, it's possible that Hugin is handling them differently than before. Which version of Hugin have you installed? I'm sure there is a possible fix in the plugin to sort out everything. For now, I really don't have the time to do it (maybe in late October, or November, but not sooner). If anyone is interested, anything relevant is in panorama/tasks/copyfilestask.cpp.
Hello Benjamin, my version of Hugin is: Version : 2014.0.0.5da69bc383dd I just see that version 2015 has been released few days ago. I will try to update it and redo some tests. I'm sorry I'm of no use for programming/resolving bugs. Best regards.
Unfortunately Hugin 2015.0 changed a few things and is not compatible with the panorama plugin at the moment. This is another task on my todo list that will have to wait...
I've been off line for the last while, but now have some additional comments. I think the resulting pano image should follow MWG guidelines for the date: Date/time original: When the image was taken. Date/time digitized: Same as original for images taken with a digital camera. Date/time modified: When the the image was modified. This would be the date that the original images were stitched together. Is the Date/time original data being erased when creating the pano image? http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=37
Thanks for the info Alan. I think that the KExiv2 API is not complete enough to correctly handle all those date and time. At the moment there is only those two functions: - KExiv2::getImageDateTime - KExiv2::setImageDateTime The first one tries to get a useable date/time entry (I haven't checked the priority), and the second one writes a provided date/time to original and modified (and optionally digitized). Threrefore, KExiv2 does not provide the API to make the proper distinction between those three classes of date/time. I don't mind doing it, but that will have to wait (if anyone is interested, go ahead ;o) )
Hello, I confirm that after updating Hugin to the latest release, Digikam panorama plugin does not work anymore. Also, the new Hugin still stamped the panorama with the date of the panorama creation, not the date at which the images where taken.
To comment #6 : I found the problem with the date. It's a stupid line hadcoded in source with assign pano date to target file and later creation date. See my commit : http://commits.kde.org/kipi-plugins/3438a50e290bd234c0373217f011e1dddd6d344a .. into panorama/tasks/copyfilestask.cpp // 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")); - metaDst.setImageDateTime(metaSrc.getImageDateTime(), true); <<== Right one + if (m_meta) + { + m_meta->load(urlList->constBegin().key()); + QByteArray iptc = m_meta->getIptc(); + QByteArray xmp = m_meta->getXmp(); + QString make = m_meta->getExifTagString(QLatin1String("Exif.Image.Make")); + QString model = m_meta->getExifTagString(QLatin1String("Exif.Image.Model")); + QDateTime dt = m_meta->getImageDateTime(); <<== Moved here !!!! + + m_meta->load(panoUrl); + m_meta->setIptc(iptc); + m_meta->setXmp(xmp); + m_meta->setXmpTagString(QLatin1String("Xmp.tiff.Make"), make); + m_meta->setXmpTagString(QLatin1String("Xmp.tiff.Model"), model); + m_meta->setImageDateTime(dt); <<== and here !!!! + + QString filesList; ... - metaDst.setXmpTagString("Xmp.kipi.PanoramaInputFiles", filesList, false); - metaDst.setImageDateTime(QDateTime::currentDateTime()); <<== The wrong one As 4.x serie is closed now, code is fixed into next 5.0.0 only... Gilles Caulier
Great news, Gilles, many thanks ! Eager to discover Digikam 5.0.0. Best regards.
Note : if you recompile kipi-plugins yourself, there is just one line of code to remove to fix the problem...
(In reply to caulier.gilles from comment #19) > To comment #6 : > > I found the problem with the date. It's a stupid line hadcoded in source > with assign pano date to target file and later creation date. See my commit : > > http://commits.kde.org/kipi-plugins/3438a50e290bd234c0373217f011e1dddd6d344a > > .. into panorama/tasks/copyfilestask.cpp This one is on you ;o) http://commits.kde.org/kipi-plugins/fe279dc1be18b57854fae4476f2a10e7c4cc9c7f And if your commit message was accurate at the time, maybe expoblending shows the same issue...