Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 




      :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: filmscanners: Scanner resolution &File Sizes (& workflow)

I scan to the hard drive, and when done with a roll transfer to CD-ROM.  I
use Irfanview (freeware) from
to make a thumbnails sheet which I then print out on inkjet to stick in with
the CD, save a copy with the images on the CD, and save a copy on the hard
drive while deleting the image files themselves.


----- Original Message -----
From: "Lynn Allen" <ktrout@hotmail.com>
To: <filmscanners@halftone.co.uk>
Sent: Monday, June 25, 2001 10:27 AM
Subject: Re: filmscanners: Scanner resolution &File Sizes (& workflow)

| 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
| >a
| > > program that would save both a TIFF and a much smaller JPEG file to
| >and
| > > index them according film strip, date scanned and frame#. Then one
| > > 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
| > > "Intellectual Property"--so feel free to run with it, anyone. If I
| >a
| > > better programmer, I'd start on it tomorrow, and wouldn't have
| >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
| >what you are proposing.  It's just a matter of locating them.
| >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
| >and faster methods, but the following workflow and method works for me
| >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
| >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
| >even an 80 gig drive will fill up if you don't purge it often).  I
| >files from the hard drive to CD as soon as possible (as protection
| >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
| >uncompressed resolution.  These files are never stored as sharpened
| >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
| >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
| >the
| >same CD.  I print one copy of each proof sheet for my records and
| >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
| >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
| >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
| >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.
| >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


Copyright © Lexa Software, 1996-2009.