Sprintscan 35+, 10 bits vs 8 bits

PC Hardware
Dicussion of PC hardware and peripherals

FAQ

Memberlist

Profile

Sprintscan 35+, 10 bits vs 8 bits Goto page Previous 1, 2

PC Hardware Forum Index -> Scanners

Author

Message

Lorenzo J. Lucchini
Guest

Posted: Thu Oct 20, 2005 1:03 am Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

Don wrote:

Quote:

On Wed, 19 Oct 2005 15:27:07 +0200, "Lorenzo J. Lucchini"
ljl@tiscali.it> wrote:

and - unless he goes through the above procedure - his
editing decisions will be made based on the preview keyhole i.e. they
will be wrong.

Where do you place the line that separates a scan from a "keyhole"?

Just below native resolution.

Oh... ok.

Quote:

[snip]

A preview doesn't necessarily have to be made at 100dpi or so.

Not strictly true as most scanning programs don't even offer that
option (or at the very least limit it severely). Instead, most
scanning programs preview at what they consider "enough" resolution.

Well, that can be a problem if a scanner isn't supported by anything
other than the native driver. Which, unfortunately, seems to be the OP's
case -- no SANE support and no SilverFast support, though he said
VueScan has support.

Quote:

Unless the software is really bad, I don't see why it's all so
inadequate. Working histogram, curves and levels should be more than enough.

Quote:

Now, no matter how high your preview's resolution, you won't have *all*
the necessary information until you take your preview at the *same*
resolution as the final scan;

There you go! So why argue otherwise?

Never argued otherwise. I said you won't have *all* the necessary
information (needed to make a "perfect" scan), but I think you do have
*some* of the necessary information (allowing to make a better scan than
making use of *no* available information at all).

Quote:

however, with a decent compromise between
resolution and scanning speed, I think you can come pretty darn close.

"Close only counts in grenades and horse shoes" as the saying goes.

You can come up with all sorts of convoluted procedures to make any
statement "true" but you only end up with a "cure worse than the
disease".

I can see how the cure would be "not so much better than the disease",
but no more.
Then whether the cure is *worth* doing, wrt cost/benefit, is something
that should be decided on an individual basis.

Quote:

Since I seem stuck in a quoting mode ;o) here's one more:

"You can put lipstick on a pig, but it's still a pig!" ;o)

If you're stuck with the pig, then a better pig may still be an
improvement for you.

Obviously I don't know if the OP is really "stuck" with his pig, I mean
scanner, but he didn't ask whether we think he should buy another scanner.

Quote:

For example, setting the whitepoint and blackpoint at scantime should do
no damage and can improve the results, if the scanned image doesn't
cover the whole range of values.

No, it doesn't, simply because you're basing those crucial decisions
on the *preview image* histogram!

Again, that histogram is based on the *tiny* preview image!

Yes, but all you need from that histogram is the whitepoint and the
blackpoint.

Which will be only as accurate as the histogram.

The tiny preview image histogram is massively inaccurate.

Ergo: Your B&W points based on such a histogram will be equally
massively inaccurate.

Bah... sorry, I just can't agree. Yeah, they're inaccurate. For me,
though, they're good enough to set the exposure time to a reasonable
value (you know that setting exposure is the same as setting the
whitepoint for me).
"Reasonable" means that they allow to avoid clipping in the vast
majority of cases, while giving a very real quantization advantage for
underexposed frames.

Quote:

Those *will not* be correct in the smaller preview, agreed.

There you go #2! Why argue otherwise when you know this?

Not arguing otherwise. They are not correct.
That something isn't "correct", though, has never meant that it can't be
close enough.

And if you don't like "close enough"... well, you should probably get an
infinite bit depth and resolution scanner (as well as film, as well as a
parfect lens) in the first place!

Quote:

But this error will result in two possible situations: either you end up
with a clipped image, or you end up with an image where the whitepoint
and blackpoint are not as "stretched" as they could have been (ideally,
1 and 254).

So, once again, you end up with a convoluted "solution" i.e. a cure
worse than the disease.

Worse? No.
Worse only in the case that you end up with clipping. That's easily
solved by scanning again, and is not something that should happen
anywhere near often.

Quote:

In the latter case, oh well, you can't have everything, but you've still
gained something.

No, you haven't! All you "gained" is having to perform multiple
previews and still end up with an inaccurate setting.

No. You've performed *one* preview and *one* scan, and you've ended up
with a setting that's more accurate than *no* setting, though not 100%
accurate.

Quote:

Also, it's not a case of "hmm, wonder whether I made the right
adjustments from that tiny preview": either the image clips, or it
doesn't. If it does, scan again, and consider increasing your safety
margin next time.

You're tying yourself in knots to do something which is unnecessary
just to "prove" a point which you know is wrong.

Unnecessary? Of course it's unnecessary. Do you think that multi-pass
multi-scanning with sub-pixel alignment is "necessary"?

I'm just trying to describe out to obtain as much information as
possible from a 10-bit internal / 8-bit external scanner.
Whether the complicatedness of the process is comparable to "tying
oneself in knots" is something that *the single scanner user* should decide.

Quote:

Like I said above, you end up with a convoluted "solution" only doing
even more damage. Those multiple previews ending up with a guess is a
cure worse than the disease.

Demonstrate this please.

Say I have an image with whitepoint=50.
I take a preview. The preview tells me that whitepoint=40.
I take the scan, setting whitepoint=57 (40+1/5*40) to be on the safe side.
I obtain an image that has whitepoint=223.

A "perfect" scan would have had whitepoint=254, so I definitely haven't
obtained a "perfect" scan.

But tell me exactly why having 223 values would be worse than having
only 50 of them.

Oh, but wait, are all those 223 values "real"? No. With 10 bits per
channel, only 200 of them will be "real".

Well, it appears that I've gained a net 150 pixel values, or if you
prefer, I have 4 times less quantization than I would have had if I
didn't set the whitepoint.

Tell me again why this is considered bad.

Quote:

