Optimum format for filenames?

[Guest]

Archived from groups: rec.photo.digital (More info?)

On Mon, 18 Jul 2005 08:13:16 +0100, Terry Pinnell wrote:

> In particular, with future sorting in mind, I vary between making the
> major field the Date/Time Taken, or some keyword about the subject.
> For example, my photo taken at 4:26pm yesterday on a walk from a place
> called Exceat could be renamed from
> DSC0005.jpg to
> 2005-07-17-09-16-26-Exceat.JPG
> or
> Exceat-2005-07-17-09-16-26-Exceat.JPG

That looks like [July 17, 2005] [09] [4:26PM] [Exceat.JPG] to me.
Since most cameras can take many pictures in less than one minute,
would the 09 be a misplaced 'seconds' counter, where the time was
4:26:09PM? You'd need a seconds counter if you took several
pictures rapidly in Exceat. Here's hoping you don't get (and use) a
camera that can take long rapid bursts of pictures where you might
end up with more than 60 shots taken within a minute. Maybe your
current camera can't do that, but you might want to plan in advance
for the camera you might be using 3 years from now. In that case a
unique sequential key would help. They're generally used in
relational and other database tables and might be a worthwhile
addition to your naming scheme, even if you don't plan on using a
database to keep track of your photos in the near future.

 

[Ralph]

Archived from groups: rec.photo.digital (More info?)

Terry, I forgot to add that I also place the date folders into a year
folder. This reduces the number of folders I am presented with. I usually do
this every couple of months. i don't shoot often enough to worry about
monthly folders.

--
remove n u m b e r s to reply
Terry Pinnell wrote in message ...
>"Ralph" <Ralph.Smith2@team4.telstra6.com> wrote:
>
>>I guess it depends upon how many photos you take. I take drga racing and
>>family photos, not commercial.
>>I store my photos in folders with the date they were taken.
>>I then browse the new directories with IrfanView thumbnails to determine
>>what was taken on each date. I then make a brief note of what is each
>>directory in a spreadsheet. The spreadsheet has a different page for each
>>year and the entries are in date order.
>
>Many thanks for the many further replies. Several new ideas I hadn't
>previously considered seriously, especially:
>- dated *folders* rather than (or in addition to) dated filenames
>- the complementary use of a spreadsheet to aid retrieval (at the cost
>of additional input effort)
>
>--
>Terry, West Sussex, UK
>

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

Terry Pinnell wrote:
> I'd appreciate learning what format others have chosen for renaming
> photos please. Despite much experiment, I've still not settled on
> anything consistent!
>
> In particular, with future sorting in mind, I vary between making
> the
> major field the Date/Time Taken, or some keyword about the subject.
> For example, my photo taken at 4:26pm yesterday on a walk from a
> place
> called Exceat could be renamed from
> DSC0005.jpg to
> 2005-07-17-09-16-26-Exceat.JPG
> or
> Exceat-2005-07-17-09-16-26-Exceat.JPG
>
> But, assuming I do settle on making Date/Time Taken the major sort,
> there are so many formats possible for that. I've tried:
> 2005-07-17-09-16-26
> 2005-07-17 09.16.26
> 05-07-17 09.16.26 (that space can cause problems)
> 2005Jul17-16.26
> 2005Jul17-16.26
> 2005Jul17-16:26 (looks better but often the ':' screws up)
>
> and more. What do others use please?

Way back in history (couple years ago) I used jhead to translate EXIF
time (to the second) and date into file names, using a batch file.
Filenames looked this way:
2003_06_01_140224
Very little likelihood of duplicate file names.
I stored them in folders named for the camera and date they were made:
nA20030601 nA being a nikon CP995.

Somehow over the years I lost track of the benefits of renaming the
files _per_ EXIF, and today the originals maintain camera-assigned
names:
_MG_2231.CR2
They are stored in folders named for the camera and the date they were
copied from the CF card to to a drive, and the drive designation; I
add the number of the last frame in the folder:
20d_20050221_d_2231

After copying the files from the card to the working drive, I copy the
entire folder to an external drive (and rename the folder according to
its new location:
20d_20050221_k_2231), where it languishes until the drive is full,
when I replace it and pack it off to a safe place.

When pictures are modified (that is, a new file is made based on the
content of the original), I replace the camera-assigned prefix with a
descriptive abbreviation:
worldEnds_2231.PSD
subsequent versions are designated by appropriate crypts:
worldEnds_2231c.PSD ("c" for "crop"; "m" for "modified"; "p" for
"print optimized"; "t" for "thumbnail"; "w" for "web"; _etc_).

Files that have been awarded real names are stored in folders named
after projects:
worldEnds200506
Projects are stored in folders named for their era (year and month)
200506
All these are copied to the external drive folder called "projects"
from time to time.

Someday soon I will probably lose track of the general date-area
certain pictures were made, and my searches will become more
difficult; so far it has been pretty easy finding a particular
picture. I use "Agent Ransack" to search for filenames that have been
key-word implanted. It works quick and well.
http://www.mythicsoft.com/agentransack/default.aspx

Since the camera-assigned mumber is always associated with every
version of the picture, finding the original and all declensions is
relatively quick.

I didn't plan this scheme: it just grew, but is pretty consistently
applied since about December last year. I'd like to be more organized,
but you know how it is with artists...

--
Frank ess

"Verbing wierds language."
-Calvin

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

Terry Pinnell wrote:

> Many thanks for the many further replies. Several new ideas I hadn't
> previously considered seriously, especially:
> - dated *folders* rather than (or in addition to) dated filenames
> - the complementary use of a spreadsheet to aid retrieval (at the cost
> of additional input effort)

