Histogram puzzle...

  • Thread starter Thread starter Don
  • Start date Start date
The "Lo-Cont" settings refer to the Prescan mode of the autoexposure,
not the interpolation method used. It would appear that your Help file
is corrupted - at least it is very different from mine. :-(

Having finally got the pdf manual (from a secret hiding place at
Nikon's site) it turns out "Lo-Cont" and friends only appear when
"Negative" is selected. Working with slides I had chosen "Positive",
of course, which explains their absence. However, the help file should
know that and display appropriate messages. Yet another buglet...

I also "fixed" those histogram "gaps and spikes". I changed NikonScan
gamma to 1 and, "viola" I get a civilized histogram. Now, you did
mention this and I had already tried it before on my own that but with
no luck. What changed this time is that I turned the scanner off and
on (just like I need to when changing NCM status) and this time the
gamma change took. So, another major bug...

Of course, as you also said, once correct gamma (2.2 in my case) is
applied in PS the "gaps" reappear. However, there are no "spikes" and
the histogram is generally much more civilized in the sense that there
is no overlapping or recursive "ghosting", and the values are
stretched out in a much more even manner. I suppose PS' algorithm and
precision are superior, which doesn't surprise me, and which is why I
try to avoid any processing in the firmware if I can (limited space,
processor, etc).

Converting the image to 16-bit before applying gamma and then going
back to 8-bit appears to improve things somewhat. Anyway, this is hot
of the presses and many more tests still to do, but as the joke goes:

I'm hopelessly lost, but making good time... ;o)

Don.
 
I also looked thru the Nikon site for the manual and couldn't find it
.....how about a hint as to where it is?

Thanks,

Jean


| On Sat, 14 Feb 2004 15:31:49 +0000, Kennedy McEwen
|
| >The "Lo-Cont" settings refer to the Prescan mode of the autoexposure,
| >not the interpolation method used. It would appear that your Help file
| >is corrupted - at least it is very different from mine. :-(
|
| Having finally got the pdf manual (from a secret hiding place at
| Nikon's site) it turns out "Lo-Cont" and friends only appear when
| "Negative" is selected. Working with slides I had chosen "Positive",
| of course, which explains their absence. However, the help file should
| know that and display appropriate messages. Yet another buglet...
|
| I also "fixed" those histogram "gaps and spikes". I changed NikonScan
| gamma to 1 and, "viola" I get a civilized histogram. Now, you did
| mention this and I had already tried it before on my own that but with
| no luck. What changed this time is that I turned the scanner off and
| on (just like I need to when changing NCM status) and this time the
| gamma change took. So, another major bug...
|
| Of course, as you also said, once correct gamma (2.2 in my case) is
| applied in PS the "gaps" reappear. However, there are no "spikes" and
| the histogram is generally much more civilized in the sense that there
| is no overlapping or recursive "ghosting", and the values are
| stretched out in a much more even manner. I suppose PS' algorithm and
| precision are superior, which doesn't surprise me, and which is why I
| try to avoid any processing in the firmware if I can (limited space,
| processor, etc).
|
| Converting the image to 16-bit before applying gamma and then going
| back to 8-bit appears to improve things somewhat. Anyway, this is hot
| of the presses and many more tests still to do, but as the joke goes:
|
| I'm hopelessly lost, but making good time... ;o)
|
| Don.
 
I also looked thru the Nikon site for the manual and couldn't find it
....how about a hint as to where it is?

Thanks,

Jean

Oh, sorry! Didn't think anybody else cared for version 3... :-)

The link given to me by Nikon is:

http://support.nikontech.com/cgi-bi...std_adp.php?p_faqid=5309&p_created=1056464188

However, this failed to work as Internet Explorer refused to start
downloading ("cannot find server") so I used an ftp client and
downloaded the file directly from:

ftp://ftp.nikon-euro.com/DOWNLOAD/NScan3/ns3rmena1.pdf

Don.
 
|
| >I also looked thru the Nikon site for the manual and couldn't find it
| >....how about a hint as to where it is?
| >
| >Thanks,
| >
| >Jean
|
| Oh, sorry! Didn't think anybody else cared for version 3... :-)
|
| The link given to me by Nikon is:
|
|
http://support.nikontech.com/cgi-bin/nikonusa.cfg/php/enduser/std_adp.php?p
_faqid=5309&p_created=1056464188
|
| However, this failed to work as Internet Explorer refused to start
| downloading ("cannot find server") so I used an ftp client and
| downloaded the file directly from:
|
| ftp://ftp.nikon-euro.com/DOWNLOAD/NScan3/ns3rmena1.pdf
|
| Don.


Thanks Don!

I'm interested in anything I can find on NikonScan. I've been following
this thread because I was hoping to learn how to optimize the settings for
NS for those occassions when I scan my really old (ie, the color is waaaay
off) Kodachromes.
 
Don said:
Having finally got the pdf manual (from a secret hiding place at
Nikon's site) it turns out "Lo-Cont" and friends only appear when
"Negative" is selected.

Interesting that the file from the location you posted only appears to
be about 2.7Mb, whilst the version on the NSv3.2 CD is over 30Mb - I
will have to take a detailed look at the difference, although on the
face of it they look identical. At a guess it is probably the
resolution of the embedded example images.
I also "fixed" those histogram "gaps and spikes". I changed NikonScan
gamma to 1 and, "viola" I get a civilized histogram. Now, you did
mention this and I had already tried it before on my own that but with
no luck. What changed this time is that I turned the scanner off and
on (just like I need to when changing NCM status) and this time the
gamma change took. So, another major bug...

Of course, as you also said, once correct gamma (2.2 in my case) is
applied in PS the "gaps" reappear. However, there are no "spikes" and
the histogram is generally much more civilized in the sense that there
is no overlapping or recursive "ghosting", and the values are
stretched out in a much more even manner. I suppose PS' algorithm and
precision are superior, which doesn't surprise me, and which is why I
try to avoid any processing in the firmware if I can (limited space,
processor, etc).
Woaohahaaoah!! Not so fast there - all that glistens is not gold!

Are you sure that you are actually converting from linear gamma, as
produced by Nikonscan, to the necessary 2.2 gamma for standard PC screen
display? Or are you simply assuming that the conversion from the
default sRGB gamma, which PS will assume for a non-tagged file, to the
gamma that you are using is implementing the conversion? The latter is
far from true.

As you may recall, and you will if you read back through the texts, I
specifically tested (and asked you to confirm) that the application of
2.2 gamma to an 8bpc (and, to a lesser extent, 10bpc) image produced
roughly the same amount of "spikes and gaps" in the histogram as you
were obtaining from NikonScan. (Indeed, this is a simple mathematical
consequence of the application of gamma to a quantised media and the
same effect will be visible at any resolution if the histogram bins are
fine enough.) However, now you say that the issue has gone, simply by
scanning at gamma=1 and then applying the required gamma in Photoshop!

Magic perhaps, but the difference certainly isn't one of PS algorithm
superiority to NS because the effect was already demonstrated in PS!

I suspect that the difference has more to do with the mixing of the
three channels to obtain the luminosity signal you are viewing in the
histogram than the disappearance of the quantisation itself. Take a
look at the individual colours - or the RGB histogram under the levels
control. There is no difference in image quality, just a mix that fits
well with the luminance weight!
Converting the image to 16-bit before applying gamma and then going
back to 8-bit appears to improve things somewhat. Anyway, this is hot
of the presses and many more tests still to do, but as the joke goes:
All that such a conversion can utilise is the additional two bits of
quantisation that that LS-30 has in hand - woefully inadequate to
eliminate the quantisation effect, as you have (if you have been
following through my suggestions) seen for yourself.

Don't confuse a smooth histogram for a good image. For example, a
smooth histogram can be obtained simply by adding noise to an image with
an otherwise quantised histogram. Nobody would argue that the addition
of noise improves the image quantisation depth. it may improve the
perception of the image by burying the detail in noise, but that is
obtained at the expense of that detail. All that glistens certainly is
not gold!
 
Don said:
Oh, sorry! Didn't think anybody else cared for version 3... :-)
Dontcha believe it!

Having run extensive tests on both slides and negatives using V3 and V4
I have concluded that the scan times for V4 are approximately 25% longer
for absolutely no benefit whatsoever, using my LS-4000. With V3 the
actual scan proceeds smoothly on my 2.4GHz P4 machine across the
firewire interface. Under V4 the transfer stops and starts as if the
bis itself is being saturated. That, however, only accounts for around
1% of the lost time. The rest is in the processing, excluding ICE, GEM,
and ROC. V4 offers nothing over V3 for users of older machines.

I have been back using V3, in preference to V4, for some time now and
have a question logged with Nikon as to why this major slowdown has
occurred. I suspect Hell will freeze over long before they stoop to
respond though.
 
I'm interested in anything I can find on NikonScan. I've been following
this thread because I was hoping to learn how to optimize the settings for
NS for those occassions when I scan my really old (ie, the color is waaaay
off) Kodachromes.

Ah! A fellow Nikon/Kodachrome victim!!! ;o) It makes me feel much
better knowing I'm not alone in this!

Seriously though, I don't know how much you followed my previous
messages but I've been at this for a good part of a year (about 3-4
months in these parts, the rest in the Photoshop group). Had a couple
of rounds with Nikon who blamed everything and everybody and denied
any problem. They even requested I send in a slide, as if they don't
know what Kodachrome is...

So far, when it comes to Nikon (LS30) and Kodachrome (KC), I've
learned a few things, some on my own and others with help around the
Net:

1. ICE off. Some people claim some KC slides may work with ICE on, but
I'm looking for a streamlined process, so I decided ICE off, for good.

2. Nikon Color Management (NCM) off! Very, very, very important! It
only makes the problem worse but amplifying the blue channel which is
already over the top, and reducing red which is already lacking!

3. Any time you change NCM, gamma, or any other major setting, turn
the scanner off in addition to restarting NikonScan. I know the docs
say restart only after changing NCM and nothing about turning off the
scanner, but since I started doing that I have no "random" scans
anymore. Hard to test when the scanner has a "random exposure
generator" and considers any setting merely a random seed number...
:-/

4. Turn Auto Exposure off (both preview and scan). It simplifies
things knowing there are no "external" changes outside of your direct
control.

5. Use Analog Gain to set exposure. Not only is this applied before
the scan (for purest results i.e. data) but it gives maximum control.

6. Be aware that any other setting besides AG is applied after the
scan. You may just as well use Photoshop and I have all NikonScan
settings at neutral.

What I'm trying to do now is streamline the process and eliminate
"user intervention" as much as possible. That's because I don't trust
this user (me!) and prefer an objective, reliable and repeatable
method. Ideally, I'd like a recommendation from Nikon but that's "not
gonna happen" and Kennedy thinks a general setting is not possible.

I'm currently trying to come up with a method to extract maximum
dynamic range from the scanner without any processing - data as raw as
possible to be processed later. I use Analog Gain (AG) for this
because it's the only setting which is applied before the scan. Auto
Exposure is set to off (both preview and scan). I'm considering two
approaches:

Approach A.
Scan at AG = 0. A cursory quick check in curves by clicking the
contrast button to see where individual channels end. I prefer this to
the histogram because it's hard to see pixel counts there. Instead, I
let Contrast find the ends. Actually, I'm only concerned with the
right edge as Kodachrome is usually too dark. Let's say this shows Red
at 126, G=135 and B=180. I reset curves to flat, boost red AG by 1,
and repeat the scan. I do this until all three channels are bunched
around the same value.

Still to do:
A1. Test by reducing clipping from default 0.3 to 0.1 or maybe even 0
to get maximum range (without noise) when I use Contrast to check the
histogram. I can always clip later.

A2. Find what value to aim for where the channels should meet. Going
for 255 is probably not a good idea (clipping) so, together with A1,
determine what value I should aim for. Sometimes this is academic as
even at Master AG=2 and Red=2 the red still only goes up to < 200.

Problem: By changing the relationship between channels a single global
correction (i.e. a streamlined process) may not be possible later. See
below for more...

Approach B.
Same procedure as A, only don't try to have all channels meet, but
keep their differences and increase AG in unison until one of the
channels (i.e. blue!) bumps against the right edge. The reason is to
keep the cast the same across all scans so I can apply a single
(rough) correction later.

Problem: By keeping the ratio I'm also limiting the range and blue is
always bound to hit the right edge very quickly keeping reds sometimes
as low as 126!

So, in order to reconcile these two irreconcilable requirements: Try
to find a "a rule of thumb" for Kodachrome (i.e. try to emulate what
Kodachrome setting does on Nikon models where this is available) and
then apply this at the AG stage. This should do rough color correction
and deliver maximum dynamic range. In theory...

This is controversial and Kennedy thinks not possible.

However, there is at least one fact which is irrefutable. All
Kodachromes scanned with Nikon have a blue cast. Apparently, it may
vary how much depending on the batch, LEDs, etc. but they all have it.

So, if I can find the *floor* value of this cast and apply it at the
AG stage I would have squeezed out every last drop of range, without
making matters worse, as well as done the lion share of removing the
KC cast. And that would make fine tuning color correction in Photoshop
later so much easier.

Sure, for some film, applying this generic "floor" value may not be
enough, but it's still better than not doing it at all. At the same
time I don't want to apply too much and do damage. In theory, I could
(should) come up with a custom solution for each slide, but not enough
time in this Universe for that... ;-)

Of course, finding the generic floor value in a scientific and
objective way is going to be very hard for an amateur like me without
any fancy gear. I tried, for example, to emulate the color balance of
the slide photographed with a digital camera. Other attempts were to
use results from automatic settings in various programs. Needless to
say they all differ. And my own setting of the black, white and gray
points is too subjective to be reliable. The quest continues...

Sorry for being so verbose, but I hope this is of some use - as well
as helping me take stock and organize my thoughts... ;-) Of course, as
always, any comments are most welcome!

Don.
 
Having run extensive tests on both slides and negatives using V3 and V4
I have concluded that the scan times for V4 are approximately 25% longer
for absolutely no benefit whatsoever, using my LS-4000.

It's probably the infamous "software bloat". Features and functions
nobody wants, in exchange for a performance penalty. A lose-lose
proposition... :-/
I have been back using V3, in preference to V4, for some time now and
have a question logged with Nikon as to why this major slowdown has
occurred. I suspect Hell will freeze over long before they stoop to
respond though.

Actually, you may prefer them not responding... In my experience
they'll come back with something really, really "relevant" like: What
color is your computer? ;o)

