Minolta 5400 or Coolscan 5000

[Kennedy McEwen]

I have to add here that I was working in 8 bits. This would probably not
have been the case had I been working in 16 in PS.

Certainly the difference would have been less, but I am not sure that
the results would actually have been in a different order. I don't hold
the view, taken by some, that the processes implemented by the scanner
software are inherently inferior or less accurate than those in PS. Good
though it is, PS has to earn its place on the pedestal, to give it that
position by rights is just BS.

But it does point out that if you are going to be working in 8 bits it is
better to make the adjustment prescan in 14 or 16 bits or whatever your
scanner can do.

That is what I meant when I said that you lose quality if you scan raw and
then adjust in PS. I was assuming you are working in 8 bits. Are you?

Certainly Don is working with 14-bit data. I use what I need for the
job in hand.

I went on to do some comparison scans in SilverFast and NS--both neutral--no
prescan adjustments except setting black and white points. Interesting
results. The SF scans of positives were definitely better than the NS scans.
There was a marginal improvement (though very slight) in shadow detail it
seemed to me, but more importantly the color balance was much better--so
apparently SF uses a slightly different mix of the RGB LED intensities.

No, LED intensity is not adjustable in the hardware - except in terms of
being on or off. ;-) SF may use a different balance of RGB exposure
though, based on its autoexposure algorithm.

If you had taken the time to adjust the analogue gain in NS before
setting the black and white points *could* have produced the similar
smoothness in colour throughout the range. Given your comments about
the shadows, it would appear that you are getting an advantage in SF of
a different gamma conversion, which could be minimised by appropriate
analogue gain settings in NS.

This is my issue with Don - dismissing out of hand the automatic
functions implemented by these 3rd party software packages is folly, as
is suggesting that manual intervention is always better than automatic.
The equivalent auto function on NikonScan, autoexposure (which is not
based on the preview but on a separate pass of the image), does not
yield the same results, or as accurate ones, as those of Silverfast,
hence the *need* for analogue gain manual adjustment to get a similar
result.

 

[Hecate]

Actually, research consistently shows that for inner city trips under
45 mins bike is the fastest, closely followed by public transport with
the car as the distant third. With ever increasing inner city
congestion this time is bound to go up.

The notable exception is London (U.K.) where they introduced a
"congestion charge" to limit the number of vehicles. So, the bike wins
again because cyclists don't have to pay this fee.

There is one car that doesn't either - the Toyota Prius a
petrol/battery hybrid which is actually a very nice car too.

 

[Don]

Fastest is, like hardware output, only one parameter in the entire
equation of which transport is best.

Which is why I said "the fastest" and not "the best" because the
former is measurable quantity, the latter is a subjective opinion. ;-)

Also, "research consistently shows that" bicycle riders are more likely
to be killed in road traffic accidents than truck drivers.

Very true! Civilized places like Holland have dedicated bike lanes and

Of course city trips under 45minutes are faster by bike

It's "of course" to you and me but most drivers still believe that a
car is always faster.

Don.

 

[Don]

Don, now you really are talking out of your wrong end! Speaking from
Europe, yes the UK is technically part of both the geographic continent
and the political union, there are extremely few hybrid cars, very small
fractions of a percentage point of the total number of vehicles.

That's why I said "most". Virtually all vehicles in Holland, for
example, are propane (or some sort of natural gas) / gasoline
vehicles. In Germany, I believe, a car must be 90% recyclable before
it's allowed on the market, etc.

The U.K. marches to a different drummer in many areas. While I always
admired and loved this eccentricity because it was innovative and
productive and not bound by inertia, in more recent times this is
often self-destructive and counter-productive. Point in case: the
whole anti-Europe hysteria, not to mention the support of Bush, etc...
:-/

Even though the gap is closing, London and Britain are still my
personal favorite places in Europe (of the areas I know) in spite of
the immense damage (both physically and in terms of mentality) Maggie
has done to both... ;o)

What does all this have to do with scanning? Well... Erm... I... Ah...
Yes! The fastest way to deliver your scan within a city is to jump on
a bike! Yeah, that's it! ;o)

