Bug 314441

I can confirm the bug, same version KDE 4.10.

Gael,

Do you use last digiKam code from git/master ? Renamer is not relevant of KDE version...

Gilles Caulier

I'm sorry Gilles I wasn't clear enough: same digikam version as bug reporter, that is beta 3 from Ubuntu backports PPA, and using KDE 4.10.

Since 3.0.0-beta3, a lots of work have been done...

If you can confirm with last code...

Gilles Caulier

Same issue here.
Digikam 3.0.0
KDE 4.10
Arch Linux binaries.
Canon EOS 40D, autodetected
If you need additional information, I am happy to provide.

Thanks,
Wolfgang

I believe this is the well known problem also discussed in 307253 and on digikam-devel " Import ignoring naming pattern" see Andi's mail from 31/12

Count me in...
Digikam 3.0.0
KDE 4.10
Arch binaries
Samsung NX11

I could compile the git version and check but I suspect that it would be a waste of time for now.

Jaroslav

*** Bug 316441 has been marked as a duplicate of this bug. ***

Created attachment 78119 [details]
digiKam 3.1.0-160.1 component list

The import ui is broken since last summer, and I haven't found time to fix the issues yet. Nobody has worked on it since Google Summer of Code, so it is still broken. Compiling the latest GIT won't help here.

Created attachment 78121 [details]
import shortcut dK 3.1.0-160.1

Sorry,
adding the first attachment, OpenSuse 12.3 freezed in fact of having only 2GB RAM.
And post was lost.

Here my post:
I confirm the bug, but ...
- Kamera cereated DNG import ok
- date based  destitnation directory is created
- Extention based DNG-destination subdirectory is created
- DNG file not renamed
- DNG file saved succesfully
- RAW batch editor  NOT  started
- Extention based PNG-destination subdirectory  NOT  created
- PNG file not renamed
- PNG file not saved
(thats only results of estimated behavour)

Can RAW batch editor started manually?
Bug at Notebook, OpenSuse 12.3, KDE 4.10.1, digiKam 3.1.0-160.1 (not productive system)

Desktop System, OS 11.4, KDE 4.9x, digiKam 2.6.0 is working well.

In addition to Comment 12

Also ignored is the 'Auto-rotate/flip image' for JPEG only.

Ubuntu 13.04 / KDE 4.10.1 / digiKam 3.1.0

*** Bug 317178 has been marked as a duplicate of this bug. ***

I hope I can take a look and fix it this weekend, sorry for not being active because of my military service.

Same here with Digikam 3.1.0

no renaming
no image rotation

*** Bug 317940 has been marked as a duplicate of this bug. ***

I can confirm this as well.  Gentoo Linux here.  

[ebuild   R   ~] kde-base/kdelibs-4.10.2:4  USE="3dnow alsa bzip2 fam handbook jpeg2k lzma mmx nls opengl (policykit) semantic-desktop spell sse sse2 ssl udev udisks upower zeroconf -acl (-altivec) (-aqua) -debug -doc -kerberos -openexr {-test}" 0 kB
[ebuild   R    ] media-gfx/digikam-3.0.0:4  USE="gphoto2 handbook mysql semantic-desktop thumbnails -addressbook (-aqua) -debug -doc -themedesigner -video" LINGUAS="-af -ar -az -be -bg -bn -br -bs -ca -cs -csb -cy -da -de -el -en_GB -eo -es -et -eu -fa -fi -fo -fr -fy -ga -gl -ha -he -hi -hr -hsb -hu -id -is -it -ja -ka -kk -km -ko -ku -lb -lo -lt -lv -mi -mk -mn -ms -mt -nb -nds -ne -nl -nn -nso -oc -pa -pl -pt -pt_BR -ro -ru -rw -se -sk -sl -sq -sr -sr@Latn -ss -sv -ta -te -tg -th -tr -tt -uk -uz -uz@cyrillic -ven -vi -wa -xh -zh_CN -zh_HK -zh_TW -zu" 0 kB

I thought I was loosing my mind.  :/

I can confirm this as well. Gentoo Linux with digikam 3.1.0

I can confirm this for 3.1.0 on KDE 4.10.2 / openSUSE 12.2.

BTW: Does this nightmare with KDE start on digikam also?

I hope that this bug may be fixed soon. Without this features, being able to "import" from any source seems useless for me, since it's the same as directly coping the pics with any file manager.

