Minolta 5400, Vuescan, 1px lines

[Wilfred]

Strange enough, with my old Minolta Scan Speed, the problem of
single-pixel scan lines could be *reduced* by calibrating the scanner
with VueScan. The result in that case was clearly better than the scan
result from the MInolta software.

Quite possibly, however even the merest suggestion that Vuescan is less
than perfect with any scanner would appear to upset many of its devotees
in this and other forums. I should point out that this is not a problem
that I have noticed with any of the Nikon scanners that I have used
Vuescan with - that doesn't mean it doesn't exist with them either, but
Ed does recommend their product.

It seems true that Ed prefers Nikon. AFAIK he uses a Coolscan V himself
and I think that Nikon users can be more confident that VueScan works
well with their scanners than people using scanners from other
manufacturers. I don't think Ed has a unit of every scanner at home -
for tackling problems with non-Nikon scanners he has to rely on raw
files and log files he receives from users. For tackling problems with
Nikon scanners (if he hasn't noticed them already in his own scans) he
can use his Coolscan. That would certainly be more effective.
On the other hand, our error reports could help Ed improve VueScan for
non-Nikon scanners, albeit more slowly and indirect ...

 

[Don]

At least up to 8.1.25, it seems that ALL of my scanners, when used
with Vuescan, suffer, to some extent, of the same problem (faint
stripes in the shadows).

I also remember reports of VueScan causing this with Nikon scanners.
Somebody wrote that a German magazine experienced VueScan stripes with
an LS-5000, I believe.

I'm just writing this because in the past, some hypothesys were
formulated about the nature of the problem.
Maybe this can add some data.

My money is still on a comms problem. VueScan bypasses recommended
scanner access (through TWAIN) and talks to scanners directly.

There is nothing wrong with that, of course, but that's a whole new
level of complexity which is apparently way beyond VueScan author's
limited capabilities.

Also, it's unclear whether Mac and Linux users share this VueScan bug.

Unfortunately, the rabid VueScan "supporters" are more concerned with
shouting that there is no problem and trying to censor anyone who
dares to state the facts, in the end only hurting legitimate users
like yourself.

Don.

 

[Don]

The OP is experiencing a commonly reported bug and telling them that the
bug is still an issue and (perhaps!) the subject of ongoing effort, on
Ed's part, to resolve is much more accurate and useful than your
statement along the lines of
<AOL>
works for me!!
</AOL>

The point is we don't really know it does work them!!

As "proof" they provide web images which due to their miniscule size
and heavy postprocessing are totally useless for the task. Worse
still, they don't seem to realize the futility of such "proof" thereby
showing lack of most fundamental understanding.

However, judging by their "oversensitivity" and rabid overreaction,
odds are they *are* experiencing this major VueScan bug. That's why,
instead of facts, they immediately resort to personal attacks. It
would appear that all this shouting is really frustration because they
don't like being reminded of all the grief this VueScan bug is causing
them.

On the other hand (and there is some support for this) they may just
be uneducated "sloppy" users without standards who don't care about
1px lines and only care that their web graphics look "good". Nothing
wrong with that, and as I said many times, anyone who doesn't care for
quality or reliability is the natural target audience for VueScan.

Don.

 

[Don]

It seems true that Ed prefers Nikon. AFAIK he uses a Coolscan V himself
and I think that Nikon users can be more confident that VueScan works
well with their scanners than people using scanners from other
manufacturers.

I don't think any scanner user is "safe" from VueScan bugs. You
yourself reported this only a few months ago:

It may be interesting to know that a on a German filmscanner forum, a
Nikon LS-5000 user has reported similar streaks when using VueScan. He
claims that the streaks started to appear after version 8.0.4.
For those who understand German:
http://f27.parsimony.net/forum67102/messages/5833.htm
For those who don't:
http://tinyurl.com/5uzcp

Don.

 

[DavidTT]

This newsgroup has become a total waste of time. You and your friends
Don and Hecate can be mighty proud of that.

On the contrary, contribution from posters like Don, Hecate, Kennedy,
Fernando, Bart etc. is what makes this newsgroup (and online forums in
general) good. Their inputs may be critical or supportive, and objective
or subjective. But they always have substance backed up with context,
and are not personal attacks. While I do not always agree with or
understand what they say, I admire their style. It is practicing online
information democracy at its best.

 

[Wilfred]

Also, it's unclear whether Mac and Linux users share this VueScan bug.

I'm a Mac user and I did have problems with one-pixel scan lines up and
until VueScan version 8.1.12. After that version, the problem
disappeared. I've not seen scan lines using the MInolta software - but
then again I don't use it too often because of its disadvantages.
My previous filmscanner, a Minolta Scan Speed, also produced
single-pixel scan lines. These lines were most prominently visible when
using the Minolta software. When using VueScan, they almost (but not
completely) disappeared after using VueScan's 'calibrate scanner' command.

 

[Wilfred]

I don't think any scanner user is "safe" from VueScan bugs. You
yourself reported this only a few months ago:

Yes, but I've never heard of this again. Ed Hamrick may have solved this
because it was a problem with a Nikon scanner. There was one single
mention of this in a German discussion forum.

 

[Hecate]

posting suggested otherwise and, frankly, served no purpose whatsoever
in resolving the problem. Hecate's advice did - don't use Vuescan and
the Minolta together, the former cannot reliably drive the latter. By
posting in direct conflict to that statement you imply that it is false
and thus that the problem does not exist at all.

Precisely. I tried Vuescan and it wasn't up to the job with my Minolta
scanner. I never comment on it's compatibility with, for example,
Nikon. If the OP asks about Minolta I'm going to tell him what I know,
even if it does upset what increasingly seems to be the "Cult of
Vuescan".

That the problem *still* exists, that the combination *is* incompatible
for those unfortunate enough to encounter it, that "works for me" is no
more relevant than Ed's original, oft rescinded and oft reinstated "Now
supports Minolta SE-5400" claim and that ignoring those who have grounds
for complaint is both demeaning and reputation damaging in itself.

Exactly. When I've made some comments here before and you've
corrected me, I've agreed when it's obvious that you were right and I
was wrong. The Cultists seem to accept no wrong whatever - Vuescan and
it's acolytes are right every time, regardless of any evidence to the
contrary.

 

[Dierk Haasis]

On the contrary, contribution from posters like Don, Hecate, Kennedy,
Fernando, Bart etc. is what makes this newsgroup (and online forums in
general) good.

As for Fernando, Bart (especially) and Kennedy I can follow you.
Include Ralf, who is also a very good contributor. I have no idea why
you include our pet trolls, but, hey, everyone to his taste.

Perhaps Kennedy and Ralf could concisely explain why they and over
what they started their current war? Can't be just for the differing
perspectives on Vuescan and Minolta scanners since both stated correct
claims about it - only on different content levels [my own theory of
communicative misinterpretation, based on my own Contextual Analysis
Theory].

The facts are:

1. Some users of certain Minolta scanners (mostly the SE 5400) get
sub-par scans when Vuescan is used. This (and some maybe related
issues) are known and asserted by the programmer.

2. Some users have been vocal about *not* having problems with the
Minolta/Vuescan combo (me among them).

There's a whole plethora of proposals that can be derived from these,
not necessarily mutually exclusive.

My favourites (for all practical purposes):

A. Be sure the problems you see do translate into problems in the real
world. E.g., if 1px lines feature in your end product when not
treated, use Minolta's or Lasersoft's application.

From this stem two corollaries - those who don't see problems may just
not have the same expectations as those who see them; and, if you are
content with what you get, stay with VS regardless of any theoretical
problems reported.

B. As so often is true in the computer world, the numerous
combinations of varying variables translate to some problematic and
some perfect scans. One possible solution for this would be that VS
algorithms is much better in showing deficiencies of certain scanner
units.

We know that Minolta had some quality trouble with the 5400 at the
beginning, they had to exchange some units because the sensors were
faulty. They also had to change the software and the firmware (which
is loaded by the sw, as it seems, and is not resident in the hardware
when one switches the 5400 off) to "repair" sensor problems.

Neither do we have a really representative statistic on how the
VS/Minolta scanner combo actually performs nor do we have enough
knowledge of the internals of either VS or Minolta's scanners to
logically derive at the solution of the problem discussed. That leaves
us with testing for oneself.

You want to know how VS performs with your scanner, load down the test
version and try it out, preferably on a few typical negatives and
transparencies and on a few problematic ones.

 

[Dierk Haasis]

I used to have scan lines on my old Minolta Scan Speed too,
both with VueScan and the Minolta software.

Confirms my believe that VS isn't the only culprit in this puzzle
[there goes style and consistent metaphor].

As I stated in other messages - one in this thread just minutes ago -
it may be that VS shows hardware "deficiencies" better than the
manufacturer's own sw, which wouldn't really surprise me. Since
Minolta (other companies respectively) know their designs rather well
they may also have easier ways to mask them through sw.

Wasn't it Bart who acknowledge the different density values Minolta
and VS come up with?

 

[Kennedy McEwen]

Perhaps Kennedy and Ralf could concisely explain why they and over
what they started their current war?

On my part it was simply a response to misleading statements posted in
response to truthful statements and recommendations made to the original
poster who was having problems with the Vuescan/Minolta combination in
one configuration.

The original poster identified No. 1 in your fact list:

1. Some users of certain Minolta scanners (mostly the SE 5400) get
sub-par scans when Vuescan is used. This (and some maybe related
issues) are known and asserted by the programmer.

They were provided with the only realistic solution at present,
identified as A in your solution proposal list:

A. Be sure the problems you see do translate into problems in the real
world. E.g., if 1px lines feature in your end product when not
treated, use Minolta's or Lasersoft's application.

However this was then contradicted by Ralph using only the justification
given in your post as:

those who don't see problems may just
not have the same expectations as those who see them; and, if you are
content with what you get, stay with VS regardless of any theoretical
problems reported.

This was both totally adequate to contradict the original solution and
also contradicted the original premise underlying question: the original
poster *is* experiencing the problem acknowledged by the programmer
*and* is not content with what he gets from it.

 

[Kennedy McEwen]

I used to have scan lines on my old Minolta Scan Speed too,
both with VueScan and the Minolta software.

Confirms my believe that VS isn't the only culprit in this puzzle
[there goes style and consistent metaphor].

No - I am pretty sure that the only bugs in this instance acknowledged
by the Vuescan author relate to its operation with the Minolta SE-5400.
Previous Minolta scanners seem to have been working fine, long before
the SE-5400 was released.

As I stated in other messages - one in this thread just minutes ago -
it may be that VS shows hardware "deficiencies" better than the
manufacturer's own sw

Or put another way, Vuescan is less able to cope with the hardware than
the manufacturer's own product - which is how most users see it when
they find problems on Vuescan that do not exist on Minolta's own
software.

However, I direct all of those submitting to this thread to read the
original post again - particularly the paragraph below:

"These lines occur only with Vuescan and only when I enable the grain
dissolver. Scanning with the Minolta-Software in any configuration OR
WITH VUESCAN without the grain dissolver give no lines." (My
capitalisation added for emphasis.)

