Sign in with
Sign up | Sign in
Your question

How do you label your digital photos?

Last response: in Digital Camera
Share
June 26, 2005 3:10:18 PM

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

I would like to be able to assign keywords to every digital photos so
that I can later seach by key words. Is there a pdrogram that would
allow me to do this?

More about : label digital photos

Anonymous
June 26, 2005 3:10:19 PM

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

Jack wrote:
> I would like to be able to assign keywords to every digital photos so
> that I can later seach by key words. Is there a pdrogram that would
> allow me to do this?
Well you can in fact do this in Windows XP, right click then go to
properties and set the keywords, but this does not work all that will,
you can search by keyword by it is slow.

There are a lot of programs out there that will do this kind of thing,
we all have the ones we like, you might want to try a few as there is
normally a free trial period will all of them.

I use ACDSee, which for me works great.

I organize my photos a bit differently then most people, I have a
directory for each year and then under those directories I have one for
each day that I shoot photos. I then pick on photo from each day that
best represents what was going on that day and these all get put into a
category (something like keywords). I can then open the list of off
the key photos and from this pretty much figure out what day I am
looking for. If there is a lot going on in a day I might put in two or
three photos from it into the category.

Scott
Anonymous
June 26, 2005 3:49:27 PM

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

Jack,

As the others have already said, there are several great programs for
this task. I use IMatch and like it very much for the task of
cataloging images. It does require a little time on your part to learn
it, but I think it's worth the time.

You can get more info here: http://photools.com

Charlie
http://FlyingSamPhoto.com
Got digital photos? Show them off!
Related resources
Anonymous
June 26, 2005 5:41:51 PM

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

"Jack" <memenme@email.com> wrote in message
news:h4htb15qpfctocslc088tgv0bb2585svuq@4ax.com...
>I would like to be able to assign keywords to every digital photos so
> that I can later seach by key words. Is there a pdrogram that would
> allow me to do this?

The best way is to use a long file name for the pictures. WinXP allows up to
256 character file names.

I start the filename with the date so they sort chronologically in a
directory.

I then name the place or the people from left to right and maybe what they
are doing like:

2005BlackRockDesertJaneCutyRobinBalkDwainSuplovShowingOff.jpg

It takes a bit of time to makeup the filenames but they will be understood
generations later.

ER
Anonymous
June 26, 2005 6:38:45 PM

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

ER wrote:
> "Jack" <memenme@email.com> wrote in message
> news:h4htb15qpfctocslc088tgv0bb2585svuq@4ax.com...
>> I would like to be able to assign keywords to every digital photos
>> so
>> that I can later seach by key words. Is there a pdrogram that
>> would
>> allow me to do this?
>
> The best way is to use a long file name for the pictures. WinXP
> allows up to 256 character file names.
>
> I start the filename with the date so they sort chronologically in a
> directory.
>
> I then name the place or the people from left to right and maybe
> what
> they are doing like:
>
> 2005BlackRockDesertJaneCutyRobinBalkDwainSuplovShowingOff.jpg
>
> It takes a bit of time to makeup the filenames but they will be
> understood generations later.
>
> ER

Those that are not truncated by certain PS save functions, anyway. Why
do they do that?

--
Frank ess
Anonymous
June 26, 2005 7:09:57 PM

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

"Frank ess" <frank@fshe2fs.com> wrote in message
news:-4idnXvcc7n0vSLfRVn-uA@giganews.com...
> ER wrote:
>> "Jack" <memenme@email.com> wrote in message
>> news:h4htb15qpfctocslc088tgv0bb2585svuq@4ax.com...
>>> I would like to be able to assign keywords to every digital photos so
>>> that I can later seach by key words. Is there a pdrogram that would
>>> allow me to do this?
>>
>> The best way is to use a long file name for the pictures. WinXP
>> allows up to 256 character file names.
>>
>> I start the filename with the date so they sort chronologically in a
>> directory.
>>
>> I then name the place or the people from left to right and maybe what
>> they are doing like:
>>
>> 2005BlackRockDesertJaneCutyRobinBalkDwainSuplovShowingOff.jpg
>>
>> It takes a bit of time to makeup the filenames but they will be
>> understood generations later.
>>
>> ER
>
> Those that are not truncated by certain PS save functions, anyway.

>Why do they do that?
>

Because they don't follow Windows program design guidelines.

ER
June 26, 2005 10:38:54 PM

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

On Sun, 26 Jun 2005 13:41:51 -0700, "ER" <evad@dodgeit.com> wrote:

>
>"Jack" <memenme@email.com> wrote in message
>news:h4htb15qpfctocslc088tgv0bb2585svuq@4ax.com...
>>I would like to be able to assign keywords to every digital photos so
>> that I can later seach by key words. Is there a pdrogram that would
>> allow me to do this?
>
>The best way is to use a long file name for the pictures. WinXP allows up to
>256 character file names.
>
>I start the filename with the date so they sort chronologically in a
>directory.
>
>I then name the place or the people from left to right and maybe what they
>are doing like:
>
>2005BlackRockDesertJaneCutyRobinBalkDwainSuplovShowingOff.jpg
>
>It takes a bit of time to makeup the filenames but they will be understood
>generations later.
>
>ER
>
>

Problem is CDs only take 64 letters...
Anonymous
June 26, 2005 10:56:56 PM

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

I've been using ACDsee for a few years, very nice. And their FotoSlate
plugin for printing is also very good. If you signup for and download
the free trial for ACDsee after a while they typically send an email
with special pricing for all their products.

