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.
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
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 <caulier.gilles@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |caulier.gilles@gmail.com > > --- Comment #1 from Gilles Caulier <caulier.gilles@gmail.com> --- > 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 >
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
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.
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 <caulier.gilles@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|general |Sidecar Management > > --- Comment #3 from Gilles Caulier <caulier.gilles@gmail.com> --- > 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 >
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 <ajg02@elfringham.co.uk> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ajg02@elfringham.co.uk > > --- Comment #4 from Andrew Goodbody <ajg02@elfringham.co.uk> --- > 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. >
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
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