the speed of a Nikon Coolscan 500 ED

[Sam Carleton]

About a week ago I bought a Nikon Coolscan 5000 ED. For the most part I
am tickeled pink with the unit. I have noticed that it is MUCH slower
then I expected, but then I fully realized that it could be a Digital
ICE issue. I am scanning a neg at 1800x1200 and Digital ICE, it is
taking about three minutes per image! Is this correct? Does Digital
ICE slow things down this much? Nikon does clam that the scanner can do
a full 4000 dpi in 20 seconds.

Sam

 

[Mac McDougald]

About a week ago I bought a Nikon Coolscan 5000 ED. For the most part I
am tickeled pink with the unit. I have noticed that it is MUCH slower
then I expected, but then I fully realized that it could be a Digital
ICE issue. I am scanning a neg at 1800x1200 and Digital ICE, it is
taking about three minutes per image! Is this correct? Does Digital
ICE slow things down this much? Nikon does clam that the scanner can do
a full 4000 dpi in 20 seconds.

Sam

Probably the ICE is indeed responsible for most of that extra time.
It sure slows down my old Nikon 2000.
Note that Nikon says "time to complete preview or scan when no options
selected"

Easy to test, just do same scan without ICE on, eh?

Mac

 

[degrub]

Short answer, yes it will. However, the scan time may also be slowed
down by forcing it to interpolate to a given resolution and that is
further complicated by ICE ( i recall reading that ICE used some
arbitrary ppi, perhaps 1000, but i won't swear on it). Try this and see
if you notice a difference. Turn off all of the ICE options and
multisampling, etc. Scan at 4000ppi, 2000 ppi,1200ppi, and 1000ppi.
4000ppi will give you a comparison with Nikons number. The CS5000 has a
double row of ccd elements versus the single on my CS4000. Nikon did
this to speed up the scan rate. i suspect the 2000ppi and and the
1200ppi times will be similar, but it will depend on where Nikon made
the breaks for downsampling. Depending on how the times work out you may
be better off downsampling in Photoshop. The image might look slightly
better as well since Photoshop is reputed to have better algorithms. i
have no idea what Nikon used.

Frank

 

[Roger Halstead]

About a week ago I bought a Nikon Coolscan 5000 ED. For the most part I
am tickeled pink with the unit. I have noticed that it is MUCH slower
then I expected, but then I fully realized that it could be a Digital
ICE issue. I am scanning a neg at 1800x1200 and Digital ICE, it is

Putting that into normal figures, I take it you are scanning at 1200
dpi? I'm also assuming you are using NikonScan. ViewScan takes
considerably longer for me. I like ViewScan, but can't seem to get it
to find the image boundaries when doing batch scanning.

taking about three minutes per image! Is this correct? Does Digital
ICE slow things down this much? Nikon does clam that the scanner can do
a full 4000 dpi in 20 seconds.

OK... I'm going to be some what contrary to what others have said.
Digital ICE should NOT slow it down that much. I would expect it to
double the scan time from 20 to 40 seconds as it adds a second scan.

OTOH there are many items that will influence time.

I am past 10,000 slides and negatives.
Right now I'm scanning negatives at 4000 dpi and running digital ice
in the normal mode. I'm saving them as TIFFs.

It took 2 minutes and 40 seconds to do 4 images, or 40 seconds per
image. I'm not sure if Digital ice does any interpolation or not, but
that would be easy enough to prove. Just scan an image with digital
at 4000 dpi and 8 bit depth with all options off. It should be 20
seconds or close to it. Mine is right on 20 seconds. With digital
ice the same scan is 40 seconds, or twice as long which makes sense as
it takes two passes, one for the IR and one for the visual.

Now scan the same image at say 2000 dpi, and then again at 1200, or
1500 dpi and measure the time. It'd be interesting to see how they
differ.

If you have ANY other options turned on and particularly "post
processing with DEE" it will add dramatically to the scan time.

Turning on the post processing to remove grain, or enhance the shadows
will take mine up to about 3 minutes per image.

This is really noticeable when using the SF210 slide feeder as it will
take several hours for 50 slides with "the works turned on".

As a suggestion: if scanning at the lower resolution ends up costing
you a lot of time, I'd scan at the higher resolution and then resize
using a batch process in Photoshop, Photoshop Elements, PaintShop Pro,
or what ever program you use. Most make some provision for batch
processing to resize, change file type, and rename.

Although the individual session may use up a bit of HD space you
should have more than enough room to run any single session at high
resolution and then resize.

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

 

[W. W. Schwolgin]

About a week ago I bought a Nikon Coolscan 5000 ED. For the most part I
am tickeled pink with the unit. I have noticed that it is MUCH slower
then I expected, but then I fully realized that it could be a Digital
ICE issue. I am scanning a neg at 1800x1200 and Digital ICE, it is
taking about three minutes per image! Is this correct? Does Digital
ICE slow things down this much? Nikon does clam that the scanner can do
a full 4000 dpi in 20 seconds.

Sam

I can think of an number of bottlenecks that could be responsible for
the long scanning time:
- the CPU: is your system cpu-bound? Have a look at the taskmanager
during the scan. ICE is a hard-/software-feature that takes many
cpu-cycles.
- the interface: does your system has an usb1.1 or usb2.0 interface.
An usb1.1-interface slows the scanner down.
- Since the scanner cannot vary the brightness of the lamp, it simple
increases the exposure time for dark slides/negatives. This may
also result in longer scanning time.

The claimed 20 second is just the minimum time the scannerhead needs
to move from one side of a slide to the other. No transfer time for
the data to the PC, because this time depends on the PC and the
interface. No ICE, GEM or ROC because this functions need cpu-cycles.
No autofocus, because the autofocus procedure needs time. Therefor in
an optimal situation the 20 seconds might be ok, but in real life ...

Winfried

 

[Ian]

About a week ago I bought a Nikon Coolscan 5000 ED. For the most part I
am tickeled pink with the unit. I have noticed that it is MUCH slower
then I expected, but then I fully realized that it could be a Digital
ICE issue. I am scanning a neg at 1800x1200 and Digital ICE, it is
taking about three minutes per image! Is this correct? Does Digital
ICE slow things down this much? Nikon does clam that the scanner can do
a full 4000 dpi in 20 seconds.

Sam

Times for various processing combinations are quoted in the
manual, page 68 in mine. Just ICE at 4000dpi says 46 sec on
a fast computer with 1G RAM (excludes preview and autofocus).

Regards
Ian

 

[Roger Halstead]

Times for various processing combinations are quoted in the
manual, page 68 in mine. Just ICE at 4000dpi says 46 sec on
a fast computer with 1G RAM (excludes preview and autofocus).

Excluding preview (running batch mode), but including autofocus and
ICE I get an average of 40 seconds per slide.

However, I'm running a 2.8 gig Athlon XP Plus with I Gig of DDR RAM
with a buss speed of 333 Mhz.

OTOH, I'm also running, Agent, Outlook Express, PhotShop Elements,
Zone Alarm Pro, and Norton AntiVirus Autoprotect at the same time.

One thing to check for is "Page file swapping" IF the HD is running
continually throughout the operation the likely hood is you need more
RAM. These images take a horrendous amount of RAM AND a lot of
computing HP. At 4000 dpi at 8 bit the image takes about 64 megs and
the operation could at times easily take 2 or 3 times as much.

As Ian mentioned you can be CPU bound, memory bound, or I/O bound.
With 512 Megs my system was Sloooooowwww.... Increasing to one Gig
brought the speed right up to what Nikon claims.

Prior to the memory increase I could not even run the other apps while
NikonScan was running.

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

 

[Sam Carleton]

As Ian mentioned you can be CPU bound, memory bound, or I/O bound.
With 512 Megs my system was Sloooooowwww.... Increasing to one Gig
brought the speed right up to what Nikon claims.

Prior to the memory increase I could not even run the other apps while
NikonScan was running.

That is scarry! I thought I was doing well having 768 Meg of ram, I
guess not! I have a 2.8GHz Pentium with 768 Megs of 333 MHz ram.

Excluding preview (running batch mode), but including autofocus and
ICE I get an average of 40 seconds per slide.

However, I'm running a 2.8 gig Athlon XP Plus with I Gig of DDR RAM
with a buss speed of 333 Mhz.

OTOH, I'm also running, Agent, Outlook Express, PhotShop Elements,
Zone Alarm Pro, and Norton AntiVirus Autoprotect at the same time.

One thing to check for is "Page file swapping" IF the HD is running
continually throughout the operation the likely hood is you need more
RAM.

I will most diffently look into more ram, but something I am doing a bit
different the most, I think, is storing all the images on a network
across a 100 MBit conneciton, that might be a bottleneck, too.

Sam

 

[Sam Carleton]

Ok, here are the specs on my machine:

Dell PowerEdge 400SC w/ 2.8GHz CPU w/ Hyperthreading turned on
768Megs physical memory
40G HD

I am doing a batch scan @ 4000 dpi, Digal ICE is normal, Digital ROC is
at 1 and Digital GEM is at 3.

During the first scan which take around four or five minutes, the CPU is
running around 50% and memory is as high as 300 Megs, for the second
scan, the memory climbs as high as 630 megs, on the fifth image, memory
is sitting right around 656 Megs.

It looks to me like memory usage goes up as the batch scan progresses.
Now if you all are right, with Digital ICE turned on, I should be around
40 seconds to a minute for the first few images, until I surpass my
physical memory. Here is the log generated by the batch scan:

---------------------------------------------------------------------------
Start: 5/16/2004 8:19 PM

Image 1 Started 5/16/2004 8:19 PM.
Scan Completed.
Saved as Frame19.tif.

Image 2 Started 5/16/2004 8:25 PM.
Scan Completed.
Saved as Frame20.tif.

Image 3 Started 5/16/2004 8:30 PM.
Scan Completed.
Saved as Frame21.tif.

Image 4 Started 5/16/2004 8:35 PM.
Scan Completed.
Saved as Frame22.tif.

Image 5 Started 5/16/2004 8:40 PM.
Scan Completed.
Saved as Frame23.tif.

Batch scan completed: 5/16/2004 8:46 PM
---------------------------------------------------------------------------

I just did a scan and turned off all features under the Digital ICE4
Advanced settings and it took 2 minutes and 25 seconds for one scan at
4000 dpi. Mind you I do have Curves, Color Balance, Unsharp Mask, and
LCH Editor all checked.

When I first posted, the scanner was hooked to the USB hub in my 22" NEC
monitor, but all of the times I listed here are with the scanner hooked
directly to the Dell 400SC.

I have a really hard time believing that adding more memory will help
considering I never used all the physical memory of my system.

Sam

 

[Bart van der Wolf]

SNIP

I have a really hard time believing that adding more memory will help
considering I never used all the physical memory of my system.

The scanner+interface are most likely the bottleneck. You will know if the
scanner starts to intermittently pause while scanning.

ICE and GEM and ROC are processor dependent operations, but on (very!) large
images the amount of memory may help to avoid some memory swapping to disk.

Bart

 

[Don]

The scanner+interface are most likely the bottleneck. You will know if the
scanner starts to intermittently pause while scanning.

Not quite correct. If you turn ICE on the scanner itself will stop and
think even though the bus is free. So just listening to the scanner
stepper motor is not a definitive indication of bus load.

ICE and GEM and ROC are processor dependent operations, but on (very!) large
images the amount of memory may help to avoid some memory swapping to disk.

I don't know about GEM and ROC but as far as ICE is concerned that
happens within the scanner itself and has nothing to do with the PC
processor or memory.

Don.

 

[Bart van der Wolf]

Not quite correct. If you turn ICE on the scanner itself will stop and
think even though the bus is free. So just listening to the scanner
stepper motor is not a definitive indication of bus load.

The hardware part of ICE only adds a 4th channel to RGB. That means it must
send 33% more data to the computer.

disk.

I don't know about GEM and ROC but as far as ICE is concerned that
happens within the scanner itself and has nothing to do with the PC
processor or memory.

No, only the addition of an IR channel exposure channel is done in the
scanner. The processing (mask creation and interpolation) for filling in
absent image detail is all done in the computer itself.

Some scanner drivers try to do the postprocessing while the data comes in
through the cable, others wait for the scan to complete and then process
everything. It may claim so much processing power (check if the processor
load is 100%) that interfaces slow down. But if the processor load remains
below 100%, it's the scanner (with a given exposure time per pixel that can
vary between images) and/or the interface.

