[digiKam-users] Issue with {unique} in batch-rename

[hajo]

Hi group,

Not sure if this was discussed earlier, apologies if so. I can open a bug/feature request if not. 

Assume the following batch rename string: 

[date:yyyyMMdd-hhmmss]{unique}_Vacation

If 3 photos have the same date/time they will be renamed as follows:

DSC1:  20181029-130000_Vacation

DSC2:  20181029-130000_1_Vacation

DSC3:  20181029-130000_2_Vacation

In alphabetic sorting (e.g. file manager), they will then be listed in the wrong order, since the unique numbers '1' & '2' are before the 'V' in the alphabet -- Pic 1 will be listed after Pic 2 & 3. I ran into this when trying to make an animated GIF recently.

I think {unique} should add a _0 per default or, of course better yet, be aware if there's a conflict coming up and only add the _0 in such case.

[Jack Marxer]

If there are duplicates and {unique}, why not number them with _01, _02, _03, etcetera?

Jack

On Mon, Oct 29, 2018 at 4:51 AM HaJo Schatz <[hidden email]> wrote:

Hi group,

Not sure if this was discussed earlier, apologies if so. I can open a bug/feature request if not. 

Assume the following batch rename string: 

[date:yyyyMMdd-hhmmss]{unique}_Vacation

If 3 photos have the same date/time they will be renamed as follows:

DSC1:  20181029-130000_Vacation

DSC2:  20181029-130000_1_Vacation

DSC3:  20181029-130000_2_Vacation

In alphabetic sorting (e.g. file manager), they will then be listed in the wrong order, since the unique numbers '1' & '2' are before the 'V' in the alphabet -- Pic 1 will be listed after Pic 2 & 3. I ran into this when trying to make an animated GIF recently.

I think {unique} should add a _0 per default or, of course better yet, be aware if there's a conflict coming up and only add the _0 in such case.

[hajo]

On Mon, Oct 29, 2018 at 3:57 PM Jack Marxer <[hidden email]> wrote:

If there are duplicates and {unique}, why not number them with _01, _02, _03, etcetera?

Jack

On Mon, Oct 29, 2018 at 4:51 AM HaJo Schatz <[hidden email]> wrote:

Hi group,

Not sure if this was discussed earlier, apologies if so. I can open a bug/feature request if not. 

Assume the following batch rename string: 

[date:yyyyMMdd-hhmmss]{unique}_Vacation

If 3 photos have the same date/time they will be renamed as follows:

DSC1:  20181029-130000_Vacation

DSC2:  20181029-130000_1_Vacation

DSC3:  20181029-130000_2_Vacation

In alphabetic sorting (e.g. file manager), they will then be listed in the wrong order, since the unique numbers '1' & '2' are before the 'V' in the alphabet -- Pic 1 will be listed after Pic 2 & 3. I ran into this when trying to make an animated GIF recently.

I think {unique} should add a _0 per default or, of course better yet, be aware if there's a conflict coming up and only add the _0 in such case.

[Jack Marxer]

I meant that it might be preferable for digiKam to number duplicates (including the first photo) with _01, _02, _03, etcetera.

On Mon, Oct 29, 2018 at 12:32 PM HaJo Schatz <[hidden email]> wrote:

On Mon, Oct 29, 2018 at 3:57 PM Jack Marxer <[hidden email]> wrote:

If there are duplicates and {unique}, why not number them with _01, _02, _03, etcetera?

Jack

On Mon, Oct 29, 2018 at 4:51 AM HaJo Schatz <[hidden email]> wrote:

Hi group,

Not sure if this was discussed earlier, apologies if so. I can open a bug/feature request if not. 

Assume the following batch rename string: 

[date:yyyyMMdd-hhmmss]{unique}_Vacation

If 3 photos have the same date/time they will be renamed as follows:

DSC1:  20181029-130000_Vacation

DSC2:  20181029-130000_1_Vacation

DSC3:  20181029-130000_2_Vacation

