[Bug 303194] New: Filemanagement xml-files

[Axel Krebs]

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

            Bug ID: 303194
          Severity: wishlist
           Version: 2.6.0
          Priority: NOR
          Assignee: [hidden email]
           Summary: Filemanagement xml-files
    Classification: Unclassified
                OS: Linux
          Reporter: [hidden email]
          Hardware: Ubuntu Packages
            Status: UNCONFIRMED
         Component: general
           Product: digikam

I am wondering what is about the influence of extremely different file sizes
when using digiKam. With file systems, many are optimized on a statistical
distribution of files sizes, some new ones are optimized for large files as for
streaming media.

Some time back, a "size mixture" as under digiKam was fairly critical. Whereas
pics have sizes of about 15 MB (NEF) and 5 MB (jpg), the according xml-files
have just a few hundreds of bytes.

Therefore: Does digiKam recommend certain files systems to avoid the bove
mentioned problems as ext3, etx4, or which else?

What is about left over xml-files, when related pics do not exist any more?

Does digiKam provide a xml-file management? So, if erasing a pic, maybe even
variants of these, digiKam should erase accoring variants of correlated
xmls-files.

In other cases, a computer would accumulate small xml-files with the described
negative effects.




Reproducible: Always

Steps to Reproduce:
1. digiKam should provide a xml file mangement
2. digiKam should minimize the total number of xml files
3.

--
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=303194

Gilles Caulier <[hidden email]> changed:

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

--- Comment #1 from Gilles Caulier <[hidden email]> ---
1. digiKam already manage standardized XMP sidecar file, which are XML based.
2. no. digiKam cannot manage XML files generated by 3rd party photo management
program which do not repsect the standard used in photography from Adode...

We already manage metadata using a database and optionally through XMP sidecar
files. that all...

Gilles Caulier

--
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

[Axel Krebs]

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

--- Comment #2 from Axel Krebs <[hidden email]> ---
Sounds good. Maybe there is a way to take advantage of the existing file
system.

Axel

Am 08.07.2012 18:07, schrieb Gilles Caulier:

> https://bugs.kde.org/show_bug.cgi?id=303194
>
> Gilles Caulier <[hidden email]> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |[hidden email]
>
> --- Comment #1 from Gilles Caulier <[hidden email]> ---
> 1. digiKam already manage standardized XMP sidecar file, which are XML based.
> 2. no. digiKam cannot manage XML files generated by 3rd party photo management
> program which do not repsect the standard used in photography from Adode...
>
> We already manage metadata using a database and optionally through XMP sidecar
> files. that all...
>
> Gilles Caulier
>

--
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=303194

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Sidecar Management

--- Comment #3 from Gilles Caulier <[hidden email]> ---
The wy to improve is to take a care about 3rd party XML sidecar files when
image has imported to digiKam database. Nothing is done currently in this way,
excepted about standardized XMP sidecar files of course...

This can be done in Exiv2 library, as it done for XMP sidecar, but honestly, i
doubt  that a non standard way to host metadata will be implemented. Why ?
Because the puzzle is already really complex...

Gilles Caulier

--
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

[Andrew Goodbody]

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

Andrew Goodbody <[hidden email]> changed:

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

--- Comment #4 from Andrew Goodbody <[hidden email]> ---
I think Axel wants the 3rd party xml files grouped with the image file to ease
file management issues. He does not seem to be asking about the metadata
contained in those files at all.

--
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

[Axel Krebs]

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

--- Comment #5 from Axel Krebs <[hidden email]> ---
Gilles:

Maybe there could be a way: as described earlier, it could help to just
_link_ metadata between each file and coupled files (or internal database).

As long as only this connection has to be "standardized", one could
attribute as much information as one wants to in the linked text(?)-file
(or internal database).

I mean, it is much more difficult to "fit" each and every metadata-field
in a specific and correct way between an external program as digiKam and
the according field within the pics, so that every field can be "hit" be
external programs.

