Version: 0.9.3 (using KDE 3.5.8) Installed from: SuSE RPMs Compiler: 4.2.1 OS: Linux My primary tool for photo management is digikam. However especially for RAW file processing I use bibble. The resulting jpg as well as the RAW files are again tagged using digikam, all of the files are in digikams album tree. When processing a photo using bibble it creates a <mypic>.nef.bib file that contains all the image manipulation commands for the RAW pic <mypic>. The file is stored in the same directory as the photo it belongs to. Now if I want to move or copy photo files in digikam I cannot do so for .nef files I worked on with bibble, because in digikam I only see the photos but not the corresponding .bib files. This is really bad because afterwards your RAW files are in a new place but without the correcponding .bib files. So if I restart bibble all my work on this RAW files is gone if do not get the corresponding .bib files in place again. Thats why I would like to have an additional file filter like "Really show all files of any type in album" (well perhaps a litte shorter name) to get around this problem and to be able to move all the files I select. Thanks Rainer Krienke
I went and downloaded BibbleLite and produced a .bib file. "file" evaluates it to be: "ASCII text, with very long lines" So, an extension search would seem to be a good idea.
Brendan, All side-car file are depreciate. we have a dedicated database. This is a non sence to pollute hard drive with more metadata files... Also, to perform filtering and seraching thrue SQL request is faster than open sidecar file search/play + sidecar file search/play + sidecar file search/play + ...etc. Note : Unforget also, that metadata can be hosted directly in image directly. Gilles Caulier
I am not the bug author. I was just trying to add info to the bug. To the bug author: " I was mostly commenting how I (or someone more savvy) would implement your > wishlist item, programmatically. I was saying that the way .bib files are > detected would have to be by extension (.bib files) if none of the tools > available could detect the difference between a file with lots of text in > it > with very long lines (how one of the utilities used to detect filetypes saw > it > as), instead of saying "Bib file" and having a utility that could say "Even > though it's named image.foo, I know it's a Bibble file". Did I explain that > well? > > I definitely understood your wishlist item, I just wanted to see if it was > easy enough for a newbie like myself to handle, and if anyone on the dev > team > had an opinion before I took a crack at it."
Gilles, I do understand your viewpoint of just using one file + database which contains it all. However, it seems that there are (many?) professionals, having the philosophy to never touch original files at all. See eg.: http://panospace.wordpress.com/2008/03/22/dont-touch-my-raw-files/ for one viewpoint. There are surely various issues with side-car files, but obviously they are used by other applications, so (maybe a partical) support should be discussed. Possible tasks: a) when moving/renaming/copying files around (within digikam) also deal with the corresponding side-car files accordingly b) on import of new images, also make use of any relevant info from the corresponding side-car files c) write changes back to the side-car file While a) and b) seem not too invasive to the philosophy/approach of digikam, I am sceptical on c). This might lead to many synchronization problems. So to return to the problem of the original poster: instead of the possibility to show all files, wouldn't a) be even more comfortable? My impression is that this would not be too difficult to implement (along the lines Brendan suggested) and have no negative side-effects to digikam itself. Just my 1/2 cent (I am not using side car files anyway... ;-), best Arnd
Arnd, If you want to untouch original file, Database is enough to perform search/filtering. No need to create sidecar files. In digiKam, by default, files are not touch. Gilles Caulier
Krienke, This file still valid using digiKam 2.4 ? Gilles Caulier
Hello Caulier the bug ist still valid, since nothing the bug describes has changed. Still there is no way to see all files that exist in a directory ( album). All you see are photo/video files but nothing else. Rainer Krienke
Reading the original request, I'd say WONTFIX because digikam is not a file manager (and the implementation is not trivial or without side effects)
I agree with Marcel... Gilles Caulier
I think digikam has all features of a special purpose filemanager: You can rename files (photos) or folders (albums). You can copy and move both of them and also delete files and folders. All this are elements of a filemanager. The second argument is that sidecar files are not of "any" type of file. They are special files belonging to photos use by different professional grade software like eg bibble. Like sidecar files or not, they are reality and digikam should not ignore them up to a degree where a user can really loose his work by loosing the sidecar files. At the moment this is very easy in digikam: Just create an album with a raw photo file and a sidecar file for this photo. In digikam you see the raw photo and can now eg move this photo to another album and then delete the source album which appears to be empty in digikam. Upps you just lost all the work you invested on the photo using the software that stored all these modification you made for the raw photo in the sidecar file. This also works just the same for a hundred of photos and digikam does not even issue any kind of warning to the user.This is bad. If its hard to implement to see and copy move these sidecar files, than another solution should be in place so that at least a user can not that easily loose all of his work. For example digikam, could move/copy the sidecar files silently with the photos even without showing their existance. Or at least it should issue a big warning that when moving a photo for which there is a sidecar file, that these files are not moved along with the photo when using digikam. nd when deleting an album it should not delete it when there are still sidecar files in it. The best choice in my eyes is still to show these files to the user. No matter which solution is found I think its really bad if digikam allows the user to unintendedly delete important files not displaying them and not even letting the user know they exist but deleting them without any kind of notice. Rainer
Another type of file that I commonly encounter are GPX files, which are not yet supported to be shown by digikam, but are very much related to the photos. So I just added the GPX extension under the "Image mime types" list to at least have them shown in the album view. Currently there are mime types for images, videos and audio - having a fourth one for files which do not fit into the other groups would be a workaround for now I think. As for a warning when deleting non-empty folders, I have filed bug#216412 earlier. Michael
I fully agree that digikam should manage sidecar files and copy them along, and it has bugs and missing features at the moment. One may argue that a .bib file is a sidecar - it does not seem to me because a sidecar contains XMP data in a standardized way, and .bib for bibble looks like a custom/proprietary solution. The wontfix is directed at showing any kind of file from within digikam.
Well in between there are no more .bib files but instead it there are .xmp files. I cannot tell if the content is conform to any standard but any way, they contain very valuable information about all the "editing" that has been done using bibble5 to the corresponding raw file. Should I start a new bugreport about .xmp files now?
No, for XMP there are already bug reports like bug#289845. Just vote on them instead ;-) Michael