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: Thu, 27 Oct 2005 18:53:19 +0200
On Wed, 26 Oct 2005 22:44:02 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:
>>>The mere fact that people *do* use their "tiny preview keyholes" to set
>>>their exposure times ought to suggest that it ain't so bad after all...
>>
>> No, the *only* thing such a statement *factually* suggests is that
>> those people have a (very?) low quality threshold. Any other
>> *interpretation* is subjective guesswork.
>
>I didn't mean to imply otherwise; in fact, that's why I've worded it as
>"ought to suggest that", rather than, say, "demonstrates that".
Oh, come on Lorenzo, the clear implication from the above statement is
that you're trying to justify a procedure (you yourself advocate!)
simply because some people may use it!
Otherwise you would've said "using the preview ought to suggest some
people have lower standards"?
But you didn't, because you wanted to put a positive spin on using the
preview in this context. Backtracking now is not going to change that.
>My article *explains* what the requirements are for "my" procedure to work;
>if *one specific scanner [software], or more than one* don't fulfill those
>requirements, tough luck.
As good as your procedure may be, that's neither the point nor the
subject. That procedure uses scanner software to edit. That's all we
need to know! What type of edit or procedure is unimportant at this
stage because the subject is: *scanner software edits degrade data*.
That's how this subthread started. You tried all sorts of different
avenues to get around it (some of it good advice, but not pertinent to
the thread). That's why I keep bringing the discussion back to this
point instead of digressing because all that does is makes us run
around in circles.
>What I'm talking about is how to get the best possible results that are
>obtainable *without* getting another scanner.
I know that's what you want to talk about, and I've been trying to
explain repeatedly that is not the subject!
But instead of addressing this key point (that your procedure is not
the subject) you go into a defense of your procedure (which I am *not*
attacking or even addressing in any way) and digress ever more from
the subject matter.
That's the problem in this thread.
>You seem to imply (well, rather more than imply, actually) that my procedure
>*causes* damage, and them does something to minimize the damage caused.
That's the key to your misunderstanding. I'm *not* attacking or
addressing your *procedure* in any way, and that's what I'm trying to
make clear (but, apparently, failing).
Your procedure is beside the point. When I say that, it's not a
criticism of your procedure. It says nothing about your procedure. It
makes no qualitative judgment of the procedure. It simply states the
procedure is not pertinent to the subject matter.
>> I'm sorry you went through all the trouble (and I hope at least others
>> can benefit from the procedure) but in the context of this thread you
>> are trying to "prove" something which is *not* even at discussion! As
>> useful and as comprehensive as your procedure may be, in the context
>> of the thread it's still an unrelated tangential digression.
>
>Really, I'm not sure, *what* is at discussion in this thread?
OK, let's see if we can agree on this:
The thread started with advice on optimum workflow for the OP's
scanner. NOTE: Optimum, as defined by the OP, meant *both*: maximum
quality *and* minimum time!
Early on, I made a *side note* (!) that any editing in scanner
software is going to cause problems regarding quality. Nothing
Earth-shattering or controversial about that. Plain vanilla.
(Implying, this may not be important to him (given his full context)
in which case just ignore. But, if it's something he does find
important, it's a good thing to make a note of.)
You objected to that (scanner software edits do harm) at which point
the thread *forked*! That fork, then, became the subject!
You devised a complex procedure as proof of your objection. Nothing
wrong with that... per se.
However, the problem is this procedure did not focus on the key
subject (reduced quality) alone but branched out to black point, etc.
(You then brought in the OP and all sorts of other things including
making many contradictory statements which didn't help things.)
That's where I said that the procedure becomes irrelevant because it
digresses. That's *not* a criticism of the procedure! However, you
took it as such and went on defending it only to digress even more!
So, the rational conclusion we can objectively and factually make:
1. Scanner software edits do harm to raw data. That's just a simple,
elementary and axiomatic fact.
2. A procedure can be devised to minimize this harm, but it can't
eliminate it.
Agreed?
If yes: Yippie! :-)
Now, let's go talk about something else...
If not: Let's agree to disagree agreeably! :-)
And then let's go talk about something else...
Don.
.
- Follow-Ups:
- 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)
- 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
- An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
- Prev by Date: Re: Questions about Nikon SA-30 roll film adapter
- Next by Date: Re: resolution
- 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
|