"Jack" <memenme@email.com> wrote in message
news:h4htb15qpfctocslc088tgv0bb2585svuq@4ax.com...
>I would like to be able to assign keywords to every digital photos so
> that I can later seach by key words. Is there a pdrogram that would
> allow me to do this?
Anonymous
June 27, 2005 12:08:04 AM

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

On Sun, 26 Jun 2005 11:10:18 -0400, Jack <memenme@email.com> wrote:

>I would like to be able to assign keywords to every digital photos so
>that I can later seach by key words. Is there a pdrogram that would
>allow me to do this?

There are many program that will let you do this, only problem is
when you find another program that suits your needs better and you
have to enter the keywords all over again!

IfranView supports IPTC editing, isn't that information embedded in
the pictures? How searchable IPTC is I do not know.
June 27, 2005 12:24:14 AM

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

Thanks for all the suggestions and info. I should have also mention
that I have now the Canon SW that came with my 20D, PSCS2 and
Faststone Image Viewer. After paying for the CS2 (even though it's
education version), there's very little justification in buying other
programs. So, are there any freebies that I should try out, or does
any of the ones I have can do what I want. Thanks to all again.
Anonymous
June 27, 2005 12:58:23 AM

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

Bob commented courteously...

> Problem is CDs only take 64 letters...

That's with the Joliet file system. If you use UDF (Universal Disk
Format), you can use up to 115 characters.

--
ATM, aka Jerry
June 27, 2005 2:12:33 AM

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

On Sun, 26 Jun 2005 11:10:18 -0400, Jack <memenme@email.com> wrote:

>I would like to be able to assign keywords to every digital photos so
>that I can later seach by key words. Is there a pdrogram that would
>allow me to do this?

Photools iMatch
http://www.photools.com/index.php?PHPSESSID=01c917158cf...
Drifter
"I've been here, I've been there..."
June 27, 2005 2:30:16 AM

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

On Sun, 26 Jun 2005 20:58:23 -0500, All Things Mopar <noneofyour@busi.ness>
wrote:

>Bob commented courteously...
>
>> Problem is CDs only take 64 letters...
>
>That's with the Joliet file system. If you use UDF (Universal Disk
>Format), you can use up to 115 characters.

Is that a completely compatible system? Does Easy CD Creator do it?
June 27, 2005 6:54:33 AM

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

Try Picasa..........it's FREE from Google: http://www.picasa.com/index.php


"Jack" <memenme@email.com> wrote in message
news:h4htb15qpfctocslc088tgv0bb2585svuq@4ax.com...
>I would like to be able to assign keywords to every digital photos so
> that I can later seach by key words. Is there a pdrogram that would
> allow me to do this?
Anonymous
June 27, 2005 10:38:40 AM

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

Bob commented courteously...

>>> Problem is CDs only take 64 letters...
>>
>>That's with the Joliet file system. If you use UDF
>>(Universal Disk Format), you can use up to 115
>> characters.
>
> Is that a completely compatible system? Does
> Easy CD Creator do it?

Yes. I use Easy CD Creator 5, which fully suports ISO,
Joliet, and UDF. I believe that UDF was really invented
for DVD-Rs but is compatible with CD-Rs.

I never found out what the max character length using
UDF really is, but its around 120. However, /big
however/, in my case, if I go over /115/, I get
successful burns but all the files are zero-length, thus
useless. So, I stay at 114 or under.

A useful utility to determine if your file names are too
long, for Joliet, UDF, or anything else, try Long File
Name Finder. It is totally /free/ and you can get it at

http://www.dcsoft.com/products/longff/longff.htm

I've been told that not all CD/DVD readers can
successfully read a CD-R bunred with UDF, but that's
/not/ been my experience. Everybody seems to be able to
read my CD-Rs, so I imagine it is a "compatible" file
system.

--
ATM, aka Jerry
June 27, 2005 12:34:20 PM

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

I use iView Media Pro, which allows you to tag by keyword or 'rate' 1
to 10. The big advantage here is that it allows you to export a .csv
text or an xml file with the rating or the keyword tagging, as well as
any of the other info associated with the file (path, EXIF, etc).
Very, very handy if you ever want to move to a different viewer or look
at the info in excel.
Anonymous
June 27, 2005 2:05:19 PM

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

Hi Scott,
>
>>I would like to be able to assign keywords to every digital photos so
>>that I can later seach by key words. Is there a pdrogram that would
>>allow me to do this?
If you use TIFFs you can use the TIFF description tag. The advantage of that
is that it is part of the image file and doesn't depend on any application,
archiving system or OS. Among others, the Gimp will let you edit it.

-- Hans
Anonymous
June 27, 2005 5:38:14 PM

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

In article <1119800146.295852.280540@z14g2000cwz.googlegroups.com>,
"Scott W" <biphoto@hotmail.com> wrote:

> Jack wrote:
> > I would like to be able to assign keywords to every digital photos so
> > that I can later seach by key words. Is there a pdrogram that would
> > allow me to do this?
> Well you can in fact do this in Windows XP, right click then go to
> properties and set the keywords, but this does not work all that will,
> you can search by keyword by it is slow.
>
> There are a lot of programs out there that will do this kind of thing,
> we all have the ones we like, you might want to try a few as there is
> normally a free trial period will all of them.
>
> I use ACDSee, which for me works great.
>
> I organize my photos a bit differently then most people, I have a
> directory for each year and then under those directories I have one for
> each day that I shoot photos. I then pick on photo from each day that
> best represents what was going on that day and these all get put into a
> category (something like keywords). I can then open the list of off
> the key photos and from this pretty much figure out what day I am
> looking for. If there is a lot going on in a day I might put in two or
> three photos from it into the category.
>
It's often much easier to retain the original DSC numbering and then
create an Excel program with pages organized under different headings -
Family, Landscapes, Flowers etc and sub-heading within each worksheet.
This would make copying the DSC number into as many categories as you
like, very easy.
Anonymous
June 27, 2005 10:10:43 PM

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