I don't know what kind of background you have, but the issue falls
under the general rubric of "database design", for which there are many
texts. Perhaps too many ;-/ If you have or plan on gathering a large
collection of images, I advise you to ditch the 'spreadsheet' and use a
formal RDBMS

http://en.wikipedia.org/wiki/RDBMS

I've been slowly developing a simple scheme around the normal
filesystem for image and image meta-data storage and MySQL and some
shell scripts to index the lot automatically.

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

Terry Pinnell <terrypinDELETE@THESEdial.pipex.com> wrote:

<snip>

>For example, my photo taken at 4:26pm yesterday on a walk from
>a place called Exceat could be renamed from
>DSC0005.jpg to
>2005-07-17-09-16-26-Exceat.JPG

Just noticed my careless slip above. Rather academic at this late
stage of the thread, but for the record (and anyone seeing this thread
in future) it should of course read:
"For example, my photo taken at about 9:16am yesterday..."

--
Terry, West Sussex, UK

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

ASAAR <caught@22.com> wrote:

>On Mon, 18 Jul 2005 08:13:16 +0100, Terry Pinnell wrote:
>
>> In particular, with future sorting in mind, I vary between making the
>> major field the Date/Time Taken, or some keyword about the subject.
>> For example, my photo taken at 4:26pm yesterday on a walk from a place
>> called Exceat could be renamed from
>> DSC0005.jpg to
>> 2005-07-17-09-16-26-Exceat.JPG
>> or
>> Exceat-2005-07-17-09-16-26-Exceat.JPG
>
> That looks like [July 17, 2005] [09] [4:26PM] [Exceat.JPG] to me.
>Since most cameras can take many pictures in less than one minute,
>would the 09 be a misplaced 'seconds' counter, where the time was
>4:26:09PM? You'd need a seconds counter if you took several
>pictures rapidly in Exceat. Here's hoping you don't get (and use) a
>camera that can take long rapid bursts of pictures where you might
>end up with more than 60 shots taken within a minute. Maybe your
>current camera can't do that, but you might want to plan in advance
>for the camera you might be using 3 years from now. In that case a
>unique sequential key would help. They're generally used in
>relational and other database tables and might be a worthwhile
>addition to your naming scheme, even if you don't plan on using a
>database to keep track of your photos in the near future.

Sorry, that was my slip! It should of course read:
"For example, my photo taken at about 9:16am yesterday..."

Only spotted it now, on reading your post - thanks <g>.

--
Terry, West Sussex, UK

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

Ralph wrote:

> The advantage of a spreadsheet over a database is that it is more likely to
> be readable in the future. A plain text file would be even more future proof
> IMO.

Why stop there? Why not etch it in cuneiform onto clay tablets and
bake them in a kiln for 3 days? If it wasn't for the USA, people would
still be digging this sort of thing out of the ground in Iraq 5
thousand years later.

Of course, if a "plain text file" is in fact "future proof", then you
can always ask your RDBMS to just export your table(s) as such.

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

On Thu, 21 Jul 2005 09:41:21 +0100, Terry Pinnell wrote:

>> That looks like [July 17, 2005] [09] [4:26PM] [Exceat.JPG] to me.
>
> Sorry, that was my slip! It should of course read:
> "For example, my photo taken at about 9:16am yesterday..."

No problem, there was plenty of context in your message so what
you were asking about in the OP was clear. I just wondered if there
was any special significance to the "09" and if so what it might be,
all the while mentally hearing Lennon's(?) voice proclaiming "Number
9. Number 9. Number 9 . . .".

 

[Guest]

Archived from groups: rec.photo.digital (More info?)

On 21 Jul 2005 12:03:15 -0700, eawckyegcy@yahoo.com wrote:

>Ralph wrote:
>
>> The advantage of a spreadsheet over a database is that it is more likely to
>> be readable in the future. A plain text file would be even more future proof
>> IMO.
>
>Why stop there? Why not etch it in cuneiform onto clay tablets and
>bake them in a kiln for 3 days? If it wasn't for the USA, people would
>still be digging this sort of thing out of the ground in Iraq 5
>thousand years later.
>
>Of course, if a "plain text file" is in fact "future proof", then you
>can always ask your RDBMS to just export your table(s) as such.

Sure, ASCII is about as future proof as EBCDIC was.

<g>

--
Owamanga!
http://www.pbase.com/owamanga

 

[Ralph]

Archived from groups: rec.photo.digital (More info?)

The advantage of a spreadsheet over a database is that it is more likely to
be readable in the future. A plain text file would be even more future proof
IMO.

--
remove n u m b e r s to reply
eawckyegcy@yahoo.com wrote in message
<1121882858.789973.244170@g43g2000cwa.googlegroups.com>...
>Terry Pinnell wrote:
>
>> Many thanks for the many further replies. Several new ideas I hadn't
>> previously considered seriously, especially:
>> - dated *folders* rather than (or in addition to) dated filenames
>> - the complementary use of a spreadsheet to aid retrieval (at the cost
>> of additional input effort)
>
>I don't know what kind of background you have, but the issue falls
>under the general rubric of "database design", for which there are many
>texts. Perhaps too many ;-/ If you have or plan on gathering a large
>collection of images, I advise you to ditch the 'spreadsheet' and use a
>formal RDBMS
>
>http://en.wikipedia.org/wiki/RDBMS
>
>I've been slowly developing a simple scheme around the normal
>filesystem for image and image meta-data storage and MySQL and some
>shell scripts to index the lot automatically.
>