[Digikam-devel] [kipiplugins] [Bug 342687] Panorama file time-stamps should be the same than the stitched pictures [patch]

[Benjamin Girault]

https://bugs.kde.org/show_bug.cgi?id=342687

Benjamin Girault <benjamin.girault at nebux.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benjamin.girault at nebux.org

--- Comment #9 from Benjamin Girault <benjamin.girault at nebux.org> ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.