ðòïåëôù 


  áòèé÷ 


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: Scanning and memory limits in Windows



Now that I see you are stating load times for uncompressed files I see
our times are much more similar. LZW compression is very CPU-intensive
and there is no comparison between load times for non-compressed and
compressed files (other than compressed files take a *lot* longer).

I compress TIFFs before putting them on CDs because it's much easier to
manage 800 CDs than it is to manage over 1200 CDs. The reason I see a
fairly large compression ratio is that I am saving 48-bit TIFFs, but
the scanner uses only about 40 of them.

There *is* a big hit in load and store times, though, which is the
reason I compress *only* what's going onto the CDs. Images that are
being played with are left uncompressed to reduce the file-handling
times (even though the files are much larger).

The upshot of this conversation is to point out (yet again) that one
needs to look at where the bottlenecks really are. If the process is
largely CPU-bound, as loading and storing LZW-compressed TIFFs are on
my computer, I will realize much greater gains if I spend money to
upgrade the CPU than if I get 10,000 rpm drives. Others who have fast
processors and do not use LZW compression may well find their hard
drives are the bottleneck and would be far better off upgrading them.
It is up to each person to investigate where the bottlenecks are in
*their own* processes and act to relieve them, instead of just assuming
they need a particular item (faster hard drives, more RAM, or
whatever).

As for "mucking about" with the image, lossless compression schemes
like LZW merely encode the values in different bits than straight
binary. It's really a code similar to Morse code -- the most popular
values are stored in fewer bits, and the least popular take lots and
lots of bits but because there are so few instances of them the overall
number of bits (and therefore bytes) needed to store the image is
reduced. As for questions about how lossless the process is, just do a
file compare between the original uncompressed image and one that has
been retrieved from a compressed TIFF. I have yet to see anything other
than an exact match -- if there is a difference there is something
definitely wrong with the computer!

Ta for now,
  --Dana
----------
From: geoff murray <geoffmurray@primus.com.au>
To: filmscanners@halftone.co.uk
Subject: Re: filmscanners: Scanning and memory limits in Windows
Date: Saturday, July 28, 2001 7:21 PM

Hi Dana,
            I never bother to compress TIFF's, apparently there is not
much
space saving anyway and I believe the less an image is mucked about
with the
better, even if people say that LZW compression is lossless.

Geoff


----- Original Message -----
From: "Dana Trout" <dana@troutcom.com>
To: <filmscanners@halftone.co.uk>
Sent: Sunday, July 29, 2001 5:49 AM
Subject: Re: filmscanners: Scanning and memory limits in Windows


> I find that little of the time spent is due to the disk drive, which
is
> the reason for my comment that a 7200 rpm drive, even though it is
33%
> faster than a 5400 rpm drive, will not necessarily reduce load times
by
> a like percentage.
>
> As for my times being slow, you're right: I was quoting the
performace
> of my "junker" computer which is used only for scanning -- it's a 466
> Celeron with 512MB RAM but Intel's woefully undersized L2 cache.
> However, the times you quote make me wonder if you are loading
> LZW-compressed TIFFs. If so, it is *definitely* time for me to
upgrade
> the scanner computer!
>
> Thanks for your comments,
>   --Dana
> ----------
> From: geoff murray <geoffmurray@primus.com.au>
> To: filmscanners@halftone.co.uk
> Subject: Re: filmscanners: Scanning and memory limits in Windows
> Date: Saturday, July 28, 2001 6:15 AM
>
> Hi Dana,
>             Gee your times seem very slow. I tried loading a 56mb
file
> from
> my scratch disk and it took 3.6 seconds. A 169mb file took 17
seconds.
> This
> on a Win 98SE machine with a 1Ghz Athlon and 512mb of PC133 ram and
two
> 7200rpm hard drives. Scratch partition is not on the hard drive which
> has
> PS6. 7200 rpm drives made a significant difference to overall speed.
>
> Geoff Murray
> www.geoffmurray.com
>
> ----- Original Message -----
> From: "Dana Trout" <dana@troutcom.com>
> To: <filmscanners@halftone.co.uk>
> Sent: Saturday, July 28, 2001 7:40 AM
> Subject: RE: filmscanners: Scanning and memory limits in Windows
>
>
> > A 25% faster drive won't necessarily get you 25% faster load/store
> > times. PhotoShop seems to be inordinately slow in dealing with
> > compressed TIFFs -- I got curious so I set up a cache large enough
to
> > hold the whole file (53MB). The first time I loaded it into
PhotoShop
> > it took 61 seconds (reading from the disk). I then closed the file
> and
> > reloaded it into PhotoShop (this time from the cache -- the disk
> light
> > never even blinked) and it took 55 seconds. And I'm reasonably sure
> > that a RAM cache is *much* faster than a 7200 rpm drive!
> >
> > BTW, Ed's VueScan takes less than 30 seconds to read the same file.
> >   --Dana
> > ----------
> > From: Rob Geraghty <harper@wordweb.com>
> > To: filmscanners@halftone.co.uk
> > Subject: filmscanners: RE: filmscanners: Scanning and memory limits
> in
> > Windows
> > Date: Friday, July 27, 2001 12:22 AM
> >
> > < snip >
> >
> > On the other hand I'm reasonably sure the main
> > bottleneck in my PC when dealing with large scans is the 5400RPM
IDE
> > drive.
> >  A 7200RPM drive would speed up loading and saving files by at
least
> > 25%.
> >  Two 7200rpm drives in a RAID array should be significantly better
> > still.
> >  Loading and saving files is the no.1 timewaster for me when
working
> > with
> > film scans on my PC.
> >
> > Rob
> >
> >
> > Rob Geraghty harper@wordweb.com
> > http://wordweb.com
> >
> >
> >
>




 




Copyright © Lexa Software, 1996-2009.