Automatic renaming made optional

[GoogleCodeExporter]

why is Automatic renaming "advised?"

What is the advantage for jBrout? It's cool for the file explorer, because
pictures are in the good order - even when differents cameras are used -
but i think jBrout is able to order picture with it's own database... Am I
wrong?

By renaming some pictures, you may loose useful information...  Sometimes I
put some pictures from one album to another... For example, I have an album
of greece with pictures called greece(1).jpg, greece(2).jpg and I have put
some older pictures on this album to illustrate my album (it mainly
pictures of cities roadsign ("Panneaux de ville")) and they are put at
differents parts of the album greece(4).jpg etc... 

Now all roadsign pictures are at the beginning and there is no way to go
back...

If it's possible, I think it may be useful to store the old name somewere
on the picture (if there any exif/iptc/other tag free for that?) to be able
to go back...

But at least, I think it may be better not to advice to activate automatic
renaming....

Original issue reported on code.google.com by gautier....@gmail.com on 10 Jan 2009 at 8:41

[GoogleCodeExporter]

I can partially answer to your question: because almost all other automatic 
names are
worthless! Actually, the install should advise to rename if the user uses the
original camera names. But you are right that if the user took the trouble to 
rename
his files, letting jBrout rename them again is probably a bad idea. I suggest 
that
the install dialog should be modified say this clearly. Furthermore, if for some
reason (ill-behaved image editor) the Date tag is lost, the automatic renaming 
can
not give a correct name to the file. What does jBrout do in this case? Does he 
rename
even if the tag is not there and uses the file date (bad idea IMO) or does he 
skip
renaming the file?

Original comment by davito...@gmail.com on 10 Jan 2009 at 11:50

[GoogleCodeExporter]

> Furthermore, if for some reason (ill-behaved image editor)
> the Date tag is lost, the automatic renaming can not give
> a correct name to the file. What does jBrout do in this
> case? Does he rename even if the tag is not there and uses
> the file date (bad idea IMO) or does he skip renaming the file?

In older jbrout 0.2 : files without exif, so without exif dates, were not 
renamed
In newer : files without exif are "minimal exif taggued" at the first import 
process
by jBrout ...and exif dates are set according filedate ...
so every files can now be renamed(handled) accordind exif dates ...

In the past, I had got an old old apn (kodak ez200) with pictures without exif 
tags. 
I found it very logical to store in exif the "file date" (which is near of 
reality).
(It makes sense, because in 0.2 version filedate ware strongly preserved by any
operations in jbrout). Because, since 0.3, filedates can be changed by a jbrout
operation. 

Original comment by manat...@gmail.com on 10 Jan 2009 at 1:33

[GoogleCodeExporter]

> What is the advantage for jBrout?

another big advantage : it's easier to find duplicates in its collection (same 
names)

Original comment by manat...@gmail.com on 10 Jan 2009 at 1:35

[GoogleCodeExporter]

manatlan, about your comment 2: I think the current behaviour is not always the 
best:
if one of my pictures has it's Date tag erased by a "bad" software, the picture 
will
be renamed by jBrout and I may look for it a long time because the date which 
jBrout
will use will be meaningless for me. IMO this behaviour should be optional.

Original comment by davito...@gmail.com on 10 Jan 2009 at 2:58

[GoogleCodeExporter]

Sure ...

but it's up to you to not use a bad software ;-)
be careful with yours pictures ! (btw, "external tools" are done for that ...)

There's no many choices ... If I want to put any pictures in jBrout, and 
pictures
with no exif : no others choices than to create a "minimal exif set" ... and if 
I
done that, I need "a date" ... and the only date I have, is the file date.
I did'nt want to continue to manage this kind of pictures (no exif) in jbrout 
(like
in 0.2 versions) ... Now with 0.3 : it's a lot less complex to do that ..

Original comment by manat...@gmail.com on 11 Jan 2009 at 1:11

[GoogleCodeExporter]

manatlan, be sensible! Can you show me a list of "bad" software, or of "good"
software? How can the average user check if he's taking a risk or even doing
something wrong? You can't expect every jBrout user to have a computer science 
degree!

