Strategien zum Archivieren und Auffinden von Fotos in
Datenbanken
- eine Diskussion aus dem Forum der Firma cerious.com (Hersteller von ThumbsPlus)
Mir scheint diese Diskussion ganz lehrreich zu den Problemen
beim Organisieren von Foto- Datenbanken, ich habe selbst eine Menge Lehrgeld
gezahlt.
"Stephen LaMantia" <slamantia@home.com> wrote in message
news:363lat40dr484fmar6uv5d3h04hkkk9d4g@4ax.com...
> Hi folks.
>
> I'm posting this to cerious.misc because my question has not so
> much to do with the technical aspects of Thumbs Plus, as with the
> details of organizing strategies one could use to keep track of
> thousands of images. My wonderings are broad in scope -- in
> fact, my head reels sometimes when I try to consider everything I
> think I need to be considering -- and range all the way from
> scanning, through the editing process, to archiving images.
>
> I'm about to embark on what's probably going to be a several-year
> project of scanning in thousands of old family photographs and
> storing them digitally (ultimately onto CD-R disks), and I'm
> hoping some folks can offer me some tips about how they go about
> the process.
>
> While Thumbs Plus offers many great tools that form an excellent
> technical basis for organizing things, I haven't found too much
> discussion -- either in the TP help file, on the Cerious web site
> (or the web sites of other folks), or in these newsgroups --
> dealing with particular strategies folks use as the basis of a
> coherent organizing scheme, and as I mull over several possible
> strategies, I get a bit confused as to what might be the best way
> to proceed. (Any librarians out there with a focus on digital
> imagery? I bet you go through these same wonderings all the
> time.)
>
> I know a good, and always true, answer to this question is
> "Whatever works for you". Sure, I could experiment, and try one
> organizing strategy after another, until I find what works for
> me. In the end, of course, I'm sure that that's what I will be
> doing, to a certain extent.
>
> But what I'm hoping to do right now by querying folks on *their*
> methods is to avoid having to try out for myself every possible
> organizing scheme until I get it right. Renaming huge numbers of
> files, re-doing directory structures, re-entering annotations,
> re-creating fields and the field entries, and re-doing keywords,
> over and over again while I thrash about experimenting is not my
> idea of fun. I'm hoping to avoid having to reinvent *every*
> little wheel along the way, by asking for your advice on what
> you've found useful, and on what pitfalls to avoid. I don't want
> to get far downstream using a particular cataloging data
> strategy, only to discover some fatal flaw in that strategy after
> scanning and naming and cataloging, say, 1500 images, and then
> have to start all over.
>
> Since I'm never sure if I'm clearly stating what I'm thinking,
> here are some details that might help explain what I'm wonding
> about:
>
> I guess I'm actually wondering about *two* different points in
> the "flow" from scan to image to cataloging. The first would be
> in the file and directory structure itself, all of which happens
> before I invoke Thumbs Plus. And then, the second area would be
> in cataloging strategies using Thumbs Plus.
>
> Regarding the image files themselves, what conventions do you use
> for naming files and directories? Do you keep separate
> "versions" of an individual image representing different stages
> in the editing process?
>
> For file names, I tend to adopt a "paranoid" strategy, and try to
> put lots of info right into the filename, and I save multiple
> files at each step. For example, say I scan in (into Photoshop)
> an old photo of my cousin Gary on a horse. I would name that
> original file
>
> Gary on horse, as scanned.psd
>
> Then I remove dust and scratches from the digital image, and then
> crop it, adjust the contrast, sharpen it a bit, then (optionally)
> resize it for a web page, and then make a 95%-quality jpg of it.
>
> Under my current working method, I would save a file each step
> along the way, so I end up with this series of separate .psd
> files:
>
> Gary on horse, as scanned.psd
> Gary on horse, dusted.psd
> Gary on horse, dusted, cropped.psd
> Gary on horse, dusted, cropped, contrast.psd
> Gary on horse, dusted, cropped, contrast, sharpened.psd
> Gary on horse, dusted, cropped, contrast, sharpened, webresized.psd
> Gary on horse, dusted, cropped, contrast, sharpened, webresized,
jpg95pct.jpg
>
> This is all for one photo. Aside from the fact that I need to
> learn Photoshop better -- because I think some of those
> adjustments can be achieved with something called "layer masks"
> and hence all saved into one file (yet retaining the ability to
> separate them out at a later time if need be), what I'm trying to
> show here is that I have a tendency to try to put info into the
> filenames themselves regarding the editing process. Is that
> good, or bad? Should I save that info for Thumbs to handle?
> Let's say I manage to master Photoshop to the point that I *can*
> use layers and layer masking to put all those discrete editings
> into one file, and do away with a need to archive the resizing
> and jpeg-ing results (on the assumption that I could always
> easily recreate those later if need be), and so I end up with
> just two files,
>
> Gary on horse, as scanned.psd
> Gary on horse, reworked.psd
>
> I guess I could put the technical editing info into Thumbs
> fields, but then I worry about losing that info when I archive
> those images over onto CD-R disks later, or at least, being faced
> with having to re-enter it all onto the Thumbs scans of the CD-
> Rs. (That seems a setup for error.)
>
> But then I also wonder, am I trying to retain *too much* info,
> either via filenames or via Thumbs? I could retain everything I
> could possibly think of, on the fear that someday I may need that
> info, but in your experience, what info actually *does* need to
> be referenced in the future, and what info never comes up?
>
> And what about directory structures? By subject, by date, by
> genre, by people, by roll of film? There are so many parameters,
> it seems so multi-dimensional, it's hard to decide on a hierarchy
> for directory structure, or if (again), I should just go for a
> minimal directory structure and leave the "presentation" of the
> data to Thumbs Plus.
>
> So much for files, filenames, and directory structure. The
> second area that's befuddling me -- and that's more germaine to
> this newsgroup, I guess -- is in the optimal usage of the data-
> storage features of Thumbs Plus itself. Let's say I don't try to
> shoehorn much image data into file or directory names at all, and
> rely on Thumbs to do all that. I guess my main question in that
> regard has to do with the fact that Thumbs Plus offers what seems
> to me to be three different "buckets" for data: annotations,
> keywords, and data fields. What best goes where? What info do
> you put in the annotation, in the keywords, or in the fields, and
> why?
>
> First of all, it does seem to me that annotations are best used
> for freeform "scribblings" about an image, things like "Uncle
> Lucky's black eye was from his girlfriend Mellow, the cast on his
> leg is from falling off the ladder getting the dog down from the
> roof again, and he's flailing his arms around like that because
> he was being attacked by bees just as I took the picture." (Do I
> have the purpose of annotations right?)
>
> So, that leave keywords vs. fields.
>
> Here, I can figure some other things out on my own, too. For
> example, it's easy to see that the year a photo was taken (or the
> full date) belongs in a TP field, not stored as a keyword.
> (Otherwise, I'd have to create a separate keyword for every year,
> or every date, I have a photo for, a silly proposition.)
>
> It seems that people's names, for example, also go best into
> fields. For example, I'm thinking of creating a LastName field,
> and a FirstName field, because that gives a lot of flexibility,
> because I could do a search on "LastName=Johansen", for example,
> and get all my mom's side of the family, the Johansens, or I
> could pin it down to "LastName=Johansen and FirstName=Kenneth"
> and get only the photos of my mom's brother, Uncle Kenny.
>
> In fact, the more I think about keywords vs. fields, the more it
> seems to me that I can't think of what advantage using keywords
> might have over using fields, that everything you could do with
> keywords could also be done with fields and with more
> flexibility. So now then I'm wondering if I'm missing something
> about the usefullness of keywords, as opposed to fields. With
> the presence of fields, the presence of keywords seems redundant.
> (So, what am I missing about keywords? What things go best into
> keywords, rather than into fields.)
>
> But back to fields. I think I see a deficiency, and wonder how
> to deal with it. Suppose I have some photos that can have up to
> ten people in them. To use fields to record each person's name,
> I'd have to create a field FirstName1, LastName1, FirstName2,
> LastName2, FirstName3, LastName3, ... FirstName10, LastName10.
> But in most photos, most of those fields would go unused. Would
> that cause a tremendous waste of space in the database file? I
> guess since the TP database (at least from the user's
> perspective) is not relational, we can't just create a separate
> PeoplesName table with just FirstName and LastName and then
> assign multiple records from that to our thumbnails, could we?
> (Or again, am I missing something.)
>
> And I guess the last thing I wonder about, once questions about
> the purpose and usage of the various Thumbs Plus data-storage
> features are resolved, is about the nature of the information
> itself. What are the important parameters to maintain? Source
> info, of course, like date, location, subject, people, etc, and
> maybe camera and film and print info. Anything else? Which
> parameters do you find yourself having to search on frequently?
>
> Folks, I realize this has been quite a long post, and if you've
> read this far you have my utmost appreciation. Thing is, all
> these questions have been pestering me for months now, as I try
> to plan out my big family-photo project, and I want to do it as
> right as possible, and it finally occurred to me that maybe,
> rather than continuing to torture myself with all these various
> wonderings, maybe I should just spill my guts out about them all
> to the cerious.misc newsgroup, in the hope that some of you have
> had these same concerns somewhere along the way, and perhaps have
> had some success in coming up with some methodology that deals
> with them.
>
> And, of course and it goes without saying, if there are any
> websites out there that discuss such things, I'd love to hear
> about them, too.
>
> Thank you all for bearing with me. Thanks!
>
> Steve LaMantia
> Seattle, WA
Tim Long wrote:
> so now I just keep all my originals in a single,
> flat directory.
The only disadvantage of a single flat directory for all your images
lies in the problematic incremental backup for such a structure. How
important a backup is you will notice the first time you loose an
important file.
Having smaller directories does not make a big difference for TP+ as
you still can view "child folders" and use galleries. However burning
a number of small directories even on different CD-Rs is much easier
than to make a save copy of a very big directory.
Just my two cents of experience,
Great discussion indeed! I don't know about collating all of this info. ;-p
But I will create a web page with all opinions and posts on this subject. I'll
let you guys know when this page is available.
Kind regards,
Laura Shook
Cerious Software, Inc.
szt wrote:
> This is a great discussion. Deciding how best to use Annotations vs.
> Comments can be confusing. I use Comments to permanently identify features
> of an image, particularly in archived copies (on CD or wherever). Most of my
> images of late are jpeg, generated by an Olympus digital camera, and many of
> my old scanned images are jpeg also. Converting jpegs to tiffs avoids the
> problem of lossiness when writing image Comments and then saving the file.
> It's best to write image Comments soon after acquiring images while details
> are still fresh in mind. Fortunately, conversion of tiff to back to jpeg
> copies Comments to the jpeg, which can be sized, etc. for its current
> purpose.
>
> A neat feature of TPbeta6 under Options|Preferences|Thumbnails is 'Auto copy
> image comments to db annotations.' Since I write Comments like image
> captions, they can then be displayed with TN's in web settings, etc.
> (Options|Show for Files|Annotations). This will overwrite (I assume) the db
> Annotations field, effectively making image Comments and db Annotations one
> and the same. So far I haven't found a need for db Annotations, except as a
> vehicle for displaying a caption created in the first place as an image
> Comment.
>
> It should be possible to hold other data (e.g., keywords or user defined) in
> image Comments, probably by using standard delimiters. These data elements
> could then be parsed out and copied into appropriate db fields on the fly or
> as part of creating or repairing a db. The advantage would be that key data
> would be always filed as part of an archived, lossless image. Loss of the db
> wouldn't be quite as catastrophic. Just a thought.
Hi folks.
I'm posting this to cerious.misc because my question has not so
much to do with the technical aspects of Thumbs Plus, as with the
details of organizing strategies one could use to keep track of
thousands of images. My wonderings are broad in scope -- in
fact, my head reels sometimes when I try to consider everything I
think I need to be considering -- and range all the way from
scanning, through the editing process, to archiving images.
I'm about to embark on what's probably going to be a several-year
project of scanning in thousands of old family photographs and
storing them digitally (ultimately onto CD-R disks), and I'm
hoping some folks can offer me some tips about how they go about
the process.
While Thumbs Plus offers many great tools that form an excellent
technical basis for organizing things, I haven't found too much
discussion -- either in the TP help file, on the Cerious web site
(or the web sites of other folks), or in these newsgroups --
dealing with particular strategies folks use as the basis of a
coherent organizing scheme, and as I mull over several possible
strategies, I get a bit confused as to what might be the best way
to proceed. (Any librarians out there with a focus on digital
imagery? I bet you go through these same wonderings all the
time.)
I know a good, and always true, answer to this question is
"Whatever works for you". Sure, I could experiment, and try one
organizing strategy after another, until I find what works for
me. In the end, of course, I'm sure that that's what I will be
doing, to a certain extent.
But what I'm hoping to do right now by querying folks on *their*
methods is to avoid having to try out for myself every possible
organizing scheme until I get it right. Renaming huge numbers of
files, re-doing directory structures, re-entering annotations,
re-creating fields and the field entries, and re-doing keywords,
over and over again while I thrash about experimenting is not my
idea of fun. I'm hoping to avoid having to reinvent *every*
little wheel along the way, by asking for your advice on what
you've found useful, and on what pitfalls to avoid. I don't want
to get far downstream using a particular cataloging data
strategy, only to discover some fatal flaw in that strategy after
scanning and naming and cataloging, say, 1500 images, and then
have to start all over.
Since I'm never sure if I'm clearly stating what I'm thinking,
here are some details that might help explain what I'm wonding
about:
I guess I'm actually wondering about *two* different points in
the "flow" from scan to image to cataloging. The first would be
in the file and directory structure itself, all of which happens
before I invoke Thumbs Plus. And then, the second area would be
in cataloging strategies using Thumbs Plus.
Regarding the image files themselves, what conventions do you use
for naming files and directories? Do you keep separate
"versions" of an individual image representing different stages
in the editing process?
For file names, I tend to adopt a "paranoid" strategy, and try to
put lots of info right into the filename, and I save multiple
files at each step. For example, say I scan in (into Photoshop)
an old photo of my cousin Gary on a horse. I would name that
original file
Gary on horse, as scanned.psd
Then I remove dust and scratches from the digital image, and then
crop it, adjust the contrast, sharpen it a bit, then (optionally)
resize it for a web page, and then make a 95%-quality jpg of it.
Under my current working method, I would save a file each step
along the way, so I end up with this series of separate .psd
files:
Gary on horse, as scanned.psd
Gary on horse, dusted.psd
Gary on horse, dusted, cropped.psd
Gary on horse, dusted, cropped, contrast.psd
Gary on horse, dusted, cropped, contrast, sharpened.psd
Gary on horse, dusted, cropped, contrast, sharpened, webresized.psd
Gary on horse, dusted, cropped, contrast, sharpened, webresized, jpg95pct.jpg
This is all for one photo. Aside from the fact that I need to
learn Photoshop better -- because I think some of those
adjustments can be achieved with something called "layer masks"
and hence all saved into one file (yet retaining the ability to
separate them out at a later time if need be), what I'm trying to
show here is that I have a tendency to try to put info into the
filenames themselves regarding the editing process. Is that
good, or bad? Should I save that info for Thumbs to handle?
Let's say I manage to master Photoshop to the point that I *can*
use layers and layer masking to put all those discrete editings
into one file, and do away with a need to archive the resizing
and jpeg-ing results (on the assumption that I could always
easily recreate those later if need be), and so I end up with
just two files,
Gary on horse, as scanned.psd
Gary on horse, reworked.psd
I guess I could put the technical editing info into Thumbs
fields, but then I worry about losing that info when I archive
those images over onto CD-R disks later, or at least, being faced
with having to re-enter it all onto the Thumbs scans of the CD-
Rs. (That seems a setup for error.)
But then I also wonder, am I trying to retain *too much* info,
either via filenames or via Thumbs? I could retain everything I
could possibly think of, on the fear that someday I may need that
info, but in your experience, what info actually *does* need to
be referenced in the future, and what info never comes up?
And what about directory structures? By subject, by date, by
genre, by people, by roll of film? There are so many parameters,
it seems so multi-dimensional, it's hard to decide on a hierarchy
for directory structure, or if (again), I should just go for a
minimal directory structure and leave the "presentation" of the
data to Thumbs Plus.
So much for files, filenames, and directory structure. The
second area that's befuddling me -- and that's more germaine to
this newsgroup, I guess -- is in the optimal usage of the data-
storage features of Thumbs Plus itself. Let's say I don't try to
shoehorn much image data into file or directory names at all, and
rely on Thumbs to do all that. I guess my main question in that
regard has to do with the fact that Thumbs Plus offers what seems
to me to be three different "buckets" for data: annotations,
keywords, and data fields. What best goes where? What info do
you put in the annotation, in the keywords, or in the fields, and
why?
First of all, it does seem to me that annotations are best used
for freeform "scribblings" about an image, things like "Uncle
Lucky's black eye was from his girlfriend Mellow, the cast on his
leg is from falling off the ladder getting the dog down from the
roof again, and he's flailing his arms around like that because
he was being attacked by bees just as I took the picture." (Do I
have the purpose of annotations right?)
So, that leave keywords vs. fields.
Here, I can figure some other things out on my own, too. For
example, it's easy to see that the year a photo was taken (or the
full date) belongs in a TP field, not stored as a keyword.
(Otherwise, I'd have to create a separate keyword for every year,
or every date, I have a photo for, a silly proposition.)
It seems that people's names, for example, also go best into
fields. For example, I'm thinking of creating a LastName field,
and a FirstName field, because that gives a lot of flexibility,
because I could do a search on "LastName=Johansen", for example,
and get all my mom's side of the family, the Johansens, or I
could pin it down to "LastName=Johansen and FirstName=Kenneth"
and get only the photos of my mom's brother, Uncle Kenny.
In fact, the more I think about keywords vs. fields, the more it
seems to me that I can't think of what advantage using keywords
might have over using fields, that everything you could do with
keywords could also be done with fields and with more
flexibility. So now then I'm wondering if I'm missing something
about the usefullness of keywords, as opposed to fields. With
the presence of fields, the presence of keywords seems redundant.
(So, what am I missing about keywords? What things go best into
keywords, rather than into fields.)
But back to fields. I think I see a deficiency, and wonder how
to deal with it. Suppose I have some photos that can have up to
ten people in them. To use fields to record each person's name,
I'd have to create a field FirstName1, LastName1, FirstName2,
LastName2, FirstName3, LastName3, ... FirstName10, LastName10.
But in most photos, most of those fields would go unused. Would
that cause a tremendous waste of space in the database file? I
guess since the TP database (at least from the user's
perspective) is not relational, we can't just create a separate
PeoplesName table with just FirstName and LastName and then
assign multiple records from that to our thumbnails, could we?
(Or again, am I missing something.)
And I guess the last thing I wonder about, once questions about
the purpose and usage of the various Thumbs Plus data-storage
features are resolved, is about the nature of the information
itself. What are the important parameters to maintain? Source
info, of course, like date, location, subject, people, etc, and
maybe camera and film and print info. Anything else? Which
parameters do you find yourself having to search on frequently?
Folks, I realize this has been quite a long post, and if you've
read this far you have my utmost appreciation. Thing is, all
these questions have been pestering me for months now, as I try
to plan out my big family-photo project, and I want to do it as
right as possible, and it finally occurred to me that maybe,
rather than continuing to torture myself with all these various
wonderings, maybe I should just spill my guts out about them all
to the cerious.misc newsgroup, in the hope that some of you have
had these same concerns somewhere along the way, and perhaps have
had some success in coming up with some methodology that deals
with them.
And, of course and it goes without saying, if there are any
websites out there that discuss such things, I'd love to hear
about them, too.
Thank you all for bearing with me. Thanks!
Steve LaMantia
Seattle, WA
Subject: Re: Photo Organizing Strategies?
Date: Sun, 11 Mar 2001 13:15:22 +0100
From: Uwe Zimmermann <uwe@ele.kth.se>
Newsgroups: cerious.misc
Hej Stephen, hello Group!
Yes, I read your long post, but I'm trying - for now - to answer a bit
shorter ;-}
I stand in front of a similar gigantic project, even though I do not
only consider family photographs, but all my conventional photographs
(in the order of 10k as a rough approximation) and my digital
photographs (3000 since May last year).
I don't know if it really is worthwhile doing so, but anyway, I've
already come quite far. I actually haven't thought about including the
names of people on the photo, but for this purpose I think a long UDF
should work fine, instead of having a douzen of first name/last name
pairs. You can fit a lot of information into 255 characters, the
longest field length available.
Considering the naming of files, I try to include the date and if
possible the rough location into the file name. Using the ISO date
format, i.e. century first, day last (20010311 for today) makes it
later possible to easily sort after this information - unlike
Americans and British who tend to mix day and month in their
significance...
I then collect about 100 pictures, scanned by my film scanner in
2700dpi, sorted into directories named after the date of the pictures,
compressed to still high-quality JPEG (5-8MByte filesize) and burn
them onto CD-R. According to the advice of a good friend, burning many
CDs a month, I'm considering actually storing an additional copy of
each CD together with it....
After having burned the files onto CD, I start archiving them with TP+
(scanning, sorting, converting are of course also done from within
TP+). Not all UDFs are yet filled in, but the pictures are given some
keywords and the thumbnails are archived into the database...
Uwe.
Uwe Zimmermann <uwe@ele.kth.se> schrieb in im Newsbeitrag:
3AB63B22.14D50F88@ele.kth.se...
> Nice list and good tips!
>
> I actually planned yesterday to abandon the date/time field due to its
> inconvenience in adding incomplete dates, e.g. year only, year and
> month only....
>
> Uwe.
This sounds like "paralysis by analysis". I started out organizing my
digital photos into folders etc. but I soon came to the conclusion that I
was just making life more difficult for myself. T+ makes it easy to
catalogue and find images, so now I just keep all my originals in a single,
flat directory. I try to annotate most of my images and then let T+ generate
keywords from the annotation. That covers 99.9% of my retrieval needs. If I
need to impose some sort of higher-level structure, then I use Galleries. My
camera generates files with names beginning with P and then a 7-digit
auto-incrementing serial number. I just leave the file name as the camera
generates it. The date the photo was taken is the file creation date. Also,
there is a very useful feature in the latest beta versions of T+ that will
extract info from the EXIF fields (if your camera generates them) and copies
the info to user-defined fields of the same name, so I get a second copy of
the date and a lot of other stuff besides, right into the database.
Stephen,
here are my experiences, knowing they don't cover all your needs:
I've been using digital cameras for four years now, accumulating pictures of
friends, family, vacation and business trips, and of special occasions.
a) While I initially started renaming pictures with meaningful names, I
quickly stopped doing so.
b) A visual catalog like T+ lets you find a picture more more quickly than a
file name, and keywords may allow for better searches than just file names
(but I haven't gotten around to assigning keywords).
c) I use directories to organize files, using a directory structure like
this:
photos\1999\...
photos\2000\...
photos\2000\00-12 Christmas Eve
photos\2001\01-01 Michael's Birthday
photos\2001\01-01 Trip to Casablanca
(I'm not adding days in the directory names as events may span multibple
days; events (trips) spaning two months are stored under the beginning
month.) I have 5-15 directories per month, and thus no trouble finding an
event.
Inside the directoroes, I may add directories for not-so-good or double
shots, so they stay out of slide shows.
d) I ALWAYS keep the original file, if necessary after lossless rotation. If
I modify an image, then I put the original in a subdirectory so it's still
there. The main directory holds the presentable images, ready to be shown
with Slide Show.
I hope this helps
Rainer
Subject: Re: Photo Organizing Strategies?
Date: Sun, 11 Mar 2001 20:00:30 -0500
From: Madeleine Dillmann & Erik Magnuson <maderik@cfl.rr.com>
Newsgroups: cerious.misc
Stephen LaMantia wrote:
> I'm about to embark on what's probably going to be a several-year
> project of scanning in thousands of old family photographs and
> storing them digitally (ultimately onto CD-R disks), and I'm
> hoping some folks can offer me some tips about how they go about
> the process.
I'm in the middle of a similar task. No matter how much I do, I'm still in the
middle! Remember that whatever you are doing, you will do it for 100's or thousands
of images. You want to streamline the workflow or you will never finish. Better is
the enemy of good enough.
> Regarding the image files themselves, what conventions do you use
> for naming files and directories?
I also started out with descriptive names. But this begins to get troublesome:
a) if you every want to use a command line or batch program, you have to quote all
those names with spaces.
b) "Joliet" CD-R format limits you to 64 character names.
So now, I don't worry about the filename as long as it's unique.
For directories, I have 2 strategies depending on the source:
1) photos from relatives' albums
2) dated slides or photo envelopes or digital photos.
Right now, my 1st level directory is by who gave me the photos, e.g.,
helmer\
erik\
lyle_dillmann\
The next level depends on the source. I either use album number/name or the date:
album1\
1964\
20010311\
For each photo, I then use an alphanumeric name based on the photo sequence number.
For albums I've tried two conventions: just simple sequentially increasing, or
page#-photo#. The thought behind page#-photo# was to make it easier to ask a remote
relative (who has the album) "Who's that in the photo on page N, lower-left?" in
practice this has not helped too much.
For slides (which usually have year-month-sequence#, I use a scheme like yymm-a##,
where yy is the year, mm the month, 'a' for the 1st roll (either by time or by
scanning order), and ## is the slide number.
For digital photos, I leave them in the camera name format.
Notice that my particular brand of paranoia makes me use 8+3 names w/o spaces.
Where I have descriptions of the photos (or dates) from the margins or backs, I type
these into a separate text file that is saved in the same directory (this is also
part of my special paranoia.) E.g.,
04-01: Helmer; Feb 1958
04-02: Helmer in San Diego; c1950
04-03: Helmer & Navy buddies
I later embed this description in the image as an image comment.
All of this means that I never have to worry about a database crash causing me to
loose anything irreplaceable than can't be fairly easily regenerated (or put into a
new or different database.)
> Do you keep separate
> "versions" of an individual image representing different stages
> in the editing process?
No. The original scans are archived on at least 2 CD-ROMs (w/description file). Then
I start work on editing. Sometimes I might add an 'a', 'b', 'c', etc. for
experimental changes, but mostly I overwrite the file. (After all, I have the
originals elsewhere.)
One other thing. I originally planned on using TIFF for storing all my files. I
judged it as the most widely supported lossless format. I then calculated how much
hard disk space I would need to keep everything online. Then I started adding up how
many CD-ROMs and and size of backup tapes I would need to keep the data safe. My
then-new 20GB disk starting looking awfully small and the backup times awfully long.
So I did a comparison of the loss w/JPEG at the higher quality levels even after one
or two edits. I decided that the 4x smaller files were worth the almost
insignificant loss of image detail.
> I could retain everything I
> could possibly think of, on the fear that someday I may need that
> info, but in your experience, what info actually *does* need to
> be referenced in the future, and what info never comes up?
Who's gonna want to use this information? Depending on technology, later viewers may
want to re-scan the originals with one of the new tunneling electron scanners that
picks up data from the molecular level and run it through the new software that
produces a 3-D hologram output. Will they care about spotted vs. non-spotted .PSD
files? Also, do you plan on finishing this process anytime this decade?
> And what about directory structures? By subject, by date, by
> genre, by people, by roll of film? There are so many parameters,
> it seems so multi-dimensional, it's hard to decide on a hierarchy
> for directory structure, or if (again), I should just go for a
> minimal directory structure and leave the "presentation" of the
> data to Thumbs Plus.
Exactly. This is the strength of using ThumbsPlus (a database) over other
mechanisms.
> First of all, it does seem to me that annotations are best used
> for freeform "scribblings" about an image, things like "Uncle
> Lucky's black eye was from his girlfriend Mellow, the cast on his
> leg is from falling off the ladder getting the dog down from the
> roof again, and he's flailing his arms around like that because
> he was being attacked by bees just as I took the picture." (Do I
> have the purpose of annotations right?)
Well, maybe. If you have that much description on most photos, I'd be surprised.
> So, that leave keywords vs. fields.
Of course fields are new in 4.10. They did not factor in my original planning.
> Here, I can figure some other things out on my own, too. For
> example, it's easy to see that the year a photo was taken (or the
> full date) belongs in a TP field, not stored as a keyword.
> (Otherwise, I'd have to create a separate keyword for every year,
> or every date, I have a photo for, a silly proposition.)
It's not so silly if you use the "Auto generate keywords" options to create all
these for you.
> But back to fields. I think I see a deficiency, and wonder how
> to deal with it. Suppose I have some photos that can have up to
> ten people in them. To use fields to record each person's name,
> I'd have to create a field FirstName1, LastName1, FirstName2,
> LastName2, FirstName3, LastName3, ... FirstName10, LastName10.
> But in most photos, most of those fields would go unused. Would
> that cause a tremendous waste of space in the database file? I
> guess since the TP database (at least from the user's
> perspective) is not relational, we can't just create a separate
> PeoplesName table with just FirstName and LastName and then
> assign multiple records from that to our thumbnails, could we?
> (Or again, am I missing something.)
This is where keywords might work better. Your searches would be much simpler as you
just have to search all 10 different name fields. I'm leaning towards using UDF's
for very structured data (like year), and keywords for less structured data (like
names.)
> And I guess the last thing I wonder about, once questions about
> the purpose and usage of the various Thumbs Plus data-storage
> features are resolved, is about the nature of the information
> itself. What are the important parameters to maintain? Source
> info, of course, like date, location, subject, people, etc, and
> maybe camera and film and print info. Anything else? Which
> parameters do you find yourself having to search on frequently?
Is this for you or your family? Most people only want to know who, what, when,
where. Camera/film info may be important for you, but I doubt anyone else will care.
However, you've left out one very important item: Are you planning to share this
database with your family? If so, how do plan to do that?
My plan is to create a CD-ROM using the web-page wizard + some home grown
scripts/mods. There would be index pages by date, person, and source all pointing to
the same base image directories. I figured this would be the easiest mechanism for
others to use/browse the photos. The only problem is what to do about screen
resolution. I either have to limit myself to no more than 800x600 or force some of
them to scroll around. (Ugh. I wish standard browsers had an option to resize images
to fit the window.) I actually prototyped this approach creating a photographic CD
record of one of my nephew's soccer season (e.g., index by game and by player). It
seemed pretty popular. It's platform independent (works the same on Macs or even
Unix.) It should also work on any foreseeable future platform.
I've not decided about including original size/quality images. Again this starts
getting into too many CD-ROMs to be practical. I guess I would provide those
on-demand.
Oh, well, I've matched your ramblings with some of my own.
--
Erik
This is getting into an interesting discussion!
And I thought I was alone in the world ;-}
> My plan is to create a CD-ROM using the web-page wizard + some home grown
> scripts/mods. There would be index pages by date, person, and source all pointing to
> the same base image directories. I figured this would be the easiest mechanism for
> others to use/browse the photos. The only problem is what to do about screen
> resolution. I either have to limit myself to no more than 800x600 or force some of
> them to scroll around. (Ugh. I wish standard browsers had an option to resize images
> to fit the window.)
If you change the output of the webpage wizard slightly, then you can
workaround this problem! Browsers do not have a resize option when
displaying just the image. When embedded into a webpage of their own
you can at least scale them to say 90% of the window size. Have a look
at my latest creation - and if you like it, you are free to copy the
code!
Oh, yes I forgot. The latest creation is down right now due to a giant
power failure affecting three parts of Stockholm icluding my
workspace. So try instead an older version:
http://user.tninet.se/~yxq358g/20000101/index2.html
It's pure Javascript, but you might need to use some tricks to get to
the source code...
Uwe.
Subject: Re: Photo Organizing Strategies?
Date: 11 Mar 2001 21:46:18 -0800
From: layer@killspam.known.net
Newsgroups: cerious.misc
Like Uwe, and others, I have 1000's of pictures from digital cameras.
I use a combination of directory structure and TP keywords.
I read into pictures\_TMP\, where I make several passes over them to
classify as outtakes, printable, etc. For pictures that are out of
focus, or are bad for other reasons, I just delete them outright. By
`classify' I take them with keywords.
I move the outtakes to a single directory on a hard drive, that is not
backed up, with the name of the year (ie, 2001). Then, I forget about
them. I've rarely looked at them again.
The remaining pictures are moved into directory structure having to do
with subject:
family\layer (my last name)
\vu (wife's last name)
\lp (cat's name)
\adrian (son's name)
franz\ (company I work for)
imported or scanned\
inventory\
misc\
slides\
You get the idea. In each of these directories, I have subdirectories
for year, then month. For example,
family\adrian\2000\12\
Also, I have a program that renames my pictures out of the camera(s)
like this:
YYYY-MMDD-hhmm-ssnn-zzzz.jpg
YYYY is the year, MM month, DD day, hh hour, mm minute, ss second, nn
sequence number (some of my cameras can take multiple pictures per
second) and zzzz is the camera name.
This way I can search for pictures by date or subject/event.
Kevin Layer
Subject: Re: Photo Organizing Strategies?
Date: Mon, 19 Mar 2001 15:45:54 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
This is very useful. Fascinating to see the different approaches people have
adopted. Here are some thoughts after working for six months on what will be
a large archive of family photos.
First some somewhat controversial generalizations:
1. The directory structure does not matter very much. And if other things
have been done right, it can be changed easily as you go along.
2. Do not try to put useful information into file names; use auto-rename as
much as possible.
3. Make sparing use of User Defined Fields (UDFs), essentially only for
quantitative information which you want to be able to sort ordinally or
cardinally.
4. Keywords are very well implemented in TP - make liberal use of them.
5. Comments are useful, Annotations are not.
6. Cropping is a problem - which could be solved
7.Try to keep copies of the same image to a minimum.
8. The canned slideshow is fine - but could be improved.
DIRECTORY STRUCTURE.
Family photo archives do not lend themselves to hierarchical classification.
Families merge and dissolve, photos often include people from different
branches of the family etc.. However, rather than put all photos into a
single folder, it is convenient to split them up in a pragmatic way.
Depending on the circumstances there are many possibilities: batches as
scanned; branches of the family roughly defined; by date when taken; events
such as weddings; and so on.
The above would not apply to more hierarchically structured data, for
example photos of animals classified by genus, species, sub-species etc, or
a product catalog with many sub categories. For these a rigorous directory
structure would be desirable. But more important would be a structured use
of UDFs (which, for reasons discussed below, TP is not yet well equipped).
FILE NAMES
Personally, I am hopeless at entering and reading file names with long
strings of numbers. Before the advent of UDFs there was nevertheless a case
for using a system of folder and file names to record *Date Taken* as Rich
Pasco does in a very systematic way.
I use file names as follows. I scan using *Mutiple acquire TWAIN* which
automatically allocates a file name (in my case Scan_0001, 0002 etc) and
saves them in a WIP (work in progress) folder. After working on them, when
they are ready to be archived, I create a gallery for them, rearrange them
manually into the order I want for a slideshow, auto-number them, move them
into their appropriate folder in the database, sort that folder by *Date
Taken* and *File name*, and then auto-rename that folder (which has a unique
three letter prefix). In other words my file names give info about the
folder and the order in the folder only - but none of them are ever entered
by me (saves a lot of time).
USER DEFINED FIELDS
UDFs were added to TP quite recently and there is still room for
improvement. As of now, there are no drop down lists to enter values, which
makes it quite impracticable to enter any significant amount of text. (If
you used them for names you would have to keep entering them over again all
the time). Also one can only display three UDFs at a time in thumbnail view,
and
one can only sort on two UDFs at a time (which would be a serious handicap
with
a multiple level hierarchical classification system).
Probably the main use of UDFs is for *Date Taken*. A problem with family
photos is that the date is often guessed and is often incomplete - the year
only, or month and year but no day. For this reason I do not use the Field
Type *Date/Time*. Instead I use a slight variant on the method used by Rich
and Uwe. I define the Field Type as *Decimal*, then enter the year as four
digits. If - but only if - I know the month, I add a decimal point and put
the month
into the first two places after the decimal point (and the day into the
third and fourth). I also have a second *Text* UDF named *Date guessed* into
which I put a question mark when the date has been guessed. I have a third
*Numeric* UDF called Sequence, into which I enter, if necessary, the order
in a slideshow for photos with the same date. (This means that when I am
preparing a
slideshow with a selection of photos from different folders I simply sort
it on *Date Taken* and *Sequence*). I also have a *Numeric* UDF for
*Interest/Quality* rated from 1 to 4.
Some other photo archiving programs handle Date Taken better than TP and I
have made suggestions to Laura about this.
Note that all my photos are scanned. If one is using a digital camera it
obviously makes sense to use EXIF info, especially for Date Taken. I believe
there are plans for an option in version 5 to enable one to embed *Date
Taken* into image files as EXIFs (and IPTCs?), which could be very useful.
KEYWORDS
These are handled very well in TP. There are drop down lists both by
alphabetical order and most recently used. Keywords can be assigned to
multiple images. There is a very useful (undocumented) AutoFind function
whereby if, with the drop down alphabetic list displayed, you type the first
few letters of a keyword the list scrolls to the nearest keyword. It is also
possible to Edit keywords, e.g. if you want to change the spelling you can
change all the occurrences of that keyword in one go.
Some tips. Put family name first, a comma, then the given name. Let women
keep their maiden names. Have keywords for places that recur in the family's
history. Look out for special themes: e.g. my family has done a lot of
sailing over the last 120 years, so I have Sailing as a keyword.
An example. Recently back from a trip to Australia I scanned in the 80
photos. First I selected them all and entered at one go UDFs for November
2000, and Interest/Quality 4 (which I modified later for the less good ones
when viewing them). I then selected them all again and entered an *Australia
2000* keyword. I then selected all photos with my wife in them and selected
and entered her name from the drop down list using AuroFind. Ditto for
myself and all
the other members of the family (most of whom were already on my keyword
list). Ditto for all the sailing photos. And so on. In a surprisingly short
time I had entered the date taken and over 250 keywords for the 80 photos.
COMMENTS AND ANNOTATIONS.
Comments are stored in the image file and can be displayed in a slideshow.
Annotations are stored in the td4 database file and cannot be displayed in a
slideshow. I use comments a lot, especially for old photos. I have not found
any use for Annotations I suppose they could be used for textual
information which one does not want displayed in a slideshow. As far as I
can make out, however, either Comments OR Annotations can be shown in the
*Annotation* column in Report View, but not both. (Note that to have
Comments show in this column one must select *Always* in
Options>Preferences>Thumbnails - but that as I have informed Laura this is
not working properly in my copy of beta
5).
THE CROPPING PROBLEM
This one I learned the hard way. I cropped into a portrait view, forgetting
that I
was also going to want a landscape version for the slideshow. I cropped out
an unknown individual who turned out to be somebody's best friend. I forgot
that in old photos people may be interested in the garden of the old family
house in the background, or the old cars parked in the street.
So now (a) I crop the original only minimally, (b) I print using the HP
PhotoSmart printing program with which I can lay out photos contiguously for
cutting on A4 paper in all shapes and sizes, and can crop, rotate etc to my
heart's content without altering the original file, and (c) I create a JPEG
copy of the original for the slideshow cropping it using TP's neat Trim to
Size
function.
This last step would be unnecessary if TP copied a feature from one of its
competitors which enables one to create different views of the same image
without copying the file. Apart from halving the size of the database, one
could use this in a slideshow to show the whole photo followed by one or
more close-ups. I have shown this to Laura and I hope others will agree
that it should be quite high up on a list of new features to be added.
KEEPING MASTER COPIES
I started by creating master copies of each scan in special folder "for
posterity". I dropped this because it became tedious and I realized
that it doubled the size of my database. I am now considering copying each
batch of scans to a CD before processing them using Windows Explorer (so as
not to create an entry in the database), simply numbering them
consecutively.
If they are ever needed they could be found again by bringing them into TP
and using *Date Created* and/or *Find Similar*
DISTRIBUTING TO THE FAMILY
My experience so far is that the family mainly likes looking at the
archive in a slideshow, although they also want prints of selected
photos. So the easiest thing is to give them the canned slideshow plus the
image files on a CD. (But, as of now, the canned slideshow is much less good
than the internal slideshow).
Actually, one of the reasons I bought TP is that there is a CD Developers
kit to create runtime executable versions of TP which can be distributed
free to family members. This would be the obvious answer for computer
literate members of the family who did not want to cough up $80 for the full
version, but it has not yet been updated from Version 3.
I have not tried the Web features yet. Uwe's web page is fun, but I cannot
see the advantage over a slideshow for distributing my archive to the
family.
Stephen Marris
Paris
Subject: Second thoughts
Date: Sat, 24 Mar 2001 15:17:26 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
With Ray's post it gets more and more interesting!
The thing that really surprises me is the relative complexity of the
directory structure and file naming conventions used by almost all of the
experienced long time TP users who have contributed to this thread.
I bought TP because it is an image DATABASE program, and to me one of the
important differences between an image viewing program like ACDSee and an
image database program is that the former requires a carefully designed
directory structure whereas the latter does not. Indeed, almost by
definition, in a *pure* database the images would all be in a single folder
and would only be accessed by a search query.
No doubt one of the reasons everybody makes good use of the directory
structure is that cerious has designed such a nice emulation of the Windows
explorer tree, with a very full set of folder and file management tools.
But the question newcomers will need to consider carefully is how far this
complexity of the methods used by old hands may, as I believe, also reflect
past - and to some extent present - weaknesses in TP's database management
tools. In particular, newcomers should note that the ability to SORT on UDFs
was
only introduced last December in version 4.15 which is still in beta.
I have divided my thoughts on this in to three separate posts covering, Date
Taken, UDFs, and handling several copies of the same image.
Stephen Marris
Subject: Second thoughts - Date taken
Date: Sat, 24 Mar 2001 15:27:02 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
It is striking that most experienced TP users have resorted to complex
directory structures and/or file names in order to deal with Date
Taken problem (the *problem* being that at least in family photo
archives it is essential to be able to organize the photos and sort
them by the date the photo was taken, which is often incomplete). They
have all (including myself) also developed some variant of the ISO
date format for this purpose.
I feel this indicates rather clearly the need for a dedicated Date
Taken routine along the lines of my March 20 post on this subject in
the *Suggestions* newsgroup. I suspect, however, that Laura feels I
have an obsession on this subject (which I first raised last summer
and have come back to several times since). Maybe I am obsessed, in
which case let's forget it. But if others agree with me I think they
should let Laura know in the hope this will help to convince her and
Phillip that this enhancement should be given a higher priori than at
present seems to be the case.
There would, of course, be a problem of backward incompatibility, so
that this enhancement might be of little interest to old timers who
already have large databases. But ultimately the prosperity of TP
depends on a steady supply of NEW users, and potential new users may
be put off if (like me) they look at the various programs on the
market and note that others have a dedicated Date Taken function
(although not as nice as the one I have suggested!).
Finally I should declare a personal interest. If this enhancement were
introduced quite soon my database is still small enough that it would
make sense to re-enter the *Date Taken* info - especially if the new
routine also embedded this data into the image file. But by the summer
or the autumn it will be too late.
Stephen Marris
Subject: directories (Re: Second thoughts)
Date: Sat, 24 Mar 2001 16:52:05 +0100
From: Uwe Zimmermann <uwe@ele.kth.se>
Newsgroups: cerious.misc
I cannot see anything wrong with the combination of TP+ and the use of
directories. I have seen what happens when you have too many images in
a single directory - luckily enough the corresponding problems have
been fixed with beta6. Having your images sorted into smaller
directories also makes backup onto CD-R much easier and once you have
exported your images onto CDs you can much easier pick the right CD.
Also when it comes to modified, downsampled etc copies of pictures,
it's convenient (for me) to have those in subdirectories. In TP+ you
have always the possibility to view all thumbs from the child folders
at the same time when you want to.
And here comes a suggestion!
It might be a nice feature to be stored in the database that certain
directories always automatically display the thumbs from their child
folders....
Uwe.
Subject: Second thoughts - UDFs
Date: Sat, 24 Mar 2001 15:35:42 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
I was intrigued by the ingenious way Ray got around the fact that the were
no UDFs in version 3 which he used to set up his database - by giving
prefixes to Keywords such as @ for places, # for people, and so on.
I imagine that Ray would readily agree that with version 4 a simpler
solution would be to create a UDF named, say, CATEGORY, and then enter
values into it - PLACES, PEOPLE, and so on as appropriate. In fact it would
be relatively easy to convert his quite large database along these lines:
- Create the UDF CATEGORY in Files>Database>User Fields. Select all the
files with a keyword beginning with @ and then assign the value PLACES in
the UDF CATEGORY to them all in one go.
- Then go to Files>Database>Edit Keywords and delete the @ prefixes
I suspect, however, that Ray would also agree with me that it would hardly
be worth doing this until two improvements have be made to TP's UDF feature,
namely: Drop down lists to enter text into UDFs; and the possibility of
displaying more than 3 UDFs in Thumbnail view.
Again I made a suggestion along these lines as far back as last summer, so
far to no avail. So if others agree that it should be given a relatively
high priority they should Laura know (To an ignoramus like me it looks like
a relatively easy piece of programming, which need not wait for version 5)
Stephen Marris
Subject: Re: Second thoughts - Date taken
Date: Sat, 24 Mar 2001 16:45:21 +0100
From: Uwe Zimmermann <uwe@ele.kth.se>
Newsgroups: cerious.misc
Hej Stephen, hello everyone!
Considering the "date taken" routine you suggest, I don't know if it
really is a necessary feature in a program like TP+, as it only
applies to photographies, but not to other graphics like web buttons,
backgrounds,....
However a slightly more flexible date field would be nice, but that's
probably a problem of the underlying database engine rather than TP+.
Using a text string containing the date taken in a user field is an
effective solution - at least in my opinion...
Uwe.
Subject: Re: directories (Re: Second thoughts)
Date: Sat, 24 Mar 2001 19:16:11 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
Hi Uwe
Thank you for opening my eyes to another neat feature of TP which I haven't
used up to now - Show Child Folders!
First, of course I entirely agree with you about using directories to keep
the number of files down to manageable proprtions. I was't seriously
suggesting putting everything into one folder! What I was trying to do was
to push the *database logic* to its outer limits in order to identify the
optimum use for the directory structure. My general answer remains the same
as in my original post - in family photo archives use it in a pragmatic way
to keep folder size to manageable proportions.
But you have now convinced me that there is a strong positive case for using
sub-directories for copies of the same image in different form. This is
because you have solved my *editing* problem, since by using *Show Child
Folders* one can see all the different versions of an image in
sub-directories alongside one another, and hence it is very easy to select
them all and edit them in one pass. This is a much better solution than my
suggestion about galleries.
To give an example for the benefit of others. I have a directory with TIf
files for printing. I create a *Slide* sub-directory. I do a batch convert
to JPEG specifying *Slide* as the destination directory and adding the
suffix _SLIDE to the JPEG files. I can go into the Slide directory and, for
example, Trim to Screen proportions. But also if I open the TIF directory
with Show Child Folders, I can see and edit successive pairs of the TIF and
JPEG versions for, e.g. an additional Keyword.
I am not sure about your suggestion for an option to designate certain
directories to always show child folders. For many purposes one does not
want to see them, and the Shift-Ctrl-N toggle makes it extremely easy to
switch from one view to the other.
I think we are getting somewhere!
Stephen Marris
Subject: Second thoughts - storing copies of files
Date: Sat, 24 Mar 2001 15:44:28 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
Apparently we all use directories or subdirectories to store copies of
images made for different purposes - Original, Edited, Slideshow, the Web
etc. It has only now occurred to me that this is contrary to my dogmatic
view that databases do not need a directory structure. So here are some
further very tentative views on this subject.
An alternative would be to put all the different versions of the same image
in the same folder, with different suffixes to their file names to
differentiate them.
A significant advantage - at least for me - would be that if at some later
date one wanted to edit a Comment, add a Keyword, or whatever, one could
simply select all the different versions (which would be next to each other
in the folder) and make the change in one pass. This would be much easier
than remembering to go to each of the relevant folders, finding the file,
and making the changes one by one.
An obvious disadvantage is that it would no longer be possible to go
straight to a folder and, for example, display it in a slideshow or on a web
page (all the different versions would appear).
But here's another thought. As of now I only use galleries temporarily to
re-order my photos manually. But we have been promised nested galleries (for
version 5?). So what one could do is have a streamlined DIRECTORY structure
for the *database* with all copies of the same image in the same folder, and
then have a more sophisticated GALLERY structure with different branches for
Slideshows. Web pages, and so on.
As I understand it, files are not copied into galleries, there is simply a
*link* back to the file. If so, this means that this technique would not add
inordinately to the size of the database, and that changes made to a file in
the database would automatically carry over into the gallery, and vice
versa. I believe it might also be possible to have a routine whereby when
images are added to the database the gallery is updated automatically. (I
gather some people already make quite intensive use of galleries).
I am quite tempted by this idea, although it would require me to develop a
slightly more complex convention for naming my files, which might mean that
I had to use, like Ray, an external naming facility.
As I said, these are very tentative ideas, and I would love to know what
other people think !
Stephen Marris
Subject: Uwe on Date Taken
Date: Sat, 24 Mar 2001 19:32:11 +0100
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
Hi Uwe,
OK, I don't get your vote on Date Taken.
People clearly use TP for a great many different things. I would have
thought that for a fair number Date Taken was an important piece of
information, but I may be wrong.
As things stand I think the procedure outlined in my original post is the
best solution. It is not that bad. It's main disavantage is that the
(sortable) number looks mysterious when displayed in thumbnail view, and
could not be used to display the date in a slideshow (or printed out) when
it becomes possible to display UDFs automatically as is planned for the
future.
Agreed it could not be accomplished without writing a special routine, but I
would have though that would be child's play compared with some of the
amazing graphic enhancements that Phillip has produced.
Stephen Marris
Subject: Date created
Date: Sun, 25 Mar 2001 13:13:44 +0200
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
I increasingly think that the date an image was entered into the TP database
is a useful piece on information which should be permanently recorded. (*Oh
yes, I remember, it was in that batch I scanned last Easter*). I was
hoping/assuming that the Windows *Date created* would serve this purpose,
although I had my doubts. These have been confirmed by a FAQ in the new
section on the cerious web site and some subsequent experiments.
If I was starting from scratch I think I would have a *Date entered* UDF,
and then, at the end of each scanning session, I would simply *Select all*
and enter the date in one pass in my variant of the ISO format. (I would do
it now, except that the new UDF would come at the top of my list, whereas I
would want it at the bottom, and, as of now, there is no way of reordering
UDFs from within TP).
Stephen Marris
Subject: Re: Date created
Date: Mon, 26 Mar 2001 15:30:11 +0200
From: "Stephen Marris" <s.marris@wanadoo.fr>
Newsgroups: cerious.misc
In a reply to me in the Support group thread on this subject Uwe tells me:
<I can only say that WinNT4 sp6(a) handles the date/time attributes
correctly. The "date created" is not changed by a modify/save command,
nor by copy or move commands>
This is very interesting and also important for TP users, since it does not
work with Win98SE. It would be useful if others could tell us whether it
works with Win2000 and WinME, and then perhaps it would be a good idea if
Laura could update the FAQ.
Personally I was hoping to wait for XP before upgrading - bxxxxxxy MS!
Stephen Marris
Subject: Re: Photo Organizing Strategies?
Date: Mon, 19 Mar 2001 18:00:18 +0100
From: Uwe Zimmermann <uwe@ele.kth.se>
Newsgroups: cerious.misc
Nice list and good tips!
I actually planned yesterday to abandon the date/time field due to its
inconvenience in adding incomplete dates, e.g. year only, year and
month only....
Uwe.
Subject: Re: Photo Organizing Strategies?
Date: Sun, 25 Mar 2001 17:43:16 -0500
From: "szt" <szturn@home.com>
Newsgroups: cerious.misc
This is a great discussion. Deciding how best to use Annotations vs.
Comments can be confusing. I use Comments to permanently identify features
of an image, particularly in archived copies (on CD or wherever). Most of my
images of late are jpeg, generated by an Olympus digital camera, and many of
my old scanned images are jpeg also. Converting jpegs to tiffs avoids the
problem of lossiness when writing image Comments and then saving the file.
It's best to write image Comments soon after acquiring images while details
are still fresh in mind. Fortunately, conversion of tiff to back to jpeg
copies Comments to the jpeg, which can be sized, etc. for its current
purpose.
A neat feature of TPbeta6 under Options|Preferences|Thumbnails is 'Auto copy
image comments to db annotations.' Since I write Comments like image
captions, they can then be displayed with TN's in web settings, etc.
(Options|Show for Files|Annotations). This will overwrite (I assume) the db
Annotations field, effectively making image Comments and db Annotations one
and the same. So far I haven't found a need for db Annotations, except as a
vehicle for displaying a caption created in the first place as an image
Comment.
It should be possible to hold other data (e.g., keywords or user defined) in
image Comments, probably by using standard delimiters. These data elements
could then be parsed out and copied into appropriate db fields on the fly or
as part of creating or repairing a db. The advantage would be that key data
would be always filed as part of an archived, lossless image. Loss of the db
wouldn't be quite as catastrophic. Just a thought.
3.5.2001
Hi Stephen, hello everyone,
You have initialized a very fascinating discussion. My experiences are
similar to Yours.
I Think, if You want to build up a new_database, You have to develop
1. one_strategy to STORE_files
2. some_strategies to FOUND_files (and LOOK-files).
Reason for this important difference:
only a few media files have one dimensional contents. For example: one photo
may content
- an event ("just married"),
- a person (or a group),
- a location
If You wish to store the files in folders following the contents of a file,
You have to decide what content is the most important and You may create
folders following person's name or the location. If You follow this, You
will be confused after ca. 2000 files, because some informations will get
lost.
Conclusion: never store files in folders following contents of a file! With
T+ You can get a maximum flexibility to access an found the contents of the
files. The most important are the
- keywords: yon can easy solve the problem of multiple persons or objects in
a file, for example assign to one file the keywords "John", "Mary",
"Christian", "marriage", "Our Home" [for location]. For Date/Time of an
Event You may assign the Keywords "2001" [year], "April" [month], "spring"
[season], "flash" [if You used it] and so on. Indeed the keywords an their
boolean combination allow the most flexible access to file contents. Much
better than the unflexible hoerarchy of a folder structure.
- annotations and
- users fields (improved by 4.15 of T+). With the EXIF- Transfer to user
fields Yo can get the Origin Date/Time of a file. If You scan chemical
fotos, You may assign UDF's after scanning some similar files.
The almost best way for storing files is a simple sequential order. It
Means: create on the first level folders for each Year, in the second level
for each month, third level for days or weeks. That's all. The file names
must not show any contents, it ist enough to assign an sequential (automatic
generated by T+) clear- cut alfanumerical name. The only exception in the
first level may be different kinds of files, for example: Black and White
negative scans, Color Slide Scans, Digital Photos, Videos.
An Example may look as follow [Comments in brackets]
- B&W [Black and White Negative]
- 1999 [year]
- 01 [month, january]
- 01 [Day, new year)
- 28 [day][marriage]
- 04 [month april]
- 01 [day]
- jokes [1st event, only if You have too many files for overview
in one folder]
- hiking-trip [2nd event, only if You have too many files for
overview in one folder]
- party [3rd event, only if You have too many files for overview
in one folder]
- 2000
- 01 [month]
- 22[day]
- 07 [month]
- 13[day]
- ColorSlides
- 1999 [year]
- 01 [month]
- 01 [Day, new year)
- 28 [Day, marriage]
- 04 [month]
- 01 [Day, April' joke]
- 2000 [year]
- 01 [month]
- 22 [day]
- 07 [month]
- 13 [day] [hiking trip]
- 12 [day]
- 25 [day] [Christmas]
and so on. Don't forget leading zeros in the folder names < "10"!
The separation of Storing and Accessing of/to files is the new chance
offered by modern Software Products like T+.
For access to files T+ will offer You a lot of Instruments like
- found files query (with further improvements)
- Galleries ( with further improvements, most important are nested
(hierarchic) galleries).
I recommend to use these advanced instruments instead of folders. This is in
my opinion the great benefit of DATABASE Software like T+ compared with
simple VIEWERS like the famous ACDSee or teh great freeware IrfanView.
If You have an old Database or folder structure:
I'm a chemical photographer since 1982 with about 80.000 photos. Therefore i
stored my negatives and slides in foils, collected in physical folders, the
folders collected in a mixed content/ format- orientated groups: the number
1 stands for hiking trips, number 2 for Architectur, 3 for Landscape and
nature, 4 for Cementaries and towns, 6 for 6X6 Black&White Negatives, 8 for
35mmm Black&White Negatives, 9 for Holidays. Now i think (except for extra
collections for the 6X6 B&W and 35mm B&W): this was a mistake.
But in a pragmatic way i don't reorganize t the complete order. Instead of
such a heavy process i use the keywords and UDF's to get the most flexible
access to the files. And the most important: the original version was a
simple table in a MS-DOS Worksheet program (~ 1988), then i transferred it
to the database software Question & Answer (Q&A) from Symantec - the
formerly best in the DOS-Time (~1992). This software disappeared from the
market several years ago. Now i transferred it to MS-ACESS (~1998). I had to
work with SQL-Queries, Tables, Forms, Reports... Heavy work. And in T+ i
could import the access database with some MS-Acess-queries for filling
UDF's and annotations. Now i have to decide to throw away the troublesome
buliding up MS-ACESS Database.
Since 1999 i scan the most important and example- film pieces for the only
purpose to find the chemical fotos. For this purpose are UDF's with the info
about the physical photos necessary. I'm glad about T+ by the following
reasons
- i could import my "historic" Informations
- no need to reorganize the folder and file structure
- flexible access to the database infos and the files
- no need for advanced Database tricks for building an own Database
So i recommend the following simple methods in summary:
- Buildung a new database: make a separate strategy for STORE and FIND
Files. Make a simple sequential folder structure sorted and grouped only by
Date/Time
- Old database/folder structure: do not change the old folder Organization.
The disadvantage and the lacks of this structure are not so heavy in
comparison to the lot of work with the reorganization of an complex folder
structure (say nothing of reorganize PHYSICAL_FOLDERS with chemical
Photographs). With keywords, User Fields, Queries and Galleries You can
nearby equalize these problems.
So - that's only my experience. Maybe the one ore another of You may have a
benefit of my learning in the hard way.
Christian