Moe wrote:
> Try Picasa..........it's FREE from Google: http://www.picasa.com/index.php

Picasa is said to be very nicely done. Too bad it doesn't run on my
platform.

The scheme I use goes like this: I don't ever rename images. They come
off the camera into a folder with a meaningful name. My software keeps
track of unique images by filename and EXIF timestamp. (Using an MD5
hash would be better, but slower, and it would treat crops and modified
images as different from the original.) Images can have an arbitrary
number of tags applied to them: places/parks/Mount Rainier NP,
people/Allens/Mom, plants/ident/Indian Paintbrush, etc. The tags
are hierarchical and lend themselves to a tree-structured GUI for
adding/removing tags. You can add new tags to the tree by simply
right-clicking on the tree and entering the new tag name. All of
the metadata about images, folders, and the "shoeboxes" that folders
live in is stashed in an XML file. It is a simple matter of a couple
mouse clicks to find all the images of Aunt Marge at Mount Rainier
with Indian Paintbrush in the background. I currently have about
6000 images and queries come back in less than a second.

Paul Allen
Anonymous
June 27, 2005 10:25:43 PM

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

"ER" <evad@dodgeit.com> wrote in message news:42bf13f3_1@newsgate.x-privat.org...
> ...
> I start the filename with the date so they sort chronologically in a directory.
>
> I then name the place or the people from left to right and maybe what they are doing
> like:
>
> 2005BlackRockDesertJaneCutyRobinBalkDwainSuplovShowingOff.jpg
>
> It takes a bit of time to makeup the filenames but they will be understood generations
> later.

Yes, and unlike some other solutions, this one is relatively independent
of specific software programs.

I have used the same scheme on scans of my old photos, but
gotten a little lazy with the digital photo outputs.

I've thought of using coded filenames. Something like this:

2005.FS.BlackRockDesertJane...jpg

where "S" means "Scenic" and "F" means "Family".

Other codes might be something like:

P = people
I = indoor
T = travel
C = city

Then you could search for files with a search like this:

dir /s "2004.*S*.*jpg

which would find all scenics shot in 2004.

If you put the code letters in alphabetical order, you can always
find combinations, for example:

dir /s "????.*F*T*.*.jpg

finds all family travel photos for all years.

Unfortunately, the Windows DIR command doesn't always handle
all of this correctly, but there are free versions of the UNIX ls
command that should do it.

I haven't implemented this, but would be curious to hear from
anyone who's tried a similar scheme.

Alan
June 28, 2005 1:36:21 AM

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

On Mon, 27 Jun 2005 06:38:40 -0500, All Things Mopar <noneofyour@busi.ness>
wrote:

>Bob commented courteously...
>
>>>> Problem is CDs only take 64 letters...
>>>
>>>That's with the Joliet file system. If you use UDF
>>>(Universal Disk Format), you can use up to 115
>>> characters.
>>
>> Is that a completely compatible system? Does
>> Easy CD Creator do it?
>
>Yes. I use Easy CD Creator 5, which fully suports ISO,
>Joliet, and UDF. I believe that UDF was really invented
>for DVD-Rs but is compatible with CD-Rs.
>
>I never found out what the max character length using
>UDF really is, but its around 120. However, /big
>however/, in my case, if I go over /115/, I get
>successful burns but all the files are zero-length, thus
>useless. So, I stay at 114 or under.
>
>A useful utility to determine if your file names are too
>long, for Joliet, UDF, or anything else, try Long File
>Name Finder. It is totally /free/ and you can get it at
>
>http://www.dcsoft.com/products/longff/longff.htm
>
>I've been told that not all CD/DVD readers can
>successfully read a CD-R bunred with UDF, but that's
>/not/ been my experience. Everybody seems to be able to
>read my CD-Rs, so I imagine it is a "compatible" file
>system.

Thanks - that will save me from getting out my old 'C' programming books!
Anonymous
June 28, 2005 2:12:08 AM

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

"Paul Allen" <"paul dot l dot allen at comcast dot net"> wrote in message
news:CbSdnTOasYQJPl3fRVn-sw@comcast.com...
> Moe wrote:
>> Try Picasa..........it's FREE from Google: http://www.picasa.com/index.php
>
> Picasa is said to be very nicely done. Too bad it doesn't run on my
> platform.
>
> The scheme I use goes like this: I don't ever rename images. They come
> off the camera into a folder with a meaningful name. My software keeps
> track of unique images by filename and EXIF timestamp. (Using an MD5
> hash would be better, but slower, and it would treat crops and modified
> images as different from the original.) Images can have an arbitrary
> number of tags applied to them: places/parks/Mount Rainier NP,
> people/Allens/Mom, plants/ident/Indian Paintbrush, etc. The tags
> are hierarchical and lend themselves to a tree-structured GUI for
> adding/removing tags. You can add new tags to the tree by simply
> right-clicking on the tree and entering the new tag name. All of
> the metadata about images, folders, and the "shoeboxes" that folders
> live in is stashed in an XML file. It is a simple matter of a couple
> mouse clicks to find all the images of Aunt Marge at Mount Rainier
> with Indian Paintbrush in the background. I currently have about
> 6000 images and queries come back in less than a second.
>
> Paul Allen

That's a very interesting sounding system. Can you tell us more?

