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



800 CDs.  Man I nearly fainted - need some chocolate, quick...

My music collection is around that size, and it makes me stutter just
thinking about the improbability of enjoying it properly.

I use JPEG quality 10 to "archive" my scans - my 36MB 8-bit, full res scans
drop to a cosy 2 to 5MB - the occasional 6MB file doesn't upset me too much.

I guess I'm just not anal enough.  I hope this doesn't get me barred from
the list...

Jawed

> -----Original Message-----
> From: owner-filmscanners@halftone.co.uk
> [mailto:owner-filmscanners@halftone.co.uk]On Behalf Of Dana Trout
> Sent: 29 July 2001 23:29
> To: filmscanners@halftone.co.uk
> Subject: 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




 




Copyright © Lexa Software, 1996-2009.