In alphabetic sorting (e.g. file manager), they will then be listed in the wrong order, since the unique numbers '1' & '2' are before the 'V' in the alphabet -- Pic 1 will be listed after Pic 2 & 3. I ran into this when trying to make an animated GIF recently.

I think {unique} should add a _0 per default or, of course better yet, be aware if there's a conflict coming up and only add the _0 in such case.

[Stefan Haag]

Hi all, for me there is the same issue when downloading from the camera. I am using a similar naming string.

I would also highly appreciate having always a "_1" or "_01" when using the {unique} Option. I am using a NAS for watching my pictures in a TV, and when there is a series oft pictures the first is always shown last due to the filename.

Regards

Stefan

Am 29. Oktober 2018 04:51:59 schrieb HaJo Schatz <[hidden email]>:

Hi group,

Not sure if this was discussed earlier, apologies if so. I can open a bug/feature request if not. 

Assume the following batch rename string: 

[date:yyyyMMdd-hhmmss]{unique}_Vacation

If 3 photos have the same date/time they will be renamed as follows:

DSC1:  20181029-130000_Vacation

DSC2:  20181029-130000_1_Vacation

DSC3:  20181029-130000_2_Vacation

In alphabetic sorting (e.g. file manager), they will then be listed in the wrong order, since the unique numbers '1' & '2' are before the 'V' in the alphabet -- Pic 1 will be listed after Pic 2 & 3. I ran into this when trying to make an animated GIF recently.

I think {unique} should add a _0 per default or, of course better yet, be aware if there's a conflict coming up and only add the _0 in such case.

[digikam-2]

I do my own unique by keeping the camera image counter in the
filename. My files are:

img_1234.cr2 and I rename then to text_yyyymmdd_1234.cr2 with:

text-[date:"yyyyMMdd"]-[file]{range:5,8}

Thanks

Syv

On Tue, 30 Oct 2018 14:34:20 +0100
Stefan Haag <[hidden email]> wrote:

> Hi all, for me there is the same issue when downloading from the
> camera. I am using a similar naming string. I would also highly
> appreciate having always a "_1" or "_01" when using the {unique}
> Option. I am using a NAS for watching my pictures in a TV, and when
> there is a series oft pictures the first is always shown last due
> to the filename.
>
>
> Regards
> Stefan
> Am 29. Oktober 2018 04:51:59 schrieb HaJo Schatz <[hidden email]>:
> > Hi group,
> >
> > Not sure if this was discussed earlier, apologies if so. I can
> > open a > bug/feature request if not.
> >
> > Assume the following batch rename string:
> > [date:yyyyMMdd-hhmmss]{unique}_Vacation
> >
> > If 3 photos have the same date/time they will be renamed as
> > follows: DSC1:  20181029-130000_Vacation
> > DSC2:  20181029-130000_1_Vacation
> > DSC3:  20181029-130000_2_Vacation
> >
> > In alphabetic sorting (e.g. file manager), they will then be
> > listed in the > wrong order, since the unique numbers '1' & '2'
> > are before the 'V' in the > alphabet -- Pic 1 will be listed
> > after Pic 2 & 3. I ran into this when > trying to make an
> > animated GIF recently.
> >
> > I think {unique} should add a _0 per default or, of course better
> > yet, be > aware if there's a conflict coming up and only add the
> > _0 in such case.
> >
> > Oh, away from the affected computer now. But it's digikam on
> > Fedora 28 from > the std repo, I must assume 5.9.0. Haven't
> > checked 6.0.0 yet...
> >
> > Thx a lot,
> > Hajo
> >
> > --
> > PGP key: http://tinyurl.com/2016PGPKEY 
>

--
sknahT

vyS

[Maik Qualmann]

The {unique} modifier can also prefix zeros {unique:n}, for example, for
"_001" then {unique:3}

Maik

Am Dienstag, 30. Oktober 2018, 15:26:25 CET schrieb [hidden email]:

> I do my own unique by keeping the camera image counter in the
> filename. My files are:
>
> img_1234.cr2 and I rename then to text_yyyymmdd_1234.cr2 with:
>
> text-[date:"yyyyMMdd"]-[file]{range:5,8}
>
> Thanks
>
> Syv
>
> On Tue, 30 Oct 2018 14:34:20 +0100
>
> Stefan Haag <[hidden email]> wrote:
> > Hi all, for me there is the same issue when downloading from the
> > camera. I am using a similar naming string. I would also highly
> > appreciate having always a "_1" or "_01" when using the {unique}
> > Option. I am using a NAS for watching my pictures in a TV, and when
> > there is a series oft pictures the first is always shown last due
> > to the filename.
> >
> >
> > Regards
> > Stefan
> >
> > Am 29. Oktober 2018 04:51:59 schrieb HaJo Schatz <[hidden email]>:
> > > Hi group,
> > >
> > > Not sure if this was discussed earlier, apologies if so. I can
> > > open a > bug/feature request if not.
> > >
> > > Assume the following batch rename string:
> > > [date:yyyyMMdd-hhmmss]{unique}_Vacation
> > >
> > > If 3 photos have the same date/time they will be renamed as
> > > follows: DSC1:  20181029-130000_Vacation
> > > DSC2:  20181029-130000_1_Vacation
> > > DSC3:  20181029-130000_2_Vacation
> > >
> > > In alphabetic sorting (e.g. file manager), they will then be
> > > listed in the > wrong order, since the unique numbers '1' & '2'
> > > are before the 'V' in the > alphabet -- Pic 1 will be listed
> > > after Pic 2 & 3. I ran into this when > trying to make an
> > > animated GIF recently.
> > >
> > > I think {unique} should add a _0 per default or, of course better
> > > yet, be > aware if there's a conflict coming up and only add the
> > > _0 in such case.
> > >
> > > Oh, away from the affected computer now. But it's digikam on
> > > Fedora 28 from > the std repo, I must assume 5.9.0. Haven't
> > > checked 6.0.0 yet...
> > >
> > > Thx a lot,
> > > Hajo
> > >
> > > --
> > > PGP key: http://tinyurl.com/2016PGPKEY

[hajo]

Thx Maik!

That is interesting & helpful to know. But unfortunately, it does not solve the original problem -- the first photo in a series still doesn't get a number attached...

Gilles, I know you are the master of all features & problems of Digikam. Any thoughts about this?

On Wed, Oct 31, 2018 at 7:01 PM Maik Qualmann <[hidden email]> wrote:

The {unique} modifier can also prefix zeros {unique:n}, for example, for
"_001" then {unique:3}

Maik

Am Dienstag, 30. Oktober 2018, 15:26:25 CET schrieb [hidden email]:
> I do my own unique by keeping the camera image counter in the
> filename. My files are:
>
> img_1234.cr2 and I rename then to text_yyyymmdd_1234.cr2 with:
>
> text-[date:"yyyyMMdd"]-[file]{range:5,8}
>
> Thanks
>
> Syv
>
> On Tue, 30 Oct 2018 14:34:20 +0100
>
> Stefan Haag <[hidden email]> wrote:
> > Hi all, for me there is the same issue when downloading from the
> > camera. I am using a similar naming string. I would also highly
> > appreciate having always a "_1" or "_01" when using the {unique}
> > Option. I am using a NAS for watching my pictures in a TV, and when
> > there is a series oft pictures the first is always shown last due
> > to the filename.
> >
> >
> > Regards
> > Stefan
> >
> > Am 29. Oktober 2018 04:51:59 schrieb HaJo Schatz <[hidden email]>:
> > > Hi group,
> > >
> > > Not sure if this was discussed earlier, apologies if so. I can
> > > open a > bug/feature request if not.
> > >
> > > Assume the following batch rename string:
> > > [date:yyyyMMdd-hhmmss]{unique}_Vacation
> > >
> > > If 3 photos have the same date/time they will be renamed as
> > > follows: DSC1:  20181029-130000_Vacation
> > > DSC2:  20181029-130000_1_Vacation
> > > DSC3:  20181029-130000_2_Vacation
> > >
> > > In alphabetic sorting (e.g. file manager), they will then be
> > > listed in the > wrong order, since the unique numbers '1' & '2'
> > > are before the 'V' in the > alphabet -- Pic 1 will be listed
> > > after Pic 2 & 3. I ran into this when > trying to make an
> > > animated GIF recently.
> > >
> > > I think {unique} should add a _0 per default or, of course better
> > > yet, be > aware if there's a conflict coming up and only add the
> > > _0 in such case.
> > >
> > > Oh, away from the affected computer now. But it's digikam on
> > > Fedora 28 from > the std repo, I must assume 5.9.0. Haven't
> > > checked 6.0.0 yet...
> > >
> > > Thx a lot,
> > > Hajo
> > >
> > > --
> > > PGP key: http://tinyurl.com/2016PGPKEY