I've had a short look into the code (I don't really understand it, but I just went to have a quick look in it). 
With the git of apr 10 I figured out that the original name is being used, because the downloadName field is not being set in the CamItemInfo. 
I don't know where the downloadName in the CamItemInfo is supposed to be set, but what I do know is that it is not happening.
core/utilities/importui/main/importui.cpp:2038 :
        if (downloadName.isEmpty())
        {
            downloadUrl.addPath(settings.file); //<= THIS is being executed
        }
        else
        {
            // when using custom renaming (e.g. by date, see bug 179902)
            // make sure that we create unique names
            downloadUrl.addPath(downloadName);

Another gentoo users here, confirming this bug with digikam 3.0.1 and KDE 4.10.2.

 - the enabled auto-rotate checkbox is ignored during import
 - the images are not renamed

Both features worked fine for me with digikam 2.9.0 and KDE 4.9.5.

Concerning the "no auto-rotation problem", I found the following while looking at digikam's console output:
In digikam 1.9.0 (see bug #274947) you got something like:
---------------------- 8< ----------------------
Digikam::CameraController::executeCommand: Downloading: "IMG_1122.JPG" ...
...
Digikam::CameraController::executeCommand: Exif autorotate: "IMG_1122.JPG" ...
...
Digikam::CameraController::executeCommand: Set metadata from: "IMG_1122.JPG" ...
---------------------- >8 ----------------------
In digikam 3.0.1's console output, the line "Digikam::CameraController::executeCommand: Exif autorotate" is missing. So it does not look like a crash while auto-rotating, but the auto-rotation function is not even called at all.

Setting the downloadName on each item was an ancient way of doing it. The name could just be queried in the download pipeline. I'm just unsure about the correct API to use, hoping for some of Andi's feedback, see 307253

The renameManager was initialized in the old code in a method called 
void CameraIconView::slotUpdateDownloadNames(bool hasSelection)


This method is not there anymore, I don't know how the new names are generated nowadays.

I tried the following:
        downloadName    = d->renameCustomizer->newName(info.name, info.mtime);

But that did not work, because the renamedFiles list in the advancedRenameManager is not filled with the files. I can't really figure out when that is supposed to happen because I'm not familiar with the code, but I sure hope this helps point out the problem.

It happened in 
void CameraIconView::slotUpdateDownloadNames(bool hasSelection)

but I have no clue where this method is now... :-(

Andi, can you give us some guidance which methods of RenameManager need to be called in which sequence?

This is the old code before the port, this should be enough:


void CameraIconView::slotUpdateDownloadNames(bool hasSelection)
{
    if (!count())
    {
        return;
    }

    bool useDefault = true;
    int  startIndex = 0;

    if (d->renamer)
    {
        useDefault = d->renamer->useDefault();
        startIndex = d->renamer->startIndex();
    }

    DownloadSettings settings = d->cameraUI->downloadSettings();

    viewport()->setUpdatesEnabled(false);

    // NOTE: see B.K.O #182352: ordering of item count must be adapted sort of icon view,
    // since items are ordered from the most recent to the older one.
    bool revOrder = !d->cameraUI->chronologicOrder();
    // Camera items selection.

    // reset the start index
    d->renamer->reset();
    d->renamer->setStartIndex(startIndex);

    QList<ParseSettings> cameraFiles;

    for (IconItem* item = (revOrder ? lastItem() : firstItem()); item;
         (revOrder ? item = item->prevItem() : item = item->nextItem()))
    {
        CameraIconItem* viewItem = static_cast<CameraIconItem*>(item);

        if ((hasSelection && item->isSelected()) || !hasSelection)
        {
            QFileInfo fi;
            fi.setFile(QDir(viewItem->itemInfo().folder), viewItem->itemInfo().name);
            ParseSettings ps;
            ps.fileUrl      = KUrl(fi.absoluteFilePath());
            ps.creationTime = viewItem->itemInfo().mtime;
            cameraFiles << ps;
        }
    }

    d->renamer->renameManager()->addFiles(cameraFiles);
    d->renamer->renameManager()->parseFiles();

    for (IconItem* item = (revOrder ? lastItem() : firstItem()); item;
         (revOrder ? item = item->prevItem() : item = item->nextItem()))
    {
        QString downloadName;
        CameraIconItem* viewItem = static_cast<CameraIconItem*>(item);

        if ((hasSelection && item->isSelected()) || !hasSelection)
        {
            if (!useDefault)
            {
                QFileInfo fi;
                fi.setFile(QDir(viewItem->itemInfo().folder), viewItem->itemInfo().name);
                downloadName = d->renamer->renameManager()->newName(fi.absoluteFilePath());
            }
            else
            {
                downloadName = getCasedName(d->renamer->changeCase(), viewItem->itemInfo());
            }
        }

        if (settings.convertJpeg && !downloadName.isEmpty())
        {
            QFileInfo fi(downloadName);
            QString ext = fi.suffix().toUpper();

            if (ext == QString("JPEG") || ext == QString("JPG") || ext == QString("JPE"))
            {
                downloadName.truncate(downloadName.length() - ext.length());
                downloadName.append(settings.losslessFormat.toLower());
            }
        }

        viewItem->setDownloadName(downloadName);
    }

    viewport()->setUpdatesEnabled(true);
    viewport()->update();
}

So calling

d->renamer->renameManager()->addFiles(cameraFiles);
d->renamer->renameManager()->parseFiles();

and later

downloadName = d->renamer->renameManager()->newName(fi.absoluteFilePath());

should be enough

Created attachment 79792 [details]
patch of what I tried, but did not work.

Little extra explanation on previous post (sorry, forgot to add it when uploading patch)

I'm trying to do something like that in the ImportUI::downloadCameraItems method (don't know if that is the right place, though), but I don't understand how to get the parameters.

Here's my attempt:
if (!d->renameCustomizer->useDefault()) {
		QList<ParseSettings> renameFiles;
		foreach(CamItemInfo info, list)
		{
			ImageInfo imInfo(info.url());
			ParseSettings settings(imInfo);
			renameFiles.append(settings);
		}
		d->renameCustomizer->renameManager()->addFiles(renameFiles);
		d->renameCustomizer->renameManager()->parseFiles();
    }

However, it does not work, probably  because ImageInfo is an interface to the database, and we are working here with images that are not yet in the database. This code gives the following output in the console: 
No location could be retrieved for url KUrl("file:///media/6461-6562/DCIM/100CANON/IMG_3788.JPG")

Created attachment 79794 [details]
Another attempt, but still not working

I did another attempt, slightly different than the previous one. I don't like the way the code is looking now (creating a parsesettings object, from which info is taken to put into a parsesettings object, etc.), but I like even less that it is still not working. I still get the message :
No location could be retrieved for url KUrl("file:///media/6461-6562/DCIM/100CANON/IMG_3798.JPG")

I confirm this bug in digikam 3.1.0 (openSUSE 12.3 - KDE 4.10.2 "release 1").

Still the same behaviour in digikam 3.2.0

I can confirm that the auto-rotation of JPEGs during import does not work with digikam 3.2.0 on KDE 4.10.2, Kubuntu 13.04.

Additionally, the date-based creation of subfolders converts custom text in single quotes to lowercase. E.g. using the pattern "yyyy-MM-dd 'Sunset' " results in folder "2013-06-01 sunset" being created. Instead, the folder should be called "2013-06-01 Sunset".

The bug still in 3.2.0 (At the image download, rename settings is ignored).

Bug (renaming does not work when importing) still present in 3.2.0 with 3.7.10.-1.11-desktop Opensuse 12.3
but renaming started from BatchQueueManager works fine.

(In reply to comment #33)
> Created attachment 79794 [details]
> Another attempt, but still not working
> 
> I did another attempt, slightly different than the previous one. I don't
> like the way the code is looking now (creating a parsesettings object, from
> which info is taken to put into a parsesettings object, etc.), but I like
> even less that it is still not working. I still get the message :
> No location could be retrieved for url
> KUrl("file:///media/6461-6562/DCIM/100CANON/IMG_3798.JPG")

Hi Jonatan,

I used your patch and modified slightly and now it works. How to proceed? Shall I commit? Can I commit?

Created attachment 80748 [details]
Another attempt, now it works

This is the proposed patch that brings back renaming during import of images.

Rüdiger,

Thanks for you feedback. I will review patch asap...

Gilles Caulier

Today I finally had a little bit of time for fixing the ImportUI bug, but now the problem has been fixed :-)
Well at least a little bit, the patch seems to work fine, but the preview of the new filename is not shown.
I don't know if this feature is still present in the new importUI, but it was there in the old code.

Gilles,

I could commit the patch if you like to, but there are still some problems with the ImportUI:

- Already downloaded images are not marked as imported?
- "New filename" preview is gone?

Andi

Hi Andi,

Yes, i review patch too, and it sound fine for me. Let's go to commit.

==> Already downloaded images are not marked as imported? => there is another file about if i remember about this problem (see bugs #313678 and #281758)...

==> "New filename" preview is gone? => this feature must still here now, but you are right. Another stuff which have disappear...

Gilles

The patch has been applied, thanks Rüdiger Härtel  for your help. I will not close this bug yet since the filename preview is not yet fixed.

Andi

The "Camera filenames" option is not working, too. I will try to fix this now... (it just returns the plain camera filename, no upper or lowercase is applied)

Git commit 1583c952ac27d76c61dd947db8c064b08519adc3 by Andi Clemens.
Committed on 25/06/2013 at 11:09.
Pushed by aclemens into branch 'master'.

fix "Camera filenames" import option

M  +6    -1    utilities/importui/widgets/renamecustomizer.cpp

http://commits.kde.org/digikam/1583c952ac27d76c61dd947db8c064b08519adc3

Andi,

Look like RenameCustomizer::signalChanged() is not connected to ImportUI to dispatch event on icon-view class.

Camera file name is stored by CameraItemInfo::name. New file-name to use during import is stored by CameraItemInfo::downloadName.

Through digiKam setup cameras/Import Windows section, we can configure icon-view to display file-name under thumbnail (as AlbumGUI). It can be easy to reproduce 2.x renaming result by this way in Qt4 model/view port. Icon-item print file-name through ItemViewImportDelegate::drawName(). Call to this method is done into ImportDelegate::paint() line 279.

As you can see, drawName() is called to print only CameraItemInfo::name. There is n rules to print CameraItemInfo::downloadName if rename customizer settings has changed.

Gilles Caulier

Gilles,

CameraItemInfo::downloadName is never set anywhere in the code (verify it by removing the downloadName member from the CameraItemInfo class, no assignment anywhere).

This means there is a lot more wrong in the code then simply not showing the downloadName. For example the method CameraItemPropertiesTab::setCurrentItem() will always display "unchanged" in line 485 because the downloadName is never set. It is only set (internally) in ImportUI::downloadCameraItems() in line 2053. 

Right now we are not able to simply display the new name in the ImportUI, because there is a lot of code missing from what I've seen so far.

Gilles, Marcel,

There are still some problems I am not able to fix on my own:
- First of all, displaying the download name is not as easy as it might sound. I was able to display it (not yet happy with it thought due to some rendering issues), but the concept doesn't work for workflows were you just download a bunch of selected images. The problem is that the download names are not matching the onces after the download process.
For example: 5 images in the ImportUI, named image_#### (image_0001, image_0002 etc). If you only select the image_0003 and image_0004, they will be named image_0001and image_0002 after the download, which is ok, because it doesn't make sense to use the names from the ImportUI.
I guess we need to rename the images in the view when a selection is done, but this is a weird concept in my opinion, because the selected images will have the new downloadName, the others the old camera name.
I guess this is confusing. Any ideas how to fix this issue?

- Right now I don't really understand the code, I am not able to see when the view has finished loading and how to detect this in the ImportUI. I need this to initialize the advancedRenameManager to set the new file names. But right now I can not find the appropriate signal or slot. 
The only thing I found so far is the NewItemsFinder in ImportUI::finishDialog(), but it is created locally and no signal / slot connection is done, so the ImportUI must recognize the change through some other mechanism.
Can you help me out here?

> I guess we need to rename the images in the view when a selection is done, 
> but this is a weird concept in my opinion, 

Well this is how it is in fact. Either we do it, or we don't display a download name at all per default.
I guess there will be a "preview" name generator which is initialized with selection change and a "final" name generator.
Is generating the name always fast or are there cases where loading of data is necessary?

To Andi, #49 :

>I guess we need to rename the images in the view when a selection is done,

This is how 2.x release do with Qt3support classes.

> but this is a weird concept in my opinion, because the selected images will have the new 
> downloadName, the others the old camera name.

I think no, if downloadName is used to printed new file name in icon-view and if for each changes from Rename Customizer, downloadName is updated accordingly with settings. By default set downloadName = name (camera file name) from camera item container.

I remember to have implemented this way in the past.

In old code, we can see 2 connections from settings widget to camera icon view :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L498

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L209

First is for batch process settings done at download time as loss les conversion for ex which change file extension. Second is for rename customizer.

Both call this slot :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L417

... which check items selection and call another internal slot from :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L434

Which do the stuff about file renaming for each items in camera icon view. For each icon view item, we have an Camera Item Settings instance, where downloadName vlaue is changed accordingly. At end we refresh icon view to print all target file name. Et Voilà.

Code puzzle is a little bit complex, due to factoring stage that i do, before model/view port. It's not the best coding, but as i remember, it work well...

> Right now I don't really understand the code, I am not able to see when the view has finished 
> loading and how to detect this in the ImportUI. I need this to initialize the 
> advancedRenameManager to set the new file names. But right now I can not find the 
> appropriate signal or slot. 

Why you need to wait that pre download is done to set advancedRenameManager. Do it before sarting donwload when user change something in settings view.

>The only thing I found so far is the NewItemsFinder in ImportUI::finishDialog(), but it is 
>created locally and no signal / slot connection is done, so the ImportUI must recognize the 
>change through some other mechanism.

This one is another part dedicated to find new items downloaded from camera and update database. It's done when all is already completed. You init must be done before...

Gilles

To Marcel, #50 :

>Well this is how it is in fact. Either we do it, or we don't display a download
>name at all per default.

I thionk the option to display file name must be show by default, else it will be very difficult to adjust renaming settings. In 2.x implmeentation it work like this.

>I guess there will be a "preview" name generator which is initialized with
>selection change and a "final" name generator.

It's a good idea. Just a preview in rename customizer widget can be enough and lees complex to implement.

>Is generating the name always fast or are there cases where loading of data is
>necessary?

This is an important point. Generating new file name can take a while if use use metadata or file properties.

Gilles

Andi, Marcel,

About Already Downloaded Flag from icon-view to indicate which item have already imported to digiKam DB, look like this slot connection is commented :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/importui/main/importui.cpp#L191

CameraHistoryUpdater which manage status of already imported item with DB through CHUpdateItemMap container do not dispatch information to icon-view. I cannot see any code relevant in model/view. This is why there is no downloaded information displayed over item. I think it can be fixed easily.

This is the older code relevant :

In process to update icon-view (item from camera are listed or item filter has changed), CameraHistoryUpdater is called :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L1139

CameraHistoryUpdater ask to DB if items are already imported :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/controller/camerahistoryupdater.cpp#L154

...and give feedback to GUI through this slot :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L1142

here, we pass to addItem() the relevant CamItemInfo with DB info. When icon-view item is created :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L260

... it use this container to plug the right icon over thumbnail to idicate download status :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/items/cameraiconitem.cpp#L285

Gilles



https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L1162

(In reply to comment #51)

> > Right now I don't really understand the code, I am not able to see when the view has finished 
> > loading and how to detect this in the ImportUI. I need this to initialize the 
> > advancedRenameManager to set the new file names. But right now I can not find the 
> > appropriate signal or slot. 
> 
> Why you need to wait that pre download is done to set advancedRenameManager.
> Do it before sarting donwload when user change something in settings view.

I need to wait because the manager needs all the files for generating its caches. I have 5 cache maps that need to be filled, so that the actual renaming or changing the rename string is rather fast.

I will try to implement something now, I'll keep you informed...

(In reply to comment #50)
> Is generating the name always fast or are there cases where loading of data
> is necessary?

Yes, it is rather fast. When I rename 800 images (change the rename settings) in the albumUI, the new filenames are generated in approx 1 second, even when reading metadata or file properties. 
There is also the possibility to add more cache maps in the RenameManager during initialization, to read the most important file properties and metadata information (or even create new cache maps dynamically when the rename settings are changed).
But right now I think it is fast enough.

I'll take a look at implementing a preview widget in the rename settings, to. Maybe a label is sufficient that displays the new name of the first (selected) image?

Git commit 78c5968a304f10bdbee5e329a915a93136c03daa by Andi Clemens.
Committed on 30/06/2013 at 08:53.
Pushed by aclemens into branch 'master'.

Display the download file in the icon view for the selected items, like we did in digiKam 2.x.
I still think this is not the best solution, but it seems to work right now.

There is a refresh problem with the view, that has always been there and is not introduced by this patch.
If you change rename settings or if you download images, the icon view is only refreshed when you move the mouse out of the view and in again.
I tried fixing this issue, but failed.
Maybe someone who knows this code can take a look at the issue?

Andi

M  +1    -1    utilities/importui/items/importdelegate.cpp
M  +120  -101  utilities/importui/main/importui.cpp
M  +7    -1    utilities/importui/widgets/renamecustomizer.cpp
M  +1    -0    utilities/importui/widgets/renamecustomizer.h

http://commits.kde.org/digikam/78c5968a304f10bdbee5e329a915a93136c03daa

In 3.2.0, this is still present. Any hope for 3.3?

Yes, some stuff have already fixed by Andi for 3.3.0

I will take holiday 3 weeks in July. I will take time to hack download flag feature for 3.3.0.

Gilles Caulier

Hi Andi, hi Gilles

Many thanks for all your efforts in fixing the involved bugs.

I observed an unexpected behaviour probably in the same context of this.
If you delete any selected pictures in the download dialog, the pictures being deleted are the ones selected. However the pictures being displayed after the operation aren't the ones effectively remaining on the device.

May the major bugs be fixed in 3.3.0

The bug still in the last patch for openSUSE 12.3 x86_64 (3.2.0-1.83.3 - At the image download, renaming settings is ignored).

Hello,

I notice also this incorrect behavior on LinuxMint 15 (Digikam 3.1) and ROSA Desktop Fresh (Digikam 3.2) with PTP mode on NIKON D5100

When I tell Digikam to download / delete images from the camera, all is well downloaded but only the first image is deleted, the others stay and Digikam seems to wait something to finish the operation

Using debug mode with gdb, I can see this :
"No location could be retrieved for url KUrl("") "

Is it a consequence of the above bug or should I declare a new one ?

Further details, if I ask Digikam to delete only, it works

To comment #61 : It's another bug that i can confirm. Please, check first if a file about it doesn't exist yet in bugzilla. If not, open a new one.

Gilles Caulier

This bug is still present in 3.3. It is partially solved, in the sense that now the basename is  changed (i.e., DSC_2546.JPG can be changed to my_name_007.JPG), but, sadly, other rename options are ignored or applied in a bad way.
For example, let's say we want to rename some photos to bird_001.JPG: one need to enter bird_### in the rename mask. Well, digiKam accepts the basename, the fact that there should be 3 digits, but chooses the number by itself. In the above example, numbering should start from 1, while digiKam insists to start numbering from a number that seems to be the position in the import view. More precisely, if the image is the 8th in the view, numbering starts (as far as I have tried) from 9 or so.
Also bird_###[10] is ignored: the number between square brackets doesn't mean nothing to digiKam.

Other options (like [cam], etc) don't work.

I've found a workaround for the problem mentioned in my previous comment. I don't like it too much, but it works.
If the name is set to something like my_name_###[f] (so "folder aware numbering" is active) digiKam correctly starts from 1 for numbering renamed items. Also my_name_###[f,start,step] works.

Options tested as non-working: [cam], [dir]
Working: [file], [date] (I've tested these ones)

I don't know if this is the correct place, but there are two other minor problems with advance rename. They regards the field used for writing new names.

#1: the button on the right for deleting field content doesn't work
#2: the field is too small and does not display the bottom part of some characters, for example "p". Underscores are not visible at all.

If needed I will file a new bug for this.

In the new digikam versión 3.5.0, the renaming settings during import, has been SOLVED !!!

I auto rename my pictures, with exif date-time in format [date:"yyyy-MM-dd_hh-mm-ss"], and it works !!!.

:)

> If needed I will file a new bug for this.

Please do if there is no similar entries available. Both could go to the same bug report, as they seem to be related.

Bug checked against digikam 3.5.0 (KDE 4.10.5, gentoo linux):
I can confirm Stefano Ferri's  comment #64
> This bug is still present in 3.3. It is partially solved, in the sense that
> now the basename is  changed (i.e., DSC_2546.JPG can be changed to
> my_name_007.JPG), but, sadly, other rename options are ignored or applied in
> a bad way...

And comment #65
> ... Options tested as non-working: [cam], [dir]
> Working: [file], [date] (I've tested these ones)

For import from SD card, my default setting is:
"[cam]{range:13,15}-[file]{lower}.[ext]{lower}"
expected result: "EOS-img_2108.jpg"
actual result: "-img_2108.jpg"

So "[file]", "[ext]" and "{lower}" work. But "[cam]{range...}" only brings up an empty string.
Also "[meta:Exif.Image.Model]", "[meta:Exif.Canon.ImageType]",
"[dir]" and a sole "[cam]" (without "range"-modifier) only give an empty string.
These are the points I tested. This matches with Stefano Ferri's test results.

Also "Auto-rotate/flip image" does not work. Portraits are not automatically 
rotated, but remain in landscape orientation.

In the console debug output one can find a lot of 
  "Cannot load metadata from file   (Error # 9 :  IMG_1995.JPG: Failed to open the data source:  (errno = 2)"
The reason might be: "IMG_1995.JPG" was the original image name on SD card,
but while importing the picture is renamed to "-img_1995.jpg" (see above).
So the error message is correct. But the question is, why does digikam look for 
files with the old name?

As for the "Failed to open the data source" errors from comment #69:
If I disable image renaming during import, those error messages don't show up. But rotation according to EXIF-Flag also does not work.

(In reply to comment #67)
> In the new digikam versión 3.5.0, the renaming settings during import, has
> been SOLVED !!!
> 
> I auto rename my pictures, with exif date-time in format
> [date:"yyyy-MM-dd_hh-mm-ss"], and it works !!!.
> 
> :)

Are you sure that [date:"yyyy-MM-dd_hh-mm-ss"] uses *exif date-time*?
After reading the documentation I'd say it uses the image file's timestamp.
[meta:Exif.Photo.DateTimeOriginal] uses EXIF date-time but it can't be formated like this: [meta:Exif.Photo.DateTimeOriginal:"yyyy-MM-dd_HH-mm-ss"].

I don't know if that's a bug or simply not supported.

Best regards,
Andreas

*** Bug 322539 has been marked as a duplicate of this bug. ***

In version 4.0 still works only partially: getting date information from file works, but from exif does not.

*** Bug 337987 has been marked as a duplicate of this bug. ***

What's the status of this bug ?

Somebody can resume all dysfunction which are pending to fix please

Gilles Caulier

The setting I was using since many many years is still not working since more then a year, and was not in between:
[meta:Exif.Photo.DateTimeOriginal]{replace:":",""}{replace:" ","T"}
results in DSC_1234.JPG

as well as:
[meta:Exif.Image.DateTime]


But, after reading now posts from above and testing other settings as mentioned there, I can confirm it is working with the file-timestamp:
[date]
[date:"yyyyMMdd(hhmm)"]-###

[date]{lower} will not set the .JPG extension to lower case - don't know if it should but I would expect it actually.

Tested with digikam 4.2.0 on KDE 4.12.5 (gentoo linux):

 - auto rotation does not work: 
     - "portrait" fotos are imported as "landscape"
     - clicking from the digikam menu "Image -> Auto Rotate / Flip Using Exif Information" does rotate them to the correct portrait orientation (after import, so orientation tag is present in image file)
     - in digikam settings I have turned off "Show images/thumbnails rotated according to orientation tag"

 - renaming (my personal file rename pattern): "[cam]{range:13,15}-[file]{lower}.[ext]{lower}"
   - working:
      - plain character as seperators: "-" and "."
      - plain text: "eos"
      - "[file]" -> "IMG_9885"
      - "[ext]" -> "JPG"
      - "[date]" -> "20140901T203242" (time, the picture was taken)
      - '[date:"yyyy-MM-dd_hh-mm-ss"]' -> "2014-09-01_20-32-42" (time, the picture was taken)
      - modifier "{lower}", "{upper}", "{firstupper}"
      - modifier "{trim}"
      - modifier "{removedoubles}"
      - modifier '{default:"..."}' -> expands to the given default text as expected
      - modifier '{replace:"IMG","XXX",i}' -> replaces "IMG" with "XXX"
      - modifier '{replace:"\w+_","PIC",ri}' -> replaces "IMG_" with "PIC" (RegExp)
      - modifier "{range:...}"
      - even modifier combinations work: '[cam]{default:"spaces  "}{trim}end' becomes "spacesend"

   - failing:
      1) "[cam]" (selected by clicking "Camera" in the Options-Popup-Menu) becomes an empty string (should be something like "Canon EOS 550D" (in my case))
      2) "[meta:Exif.Photo.DateTimeOriginal]"
      3) "[meta:Exif.Photo.ExposureTime]"
      4) "[meta:Exif.Image.Model]"
      5) "[meta:Exif.Canon.ModelID]"
      => I guess all "[meta:Exif....]" fail, since I could not find a single working one
      6) "[dir]" (in my case it is an empty string, which looks wrong; I guess it should either be "100CANON" (source dir) or "New Fotos" (destination dir); the online help is not that clear at this point)
      7) "[user]" / "[group]" (file's user and group access settings) -> empty string
      8) modifier "{unique}": Add for example "[ext]{unique}" in the middle of the filename and select three images in the download window
            -> this will preview the following filenames: "...JPG...", "...JPG_1...", "...JPG_2..."
            -> so far so good :)
            -> but if you click "Download Selected", you will find three images in your digikam collection with the names:
                    "...JPG_3...", "...JPG_4...", "...JPG_5..."
            => so the unique-counter is not reset between "display the preview" and "really import the images"
      9) "###" -> same problem as "{unique}" modifier: counter not reset; with three files selected:
            -> preview: "001", "002", "003"
            -> imported files: "004", "005", "006"

