VueScan or NikonScan?

[Philip Homburg]

Because the "great unwashed" that say that, don't know what they're
doing:

TURN OFF AUTO-EXPOSURE!!!

If there is clipping, that means the slide (I'm currently busy with
slides...) is probably overexposed in which case adjust Analog Gain.

NikonScan's handling of negatives (in negative mode) is simply (intentionally)
buggy.

If you scan negatives as slides, NS works as expected, but gets the
frame boundaries wrong. You can't win.

 

[Philip Homburg]

Unfortunately, it doesn't do this very well in many (but certainly not
all) cases. Vuescan and Silverfast let the user choose the range even
to the point
of including data far beyond the range of the negative being scanned
if the user so chooses. NS makes its internal decision and the user is
left to live with it for better or for worse.

You can scan a negative as slide, and invert the color channels manually.
It is much more work, but it provides very good results.

 

[Mike Engles]

Because the "great unwashed" that say that, don't know what they're
doing:

TURN OFF AUTO-EXPOSURE!!!

If there is clipping, that means the slide (I'm currently busy with
slides...) is probably overexposed in which case adjust Analog Gain.


Of course they ignore the auto-exposure setting when you tell them to
ignore it. (You may tell them to ignore it indirectly by saying, for
example, "scan as raw".)


Not to speak for Kennedy, because he can and does that very eloquently
himself, but as far as Auto Exposure is concerned page 39 in
"ns3rmena1.pdf" tells you how to turn it off. If you prefer pictures,
there are some on pages 126 and 128...

Don.

Hello

I have never seen clipping unless one uses the auto button and then it
will use the one set in the prefs.
The auto preexposure does not clip. It leaves a margin.
You really do need the auto pre exposure, so that Nikonscan can set the
margin. It is also needed to get a neutral scan.

Mike Engles

 

[Kennedy McEwen]

NikonScan's handling of negatives (in negative mode) is simply (intentionally)
buggy.

You have evidence that a) it is buggy and b) that the bugs are
intentional (in which case they can scarcely be termed bugs, but that's
another debate)?

 

[Kennedy McEwen]

Analog Gain adjustment does not resolve this issue with Nikonscan.
When scanning negatives it merely lets you choose which end gets
clipped.
For example, with the snow scene I described, NS will clip the white
highlights as I described. If analog gain is adjusted to bring in the
white
point (so there is no significant highlight clipping), then the black
point gets clipped!!

As I explained in the previous post, the only clipping produced in the
test I did earlier today to try to find this effect was exactly the same
as Vuescan when the exposure was adjusted accordingly to bring either
the whites or blacks close to the mid range.

 

[Dave]

I just noticed the uncompressed TIF files created by VueScan are about
6 Megs smaller than the TIF files created by NikonScan for the same
scans with equivalent settings. Do you think VueScan is capturing
less information?

 

[Kennedy McEwen]

I just noticed the uncompressed TIF files created by VueScan are about
6 Megs smaller than the TIF files created by NikonScan for the same
scans with equivalent settings. Do you think VueScan is capturing
less information?

I doubt it.

MikonScan stores two files in the TIFF image though: the full image and
a thumbnail. I am surprised that the thumbnail is taking 6Mb though, as
it is usually only a couple of hundred kilobytes.

 

[Philip Homburg]

You have evidence that a) it is buggy and b) that the bugs are
intentional (in which case they can scarcely be termed bugs, but that's
another debate)?

If you scan a negative (as negative), NikonScan tries very hard to clip
the shadows.

For slides, you can set the auto-exposure parameters, for negatives that
doesn't work. And (at least in NS3) there is no manual exposure.

This problem is not mentioned in the manual, so I will call it a bug
(might be a documentation bug). If they document it, it will become a
design misfeature.

 

[Kennedy McEwen]

If you scan a negative (as negative), NikonScan tries very hard to clip
the shadows.

