Just turn on the Task Manager if you are running XP or 2000.
It clearly shows the CPU time. With ICE turned on there are two scans
and on my machine it takes twice as long.
Also, The CPU is running 100%! That in and by itself eliminates all
other points as bottlenecks on this particular system which at 100% is
"CPU bound". This means the scanner and USB buss are getting the data
to the processor as fast, or faster than it can handle.
It is also safe to assume that running a 2.8 GHz processor equivalent
that slower machines are going to be CPU bound as well "Unless they
have insufficient memory and/or a slower data transfer (USB-1).
Unless you are running a slow machine a scan and ICE "with no other
functions turned on". should take *about* 40 seconds, or twice as
long as a scan only. "In general" I have not found it necessary to
even turn on the post processing functions. They work well for faded,
off color, and overly dense, or thin slides or negatives, but have not
otherwise been necessary..
Turning on "post processing" can *easily* take the time per image from
40 seconds to 3 minutes. Don't even turn on "post processing". I've
found that it takes extra time even if ROC DEE and GEM are set to 0.
And at the time I did point out that the assumption you make is somewhat
unlikely given the alternative issues, however....
I think some important information is missing here.
I may be making some improper conclusions, but in my system I do not
see this sort of numbers.
It "sounds to me" like there is a good deal of page file swapping
going on. At least that is the way mine acted prior to adding more
memory.
I can now run multiple applications, but it is very easy even with one
meg of RAM to end up with page file swapping when using one or several
of those apps when the scanner is running. Once the page file
swapping starts, you have to wait until the system has cleaned up all
the files involved or it will just continue swapping even if you are
not using the other apps. This sometimes can take 5 to 10 minutes on
my system.
...what is this super intelligent, scanner that "thinks", let alone
knows enough to stop other tasks before it does so? It's clearly male,
since it can only do one thing at a time and thinking takes priority -
good job they don't breed! ;-)
The scanner does very little thinking. It only does what the soft
ware tells it to do with a couple of simple exceptions. Although... I
do have to admit that mine sometimes forgets what it was doing which
usually hangs the whole system. Actually I think it and the software
forget to talk to each other when that happens.
Whilst I agree that the listening test is not a definitive test of bus
saturation, it is a test that something has become a bottleneck in the
system and, assuming adequate processor power and memory, the bus is the
Considering the processor power I have available and my system is CPU
bound I don't think it is a safe assumption. The data still gets
transferred even if the CPU can't keep up. You can see that in the
memory use.
obvious candidate. In the case of USB1.1, it is a pretty poor processor
that cannot keep pace with the bus.
It depends on what the processor is doing with the data. For simple
transfers I'd agree. For linear processing as well even though the
processor has some overhead involved with the data transfer, but if it
were doing something like Fourier transforms (which I certainly hope
it's not) then a simple serial buss would have no trouble keeping up.
In my case I'm feeding the CPU bound processor via USB-2.
You are assuming that the bottleneck is the processing ability of the
scanner, a rather dumb piece of hardware which operates automatically,
consistently and synchronously, albeit under software control. It is
The scanner is rated at 20 seconds for a straight scan and a bit over
40 seconds for a scan with ICE. I would think that anything beyond
that would have to lie elsewhere such as processor, external data
transfer buss, Front Side Buss (FSB), Memory (quantity and speed
including CAS setting)
much more likely that the saturation that your test highlighted is
actually saturation of the computer CPU which functions sequentially
rather than synchronously.
Yup!
Consequently the increased processing load
of ICE reduces the ability of the CPU to process the data and thus clear
Which is not a problem except for insufficient memory available.
It appears to add very little in the way of processing as the scan
takes 20 seconds as does the IR pre scan and the overall processing
takes about 40 seconds.
the USB input buffer, rather than the scanner stopping to do something
it is incapable of.
But ICE should not add that much of a load. (In mine it adds 20
seconds) The scan takes the same time as a regular scan, but the data
is simpler. It is my understanding that it is a complete monochrome
scan in the IR region.
"My guess" is that the software sets the background to 0 and then
figures the value of the imperfections based on that. During the
processing of the scanned image the two are basically fitted together
and the data from the IR scan is algebraically added to the final scan
which in effect cancels out the data from any defects that show up in
the IR scan. This too is done with the CPU and not in the scanner.
BTW, I just ran all the analog gains up to max (2) and re scanned 4
negatives. The time including ICE was just under 1 minute each.
Adding the gain added just under 20 seconds average to each scan.
Thing is I can't tell if that time is in the processing, or from the
scanner. I haven't timed how long the stepper motor has been
running.I could turn on "post processing" and do it again, but I'd guarantee
the times will be 2 to 3 minutes with the analog gains set to normal
(0) This is with no page file swapping. With half a gig of RAM it
seems to take forever and the drive light is on constantly.
Next you'll be telling us that your washing machine solved Einstein's
Grand Theory of Unification before entering its high speed spin cycle.
;-)
I'll take one of those to replace my computer. Then it can do the
work while it's doing the wash. <
)
Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com
)