ðòïåëôù 


  áòèé÷ 


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)



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




 




Copyright © Lexa Software, 1996-2009.