It sounds like one photo fits in multiple places in the hierarchy. Is
that right?

It sounds like you've got certain broad categories at the top: "places",
"people", "plants". Is that right? Did you make these up to suit yourself
or are you using an existing cataloging vocabulary as an "authority" file?

Are you using an XML editor for this, or just a text editor and
displaying in an XML aware browser?

I presume that, at the leaf node, you've got a fully qualified path to
a filename. Is that right?

Thanks.
Anonymous
June 28, 2005 2:12:09 AM

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

Alan Meyer wrote:
> "Paul Allen" <"paul dot l dot allen at comcast dot net"> wrote in message
> news:CbSdnTOasYQJPl3fRVn-sw@comcast.com...
>
>>Moe wrote:
>>
>>>Try Picasa..........it's FREE from Google: http://www.picasa.com/index.php
>>
>>Picasa is said to be very nicely done. Too bad it doesn't run on my
>>platform.
>>
>>The scheme I use goes like this: I don't ever rename images. They come
>>off the camera into a folder with a meaningful name. My software keeps
>>track of unique images by filename and EXIF timestamp. (Using an MD5
>>hash would be better, but slower, and it would treat crops and modified
>>images as different from the original.) Images can have an arbitrary
>>number of tags applied to them: places/parks/Mount Rainier NP,
>>people/Allens/Mom, plants/ident/Indian Paintbrush, etc. The tags
>>are hierarchical and lend themselves to a tree-structured GUI for
>>adding/removing tags. You can add new tags to the tree by simply
>>right-clicking on the tree and entering the new tag name. All of
>>the metadata about images, folders, and the "shoeboxes" that folders
>>live in is stashed in an XML file. It is a simple matter of a couple
>>mouse clicks to find all the images of Aunt Marge at Mount Rainier
>>with Indian Paintbrush in the background. I currently have about
>>6000 images and queries come back in less than a second.
>>
>>Paul Allen
>
>
> That's a very interesting sounding system. Can you tell us more?

You're sure you want to start a geek talking about his pet project?
:-)

> It sounds like one photo fits in multiple places in the hierarchy. Is
> that right?

You could think of it that way, but it would be closer to say that
a photo has multiple references into the tag hierarchy attached to
it. In database terminology, I've got an "images" table indexed by
filename and timestamp, and a "tags" table indexed by tag id. Each
tag record has an id, a name, and possibly a parent and some children.
Each image record has a filename, a timestamp, a reference to its
containing folder and shoebox, and a list of tag ids.

> It sounds like you've got certain broad categories at the top: "places",
> "people", "plants". Is that right? Did you make these up to suit yourself
> or are you using an existing cataloging vocabulary as an "authority" file?

You understand it right. I'm making up the tag hierarchy as I go
along. It's a personal expression of the way I think about my
image collection. If someone else were to start using my software,
I expect that they'd look at my hierarchy, shrug their shoulders,
and invent their own. Lack of consistency with existing vocabularies
could be considered a flaw. Or not. :0)

> Are you using an XML editor for this, or just a text editor and
> displaying in an XML aware browser?

It would be painful to maintain the XML by hand. I've built an
image database abstraction layer on top of the perl binding to the
libxml2 implementation of the DOM and XPath. Sitting on top of
the database layer is a Tk/perl GUI. The total is about 3000 lines
of perl. The XML file is currently about 1.5MB in size. A quick
find shows a bit over 10000 images in the collection.

> I presume that, at the leaf node, you've got a fully qualified path to
> a filename. Is that right?

Hmmm... Not quite. An image node in the XML has elements pointing
to the names of the containing folder and shoebox. The entire
collection lives in what I'm calling a "stash" directory. In the
current scheme, the path to an image file is:

$stashDir/$shoeBox/$folder/.data/native/$fileName.jpg

(The .data/native bit in the middle is legacy baggage from the pre-
XML implementation of the software.) When you ask for all the
images with a given set of tags, the code constructs an XPath query
that returns an array of XML nodes containing references to those
tags. From those nodes, the shoeboxes, folders, and filenames are
extracted to construct an array of pathnames that is then used to
present the selection in the GUI. Of course, the person operating
the GUI doesn't need to know anything about XPath, XML, or perl.

Given a selection of images, you can create a "room" in a "gallery" and
generate HTML, or you can print, or you can export the JPEG files
to a directory outside the stash for direct manipulation in the GIMP
or whatever.

My code depends critically on libxml2 and the XML::LibXML perl
module. It depends on several other perl modules, ImageMagick
for resizing, exifprobe for EXIF support, jpegtran for lossless
cropping and rotation, GhostScript for printing, and probably
some other things I'm forgetting. It's only known to run on
Linux, although a port to MacOS 10 would likely be trivial. A
port to Windows might be an adventure. I know perl and Tk exist,
but don't really know about the rest. ImageMagick and the printing
stuff might be the worst part.

For a while now I've been toying with the idea (and working toward
the possibility) of releasing my image database code as an open
source project. Are there any perl-hacking camera geeks here looking
for a project? This thing's got lots of warts that need filing off,
and I'm not sure the world needs yet another image database. :-)

Paul Allen
Anonymous
June 28, 2005 6:38:10 AM

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

On Sun, 26 Jun 2005 11:10:18 -0400, Jack wrote:

> I would like to be able to assign keywords to every digital photos so
> that I can later seach by key words. Is there a pdrogram that would
> allow me to do this?

iMatch
iView Media Pro
Extensis Portfolio

--
http://mahune.org/
June 28, 2005 10:00:25 AM

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

"Alan Meyer" <ameyer2@yahoo.com> wrote:

> ...
> where "S" means "Scenic" and "F" means "Family".
>
> Other codes might be something like:
>
> P = people
> I = indoor
> T = travel
> C = city
>
> Then you could search for files with a search like this:
>
> dir /s "2004.*S*.*jpg
>
> ...

So something like PICF&ROFL.2005.jpg would be simple to remember in 20
years... got it. ;^)
Anonymous
June 28, 2005 11:55:00 AM

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

Deedee Tee wrote:
> On Tue, 28 Jun 2005 06:00:25 GMT, Confused
> <somebody@someplace.somenet> wrote:
>
> [..]
> >So something like PICF&ROFL.2005.jpg would be simple to
> >remember in 20 years... got it. ;^)

That's a good point. It would make sense to store a README file
in each directory containing the legend explaining what the key
characters mean.

> I am joining this thread late, so I don't know whether someone
> else has already pointed out an obvious problem with databases
> that store information separate from the pictures.
>
> This system is vulnerable to obsolescence (it may not run under
> the next version of Windows, and an update may not be available
> - how many of you can still run a CP/M program or read a stack
> of perforated cards?), and the database itself can be lost.
> Museum collections have a conceptually similar problem. I have
> been working with many collections of scientific samples in
> museums, some of them accumulated over centuries. Many
> specimens carry inventory numbers written on them, which once
> corresponded to an entry in a handwritten log book that has
> been long lost. Different collections donated over time came
> with different cataloguing systems, or, even worse, with just a
> number, so it is impossible to know from which of a dozen
> collections a specimen labelled n.6027 comes. The result:
> thousands of potentially valuable specimens which are useless
> because locality data and observations are lost - except, of
> course, for those specimens that have the data written on a
> label placed in the same box.
>
> So, learning from this, plan on a system that makes use of
> information self-contained in the picture. EXIF is not very
> useful bcause it is not supposed to be altered after the
> picture is stored, but IPTC has plenty of useful fields that
> can be added and edited at any time. Any serious software,
> present or future, that can display the picture can also read
> and write IPTC, as long as the file format itself will not
> become obsolete (at which point it does not matter if you can't
> read the data, because you can't see the picture either). You
> -can- use safely software that reads IPTC and places it in a
> separate database, as long as this database is used only for
> searching and not for storing additional information.

I think your point is well taken, but I'm not ready to go quite
as far with it as you are.

One thing I do now is store a catalog file, just plain text notes
explaining what's in the photos, in each directory that contains
photos.

Could it be lost? Possibly. But it's unlikely. If the
directory is lost then the photos are lost with it. If the
directory is preserved then the catalog is preserved with it. If
the directory is copied to CD or DVD or some other medium, the
catalog is copied with it - so long as the user copies the whole
directory and not individual files or file globs like "*.jpg".

Is this 100% safe? No. But perhaps IPTC isn't 100% safe either.
Someone might come along with a photo editor that reads and
writes files without copying the IPTC data. This is not as
unlikely as it sounds if, for example, someone is told to convert
all these old JPEG photos into the new WhizBang 2100 format in
order to make them readable by common WhizBang readers.

A relatively unsophisticated user might see the directory and the
images, and use an image viewer to see the photos, but never even
know that there is data copied into the IPTC fields. Of course
that's possible, and even more likely, with an external database
too.

We need to analyze our aims here. For home use, I'm concerned to
meet the following goals:

1. Preservation of photos and data.

We shouldn't rely on software or encoding formats that are
almost certain to become obsolete even in our own
lifetimes.

This is a big problem with any database format, and also
with propietary word processing formats like Microsoft
Word. It's a bit less of a problem with IPTC since IPTC
is part and parcel of JPEG. But it's still at least
slightly problematic.

The least problematic format, I think, is ASCII text,
either as plain text, or perhaps as XML.

2. Explanation of what's in the photos.

Someone looking at pictures of dead people 100 years from
now will get nothing from them. But if they can find out
who the people are and what they are doing, the photos
become more meaningful.

3. Ability to find photos by subject.

If you're looking for photos of long gone Aunt Martha, how
do you go about it?

4. Ease of use.

I don't want to do something that's hard for me to do. I
want to be able catalog the photos quickly.

One really valuable aid to simplify cataloging is the
ability to write information that pertains to groups of
photos. For example, I want to be able to say "IMG_0123 -
IMG_0150 are photos of Aunt Martha and Uncle Dave on their
visit to the pyramids in 2004." That's vastly easier than
calling up all 27 images in a photo editor, adding the
same IPTC text to each, and saving each one.

In a text file I might even do something like write an
introduction that explains all the photos in a directory

These were made on Aunt Martha and Uncle Dave Jones'
visit to Egypt in 2004.

Then add notes explaining ranges of photos:

123-150: A&D at the pyramids.

129-131: The camel driver who brought them there,
he was an interesting character whom M&D
corresponded with afterwards.
132-135: M&D climbing in the hot sun. They
made it to the top.
136-148: Views from the top.

151-155: The bus trip to Alexandria - photos taken
from the windows.

And so on.

5. Friendliness to the naive user.

My wife, bless her soul, is capable of viewing an image
and capable of viewing a text file. Although she's a very
intelligent woman, she finds computers slightly repellent
and is unlikely to remember instructions for viewing IPTC
data. If she survives me, she'd never figure out how to
view it or remember to tell our children or anyone else
that IPTC data is in the photos with explanations of
what's there.

I think your idea makes a lot of sense for museum use, but may
not be as suitable for home use.

Alan
Anonymous
June 28, 2005 11:59:28 AM

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

Thanks for the explanation.

I actually know Perl pretty well and was able to more or less
follow your explanation. But I'm not ready to leap into a 3,000
line project at this time.

However I like your idea of using XML. It's a plain text format that's
likely to be readable as long as English is readable. It also
provides hierarchy - which is very useful.

You could also easily combine the hierarchical tags with text content
providing explanation. I've written more about text in answer to
Deedee Tee earlier in the thread.

I'd love to see a sample of your XML. Just a dozen lines or so
would be instructive.

Thanks.

Alan
Anonymous
June 28, 2005 12:25:38 PM

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

Which leads to the final conclusion that you should use Long File Names for
picture notations.


ER


"Alan Meyer" <ameyer2@yahoo.com> wrote in message
news:1119970500.564967.6920@g49g2000cwa.googlegroups.com...

snip...
Anonymous
June 28, 2005 12:48:38 PM

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

ER wrote:
> Which leads to the final conclusion that you should use Long File Names for
> picture notations.
>
>
> ER
>
>
> "Alan Meyer" <ameyer2@yahoo.com> wrote in message
> news:1119970500.564967.6920@g49g2000cwa.googlegroups.com...
>
> snip...

That's a good approach and I've used it extensively myself, but
it's not necessarily what I would have concluded from the above.

It might be better to use the camera file names (IMG_0123 or
whatever) and create a text file catalog as described above.

The advantages are:

1. You can write much more in a text catalog than you can
in a long file name.

2. You can summarize ranges of photos easily.

3. You preserve the photos in the directory, and in the catalog,
in the original order they were taken.

Alan
Anonymous
June 28, 2005 1:26:42 PM

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

Alan Meyer wrote:
>
> We need to analyze our aims here. For home use, I'm concerned to
> meet the following goals:
>
> 1. Preservation of photos and data.
>
> We shouldn't rely on software or encoding formats that are
> almost certain to become obsolete even in our own
> lifetimes.
>
> This is a big problem with any database format, and also
> with propietary word processing formats like Microsoft
> Word. It's a bit less of a problem with IPTC since IPTC
> is part and parcel of JPEG. But it's still at least
> slightly problematic.
>
> The least problematic format, I think, is ASCII text,
> either as plain text, or perhaps as XML.

Agreed. I spent some time building an image database in MySQL, but
concluded that it wasn't portable enough. I wanted a way to deliver
a CD to distant relatives along with a simple viewer with access to
all of the relevant image metadata without having to depend on my
mother in law knowing how to install MySQL.

I'm using XML because it gives me database-like functionality in
an ASCII format that shows no signs of going away any time soon.

> 2. Explanation of what's in the photos.
>
> Someone looking at pictures of dead people 100 years from
> now will get nothing from them. But if they can find out
> who the people are and what they are doing, the photos
> become more meaningful.

Yep. This is critical, especially for family shots. Having notes
written on the back of a print is ideal, but being able to recover
the notes from the same medium that preserved the images is the
next best thing.

> 3. Ability to find photos by subject.
>
> If you're looking for photos of long gone Aunt Martha, how
> do you go about it?

Yup. For a large archive, rummaging through each image looking at
metadata doesn't work well. It works for disaster recovery, but
something approximating a database is nicer to use.

> 4. Ease of use.
>
> I don't want to do something that's hard for me to do. I
> want to be able catalog the photos quickly.

Again, this is critical. The pile of code I've written to manage
my images is fairly easy for its author to use, but it's not easy
enough for anybody else yet. :=)