As an engineer, I would try to resolve to problem _seperately_ and
_independantly_!

There are free text-editors galore, therefore, we just ("only", ;-) )
need a flexible editor which can be configured for every specific
allocation between pic formats (and their specific way to deal with
metadata) and digiKam.

So, I think it is a question of assignements. Each source (as ADOBE,
CANON, NIKON RAW-files, and so on) could be treated as a profile, where
specific assignements were stored.

So. when working with metadata, digiKam has only to find out the very
file type, automatically (as source profiles are stored in digiKam and
is, therefore, wellknown!!) and can do the mapping between every desired
(and existing) type of metadata.

When contributed metadata from source, digiKam could fill up an internal
database, wherefrom one could adhibit and work with metadata.

Guess, digiKam did something similar, already?



Axel Krebs



Am 08.07.2012 20:34, schrieb Gilles Caulier:

> https://bugs.kde.org/show_bug.cgi?id=303194
>
> Gilles Caulier <[hidden email]> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Component|general                     |Sidecar Management
>
> --- Comment #3 from Gilles Caulier <[hidden email]> ---
> The wy to improve is to take a care about 3rd party XML sidecar files when
> image has imported to digiKam database. Nothing is done currently in this way,
> excepted about standardized XMP sidecar files of course...
>
> This can be done in Exiv2 library, as it done for XMP sidecar, but honestly, i
> doubt  that a non standard way to host metadata will be implemented. Why ?
> Because the puzzle is already really complex...
>
> Gilles Caulier
>

--
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

[Axel Krebs]

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

--- Comment #6 from Axel Krebs <[hidden email]> ---
Hi Andrew:

to be honest, I did not even think about those details, nor about the
file format to use for such a purpose.

I just try to see some side-effects of this solution from the view point
of an interested user.

- The "mixture of large and small files" will waste lots of sections, I
fear.

- there are hundreds of xml-files o my machines, and I have not idea, if
they may be erased 8lost metadata???)

- from these simple observations, I fear bout the releiability of th
association between metadata (xml?) and within the pics.

- Especially, as different pic formats support different metadata
standards.


Axel

- Do we have the option to extend furhermore the metadata, as for pic
authors comments, history, free text, etc, e.g.? Can xml provide such a
flexibility?


Am 08.07.2012 21:00, schrieb Andrew Goodbody:

> https://bugs.kde.org/show_bug.cgi?id=303194
>
> Andrew Goodbody <[hidden email]> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |[hidden email]
>
> --- Comment #4 from Andrew Goodbody <[hidden email]> ---
> I think Axel wants the 3rd party xml files grouped with the image file to ease
> file management issues. He does not seem to be asking about the metadata
> contained in those files at all.
>

--
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=303194

--- Comment #7 from Gilles Caulier <[hidden email]> ---
To Andrew comment @4 : this is already the case. XMP sidecar + image file are
considerated as unique item by all digiKam parts...

If you copy/move/remove an item for ex, sidecar will be processed in the same
way.

Gilles Caulier

--
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=303194

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #8 from Gilles Caulier <[hidden email]> ---
XMP sidecar are processed in digiKam as all other photo management program do :

- sidecar is created using filename+extension+.xmp at the same place than file.
- sidecar is a separate file on FS.
- sidecar is managed internally by digiKam to be processed in the same way than
image file.

That all. All other considerations around FS to link image file with sidecar
cannot be take in place, because it will break interroperability with other
photo management programs.

Also, a FS solution will increase complexity to manage both file and respect
compatibility with other FS, as for ex FAT32, NTFS, or HPFS. If we use a FS
feature working under ext4 for ex, there is no chance to be reproduced with
another FS, especially with a non Linux OS.

So i vote for no to this entry excepted if somebody can found a simpler and
compatible way (everywhere) to implement it.

Gilles Caulier

--
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=303194

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |4.0.0

--
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