You don't have many choices, I agree, but you did have other choices. Many 
database
programmers I know think that bad data is worse than no data. By setting the 
date to
a wrong value (the file date can be anything: editing, download...) you create 
bad
data, you hide the fact that the date is wrong. I'd rather have jBrout use a
arbitrary date i.e. 01/01/1900. Thus the user would know which pictures are not
correctly dated and has a chance to set a correct date to them. 

Furthermore, if a user avoids jBrout's offer of renaming files, he still has a 
chance
to set a (more) correct date to the picture: I keep the original name almost
unchanged, so that I can often estimate the correct date and even time by 
looking at
the previous and following picture. But if all files are renamed to timestamps, 
this
is not possible any more.

Original comment by davito...@gmail.com on 11 Jan 2009 at 2:08

[GoogleCodeExporter]

I agree with that... I've spend a lot of time to find pictures with false 
dates...
For almost (all?) of my pictures, it's a software used to modify the picture 
which
has removed the exif data... So since files are modified, the picture's date is
always wrong... :(

I suggest : 
Do not set an unsure date on the file... 01/01/1900 is okay for me... (So it 
will be
easy to find every picture with a false exif date)
Do not rename pictures if there is no way to go back (save the filename 
somewhere on
the picture for example)...

And there is no unwanted duplicates on my albums! ;) 

It's too late for me, but I hope it will avoid jbrout frustrating... :) 

Original comment by gautier....@gmail.com on 11 Jan 2009 at 3:12

[GoogleCodeExporter]

i love that functionality (Automatic renaming)
please don't remove it

Original comment by thibaut....@gmail.com on 31 Jan 2009 at 5:54

[GoogleCodeExporter]

Nobody want this feature to be removed, I just think that it's not necessary to
advice to enable this feature... And, as said by davidtofr, it may be useful to
prevent people of the unwanted effects which may happen...

I also think it may be useful to store the old name somewhere in the picture, 
to be
able to go back... It can be a tag like "jbrout_original_name:I2726.jpg" but 
there
should be better solutions...

I've also find another problem with this function : when you've picture and 
movies
taken by your camera, only pictures are renamed... With my camera, it's almost
impossible to retrieve the correct order because the date is not mentioned in 
the
movie data...

Original comment by gautier....@gmail.com on 31 Jan 2009 at 10:50

[GoogleCodeExporter]

better use 01/01/1970 for compatibilty with other date formats (timestamp&co).
or ask the behavior for no date present also in the starting dialog.

Original comment by lome...@googlemail.com on 14 Oct 2009 at 2:51

[GoogleCodeExporter]

I don't use jbrout automatic renaming since I have my own renaming scheme. I 
have a script which does that (and maybe tries to rename videos based on the 
accompanying thumbnail). The scheme I use the original name AND the date (but 
no time) leading to a name like: pyyyymmjj-original_name.jpg (and vyy... for 
videos but that wasn't necessarily a good idea). And since I rarely rename 
picture, the original name is usually the one given by the camera. 

Maybe we could have an extensible renaming system, using a simple formatting 
string like: 
{date}-{time}-{originalname}
I've used some id3 programs (like kid3) for renaming mp3 files which use 
something of the kind. 

Original comment by chartier...@gmail.com on 8 Jun 2010 at 9:27

[GoogleCodeExporter]

Maybe could we have a confirmation before renaming files?
At each import (it's not that frequent) asking "do you want to rename all 
files?".
And creating a backup-batch would be useful, like
rename "dir/new_name1.jpg" "dir/old_name1.jpg"
so the (advanced) user could execute this batch to have his filenames back

Original comment by p...@gmx.fr on 9 Oct 2010 at 5:08

[GoogleCodeExporter]

I think if somebody provides patches for this enhancement, it would be added. 
Otherwise, I don't see much enthusiasm among the regular developers to fix this.

Original comment by matej.c...@gmail.com on 12 Aug 2013 at 10:04

• Changed title: Automatic renaming made optional
• Changed state: Accepted
• Added labels: OpSys-All, Priority-Low, Type-Enhancement