This is not just a matter of Minolta software working and Vuescan
software not working. The original poster clearly states that Vuescan
works perfectly in his configuration *without* the grain dissolver. It
is *only* when the grain dissolver is enabled that Vuescan fails.

My analysis of this is that Vuescan is *still* incompatible with the
Minolta scanner since it is clearly failing to take adequate account of
a physical change in the scanner hardware configuration. The grain
dissolver changes the illumination level at the CCD and therefore the
scanner increases the exposure time for each scan line. Consequently,
any calibration data obtained at a higher illumination level is no
longer accurate and a *complete* recalibration sequence is required. Ed
has already stated that it is the calibration step which has caused him
most problems in his implementation. The original question merely
indicated that he is not "out of the woods" yet, although he may have
resolved the underlying calibration problem, and that further bug fixes
are necessary.

The original advice is the only relevant advice in this context -
Vuescan cannot cope (yet!) with the Minolta scanner in the configuration
required. The original poster is already achieving perfectly adequate
scans using Vuescan and the Minolta in another configuration, perhaps
even the same configuration that Ralph used for the results he posted as
"evidence" to contradict the original advice provided.

 

[Wilfred]

I used to have scan lines on my old Minolta Scan Speed too,
both with VueScan and the Minolta software.

Confirms my believe that VS isn't the only culprit in this puzzle
[there goes style and consistent metaphor].