Don.
 
Interesting that the file from the location you posted only appears to
be about 2.7Mb, whilst the version on the NSv3.2 CD is over 30Mb - I
will have to take a detailed look at the difference, although on the
face of it they look identical. At a guess it is probably the
resolution of the embedded example images.

That is odd! I guess you're right as not a lot of people can afford a
30MB download. I see no revision number but the document is called:
"Nikon Scan 3 Reference Manual". The last page is numbered 152 with
header "Custom Install (Macintosh Only)", and footer "Appendix C:
Reinstall/Custom Install".
Are you sure that you are actually converting from linear gamma, as
produced by Nikonscan, to the necessary 2.2 gamma for standard PC screen
display? Or are you simply assuming that the conversion from the
default sRGB gamma, which PS will assume for a non-tagged file, to the
gamma that you are using is implementing the conversion? The latter is
far from true.

This is what I did: I changed Gamma in NS to 1 (restart, reboot
scanner). Scan with everything at neutral at 2700 dpi (maximum
optical, no need for interpolation). Next, I loaded this file into PS,
chose "Leave as is (don't color manage)". The histogram was "smooth".
(BTW, PS color management is on with gamma at 2.2) I created a level
layer (force of habit) and applied 2.2 gamma in the master channel. I
then flattened the image (PS histogram needs that) and had a look. I
got a "comb" histogram but no "waves".