Don.

 

[Don]

I do, but (and this is where you seem to have a problem) I accept that
others have a different value system which places more emphasis on
getting the best result for the minimum effort.

Now that's just patently wrong! I always include something along the
lines of "there's nothing wrong with that and many people are
perfectly happy with it".

However, when such non-cognoscenti try to spread rumors that their
"auto-everything" is *technologically* superior, that's where I have a
problem. Sure, use it and be happy, but don't foster delusions that
*in absolute terms* that approach is superior.

The basic misunderstanding is that I make a distinction between
relative and absolute evaluations. Some "great unwashed" seem to have
the mistaken notion that just because they can in *relative* terms
easily get (what to them looks like) acceptable results, that
automatically translates into *absolute* superiority of such scans in
*technical* terms. And that's just not true. That's all I'm pointing
out...

And, now it comes to mind, that was another case where your workflow
would have produced an inferior end result: the LS-20 is a 10-bit
internal device with only 8-bit output. All processing in NS1.63 was
implemented in the scanner itself, via look-up tables to 10-bit
precision. A raw scan could only be processed to 8-bit precision in
Photoshop.

Yes, indeed, and I have always acknowledged (in numerous messages!)
that in regard to LS-30 VueScan is capable of getting the full 10 bits
while NikonScan only delivers 8. About the only advantage of VueScan.
For my new "LD-50" even that advantage is gone because NikonScan drags
out the full 14-bits out of the LS-50.

Don.

 

[Don]

This was never the point of my discussion.

Yes, it was, even though you are now trying to back pedal:

I prefer to scan raw and edit in Photoshop.

You lose a lot of quality this way.

I really hope you understand why this is wrong because it's the first
and essential step and without that it will be pretty much impossible
to understand anything else.

My point was that it is better to
make your adjustments prescan while you are working in 14 or 16 bits
(depending on your scanner) than afterwards in PS--if you are using 8 bits
there.

It's nothing to do with 8 or 16-bits. You may be able to observe the
corruption much more easily in 8-bits simply because histogram
displays are geared towards 8-bits but the corruption is there is
16-bits as well (see my other message).

When you make color or contrast adjustments using scanner software
through the tiny "keyhole" of a Preview you will virtually never "get
the most out of the scanner". Quite the contrary!

The best you can hope is to "get lucky" and by accident stumble on the
optimal settings. But the odds of that are miniscule and that's
certainly not something to rely on for repeatable results.

Relying on such a "lucky shot" is like relying on a broken clock
because even a broken clock is correct twice a day!

Don.

 

[Don]

This is my issue with Don - dismissing out of hand the automatic
functions implemented by these 3rd party software packages is folly, as
is suggesting that manual intervention is always better than automatic.

Then we can put it to rest because that was never the issue.

The issue was (and I'll repeat it once again):

I prefer to scan raw and edit in Photoshop.

You lose a lot of quality this way.

To say "lose quality" is wrong, to say "lose a lot of quality" is "a
lot" wrong and shows a lack of very rudimentary understanding.

Don.

 

[Don]

OK guys, I did some experimenting and here is what I came up with.

Very good!!! Tests are essential, although one has to prepare tests
very carefully otherwise one will arrive at wrong conclusions...

Case in point: The reason it's so windy in Holland is *not* because
all those windmill blades are spinning... ;o)

I went into PS and adjusted the first "raw" scan to visually match the
"optimized" second scan, then compared the histograms. The first one,
adjusted in PS, was much gappier than the second, adjusted pre-scan.

As I explained there are many ways to get a smooth histogram and just
looking at histograms without knowing how they were arrived at doesn't
really say much. As I also explained, a "gappy histogram" by itself is
not necessary bad. It's just an unavoidable effect of gamma
conversion.

One other note. Your "raw" scan is not really raw because you have
done at least two modifications I can see from here: Auto-Exposure and
Gamma conversion.

I have to add here that I was working in 8 bits. This would probably not
have been the case had I been working in 16 in PS.