Not only
that, but most likely the preview was done in *8-bit*! (BTW, NikonScan
previews at 16-bit.)

I don't see how this matters for setting whitepoint and blackpoint...
Yeah, you'll only be able to chose among 256 values rather than 65536,
but I'd be very happy if this was the only problem! Whitepoint at 253.74
instead of 254... terrible! ;-)

Yes, it is because...

.... because?
I don't think you're explaining why this is, below.

Quote:

But as you correctly say, the big problem is the limited preview
resolution, not the bit depth -- resolution *can*, at least under
extreme conditions, give you a white/blackpoint that's off by *much*,
possibly making the scan clip; bit depth can't.

There you go #3! So, you know all this, but still keep arguing against
it!?

Well... yes.
Anyway, whitepoint at 253.74 instead of at 254 (an example of what could
be caused by a preview's *low bit depth*, not resolution, i.e. 256
values rather than 65536) is terrible because...?

Quote:

All I need to do, is just sit here and you'll make all my points for
me! ;o)

Having A helps obtaining B.
I don't have A, therefore I can't obtain B.
Yes?

I make "your" points because I think they're true. Would you prefer I
hid them and denied them just to make my argument artificially sound
stronger?
(Well, I've found this to be common practice on Usenet, but it's not one
of the Usenet customs I like best)

Quote:

The root problem, Lorenzo, is that no matter how hard you try - and
you do try very hard! ;o) - you just can't get around the fact that
applying changes at scan time is a bad idea in all but most trivial of
cases.

Hmm... I can't really deny this when speaking about what I do with *my*
scanner, since *I* could scan at 16-bit, but instead prefer to scan at
8-bit and make some scan time adjustments.
In this case, you're obviously right (though, you know, people make
compromises for speed, storage space and all, and I don't think mine is
so terrible a compromise if done carefully).

I make compromises myself all the time. That's not the point. The
point is I know I make them, and I don't try to defend them. I know
they are less then perfect and I'm OK with that because it makes sense
in the given context. It's a subjective decision and I stand by it.
But I don't pretend it's an objective decision which applies to
others. It may, if they have similar requirements, but it may not. So
I don't try to defend it as anything other than a subjective decision
within a narrowly defined context.

What do you mean by "defending" a compromise?
If you mean something on the lines "my compromise works as good as your
no-compromise approach", well, that's just the kind of thing that
*can't* be true of a compromise.

If you mean "I have arguments showing that, in this context and given my
requirements, my compromise is better than other possible compromises",
I feel like I have every right to defend it.

In any case, while this stuff we're talking about is a compromise *in my
case*, it is not for the original poster, who just *can't* decide what
bit depth to scan at with his scanner.

So, at best, the compromise I'm talking about in his case would be that
of *not buying a better scanner and trying to take the best from the one
he's got*.
Which, of course, is a subjective decision, so if he doesn't like this
compromise he can definitely go buy a new scanner, and I'll have no
objection.

Quote:

The problem is (and I'm talking in general terms now, not necessarily
related to this discussion) people often *want* their compromise to be
the "perfect" solution, and they tie themselves in knots trying to
justify that compromise. In other words, they themselves are very
unhappy with the compromise but instead of looking for an optimal
solution they stick with the sub-standard compromise and try to defend
the indefensible. In the end they just get into more and more trouble
as facts clearly prove otherwise.

Hope I'm not unknowingly falling down into digital hell, then.

Quote:

But in the OP's case, he *cannot* scan at 10-bit (let alone 16-bit),
instead he *has* to work with 8-bit data.
In his case, I'd be very careful to say "just kiss goodbye to the lowest
two bits, and deal with the rest", even if the only other option is
messing with scan time settings.

You're missing the point! Struggling to *try* (!) and keep those two
bits (without really knowing if that attempt is successful) will
produce *worse* results than by using the alternative option where you
know what you're doing. The point is he isn't even sure if those two
bits are thrown away before scanner software applies any edits!

Don, excuse me, but are you just ignoring the fact that I've told you
and the OP, more than once, how to try to find out whether those two
bits are indeed used or not?

My approach for finding that out might be flawed, but I do clearly
recognize that, first of all, the OP should test whether his scanner is
really 10-bit or not.

Quote:

So, on balance, the safest option is not to risk any more damage but
get the best you can (i.e. with as little interference from the
scanner software "editing" as possible), up the bit depth afterwards
and edit in proper editing software.

The safest option is to check whether those two bits exist or not first,
and then behave consequently.
If it turns out that there is no method to tell with a good degree of
certainly whether those darn bits are there or not, then yes, the safest
method is probably the one you say.

Anyway, my "what-if" scenario in these posts has been based on the
finding of the existence of ten binary digits per channel in the analog
to digital conversion performed inside the scanner, and on the
consequent inclusion of all ten binary digits during any image
processing taking place at the firmware or driver level.
*Phew*.

Quote:

I still don't see valid arguments in favour of a "massive damage
cancelling out the gain".
At best, I've seen arguments that "having to scan again in case you've
got clipping at first try is time consuming and not worth the effort".
Which can be true to some degree, but is quite different.

Quote:

2. *Know* that externally scaled output is in true 16-bit and work
with the full complement of tools an external editor has knowing
you're getting the most out of available data.

In such a case option 2 will always produce superior results.

What do you mean "externally scaled output"? If you mean that the output
from the scanner is 16-bit, well, we know the OP's scanner just can't do
that.

If you mean *converting* the scanner's output to 16-bit and then working
on that, this may be valid advice; however, I don't see why this
couldn't be done *together* with option 1.

That is, IIUC, options 1 and 2 are not mutually exclusive.

by LjL
ljlbox@tiscali.it

Don
Guest

Posted: Thu Oct 20, 2005 7:28 pm Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

On Wed, 19 Oct 2005 22:03:16 +0200, "Lorenzo J. Lucchini"
<ljl@tiscali.it> wrote:

Quote:

But let's assume you can set the preview to 100% i.e. native
resolution. What have you achieved with that? Nothing! You're still
stuck in the scanner program with inadequate and limited set of
editing tools.