Is that what I was supposed to do or did I do something silly?

I then repeated with NS gamma at 2, thinking that maybe the arithmetic
errors were caused by the awkward 1 to 2.2 conversion within
NS/firmware and that 1 to 2 integer arithmetic may not be as bad -
well, it was, as this generated the same histogram as the NS 2.2
setting...

But the plot thickens... Since then I reverted back to 2.2 in NS and
have been busy with other tests (see message to Jean). In the process
I used NS Curves' Contrast for a quick check of the histogram right
edge for all three channels. I then reset the curves to neutral and
scan. And the histogram is still smooth!?!?

I have to repeat this test, but it may very well be that some setting
somewhere (Gamma?) was wrong and by changing Gamma I inadvertently
"fixed" it!? Or maybe, simply by modifying curves NS "does something"
- even if I reset them back to zero afterwards !? The interpolation is
set to bilinear but according to the manual that shouldn't matter
although as I've observed before it appears to make a difference in
the preview.
Magic perhaps, but the difference certainly isn't one of PS algorithm
superiority to NS because the effect was already demonstrated in PS!

True, and I have no explanation for that. The only thing I can think
of is that maybe with gamma at 1, NS perhaps does some conversion
anyway (1 to 1) which "smoothes things out", instead of just passing
the data as is. But that doesn't make sense... I really don't know...
I suspect that the difference has more to do with the mixing of the
three channels to obtain the luminosity signal you are viewing in the
histogram than the disappearance of the quantisation itself. Take a
look at the individual colours - or the RGB histogram under the levels
control. There is no difference in image quality, just a mix that fits
well with the luminance weight!