It would make some difference in the *histogram display* but not in
image data. If your workflow introduces corruption in 8-bits it will
introduce it in 16-bits as well.

One very important thing to keep in mind. Even when working in 16-bits
in Photoshop the histogram display is still 8-bits!!!! If it were a
true 16-bit histogram you would have 65536 vertical bars, not 256!

So, any gaps in the 16-bit image histogram are *hidden* because the
data is being squeezed into an 8-bit histogram display. Just because
these gaps are not displayed, it doesn't mean they aren't there. A
true 16-bit histogram (with 65536 vertical bars) would be just as
"gappy" as the 8-bit!!!

Technically, PS doesn't actually support true 16-bit images but
"15-bit + 1" if I remember correctly, but certainly not the full
16-bits. Not important here, but a little curiosity.

But it does point out that if you are going to be working in 8 bits it is
better to make the adjustment prescan in 14 or 16 bits or whatever your
scanner can do.

It is virtually never "better" to make adjustments in scanner software
than scanning raw and processing later.

Using 16-bits (or whatever) helps, and may mask a lot of artifacts
especially if you convert to 8-bit before saving, which may be more
than enough for your requirements, but strictly speaking (if one is
proficient in image editing software) the raw scan will virtually
always be superior.

(In theory, if scanning software included something along the lines of
Photoshop there would be no difference - but scanning software is
never as powerful, it doesn't offer the same amount of tools nor the
appropriate working environment e.g. the tiny Preview window.)

Caveat: I repeat! Such improvements are directly related to your
proficiency with image editing software. Depending on your
requirements - and even with perfect editing - these improvements may
not be important or even noticeable!

So, if what you're getting with your current workflow is acceptable to
you, that's great! Stick with it!

But be aware that it is *not* "the best" in *absolute* terms! And
certainly don't make such statements in public... ;o)

While I understand Don's point about all the bells and whistles on SF--the
auto theses and thoses, I was referring in my post to the nicer tonal
rendition I find using SF. And in fact when I adjust the NS scans (with
their smoother tonal range) I again end up with a gappy histogram, as
compared to the SF raw scans (although those still contain the tonal gap in
around zones 8-10).

Re-read what I wrote about gappy histograms in other messages. You are
still mixing up a lot of stuff.

Don.

 

[Don]

I don't hold
the view, taken by some, that the processes implemented by the scanner
software are inherently inferior or less accurate than those in PS.

Processing not, but the ability to employ yes. You just can't achieve
the same result looking at the image in the tiny Preview windows even
if you used Photoshop or any other image editing software.

Also, Photoshop and other image editing software have a much wider
toolbox than scanner software, as well as a much more detailed image
analysis utilities, etc. I never claimed that PS or any other image
editing software has superior algorithms to scanner software. They
may, but that's not what this is about.

Certainly Don is working with 14-bit data. I use what I need for the
job in hand.

Yup, and to get off topic... (We like to do that!) ;-)

My latest tests actually indicate that to really get the most I would
need a 20-bit scanner! I know, I know... Dmax and all that, but (at
least as far as my Kodachromes go) anything below about 32 in the
histogram has noise and all multiscanning does is just mask that noise
to some degree, but doesn't recover any more actual image data in
these dark areas!

I can achieve comparable masking of this noise by simply applying
between 0.3 and 0.5 Gaussian blur on data below 32 - perhaps followed
by Unsharp mask. On the other hand, boosting Analog Gain until
relevant histogram data is over 32 reveals much more detail (shading)
in the same area than simply multiscanning where no such shading is
apparent. At least in my current environment: LS-50, 80's Kodachromes.

This is my issue with Don - dismissing out of hand the automatic
functions implemented by these 3rd party software packages is folly, as
is suggesting that manual intervention is always better than automatic.

Then we can put it to rest because that's not what I said.

I said, among other things, that:

- stating that *relative* user friendliness of "auto-everything"
directly translates into *absolute* technical superiority over
knowledgeable "everything-off" user is wrong.