Nope - I have seen numerous reports to the effect that shadows are
clipped and others, such as those in this thread, claiming that the
highlights are clipped.

Just for reference, the negative I happen to be scanning at the moment,
Fuji Reala, has the following statistics in Photoshop:

Mean: 117.45
St.Dev: 50.34
Median: 112
Min: 34
Max: 246

This scan was without any levels adjustment at all, used ICE(Normal) and
GEM(2), and deliberately included the black border, so that I could
check for any of the shadow clipping you claim. As the numbers above
prove, there is certainly no shadow clipping, no highlight clipping and,
as would be normal for a negative scan, would actually benefit from a
little contrast enhancement using the Curves control, particularly to
pull the shadows down to black. NikonScan *does* offset the black level
on colour negative scan, a consequence of the orange mask affecting the
raw data, and this requires to be adjusted using the curves tool but,
since this is implemented on the full depth data before reduction to
8-bits, the effect is negligible.

For slides, you can set the auto-exposure parameters, for negatives that
doesn't work. And (at least in NS3) there is no manual exposure.

It seems to work here with my LS-4000 OK. Depending on whether it is on
or off, the resulting scan has a different mean level, as per the
following data obtained with autoexposure switched off:

Mean: 112.21
St.Dev: 46.02
Median: 107
Min: 32
Max: 239

Not very different, but different enough to demonstrate that the
autoexposure is functioning and can be switched on or off. In this scan
without autoexposure, shadow clipping *has* occurred because the minimum
level achieved on a non-curve adjusted colour negative scan is 32.
Analogue gain functions as a manual exposure as demonstrated on my
previous post and by a further scan with the analogue gain at -1EV:

Mean: 67.27
St.Dev: 32.38
Median: 61
Min: 32
Max: 170

I could post data with analogue gain at +1EV to demonstrate manual
exposure in the opposite direction, but I am sure you get the picture. I
have yet to see the effect to which you continually refer.

Incidentally, when scanned normally, with autoscan on and curves
adjustment set properly as per my default setting for Fuji Real negative
film, the image has the following statistics:

Mean: 98.65
St.Dev: 56.06
Median: 94
Min: 0
Max: 248

and if I crop out the black border it becomes:

Mean: 102.24
St.Dev: 53.86
Median: 95
Min: 2
Max: 248

Clearly nothing in the actual image is as dark as the unexposed film
between the frames - so Nikonscan certainly *isn't* clipping the shadows
as you claim.

Now, I don't know what you are doing with your negative scanning which
makes it so different from mine, but it certainly isn't the case that
the problem that you cite as an intentional bug is common to all
operators.

This problem is not mentioned in the manual, so I will call it a bug
(might be a documentation bug). If they document it, it will become a
design misfeature.

Since it has demonstrably not manifested itself here then I would call
it an operator bug. If they document why you cause it then it will
become a FAQ.

Even allowing for the nomenclature, you have *still* failed to provide
any evidence that this bug is intentional.

 

[Philip Homburg]

Just for reference, the negative I happen to be scanning at the moment,
Fuji Reala, has the following statistics in Photoshop:

Mean: 117.45
St.Dev: 50.34
Median: 112
Min: 34
Max: 246

This scan was without any levels adjustment at all, used ICE(Normal) and
GEM(2), and deliberately included the black border, so that I could
check for any of the shadow clipping you claim. As the numbers above
prove, there is certainly no shadow clipping, no highlight clipping and,
as would be normal for a negative scan, would actually benefit from a
little contrast enhancement using the Curves control, particularly to
pull the shadows down to black. NikonScan *does* offset the black level
on colour negative scan, a consequence of the orange mask affecting the
raw data, and this requires to be adjusted using the curves tool but,
since this is implemented on the full depth data before reduction to
8-bits, the effect is negligible.

I'll try to see what I have to do to trigger this problem. But I see
two differences with my normal work flow: I don't use GEM and I scan in
16-bit/ch mode.

 

