VueSCAM!

[Don]

In that case, the Minolta software and SilverFast probably mask these
lines too. What's the point if you can't see them?

The point (as I indicate above) is that, when some people see them and
others don't, it's a fudge. It's not a fix. It may fool some less
critical people, but it doesn't fool everybody.

A fix would be when nobody sees them anymore. It actually fixes the
problem, instead of trying to hide it.

It's like the difference between painting over a crack in the wall and
filling the crack up. VueScan just splashes on a coat of paint but
that doesn't hide the (many) VueScan's *structural* problems.

Don.

 

[Fernando]

The point (as I indicate above) is that, when some people see them and
others don't, it's a fudge. It's not a fix. It may fool some less
critical people, but it doesn't fool everybody.

Don and Wilfred, believe me: those streaks are absolutely evident in
the shadows (though they are faint on properly lit areas). There's no
way a person with a normal vision would miss them. So it's not like
someone notice the streaks, and someone don't; it's more like on some
units those streaks are so faint to be unnoticeable, and on some other
units they jump at you. With Vuescan, that is.
Now I'm not at home and can't post samples, but will do over the WE.

If I only had the time, I would try a couple algorythm on raw Vuescan
data... I think the streaks could be fixable, if one has a dark frame
scanned under the same conditions. It just escapes me why I should do
that by myself; but then, Canon did just the same with their own
cameras (banding on the 20D), that is, ignored the problem and let
their customers trying to find workable conditions for quite a lot of
20D cameras (not all 20D cameras suffer from banding).

Fernando

 

[Wilfred]

The point (as I indicate above) is that, when some people see them and
others don't, it's a fudge. It's not a fix. It may fool some less
critical people, but it doesn't fool everybody.

A fix would be when nobody sees them anymore. It actually fixes the
problem, instead of trying to hide it.

It's like the difference between painting over a crack in the wall and
filling the crack up. VueScan just splashes on a coat of paint but
that doesn't hide the (many) VueScan's *structural* problems.

Nonsense. You're suggesting that I have become less critical because I
used to see scan lines with older versions of VueScan, yet I don't see
them with newer versions. I know exactly what 1-pixel green lines look
like (they're mostly green IME). They're a pain in the a#%, especially
when you apply USM somewhere in the process.
I'm not suggesting the problem has been solved. Apparently, VueScan has
been modified in such a way that it discriminates between different
units. Some units still suffer from the problem in combination with
VueScan, others don't - whereas all units used to suffer from the
problem in combination with VueScan in the past.

 

[Bruce Graham]

I think he's simply suggesting that VueScan is not in the same league
as Silverfast. It certainly doesn't have as many bugs as VueScan.

Silverfast has a different target market to Vuescan - the very large
difference in price means that Silverfast is excluded from consideration
for many. I wondered about it for my scanner when I bought it a few
years ago (CanonFS4000) but then realised Silverfast:

1. could only be used with that scanner - if I bought another, I needed
to buy the software again.

2. did not support IR cleaning for the FS4000

3. cost more than I was comfortable paying for this aspect of my hobby.

so I'm glad Ed sells Vuescan. It lets me do lots of things I could not
do with the "auto only" Canon software. Its bug level for my purposes is
less than lots of software that I use, because my scanner is not the one
scanner type of about 400 supported that Don is worrying about.

BTW. I'm not knocking Silverfast, if I had more money and a different
scanner which Silverfast supported better I may well have bought it.

 

[Bruce Graham]

But, then again, judging by all the messages no software seems to have
as many bugs as VueScan...

about half of the messages come from you!

 

[degrub]

No. a drum scanner is a drum scanner. There are a lot of differences
between PMT and CCD based scanning.

 

[Sansame]

Don, negative posts against Vuescan are mainly from you !
How do you get so much energy and time to spend on this small war ?
As many people, I have Silverfast AND Vuescan. Both of two are very
good but I prefer to use Vuescan for scanning dias and negs on my
Nikon4000ED, because results are excellents and driving my SF-200
automatic feeder is much more easy with Vuescan.
I am a very happy Vuescan user, very sorry because Ed dont talk anymore
here...
Sansame

 

[Don]

Don, negative posts against Vuescan are mainly from you !

There is nothing negative about my posts regarding VueScan. They are
just plain facts. When somebody asks for advice or makes misleading
statements, I just tell it like it is.

The trouble is that doesn't sit well with (some!) VueScan users. So
when they challenge me with their *feelings* I just respond with more
facts. That's all!

The problem is they don't like these facts. But, as I keep writing,
attacking anyone reporting VueScan bugs is not going to fix the bugs!

As many people, I have Silverfast AND Vuescan. Both of two are very
good but I prefer to use Vuescan for scanning dias and negs on my
Nikon4000ED, because results are excellents and driving my SF-200
automatic feeder is much more easy with Vuescan.
I am a very happy Vuescan user

And I'm glad you're happy with VueScan. I have often mentioned VueScan
to people who just want a quick-and-dirty job. But they should not be
under the misapprehension that it's anything else.

Don.

 

[Don]

about half of the messages come from you!

Many of them responding to messages like this to correct misleading
insinuations... As I just did! ;o)