- stating that relying on tiny Preview window and a limited subset of
tools is superior to full display and a full set of tools is wrong.

- stating that auto is "a lot" better than manual is wrong, except in
the singular and very unlikely and rare case of a "lucky shot" - when
it's at best merely equal - which "lucky shot" is beyond the scope of
this discussion.

Don.

 

[Bruce Graham]

Thanks Bruce for digging this up. As stated in an earlier response, I
did find and try this. After removing some lint on the mirror, the
ss4000 flare problem diminished somewhat but not entirely.

Sorry David, with all the other stuff floating around I missed your
response. Have you tried reducing the scanner exposure a bit more than
you would expect from the histogram? Just an experiment to see if the
CCD overload point is inside the ADC range, which might cause something
like flare.

BTW (just to keep on topic) I recently returned from a 2000 Km bicycle
ride, but I flew home so I lost all my enviro points. I have a Nissan
Patrol 4WD (not sold in USA, originally military, UN etc - heavy duty gas
guzzler), but I also have a tiny Toyota 820 Kg kerb mass (Japanese
Starlet) which I use for all city driving, so I am partly redeemed.

Bruce

 

[DavidTT]

What has that got to do with the price of fish?

Why is a better end result questionable? If it works for you, that's
what matters.


And why are there more of them on the market, when a manual Tx gives
better performance. Do Americans not care about performance or do they
dust have a different value system for it?


Same question in different terms: What drives what is on the European
market? Do Europeans care more about performance than Americans, or
just have a different value system for it?

The auto manufacturers have a thing to do with it. They make more
selling auto transmission. Just like sellers of third party scanner sw.

Found the clutch yet?

Down boy. The sun had set long ago in your Great Empire.

 

[Toby]

Hi Don,

First I need to apologize for being totally inaccurate in my language. It
was certainly a mistake to make the blanket statement that I did about
losing a lot of quality without explaining what I meant. I have areas of
expertise that I have and exercise in other NGs (mostly concerning music and
videography) I am constantly correcting imprecise and incorrect statements,
and so it embarrasses me to make inaccurate statements myself.

I do want to quote to you from Photoshop Artistry by Barry Haynes and Wendy
Crumpler, which was the genesis of the statement I made. As I said, I
assumed that you were working in 8 bits in PS. Many people do, and it was
not specified either way. However to assume so without stating so was wrong.

If we are talking about working in 16 bits, or whatever passes for that in
PS I quite agree than unless the analog gain of the scanner is wrong you get
all the information you are going to get--the software will not get you more
and PS generally is easier and more precise in its controls.

However as Haynes and Crumpler point out, "When the file you are saving is
an 8-bit per channel file, the scanner software will often have to decide
how to convert the 12 or more bits of information the scanner is actually
getting down to 8 bits per channel in the file that will be saved. When you
are doing this, it is important to use the setting in the scanner software
to optimize how the scanner converts from the higher bit depth down to 8
bits."

If you feel that this is in error please let me know how.

I am rather fascinated by the difference in the scans I got from NS and
SF--raw scans both. It must be related to analog gain. The color differences
in the positive scans is also rather interesting.

Toby

 

[Toby]

I will apologize for my statements about getting better results from SF than
NS, which was as you point out no more than a matter of convenience and
perhaps more pleasing algorithms.

Please see my other message as regards pre-scan correction as related to 8
bits vs. 14-16 bits.

Toby

 

[DavidTT]

As I explained there are many ways to get a smooth histogram and just
looking at histograms without knowing how they were arrived at doesn't
really say much. As I also explained, a "gappy histogram" by itself is
not necessary bad. It's just an unavoidable effect of gamma
conversion.

After making pre-scan adjustment, the Nikon sw should show a gappy
histogram (not a Nikon user, so not sure). The sw will then interpolate
the pixels to fill the gaps, and that's why you are seeing a smooth
histogram in PS.

The same is true with a histogram in PS. After you edit the raw scan in
PS, you get a gappy histogram. However, the gaps won't stay long. Add a
new levels layer or a levels adjustment layer. Before making any levels
edits, you will see that the histogram is smooth and the gaps are gone.
PS has interpolated the pixels to fill the gaps, just like the scanner
sw did.

