Black/white pt triangles in Vuescan Histograms?

[Tom]

Ed

I have gotten very confused about how Vuescan handles the black
point(s). To be specific, I am scanning slides, with Input|Media set
to image and color balance either off or set to manual. In order to
get access to the 3 color black pts I sometimes check Input|Lock Image
Color. LS5000 with Scanner color space set to built in. I have also
set this to Nikon's scanner color profile and get the same results
described below and I have examined this color space with
ColorSyncUtility and it appears to map 0 to 0 for all colors. Mac OSX
10.3.5, Vuescan 8.0.14

In the top (before) histogram the right single triangle is at about
the 6th bin. The blue histogram starts near 0, but the other two start
near 6. In the lower (after) histogram the blue has been shifted up
and all colors start around 6 -- so there is clipping of about 6 bins
in the black. I see this also in the Photoshop histograms.

When I Lock Image Color I get access to the 3 color black and white
pts and the 3 triangles at each end. I force these all to zero. Yet I
still get the same output clipping.

I like my blacks and I don't want to lose even 6 bins so I am really
curious about what is going on. I can understand that the scanner
color space might need to correct the blacks, but why aren't the red
and green pushed down to meet the blue at 0 rather than what seems to
be happening is that the blue is pulled up to meet the other 2? Why
does the scanner profile seem to indicate that it maps 0 to 0 for all
colors? Is it correct that Built in Scanner space mean you are using
Nikon's profile? No other color correction should be involved since
there is no film base correction going on. For full disclosure, I have
light cleaning, but no other filter active. How can I avoid clipping
these blacks? Can you explain how this all works?

And, oh by the way, Vuescan is one of the truly great software
programs!

 

[Wilfred]

I have gotten very confused about how Vuescan handles the black
point(s). To be specific, I am scanning slides, with Input|Media set
to image and color balance either off or set to manual. In order to
get access to the 3 color black pts I sometimes check Input|Lock Image
Color. LS5000 with Scanner color space set to built in. I have also
set this to Nikon's scanner color profile and get the same results
described below and I have examined this color space with
ColorSyncUtility and it appears to map 0 to 0 for all colors. Mac OSX
10.3.5, Vuescan 8.0.14

In the top (before) histogram the right single triangle is at about
the 6th bin. The blue histogram starts near 0, but the other two start
near 6. In the lower (after) histogram the blue has been shifted up
and all colors start around 6 -- so there is clipping of about 6 bins
in the black. I see this also in the Photoshop histograms.

When I Lock Image Color I get access to the 3 color black and white
pts and the 3 triangles at each end. I force these all to zero. Yet I
still get the same output clipping.

I like my blacks and I don't want to lose even 6 bins so I am really
curious about what is going on. I can understand that the scanner
color space might need to correct the blacks, but why aren't the red
and green pushed down to meet the blue at 0 rather than what seems to
be happening is that the blue is pulled up to meet the other 2? Why
does the scanner profile seem to indicate that it maps 0 to 0 for all
colors?

That's interesting: with my scanner (Minolta 5400) I sometimes have the
same problem on the other side of the histogram, with one of the colors
clipped in the highlights. I've only seen it with negatives (that may be
consistent with your observations on slides). Still haven't found a
workaround, although I sometimes manage to get rid of the clipping after
a long, non-repeatable process of messing around with the different
settings in VueScan.

 

[WD]

I would suggest asking this question to Ed Hamrick. I have at times
found Vuescan to be tricky with issues like this.
At least Vuescan lets you (or attempts to let you) control the black
and
white point selections for R G and B. This is far superior to Nikon
Scan
which makes its own determination, the user be damned. I have always
had an issue with NikonScan (I scan mostly negatives) with black and
white
point determination causing clipping of highlights and/or shadows.
This IMHO is Nikon Scans biggest problem. It is a pity because it
would
probably be quite easy to remedy for the SW developers.
I have used Epson flatbeds (w/Epson SW) and they do not have this
issue at all giving
the user full control of black and white point selection much like
Vuescan.
It is a pity Nikon refuses to let the advanced user control this.

 

[Bart van der Wolf]

Ed

I have gotten very confused about how Vuescan handles the black
point(s). To be specific, ...

SNIP for brevity

In the top (before) histogram the right single triangle is at
about the 6th bin. The blue histogram starts near 0, but the
other two start near 6. In the lower (after) histogram the blue
has been shifted up and all colors start around 6 -- so there
is clipping of about 6 bins in the black. I see this also in the
Photoshop histograms.

Do you mean 6 in the total range of... 100% / 255 / 65535 (32767 in
case of PS)?
A screen print of the histogram pane may be helpful.

When I Lock Image Color I get access to the 3 color black
and white pts and the 3 triangles at each end. I force these
all to zero. Yet I still get the same output clipping.

If you increase the Black/White point settings from 0.0 by 0.001
increments, you'll be able to get output close to zero for the
individual channels.

I like my blacks and I don't want to lose even 6 bins so I
am really curious about what is going on. I can understand
that the scanner color space might need to correct the
blacks, but why aren't the red and green pushed down to
meet the blue at 0 rather than what seems to be happening
is that the blue is pulled up to meet the other 2? Why does
the scanner profile seem to indicate that it maps 0 to 0 for
all colors?

I assume we're seeing step increments that are relatively small, but
significant in the lower densities.

Bart

 

[Tom]

Responses in snips from your message below:

Do you mean 6 in the total range of... 100% / 255 / 65535 (32767 in
case of PS)?

255 although I am working in 16 bit/color. The PS Levels Histogram,
which is the best place to measure this, only reads out in 8 bit
resolution.
It is about 3% on VueScan's % histograms.

A screen print of the histogram pane may be helpful.

I am not sure how to post this, but I don't think it is necessary.

If you increase the Black/White point settings from 0.0 by 0.001
increments, you'll be able to get output close to zero for the
individual channels.

Aha! Yes, this did push the 8 bit histogram down to 0. Thanks for the
tip. I tried smaller increments and it behaved as if it was set to 0.
If I understand correctly these numbers are in linear space, so they
are fractions of 32767.

Is it correct that these are fractions, not %? If so, there is still
some lost information as .001x32767 is ~32 and we are losing the
lowest 4 or 5 bits of the 16 bit capability of the LS5000. Perhaps
this limitation dates back to when so called 16 bit scanners like the
LS4000 really were only 12 bit?

I assume we're seeing step increments that are relatively small, but
significant in the lower densities.

I realize this is very finicky, but shadow detail can be crucial and
we are taught to try to set end points at where 0 info is lost and
then work from there. I am printing with ColorByte's ImagePrint 6 RIP
on an Epson 2200. ImagePrint provides extremely fine control of shadow
detail with a special slider that works the black point region and
goes beyond what you can normally obtain in Photoshop. So getting a
little more shadow detail is very desirable. I am presently working
with an image that has huge nearly black areas, but there is some
detail and it is important to the overall feel of the print. So that's
why I care.

I have not yet done a step increment test with my new LS5000 though I
have a Kodak Q60E3 target available. I sure hope it is better than the
LS4000 in this regard -- one of the reasons I upgraded...

Tom