Bart

 

[Don]

The hardware part of ICE only adds a 4th channel to RGB. That means it must
send 33% more data to the computer.

ICE processing takes place within the scanner itself. It is this
processing which can cause pauses in stepper motor movement, not the
transfer. See below for more detail, specifically the duration of ICE
and non-ICE scans. This is not proportional to the amount of IR data.

No, only the addition of an IR channel exposure channel is done in the
scanner. The processing (mask creation and interpolation) for filling in
absent image detail is all done in the computer itself.

Kennedy was of the same opinion (that stepper motor activity is an
indication of bus load) until I ran a few tests. Here's my original
reply:

-- cut start ---

The critical test is to listen to the scanner motor while making a scan.
If the unit is producing data faster than the USB1.1 bus can transfer it
to the computer then the scanner head will stop moving while the bus
catches up.

I don't think you can rely on this method. What if the scanner itself
can't keep up and "stops and thinks" before sending data? For example:

When I run a scan without ICE the stepper motor purrs along
uninterrupted. However, when I do turn ICE on, there are numerous and
long stops.

Even allowing for the scanner to send the IR channel data (which I
don't think is the case) the time it takes to complete an ICE scan
(about 3 mins) is not commensurate with non-ICE scan time (about 1
min). That's an increase of 300% for, nominally, 33% more data.
Therefore, it's the scanner itself that "stops and thinks" before
sending data or, the scanner software on the PC side tells it to cease
until the software digests the data it has already received.

Either way, even though in some cases listening to the stepper motor
may indicate a transfer bottleneck, I don't think it's a reliable
method because of many other variables.

--- cut end ---

Don.

 

[Bart van der Wolf]

SNIP

I don't think you can rely on this method. What if the scanner itself
can't keep up and "stops and thinks" before sending data? For example:

When I run a scan without ICE the stepper motor purrs along
uninterrupted. However, when I do turn ICE on, there are numerous and
long stops.

Have you checked the processor load?

Even allowing for the scanner to send the IR channel data (which I
don't think is the case) the time it takes to complete an ICE scan
(about 3 mins) is not commensurate with non-ICE scan time (about 1
min). That's an increase of 300% for, nominally, 33% more data.
Therefore, it's the scanner itself that "stops and thinks" before
sending data or, the scanner software on the PC side tells it to cease
until the software digests the data it has already received.

The processor load will tell. Try it once without ICE, and once with.

Either way, even though in some cases listening to the stepper motor
may indicate a transfer bottleneck, I don't think it's a reliable
method because of many other variables.

Scanners are pretty dumb devices, that's why we need elaborate drivers...

Bart

 

[Roger Halstead]

Ok, here are the specs on my machine:

Dell PowerEdge 400SC w/ 2.8GHz CPU w/ Hyperthreading turned on
768Megs physical memory
40G HD

As a comparison:

Home brew Athlon 2.8 Gig, 1 Gig RAM @ 333 MHz and doing the R/W to a
200 Gig HD.

Starting with the first scan and all scans the CPU when processing
preview, or scan is 100%. RAM with the first image is 488 Megs and
goes to a high on the 4th image with digital ICE, ROC, GEM, and DEE
reached 682 megs. I can save across the network which adds some time
due to the overhead on an already CPU bound system.

Again, the system was CPU bound during image preview, scan, and
processing such as Preprocessing with ICE and post processing using
GEM, DEE, and ROC.

Still, I get 20 seconds for a 4000 dpi image and 40 seconds average on
4 images with ICE. Adding ROC, GEM, and DEE easily triples that to 2
minutes.

I see no real difference between using ICE and not using it for the
exception of time, which with a CPU bound system AND the second
physical scan makes sense.

ROC, GEM, and DEE are all CPU hogs, but they work well.

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

 

[Gary L Hunt]

The hardware part of ICE only adds a 4th channel to RGB. That means it must
send 33% more data to the computer.


No, only the addition of an IR channel exposure channel is done in the
scanner. The processing (mask creation and interpolation) for filling in
absent image detail is all done in the computer itself.

Some scanner drivers try to do the postprocessing while the data comes in
through the cable, others wait for the scan to complete and then process
everything. It may claim so much processing power (check if the processor
load is 100%) that interfaces slow down. But if the processor load remains
below 100%, it's the scanner (with a given exposure time per pixel that can
vary between images) and/or the interface.

Bart

Okay, here's a data point; somebody tell me what it means. I've been
scanning the same slide over and over with a stopwatch, and I do not
understand what's going on inside the scanner. I'm doing 4000 dpi scans
(to JPGs) with and without ICE [using NikonScan 4.01], with pretty much
everything else turned off to avoid confusing the timing (including
autofocus and auto-exposure.)

With ICE off, the total pass takes about 30 seconds of scanner run time,
plus 3 to 4 seconds to do the JPG compression and write the file,
regardless of whether it's the first or subsequent scans without taking
the slide out.

With ICE on, the first scan after the slide is inserted takes 65 seconds,
of which the first 15 is a "pre-scan" of some kind. Scanning the slide
again without taking it out of the scanner gives 50 seconds, with no
"pre-scan". Of the 50 seconds, 36 seconds is the actual scanner run time,
with another 12 seconds for post-processing of some sort and two seconds
for saving the file.

So--ICE adds maybe 6 seconds to the actual scan pass. Is this due to the
IR channel data being acquired? If so, what the heck is that 15 second
"pre-scan" that only gets done the first time the slide is scanned?

And by the way, does anybody else's 5000ED just sort of "wander away" for a
minute or so every now and then? Sometimes the scanner makes noise, sometimes
it doesn't, but NikonScan appears to freeze while it happens. Then it
comes back and continues as though nothing has happened. I was using this
same version of NikonScan with my 4000ED until two days ago, and this never,
ever happened.

Gary Hunt


P.S. I don't think any of this is due to interface or CPU limitations. The
scanner never slows down with ICE on or off. The 4000 definitely "stutters"
a bit using ICE on the same system: 3.0 GHz P4 hyperthreaded, 1.5 GB of
dual-channel DDRAM. CPU utilization is ~50-52% during the scan with or
without ICE. (That's about as high as it ever gets on most single programs,
except Photoshop, which seems to make much better use of hyperthreading.)

 

[Don]

Have you checked the processor load?

We're digressing a bit...

The subject I commented on was that stepper motor activity is an
indication of bus load. That's just not true. It's an interesting
lateral thought but there are far too many unknowns to make scanner's
stepper motor activity a reliable monitor of bus activity.

So, even if the delay were caused by the processor (which I don't
think is the case) that alone makes listening to the scanner's stepper
motor as indication of bus activity meaningless.

Don.

 

[Bart van der Wolf]

SNIP

So--ICE adds maybe 6 seconds to the actual scan pass. Is this
due to the IR channel data being acquired?

What's the processor load % ?

If so, what the heck is that 15 second "pre-scan" that only gets
done the first time the slide is scanned?
Autofocus?

SNIP
P.S. I don't think any of this is due to interface or CPU
limitations. The scanner never slows down with ICE on or off.

Maybe it always scans RGB+IR but only uses the IR channel when ICE is turned
on?

The 4000 definitely "stutters" a bit using ICE on the same
system: 3.0 GHz P4 hyperthreaded, 1.5 GB of dual-channel
DDRAM. CPU utilization is ~50-52% during the scan with or
without ICE.

Which is pretty high in my experience. Although I use completely different
hardware (so comparisons are hardly valid) a 20-35% processor load while
scanning on an 1.8GHz machine with Firewire, seems the top. However,
switching on ICE creates a constant 100% processor load while scanning, but
that may be due to way the Minolta software is optimized (or the lack
thereof).

Bart

 

[Bart van der Wolf]

SNIP

The subject I commented on was that stepper motor
activity is an indication of bus load. That's just not true.

How do you know so certain?

It's an interesting lateral thought but there are far too many
unknowns to make scanner's stepper motor activity a reliable
monitor of bus activity.

So, even if the delay were caused by the processor (which I
don't think is the case) that alone makes listening to the scanner's
stepper motor as indication of bus activity meaningless.

You might underestimate the reverse engineering that was undertaken to
understand the data stream coming from the scanner, notably by Ed Hamrick.
By studying the data, it can be concluded that non-ICE processed RGB data is
coming through the cable and a single IR channel can accompany the RGB data.
The RGB data can be raw for some scanners, and it can be Gamma processed for
others (sometimes triggered by sending either a Linear LUT or a Gamma
adjusted one).

Exposure time (inappropriately called gain) can be increased, which has an
audible effect (and it can be timed) because of the increased exposure time
per pixel(line). All very predictable and repeatable. It doesn't change with
image content either, also indicating no internal processing on the many
megapixels (even the smallest processing difference multiplied by the number
of pixels would be noticeable). No lateral thinking, just deduction.

If we assume, with a probability bordering on absolute certainty, that the
scanner does no other processing than turning voltages into bit-patterns and
sending them to the interface, that leaves us very little else than the
interface, and the computer as potential causes.
When the interface buffer cannot be unloaded fast enough, the scanner will
have to stop filling the buffer. That can be caused by a slow interface, or
a slow computer. Both can be monitored.

If neither the computer, nor the interface show increased activity
approaching or in excess of their processing capabilities, but the scanner
(intermittently) slows down, then the scanner is doing something else than
recording and trying to send. It doesn't seem too difficult, or am I
overlooking something?

Bart

 

[Jean]

|
....snip
|
| Exposure time (inappropriately called gain) can be increased, which has
an
| audible effect (and it can be timed) because of the increased exposure
time
| per pixel(line). All very predictable and repeatable. It doesn't change
with
| image content either, also indicating no internal processing on the many
| megapixels (even the smallest processing difference multiplied by the
number
| of pixels would be noticeable). No lateral thinking, just deduction.
|
....snip
|
|
| Bart
|

I recently contacted Nikon Tech (via email) about "Analog Gain" and asked
if the scanner varied the exposure time and/or the light intensity. They
responded back that the Nikon LS-40 scanner varies the intensity of the
LED's. I tried to verify this with my scanner by timing scans with no gain
and with max gain; the scan times were the same. I would guess that the
newer Nikon scanners behave similarly.


Jean