Histogram is a great tool to see what happens after each edit. However,
it does not keep track of the accumulated effect of the data losses
after multiple edits. Otherwise, the gaps will look uglier after each
incremental edit.

 

[Don]

Hi Don,

Hi Toby!

First I need to apologize for being totally inaccurate in my language. It
was certainly a mistake to make the blanket statement that I did about
losing a lot of quality without explaining what I meant. I have areas of
expertise that I have and exercise in other NGs (mostly concerning music and
videography) I am constantly correcting imprecise and incorrect statements,
and so it embarrasses me to make inaccurate statements myself.

There's absolutely no need to apologize. We are all constantly
learning, me most of all!

I do want to quote to you from Photoshop Artistry by Barry Haynes and Wendy
Crumpler, which was the genesis of the statement I made. As I said, I
assumed that you were working in 8 bits in PS. Many people do, and it was
not specified either way. However to assume so without stating so was wrong.

If we are talking about working in 16 bits, or whatever passes for that in
PS I quite agree than unless the analog gain of the scanner is wrong you get
all the information you are going to get--the software will not get you more
and PS generally is easier and more precise in its controls.

This is not really a question of 8 vs. 16 bits. If you make changes in
your scanner software (regardless of bit depth) you are not getting a
"pure" scan from the scanner. All changes you made in your scanner
software get applied to the "pure" scan *before* it is passed on to
you.

Therefore, by definition, any time you do something (such as curves or
contrast) to this "pure" scan you are not getting "the most" out of
the scanner. You're getting a modified version instead.

The order of things, very, very, very roughly and without getting into
any details - Kennedy will do that... ;-)

1. An image is scanned and passed to the host software. This is the
purest scan you can get. If you set 8-bits that's the purest 8-bit
scan. If you set 16-bits then it's the purest 16-bit scan. The fact
that 16-bit scan contains more data than 8-bit scan is not the point
here. The point is what (if anything) you do to this 8 or 16-bit scan
before you receive it!

2. Various modifications can be made at this point by the scanner
software depending on what you did there e.g. curves adjustments,
contrast etc. And it doesn't matter whether this is done to 8 or
16-bit data. Remember, we are not talking about the difference between
8 and 16 bits, but the difference between whether you made any changes
or not.

This simple list leaves out a lot (gamma, ICE, etc) but the above is
not meant to be a comprehensive flowchart. It's only there to
illustrate that scanner software changes such as color and contrast
are applied to the "raw" scan data *before* you ever get to see it.

However as Haynes and Crumpler point out, "When the file you are saving is
an 8-bit per channel file, the scanner software will often have to decide
how to convert the 12 or more bits of information the scanner is actually
getting down to 8 bits per channel in the file that will be saved. When you
are doing this, it is important to use the setting in the scanner software
to optimize how the scanner converts from the higher bit depth down to 8
bits."

It doesn't matter. This "interpolated 8-bits" is still purer than
"interpolated 8-bits" *plus* your changes (curves, contrast).

That's the key! Any scanner software curves or contrast adjustments
get applied to the "raw" scanner data no matter what that data is (8
or 16 bit).

If you feel that this is in error please let me know how.

I am rather fascinated by the difference in the scans I got from NS and
SF--raw scans both. It must be related to analog gain. The color differences
in the positive scans is also rather interesting.

There are many reasons for that and Kennedy addressed some of them.
It's the "bells and whistles" which SF adds to make your life easier.
However, in the process you are moving further and further away from
what the scanner delivered in the first place.

As I said many times, there's absolutely nothing wrong with that. If
you're happy with what you're getting - even if SF or VueScan or
whatever "massaged" scanner data to death - all that doesn't matter.
The important thing is that you are getting results which satisfy your
requirements.

However, it's important to know that - no matter how attractive this
output may look to you - that is not the purest (i.e. "the most") data
from the scanner. The scanner always produces the same data. The
difference is whether you let the software such as SF do the
additional editing for you before you receive this data or, you take
this data "as is" and do the editing yourself later in the image
editing software of your choice.