> One really valuable aid to simplify cataloging is the
> ability to write information that pertains to groups of
> photos. For example, I want to be able to say "IMG_0123 -
> IMG_0150 are photos of Aunt Martha and Uncle Dave on their
> visit to the pyramids in 2004." That's vastly easier than
> calling up all 27 images in a photo editor, adding the
> same IPTC text to each, and saving each one.

Agreed. I can attach chunks of text to individual images and to
collections of images. And I can apply a tag to a whole collection
of images simultaneously. The interface needs usability work, but
it is good enough for its author.

> In a text file I might even do something like write an
> introduction that explains all the photos in a directory
>
> These were made on Aunt Martha and Uncle Dave Jones'
> visit to Egypt in 2004.
>
> Then add notes explaining ranges of photos:
>
> 123-150: A&D at the pyramids.
>
> 129-131: The camel driver who brought them there,
> he was an interesting character whom M&D
> corresponded with afterwards.
> 132-135: M&D climbing in the hot sun. They
> made it to the top.
> 136-148: Views from the top.
>
> 151-155: The bus trip to Alexandria - photos taken
> from the windows.
>
> And so on.

Yup, yup.

> 5. Friendliness to the naive user.
>
> My wife, bless her soul, is capable of viewing an image
> and capable of viewing a text file. Although she's a very
> intelligent woman, she finds computers slightly repellent
> and is unlikely to remember instructions for viewing IPTC
> data. If she survives me, she'd never figure out how to
> view it or remember to tell our children or anyone else
> that IPTC data is in the photos with explanations of
> what's there.

Good golly, yes! My target is my 80-year-old mother in law, who
regards computers with about as much trepidation as Sam Gamgee
regards boats.

> I think your idea makes a lot of sense for museum use, but may
> not be as suitable for home use.

It might be worthwhile to experiment with both approaches. Although
I copy the XML along with the images when I write archive CD's, I
do worry about my inability to recover the tagging info if the XML
becomes damaged or lost. If it were backed up in each image,
recovery would be possible.

Paul Allen
Anonymous
June 28, 2005 2:57:27 PM

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

Canto Cumulus is designed for this purpose.

