Optimum format for filenames?

[Guest]

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

"Owamanga" <owamanga-not-this-bit@hotmail.com> wrote in message
news:stqpd1dfd2j6b9e8506mpdf7it583gnai3@4ax.com...
> On Tue, 19 Jul 2005 10:29:52 +0200, "Morten L.Pedersen"
> <mlp@melped.dk> wrote:
>
> >"Owamanga" <owamanga-not-this-bit@hotmail.com> wrote in message
> >news:bmhnd1des6o3uef3dhr49jucp778kkfotm@4ax.com...
> >> On Mon, 18 Jul 2005 08:13:16 +0100, Terry Pinnell
> >> <terrypinDELETE@THESEdial.pipex.com> wrote:
> >>
> >>
> >> In view of the somewhat complicated approaches mentioned here, I
> >> prefer my current system (having moved away from a more structured,
> >> somewhat encrypted system that I used for films and negs).
> >>
> >> Here is an example directory snippet:
> >>
> >> Set044_Mar_2005_Renaissance_Festival
> >> Set045_Mar_2005_St_Patrics_Day
> >> Set046_Mar_2005_Universal_Studios
> >> Set047_Apr_2005_Key_Lago_Dolphins
> >> Set048_Apr_2005_Loxahatchee
> >> Set049_Apr_2005_Sprinkler
> >>
> >> Set number represents a 1Gb or under CF card being filled. I usually
> >> empty the card after any 'major' event, create the set and name it
> >> accordingly. Underscores are optional of course, and this system
> >> allows you to use whatever date format you are happy with because the
> >> set-number keeps them in chronological order. One set will often
> >> contain photos taken over a number of days, and the descriptive tag I
> >> choose is one that best describes the majority of the photos.
> >>
> >> Inside, the DSC_NNNN.NEF files get renamed to the set number:
> >>
> >> 048_0001.NEF
> >> 048_0002.NEF
> >> 048_0003.NEF
> >>
> >> and so on...., this keeps the filenames of the images unique, but
> >> still nice and small.
> >>
> >> Every few months I get around to making a small html based index in
> >> each set, for fast visual location of a particular file (using
> >> software that makes small thumbnails + 800x600 preview files, and
> >> exposes the EXIF data for each image).
> >>
> >> I'm too damn lazy to add EXIF descriptions for every shot or create
> >> some kind of database. Everything I print (using mpix.com) gets the
> >> filename printed on the back of the photo, which makes it easy to
> >> re-print if I need to.
> >>
> >> --
> >
> >With this approach it's difficult to find photos showing a particular
person
> >or photos with other specifich properties.
> >The EXIF/IPTC metadata-approach takes a little work and effort, but it
pays
> >off, when you need to find that one particular picture.
>
> I guess it depends heavily on your shooting habits. The subject of 70%
> of shots is my toddler, 25% is Florida wildlife and 5% is everything
> else. A searchable EXIF database has an extremely limited appeal for
> me. I can recall an image with good accuracy based on the event, and
> with my visual indexing system, finding the exact file is extremely
> rapid.
>

But when you're not here anymore, a lot of info about your pictures will die
with you.
If you find a box of old photographs with no comments written on the back -
they are not of much value to you when you don't know anything about who's
on the pictures, where were they taken and so on.
I try to treat my picturefiles as I treated my old negatives/paperprints. I
placed them in an album and wrote comments beside them. Then my children and
other people can get an idea about whats on the pictures, when they look at
them 50 years from now...

regards


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

 

[Guest]

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

On Tue, 19 Jul 2005 16:10:42 +0200, "Morten L.Pedersen"
<mlp@melped.dk> wrote:

>But when you're not here anymore, a lot of info about your pictures will die
>with you.

That is true, yes. I'm not at all certain that an EXIF database will
help. It'll probably disappear long before me. Tagging the files is
the only hope, and I'm simply too lazy.

>If you find a box of old photographs with no comments written on the back -
>they are not of much value to you when you don't know anything about who's
>on the pictures, where were they taken and so on.

Usually the set names cover the general 'where' bit, of course the
EXIF copes with the date. The 'who' is still missing, yes...

>I try to treat my picturefiles as I treated my old negatives/paperprints. I
>placed them in an album and wrote comments beside them. Then my children and
>other people can get an idea about whats on the pictures, when they look at
>them 50 years from now...