As I stated in other messages - one in this thread just minutes ago -
it may be that VS shows hardware "deficiencies" better than the
manufacturer's own sw, which wouldn't really surprise me. Since
Minolta (other companies respectively) know their designs rather well
they may also have easier ways to mask them through sw.

The strange thing was that, with the Scan Speed, the number of scan lies
was *lower* when using VueScan, provided that the 'calibrate' command
was performed before scanning.

Wasn't it Bart who acknowledge the different density values Minolta
and VS come up with?

Yes, it was Bart. However, Ed Hamrick claims that the density values in
VueScan are no longer different since version 8.x.y. My impression is
that, at least for my DSE5400, this is true - but as we have seen in
these discussions, this may not be true for other units.

It is also possible that different production batches of the DSE5400
behave differently and that the Minolta SW -and software based on the
SDK- are able to detect the production batch and correct for the
different behaviors, while VueScan can't.

 

[Fernando]

My money is still on a comms problem. VueScan bypasses recommended
scanner access (through TWAIN) and talks to scanners directly.

I think (I'm a programmer myself; my present job involves reading and
writing new generation 2D-barcodes) that the problems could have (at
least) something to do with black level compensation.
Maybe the way Vuescan calibrates the black level of the sensor
(assuming of course that the calibration is done on individual pixel
basis as it should be) is not good enough.
So, sensors that show larger differences between the single
photodiodes are not adequately "calibrated" (that is, their RGB
readouts are not fully compensated), and the different responses from
the various photodiodes show up as thin streaks in the final image;
the visibility of those streaks would depend of course on various
settings (from CCD exposure to postprocessing manipulations such as
Color Balance, sharpening and so).