[Maik Qualmann]

The serial processing in the rename tool does not allow us a simple solution
at the moment to realize that the first file has to be counted as well. This
requires major code changes.

Maik

Am Freitag, 2. November 2018, 14:07:37 CET schrieb HaJo Schatz:

> Thx Maik!
>
> That is interesting & helpful to know. But unfortunately, it does not solve
> the original problem -- the first photo in a series still doesn't get a
> number attached...
>
> Gilles, I know you are the master of all features & problems of Digikam.
> Any thoughts about this?
>
> On Wed, Oct 31, 2018 at 7:01 PM Maik Qualmann <[hidden email]> wrote:
> > The {unique} modifier can also prefix zeros {unique:n}, for example, for
> > "_001" then {unique:3}
> >
> > Maik
> >
> > Am Dienstag, 30. Oktober 2018, 15:26:25 CET schrieb
> >
> > [hidden email]:
> > > I do my own unique by keeping the camera image counter in the
> > > filename. My files are:
> > >
> > > img_1234.cr2 and I rename then to text_yyyymmdd_1234.cr2 with:
> > >
> > > text-[date:"yyyyMMdd"]-[file]{range:5,8}
> > >
> > > Thanks
> > >
> > > Syv
> > >
> > > On Tue, 30 Oct 2018 14:34:20 +0100
> > >
> > > Stefan Haag <[hidden email]> wrote:
> > > > Hi all, for me there is the same issue when downloading from the
> > > > camera. I am using a similar naming string. I would also highly
> > > > appreciate having always a "_1" or "_01" when using the {unique}
> > > > Option. I am using a NAS for watching my pictures in a TV, and when
> > > > there is a series oft pictures the first is always shown last due
> > > > to the filename.
> > > >
> > > >
> > > > Regards
> > > > Stefan
> > > >
> > > > Am 29. Oktober 2018 04:51:59 schrieb HaJo Schatz <[hidden email]>:
> > > > > Hi group,
> > > > >
> > > > > Not sure if this was discussed earlier, apologies if so. I can
> > > > > open a > bug/feature request if not.
> > > > >
> > > > > Assume the following batch rename string:
> > > > > [date:yyyyMMdd-hhmmss]{unique}_Vacation
> > > > >
> > > > > If 3 photos have the same date/time they will be renamed as
> > > > > follows: DSC1:  20181029-130000_Vacation
> > > > > DSC2:  20181029-130000_1_Vacation
> > > > > DSC3:  20181029-130000_2_Vacation
> > > > >
> > > > > In alphabetic sorting (e.g. file manager), they will then be
> > > > > listed in the > wrong order, since the unique numbers '1' & '2'
> > > > > are before the 'V' in the > alphabet -- Pic 1 will be listed
> > > > > after Pic 2 & 3. I ran into this when > trying to make an
> > > > > animated GIF recently.
> > > > >
> > > > > I think {unique} should add a _0 per default or, of course better
> > > > > yet, be > aware if there's a conflict coming up and only add the
> > > > > _0 in such case.
> > > > >
> > > > > Oh, away from the affected computer now. But it's digikam on
> > > > > Fedora 28 from > the std repo, I must assume 5.9.0. Haven't
> > > > > checked 6.0.0 yet...
> > > > >
> > > > > Thx a lot,
> > > > > Hajo
> > > > >
> > > > > --
> > > > > PGP key: http://tinyurl.com/2016PGPKEY