[Bug 278935] New: Please make XMP Sidecar filename configurable

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

           Summary: Please make XMP Sidecar filename configurable
           Product: digikam
           Version: 2.0.0
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: Metadata
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:           2.0.0 (using KDE 4.6.2)
OS:                Linux

Digikam stores metadata in sidecar files named $BASENAME.$EXT.xmp.

However, several other applications use the sidecar file name $BASENAME.xmp
(without the original extension), so I am not able to use digikam together with
those. (e.g. Geeqie, exiv2)

Please add a checkbox in the settings dialog to change the sidecar file name.
Thank you.

Reproducible: Didn't try

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|Metadata                    |Sidecar Management




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

--- Comment #1 from Marcel Wiesweg <[hidden email]> ---
What happens if there is file1.jpg, file1.tiff and file1.png?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tomasz]

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

Tomasz <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from Tomasz <[hidden email]> ---
I see how fully supporting this naming scheme for sidecar files could be
problematic, but from what I see on the web, Adobe itself also uses
$BASENAME.xmp. Thus at least partial support for those files in Digikam is
needed (e.g. only reading).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

klaus <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #3 from klaus <[hidden email]> ---
I currently use JPhotoTagger (http://jphototagger.org/) on win-pc and
APhotoManger (https://github.com/k3b/APhotoManager/) on android to manage my
12000 photos.

JPhotoTagger has hard coded "write changes only to sidecar file" and currently
both use the naming convention $BASENAME.xmp so i cannot import the meta data
to digiKam without renaming 12000 xmp sidecar files.

I also agree that $BASENAME.$EXT.xmp makes more sense but adding this option
would increase interoperability and allows me to use both JPhotoTagger and
digiKam at the same time

I have just added this issue to APhotoManager
https://github.com/k3b/APhotoManager/issues/84

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

[bugzilla_noreply]

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

--- Comment #4 from Tomasz <[hidden email]> ---
BTW. Current Geeqie GIT version supports both sidecar naming schemes.

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

[bugzilla_noreply]

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

Simon <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #5 from Simon <[hidden email]> ---
I see why this could be desirable for interoperability (I see no other
benefit?) However I don't see how to do this conceptually. Digikam doesn't
store images in a managed library, but reads it from disk. So how do you
enforce unique base filenames (i.e. that image.jpg and image.png never exist
alongside)?

Does anyone know how the mentioned projects (JPhotoTager, AphotoManager, Adobe)
handle this?

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

[bugzilla_noreply]

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

--- Comment #6 from Tomasz <[hidden email]> ---
I can comment about Geeqie only. Even before this issue was resolved Geeqie
grouped files with the same basenames together (e.g. img.cr2 and img.jpg). By
default it included img.xmp in the same group and used it to read/write tags
for other image files in this group.

Now, the recent patch makes Geeqie add img.cr2.xmp to the group if img.cr2 is a
member. It also offers an option to write metadata to img.cr2.xmp files rather
than img.xmp files. The issue was discussed here:
https://github.com/BestImageViewer/geeqie/issues/147

I agree that it can have unintended consequences if two unrelated files share
basename. That's why I believe that using img.xmp naming scheme should be
optional. Moreover, since the longer naming scheme makes more sense, I don't
think there is a need to make Digikam able to write those files. However if
they do exist, they could be read (or even migrated, but that might create a
mess).

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

[bugzilla_noreply]

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

--- Comment #7 from klaus <[hidden email]> ---
I see, the "unique base filename" makes it much more complicated ;-(

how frequent are these naming conflicts so that code must take care of it?

On the android/APHotoManager side i will ignore the problem in the first run.

Move/rename/delete of img.jpg will also
handle img.xmp and img.jpg.xmp if they exist
(no matter what xmp-naming-convention the seggings dialog has)

if there is imp.jpg and img.jpeg the first one beeing moved/deleted/renamed
wins

the media scanner will assing the content of img.xmp to both: img.jpg and
img.jpeg

xmp update policy:

* if there is imp.jpg.xmp update this file
* else if there is img.xmp update this file
* else if there is no xmp file yet create it according to xmp-naming-convention
settings

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

[bugzilla_noreply]

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

MikeF <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #8 from MikeF <[hidden email]> ---
I see two possible ways to avoid conflicts...

1) Other programs add this line to the .xmp files
photoshop:SidecarForExtension="cr2"
Can't this just be expanded to a list to reflect all extentions the sidecar is
used for?
I'll admit I have not read through the xmp specifications so i apologize in
case this is complete nonsense.

2) Since most of the time sidecar files are only needed for RAW files (jpg and
tiff both support embedded xmp data), why not add two options of which only one
can be turned on:

- write xmp sidecar data only for raw files and embed metadata in other image
formats
- The way it is handled right now with .ext.xmp

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