This would make sense, to me at least, when we take into account that
Ed Hamrick has not direct access to all the scanners Vuescan supports:
units slightly worse than the ones he used may show problems he did
not encountered, during the limited time he spent with the machines at
hand.

Also, it's unclear whether Mac and Linux users share this VueScan bug.

I use both Linux and Windows versions of Vuescan; they share the same
problem.

Fernando

 

[Fernando]

Wasn't it Bart who acknowledge the different density values Minolta
and VS come up with?

Yes, but it was at Vuescan disadvantage: with Vuescan, we both
experienced a more limited actual dynamic range. In particular, shadow
levels were too high, too close to midtones levels, so to speak.
A target made of a fully opaque part and a fully transparent part gave
for example (with optimal exposure and no after-scan levels tweaking)
a dynamic range of say 10 to 250 with Minolta software, and 30 to 250
with Vuescan.
Values are just given for figures, I honestly don't recall the exact
numbers; but they were in this range, approximately.

This, again, could have something to do with black level
"calibration".

Fernando

 

[Kennedy McEwen]

I think (I'm a programmer myself; my present job involves reading and
writing new generation 2D-barcodes) that the problems could have (at
least) something to do with black level compensation.

As a designer of high performance imaging systems, I would say that is
almost certain.

Maybe the way Vuescan calibrates the black level of the sensor
(assuming of course that the calibration is done on individual pixel
basis as it should be) is not good enough.

Looks that way, from the reports.

So, sensors that show larger differences between the single
photodiodes are not adequately "calibrated"

I think it is more likely to be associated with noisy cells rather than
worse raw uniformity.

