Thanks, Roger, for that work-flow description. I've also found that
anotating a proof-sheet is very labor-intensive, which is what prompted my
comments. Seems like there ought to be an easier way, but I haven't found
one, either--despite the claims of the software packages.
Keeping a tidy shop is a b*tch. ;-)
Best regards--LRA
>From: RogerMillerPhoto@aol.com
>Reply-To: filmscanners@halftone.co.uk
>To: filmscanners@halftone.co.uk
>Subject: Re: filmscanners: Scanner resolution &File Sizes (& workflow)
>Date: Sat, 23 Jun 2001 18:10:04 EDT
>
>In a message dated 6/22/2001 6:20:01 PM Pacific Daylight Time,
>ktrout@hotmail.com writes:
>
>
> > Rafe wrote:
> >
> > >35 mm images are about 60 Mbytes (24 bit color.)
> > >645 images are about 160-170 Mbytes (24 bit color.)
> >
> > That stands to reason, given the larger size. I'm wondering if there is
>a
> > program that would save both a TIFF and a much smaller JPEG file to HD,
>and
> > index them according film strip, date scanned and frame#. Then one could
> > select the best TIFFs and dump the weak ones, but still have good
> > references
> > for future work.
> >
> > If there isn't, it's just an idea and I don't believe too thoroughly in
> > "Intellectual Property"--so feel free to run with it, anyone. If I were
>a
> > better programmer, I'd start on it tomorrow, and wouldn't have mentioned
>it
> > today. (I might not believe in IP, but I'm not stupid, either! ;-) )
> >
> > Best regards--LRA
> >
>
>There are probably a number of programs out there that will allow you to do
>what you are proposing. It's just a matter of locating them. Personally,
>I
>use a rather simple method of managing my digital photos that doesn't
>require
>any special software and is suited to my needs. I'm sure there are better
>and faster methods, but the following workflow and method works for me and
>might give some ideas to others who are developing their own system or
>workflow:
>
>I don't scan anymore than I have to. I scan mostly 35 mm slides and they
>remain in their original box except during the actual scan, so I don't have
>the dust problems that others on this list complain about. I don't leave
>scans on my hard drive any longer than I have to (it's surprising how fast
>even an 80 gig drive will fill up if you don't purge it often). I transfer
>files from the hard drive to CD as soon as possible (as protection against
>a
>crash and to allow for disc purging) and I make CDs only if I anticipate
>needing to work with that image again (if I guess wrong, I can always
>re-scan). I store images in psd format, not tif or jpg, and at their full
>uncompressed resolution. These files are never stored as sharpened images
>and Photoshop annotations are added when useful. Each slide and its
>digital
>file is give a name that includes the date it was processed, the roll
>number,
>and the frame number (for example, "28Mar00 R06 F34"). The date and frame
>number are already stamped on the slide by the processor and I write the
>roll
>number on the slide when I scan it. Note that I use two digit roll and
>frame
>numbers (R06, not R6) so that they will sort properly. The date could be
>written in a different format for better sorting too (000328 for 28Mar00,
>for
>example) but that's not necessary for my applications.
>
>All images for a given job that I want to "archive" on CD are also copied
>to
>a "proof sheet" file using Photoshop to create that file. That file is
>designed to print on 8.5 x 11 inch paper and each image on it is 2 inches
>high. I can sometimes get nearly 50 images on one proof sheet because I
>crop
>tightly around the model and sometimes even "knockout" the model from the
>background. The entire proof sheet file is heavily sharpened, even if it
>messes up the skin tones. Each image on the proof sheet has the roll
>number
>and frame number printed next to it and the date and any brief notes,
>customer name, etc., are printed only once somewhere else on the proof
>sheet.
> Every image copied to a CD also has its associated proof sheet copied to
>the
>same CD. I print one copy of each proof sheet for my records and sometimes
>an additional one for the customer. I also print a word document listing
>the
>file names for each CD. By the way, creating the proof sheet is the most
>labor intensive part of the process and the area that could use some
>software
>automation. But, for me, the software would have to be optimized to get as
>many cropped and knocked out images as possible on a single proof sheet.
>That's something no commercially available program probably does, but I'd
>be
>happy to share royalties if someone wanted to write such a probram.
>
>The result of my work flow is that I can keep a fairly clean hard drive and
>I
>have a hard copy of a proof sheet for every important image. I, or my
>customer, can use the proof sheet to readily identify and locate a given
>slide or its CD file by using the file/slide name shown on the proof sheet.
>Some people might prefer to keep a copy of the proof sheet on their hard
>drive, but I prefer to purge it and use the hard copy version instead. By
>the way, unlike others on this list, I don't consider CDs as archival
>storage
>due to their relatively high failure rate and prefer to rely on the
>original
>slides themselves as the archival storage media. CDs are a convinience,
>but
>are not likely to last as long as the original slide.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com