Jack wrote:
> I would like to be able to assign keywords to every digital photos so
> that I can later seach by key words. Is there a pdrogram that would
> allow me to do this?
Anonymous
June 28, 2005 4:45:49 PM

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

"Alan Meyer" <ameyer2@yahoo.com> wrote in message
news:1119973718.873878.242490@g14g2000cwa.googlegroups.com...
> ER wrote:
>> Which leads to the final conclusion that you should use Long File Names
>> for
>> picture notations.
>>
>>
>> ER
>>
>>
>> "Alan Meyer" <ameyer2@yahoo.com> wrote in message
>> news:1119970500.564967.6920@g49g2000cwa.googlegroups.com...
>>
>> snip...
>
> That's a good approach and I've used it extensively myself, but
> it's not necessarily what I would have concluded from the above.
>
> It might be better to use the camera file names (IMG_0123 or
> whatever) and create a text file catalog as described above.
>
> The advantages are:
>
> 1. You can write much more in a text catalog than you can
> in a long file name.
>
> 2. You can summarize ranges of photos easily.
>
> 3. You preserve the photos in the directory, and in the catalog,
> in the original order they were taken.
>
> Alan
>

Best of all, do both Long File Names, and Text Database and teach your kids
to understand.

ER
Anonymous
June 28, 2005 6:10:36 PM

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

Paul,

It sounds like you've got the right ideas in what you're doing.
Assuming you don't want to sell the software (selling software is
a difficult, thankless task that rarely compensates the author
for the time and money spent trying to sell it) you might consider
making it open source, e.g., creating a project for it on SourceForge.

That may or may not attract another developer to share the burden
with you, but it might be interesting to try.

Good luck with it.

Alan
Anonymous
June 28, 2005 11:17:03 PM

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

On Tue, 28 Jun 2005 06:00:25 GMT, Confused
<somebody@someplace.somenet> wrote:

[..]
>So something like PICF&ROFL.2005.jpg would be simple to remember in 20
>years... got it. ;^)

I am joining this thread late, so I don't know whether someone else
has already pointed out an obvious problem with databases
that store information separate from the pictures.

This system is vulnerable to obsolescence (it may not run under the
next version of Windows, and an update may not be available - how many
of you can still run a CP/M program or read a stack of perforated
cards?), and the database itself can be lost. Museum collections have
a conceptually similar problem. I have been working with many
collections of scientific samples in museums, some of them accumulated
over centuries. Many specimens carry inventory numbers written on
them, which once corresponded to an entry in a handwritten log book
that has been long lost. Different collections donated over time came
with different cataloguing systems, or, even worse, with just a
number, so it is impossible to know from which of a dozen collections
a specimen labelled n.6027 comes. The result: thousands of potentially
valuable specimens which are useless because locality data and
observations are lost - except, of course, for those specimens that
have the data written on a label placed in the same box.