Don.

 

[Don]

Nonsense. You're suggesting that I have become less critical because I
used to see scan lines with older versions of VueScan, yet I don't see
them with newer versions.

No, I'm saying that in your case the "splash of paint" - to use the
above metaphor - *hides* them, but they are still there underneath the
paint like that crack in the wall is still there even though the paint
may (try to) hide it.

The fact they appear on other models means what you see is not a
solution but a fudge. They have not been fixed but only *masked*.

Why does that matter if you can't see them? Because that means the
data you are receiving from the scanner has been "massaged" in order
to mask them. I call that *corrupt* data! That's the problem!

When you lean against that above wall, the paint will crumble and the
crack will be revealed. Now, if the crack has been really solved i.e.
filled, you can lean all you want and it won't make any difference.

VueScan is full of such fudges which is why when you "lean" against
it, it crumbles! That's why many bugs keep reoccurring. The program is
a house of cards.

I'm not suggesting the problem has been solved. Apparently, VueScan has
been modified in such a way that it discriminates between different
units. Some units still suffer from the problem in combination with
VueScan, others don't - whereas all units used to suffer from the
problem in combination with VueScan in the past.

It's not the units, it's VueScan. Let me try another example:

If you have "jaggies" in a scan (diagonal straight lines which are not
smooth but have pixel-steps") you can approach this in two ways:

1. You can mask them using aliasing.
2. You can scan using higher resolution.

Number 1 is fudging, number 2 is solving.

Some people will find "solution" 1 perfectly acceptable. However,
applied to different lines it will produce different results. Indeed,
very thin lines may "disappear" altogether (turn into a very faint
gray line). That's because the fact remains that the jaggies are
*still there*, underneath, just masked. And given the right
circumstances (like the case of a thin line) they result in major
problems.

That's why No. 1 is not a solution but a fudge. Just like VueScan's
approach is a fudge trying to hide a major bug. Some users may not
care, and that fine. What is not fine is when they call this *fudge* a
solution.

Don.

 

[Don]

So it's not like
someone notice the streaks, and someone don't; it's more like on some
units those streaks are so faint to be unnoticeable, and on some other
units they jump at you. With Vuescan, that is.

Which is exactly why that has nothing to do with the units, as some
people try to imply. The problem is clearly with VueScan.

If I only had the time, I would try a couple algorythm on raw Vuescan
data... I think the streaks could be fixable, if one has a dark frame
scanned under the same conditions.

Well, you can't really fix them, but you can try to mask them.

One thing you may want to try (in your image editing software) is to
select dark areas with a high feather value (so the selection edge is
"fuzzy" and not a straight cut-off) and then apply a small amount of
Gaussian Blur. That should blend them with their surroundings - but
you may lose some detail.

Or do something similar to what ICE does and treat them like "dust and
scratches" and try to hide them that way.

Or better still, instead of VueScan, use good software! ;o)

Don.

 

[Don]

Silverfast has a different target market to Vuescan - the very large
difference in price means that Silverfast is excluded from consideration
for many.

That may be the case, but it only confirms that the two programs are
not in the same league.

Don.

 

[Fernando]

If I only had the time, I would try a couple algorythm on raw Vuescan

Well, you can't really fix them, but you can try to mask them.

The thing I'm talking about, is per-cell calibration.
You scan an empty frame, examine the levels of the rows (single cell
outputs), and use those informations to correct the levels of the
actual scanner images.
It's the very same thing Minolta Scan Utility and Silverfast do, and
that Vuescan try to do without good success in many cases.
There is no other way to correct streaks, for you can't adjust the
gain/offset of the single sensor cell.

One thing you may want to try (in your image editing software) is to
select dark areas with a high feather value (so the selection edge is
"fuzzy" and not a straight cut-off) and then apply a small amount of
Gaussian Blur. That should blend them with their surroundings - but
you may lose some detail.