Unless the software is really bad, I don't see why it's all so
inadequate. Working histogram, curves and levels should be more than enough.

I explained all that several times already, including that I'm not
saying everyone must use an external editor. I'm just stating the
facts. It's up to each user to decide what they want or need. If one
is happy with scanner editing tools, more power to them! But if one
says they are equal to an external editor, that's simply inaccurate,
for the many reasons outlined earlier.

Quote:

Again, that histogram is based on the *tiny* preview image!

Yes, but all you need from that histogram is the whitepoint and the
blackpoint.

Which will be only as accurate as the histogram.

The tiny preview image histogram is massively inaccurate.

Ergo: Your B&W points based on such a histogram will be equally
massively inaccurate.

Bah... sorry, I just can't agree. Yeah, they're inaccurate.

That's inconsistent. You can't say you disagree and then in the same
breath confirm what I just said (i.e. that what you disagree with is
actually correct).

Quote:

For me,
though, they're good enough to set the exposure time to a reasonable
value (you know that setting exposure is the same as setting the
whitepoint for me).

The two key words being "for me". We are not talking about subjective
judgment. As I keep repeating, if it works for you, fine. But that
does not make it objectively true. It may mean you have lower
expectations or any number of other things. Nothing wrong with that,
of course. What is wrong, however, is to assume that your personal
preferences translate into objective statements. They don't.

Meta level diversion:

I think there's a basic misunderstanding of the principle of what I'm
saying. When I'm stating generic facts I'm not advocating any
particular application or use of these facts. I'm just offering
pertinent information. It's then up to each reader to decide what to
do with those facts: ignore them completely, use them fully, use them
only in part, ... etc.

Quote:

Like I said above, you end up with a convoluted "solution" only doing
even more damage. Those multiple previews ending up with a guess is a
cure worse than the disease.

Demonstrate this please.

I have! The inexactness of scanner software environment causes vastly
inaccurate settings.

Quote:

Say I have an image with whitepoint=50.
I take a preview. The preview tells me that whitepoint=40.
I take the scan, setting whitepoint=57 (40+1/5*40) to be on the safe side.

That's just not realistic. The clipping settings are on the order of
0.3% to 0.5.% and you're bracketing with 20%!?

....

Quote:

Tell me again why this is considered bad.

Because it starts with a wrong premise and then goes downhill from
there.

This is a prime example of tying yourself in knots trying to justify
this wrong premise and trying to solve a problem that doesn't exist.

If one is so concerned with accuracy, one should simply edit in an
external editor and all of the above "problems" disappear.

Quote:

Because you explained it yourself:

Quote:

....

Quote:

All I need to do, is just sit here and you'll make all my points for
me! ;o)
....
I make "your" points because I think they're true. Would you prefer I
hid them and denied them just to make my argument artificially sound
stronger?

No, no, no, you misunderstand. What I'm referring to is: You object to
the facts but then immediately add in the following sentence that the
facts are actually true. You do this all the time.

It's inconsistent. So what I'm saying above has nothing to do with
style but with substance which is contradictory.

Quote:

(Well, I've found this to be common practice on Usenet, but it's not one
of the Usenet customs I like best)

I don't even answer such messages. If one can't "agree to disagree
agreeably" then there's no point. I have no interest in shouting and
calling people names.

Quote:

In this case, you're obviously right (though, you know, people make
compromises for speed, storage space and all, and I don't think mine is
so terrible a compromise if done carefully).

I make compromises myself all the time. That's not the point. The
point is I know I make them, and I don't try to defend them. I know
they are less then perfect and I'm OK with that because it makes sense
in the given context. It's a subjective decision and I stand by it.
But I don't pretend it's an objective decision which applies to
others. It may, if they have similar requirements, but it may not. So
I don't try to defend it as anything other than a subjective decision
within a narrowly defined context.

What do you mean by "defending" a compromise?

For example, your above attempt of trying to come up with a convoluted
clipping margin of 20%.

Quote:

If you mean something on the lines "my compromise works as good as your
no-compromise approach", well, that's just the kind of thing that
*can't* be true of a compromise.

If you mean "I have arguments showing that, in this context and given my
requirements, my compromise is better than other possible compromises",
I feel like I have every right to defend it.

None of the above. It's number 3: "There is a perfect solution already
available (edit in an external editor). However, I want to use scanner
software to edit. But it's bad. So I will tie myself in knots trying
to work around its inaccuracies - but not succeeding. I'll end up with
worse results than easily available solution of just using an external
editor. I agree that's the ideal solution, but I will continue to
defend the inferior and inexact attempt at a workaround in scanner
software."

Quote:

In any case, while this stuff we're talking about is a compromise *in my
case*, it is not for the original poster, who just *can't* decide what
bit depth to scan at with his scanner.

Which - as I've shown - is irrelevant because even if he could make
scanner software work at 10 bits internally, due to all the outlined
problems, that would still be worse than using the full complement of
tools on 8-bit data in an external editor.

Quote:

You're missing the point! Struggling to *try* (!) and keep those two
bits (without really knowing if that attempt is successful) will
produce *worse* results than by using the alternative option where you
know what you're doing. The point is he isn't even sure if those two
bits are thrown away before scanner software applies any edits!

Don, excuse me, but are you just ignoring the fact that I've told you
and the OP, more than once, how to try to find out whether those two
bits are indeed used or not?

But that's simply irrelevant for the reasons I just explained in the
previous paragraph. What's the point of wasting time trying to find
that out when in the end - even if true (!) - the end result would
still be inferior to editing in an external editor?

Quote:

My approach for finding that out might be flawed, but I do clearly
recognize that, first of all, the OP should test whether his scanner is
really 10-bit or not.

It just doesn't matter. The only thing that would matter is if he
could actually get those 10-bits out. But he can't.

Quote:

Anyway, my "what-if" scenario in these posts has been based on the
finding of the existence of ten binary digits per channel in the analog
to digital conversion performed inside the scanner, and on the
consequent inclusion of all ten binary digits during any image
processing taking place at the firmware or driver level.
*Phew*.

What you're ignoring is that it doesn't matter as I just explained.

If the only place he can use those 10-bits is within the scanner
software then it's "Game Over". No need to look any further.

Quote:

Given those two options:

1. *Hope* that scanner software edits are in 10 bits and work through
the preview keyhole doing massive damage which more than cancels out
any 2-bit gain! And all along not even knowing if the 2 bits are used!

I still don't see valid arguments in favour of a "massive damage
cancelling out the gain".
At best, I've seen arguments that "having to scan again in case you've
got clipping at first try is time consuming and not worth the effort".
Which can be true to some degree, but is quite different.

2. *Know* that externally scaled output is in true 16-bit and work
with the full complement of tools an external editor has knowing
you're getting the most out of available data.

In such a case option 2 will always produce superior results.

What do you mean "externally scaled output"? If you mean that the output
from the scanner is 16-bit, well, we know the OP's scanner just can't do
that.

If you mean *converting* the scanner's output to 16-bit and then working
on that, this may be valid advice;

That's what I mean, of course.

Quote:

however, I don't see why this
couldn't be done *together* with option 1.

That is, IIUC, options 1 and 2 are not mutually exclusive.

No, they are not - but only theoretically. In practice, since 1 causes
irreparable damage it (a priori) negates any potential benefits of 2.
Worse still! It goes beyond any benefits of 2.

One final meta level observation:

If what I write sometimes appears "picky" this could be because the
intentions are misunderstood. The intention is *not* to be picky but
to point an (objectively) important aspect. I don't expect this will
be important to everyone (subjectively). However, in that case they
can just ignore it. The problem only occurs when they try to use
subjective assertions to counter objective fact.

I mean, the normal reaction to such a statement offering additional
information (which is my only intention) and made in a
non-confrontational, matter-of-fact fashion (i.e. not argumentative,
but simply and calmly stating facts), a normal reaction to that would
be:
A. Thanks, but no thanks! I don't care for such level of detail
B. Huh! I never thought of that! Thanks!

I'm perfectly OK with either reaction.

Don.

Lorenzo J. Lucchini
Guest

Posted: Fri Oct 21, 2005 1:18 am Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

Don wrote:

Quote:

On Wed, 19 Oct 2005 22:03:16 +0200, "Lorenzo J. Lucchini"
ljl@tiscali.it> wrote:

But let's assume you can set the preview to 100% i.e. native
resolution. What have you achieved with that? Nothing! You're still
stuck in the scanner program with inadequate and limited set of
editing tools.

Unless the software is really bad, I don't see why it's all so
inadequate. Working histogram, curves and levels should be more than enough.

I explained all that several times already, including that I'm not
saying everyone must use an external editor. I'm just stating the
facts. It's up to each user to decide what they want or need. If one
is happy with scanner editing tools, more power to them! But if one
says they are equal to an external editor, that's simply inaccurate,
for the many reasons outlined earlier.

I'm not saying that one should not use an external editor because the
driver-integrated tools are equivalent. They are obviously not, with any
dedicated editor having many more tools.

I'm saying that the tools the scanner driver does have (typically
curves, level and a histogram) don't have any specific flaws that make
them worse than what's in Photoshop.

(That's a general statement, of course I suppose you can find a scanner
driver with irremediably bugged curves and levels...)

Any flaws are thus not in the *tools*, but in the fact you're applying
them based on a preview -- which is what we are discussing.

But if you maintain that it's the *scanner driver tools* themselves that
are inadequate, then please explain how they are. The "main reasons
outlined earlier" simply refer to something else.

Quote:

You said they're massively inaccurate.
I said I they are inaccurate.

Clearly I interpreted you "massively" as meaning "too much, for any
purpose", which is what I do not agree with.

Quote:

For me,
though, they're good enough to set the exposure time to a reasonable
value (you know that setting exposure is the same as setting the
whitepoint for me).

The two key words being "for me". We are not talking about subjective
judgment. As I keep repeating, if it works for you, fine. But that
does not make it objectively true.

Nor objectively false.

Anyway, my "for me" was not really intended as to imply subjective
judgement, although it does probably sound as such.

"For me" = "With my own scanner, they're good enough to set decent (i.e.
not-clipping, but still narrower than 0..255) w/b-point values at first
try in the vast majority of cases. Others may find that they'll often
have to make multiple trial scans (perhaps too many for their likings)
to obtain the same result)".

Because, you see, I maintain that a good result is *always* obtainable:
in the worst case, with a very bad scanner, you'll have to take a number
of "trash scans" before coming out with a good scans.

Now, yeah, *really* having to do *that* could be labeled as "tying
oneself in knots", I admit: you'd come up with a good result, but only
through such a time-consuming process that, I guess, nobody would do it
in practice.

However, the fact that it doesn't get (nearly) to such an extreme with
my scanner makes me infer that it'll be workable with many other scanners.

Quote:

It may mean you have lower
expectations or any number of other things.

Actually, what I'm trying to say is that I suspect the OP could obtain
*better* results by exploiting the internal 10-bits than by ignoring them.

You may disagree with this statement, but saying that it may mean I have
lower expectations than someone else just does not make any sense.

Quote:

Nothing wrong with that,
of course. What is wrong, however, is to assume that your personal
preferences translate into objective statements. They don't.

No preferences.

I stand that: if you own a 10-bit external / 8-bit internal scanner,
then by taking a less-than-full-resolution scan ("preview") followed by
one or more full-resolution scans, you can *always* obtain more
information content than by using a "standard procedure" (i.e. just scan).

In particular, here is the complete algorithm, so that no doubts need
remain:

1) Take a scan with with bp=0, wp=255, using any resolution ("preview")
2) Take a full-resolution scan using bp=preview_bp, wp=preview_wp
3) Repeat step 2 if clipping is found