(In reply to rockhopper.tux from comment #76)
> ...
> [date]{lower} will not set the .JPG extension to lower case - don't know if
> it should but I would expect it actually.

I read your pattern like: 
1) take the pictures date as string
2) convert the date string to lowercase
3) since there is no explicit extension in your pattern, the original files extension is added, which seems to be uppercase (like in my case)

A modifier only modifies the string immediately in front of it. So from my point of view, not changing the extension seems to be correct.
Implementing some intelligent magic like "if everything in the pattern is lowercase, the default added extension should be lowercase, too", would make the powerful renaming algorithm way more complex, more diffucult to maintain and more prone to errors, I guess.
(And I personally don't like programs which _try_ to be smart and do something I did not expect.)
Of course, this is only my opinion and free for discussion.

You can achieve, what you want with:
     [date]{lower}.[ext]{lower}

(In reply to Peter Albrecht from comment #78)
> I read your pattern like: 
> 1) take the pictures date as string
> 2) convert the date string to lowercase
> 3) since there is no explicit extension in your pattern, the original files
> extension is added, which seems to be uppercase (like in my case)
> 
> A modifier only modifies the string immediately in front of it. So from my
> point of view, not changing the extension seems to be correct.
> Implementing some intelligent magic like "if everything in the pattern is
> lowercase, the default added extension should be lowercase, too", would make
> the powerful renaming algorithm way more complex, more diffucult to maintain
> and more prone to errors, I guess.
> (And I personally don't like programs which _try_ to be smart and do
> something I did not expect.)
> Of course, this is only my opinion and free for discussion.
> 
> You can achieve, what you want with:
>      [date]{lower}.[ext]{lower}