Don.

 

[Don]

After making pre-scan adjustment, the Nikon sw should show a gappy
histogram (not a Nikon user, so not sure). The sw will then interpolate
the pixels to fill the gaps, and that's why you are seeing a smooth
histogram in PS.

The same is true with a histogram in PS. After you edit the raw scan in
PS, you get a gappy histogram. However, the gaps won't stay long. Add a
new levels layer or a levels adjustment layer. Before making any levels
edits, you will see that the histogram is smooth and the gaps are gone.
PS has interpolated the pixels to fill the gaps, just like the scanner
sw did.

Histogram is a great tool to see what happens after each edit. However,
it does not keep track of the accumulated effect of the data losses
after multiple edits. Otherwise, the gaps will look uglier after each
incremental edit.

Yeah! What he said! ;o)

Don.

 

[Don]

I will apologize for my statements about getting better results from SF than
NS, which was as you point out no more than a matter of convenience and
perhaps more pleasing algorithms.

Although very much appreciated, there's absolutely no need to
apologize. We are all still learning and that's what this newsgroup is
for.

Don.

 

[Don]

BTW (just to keep on topic) I recently returned from a 2000 Km bicycle
ride

....

Oooh... Tell us more! ;o)

Besides using the bike as my main means of transport, I'm a casual
recreational cyclist myself, doing only day trips (200 KM max) and
using a plain-vanilla touring bike - nuthin' fancy. The idea is to go
slow and take in the scenery, giving my digital camera a workout in
the process. And, of course, logging the trip and marking where I took
the pics on a hand-held GPS unit!

Having said that, every now and then that leisurely pace (including
chirping birds) gets interrupted when a steep hill starts mocking me
(the soundtrack ominously changing to the Jaws signature tune) and I
can't help myself but go for broke... ;o)

Don.

 

[Kennedy McEwen]

That's why I said "most".

That's why I said you were talking out of your wrong end - it isn't
most, it isn't even a significant amount.

Brazil, Argentina and even Italy are ahead of Holland in terms of
natural gas transport fuel use.

From http://www.ecn.nl/_files/bio/psp-03-037.pdf
"Of 800,000 ... there are only 500 natural gas powered vehicles in The
Netherlands".

That is just 0.0625% but I am sure you said "most", didn't you?

It isn't a coincidence that the oil company isn't called "Royal Dutch
Shell"!

Virtually all vehicles in Holland, for
example, are propane (or some sort of natural gas) / gasoline
vehicles.

Which is also not true and a contradiction of your earlier statement
that these were hybrid vehicles with minimal emissions. Natural gas and
propane emit just as much CO2 per kW of produced power as octane
(gasoline).

In Germany, I believe, a car must be 90% recyclable before
it's allowed on the market, etc.

A law that applies Europe wide but which has completely *zero* impact on
fuel consumption or the use of hybrid engine technology.

The U.K. marches to a different drummer in many areas.

Only in those areas where we have negotiated an exemption from European
legislation, which do not impact any of the topics you have so far
introduced.

From the same document as above:
The EU has *targeted* 2% of all transportation fuel consumed by the
market to be natural gas by 2010, 5% by 2015 and 10% by 2020.

 

[Kennedy McEwen]

Now that's just patently wrong! I always include something along the
lines of "there's nothing wrong with that and many people are
perfectly happy with it".

You seem to have forgotten to include that in any of your recent posts.

Perhaps my server has filtered the relevant text out of your messages.

The basic misunderstanding is that I make a distinction between
relative and absolute evaluations.

Like "not exactly"?

Some "great unwashed" seem to have
the mistaken notion that just because they can in *relative* terms
easily get (what to them looks like) acceptable results, that
automatically translates into *absolute* superiority of such scans in
*technical* terms. And that's just not true. That's all I'm pointing
out...

And I am pointing out that your absolute statement about what is
superior methodology is equally untrue in a variety of situations.