[Roger Halstead]

NikonScan's handling of negatives (in negative mode) is simply (intentionally)
buggy.

If you scan negatives as slides, NS works as expected, but gets the
frame boundaries wrong. You can't win.

I just haven't seen this as a great problem.
I've been scanning slides and negatives. Scanning negatives as
negatives has worked just fine.

I do come across the occasional negative where NS gets the boundary
wrong, but so does ViewScan. There are apparently negatives and
positive strips that have images that confuse the algorithms. (or the
scanner) I don't know how it detects the frame separations.

Yes, I do have the occasional problem with under exposed slides and
more often with severely over exposed, but all in all both app work
quite well. OTOH it does get frustrating when coming across a batch
where neither can find the frame edges.

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

 

[Don]

No matter what I do with
NikonScan, my face is always purple (In the photo, in the photo!)

ROTFL! Very good!

and
it wasn't when the photo was taken.

Although... After many unsuccessful tries to correct it, I bet your
real life face does start to resemble the face in the picture... ;o)

So, in the end, NikonScan "works" by making both the same!

Sorry, not very helpful, but I couldn't resist...

Don.

 

[Don]

I doubt it.

MikonScan stores two files in the TIFF image though: the full image and
a thumbnail. I am surprised that the thumbnail is taking 6Mb though, as
it is usually only a couple of hundred kilobytes.

An obvious thing but worth a try: It may be the difference in
cropping!

Dave, are you sure both crops are the same size?

Don.

 

[Mike Engles]

Just for reference, the negative I happen to be scanning at the moment,
Fuji Reala, has the following statistics in Photoshop:

Mean: 117.45
St.Dev: 50.34
Median: 112
Min: 34
Max: 246

This scan was without any levels adjustment at all, used ICE(Normal) and
GEM(2), and deliberately included the black border, so that I could
check for any of the shadow clipping you claim. As the numbers above
prove, there is certainly no shadow clipping, no highlight clipping and,
as would be normal for a negative scan, would actually benefit from a
little contrast enhancement using the Curves control, particularly to
pull the shadows down to black. NikonScan *does* offset the black level
on colour negative scan, a consequence of the orange mask affecting the
raw data, and this requires to be adjusted using the curves tool but,
since this is implemented on the full depth data before reduction to
8-bits, the effect is negligible.

I'll try to see what I have to do to trigger this problem. But I see
two differences with my normal work flow: I don't use GEM and I scan in
16-bit/ch mode.

--
The Electronic Monk was a labor-saving device, like a dishwasher or a video
recorder. [...] Video recorders watched tedious television for you, thus saving
you the bother of looking at it yourself; Electronic Monks believed things for
you, [...] -- Douglas Adams in Dirk Gently's Holistic Detective Agency

Hello

Is there a difference between preview and scan? I have found that Nikon
scan 4.01 has a problem with the two not being the same with 16 bit
output. This has been fixed in 4.02. It was only a problem when doing
manual clipping in Nikonscan.

Mike Engles

 

[PeteCresswell]

"Seemed" being the operative term! Perhaps you should examine those

"Windows guidelines" before you repeat that statement! Vuescan
incorporates several significant departures from Windows convention and
whilst I wouldn't say that NikonScan follows that model, it is at least
as conventional as the software you chose to compare it with.

We're looking at two different versions of NikonScan then.

Can't remember what release I was trying to use - but it was a couple
of years ago and Nikon must've gotten their act together since then.
The release I was looking at is tied (IMHO..) with Sony's SonicStage
for worst software offering from a major corporation.

 

[Kennedy McEwen]

I'll try to see what I have to do to trigger this problem. But I see
two differences with my normal work flow: I don't use GEM and I scan in
16-bit/ch mode.