It's quite simple isn't it? Well, I haven't mentioned using a "safety
margin" and this kind of things, but they're not strictly necessary.

*Please* demonstrate what is flowed in the algorithm above. All I can
see from it is that the information content in the final scan will be
higher than by "just scanning" for any given underexposed or overexposed
scan target.

Now, *that* specific algorithm, not having any safety margin, is a bit
impractical to use, since it is bound to force the user to scan more
than once at full resolution.

So, you might find it to slow to use, but now *that's your subjective
opinion and preference*, it's not a "tying myself in knots" on my side.

Anyway, if you keep a margin, it can become much more practical to use,
even though the improvements will diminish.

Quote:

Meta level diversion:

I think there's a basic misunderstanding of the principle of what I'm
saying. When I'm stating generic facts I'm not advocating any
particular application or use of these facts. I'm just offering
pertinent information. It's then up to each reader to decide what to
do with those facts: ignore them completely, use them fully, use them
only in part, ... etc.

Same for me.

Quote:

Like I said above, you end up with a convoluted "solution" only doing
even more damage. Those multiple previews ending up with a guess is a
cure worse than the disease.

Demonstrate this please.

I have! The inexactness of scanner software environment causes vastly
inaccurate settings.

Well, no, you haven't. You have *stated* so, but not, IMHO, satisfyingly
demonstrated so. Please attack the algorithm I've given above,
demonstrating it's flawed.

And "it'll take too many test scans to be practical for people" just
doesn't cut it.

Quote:

Sorry, I'm not sure what you mean. What are the clipping settings?
Are you saying that I could safely bracket with less than 20%? That
would be even nicer. As I said, I kept on the safe side.

Quote:

...

Tell me again why this is considered bad.

Because it starts with a wrong premise and then goes downhill from
there.

What's the wrong premise?

Quote:

This is a prime example of tying yourself in knots trying to justify
this wrong premise and trying to solve a problem that doesn't exist.

The "problem" here is that the lowest 2 bits from the OP's scanner can't
be obtained directly.
Please explain why this problem doesn't exist.

(The only explanation I could think of is "more than 8 bits per channel
are useless", and other people would give such an explanation, but
you'll have a harder time than them, since I know you wouldn't say that)

Quote:

If one is so concerned with accuracy, one should simply edit in an
external editor and all of the above "problems" disappear.

And two more bits would appear by magic from nothingness? Nice.

Quote:

No, I didn't.

Quote:

You "..."'ed the part where I explained why this is no explanation to
your "yes, it is because ..." above.

Quote:

All I need to do, is just sit here and you'll make all my points for
me! ;o)

...

I make "your" points because I think they're true. Would you prefer I
hid them and denied them just to make my argument artificially sound
stronger?

No, no, no, you misunderstand. What I'm referring to is: You object to
the facts but then immediately add in the following sentence that the
facts are actually true. You do this all the time.

Cite please. At most, I think I might have sometimes been too vague
about exactly *which* parts of your facts I consider true, and which
ones I don't.

On the other hand, I suspect that I have later pinpointed that better
later in almost every case... since you pointed it out in almost every case.

Quote:

It's inconsistent. So what I'm saying above has nothing to do with
style but with substance which is contradictory.

I see, but I don't think it is.

Quote:

[snip]

What do you mean by "defending" a compromise?

For example, your above attempt of trying to come up with a convoluted
clipping margin of 20%.

I'm really missing something here. I mean, you can go with much less
than 20% if you like (and I suspect it would work quite well with many
scanners, very rarely forcing to scanning the same picture more than one).