Oh, I never look at luminance and always check the individual channels
because the effect was most pronounced there. (I used PS histogram
instead of just checking in the Levels because histogram is supposed
to be more accurate.)
Don't confuse a smooth histogram for a good image. For example, a
smooth histogram can be obtained simply by adding noise to an image with
an otherwise quantised histogram. Nobody would argue that the addition
of noise improves the image quantisation depth. it may improve the
perception of the image by burying the detail in noise, but that is
obtained at the expense of that detail. All that glistens certainly is
not gold!

I've been wondering about that. On the face of it, images with a
"weird histogram" do not look any different than the ones with a
smooth one. There's certainly no noticeable difference in quality.
It's just that it's more difficult to clip when the histogram is
"wild" like that. And I was also afraid that my scanner may have been
failing which you put to rest very quickly with the gradient test.

Don.
 
| In article <[email protected]>, Don
| >
| >Oh, sorry! Didn't think anybody else cared for version 3... :-)
| >
| Dontcha believe it!
|
| Having run extensive tests on both slides and negatives using V3 and V4
| I have concluded that the scan times for V4 are approximately 25% longer
| for absolutely no benefit whatsoever, using my LS-4000. With V3 the
| actual scan proceeds smoothly on my 2.4GHz P4 machine across the
| firewire interface. Under V4 the transfer stops and starts as if the
| bis itself is being saturated. That, however, only accounts for around
| 1% of the lost time. The rest is in the processing, excluding ICE, GEM,
| and ROC. V4 offers nothing over V3 for users of older machines.
|
| I have been back using V3, in preference to V4, for some time now and
| have a question logged with Nikon as to why this major slowdown has
| occurred. I suspect Hell will freeze over long before they stoop to
| respond though.
| --
| Kennedy


