multi-scanning
Frederic
read the CCD 4 times at each pixel position, you get effectively 12 bits of
useful image data"
Ed, does it mean that the output file will really contain 12 bits ? Or is it
only a 10 bits file ? Can you explain more ?
Thanks,
--
Frédéric
Ed Hamrick
> "For instance, if you have a 10-bit scanner like the Nikon LS-30 and you
> read the CCD 4 times at each pixel position, you get effectively 12 bits
of
> useful image data"
>
> Ed, does it mean that the output file will really contain 12 bits ?
Yes - the output file contains the sum of four 10-bit values.
Regards,
Ed Hamrick
Frédéric
>> "For instance, if you have a 10-bit scanner like the Nikon LS-30 and you
>> read the CCD 4 times at each pixel position, you get effectively 12 bits
> of useful image data"
>>
>> Ed, does it mean that the output file will really contain 12 bits ?
>
> Yes - the output file contains the sum of four 10-bit values.
But regarding the dynamic range, is it the same than a true 12 bits scanner?
Another point : how vuescan aligns the bits when < 16 ? Are they shifted to
right (MSB), or to left (LSB) ?
Thank's,
--
Frédéric
Kurt Stege
>"Frederic" <vue...@gbiloba.org> wrote:
>> "For instance, if you have a 10-bit scanner like the Nikon LS-30 and you
>> read the CCD 4 times at each pixel position, you get effectively 12 bits
>> of useful image data"
>Yes - the output file contains the sum of four 10-bit values.
Just a curious question regarding the interface to a typical scanner:
Of course, for multi pass multi scanning, the complete image will be
delivered from the scanner to vuescan multi times. But how does single
pass multi scan work? I expect, that there are special commands for
this in the scanner, so the scanner has to support this feature. Does
the scanner transmit the scanned line four times, once for each scan?
Or does the scanner calculate the sum on its own, and sends only the
medium value (with a resolution of 12 bits in above example) to vuescan?
I would expect the latter; for most to all scanners, that support
single pass multi scan at all.
And, by the way, what is the data format for a typical 10 bit scanner?
Does it send 3 (or 4) times 16 bit for each scanned pixel, or is the
data packed in some way?
Thanks,
Kurt.
Jouko Vierumäki
http://photography.vierumaki.com/multisampling.html.
Happy scanning,
Jouko
"Frederic" <vue...@gbiloba.org> wrote in message
news:avc1oa$bp3$1...@list.ege.edu.tr...
Ed Hamrick
> But regarding the dynamic range, is it the same than a true 12 bits
scanner?
This would require some testing to determine.
> Another point : how vuescan aligns the bits when < 16 ? Are they shifted
to
> right (MSB), or to left (LSB) ?
They're shifted to the left.
Regards,
Ed Hamrick
Ed Hamrick
> But how does single
> pass multi scan work? I expect, that there are special commands for
> this in the scanner, so the scanner has to support this feature. Does
> the scanner transmit the scanned line four times, once for each scan?
Yes.
> And, by the way, what is the data format for a typical 10 bit scanner?
> Does it send 3 (or 4) times 16 bit for each scanned pixel
Yes.
Regards,
Ed Hamrick
Frederic
>> Another point : how vuescan aligns the bits when < 16 ? Are they shifted
> to right (MSB), or to left (LSB) ?
>
> They're shifted to the left.
Hmmm, my question was confusing, so it is you answer. Shifted to the left
means aligned on the MSB, and not LSB !!! So, it is shifted to the MSB ?
--
Frederic
Ed Hamrick
> >> Another point : how vuescan aligns the bits when < 16 ? Are they
shifted
> > to right (MSB), or to left (LSB) ?
> >
> > They're shifted to the left.
>
> Hmmm, my question was confusing, so it is you answer. Shifted to the left
> means aligned on the MSB, and not LSB !!! So, it is shifted to the MSB ?
A left shift always means shifting the data up to the most
significant bits.
Regards,
Ed Hamrick
Mike Russell
No. This is simply wrong. Adding 10 bit quantities together does not
necessarily increase accuracy, and it will never increase accuracy beyond
what the scanner can measure.
Case 1: If a hypothetical 10 bit scanner delivers a "true" 12 bits, you'll
get the same numerical value each and every time the pixel is scanned.
Averaging them together will give no additional data at all.
Case 2: If the bottom one or two bits of the 10 bits are noise, then
averaging them together may improve things somewhat, depending on the type
of noise. If the noise is pure noise, then no information is extracted by
the averaging process. Averaging the samples together.
Case 3: If the bottom one or two bits are Gaussian noise, averaging samples
will result in an accuracy improvement proportional to the square root of
the number of samples. If there is no systematic noise in the system (and
that's a big if) we will aproach, and even exceed the full 10 bits of
accuracy as we average more and more samples, but we're looking at hundreds
of samples.
In theory, for case 3 only, accuracy could improve beyond the nominal 10
bits of the scanner, but even in that case it is not simply a linear
increase in accuracy as I understand Ed to be saying.
--
Mike Russell
http://www.zocalo.net/~mgr
http://geigy.2y.net
Ed Hamrick
> No. This is simply wrong. Adding 10 bit quantities together does not
> necessarily increase accuracy, and it will never increase accuracy beyond
> what the scanner can measure.
This has been discussed ad-nauseum in the past in this newsgroup.
Take the example of a 1-bit scanner. Assume that the signal being
measured is 0.4. In this case, some kinds of 1-bit devices will
return 0 60% of the time and 1 40% of the time.
Sampling this 1-bit value multiple times will result in more
than 1 bit of accuracy.
Regards,
Ed Hamrick
Mike Russell
Your theoretical example notwithstanding, I'll stand by my original
statement that two scans do not an extra bit make.
Bart van der Wolf
"Mike Russell" <ge...@pacbell.net> wrote in message
news:VLGT9.1459$cS7.86...@newssvr21.news.prodigy.com...
Correct, theoretically it needs 4 scans to get 1 additional bit in the
example given. Noise reduces at a rate of 1/Sqrt(#samples). So you're both
right ;-)
Bart
Jouko Vierumäki
"Bart van der Wolf" <bvd...@nospam.nl> wrote in message
news:3e1f753f$0$49107$e4fe...@news.xs4all.nl...
> Correct, theoretically it needs 4 scans to get 1 additional bit in the
> example given. Noise reduces at a rate of 1/Sqrt(#samples).
Assuming, of course, the noise being of a very pleasant nature from our
point of view. Perfect noise, I would call it ;-)
Jouko
Jeff Grandy
> "Mike Russell" <ge...@pacbell.net> wrote in message
> news:VLGT9.1459$cS7.86...@newssvr21.news.prodigy.com...
Another issue is film grain. Even if you scan a billion
times you will reduce the scanner noise to an extremely
small amount but the film grain will still be there since
the scanner sees the same grain pattern each time.
I haven't seen any statistics on the comparison of
scanner noise vs. film grain for various films but
I doubt that multipass would help much for
Kodak Max 800.
Bill Tuthill
>
> Your theoretical example notwithstanding, I'll stand by my original
> statement that two scans do not an extra bit make.
Hey Mike, I was on vacation when you announced the winner of your
16-bit challenge. Now that I look at the results (image 2 choice 2)
I'm amazed. I voted for the loser in each case, and the 8-bit image
in two cases (but maybe not in the third case).
http://www.zocalo.net/~mgr/DigPhoto/16bit/
Did you switch around the images since August? In your newsgroup post
of 2002-08-16 you claimed that image 2 choice 2 by Michael Schaffer
was the winner, but currently that is listed as an 8-bit image.
How could an 8-bit image win the challenge?
Mike Russell
> Hey Mike, I was on vacation when you announced the winner of your
> 16-bit challenge. Now that I look at the results (image 2 choice 2)
> I'm amazed. I voted for the loser in each case, and the 8-bit image
> in two cases (but maybe not in the third case).
Geeze Bill, where have you been? That was almost a year ago!
> Did you switch around the images since August? In your newsgroup post
> of 2002-08-16 you claimed that image 2 choice 2 by Michael Schaffer
> was the winner, but currently that is listed as an 8-bit image.
> How could an 8-bit image win the challenge?
Can you provide a url for the incorrect link? In any case, all the web page
images are 8 bits. Image 2 of the Greenland images was based on 16 bit
data, and received over 2/3 of the votes.
It was an interesting challenge, and the winner won fair and square. I hope
the contest brought some credibility to the notion that examples should be
forthcoming to substantiate any claim that one method is "obviously" better
than another.
Bill Tuthill
>
> Geeze Bill, where have you been? That was almost a year ago!
5 months, but who's counting? Wish I could charge contracting your way.
In mid August I was kayaking up in Idaho, on the Selway and N Payette.
Did a catch-up upon return, and missed your whole thread.
> Can you provide a url for the incorrect link? In any case, all the
> web page images are 8 bits. Image 2 of the Greenland images was based on
> 16 bit data, and received over 2/3 of the votes.
The only way to know which is 8-bit and which 16-bit is by voting, right?
http://geigy.2y.net/DigPhoto/16bit/Vote1/default.htm
In the scans of the dining room, I voted for the 8-bit image #2 because
the curtains had more apparent detail, both in sun and shadow.
http://geigy.2y.net/DigPhoto/16bit/Vote2/default.htm
In the scans of the sun{rise,set} over sea, I voted for the 16-bit
image #1 because there was more microcontrast in the waves, although
sky grain was worse. The way I interpret your 8/2002 newsgroup post,
8-bit image #2 was the winner.
http://geigy.2y.net/DigPhoto/16bit/Vote2/default.htm
In the scans of the overcast beach scene, I voted for 8-bit image #1
because the gray sky was too grainy in the 16-bit image, but oddly
the cliffs had no more shadow detail than in the 8-bit image.
> It was an interesting challenge, and the winner won fair and square.
If you made a mistake and the winner was actually the sun{rise,set} #1,
the only 16-bit image I liked, I agree. However in the sun{rise,set}
you could probably increase contrast in the waves and achieve similar
microcontrast results, then I might like #2 better because sky grain
is less apparent.
During your 16-bit challenge it was most interesting to see "experts"
floundering, unable to prove the point that more bits are better.
Pasi Savolainen
> During your 16-bit challenge it was most interesting to see "experts"
> floundering, unable to prove the point that more bits are better.
If so, the "experts" are unable to prove that 6 bits is better than 8?
You are of course talking about perceptional differences, but still, I don't
think that making a thing better is a no-win situation.
--
Psi -- <http://www.iki.fi/pasi.savolainen>
Vivake -- Virtuaalinen valokuvauskerho <http://members.lycos.co.uk/vivake/>
Jacek Zagaja
> the curtains had more apparent detail, both in sun and shadow.
This is my picture taken in Lhota Castle in Czech Republic.
I told Mike that this comparison is funny because it shows different
curves white balance settings applied to the RAW image or Gamma 1/2,2
8bpc image.
I think that it's there's no point in it. Why beat a dead horse :)
Everone who had a little experience in signal processing or just use
advanced digital workflow can show you benefits of wide bits
manipulation especialy when converting film-based images.
In other cases 90% of users can't see any difference because some
colors was limited durnig 8bpc manipulation.
Mike Russell
> ... In mid August I was kayaking up in Idaho, on the Selway and N
> Payette. Did a catch-up upon return, and missed your whole thread.
Tough job, Bill, but someone's gotta do it :-)
>> Can you provide a url for the incorrect link? In any case, all the
>> web page images are 8 bits. Image 2 of the Greenland images was
>> based on 16 bit data, and received over 2/3 of the votes.
>
> The only way to know which is 8-bit and which 16-bit is by voting,
> right?
>
> http://geigy.2y.net/DigPhoto/16bit/Vote1/default.htm
Thanks for the heads up. The web page is out of date, and still implies
that the voting is in progress, although when you actually vote it gives you
the answer instead of registering your vote.
> In the scans of the dining room, I voted for the 8-bit image #2
> because the curtains had more apparent detail, both in sun and
> shadow.
> http://geigy.2y.net/DigPhoto/16bit/Vote2/default.htm
This is the effect I was after, as well as a slightly more neutral cast in
the tablecloth, which appears yellowed otherwise. The person providing this
image felt that the yellow was appropriate because of the time of day at
which the image was taken. This is rather emblematic of the philosophy
(with which I disagree) that an image should be a more or less scientific
representation of the scene. The viewer, apparently, should ignore his or
her reactions and trust that the image is accurate.
> In the scans of the sun{rise,set} over sea, I voted for the 16-bit
> image #1 because there was more microcontrast in the waves, although
> sky grain was worse. The way I interpret your 8/2002 newsgroup
> post, 8-bit image #2 was the winner.
> http://geigy.2y.net/DigPhoto/16bit/Vote2/default.htm
You are so correct. The images are reversed. #1 is the winner, and #2 is
the one based on the 8 bit starting image - I'll check again, but I believe
I have the images reversed! In any case, the $100 check sent to the winner
was correctly filled out - heh.
> In the scans of the overcast beach scene, I voted for 8-bit image #1
> because the gray sky was too grainy in the 16-bit image, but oddly
> the cliffs had no more shadow detail than in the 8-bit image.
>
>> It was an interesting challenge, and the winner won fair and square.
>
> If you made a mistake and the winner was actually the sun{rise,set}
> #1, the only 16-bit image I liked, I agree. However in the
> sun{rise,set} you could probably increase contrast in the waves and
> achieve similar microcontrast results, then I might like #2 better
> because sky grain is less apparent.
This image was very difficult to color correct, requiring several masks to
separate the detail in the backlit fence, water detail, as well as a direct
view of the sun. The errors I made were along the lines of over-correcting
and getting a too-harsh result, rather than being up against any sort of 8
bit limit.
> During your 16-bit challenge it was most interesting to see "experts"
> floundering, unable to prove the point that more bits are better.
Yes indeed. There are still those who feel that the appearance of the image
is immaterial, but I hope the contest pushed the balance a bit the other
way, pointing out the importance of examples to back up simple assertions.
My interest has moved on to other realms since then, particularly on new
tools for gamut measurement, and color correction in Photoshop. Watch for
new developments soon.
Bill Tuthill
>
> My interest has moved on to other realms since then, particularly on new
> tools for gamut measurement, and color correction in Photoshop. Watch for
> new developments soon.
Thanks the the answers, Mike! Your interests may have moved on, but this
16-bit challenge was most intriguing for me. I'm often late to do fads:
watched Terminator 2 five years late, and The Matrix two years late.
I'm interested in the gamut question because the part of the color spectrum
that sRGB (and thus web graphics) is missing are the green-blue-cyans.
For my Creekin' photography, those are important colors. Of course I have
no idea if my inkjet printer could be trained to handle wide-gamut AdobeRGB
or CMYK, or whatever could actually record those green-blue-cyans.
Mike Russell
> Your interests may have moved on, but
> this 16-bit challenge was most intriguing for me. I'm often late to
> do fads: watched Terminator 2 five years late, and The Matrix two
> years late.
Well, the hibit editing "fad" is still going strong, and doing so largely
based on heresay of the "more bits is more better", rather than examples.
Imagine another technology (three more channels for example) that doubled
image size, promising higher image quality, but lacking any examples to
prove itself. I think people would be very slow to adopt it. Hibit images,
for many, do not seem to have this requirement and were simply accepted at
face value. I hope my challenge nudged this a little.
For my and others' part, the easy acceptance of hibit editing is largly an
error shared by a large group of people. The ironic phrase "conventional
wisdom" was coined by John Galbraith to cover exactly this situation.
Wisdom is applied knowledge, and seldom simply a convention shared by a
group. It needs the test of time, thought, and in the case of digital
images, examples.
> I'm interested in the gamut question because the part of the color
> spectrum that sRGB (and thus web graphics) is missing are the
> green-blue-cyans. For my Creekin' photography, those are important
> colors. Of course I have no idea if my inkjet printer could be
> trained to handle wide-gamut AdobeRGB or CMYK, or whatever could
> actually record those green-blue-cyans.
Good - there will be a freebie tool soon for looking at gamuts within
photoshop. Perhaps you can provide a sample image.