Peter, thanks for your response on this, and after reading your explanation and testing it I totally agree with you.

Please all ignore my my false expectation (last line) from #76, the way it is working is for sure better and more correct.

Git commit 33d6ff1e170d18a3d9a13a76e21206bdaa49ef18 by Gilles Caulier.
Committed on 28/10/2014 at 23:11.
Pushed by cgilles into branch 'master'.

Apply patch #89348 to restore autorotation feature while downloading from camera.
Related: bug 340439
FIXED-IN: 4.5.0

M  +18   -8    utilities/importui/main/importui.cpp
M  +2    -2    utilities/importui/main/importui_p.h

http://commits.kde.org/digikam/33d6ff1e170d18a3d9a13a76e21206bdaa49ef18

Hi all,

With commit from comment #80, autorotation feature is fixed in 4.5.0. See patch given into bug #340439

So, the patch from this report must be updated to only fix rename feature which still need to be fixed.

Gilles Caulier

(In reply to Andi Clemens from comment #49)

> For example: 5 images in the ImportUI, named image_#### (image_0001,
> image_0002 etc). If you only select the image_0003 and image_0004, they will
> be named image_0001and image_0002 after the download, which is ok, because
> it doesn't make sense to use the names from the ImportUI.

This specific problem is now fixed by https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/f0bba25facfaef1fdcba8f3d0990dbf453abfc7b

