Vuescan appears to be using "nearest neighbour" for downsampling
Mendel Leisk
downsampling, when used in the scan-from-disk process. At least the
result is similar to that process as done through Photoshop.
During scan-from-disk within Vuescan, downsampling is accomplished by
setting "Input|Scan(Preview) Resolution" to "Custom", and then setting
a number. In my case, I worked with raw files having dpi set to 5400.
By setting the custom dpi to 4000 during scan-from-disk, I downsampled
by 4000/5400.
Unfortunately, I've gotten a fair way into my project now, when I
happened to try a bi-cubic downsample of the raw file, through
Photoshop. Zooming both to 200%, serious "jaggies" are evident in the
Vuescan result, whlle Photoshop's bicubic output is much smoother.
Groan!
Winfried
That's not new. It is well documented:
"You can use this option to write files with a reduced number of
pixels. For instance, if size reduction is set to 3, then every 3x3
block of pixels in the image will be written as a single pixel, which
is the average of these 9 pixels."
Winfried
Mendel Leisk
setting is set in:
Input|Preview Resolution (I've activated "scan from preview")
In that page of the help file the description is:
If set to "Custom", the resolution is selected by the "Input|Preview
dpi" option
Even if the help file did go into more detail, on the Input tab
setting, I'd still be in the dark. I really did not understand the
downsampling options, and their impact, and am just getting an inkling
now.
Just from reviewing the two results, I think Vuescan is not the place
to be downsampling, Your results will look much better under close
scrutiny if you use Photoshop's bi-cubic.
Winfried
That's right.
But it is better to scan at 4000 dpi and downsample to 2000 dpi in
VueScan than scanning with 2000 dpi from the beginning.
Therefor I normaly scan at full resolution (at least with
slides/negatives).
Of course if I use a flatbed as a copy maschine I use 300 dpi.
Winfried
Bart van der Wolf
"Mendel Leisk" <mendel_le...@hotmail.com> wrote in message
news:1111866926.0...@z14g2000cwz.googlegroups.com...
> Just a heads-up, Vuescan appears to be using "nearest neighbour"
> for downsampling, when used in the scan-from-disk process. At
> least the result is similar to that process as done through
> Photoshop.
> ... , when I happened to try a bi-cubic downsample of the raw file,
> through Photoshop. Zooming both to 200%, serious "jaggies" are
> evident in the Vuescan result, whlle Photoshop's bicubic output is
> much smoother.
It was answered by Ed Hamrick (long before he was driven away from
this group by a few VueScan bashers) that he uses a bi-linear kind of
interpolation:
<http://www.google.com/groups?selm=ath46e%24kgt%241%40ngspool-d02.news.aol.com>
Good down-sampling uses a better kind of method, but it is relatively
(computationally) expensive. If you want the best results, don't even
use Photoshop but "ImageMagick" for downsampling. I have not found a
better method than their implementation of a CatRom, Lanczos, or Sinc
filtered down-sampling.
<http://www.xs4all.nl/~bvdwolf/main/foto/down_sample/down_sample.htm>
It offers the best compromise between aliasing and resolution,
followed by Mitchell and Bessel but at the expense of some resolution,
while their Cubic filter suppresses virtually all aliasing risk, but
at further loss of resolution.
If you want to use photoshop because it better suits your workflow,
then don't follow Adobe's Bi-cubic "sharper" recommendation, but just
use regular Bi-cubic:
<http://www.xs4all.nl/~bvdwolf/main/foto/down_sample/example1.htm>
The best results depend on the input signal, so the above mentioned
pre-filter methods should allow you to pick the best for your purpose.
Bart
Mendel Leisk
I'll try some of these. The big hassle for me is 200+ meg files from my
Elite 5400. Taking them down to 4000ppi cuts the file size almost in
half.
>From observation, I think the Vuescan downsample is closer to PS's
"nearest neighbour" than PS's "bi-linear". This is looking at well
defined diagonal edges, at 200% zoom.
Bart van der Wolf
> Thanks for the links/tips, Bart. Before I do ANY more
> downsampling, I'll try some of these. The big hassle for
> me is 200+ meg files from my Elite 5400.
You're welcome. Yes, the 5400 produces huge files (2 or 3 per CD,
depending on 48/64-bit).
> Taking them down to 4000ppi cuts the file size almost
> in half.
It all depends on the resolution in the original film image, and the
intended use.
If your original film image does resolve lots of detail (detailed
subject + good lens + low ISO film + good technique / tripod / mirror
lockup) the 5400 ppi scan will almost catch all there is in terms of
resolution. Down-sampling can lose real resolution, if it is there to
begin with in the film image.
If there is less detail, i.e. subject / lens / tripod limitations,
then down-sampling will not hurt available resolution much, but it
will benefit the S/N ratio. Both scanner noise and film graininess
will improve, but only if the down-sampling algorithm doesn't increase
grain-aliasing too much. That will require a good down-sampling
algorithm.
The file size reduction will also allow to store more images, and
lower noise images will also compress better.
Bart
Erik Krause
> Good down-sampling uses a better kind of method, but it is relatively
> (computationally) expensive. If you want the best results, don't even
> use Photoshop but "ImageMagick" for downsampling. I have not found a
> better method than their implementation of a CatRom, Lanczos, or Sinc
> filtered down-sampling.
The Panorama Tools have the same or better interpolators but the best
(to my knowledge) has QImage - although I must admit that I never tried
it for downsampling. However, it does a superb upsampling. Here a
comparison of Fred Miranda's Resize Pro to QImage:
http://www.ddisoftware.com/testpics/p-rp.jpg
--
Erik Krause
Digital contrast problems: http://www.erik-krause.de/contrast
Kennedy McEwen
<bvd...@no.spam> writes
>
>It was answered by Ed Hamrick (long before he was driven away from this
>group by a few VueScan bashers) that he uses a bi-linear kind of
>interpolation:
><http://www.google.com/groups?selm=ath46e%24kgt%241%40ngspool-d02.news.aol.com>
>
It either is bi-linear or it isn't bi-linear.
Ed's description of his algorithm is akin to being a little bit
pregnant!
There are many different interpolation algorithms, some better, some
worse, but "bi-linear" is a very specific algorithm that Vuescan either
is or is not compliant with.
--
Kennedy
Yes, Socrates himself is particularly missed;
A lovely little thinker, but a bugger when he's pissed.
Python Philosophers (replace 'nospam' with 'kennedym' when replying)
Bart van der Wolf
"Kennedy McEwen" <r...@nospam.demon.co.uk> wrote in message
news:xPKyajAi...@kennedym.demon.co.uk...
> In article <4245df90$0$137$e4fe...@news.xs4all.nl>, Bart van der
> Wolf <bvd...@no.spam> writes
>>
>>It was answered by Ed Hamrick (long before he was driven away from
>>this group by a few VueScan bashers) that he uses a bi-linear kind
>>of interpolation:
>><http://www.google.com/groups?selm=ath46e%24kgt%241%40ngspool-d02.news.aol.com>
>>
> So what is "approximately bi-linear"?
>
> It either is bi-linear or it isn't bi-linear.
It is bi-linear, but with a twist ;-). To me it's obvious that Ed
didn't want to fully disclose his proprietary algorithm. That's fine
with me because I use my own preferences when repurposing the scanned
data. I usually scan at full native resolution, and I use Qimage's
Vector or Pyramid interpolation for significant up-sampling, and
ImageMagic's Lanczos or Sinc prefiltering for most (pictorial)
down-sampling.
Bart
Kennedy McEwen
>
>"Kennedy McEwen" <r...@nospam.demon.co.uk> wrote in message
>news:xPKyajAi...@kennedym.demon.co.uk...
>> In article <4245df90$0$137$e4fe...@news.xs4all.nl>, Bart van der
>>Wolf <bvd...@no.spam> writes
>>>
>>>It was answered by Ed Hamrick (long before he was driven away from
>>>this group by a few VueScan bashers) that he uses a bi-linear kind of
>>>interpolation:
>>><http://www.google.com/groups?selm=ath46e%24kgt%241%40ngspool-d02.news
>>>.aol.com>
>>>
>> So what is "approximately bi-linear"?
>>
>> It either is bi-linear or it isn't bi-linear.
>
>It is bi-linear, but with a twist ;-).
But without telling anyone anything about what that "twist" is, we can
only base our conclusions on the results which, as Mendel pointed out,
is grossly inferior to bilinear.
Incidentally, from around version 1.4 up to version 7, PaintShop Pro
used a twist in their "bilinear" interpolation which meant it was much
faster to compute but the results were also grossly inferior to proper
bilinear interpolation. Despite constant bug reports at every new
release, Jasc would not even so much as acknowledge the error. Only
after continual demonstration of the shortfall in every post that Kris
Zaklika made on the subject of interpolation on the PSP newsgroup were
they finally forced to fix it - with far more mud-slinging from PSP
fanatics than the Vuescan aficionados throw at its critics here, I can
assure you.
That twist? Use nearest neighbour interpolation for downsampling
throughout and when upsampling use nearest neighbour for the integer
part and linear interpolation for the fractional residue of the scaling.
So upsampling from say 100ppi to 250ppi produced 2.5 pixels for each
original, or 5 pixels from every two. Four of these were exactly the
same as the original nearest neighbours, and only the fifth was actually
produced by linear interpolation. A lot less computation, and thus
faster to implement, but far closer to nearest neighbour scaling than
bilinear!
Since they used proper bicubic interpolation when that was introduced,
presumably from a public software library rather than Jasc home baking,
the difference between the two was astounding and resulted in many PSP
users discounting bilinear as a waste of time - even when a proper
bilinear algorithm would have been perfectly adequate and much faster
than the bicubic they were forced to use.
I am not suggesting that this is the same twist as Ed has used, although
Mendel's results suggest it might be. However, misuse of these standard
algorithm terms can be very misleading - in Jasc's case deliberately so,
since they used very specific examples which concealed the deficiency
every time the topic was raised.
If it isn't bilinear then it shouldn't be called bilinear because,
whether deliberately or not, it is deceptive terminology. What Vuescan
implements is, for want of a better term, "Hamrick Interpolation", and
without reverse engineering it, we can't say precisely how close to
nearest neighbour or bilinear it actually is.
Bart van der Wolf
SNIP
> I am not suggesting that this is the same twist as Ed has used,
> although Mendel's results suggest it might be.
I believe Mendel said "Vuescan appears to be using "nearest neighbour"
for
downsampling, when used in the scan-from-disk process. At least the
result is similar to that process as done through Photoshop".
That indicated to me that there is little difference, so indeed quite
different from the earlier PSP method you described. I have not tested
it because bi-linear is vastly inferior to many other solutions
available.
If I were Ed, I would have implemented a different resampling
algorithm, but it's his program and our choice to either use the
functionality or not. Who knows, he might still change it, due to
popular demand (which caused him to add interpolation in the first
place) or as a challenge. He could use
<http://astronomy.swin.edu.au/~pbourke/analysis/interpolation/> as
inspiration ..., and maybe even add another twist of his own, like
proper lowpass prefiltering.
Bart
Kennedy McEwen
<bvd...@no.spam> writes
>
>"Kennedy McEwen" <r...@nospam.demon.co.uk> wrote in message
>news:Hekv+cDa...@kennedym.demon.co.uk...
>SNIP
>> I am not suggesting that this is the same twist as Ed has used,
>>although Mendel's results suggest it might be.
>
>I believe Mendel said "Vuescan appears to be using "nearest neighbour"
>for
>downsampling, when used in the scan-from-disk process. At least the
>result is similar to that process as done through Photoshop".
>
process as Ed has used, but calls "approximately bilinear".
>That indicated to me that there is little difference, so indeed quite
>different from the earlier PSP method you described.
Read again my description of exactly what Jasc traded off as bi-linear
interpolation for at least 4 major version issues:
>Use nearest neighbour interpolation for downsampling throughout
ie. *exactly* the same as Photoshop nearest neighbour downsampling.
>when upsampling use nearest neighbour for the integer part and linear
>interpolation for the fractional residue of the scaling.
ie. marginally distinguishable from Photoshop nearest neighbour for
scales of 2 and above.
I don't see how you can consider it to be quite different from what I
described, since it is exactly what I described for the condition that
Mendel referred to!
>I have not tested it because bi-linear is vastly inferior to many other
>solutions available.
But significantly superior to either nearest neighbour or the crap that
Jasc peddled for years under the lie of "bi-linear" and much faster
computationally than any of the more complex routines.
Mendel Leisk
test image had a bright edge of someone's face, against a dark
background, sloping slightly off vertical.
Viewing this area at 200%, with Photoshop's bi-linear and bi-cubic, the
results seemed identical, and quite smooth. Same thing with Photoshop's
nearest neighbour, I see the smooth edge breaking up into distinct
lines, creating jagged steps.
The appearance of similar area/zoom after Vuescan downsample by same
percent, looks exactly like Photoshop nearest neighbour.
This tanked about 3 months work for me :(
Bart van der Wolf
SNIP
> The appearance of similar area/zoom after Vuescan
> downsample by same percent, looks exactly like Photoshop
> nearest neighbour.
Ed possibly didn't include proper pre-filtering before down-sampling.
In fact, it wouldn't surprise me if actually he uses binning (like
with "File size reduction" which is already available), topped off by
bilinear interpolation for the remainder to reach the desired output
size, but that's just my speculation.
Almost any interpolation scheme (including bi-cubic) will produce bad
aliased results without proper preparation. It was only as recent as
Photoshop CS that Adobe improved their bicubic algorithms, and they
still didn't get it right IMHO (edge artifacts, and halo or aliasing).
The best down-sampling implementation I use, is still the free
ImageMagick one. It offers, a choice of prefilters for all sorts of
image content, and proper handling of edge pixels. The UI (commandline
or script) may be a bit daunting for some but the results rule.
Ed may have been more concerned with the speed penalty of a better
interpolation, as scans can be quite large at native resolution. I
would recommend him to take another look at it, although I personally
won't use it a lot, there may be others that do.
Bart
Mendel Leisk
I did look into the ImageMagick software you refer to. I had great
difficulty in the download/install process. What I gather is that
ImageMagick is a fairly esoteric program, requiring a fair bit of
savvy. For install on Windows system, it might involve pre-install of
another program. I did download a package and unzip it, but could not
see where to go from there.
At this point I elected to use Photoshop's bi-cubic, which you're
saying is almost as good. It holds up to close (200~300% zoom) scrutiny
to my eyes no apparent breaking up of diagonal edges.
My project is archiving family slide collections, relatively grainy,
hand held. 4000 dpi downsampling makes a tremendous reduction in
storage requirements.
With my Elite 5400 and the Minolta Scan Utility, I output a 16 bit
linear with ICE/GD enabled, at the full 5400dpi. Then inspect each file
in PS, cleaning what ICE has missed, with healing brush etc. Then
bicubic downsample to 4000. Then scan-from-disk from this file, with
Vuescan.
Don
<mendel_le...@hotmail.com> wrote:
>The appearance of similar area/zoom after Vuescan downsample by same
>percent, looks exactly like Photoshop nearest neighbour.
>
>This tanked about 3 months work for me :(
I'm just curious... You've reported a number of serious problems with
VueScan over the months. Why do still stick with it?
This is a genuine question. Are there any specific features which you
can't get elsewhere and, if so, what are they?
Don.
BTW, it's not the first time this has happened. I clearly remember a
German company a while back also with several months of work down the
tubes. Back then it was some noise VueScan introduced, I believe.
Mendel Leisk
convenient, efficient and working to my liking, and Minolta Scan
Utility and Photoshop for the areas where Vuescan is falling short. I
like the Vuescan interface, and the control. For me, it's main
shortcoming at present is the quality of infrared cleaning, and now
this downsampling issue. I would hope these issues can be resolved. In
the interm, I use what works.
Mendel Leisk
scan-from-disk concept
simple, fairly efficient, crop and rotate
scanner calibration with targets (just considering this)
fairly good white balancing
color neg film advanced workflow (just considering this)
Note, I'm by NO means a pro. I'm sure there are other avenues for most
of the above, I'm just not that advanced/knowledgable, and Vuescan,
atleast some of it, works for me.
Bart van der Wolf
SNIP
> I did look into the ImageMagick software you refer to. I
> had great difficulty in the download/install process.
>
> What I gather is that ImageMagick is a fairly esoteric
> program, requiring a fair bit of savvy. For install on
> Windows system, it might involve pre-install of another
> program. I did download a package and unzip it, but
> could not see where to go from there.
If, assuming you do work on a Windows platform, you could download
<http://prdownloads.sourceforge.net/imagemagick/ImageMagick-6.2.1-Q16-windows-dll.exe?download>,
to get the precompiled 16-bit/channel version installer (version
6.2.1).
After installation (check all features if in doubt) you can use the
command prompt (Start|Run...|cmd).
Then it'll require some old fashion typing-in of DOS commands, like CD
followed by a space to change to the directory with your images (e.g.
C:\temp). Then use the ImageMagick command "Convert" to downsample
(e.g. type: convert filename1.tif -filter sinc -resize 4000x4000
filename2.tif). That will use the "Sinc" pre-filter to resize
"filename1.tif" to "filename2.tif" and fit the longer dimension in a
4000x4000 pixel box. You can use your favorite sharpening
program/method on that and save a JPEG version.
You can also convert from TIFF to other file types, e.g. JPEG, in the
same operation by changing the second file's extention to .jpg and
also adjusting the compression quality and chroma subsampling
parameters if the defaults don't suit your goal, but issues may arise
depending on various issues.
> At this point I elected to use Photoshop's bi-cubic, which
> you're saying is almost as good. It holds up to close
> (200~300% zoom) scrutiny to my eyes no apparent
> breaking up of diagonal edges.
Yes, it's close but less than optimal, although it may be good enough
for the purpose.
> My project is archiving family slide collections, relatively
> grainy, hand held. 4000 dpi downsampling makes a
> tremendous reduction in storage requirements.
Indeed, especially if down-sampling from a 5400 ppi sampling density
(which is best to reduce graininess with the DSE-5400, with the Grain
Dissolver activated).
> With my Elite 5400 and the Minolta Scan Utility, I output
> a 16 bit linear with ICE/GD enabled, at the full 5400dpi.
> Then inspect each file in PS, cleaning what ICE has missed,
> with healing brush etc. Then bicubic downsample to 4000.
> Then scan-from-disk from this file, with Vuescan.
Sounds like a good workflow. Going from 5400 to 4000 ppi may actually
lose very little real resolution, depending on the actual captured
film resolution, although graininess will benefit from 5400 ppi +
"perfect" downsampling.
Bart
simpl...@att.net
Mendel Leisk wrote:
>
> Missed a portion of your question. Specific features I like:
>
> scan-from-disk concept
What is this?
> simple, fairly efficient, crop and rotate
Can certainly be done in PS.
> scanner calibration with targets (just considering this)
What is this?
> fairly good white balancing
Is VueScan controlling the scanner hw, or applying sw?
> color neg film advanced workflow (just considering this)
What is this?
> Note, I'm by NO means a pro. I'm sure there are other avenues for most
> of the above, I'm just not that advanced/knowledgable, and Vuescan,
> atleast some of it, works for me.
The key is that it works for you.
Don
<mendel_le...@hotmail.com> wrote:
>Missed a portion of your question. Specific features I like:
>
>scan-from-disk concept
>
>simple, fairly efficient, crop and rotate
>
>scanner calibration with targets (just considering this)
>
>fairly good white balancing
>
>color neg film advanced workflow (just considering this)
What struck me was that you do use Photoshop in postprocessing, and
all of the above (except calibration) are really editing tasks. I mean
even scan-from-disk is basically a fancy name for applying assorted
editing functions to a raw scan which can not only be done in PS but
PS has many more and better tools.
>Note, I'm by NO means a pro. I'm sure there are other avenues for most
>of the above, I'm just not that advanced/knowledgable, and Vuescan,
>atleast some of it, works for me.
Yes, a familiar UI is certainly an important point (although I don't
think VS really has a UI) but if it works for you, that's what counts.
BTW, I also forgot to ask last time. Why do you downsample? Is it just
a question of file size?
The reason I ask is because I archive my stuff at optical resolution
of the scanner. If my scanner were capable of 5400 I would certainly
like to archive at that resolution even if that meant burning a few
extra DVDs. After all display resolutions keep going up...
Don.
Mendel Leisk
> Mendel Leisk wrote:
> >
> > Missed a portion of your question. Specific features I like:
> >
> > scan-from-disk concept
>
> What is this?
Read Vuescan help file, available online.
>
> > simple, fairly efficient, crop and rotate
>
> Can certainly be done in PS.
Yes.
>
> > scanner calibration with targets (just considering this)
>
> What is this?
Read Vuescan help file, available online.
>
> > fairly good white balancing
>
> Is VueScan controlling the scanner hw, or applying sw?
Software.
>
> > color neg film advanced workflow (just considering this)
>
> What is this?
Read Vuescan help file, available online.
>
> > Note, I'm by NO means a pro. I'm sure there are other avenues for most
> > of the above, I'm just not that advanced/knowledgable, and Vuescan,
> > atleast some of it, works for me.
>
> The key is that it works for you.
Yup! Well, until I get a nasty little suprise, like the downsample method it uses.
Mendel Leisk
Downsample was not an easy decision. I know full well, 'bout the time
I finish, hard drive and dvd size will be doubled.
I'm scanning somewhere north of 2000 slides. With downsample to
4000dpi (and crop of black edges), they'll JUST about fit on my
(mirrored) 250gig drives. That is 16 bit rgb tiffs. They are
grainy/handheld/mixed quality. I want to do them all, don't want to
cull. At 4000dpi, it will take about 50 dvd's for the raws.
I looked long and hard at the difference, and decided I could live
with the reduced zoomability. Usually, zoomed into 100% at 5400dpi,
I'm looking at some very well defined grain on a softening subject.
Kennedy McEwen
Leisk <mendel_le...@hotmail.com> writes
>
>I'm scanning somewhere north of 2000 slides. With downsample to
>4000dpi (and crop of black edges), they'll JUST about fit on my
>(mirrored) 250gig drives. That is 16 bit rgb tiffs. They are
>grainy/handheld/mixed quality.
Mendel, if they are grainy images then there is little, if anything,
being gained in saving these as 16-bit per channel. (Assuming that is
what you meant instead of 16-bit 64k colour (ie. 5-6-5 r-g-b) tiff,
since the numbers tie up at 4000ppi 16-bpc with each file around 125Mb).
You may as well half the file size by archiving them in 8-bit per
channel. You will also find that they compress much better as well,
using lossless LZW, when only 8-bit for the very reason that all of that
additional bit depth is just noise - not scanner noise, but noise on the
actual image recorded on film.
I would recommend scanning in 16-bits and then contrast stretching the
image so that the peaks are retained without clipping (so that no useful
image information is lost). Then reduce the bit depth to 8-bits and
save. The Minolta software probably has a function to implement the
stretching with minimum clipping in any case, making this a simple
operation. But if you use Vuescan then the same capability is there and
you can completely avoid the downsampling issue.
I suspect that using this approach you will get more images stored at
full resolution than you will achieve by downsampling and storing at
16-bits per channel, simply due to the improved efficiency of the LZW
algorithm once the noise content has been reduced. It all depends on
how grainy the images are to begin with though.
Mendel Leisk
stick with my Vuescan scan-from-disk workflow. I appreciate that if I
convert to 8 bit I've instantly cut my file size in half.
Back a few years, I tried converting some of my Vuescan Raw Files from
16 bit to 8 bit and found degraded smoothness of tonality when doing
scan-from-disk.
The files I'm working with now are Minolta's 16bit linear output, which
(I believe) are akin to a Vuescan raw file, and can be used as such.
Accordingly, I shy away from converting them to 8 bit, or doing any
adjustment of histogram. I suspect scan-from-disk output from an 8 bit
conversion would show degration of smooth tone.
The earlier Vuescan raws I produced were of Tri-X, scanned with a Dual
II. With them, LZW usually compressed around 4/5. Now, with my Elite
5400 and 16bit linear files, LZW compression has a negative impact on
size, they go up in size. Quite a bit if I do the process thru PS,
marginally if through Vuescan. The latter by doing scan-from-disk and
outputting a new raw file with lzw on.
I gather the poor compression is due to the grittty nature of the
scans. With my earlier lzw compressed Vuescan raw files from Tri-X, I
could always tell when I'd done a gross mis-focus. The lzw compression
ratio shot up.
Kennedy McEwen
Mendel Leisk <mendel_le...@hotmail.com> writes
>I suppose the reason I'm saving 16 bit per channel red/green/blue is to
>stick with my Vuescan scan-from-disk workflow.
Why do you consider that to be important?
Scan from disk is no more than an alternative input into Vuescan - in
fact it is just another name for the File Open function in any image
editing application. Vuescan is a data capture application, and
performs those editing functions that it provides with less capability
than a proper image editing application - as you have now discovered.
> I appreciate that if I
>convert to 8 bit I've instantly cut my file size in half.
>
>Back a few years, I tried converting some of my Vuescan Raw Files from
>16 bit to 8 bit and found degraded smoothness of tonality when doing
>scan-from-disk.
>
>The files I'm working with now are Minolta's 16bit linear output, which
>(I believe) are akin to a Vuescan raw file, and can be used as such.
>Accordingly, I shy away from converting them to 8 bit, or doing any
>adjustment of histogram. I suspect scan-from-disk output from an 8 bit
>conversion would show degration of smooth tone.
>
It certainly would if you save it as linear output, since you are
failing to utilise, or take any advantage of, perceptual space -
consequently you are storing much more information in the highlights of
your scan than you can possibly ever see and, in the case of grainy
originals, ever use.
Convert the images to a gamma compensation of around 2.2, which has an
equivalent dynamic range of more than 16-bit linear with equal spacing
of the levels throughout the range. Stretch the histogram to achieve
maximum contrast without clipping any data and then reduce this to
8-bits. The resultant file will contain all of the image information
that can be perceived, especially from a grainy original.
If you insist on using Vuescan for certain editing functions, tell it to
use the embedded colorspace profile when reading the file from disk.
Scanning raw in linear space is simply wasting resources - indeed the
only reason the data is in linear space to begin with is because it is
sourced from a CCD scanner!
Mendel Leisk
two examples of the stuff I'm scanning. One at 5400, one downsampled to
4000. They're in the folder "Downsampled etcetera"
http://www.photo.net/shared/community-member?user_id=517754
I believe you HAVE to be a logged-in member for the link to show the
pics. May work, may not.
Please, any and all, have a look if you can find it, and I would
appreciate opinions. I think the grainy/soft slides I'm doing don't
really suffer from the bicubic downsample, but any comments welcome.
Thanks.
Don
Leisk) wrote:
>> BTW, I also forgot to ask last time. Why do you downsample? Is it just
>> a question of file size?
>>
>> The reason I ask is because I archive my stuff at optical resolution
>> of the scanner. If my scanner were capable of 5400 I would certainly
>> like to archive at that resolution even if that meant burning a few
>> extra DVDs. After all display resolutions keep going up...
>>
>> Don.
>
>Downsample was not an easy decision. I know full well, 'bout the time
>I finish, hard drive and dvd size will be doubled.
>
>I'm scanning somewhere north of 2000 slides. With downsample to
>4000dpi (and crop of black edges), they'll JUST about fit on my
>(mirrored) 250gig drives. That is 16 bit rgb tiffs. They are
>grainy/handheld/mixed quality. I want to do them all, don't want to
>cull. At 4000dpi, it will take about 50 dvd's for the raws.
>
>I looked long and hard at the difference, and decided I could live
>with the reduced zoomability. Usually, zoomed into 100% at 5400dpi,
>I'm looking at some very well defined grain on a softening subject.
I know exactly what you're going through because I'm battling the same
demons... :-(
I have about 1250 slides, another 750 negatives and about 1000 photos
for a total of some 3000 images. I also don't want to cull but want to
preserve everything. I was also hoping to fit it all on one drive but
gave up since I got the LS-50 and went from 2700 dpi to 4000 dpi
native resolution.
To make matter worse, since virtually all those slides are Kodachromes
and I twin-scan, I would really like to keep both scans (nominal and
shadow-boosted) as digital negatives. That alone doubles the slide
requirements... Sigh...
Add to that all the documents I will be scanning on my flatbed
(letters, etc) and I think that nice aluminum CD box for 300 DVDs I
saw in the store the other day may just be the ticket!
You're right about the drives, though. When I started, the largest
drive at my local shop was 160 GB, but I have since got a 250 GB as
well. In the meantime dual layer DVD burners are standard and I hear
that in Japan "Blue Ray" DVDs for HDTV have already been introduced
with ~30 GB capacity, or thereabouts.
Don.
simpl...@att.net
Kennedy McEwen wrote:
>
> In article <1113272597.6...@g14g2000cwa.googlegroups.com>,
> Mendel Leisk <mendel_le...@hotmail.com> writes
> >I suppose the reason I'm saving 16 bit per channel red/green/blue is to
> >stick with my Vuescan scan-from-disk workflow.
>
> Why do you consider that to be important?
>
> Scan from disk is no more than an alternative input into Vuescan - in
> fact it is just another name for the File Open function in any image
> editing application. Vuescan is a data capture application, and
> performs those editing functions that it provides with less capability
> than a proper image editing application - as you have now discovered.
I have been mystified by this "Vuescan scan-from-disk workflow" for
quite awhile. Thank you and Don for clarifying this.
On a slightly different topic. Is a digital camera's "camera raw"
similar in this regard? That is, the camera captures an image (like a
scanner's hw captures a scan), and then the image (or scan) is processed
by sw (i.e. camera raw) for better results?
Kennedy McEwen
It depends on the camera what is actually output as "raw".
The situation is slightly different with digital cameras in any case,
because they do not capture true rgb for each pixel, but interleave the
primary colours in a Bayer matrix. So each pixel only captures either
red or green or blue (plus a little of the other colours due to filter
leakages).
The camera software is then responsible for converting this into rgb at
each pixel using some fairly complex interpolation schemes. Some of the
better ones actually use the leaked sensitivity to adjacent colours as
part of the colour correction matrix in that interpolation, so that you
actually get more resolution out of the camera than a perfect rgbg Bayer
matrix would nominally permit. So you need some of that software to
actually get a raw image that you can store and subsequently process in
the first place.
Other cameras use a proprietary raw format so that they simply store the
Bayer data, and this can only be read by their proprietary software
because it needs to convert that data into a standard form before
further processing can be implemented, either in an editor or the
manufacturer's application.