Summary: | Import images - always increase renaming counter by number of images imported | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Michal Thoma <michal> |
Component: | AdvancedRename-Import | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | caulier.gilles, vandenberg.ra78 |
Priority: | NOR | ||
Version: | 1.0.0 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 2.1.0 | |
Sentry Crash Report: |
Description
Michal Thoma
2009-08-05 15:40:29 UTC
For most people counter is used for current job renaming so this particular would harmful for most users. However, interesting feature for digiKam import would be renaming images to make sure all images have unique numbers. Think about OAI and its identifiers http://www.openarchives.org/OAI/2.0/guidelines-oai-identifier.htm Note that for home use it is probably overkill and much more practical is schema {iso-date}_##### :) > However, interesting feature for digiKam import would be renaming images to > make sure all images have unique numbers. Yes, that would be nice. > Note that for home use it is probably overkill and much more practical is > schema {iso-date}_##### :) Yes, that would also do, unfortunately AFAIK Import tool don't support such smart tags like {iso-date} or {original-filename} etc. That is not true. I have implemented a ManualRenameWidget , that allows such tags. It can be found in Camera-Import and in BQM. It is not yet complete, but it features things like original filename, custom date format and custom numbering (with leading zeros and custom ranges / steps). The only thing that is missing is the use of Metadata tags. But it will be implemented. Oh, I see now in 1.0.0b3. Before I was looking at 0.10.0 which don't have such feature still. So this is quite enough, great job and thank you! SVN commit 1008382 by aclemens: Add the ability to only set a custom start in the ManualRenameInput widget. Added some test cases to verify the functionality. CCBUG:202641 M +2 -1 libs/widgets/common/manualrenameinput.cpp M +12 -0 tests/manualrenameinputtest.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1008382 I'm adding some quick access buttons to the rename widget: http://farm4.static.flickr.com/3446/3800955702_0cf9a241d7_o.jpg http://farm3.static.flickr.com/2476/3800136351_fb9853cc1d_o.jpg Setting up individual import names should be easier then. The only thing that is not working right now is the Metadata button... Very nice! With this new manual rename widget I find the old Custom rename rather obsolete. Yes, I think it could be obsolete then. I still need to figure out how to make it more extensible, it is working (somehow :-)), but I'm not happy. The plan is to just add another token / parser, and the rest will work automatically. What is working now: - register the parser button automatically - register the menu entry for the toolbutton automatically - create the tooltip automatically What is not working: - the parser itself :) I need to abstract a lot, so that a common parse method can be used. When all is working, I can image tokens / parser like: - metadata (completely customizable) - add author information - tags information etc... Some rename options might not work in the cameraUI, but since we use this widget also in BQM, they could work in there, because BQM has full access to the database. Andi This is the actual status: http://farm3.static.flickr.com/2480/3811917860_0db6100ea8_o.jpg But the only parsers really working are: - File Name - Camera Name - Sequence Number - Time & Date the rest is just added at the moment to test the registration, and to show some ideas for additional parsers. This report can be closed? I don't know if it is practical for most users to keep track of the index, but with AdvancedRename, you can set your starting index manually, see http://www.flickr.com/photos/26732399@N05/4089342906/in/pool-digikam-labs for example. Is this enough for your needs? First of all, I really enjoy digikam (current version 1.0.0-1, debian testing), so thanks for that. I've found a side effect of the "always increase renaming counter". When I want to use different names within one batch import, it remembers the count of the previous name. For instance, I import 10 photos according to "a###" and then import 10 photos according to "b###". The result will be a001 to a010, and b011 to b020. I can circumvent this by restarting the importer, but I think it could be done in a nicer way. Andi, Do you see comment #11 ? Gilles Caulier This should be fixed a long time ago, so we can close the bug. Gilles: By the way, the importing tool seems to be broken (CameraUI), it doesn't update the new image names and it always asks me in which folder to put the downloaded images, although I selected the album before (and then pressed CTRL+I). Thanks. I take a look... Gilles Git commit 6d0916343d845784de75bc60cd65b85047aa87e9 by Gilles Caulier. Committed on 10/08/2011 at 10:04. Pushed by cgilles into branch 'master'. preserve download name information CCBUGS: 202641 M +2 -1 utilities/cameragui/items/cameraiconitem.cpp http://commits.kde.org/digikam/6d0916343d845784de75bc60cd65b85047aa87e9 Andi, it's fixed now. You confirm ? Gilles Caulier I just checked, and the behavior as described in comment 11 is still present in my version of Digikam. Like I said previously, it's not a big issue but it would be nice if it'd be handled differently. Debian wheezy: 2.6.39-2-686-pae i686 GNU/Linux Digikam version: 2:1.9.0-3 |