Your observed slow down in processing notwithstanding, did you find any
advantages at all in using NikonScan v4? One posting I've read indicated
that Nikon Color Management was "better" in v4.

Jean
 
Jean <[email protected]> said:
Your observed slow down in processing notwithstanding, did you find any
advantages at all in using NikonScan v4?

None that I noticed - a few new options that were greyed out, only being
applicable to the new scanners, but otherwise identical in interface and
output quality.
One posting I've read indicated
that Nikon Color Management was "better" in v4.
Yes, I saw that too, which was what prompted me to try the upgrade late
last year. The speed drop was apparent with a few seconds of the first
scan beginning. :-( However I persevered, explored and compared. Even
when back through my old process of generating a default scan setting
for a couple of films to compare with the (compatible) earlier versions.
No difference noted - hence my return to NS3.1.2
 
Don said:
This is what I did: I changed Gamma in NS to 1 (restart, reboot
scanner). Scan with everything at neutral at 2700 dpi (maximum
optical, no need for interpolation). Next, I loaded this file into PS,
chose "Leave as is (don't color manage)". The histogram was "smooth".
(BTW, PS color management is on with gamma at 2.2) I created a level
layer (force of habit) and applied 2.2 gamma in the master channel. I
then flattened the image (PS histogram needs that) and had a look. I
got a "comb" histogram but no "waves".

Is that what I was supposed to do or did I do something silly?

Sounds OK, perhaps the image content is obscuring the "waves" since they
are a direct consequence of the same rounding and quantisation that
gives rise to the comb - you can't get one without t'other.
Oh, I never look at luminance and always check the individual channels
because the effect was most pronounced there. (I used PS histogram
instead of just checking in the Levels because histogram is supposed
to be more accurate.)
I do not know where you picked that myth up, because the histograms are
identical to those in the Levels dialog - check it yourself, make a
screen grab of both and overlay them in difference mode if necessary.

You may be getting confused with the preference setting option to use
the cache for histograms rather than the full image. This can certainly
result in a marginally less accurate histogram, but the inaccuracy is
equally relevant in the Histogram and the Levels dialogs. The only
difference between these two is that RGB in Levels dialog gives equal
weighting to red, green and blue, whilst the Luminance in the Histogram
dialog displays a green biased weighted sum. The histograms of the
individual channels are identical in both dialogs.
 
SNIP
You may be getting confused with the preference setting option to use
the cache for histograms rather than the full image. This can certainly
result in a marginally less accurate histogram, but the inaccuracy is
equally relevant in the Histogram and the Levels dialogs. The only
difference between these two is that RGB in Levels dialog gives equal
weighting to red, green and blue, whilst the Luminance in the Histogram
dialog displays a green biased weighted sum. The histograms of the
individual channels are identical in both dialogs.

For those interested in a more detailed ( more than 256 bins) histogram,
there is a free enhanced histogram plug-in for 16-bit images available at
http://www.reindeergraphics.com/free.shtml . It also allows to save/export
the bin values as a text file.

Bart
 
Sounds OK, perhaps the image content is obscuring the "waves" since they
are a direct consequence of the same rounding and quantisation that
gives rise to the comb - you can't get one without t'other.

It's the same slide but the NS behaves differently now. Previously (I
actually wrote about it here) with Interpolation at Bilinear the
preview histogram and the histogram of a saved image were different
(scan had the "ghosting" while the preview didn't).

The only thing different now is that I don't trust NikonScan anymore
and after *any* major change restart it and turn the scanner off. When
I ran the tests originally I didn't do that so the scanner and NS were
probably in an "unknown state" giving these unreliable results. That
seems to account for a lot of irrational results I was getting before.

The only thing affecting the histogram now (i.e. appearance of
"ghosting") seems to be the Interpolation method which, according to
documentation is only relevant when downsampling to a fractional
reduction, so it *shouldn't* play any part in the final scan's
histogram since I scan at optical resolution (no up/down-sampling). I
can still recreate the "weird" histogram when I set Interpolation to
None, but once I set it to Bilinear it's fine. Weird!

I wonder how many other people have this bug (not just the histogram
but NS in an "unreliable state") but don't notice it simply because
most slides they scan are not as extreme as mine so any errors are not
as glaring.


BTW, one other interesting thing. I'm now playing with a procedure
whereby I first "normalize" a slide to squeeze out maximum dynamic
range. I do this by adjusting AG until all three histograms
synchronize on the right (see recent message to Jean for more
details).

Now, if I take such an image and try to remove the Kodachrome cast I
need to add red and remove blue in *equal* amounts, keeping green as
is. I do this by adjusting gamma in levels. On the test slides so far
this ranges from R=1.2, G=1, B=0.8 to R=1.1, G=1, B=0.9.

Do you have a theoretical explanation for this symmetry, or is that
simply what Kodakchome is like?
I do not know where you picked that myth up, because the histograms are
identical to those in the Levels dialog - check it yourself, make a
screen grab of both and overlay them in difference mode if necessary.

That's why I wrote "supposed to be". But I saw it on the Internet, so
it must be true! ;o)
You may be getting confused with the preference setting option to use
the cache for histograms rather than the full image.