Actually, I *do* use less than 20% with my scanner.
I just chose 20% because the higher, the "safer" (i.e. there's less risk
of having to scan again, even though there's also proportionally less gain).

Quote:

Perfect? No. It doesn't let the OP exploit his scanner's internal 10
bits in any way.

You may argue (and you're doing that in fact) that "the cure is worse
than the disease" (which I don't think is true, in any case", but you
can hardly argue that the disease is a "perfect solution".

Quote:

However, I want to use scanner
software to edit. But it's bad. So I will tie myself in knots trying
to work around its inaccuracies - but not succeeding. I'll end up with
worse results than easily available solution of just using an external
editor. I agree that's the ideal solution,

As I said, I definitely don't, given you have no way to make use of the
lowest two bits in an external editor. Please don't put too many words
in my mouth.

Quote:

but I will continue to
defend the inferior and inexact attempt at a workaround in scanner
software."

Bah.

Quote:

In any case, while this stuff we're talking about is a compromise *in my
case*, it is not for the original poster, who just *can't* decide what
bit depth to scan at with his scanner.

Which - as I've shown - is irrelevant because even if he could make
scanner software work at 10 bits internally, due to all the outlined
problems, that would still be worse than using the full complement of
tools on 8-bit data in an external editor.

Yeah, except that I don't think you have shown it, while on the other
hand I do think that I have shown the contrary.
Ah, life, don't we all love it?

Quote:

You: "The point is he isn't even sure if those two bits are thown away
before scanner software applies any edits."

Me: "I've told you and the OP [..] how to try to find out whether those
too bits are indeed used"

You: "But that's simply irrelevant"

Who's being contradictory now? Is it "the point", or is it "irrelevant"

Oh, wait, I suppose a point might well be irrelevant -- that's not a
contradiction.
So, ok, I recognize that you found out your own point was irrelevant :-)

Quote:

What's the point of wasting time trying to find
that out when in the end - even if true (!) - the end result would
still be inferior to editing in an external editor?

Except that it wouldn't.

Quote:

My approach for finding that out might be flawed, but I do clearly
recognize that, first of all, the OP should test whether his scanner is
really 10-bit or not.

It just doesn't matter. The only thing that would matter is if he
could actually get those 10-bits out. But he can't.

I wonder why they make scanners that have more bits internally than
there are externally, if they serve no useful purpose.
We know the marketing is a son of the devil, but there's a limit to
everything!

Quote:

[snip]

One final meta level observation:

If what I write sometimes appears "picky" this could be because the
intentions are misunderstood. The intention is *not* to be picky but
to point an (objectively) important aspect. I don't expect this will
be important to everyone (subjectively). However, in that case they
can just ignore it. The problem only occurs when they try to use
subjective assertions to counter objective fact.

I mean, the normal reaction to such a statement offering additional
information (which is my only intention) and made in a
non-confrontational, matter-of-fact fashion (i.e. not argumentative,
but simply and calmly stating facts), a normal reaction to that would
be:
A. Thanks, but no thanks! I don't care for such level of detail
B. Huh! I never thought of that! Thanks!

I'm perfectly OK with either reaction.

I see, but my reaction (*in the case at hand, i.e. the OP's*) is
"C. Sorry, but I think better level of detail can be obtained in another
way".

Clearly I could be mistaken, but it's certainly another valid reaction
in principle.

Note the emphasized "in the case at hand", as in *my own* case (which we
discussed in another thread), my reaction is clearly B (though with
additional notes), as my scanner is perfectly able to scan at 16-bit
external if desired.

by LjL
ljlbox@tiscali.it

Don
Guest

Posted: Fri Oct 21, 2005 7:25 pm Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

On Thu, 20 Oct 2005 22:18:02 +0200, "Lorenzo J. Lucchini"
<ljl@tiscali.it> wrote:

Quote:

I'm not saying that one should not use an external editor because the
driver-integrated tools are equivalent. They are obviously not, with any
dedicated editor having many more tools.

There you go! So why do you argue against it?

Quote:

Any flaws are thus not in the *tools*, but in the fact you're applying
them based on a preview -- which is what we are discussing.

I never said the faults were in the scanner editing tools (although
there probably are!). It's the preview "keyhole" that causes you to
make bad decisions. And due to the minimal scanner editor you'll need
to edit again later. Remember the equation: 2 edits <> 1 edit! Etc...

Quote:

But if you maintain that it's the *scanner driver tools* themselves that
are inadequate, then please explain how they are. The "main reasons
outlined earlier" simply refer to something else.

No, they refer exactly to the fact that you're basing your decision on
the inadequate preview image and using inferior scanner editor.

Quote:

Anyway, my "for me" was not really intended as to imply subjective
judgement, although it does probably sound as such.

Yes it does. And it is. As you will now confirm it yourself:

Quote:

"For me" = "With my own scanner, they're good enough to set decent (i.e.
not-clipping, but still narrower than 0..255) w/b-point values at first
try in the vast majority of cases. Others may find that they'll often
have to make multiple trial scans (perhaps too many for their likings)
to obtain the same result)".

There you go! You've just described what "subjective" means!

Quote:

Because, you see, I maintain that a good result is *always* obtainable:
in the worst case, with a very bad scanner, you'll have to take a number
of "trash scans" before coming out with a good scans.

"Good" <> "as good"!

Quote:

Now, yeah, *really* having to do *that* could be labeled as "tying
oneself in knots", I admit: you'd come up with a good result, but only
through such a time-consuming process that, I guess, nobody would do it
in practice.

There you go, again. Confirming what I said: You tie yourself in knots
only to come up with sub-standard results. Remember: good <> as good!

Quote:

1) Take a scan with with bp=0, wp=255, using any resolution ("preview")
2) Take a full-resolution scan using bp=preview_bp, wp=preview_wp
3) Repeat step 2 if clipping is found

It's quite simple isn't it?

No, it isn't! That's the canonical definition of convoluted.

Quote:

*Please* demonstrate what is flowed in the algorithm above.

I have! Several times. Please re-read the thread.

Quote:

Now, *that* specific algorithm, not having any safety margin, is a bit
impractical to use, since it is bound to force the user to scan more
than once at full resolution.

There you go!

Quote:

Say I have an image with whitepoint=50.
I take a preview. The preview tells me that whitepoint=40.
I take the scan, setting whitepoint=57 (40+1/5*40) to be on the safe side.

That's just not realistic. The clipping settings are on the order of
0.3% to 0.5.% and you're bracketing with 20%!?

Sorry, I'm not sure what you mean. What are the clipping settings?
Are you saying that I could safely bracket with less than 20%? That
would be even nicer. As I said, I kept on the safe side.

A safe clipping setting is 0.3% to 0.5.%. Using 20% margin is just
impractical. You'll be left with no dynamic range to speak of.

Quote:

Because it starts with a wrong premise and then goes downhill from
there.

What's the wrong premise?

That scanner software editing can even be compared to an external
editor. Hint: Read your own words in the very first paragraph on top
of this message!

Quote:

This is a prime example of tying yourself in knots trying to justify
this wrong premise and trying to solve a problem that doesn't exist.

The "problem" here is that the lowest 2 bits from the OP's scanner can't
be obtained directly.

As I've must explained about at least two times already, any potential
"gain" of these 2 bits is more than obliterated by the inexactness of
the process. In other words, external editor on 8 bits produces better
results than scanner editor using preview on (maybe?) 10 bits.

Quote:

Please explain why this problem doesn't exist.

Again, I must have explained that many times as well. One last time:

The problem is trying to make an inferior scanner software editor
perform like a superior external editor. Since an external editor
exists, trying to replace it with inferior scanner software editing is
creating a problem where none exist. Just use the external editor and
there is no problem.

Quote:

--- start ---

On Wed, 19 Oct 2005 22:03:16 +0200, "Lorenzo J. Lucchini"
<ljl@tiscali.it> wrote:

Quote:

sorry, I just can't agree. Yeah, they're inaccurate.

First you don't agree and then, on the same line, you agree, and then
you go on not agreeing again.

Quote:

There you go #3! So, you know all this, but still keep arguing against
it!?

Well... yes.

When faced with a contradiction you admit it. And then do it again.

Quote:

I make "your" points because I think they're true.

And yet you then continue to argue against these "true points".

Quote:

In this case, you're obviously right...

But ...

And then you go on to immediately contradict yourself again.

Etc... etc...

--- end ---