Way too coarse, but thank you anyway.

Fernando

 

[Wilfred]

The fact they appear on other models means what you see is not a
solution but a fudge. They have not been fixed but only *masked*.

As Fernando says, VueScan isn't able to correct aberrations in
individual cells if they're outside a certain range. This applies to
certain DSE5400 units. If the aberrations are within the limited range
VuScan can handle (as is apparently the case with my unit), correction
is just as good as Minolta's own correction, or Silverfast's. Sure, this
is a VueScan problem, not a scanner problem - I'm not suggesting
anything else.

 

[Don]

The thing I'm talking about, is per-cell calibration.
You scan an empty frame, examine the levels of the rows (single cell
outputs), and use those informations to correct the levels of the
actual scanner images.
It's the very same thing Minolta Scan Utility and Silverfast do, and
that Vuescan try to do without good success in many cases.
There is no other way to correct streaks, for you can't adjust the
gain/offset of the single sensor cell.

I don't have a Minolta so just to make sure we're talking about the
same thing: Are the lines horizontal (parallel to the CCD array) or
vertical (always the same CCD cell)? I thought there were horizontal.

If they are horizontal then, they would be inherently random and
scanning an empty frame wouldn't help much.

If they are vertical, are they always in the same place?

If yes, then indeed doing the calibration manually may help but it
would still be masking the problem rather than solving it.

If it were me, I would still like to know why this occurs at these
very places and eliminate the cause, rather than try to deal with the
effect. (For more details, see my message to Wilfred.)

Don.

 

[Don]

As Fernando says, VueScan isn't able to correct aberrations in
individual cells if they're outside a certain range.

That implies that there is a very wide variation between individual
cells. If that is the case then I would, actually, blame the scanner!

The reason is that in that case the calibration would have to be so
severe in certain cases (at both extremes of the range) that I would
call such "radical calibration" a corruption.

I don't know for sure, of course, but I doubt very much Minolta would
release units with such sub-standard parts.

If the aberrations are within the limited range
VuScan can handle (as is apparently the case with my unit), correction
is just as good as Minolta's own correction, or Silverfast's.

If it were that easy then all VueScan has to do is simply increase the
tolerances to catch the full range!? That should take seconds to fix.

I may not think much of the author's programming capabilities, but
even he should be able to figure that out!

The fact that this has been going on for two years implies to me that
the problem goes much deeper.

For example, the "calibration" algorithm VueScan uses is so bad that
extending the range (to catch all variations) would result in
unacceptable results (heavily corrupted image).

Of course, that also means that even "corrected" lines are in reality
just clumsily masked (due to the bad algorithm). Even if not visible,
I would still call such a scan corrupted.

Sure, this
is a VueScan problem, not a scanner problem - I'm not suggesting
anything else.

Given above caveats, on that we do agree.

Don.

 

[Wilfred]

I don't have a Minolta so just to make sure we're talking about the
same thing: Are the lines horizontal (parallel to the CCD array) or
vertical (always the same CCD cell)? I thought there were horizontal.

The lines I have seen correspond to 'always the same CCD cell'. On a
35mm frame viewed in landscape orientation, this is a horizontal line.
When viewed in portrait orientation (as you do, apparently), it is vertical.

If they are vertical, are they always in the same place?

Mostly, yes. Sometimes they seem to (re)appear at different locations,
which indicates that some of these lines may be caused by dust particles
inside the scanner obscuring individual cells.

 

[Kennedy McEwen]

As Fernando says, VueScan isn't able to correct aberrations in
individual cells if they're outside a certain range.

....whilst other software can. Cause of fault: Vuescan coding
excessively limited. No further debate required.

 

[Kennedy McEwen]

Mostly, yes. Sometimes they seem to (re)appear at different locations,
which indicates that some of these lines may be caused by dust
particles inside the scanner obscuring individual cells.

Or that it is just inadequate noise filtering in the Vuescan calibration
procedure, as I suggested a couple of weeks ago. Being associated with
noise they would rea-appear at random locations every time a full
calibration was performed.

 

[Fernando]

...whilst other software can. Cause of fault: Vuescan coding
excessively limited. No further debate required.

Yes, but I'd like to try some kind of post-processing fix: because for
other aspects, I really like Vuescan. Plus, I can only use Vuescan to
drive my Polaroid, since it's attached to a Linux box.

Kennedy, do you have any suggestion about a procedure (even an
abstract one!) that, working on Vuescan raw files and a "dark scan",
could re-equalize the output from the sensor?

Thanks!

Fernando