I deselected that option for exactly that reason when I originally
installed PS, and the cache indicator in the Histogram is 1, which
means "use all pixels" according to the help file.

Don.
 
Ah! A fellow Nikon/Kodachrome victim!!! ;o) It makes me feel much
better knowing I'm not alone in this!

There are many more NikonScan/Kodachrome users here following this
thread...
1. ICE off. Some people claim some KC slides may work with ICE on, but
I'm looking for a streamlined process, so I decided ICE off, for good.

I always use ICE on with my Kodachromes. Every now and then, I turn it
off to see the difference. Off, the scan shows dust...scratches...and
more. On, it's clean and there is no discernible (to my eye) color
shift. (NikonScan 3.1; Nikon LS-2000.)

2. Nikon Color Management (NCM) off! Very, very, very important! It
only makes the problem worse but amplifying the blue channel which is
already over the top, and reducing red which is already lacking!

Almost always NCM off, but sometimes I test trouble slides with it
on. As long as I set the colorspace (usually Adobe RGB), the result are
pretty good.


But...most of the time...I use Vuescan. Even though it has a less
elegant interface, I almost always get correct colors. Only problem
is that Vuescan upgrades no longer support Macintosh OS 9. So I'm
stuck at my current version.


-db-
 
There are many more NikonScan/Kodachrome users here following this
thread...