And that's only *some* contradictions in *one* single message!
Need more? ;o)

Quote:

It just doesn't matter. The only thing that would matter is if he
could actually get those 10-bits out. But he can't.

I wonder why they make scanners that have more bits internally than
there are externally, if they serve no useful purpose.
We know the marketing is a son of the devil, but there's a limit to
everything!

Of course, they serve a purpose. The question is whether they can be
retrieved.

When a manufacturer *claims* higher internal bit rate but provides no
way of actually getting that data out, I get very suspicious. Either
they are just lying (it's been known to happen) or the data is so bad
they're ashamed to let people see it. Either way, unless I can get
that data out to put it through a rigorous testing procedure, I don't
consider any "claimed" resolution as real.

Like you say, marketroids are devil's spawn! Actually, I'd call them
even worse! :o)

Don.

Lorenzo J. Lucchini
Guest

Posted: Wed Oct 26, 2005 1:34 am Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

Don wrote:

Quote:

On Thu, 20 Oct 2005 22:18:02 +0200, "Lorenzo J. Lucchini"
ljl@tiscali.it> wrote:

[snip]

Say I have an image with whitepoint=50.
I take a preview. The preview tells me that whitepoint=40.
I take the scan, setting whitepoint=57 (40+1/5*40) to be on the safe
side.

That's just not realistic. The clipping settings are on the order of
0.3% to 0.5.% and you're bracketing with 20%!?

Sorry, I'm not sure what you mean. What are the clipping settings?
Are you saying that I could safely bracket with less than 20%? That
would be even nicer. As I said, I kept on the safe side.

A safe clipping setting is 0.3% to 0.5.%. Using 20% margin is just
impractical. You'll be left with no dynamic range to speak of.

Excuse me, but I'm afraid you misunderstood something here.

I think that by "clipping setting" you mean the percentage of pixels that
are allowed to clip -- which is what software tools (NetPBM for example)
often allow you to set when doing automatic normalization.

This is *not* what my 20% is about, not even related.
Consequently, it makes *no* sense to say that I'd be left with no dynamic
range: obviously, *in the worst case*, I'll end up with the very same scan
that you'll end up with if you "just scan" (bp=0, wp=255, etc, as you
suggest).

In *all* cases, I'm ending up with *no clipping* (*), so I don't quite see
how your 0.3%-0.5% clipping settings numbers could have any bearing.

(*) "no clipping" is entirely the point! since I explained that I'm assuming
a scan is thrown away and taken again if *any* amount of clipping is found
(i.e. if wp is found to be greater than 254, or bp is found to be smaller
than 1)

Quote:

[snip]

by LjL
ljlbox@tiscali.it

Lorenzo J. Lucchini
Guest

Posted: Wed Oct 26, 2005 4:40 am Post subject: [OT] Re: Sprintscan 35+, 10 bits vs 8 bits

Don wrote:

Quote:

On Thu, 20 Oct 2005 22:18:02 +0200, "Lorenzo J. Lucchini"
ljl@tiscali.it> wrote:

[snip]

No, no, no, you misunderstand. What I'm referring to is: You object to
the facts but then immediately add in the following sentence that the
facts are actually true. You do this all the time.

Cite please.

--- start ---

On Wed, 19 Oct 2005 22:03:16 +0200, "Lorenzo J. Lucchini"
ljl@tiscali.it> wrote:

sorry, I just can't agree. Yeah, they're inaccurate.

First you don't agree and then, on the same line, you agree, and then
you go on not agreeing again.

Let's put this quote into context, with "context" being what we said after
that quote:

--- CUT ---

Quote:

You said they're massively inaccurate.
I said I they are inaccurate.

Clearly I interpreted you "massively" as meaning "too much, for any
purpose", which is what I do not agree with.

--- CUT ---

As you see, I had already explained why that was not a contradiction.

And by the way, even without my interpretation of your "massively" (which,
could have been wrong, like any interpretation, but still it seems quite an
intuitive interpretation to me), my phrase would still *not* be a
contradiction: "I can't agree that they are massively inaccurate; they are
inaccurate" is not a contradiction.

Quote:

There you go #3! So, you know all this, but still keep arguing against
it!?

Well... yes.

When faced with a contradiction you admit it. And then do it again.

Ok, this sounds like a real contradiction, actually, it *is* a
contradiction: I can't say that "I know all this but argue against it".

What I meant was "I know all this, but argue against the implications you
attribute to it". I'm sorry for the over-concise, contradictory "well...
yes".

Quote:

I make "your" points because I think they're true.

And yet you then continue to argue against these "true points".

In this case, you're obviously right...

But ...

I don't see a contradiction here, even without seeing the context. I
definitely can say that you're right in some specific case, "but" not in
general, or not in the case at hand.

But let's indeed look a the context...

--- CUT ---

Quote:

Hmm... I can't really deny this when speaking about what I do with *my*
scanner, since *I* could scan at 16-bit, but instead prefer to scan at
8-bit and make some scan time adjustments.
In this case, you're obviously right (though, you know, people make
compromises for speed, storage space and all, and I don't think mine is
so terrible a compromise if done carefully).

But in the OP's case, he *cannot* scan at 10-bit (let alone 16-bit),
instead he *has* to work with 8-bit data.

--- CUT ---

So, apparently I said you were right about a case that wasn't the one
discussed in the thread! Come on!

Quote:

And then you go on to immediately contradict yourself again.

Etc... etc...

--- end ---

And that's only *some* contradictions in *one* single message!
Need more? ;o)

If you like...

However, please restrict your definition of "contradiction" to what the
dictionary says a contradiction is. Only one over three of those you cited
I recognize as a contradiction.

Quote:

[snip]

by LjL
ljlbox@tiscali.it

Don
Guest

Posted: Wed Oct 26, 2005 8:35 pm Post subject: Re: [OT] Re: Sprintscan 35+, 10 bits vs 8 bits

On Wed, 26 Oct 2005 01:40:53 +0200, "Lorenzo J. Lucchini"
<ljlbox@tiscali.it> wrote:

Quote:

Bah... sorry, I just can't agree. Yeah, they're inaccurate.

That's inconsistent. You can't say you disagree and then in the same
breath confirm what I just said (i.e. that what you disagree with is
actually correct).

You said they're massively inaccurate.
I said I they are inaccurate.

Clearly I interpreted you "massively" as meaning "too much, for any
purpose", which is what I do not agree with.

And that's the problem. First, you make unsubstantiated assumptions,
and then without confirming them, race to make an even less
substantiated guess based on those incorrect assumptions. And we end
up chasing ghosts...

"Massively" is simply a statement of fact. It means "a lot". It has
*no* reflection on subjective perception of quality whatsoever!

"too much, for any purpose" is a *subjective qualitative* judgment
*you* assigned to it wantonly! It's your *personal opinion*!

!=> Such low quality may be perfectly acceptable to many and it may be
totally unacceptable to others. I don't make any statements in this
regard either way! <=!

Quote:

And by the way, even without my interpretation of your "massively" (which,
could have been wrong, like any interpretation

There you go! Instead of interpreting focus on what was actually said.

Quote:

In this case, you're obviously right (though, you know, people make
compromises for speed, storage space and all, and I don't think mine is
so terrible a compromise if done carefully).

But in the OP's case, he *cannot* scan at 10-bit (let alone 16-bit),
instead he *has* to work with 8-bit data.

So, apparently I said you were right about a case that wasn't the one
discussed in the thread! Come on!

"Full context" means quoting the reply as well:

Quote:

Don't digress into "two bits" because that's not the point. Even with
those two bits present the proposed method of scanner software editing
would result in worse quality for many reasons, all outlined in the
thread, where you can find them. *That's* the point.

Quote:

However, please restrict your definition of "contradiction" to what the
dictionary says a contradiction is. Only one over three of those you cited
I recognize as a contradiction.

And that itself is a contradiction! ;o)

Seriously though, that's one of the problems. Nobody is being
contradictory of purpose (well, not in a serious discussion) and
failure to recognize or acknowledge a contradiction (for whatever
reason) is one reason why we end up running around in circles...

Don.

Roger S.
Guest

Posted: Wed Oct 26, 2005 8:49 pm Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

Don wrote: ""Massively" is simply a statement of fact. It means "a lot". It has no reflection on subjective perception of quality whatsoever! and then: "too much, for any purpose" is a subjective qualitative judgment you assigned to it wantonly! It's your personal opinion!" This again? I read "massively" in this context as hyperbole, as we're not talking about something "massive" and the magnitude of the problem is arguably not "massive" either. Don continued: "Such low quality may be perfectly acceptable to many..." Such low quality is a statement of relative values- compared to what and in whose judgment? The answer is in Don's judgment, and read together with the above statement reads exactly how Lorenzo interpreted it, as a subjective qualitative statement. Lorenzo wrote: ">And by the way, even without my interpretation of your "massively" (which, could have been wrong, like any interpretation" Don responded: "There you go! Instead of interpreting, focus on what was actually said. " Well, all reading is an act of interpretation. That Don's writing is full of subjective value judments and lends itself to multiple unintended interpretations is Don's problem. That he doesn't recognize it and believes all of his statements to be objective truths from the heavens makes these conversations pointless.

Don
Guest

Posted: Wed Oct 26, 2005 10:22 pm Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

On 26 Oct 2005 08:49:40 -0700, "Roger S." <rsmith02@gmail.com> wrote:

Quote:

Don continued:
"Such low quality may be perfectly acceptable to many..."

Such low quality is a statement of relative values- compared to what
and in whose judgment? The answer is in Don's judgment, and read
together with the above statement reads exactly how Lorenzo interpreted
it, as a subjective qualitative statement.

No, the decrease in quality is a factual statement because compared to
*original* data the data in question is *compromised* and, therefore,
of lower quality. That's not a judgment but a simple fact.

What *is* a judgment is whether this lower quality is acceptable or
not. Such compromised data may be acceptable to some, and may not be
acceptable to others. I pass no judgment on either choice.

Quote:

That Don's writing is
full of subjective value judments and lends itself to multiple
unintended interpretations is Don's problem. That he doesn't recognize
it and believes all of his statements to be objective truths from the
heavens makes these conversations pointless.

Ah... Sorry... For a moment there, I thought you were objective and
took your message seriously. My mistake... :-(

Don.

Guest

Posted: Thu Oct 27, 2005 5:49 pm Post subject: Re: Sprintscan 35+, 10 bits vs 8 bits

Don ha scritto:

Quote:

On 26 Oct 2005 08:49:40 -0700, "Roger S." <rsmith02@gmail.com> wrote:

Don continued:
"Such low quality may be perfectly acceptable to many..."

Such low quality is a statement of relative values- compared to what
and in whose judgment? The answer is in Don's judgment, and read
together with the above statement reads exactly how Lorenzo interpreted
it, as a subjective qualitative statement.

No, the decrease in quality is a factual statement because compared to
*original* data the data in question is *compromised* and, therefore,
of lower quality. That's not a judgment but a simple fact.

It's a fact for you. I think I have party demonstrated (partly, not
fully, but I'm willing to go further if I can understand exactly where
you disagree) that your so-called "fact" is wrong, and that it's
actually backwards -- the data in question represent an *improvement*
over the "original" data, which are otherwise treated in a way that
doesn't maximize what's possible to obtain from the "internal" bits.

Even if you didn't put "I" in the statement of your "fact", it remains
as much an opinion as my own "facts", as I don't think you've quite
substantiated it.

On the other hand, *I* have done my best, especially in the most
recent, long article, to substantiate my facts -- even though I
perfectly realize that "my best" isn't nearly the asme as "the best".

Your labelling my explanations as "irrelevant" doesn't quite cut it, as
I do *not* think they are irrelevant (oh, dangit, I've used "I"
again... I guess I just can't help it!).

Quote:

[snip]

by LjL
ljlbox@tiscali.it