So, learning from this, plan on a system that makes use of information
self-contained in the picture. EXIF is not very useful bcause it is
not supposed to be altered after the picture is stored, but IPTC has
plenty of useful fields that can be added and edited at any time. Any
serious software, present or future, that can display the picture can
also read and write IPTC, as long as the file format itself will not
become obsolete (at which point it does not matter if you can't read
the data, because you can't see the picture either). You -can- use
safely software that reads IPTC and places it in a separate database,
as long as this database is used only for searching and not for
storing additional information.
Anonymous
June 29, 2005 3:33:03 AM

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

Alan Meyer wrote:
> Thanks for the explanation.
>
> I actually know Perl pretty well and was able to more or less
> follow your explanation. But I'm not ready to leap into a 3,000
> line project at this time.

Understand completely. And it's worse than I thought. The XML layer
alone is 1700 lines, while the GUI is a bit over 4000.

> However I like your idea of using XML. It's a plain text format that's
> likely to be readable as long as English is readable. It also
> provides hierarchy - which is very useful.

It seems to be working well, although I'm starting to feel constrained
by the mounting pile of legacy data that I'm going to have to drag
forward with me as new ideas come along.

> You could also easily combine the hierarchical tags with text content
> providing explanation. I've written more about text in answer to
> Deedee Tee earlier in the thread.

I think I saw that post. You understand the problem.

> I'd love to see a sample of your XML. Just a dozen lines or so
> would be instructive.

You know how verbose XML is. A dozen lines can't show anything!
Here's what I got when I created a new stash containing one shoebox
and one folder, imported 10 images into it, and annotated them:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pictures SYSTEM "./samples1/pictures.dtd">
<pictures>
<defaultloc id="8"/>
<globaltags>
<nextid id="20"/>
<tag id="1" name="people">
<tag id="12" name="Paul"/> <tag id="13" name="Dad"/> <tag id="14"
name="Mom"/> <tag id="15" name="Gail"/>
</tag>
<tag id="2" name="places">
<tag id="10" name="Hi Tide Resort, Moclips, WA"/>
</tag>
<tag id="3" name="events">
<tag id="11" name="Father and son birthday"/>
</tag>
<tag id="4" name="misc">
<tag id="5" name="key image"/> <tag id="6" name="select for
printing"/> <tag id="7" name="select for web"/>
</tag>
<tag id="16" name="patterns">
<tag id="17" name="sand"/>
</tag>
</globaltags>
<location name="shoebox1" id="8">
<backup/>
<collection name="Hi Tide 2005" id="9">
<image name="p2170001" time="2005:02:17 16:28:30" rc="1">
<narrative>Wind-blown sand creates dips and hollows caught in
sharp relief by the setting sun.</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
<itag id="16"/> <itag id="17"/>
</image>
<image name="p2170002" time="2005:02:17 16:28:52">
<narrative>Paul skipping a rock</narrative> <itag
id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/> <itag id="1"/>
<itag id="12"/>
</image>
<image name="p2170003" time="2005:02:17 16:29:46">
<narrative>Mom can't walk far on the beach any more.</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
<itag id="1"/> <itag id="14"/>
</image>
<image name="p2170004" time="2005:02:17 16:31:42">
<narrative>Dad still likes to drag driftwood off the
beach.</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
<itag id="1"/> <itag id="13"/>
</image>
<image name="p2170005" time="2005:02:17 16:33:41">
<narrative>The birthday boys.</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
<itag id="1"/> <itag id="12"/> <itag id="13"/>
</image>
<image name="p2170006" time="2005:02:17 16:34:16">
<narrative>The Hi Tide Resort</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
</image>
<image name="p2170007" time="2005:02:17 16:37:32">
<narrative>Ocean beach vista</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
</image>
<image name="p2170008" time="2005:02:17 16:40:49" rc="1">
<narrative>Sand ripples left by the receding tide.</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
<itag id="16"/> <itag id="17"/>
</image>
<image name="p2170009" time="2005:02:17 16:41:18" rc="1">
<narrative>A restatement of the sand ripples theme.</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
<itag id="16"/> <itag id="17"/>
</image>
<image name="p2170010" time="2005:02:17 16:43:40">
<narrative>It's a great kite wind today!</narrative>
<itag id="2"/> <itag id="10"/> <itag id="3"/> <itag id="11"/>
</image>
<desc>A birthday at the beach</desc>
<narrative>We spent a few days at the Hi Tide Resort in
February of 2005
to celebrate my father's and my joint birthday. The setting
is a sandy Pacific Ocean beach near the mouth of the Moclips
River.</narrative>
</collection>
<project name="Sand Patterns" id="18">
<collection name="Sand Between My Toes" id="19">
<image name="p2170001" time="2005:02:17 16:28:30" collid="9"/>
<image name="p2170008" time="2005:02:17 16:40:49" collid="9"/>
<image name="p2170009" time="2005:02:17 16:41:18" collid="9"/>
<narrative>These are shots of interesting patterns in the
sand</narrative>
</collection>
</project>
</location>
</pictures>

Already, we're seeing the shear between my ten month old schema and
the current reality of the GUI. A <location> node in the XML is
represented by a "shoebox" in the GUI. A <collection> inside a
<locatin> is a "folder". Images live inside folders. A <project>
node inside a <location> is a "gallery" in the GUI. <collection>
nodes inside <project> nodes are "rooms" in the GUI. <collection>,
<project>, and <image> nodes can all have one-line <desc> elements
and free-form multi-line <narrative> elements. I use the <desc>
text for labels on prints and for mouse-over text on web pages.

<image> nodes in one <collection> may be "references" to nodes in
some other <collection>. <tag>, <location>, <project>, and <collection>
nodes all have id attributes that are used as references. This saves
space and allows things in the GUI to be renamed without having to track
down every use of the name in the XML.

In the above sample, the "Sand Patterns" project was created by
selecting all the images with the "patterns/sand" tag and then saving
the selection as a new room (<collection>) in a gallery (<project>).
The <image> nodes in the "Sand Between My Toes" collection are
references, by filename, timestamp, and collection id, to three of
the images in the Hi Tide 2005 collection.

It's not shown in the sample, but <location> nodes may contain
<backup> nodes with the timestamps and volume names of CD archives.
I'm figuring that in the long haul big hunks of my cllection will
be offline, and the GUI will ask for volumes to be mounted when
it needs them in order to satisfy queries.

I guess that's enough of a dump for now. I'll be quiet for a while
and let things digest. I don't suppose many of the photographers
here want all this XML talk. :-)

Paul Allen
Anonymous
June 29, 2005 1:52:41 PM

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

Hi Paul,
>
>
> Understand completely. And it's worse than I thought. The XML layer
> alone is 1700 lines, while the GUI is a bit over 4000.
Ever thought of putting your project on sourceforge? That way you can perhaps
attract other developers to share the burden.

just my 2 cts, Hans
Anonymous
June 29, 2005 1:52:42 PM

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

HvdV wrote:
> Hi Paul,

>> Understand completely. And it's worse than I thought. The XML layer
>> alone is 1700 lines, while the GUI is a bit over 4000.
>
> Ever thought of putting your project on sourceforge? That way you can
> perhaps attract other developers to share the burden.
>
> just my 2 cts, Hans

Yes, I've thought of that, and I'm inclined in that direction. It just
needs time and motivation to make it happen. One source of motivation
is feedback that the concept is approximately on a useful track. :-)

Paul
Anonymous
June 30, 2005 2:43:14 PM

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

Hi Paul,
>>
>> Ever thought of putting your project on sourceforge? That way you can
>> perhaps attract other developers to share the burden.
>>
>> just my 2 cts, Hans
>
>
> Yes, I've thought of that, and I'm inclined in that direction. It just
> needs time and motivation to make it happen. One source of motivation
> is feedback that the concept is approximately on a useful track. :-)
Sourceforge might be of help there, though it is not clear to me how projects
become popular. Factors will be demand (should be high in this case) and the
use of popular programming tools.
Just had a look on sourceforge, searching for 'photo' you get a fairly long
list of photo album, yet another photo album, and so on projects, most of
them in the Linux-Apache-MySQL-PHP category. Difficult to judge their quality
or usefulness. Considering the demand for a simple lightweight package I'd
say there is room for another!

Anyone experience with a photo archive from sourceforge?

-- Hans
!