This would tie in with the reports I have read on at least three
accounts:
1. Some scanners appear to have no problems at all - presumably those
with CCDs which well exceed Minolta's basic specification for noise,
although this may simply be user tolerance or expectations.
2. Some scanners only appear to suffer from the problem when the source
material is quite dense.
3. Some scanners, such as the original poster's, suffer the problem
only when the grain dissolver is enabled.

In cases 2 & 3, the CCD illumination is significantly reduced, resulting
in longer exposures and consequently the greater sensor excess noise.

During the calibration process many samples of the black and white
points are taken and averaged to determine the dark current and response
calibration coefficients. How many samples are required is a function
of the noise characteristics of the sensor however, if the noise is
random, then the noise in the resulting calibration coefficients reduces
proportionally to the square root of the number of samples taken.

The objective of the calibration is to ensure that the residual
non-uniformity is imperceptible and this requires that the calibration
coefficients are essentially noise free - at least to the limits of the
system quantisation (actually more than that for response coefficient!).
In cases where the illumination signal is low and thus excess noise is
proportionally greater, a larger number of samples in the calibration
will be needed to achieve this requirement.

Since Vuescan apparently implements its own calibration procedure,
independent of the manufacturer's own algorithms, the need for
additional samples may not be being implemented.

I should, of course, emphasise that this latter comment is entire
speculation on my part since I have no knowledge of exactly what Ed is
implementing on Vuescan - or what Minolta does either. However it does
fit with the reported problems.

 

[Hecate]

However, I direct all of those submitting to this thread to read the
original post again - particularly the paragraph below:

"These lines occur only with Vuescan and only when I enable the grain
dissolver. Scanning with the Minolta-Software in any configuration OR
WITH VUESCAN without the grain dissolver give no lines." (My
capitalisation added for emphasis.)

This is not just a matter of Minolta software working and Vuescan
software not working. The original poster clearly states that Vuescan
works perfectly in his configuration *without* the grain dissolver. It
is *only* when the grain dissolver is enabled that Vuescan fails.

My analysis of this is that Vuescan is *still* incompatible with the
Minolta scanner since it is clearly failing to take adequate account of
a physical change in the scanner hardware configuration. The grain
dissolver changes the illumination level at the CCD and therefore the
scanner increases the exposure time for each scan line. Consequently,
any calibration data obtained at a higher illumination level is no
longer accurate and a *complete* recalibration sequence is required. Ed
has already stated that it is the calibration step which has caused him
most problems in his implementation. The original question merely
indicated that he is not "out of the woods" yet, although he may have
resolved the underlying calibration problem, and that further bug fixes
are necessary.

The original advice is the only relevant advice in this context -
Vuescan cannot cope (yet!) with the Minolta scanner in the configuration
required. The original poster is already achieving perfectly adequate
scans using Vuescan and the Minolta in another configuration, perhaps
even the same configuration that Ralph used for the results he posted as
"evidence" to contradict the original advice provided.

Yes, I have the same impression as you and I think it has a lot to do
with Ed Hamrick deciding not to use the supplied Minolta SDK.

 

[Bart van der Wolf]

I think it is more likely to be associated with noisy cells rather
than worse raw uniformity.

Possibly, after all the higher resolution could well be achieved by
using smaller sensors (-> smaller well-depth), but that wouldn't
explain why the Minolta software doesn't exhibit the calibration
problem.

This would tie in with the reports I have read on at least three
accounts:
1. Some scanners appear to have no problems at all - presumably
those with CCDs which well exceed Minolta's basic specification for
noise, although this may simply be user tolerance or expectations.

Most likely manufacturing tolerance plays some role, but it is hard to
pinpoint how large a factor it is.

2. Some scanners only appear to suffer from the problem when the
source material is quite dense.

Any scanner will suffer from photon shot noise. Smaller well depths
will be more critical.

3. Some scanners, such as the original poster's, suffer the problem
only when the grain dissolver is enabled.

