Re: Sprintscan 35+, 10 bits vs 8 bits

Don wrote: 
On Wed, 19 Oct 2005 15:27:07 +0200, "Lorenzo J. Lucchini"
<ljl@xxxxxxxxxx> 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.

> [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.

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.

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).

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.

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.

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.

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!

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.

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.

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.

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.

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.


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...?

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)

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.

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.

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.

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*.

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; 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@xxxxxxxxxx
.

Relevant Pages

  • Re: Sprintscan 35+, 10 bits vs 8 bits
    ... >> editing decisions will be made based on the preview keyhole i.e. they ... Just below native resolution. ... setting the whitepoint and blackpoint at scantime should do ... >so terrible a compromise if done carefully). ...
    (comp.periphs.scanners)
  • Re: scanning options for slide archival...
    ... what DPI to use for 35mm slides? ... on my Canon 9950 flatbed scanner. ... really scan at maximum resolution and bit depth. ... limited subset of editing tools) but scan "raw". ...
    (comp.periphs.scanners)
  • Re: Sprintscan 35+, 10 bits vs 8 bits
    ... > that doing adjustments at scan time still has an advantage -- that is, if the scanner really does scan at 10-bit. ... 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; however, with a decent compromise between ... 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. ... 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). ...
    (comp.periphs.scanners)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... > The KLI-10203 is a tri-linear CCD (check the FIRST line of the data ... > application) this can be set to match whatever the scanner width is - on ... that resolution is based on actual tests of scanners ... What you are missing is that not all scanning systems in flat beds use a "pass" in ...
    (comp.periphs.scanners)
  • Re: Nikon Super CoolScan 4000 ED - some questions
    ... >It is worth noting that this interpretation of resolution, ... >is basically the number of pixels that the scanner samples per inch. ... >there is no film grain at the autofocus position, ... Of course the 4,000 ppi scans contain more information than the ...
    (rec.photo.digital)