Just a quick comment that renaming in digiKam is capable of using syntax highlighting now. It should be easier to decipher a renaming string this way :-)
A quick demo video can be found here:
... as well as some screenshots:
Is there any plan about saving these strings? I always use the "dir_[date:yyyy-MM-dd]_###" and there could be some way to avoid to write it.
As you can see, it is a combobox widget. Currently it holds a history of the last 20 typed in patterns.
This history is shared among the AlbumUI, CameraUI and Batch Queue Manager, so you have access to the history from everywhere.
For every instance the RenameWidget is used in, the last used pattern is saved and restored individually.
So if you often use a specific pattern in Batch Queue Manager, but a different one in CameraUI or AlbumUI, it i remembered correctly.
Right now on ubuntu karmic with digikam 1.0.0-beta5 it seems the used patters do not appear but no big deal.
That's because beta5 doesn't have the history... :D
Ubuntu had the stupid idea to add a beta version of digiKam into their stable release.
Unfortunately this version crashes all the time when using camera import.
digiKam-1.0.0-beta6 has been released since two weeks, but Ubuntu doesn't seem to upgrade the package.
I really hope they will not ship the beta5 for 6 months now, this can really shed a false light on digiKam, because
of the crashes... (that's why it is a beta version, they should at least have added it into an experimental repository).
Is there a way to update digikam to the last version for kubuntu without compiling?
A ppa repository? A deb package?
Luka Renko is providing digiKam-beta6 in his PPA:
PPA of Luka Renko
Maybe you can give it a try?
Thanks a lot
sorry for not knowing ANYthing...but...i would like to update Digikam but dont even know how....I use Linux Mint and have DigiKam vers. 0.10.0 and i not even know what PPA and other stuff even means.
also: if i update, all my tags are still where they belong. right?
i would like to "print" the data of the tags into the data of the pics itself, they should be a part of every individual picture. since it would be pointless to tag thousands of pics for weeks and than after i format (for example) the pc it was all in vain....
i was told this is possible but the way wich was explained to me doesnt exist in my vers. as it seems
thank you for reading
hope you can help me here
It would be cool to have this as a standalone tool for KDE
Right now this tool is closely tight into digiKam and I guess it will be even more dependend of the digiKam code in the future, since we want to provide every single peace of information from our databases, if possible.
There are standalone renaming tools like krename, gwenrename and metamorphose2. I don't think another one would make any sense.
I started this tool only to have it integrated in digiKam for importing images, renaming in the main window and for using it in the Batch Queue Manager. I had not found a batch renamer that is just a small widget that can be plugged into digiKam.
So I created my own...
I wrote my own renaming script based on Exiftool because no
matter how pretty the renaming tool is in digiKam, it depends
on the capabilities of an Exif library to support the Exif
tags. In this regard, "Exiv2" is sorely lacking.
The information I want in the file name includes the Canon
Maker Note tag "File Number". If the camera's option not
to reset the file number is chosen, then each file gets a
unique, sequential number that is extremely convenient for
identifying them. I like to add the date and a few other
details to the file name, but I always keep the file number
in the name, too. Exiv2 cannot read this tag at all, so the
renamer in digiKam is of no use to me. (The full file number
is not given in the original file name, so parsing it from
there is not an option.)
Exiv2 has had two updates this year, the last one five months
ago. Exiftool had its 41st update of the year last Friday.
Exiv2 is moving at a frustratingly slow pace and is the source
of my major gripe with digiKam: the inability to write tags to
Canon CR2 raw files. That makes the digiKam database a single
point of failure and prevents me from having standalone image
files from which I can reconstruct all needed metadata.
Now, I really like digiKam and use it almost exclusively for
photo management, but the "almost" is because Exiv2 just does
not match the standard of the rest of the package and there
seems to be little hope that it will ever get up to speed.
So, my next little project is to use Exiftool to read from
the digiKam database and write to the CR2 files, as it will
probably be years before Exiv2 can do this, if at all.
Great work on digiKam, but don't forget about the total
package: it's more than just the GUI.
Well have you reported this bug to exiv2?
I can not find anything in their bugtracker about this issue, so how should they know? ;-)
Other Canon RAW files are working fine here, I can extract Canon.ImageNumber.
The lack of Canon CR2 write support is Exiv2 "Feature #635". Is it
an open issue and the target release of "1.0" was deleted six months
ago. There have been no updates on the issue since then. As far as I
can tell it's dead, or at least years away.
The "Canon.ImageNumber" tag does not work for the EOS 40D. I haven't
tried it on the 50D, but I wouldn't hold out much hope for it there.
Exiftool had a fix for this about two years ago.
Exiftool recognises 228 Exif tags in my (now replaced) 40D images,
Exiv2 recognises only 99. For my S3 IS it's 187 vs. 110. For my
(now replaced) A40 it's 175 vs. 106. I haven't got the figures to
hand for my 50D and (now replaced) 400D, but I assume they are
about the same as the 40D. Should I open 500+ bug reports--one for
each tag--or one each for the tags that I am most intested in, or
one for each camera, or just one big one?
There is already one big one: "Feature #481", opened 26 July, 2006,
requesting that Exiv2 support the tags that are supported by
Exiftool. The response (the following day) was:
"To some extent this is work in progress; with the new TIFF
parser Exiv2 will be able to decode more Exif Makernote tags."
That new parser has yet to be released. I'm on my fifth camera since
the time that was reported, so I have come to the conclusion that what
Exiv2 contributes to digiKam--beyond the basics--is irrelevant to me.
The time to wait for fixes and the release cycle are just far too long;
longer than the upgrade cycle for my cameras. Exiftool works today and
fixes for new camera models come fast (there are already fixes for the
Canon 1D Mark IV, and that camera has yet to be released).
DigiKam, on the other hand, I'm sticking with. It is a great application.
The developers handled the KDE 4 transition more professionally than any
other application that I use regularly. I *trust* that it will continue
to improve. Where it falls down--or, more rightly, where Exiv2 lets it
down--I can compensate for with Exiftool.
I suppose my gripe is that the failings of Exiv2 mean that work on
things like syntax highlighting for file renaming are just developer
hours that I would much rather see spent on things like CR2 write support
or image grouping. There are a host of things on the digiKam wish list
with hundreds of votes; syntax highlight in the file renamer is not among
Maybe "Syntax Highlighting" was not a vote in BKO, but you know, as a developer I have wishes, too ;-)
And one wish on BKO was that renaming in digiKam is not possible because it lacks features.
Also I didn't spent months on implementing this, overall it was just 2 hours...
That's quite OK. I was only expressing my disappointment that my personal
biases did not coincide with yours. C'est la vie.
I fully understand that open source software is developed by those who
have an itch to scratch. You are quite entitled to implement what matters
most to you, as it is your time and effort that goes into it. Were us users
paying you for this, then we could demand that you address the wish list
items, but we are not, so we can't. All we can do is appeal to you to
keep an eye on the wish list and hope that you can find a little time to
use your skills to scratch a few other itches. The "itches" with the most
votes on the wish list would probably make more people happy than those
with fewer votes or none.
At least your FileNumber issue has been solved and will be available in exiv2-0.19:
[andi@macbook:/mnt/data/fotos/digiKam tests/RAW]$ /home/andi/Programmieren/KDE/exiv2-dev/src/exiv2 -pt IMG_4807.CR2 | grep Num
Exif.Photo.FNumber Rational 1 F2.8
Exif.Canon.SerialNumber Long 1 6d2426148
Exif.CanonFi.FileNumber Long 1 100-4807
Exif.CanonFi.BracketShotNumber SShort 1 0
Well at least I hope :-) This example was generated with files from a Canon EOS D400.
I'm currently trying to write a patch to support Canon File Information tags. Some fields are already working, FileNumber isn't :-) But I guess it will be done at the end of the day.
I will sent the patch to Andreas for review, I have never ever done anything for exiv2 and I'm still confused a little bit :-)
It is correct that Canon makernote hasn't seen an update in a long time and CR2 write support is not yet implemented. So I can understand the frustration if you are a Canon user and would like to see these features in digiKam. The good news is that both of these changes are not very difficult to implement. So what about this: I add the CR2 write support for the upcoming 0.19 release and you take care of the makernote update?
I have been releasing Exiv2 about four times per year. This year it will be three releases assuming I find the time to finish 0.19. The functionality has been extended greatly over time and there is always development activity, also between releases: close to 100 commits have been made to the source code repository since 0.18.2. Most Linux distros don't get updated more than four times a year, and you can always get the latest development version from the Exiv2 SVN, so this release strategy still seems appropriate.
Technically, implementing this functionality in C++ requires more lines of code and is more time consuming than doing the same in Perl. Performance is much better on the other hand and for many C/C++ applications it is not feasible to use a Perl application/library for the job.
At the end of the day, it all boils down to time. Progress depends on the amount of time invested by the people working on it. Join us to make things happen faster.