Okay, maybe I'll add a text file alongside the images describing the
batch in more detail, and specific people in specific shots.
(Presuming of course the electronic version of the images survive any
significant amount of time - something which I can't guarantee.)

Over the last year I've been slowly scanning all my family slides -
dating back from the early 50's. I named each slide with the people,
date, and location. These are destined to become a slideshow on a DVD
(I've done one already, the extended family loved it), but having
since received another batch from the same time period, I need to
re-do it.

For this I want to put that filename info onto the subtitle track, so
the viewer can switch it on or off as needed. On the first try, I
grouped each batch of slide based on the decade it was shot, and added
music from that era. The software I used lets you pan & zoom, and
cross-fades which added interest and kept the thing from becoming
tedious. It was cool, and I'll be making another one from my recent
D70 photos.

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

 

[Guest]

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

Owamanga <owamanga-not-this-bit@hotmail.com> wrote:

<snip>

>Over the last year I've been slowly scanning all my family slides -
>dating back from the early 50's. I named each slide with the people,
>date, and location. These are destined to become a slideshow on a DVD
>(I've done one already, the extended family loved it), but having
>since received another batch from the same time period, I need to
>re-do it.
>
>For this I want to put that filename info onto the subtitle track, so
>the viewer can switch it on or off as needed. On the first try, I
>grouped each batch of slide based on the decade it was shot, and added
>music from that era. The software I used lets you pan & zoom, and
>cross-fades which added interest and kept the thing from becoming
>tedious. It was cool, and I'll be making another one from my recent
>D70 photos.

I'm doing almost exactly the same here. Some of my photos are
hand-me-downs, and go back to about 1940. What DVD software are you
using? I have MemoriesOnTV, but that has no 'subtitle' track. (I can
add text captions either as part of an image or a separate text-only
image.) And I too am trying to come up with appropriate soundtracks
for each decade. Good fun, but time-consuming stuff!

--
Terry, West Sussex, UK

 

[Guest]

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

On Tue, 19 Jul 2005 18:45:14 +0100, Terry Pinnell
<terrypinDELETE@THESEdial.pipex.com> wrote:

>Owamanga <owamanga-not-this-bit@hotmail.com> wrote:
>
><snip>
>
>>Over the last year I've been slowly scanning all my family slides -
>>dating back from the early 50's. I named each slide with the people,
>>date, and location. These are destined to become a slideshow on a DVD
>>(I've done one already, the extended family loved it), but having
>>since received another batch from the same time period, I need to
>>re-do it.
>>
>>For this I want to put that filename info onto the subtitle track, so
>>the viewer can switch it on or off as needed. On the first try, I
>>grouped each batch of slide based on the decade it was shot, and added
>>music from that era. The software I used lets you pan & zoom, and
>>cross-fades which added interest and kept the thing from becoming
>>tedious. It was cool, and I'll be making another one from my recent
>>D70 photos.
>
>I'm doing almost exactly the same here. Some of my photos are
>hand-me-downs, and go back to about 1940. What DVD software are you
>using? I have MemoriesOnTV, but that has no 'subtitle' track. (I can
>add text captions either as part of an image or a separate text-only
>image.) And I too am trying to come up with appropriate soundtracks
>for each decade. Good fun, but time-consuming stuff!

Canopus Imaginate

http://www.canopus.us/US/products/Imaginate2/pm_imaginate2.asp

Quality was superb - zooms pans etc are jitter-free, but it's hardly a
single-click operation, and I had to use other authoring software to
get the AVI's it made onto a DVD. I could add the soundtrack, but
needed to do the fade in other software. I recall it had a some stupid
limitation of around 100 pictures in any one sequence too.

So, basically it made me a DV compliant video sequence containing the
slide show. This meant I could (but didn't) bring it into premiere for
bits of home video to be included in the mix. I also got to build my
own DVD menu and stuff. Lots of control, but far too much work really.

Subtitles I need to investigate further, I have no experience of them
at all.

MemoriesOnTV looks quite good, I may DL the trial version they have,
it's a quarter the price of Imaginate too.

Given it's the limitation of no subtitle support, maybe simply
creating 2 nearly identical titles on the DVD - One clean one with no
text, and the other with text describing each image (MOTV supports
that). Two versions of one half-hour slide show should fit nicely onto
the disk.

I'm gonna have the same problem when I get round to editing my DV home
videos and putting them onto DVD - I want to retain the date/time
info, and a subtitle track is the perfect place for it, so I've really
got to figure out how these are authored, and what software is needed.

Either that, (still on home video here) or between scenes add little
title pages that describe the location, date etc. I guess the time
isn't *that* relevant.

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

 

[Guest]

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

On Tue, 19 Jul 2005 18:45:14 +0100, Terry Pinnell
<terrypinDELETE@THESEdial.pipex.com> wrote:

>And I too am trying to come up with appropriate soundtracks
>for each decade. Good fun, but time-consuming stuff!

(I didn't read your post fully the first time...)

alt.binaries.sounds.1940s.mp3
alt.binaries.sounds.1950s.mp3
alt.binaries.sounds.1960s.mp3
alt.binaries.sounds.1970s.mp3
alt.binaries.sounds.1980s.mp3

...I can see a pattern here..

Usenet is a very handy resource for this type of project. I'm blessed
with easynews as my provider who have a web-based global search just
to make things really simple.

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

 

[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.
>