The more the merrier! ;o)
I always use ICE on with my Kodachromes. Every now and then, I turn it
off to see the difference. Off, the scan shows dust...scratches...and
more. On, it's clean and there is no discernible (to my eye) color
shift. (NikonScan 3.1; Nikon LS-2000.)

A few months back I started scanning my complete slide collection.
(First time ever I used a scanner and I was blissfully unaware of
Nikon's "difficulty" with Kodakchrome.) However, after about 15 CDs
worth of scans (ICE and NCM on) I hit a brick wall with some really
bad scans simply impossible to fix.

Although ICE does a pretty good job the problem was not the color
balance but - what I believe is called - pixelisation (Kodachrome blue
cast is another story...). I have some dark slides (which means lots
of silver left it) which Nikon makes even darker in addition to adding
the infamous blue cast. ICE apparently interprets this silver as
something to be corrected. Trying to brighten up such a scan then just
exposes these areas and the result is quite bad.

In my experience, if a Kodachrome slide is pretty bright then ICE will
work just fine but if there are dark and dense areas they will get
"corrupted".

Don.
 
Don said:
The only thing affecting the histogram now (i.e. appearance of
"ghosting") seems to be the Interpolation method which, according to
documentation is only relevant when downsampling to a fractional
reduction, so it *shouldn't* play any part in the final scan's
histogram since I scan at optical resolution (no up/down-sampling). I
can still recreate the "weird" histogram when I set Interpolation to
None, but once I set it to Bilinear it's fine. Weird!
In which case I suspect that, strange as it may sound to you, setting
NONE is giving you the real data from the scanner since the histogram
quantisation demonstrably results from processing the limited bit depth
you have to begin with. The lack of the visible effect with bilinear
interpolation on suggests that some interpolation is still being
performed, even at the optical resolution. It's difficult for me to
prove this because I do not have access to an LS-30, s it is just a
suggestion. The bottom line is that any workflow which enables you to
produce a smooth histogram after applying gamma 2.2 to an 8 or 10 bit
per channel image must involve noise addition or resolution/bit depth
trading because there simply is not enough information there to begin
with.
BTW, one other interesting thing. I'm now playing with a procedure
whereby I first "normalize" a slide to squeeze out maximum dynamic
range. I do this by adjusting AG until all three histograms
synchronize on the right (see recent message to Jean for more
details).

Now, if I take such an image and try to remove the Kodachrome cast I
need to add red and remove blue in *equal* amounts, keeping green as
is. I do this by adjusting gamma in levels. On the test slides so far
this ranges from R=1.2, G=1, B=0.8 to R=1.1, G=1, B=0.9.

Do you have a theoretical explanation for this symmetry
Coincidence. Gamma 1.2 v 0.8 and 1.1 v 0.9 are only symmetrical in an
exponential form. In terms of luminance at most levels there is no
symmetry.
 
Don said:
The more the merrier! ;o)


A few months back I started scanning my complete slide collection.
(First time ever I used a scanner and I was blissfully unaware of
Nikon's "difficulty" with Kodakchrome.) However, after about 15 CDs
worth of scans (ICE and NCM on) I hit a brick wall with some really
bad scans simply impossible to fix.
But Don, as I keep telling you, NO scanner with the Dmax and bit depth
limits of the LS-30 can cope with the density range and dynamic range
that slide film (let alone Kodachrome slide film) can reproduce.
Consequently it is inevitable that you will run into "problem slides"
which are beyond the capabilities of your scanner. This is not a new
discovery you have made. It has been well known for a very long time
and is actually very well documented. When this was among the best
desktop available it was just an accepted fact of life that some slides
just did not scan at all well.
 
Back
Top