On Linux Mint 7 I have just upgraded from DK 4.5 to 4.6.  I use auto rename when I import pictures from my camera, it was working fine in 4.5 but now it does not rename but retains the name from the camera file. 
On the Import screen I have Customise, then PIC[date] in the box.  
If I select the pictures after import and select Image > Rename it works fine.

Mick Sulley

Git commit 7f3459d55dd453f257ece35398175bba22ea4109 by Gilles Caulier.
Committed on 25/01/2015 at 11:39.
Pushed by cgilles into branch 'master'.

Apply patch #90637 from Maik Qualmann to fix image renaming settings rules in Import Tool to work properly while downloading.
Related: bug 342996, bug 329438, bug 307253, bug 342430
FIXED-IN: 4.7.0

M  +3    -1    NEWS
M  +2    -2    utilities/importui/backend/cameracontroller.cpp
M  +67   -44   utilities/importui/main/importui.cpp
M  +1    -0    utilities/importui/main/importui.h
M  +5    -0    utilities/importui/views/importview.cpp
M  +1    -0    utilities/importui/views/importview.h

http://commits.kde.org/digikam/7f3459d55dd453f257ece35398175bba22ea4109

Git commit 0201e6fc8549ac849029daf36eaeadd6ebb4d4ae by Gilles Caulier.
Committed on 25/01/2015 at 13:58.
Pushed by cgilles into branch 'frameworks'.

Backport commit #7f3459d55dd453f257ece35398175bba22ea4109 from git/master to frameworks branch.
Related: bug 342996, bug 329438, bug 307253, bug 342430

M  +3    -3    utilities/importui/backend/cameracontroller.cpp
M  +74   -50   utilities/importui/main/importui.cpp
M  +1    -0    utilities/importui/main/importui.h
M  +5    -0    utilities/importui/views/importview.cpp
M  +1    -0    utilities/importui/views/importview.h

http://commits.kde.org/digikam/0201e6fc8549ac849029daf36eaeadd6ebb4d4ae