VueScan became slower with 8.1.24?

  • Thread starter Thread starter olegk
  • Start date Start date
O

olegk

I'm using Vuescan with Minolta Dimage Scan Elite 2 for several years.
My usual workflow is based on scan-from-preview:
- the computer has 768 Mb of physical memory - 6 full-resolution frames
fit into it;
- enable 512Mb memory for previews in Vuescan - so that all 6 frames
fit;
- preview all 6-frame strip at full resolution (2820 dpi);
- one frame at a time: set colors and crop, save a frame

This is the fastest workflow, you may check if you like. I do miss
multi-sample here though.

With the older Vuescan versions (the last I had was 8.1.12), all the
frames did sit in the physical memory, and going from frame to frame
took ~5 seconds - there was no disk read. With 8.1.24, it always goes
to disk, even if only 2 frames are previewed. It now takes 15-20
seconds to switch frames, and it's the time when I sit and stare at the
monitor like an idiot.
 
olegk said:
I'm using Vuescan with Minolta Dimage Scan Elite 2 for several years.
My usual workflow is based on scan-from-preview:
- the computer has 768 Mb of physical memory - 6 full-resolution frames
fit into it;
- enable 512Mb memory for previews in Vuescan - so that all 6 frames
fit;
- preview all 6-frame strip at full resolution (2820 dpi);
- one frame at a time: set colors and crop, save a frame

This is the fastest workflow, you may check if you like. I do miss
multi-sample here though.

With the older Vuescan versions (the last I had was 8.1.12), all the
frames did sit in the physical memory, and going from frame to frame
took ~5 seconds - there was no disk read. With 8.1.24, it always goes
to disk, even if only 2 frames are previewed. It now takes 15-20
seconds to switch frames, and it's the time when I sit and stare at the
monitor like an idiot.
Click to expand...

Somewhere around recent version .20 "something bad happened" to Vuescan
speed. Since then, several new version descriptions have promised
greatly improved speed etc. Atleast as of .23, my personal experience
is it's still very pokey.

I'm using 8.1.4 which is still speedy, and see no need to upgrade.
There may be places around the net where you can get older versions,
not sure.
 
Somewhere around recent version .20 "something bad happened" to Vuescan
speed. Since then, several new version descriptions have promised
greatly improved speed etc. Atleast as of .23, my personal experience
is it's still very pokey.
Click to expand...

I also noticed reduced speed, especially in rebuidling the preview.
According to Ed Hamrick, my custom monitor profile is probably to blame
for this. He claims that custom monitor profiles can significantly
reduce refresh speeds.
Unfortunately I just installed this Spyder which created the profile
around the same time when VS 8.1.20 appeared, so I don't know if it's
just this particular type of profile or what VueScan does with monitor
profiles since 8.1.20 (has it changed?). Before the Spyder profile I
used a custom profile based on visual 'calibration'. Could it be that
the latter profile is matrix-based while the Spyder profile is
table-based? AFAIK, VueScan doesn't like table-based profiles ...
 
profiles since 8.1.20 (has it changed?). Before the Spyder profile I
used a custom profile based on visual 'calibration'. Could it be that
the latter profile is matrix-based while the Spyder profile is
table-based? AFAIK, VueScan doesn't like table-based profiles ...
Click to expand...

It's not that Vuescan does not love table-based profile (for
*monitors*, I mean), it's that large table-based profiles like the
ones created by the Spyder (I have it, too) are math-intensive. Big
lookup table, high degree of interpolating polynomial, and so.
Matrix-based profiles are much lighter for the processor to evaluate.
For slower processors this indeed could hurt display refresh
performances.

Fernando
 
I haven't changed anything lately. It's Vuescan that got slower. It
ticks me that the next few releases after .20 keep trumpetting improved
refresh rate etc, when reality is it took a BIG hit to begin with.
 
Mendel said:
I haven't changed anything lately. It's Vuescan that got slower. It
ticks me that the next few releases after .20 keep trumpetting improved
refresh rate etc, when reality is it took a BIG hit to begin with.
Click to expand...
Must be republicans!
Frank
 
I don't use custom monitor profile; it's set to sRGB instead. And so it
was previously. It's Vuescan that slowed down.
 
Fernando said:
It's not that Vuescan does not love table-based profile (for
*monitors*, I mean), it's that large table-based profiles like the
ones created by the Spyder (I have it, too) are math-intensive. Big
lookup table, high degree of interpolating polynomial, and so.
Matrix-based profiles are much lighter for the processor to evaluate.
For slower processors this indeed could hurt display refresh
performances.
Click to expand...

Is there a way to simplify the Spyder profile, e.g. for VueScan use
only? I can imagine that it would be possible to reduce the number of
entries in the table, or to convert it to an approxmating matrix profile ...
Outside VueScan I did not notice anything on my computer slowing down
since I installed the Spyder.
 
Is there a way to simplify the Spyder profile, e.g. for VueScan use
only?
Click to expand...

Not with the basic ColorPlus software.
I don't know if OptiCal allows choosing the profile complexity/type...
Outside VueScan I did not notice anything on my computer slowing down
since I installed the Spyder.
Click to expand...

There aren't many applications that actually use a monitor profile,
outside Photoshop, Illustrator etc.
Even Paint Shop Pro (up to 8.0 at least) does ignore the monitor
profile; so does Internet Explorer, Office and the majority of PC
applications.
My Photoshop CS refresh performances are indeed a bit worse when a
monitor profile is loaded; and Adobe "ACE" color management engine is
very powerful and fast.

Besides, I see a slowdown in Vuescan not in the display refresh
department (I have to say that I use custom monitor profiles since a
lot), but in the final processing stage and file saving. Quite slow
indeed, and my PC is no slouch (Barton 3200+ with 1.5GB DDR-400).

Fernando
 
Fernando said:
Not with the basic ColorPlus software.
I don't know if OptiCal allows choosing the profile complexity/type...
Click to expand...

That's a pity.
There aren't many applications that actually use a monitor profile,
outside Photoshop, Illustrator etc.
Even Paint Shop Pro (up to 8.0 at least) does ignore the monitor
profile; so does Internet Explorer, Office and the majority of PC
applications.
Click to expand...

Yes, that's probably true for a Windows PC but it isn't for a Mac (which
is what I'm using with VueScan). I suspect that the Mac's OS and its
processor are somehow optimized for dealing with color profiles, while
VueScan - being a multi-platform program - probably doesn't benefit from
certain shortcuts that the Mac platform offers.
My Photoshop CS refresh performances are indeed a bit worse when a
monitor profile is loaded; and Adobe "ACE" color management engine is
very powerful and fast.

Besides, I see a slowdown in Vuescan not in the display refresh
department (I have to say that I use custom monitor profiles since a
lot), but in the final processing stage and file saving. Quite slow
indeed, and my PC is no slouch (Barton 3200+ with 1.5GB DDR-400).
Click to expand...

But are you saving our files in your monitor color space? I guess that
unless that's what you're doing, VueScan only uses the monitor profile
for displaying the images in the Preview and Scan tabs.
What about the profiles typically used for saving files, such as Adobe
RGB and Wid Gamut RGB? Are these also complex table-based profiles?
 
But are you saving our files in your monitor color space?
Click to expand...

No, it's not appropriate for that.
I save them in AdobeRGB.
What about the profiles typically used for saving files, such as Adobe
RGB and Wid Gamut RGB? Are these also complex table-based profiles?
Click to expand...

No, they are simple matrix profiles (illuminant, white point, basic
primaries coordinates,...). So the slowdown during the final passes
("Color..." and "Saving...") should come from some other change...?

Fernando
 
Back
Top