Version: 1.1.0 (using KDE 4.3.5) OS: Linux Installed from: openSUSE RPMs When I try to rename images while importing them from my camera's SD card (using a card reader), the rename options produce strange results (they seem to work ok if I rename the images after they have been imported) I like to name my images to contain the date, time and camera model. If two images with the same camera have been created during the same second (continuous shooting), I add a unique sequence number to the name. Earlier I've used my own script to do this, but now I thought Digikam's import could do the work. It seems that {unique} *always* produces a sequence number on import, even if no other images with a similar name exist (this number is sometimes 1, sometimes larger). In addition to this, [cam] seems to produce the string 'ImagesonUSBDisk"STORAGEDEVICE"' instead of looking up the camera name from EXIF. For example, when I imported an image from the card using format string [date:yyMMdd_hhmmss]{unique}-[cam].[ext]{lower} My image DSC_2428.NEF became 100313_121400_6-ImagesonUSBDisk"STORAGEDEVICE".nef and I imported just one image into an empty directory. If I later rename it using the same format string, I get 100313_121400-NIKON CORPORATION NIKON D40.nef (In reality I would use [date:yyMMdd_hhmmss]{unique}-[cam]{replace:".* ([a-z][A-Z][0-9])*","\1",ri}.[ext]{lower} to use just the model number of the camera string)
SVN commit 1110842 by aclemens: Reset the parser properly in CameraUI CCBUG:230553 M +1 -0 cameraiconview.cpp M +5 -0 renamecustomizer.cpp M +1 -0 renamecustomizer.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1110842
Thanks Andi for the fix. Could we have an update on the second part of this bug report ? Is there a way to avoid that {unique} *always* produces a sequence number on import, even if no other images with a similar name exist ?
Hmm right now I can't confirm that the unique modifier is not working correctly, see this screenshot: http://img687.imageshack.us/img687/4488/importuniquemodifier.png Maybe you attach a screenshot here as well that shows the problem?
The second screen shows to files with different directory names and the unique modifier attached to it. No numbers were added: http://img88.imageshack.us/img88/6167/importuniquemodifier2.png Or am I misunderstanding your point?
Created attachment 43135 [details] Unique bug I think that you have perfectly understood the point ! But my result are different. Here what I get when I try to import 2 pictures. I am using Digikam 1.2.0 from Ubuntu 10.04.
Here's another observation (using Digikam 1.2.0 and OpenSuse 11.2 64-bit): If I choose to rename images during import (from SD card), and rename pattern contains {unique}, then numbers created by {unique} are incremented every time I select and deselect an image (no importing is done yet). This happens even if no other images with a same name are present.
Matti, this issue has been fixed by this commit: (In reply to comment #1) > SVN commit 1110842 by aclemens: > > Reset the parser properly in CameraUI > > CCBUG:230553 > > M +1 -0 cameraiconview.cpp > M +5 -0 renamecustomizer.cpp > M +1 -0 renamecustomizer.h > > > WebSVN link: http://websvn.kde.org/?view=rev&revision=1110842
Fred, you are importing two images, right? I guess these numbers are incrementing every time you select an image, deselect it and select all images after that? For example: - Click on image 1 - CTRL+A - click on image 2 - CTRL+A If so, the problem should be fixed in current trunk (digiKam 1.3.0), see my above comment. If the behavior is different (no number incrementation), I need to make sure what else could go wrong here.
Andi, Yes, numbers are incrementing each time I select an image. It is really a good news if this is fixed in trunk ! Thanks a lot, Andi. And thanks a lot to all Digikam developers.
Hi, I just upgraded to Digikam 1.4.0, and it seems that the {unique} bug is back in advanced rename. If I select a group of images to rename, {unique} produces _1 even if all the filenames are already unique without it (earlier {unique} produced an empty string in this case). What's more, when I edit the renaming pattern, the number increases all the time. Has the effects of the fix in commit 1110842 been lost some how? Matti
The {unique} behaviour described by Matti is reproducible in 1.6.0 also. Version : 1.6.0 (KDE 4.5.4) Installed from: Fedora 14 rpm (updates repo)
...and in 1.7.0 ??? Gilles Caulier
Yes, same {unique} issues with 1.7.0 installed from F14 updates-testing repo.
Git commit 3f22b9cae1b0c312fff59d3323414d7d4f6fae0a by Andi Clemens. Committed on 10/04/2011 at 17:56. Pushed by aclemens into branch 'master'. Fix some issues with the unique modifier, updated the testsuite... CCBUG: 230553 A +- -- tests/advancedrename_testimage2.jpg [License: Trivial file] M +25 -73 tests/advancedrenametest.cpp M +2 -0 tests/advancedrenametest.h M +9 -0 utilities/advancedrename/advancedrenamemanager.cpp M +1 -0 utilities/advancedrename/advancedrenamemanager.h http://commits.kde.org/digikam/3f22b9cae1b0c312fff59d3323414d7d4f6fae0a
Mati, This file still valid using last digiKam 4.2.0 ? Gilles Caulier
This file still vlid using last digiKam 5.0.0 ? Gilles Caulier
This problem still reproducible using last DK 5.4.0 bundle ? https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWlRJenM Gilles Caulier
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier
No feedback. Closed