Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Don <phoney.email@xxxxxxxxx>
- Date: Fri, 28 Oct 2005 17:49:25 +0200
On Fri, 28 Oct 2005 14:33:07 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:
>I thought I can also try another way to put it.
I really appreciate the thought and effort you are putting into this
Lorenzo. I really do! And I don't mean to make it frustrating for you,
but all I'm trying to point out is that, often, this effort is
misplaced.
But that doesn't mean I'm in any way criticizing or minimizing the
effort. On the contrary, I not only appreciate it but also try to
spare you from spending so much time when it doesn't address the
issue. That's all I mean by "irrelevant".
>So, WHERE IS THE PART THAT MAKES YOU SAY THAT IN-SCANNER (or in-firmware, or
>in-driver) EDITING DEGRADES THE DATA?
The problem is, Lorenzo, you're taking things out of context.
As I've explained, data degradation is not limited only to *direct*
effects of scanner software (although that usually plays a very large
part) but to *indirect* effects as well! That's the big picture.
All your effort has been to try and "prove" that *direct* negative
effects of scanner software editing can be minimized. However, you've
totally ignored the *indirect* effects.
One of these indirect effect is the fact that scanner software is very
limited in terms of features. So, additional editing will be required
afterwards in all but most trivial cases. And, as we all know,
multiple edits result in cumulative errors.
Ergo, the end result (which is the context and the subject here) will
be lower quality if half the editing is done in scanner software
(regardless of how "perfect" this editing is) and the other half in
external software.
So trying to perfect one half will not change the end result. "A chain
is only as strong as its weakest link." Improving the *strongest*
link, is not going to make the chain any stronger. Or, as I have been
stating it, improving the strongest link is "irrelevant" to the chain
strength. What increases chain strength (i.e. what is relevant) is
improving the *weakest* link! And the weakest link in this case is the
separation of editing, to name just one example.
>Unless that part is in "my procedure", but you said it wasn't, and that the
>procedure itself was irrelevant.
I didn't say that! That's the key of your misunderstanding.
It is only irrelevant when the context is the resulting quality of the
*whole* process, not just the qulaity of your procedure. In that case,
your procedure, no matter how perfect, is still only one link in the
chain. And trying to improve it, is irrelevant to the end result.
Your procedure is *very* relevant when the context is scanning stage
only. Indeed, then the scanner editing *is* the context! But that's
not the context here which is why I'm saying it's not relevant.
Don.
.
- References:
- An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Lorenzo J. Lucchini
- Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Don
- Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Lorenzo J. Lucchini
- Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Don
- Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Lorenzo J. Lucchini
- Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- From: Lorenzo J. Lucchini
- An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- Prev by Date: Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- Next by Date: Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- Previous by thread: Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- Next by thread: Re: An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- Index(es):
Relevant Pages
|