I should have mentioned that I was scanning at 14-bits - the LS-4000
only has a 14-bit ADC, however the results are just the same when
scanning in 8-bit mode. I should also mention that I recently upgraded
to NikonScan4.02 however, prior to that I had been using NikonScan3.1.2
having found that NikonScan4 and 4.01 resulted in much slower scanning
with the LS-4000. I reported this problem to Nikon some time ago, and
they appear to have fixed it in 4.02, which is now slightly faster than
3.1.2, scanning and processing a frame in 3min 15sec which otherwise
took 3min 45 sec.

I mentioned 8-bits in the text above because that is the mode that would
be most noticeable apparently throwing away 12.5% of the dynamic range
to give a base of 32 for black level, not because that is the mode I was
using. I guess I could have been more explicit.

 

[Kennedy McEwen]

We're looking at two different versions of NikonScan then.

Can't remember what release I was trying to use - but it was a couple
of years ago and Nikon must've gotten their act together since then.
The release I was looking at is tied (IMHO..) with Sony's SonicStage
for worst software offering from a major corporation.

Having been using NikonScan since version 1.6, running under Windows
3.0, that must have been *quite* a few years ago. ;-)

Having said that, NS1.6 - and indeed the entire approach to scanning
where the levels curve was sent to the scanner which contained an ALU
that reduced the ADC data to 8-bits before transfer back to the computer
- involved a lot more effort to get a decent scan than any of the more
recent versions.

 

[Philip Homburg]

I should have mentioned that I was scanning at 14-bits - the LS-4000
only has a 14-bit ADC, however the results are just the same when
scanning in 8-bit mode. I should also mention that I recently upgraded
to NikonScan4.02 however, prior to that I had been using NikonScan3.1.2
having found that NikonScan4 and 4.01 resulted in much slower scanning
with the LS-4000. I reported this problem to Nikon some time ago, and
they appear to have fixed it in 4.02, which is now slightly faster than
3.1.2, scanning and processing a frame in 3min 15sec which otherwise
took 3min 45 sec.

I tried some scans, and I can't find a negative that really show something
wrong. There is a small difference at the extremes (shadows and high
lights) but without a clear example, it is just theoretical.

I did notice that NS does weird things with the frame boundaries. I scanned
a negative as negative, and selected a crop. Switch to positive, and the
next preview after switching, the frame was completely off. Very weird.

Anyhow, in past I had some scans where NS made a mess of things. But it
could have been NS 2.x or the LS-2000. I'll try to find a frame that shows
the difference.

 

[Don]

As I explained in the previous post, the only clipping produced in the
test I did earlier today to try to find this effect was exactly the same
as Vuescan when the exposure was adjusted accordingly to bring either
the whites or blacks close to the mid range.

I have not time to test this in NikonScan, but just an idea...

Could it be that the Auto Exposure algorithm uses Luminance while you
all use composite RGB (or indeed, individual channels) to determine
clipping?

Namely, Luminance uses a formula which does *not* mix all three
channels equally like composite RGB does (if memory serves Luminance
is, roughly: 10% red, 60% green and 30% blue?).

To see this in Photoshop:
Alt I/H brings up a histogram with Luminance.
Levels brings up a histogram with composite RGB.
While Luminance is nowhere near clipping, quite often one or more
individual channels are clipped.

Don.

 

[Kennedy McEwen]

I have not time to test this in NikonScan, but just an idea...

Could it be that the Auto Exposure algorithm uses Luminance while you
all use composite RGB (or indeed, individual channels) to determine
clipping?

I think it is more along the lines of NikonScan uses some sort of
average setting for its autoexposure, with Vuescan using peak level.
Both have their application, but if I was choosing an algorithm to
determine the correct exposure of an image already recorded on a media
with less dynamic range than that I am using, I would go for a peak
level detection, as this would give most consistent results closest to
the original media. To that extent I would argue that the Vuescan
method is best, but it does not make the alternative wrong, just another
way of working that has to be learned.