Which all indicates that, given VueScan's rather straight forward
conversion, that it could be a coding issue within VueScan. Of course
it would take a more in depth test to "prove" that.

Some posters claim it IS a VueScan coding issue, which is obviously a
ridiculous, baseless, opinionated claim without such an in-depth test
(thus trolling in my view). Any reasonable person, like yourself, can
only assume possible causes for the phenomenon that some observe under
certain conditions. That those VueScan bashing trolls drove the author
of VueScan away from this forum, doesn't help to solve the issue. They
provided a disservice to the scanning community and themselves.

In cases 2 & 3, the CCD illumination is significantly reduced,
resulting in longer exposures and consequently the greater sensor
excess noise.

In my experience the scan (exposure)time is significantly increased
when the Grain Dissolver is activated, so case 2 seems more probable
(e.g. photon shot noise, although that could be reduced by
longer/multiple exposure times).

During the calibration process many samples of the black and white
points are taken and averaged to determine the dark current and
response calibration coefficients. How many samples are required is
a function of the noise characteristics of the sensor however, if
the noise is random, then the noise in the resulting calibration
coefficients reduces proportionally to the square root of the number
of samples taken.
Yep.

The objective of the calibration is to ensure that the residual
non-uniformity is imperceptible and this requires that the
calibration coefficients are essentially noise free - at least to
the limits of the system quantisation (actually more than that for
response coefficient!). In cases where the illumination signal is
low and thus excess noise is proportionally greater, a larger number
of samples in the calibration will be needed to achieve this
requirement.

In my opinion VueScan does an overall good job of optimizing the
exposure (maximizing exposure without highlight clipping).

Since Vuescan apparently implements its own calibration procedure,
independent of the manufacturer's own algorithms, the need for
additional samples may not be being implemented.

I also think it could be as simple as that, especially since the
Minolta software seems to manage/suppress it better (and it takes
considerable time, 40 seconds, for re-calibration versus VueScan's 30
seconds on my box).

I should, of course, emphasise that this latter comment is entire
speculation on my part since I have no knowledge of exactly what Ed
is implementing on Vuescan - or what Minolta does either. However
it does fit with the reported problems.

I agree, although thanks to the trolls we possibly may not know for
sure.
One can only hope Ed Hamrick gets enough constructive (user) feedback
to justify obtaining another DSE-5400 scanner.

The scanner's resolution, and the effectiveness of the Grain
Dissolver, is really stunning. It would be a shame if Ed didn't
prioritize solving the issue for some silly reason (there are possibly
more DSE-5400 owners out there than he realizes).

Bart

 

[Wilfred]

Yes, but it was at Vuescan disadvantage: with Vuescan, we both
experienced a more limited actual dynamic range. In particular, shadow
levels were too high, too close to midtones levels, so to speak.
A target made of a fully opaque part and a fully transparent part gave
for example (with optimal exposure and no after-scan levels tweaking)
a dynamic range of say 10 to 250 with Minolta software, and 30 to 250
with Vuescan.
Values are just given for figures, I honestly don't recall the exact
numbers; but they were in this range, approximately.

This corresponds to my impressions, but with my DSE 5400 this phenomenon
disappeared since VueScan 8.1.12 or so.

It can be illustrated by describing the leftmost end of what a typical
RGB histogram of the final scan looks like:

* Minolta software: pixel_count=0 from RGB=0 till RGB=10, from that
point, the histogram follows a gradually climbing slope

* VueScan before 8.1.12: pixel_count=0 from RGB=0 till RGB=30, at that
point there is a steep 90-degrees slope up to a certain height, from
which the slope gradually rises further

* VueScan from 8.1.12: same as Minolta software.

 

[Bart van der Wolf]

SNIP

Yes, I have the same impression as you and I think it
has a lot to do with Ed Hamrick deciding not to use the
supplied Minolta SDK.

Do you have a link to the SDK? I can't find it at:
<http://www.konicaminoltaeurope.com/magic_frameEoI.shtml?nav.html?software/software/software_en.html>

Bart