D
Don
Or, more importantly, we don't have software with this... ahem...
"problem". ;o)
Don.
Or, more importantly, we don't have software with this... ahem...
"problem". ;o)
Don.
W
Wilfred
Don said:
Have a look at the 'The classic (mostly green) lines' thread. The
original poster reports scan lines appearing in the Minolta software. He
is not talking about VueScan (!)
B
Bart van der Wolf
Wilfred said:
And thus "Don" ends up with his foot in his mouth, again.
Bart
F
Fernando
Hi Bart!
If you happen to have spare time O
, I would be very happy to know if
the dark frame subtraction utility works for you.
As for now, I'm the only tester...
Fernando
If you happen to have spare time O
, I would be very happy to know ifthe dark frame subtraction utility works for you.
As for now, I'm the only tester...
Fernando
D
Don
And neither am I!!
The fact that you and Bart would think I am only proves my point how
insecure and paranoid some VueScan users seem to be. Must be all those
bugs that make you lot so edgy...
(BTW, now that you brought it up, that *does* refer to VueScan!)
Don.
D
Don
Frustrated by your inability to respond to any of the hard facts you
have now reduced yourself to sniping from the sidelines? I really
expected more from you, Bart. I really did.
As you will have seen from my response to Wilfred, you spoke a little
bit too soon... Touchy, indeed!
So, I'm afraid, the shoe is firmly on the other foot, or in this case,
the foot is firmly in the other mouth. ;o)
Don.
D
Don
Hi Bart!
If you happen to have spare time O
Apparently not... He seems to be too obsessed lately with stalking
"Don"... ;o)
Don.
P.S. Sorry, couldn't resist... ;o)
W
Wilfred
Don said:
Not explicitly. Formally, indeed, it could be that you were comparing
NikonScan with the Minolta Dimage Scan Utility and that you were
suggesting that 'we' (NikonScan users) don't have software with this
problem. However, it seems unlikely to me because most (if not all) of
your postings regarding the Minolta 5400 have the intent of warning its
users against VueScan, telling them that the software supplied by the
manufacturer is likely to be a better choice.
If your new gospel says that the Minolta software isn't good either,
then in fact, you could be more explicit - the only option seems to be
SilverFast but AFAIK you don't have experience with SilverFast, so
what's your point?
And please don't misinterpret me - I'm not saying that VueScan (or any
software) is the best software for the Minolta 5400. However I do
recognize that it has certain advantages over the Minolta Dimage Scan
Utility. I've never used SilverFast; the only thing I'm sure of is that
it's much more expensive than the other options, for that's an
irrefutable fact.
F
Fernando
I just did an interesting test.
I used a dark frame scan from last week (Vuescan 8.1.35, BTW) and a
raw image scan from a few minutes ago (Vuescan 8.1.38), of course same
exposure.
I was expecting worse results since the scanner heating was different,
and even Vuescan was a newer version (with allegedly "better
calibration" for the 5400); but despite that, it turned out that the
dark frame subtraction was quite effective nonetheless!
http://gundam.srd.it/PhotoPages/images/5400_vuescan_darkframesub_03.jpg
I bumped up the shadows a bit on both pictures (by the very same
amount) because the image required it.
So it seems like it's not mandatory to perform a dark scan just after
(or just before) the actual image scan.
Comments are welcome.
Fernando
K
Kennedy McEwen
It may be just my imagination or my memory playing tricks, but theFernando said:
latest dark frame subtraction image (albeit with last week's dark
frame!) looks a mighty bit cleaner than the results you posted last
week. There is just the merest trace of a residual effect - and I am
not sure that isn't noise modulation rather than a genuine pixel offset.
If this really is with a week old dark reference, I would hazard a guess
that Vuescan isn't actually doing anything at all - which just happens
to have turned out to be what it is doing with the Nikon scanners!
F
Fernando
Kennedy said:
offset.
I'm rather please, too!
My first test from last week (subtraction with Photoshop, no dark scan
averaging):
http://gundam.srd.it/PhotoPages/images/5400_vuescan_darkframesub_01.jpg
My second test from last week (subtraction with Photoshop, having
applied 8 times the custom averaging filter):
http://gundam.srd.it/PhotoPages/images/5400_vuescan_darkframesub_02.jpg
Same dark frame scan, new image scan, using the new utility (that
averages the scan across the whole length):
http://gundam.srd.it/PhotoPages/images/5400_vuescan_darkframesub_03.jpg
This evening I'll perform a new test with a new dark frame (scanned
just before the actual scan).
Vuescan calibration for sure does nothing on my Polaroid SS120, Epson
2450, Epson 4180.
On the SE5400, I really can't understand why it works well on some
units and not on some others...!
Hamrick keeps writing "improved calibration" in the Changelog, also for
8.1.38, but the streaks are still here on my unit...
Ed did not reply to my email about the dark frame subtraction tests.
Fernando
B
Bart van der Wolf
Fernando said:Hi Bart!
If you happen to have spare time O
if
the dark frame subtraction utility works for you.
As for now, I'm the only tester...
Hi Fer,
I'm a bit busy with some other stuff, but I'll give it a try soon.
Bart
D
Don
Exactly!! That's the only *rational* explanation given the context.
That's a jump you made based on your own emotional overreaction.
For your "proof" you not only ignored the current context but had to
go to a totally unrelated thread (!). To any calm, objective person
that would've been a warning sign that the "conclusion" is wrong.
The point is, in spite of its warts, NikonScan still comes ahead of
Minolta software - at least the early Minolta versions before they got
the calibration right.
The second point (you and Bart so clearly demonstrated) is that some
VueScan "fans" have a big chip on their shoulder and are very eager to
misinterpret and misconstrue any statement that even remotely may be
seen as an mere indirect criticism of the (holly) VueScan.
If they were truly happy, they would shrug their shoulders (even at
explicit criticism!) and continue using it. But the fact they stalk
the group for any (in their hypersensitive mind) "criticism" of
VueScan in order to jump on it shows huge insecurity and paranoia.
I'm very sad to see you and Bart join this group. I know you may not
believe me, but I really am, because I value both your's and Bart's
other contributions and it's sad to see you reduce yourselves to this.
Yes, VueScan can divorce the Grain Dissolver from ICE (a really dumb
Minolta decision) but that pales by comparison and you pay for it with
many other VueScan problems, mainly that's it's buggy and unreliable.
Of course, each user has to decide what's important to them, but if
they do care for any semblance of quality then, I'm sorry, but it's
been demonstrated here daily that VueScan is just too flimsy to be
useful for any even remotely serious work.
Don.
B
Bart van der Wolf
Don said:
You think too much of yourself, I only see your posts (which get
automatically deleted by my newsreader due to lack of useful content)
when they are responded to by others. It improves the S/N ratio
considerably.
Running the DFsub.exe invokes an error message on my system
(CORE_RL_magick_.dll was not found). I'll take some debugging to find
a way to get it to run, and I have to finish a few other time
consuming jobs before Saturday.
Bart
W
Wilfred
Don wrote:
If you were truly happy, you would shrug your shoulders (even at
explicit praise of VueScan) and continue not using it. But the fact that
you stalk the group for any (in your hypersensitive mind) message
containing the word 'VueScan' in order to jump on it shows a huge
superiority complex (in that you think your mission is to save the world
from VueScan), chronic obsession and pathetic paranoia.
If you would reduce your mission so as to prevent people from paying for
VueScan before they know if they like it, it would be OK for me. In that
respect I think Ed Hamrick's policy that one can only try the full
version after having paid is wrong.
If you were truly happy, you would shrug your shoulders (even at
explicit praise of VueScan) and continue not using it. But the fact that
you stalk the group for any (in your hypersensitive mind) message
containing the word 'VueScan' in order to jump on it shows a huge
superiority complex (in that you think your mission is to save the world
from VueScan), chronic obsession and pathetic paranoia.
If you would reduce your mission so as to prevent people from paying for
VueScan before they know if they like it, it would be OK for me. In that
respect I think Ed Hamrick's policy that one can only try the full
version after having paid is wrong.
F
Fernando
Bart, you need to install the ImageMagick Windows runtimes
(www.imagemagick.net), I said that in the NG message and in the
README; if the ImageMagick installation works, it should find the DLLs
automatically, wherever they are.
But please take your time! I certainly don't want you to wast time on
that!
Thanks,
Fernando
D
Don
If that's the case, why the urge to respond to those comments?
Don.
D
Don
What you emotionally see as "mission" are, in reality, mere objective
facts. Like this one:
How do you explain, then, my giving people the address where they can
download a trial version and make up their own minds?
Don.
B
Bart van der Wolf
SNIP
Yes, I already re-installed the DLL version of the pre-compiled
ImageMagick, and at installation time I ticked the box to include
C/C++ support. Your program is now running without error messages.
No problem.
My first DFS v0.1 run was on the Scanner Bake-off 2005 slide (Velvia),
on a Windows XP Pro SP2 platform.
I started the scanner, and used only VueScan (8.1.38) to calibrate,
then insert the slide holder, and re-calibrated again. With the Crop
area set to maximum, I did a prescan and made sure the highlights
weren't clipped too much. I also color balanced and set the black
point for later, but that shouldn't influence the Raw data. I locked
exposure, previewed and locked image color. I then scanned the image,
which took a while (no surprise at 5232x7800 pixels x 4 16-bit
channels), and saved as 64-bit TIFF. I then moved one frame (to my
dark frame slide), and scanned again with the same locked settings.
The second (Dark) frame has the following Photoshop statistics (I left
out the left most first column, which is all white, for the
statistics):
Red: mean=0.60, stddev=0.49, median=1, highest bin=3 (14 pixels)
Green: mean=0.50, stddev=0.50, median=0, highest bin=3 (4 pixels)
Blue: mean=0.87, stddev=0.36, median=1, highest bin=3 (148 pixels)
So I have basically 1-bit out of 16 dark noise.
There were no noticeable lines at gamma 1 or after gamma 2.2
adjustment (on an 8-bit/channel CRT), unless levels were applied. The
slide scan itself revealed 1 darker line I could find in a dark
shadow, but on earlier scans I have also seen, say, 3 lighter lines.
Either my scanner is less sensitive to the issue, which I find hard to
believe because I have seen the faint lines before in other scans, or
Ed Hamrick recently did improve the calibration ...
Anyway, I couldn't find the 1 darker line anymore after running your
DFS, and the noise was a bit more visible but that was to be expected
after DFS. I'll have to run a few more tests at different levels of
scanner heat up, and perhaps with older versions of VueScan, but I
experienced no real issues with your DFS utillity.
The C code looks well written and commented, and seems easy to follow
as I read it superficially. It ran with little impact (<10%) on the
processor cycles, but did slow down system response (high priority
process), maybe due to Hard Drive activity.
Now, since I also did some C programming several moons ago, allow me
to make a few small programming/flow suggestions (I loved the profiler
for code optimization).
Obviously, when you've figured out how to read the relevant tags from
the TIFF header (I know you were in a hurry for version 0.1), there
should be no need to specify the number of channels for the source
file and the dark file on the command line.
Next, your program first reads the source file, then the dark file,
and then calculates the dark average. Although I didn't have any
problems with my two 311 MB files in a limited amount of available
memory, I'd prefer reading the dark file first, calculate the average,
and release the dark frame's memory leaving the average, and then read
the Source file. That will reduce the memory requirements to almost
half. The sequence on the command line is still logical, but you don't
have to execute in the same order.
I'll study the Averaging function a bit further to see if I can
suggest improvements. On an earlier investigation, I also discovered a
small regular ripple in dark areas, which indicates that the columns
aren't constant but fluctuate with a small amplitude sinusoid around
an average.
So far my initial impressions, kudos for a fast hack well done.
Bart
Yes, I already re-installed the DLL version of the pre-compiled
ImageMagick, and at installation time I ticked the box to include
C/C++ support. Your program is now running without error messages.
No problem.
My first DFS v0.1 run was on the Scanner Bake-off 2005 slide (Velvia),
on a Windows XP Pro SP2 platform.
I started the scanner, and used only VueScan (8.1.38) to calibrate,
then insert the slide holder, and re-calibrated again. With the Crop
area set to maximum, I did a prescan and made sure the highlights
weren't clipped too much. I also color balanced and set the black
point for later, but that shouldn't influence the Raw data. I locked
exposure, previewed and locked image color. I then scanned the image,
which took a while (no surprise at 5232x7800 pixels x 4 16-bit
channels), and saved as 64-bit TIFF. I then moved one frame (to my
dark frame slide), and scanned again with the same locked settings.
The second (Dark) frame has the following Photoshop statistics (I left
out the left most first column, which is all white, for the
statistics):
Red: mean=0.60, stddev=0.49, median=1, highest bin=3 (14 pixels)
Green: mean=0.50, stddev=0.50, median=0, highest bin=3 (4 pixels)
Blue: mean=0.87, stddev=0.36, median=1, highest bin=3 (148 pixels)
So I have basically 1-bit out of 16 dark noise.
There were no noticeable lines at gamma 1 or after gamma 2.2
adjustment (on an 8-bit/channel CRT), unless levels were applied. The
slide scan itself revealed 1 darker line I could find in a dark
shadow, but on earlier scans I have also seen, say, 3 lighter lines.
Either my scanner is less sensitive to the issue, which I find hard to
believe because I have seen the faint lines before in other scans, or
Ed Hamrick recently did improve the calibration ...
Anyway, I couldn't find the 1 darker line anymore after running your
DFS, and the noise was a bit more visible but that was to be expected
after DFS. I'll have to run a few more tests at different levels of
scanner heat up, and perhaps with older versions of VueScan, but I
experienced no real issues with your DFS utillity.
The C code looks well written and commented, and seems easy to follow
as I read it superficially. It ran with little impact (<10%) on the
processor cycles, but did slow down system response (high priority
process), maybe due to Hard Drive activity.
Now, since I also did some C programming several moons ago, allow me
to make a few small programming/flow suggestions (I loved the profiler
for code optimization).
Obviously, when you've figured out how to read the relevant tags from
the TIFF header (I know you were in a hurry for version 0.1), there
should be no need to specify the number of channels for the source
file and the dark file on the command line.
Next, your program first reads the source file, then the dark file,
and then calculates the dark average. Although I didn't have any
problems with my two 311 MB files in a limited amount of available
memory, I'd prefer reading the dark file first, calculate the average,
and release the dark frame's memory leaving the average, and then read
the Source file. That will reduce the memory requirements to almost
half. The sequence on the command line is still logical, but you don't
have to execute in the same order.
I'll study the Averaging function a bit further to see if I can
suggest improvements. On an earlier investigation, I also discovered a
small regular ripple in dark areas, which indicates that the columns
aren't constant but fluctuate with a small amplitude sinusoid around
an average.
So far my initial impressions, kudos for a fast hack well done.
Bart
W
Wilfred
Don said:
That's good. But my suggestion was that giving this address should be
your *only* contribution to the VueScan discussion;-)
On the other hand, most of us know that free downloadable version is
crippled, at least for people interested in the full version. But I
think we already agree on this.