Don said:
Because given a characteristic curve of any film its bias is always in
the same direction. If the image content causes a bias (and virtually
all image content does!) then it follows that - even if we assume a
50/50 split - a substantial number of images will be considerably
degraded by having a scanner profile applied in the wrong direction.
Agreed. But find another brand of film, its bias will be different.
This, I think, goes to say that a scanner profile *alone* just isn't
terribly useful for scanning film, and that one should rather use a film
profile, if possible.
What you're forgetting is that edits are *cumulative*!
No profile + correction = 1 edit.
Profile + correction = 2 edits.
2 edits > 1 edit.
Ergo, 2 edits = more corruption.
Applying the profile can't be considered an "edit", as -- at least in my
scanner and many other flatbeds, but I stated this more than once -- it
is applied at 16-bit internally.
Now, of course, it's still technically an edit no matter how many
bits... but we know that 16-bit has quite a bit of "room to spare", at
least for current scanners: the bits you lose were made of noise to
begin with.
A scanner profile helps if image content is neutral (and if there are
no edits later!).
A scanner profile hurts if image content is biased in the opposite
direction or any further edits are required (either to remove the
profile or to enhance the profile when it doesn't go far enough).
In the latter case (enhance the profile), it doesn't. At all.
It doesn't because
1) as I said, applying the profile doesn't count as an "edit"
2) in your 8 bpc of data, there will be more useful information than if
you didn't apply the profile -- "useful" in terms of how well your bits
map to the image's content precision.
Take an easier example than color correction: gamma.
Say you have a scanner that scans with linear gamma, and you want to
output an image with linear gamma.
Say that the picture you're scanning has a gamma of 2.0 (but you don't
know this in advance).
When you scan, you tell your scanner to apply a gamma of 0.8 internally
(i.e. at 16-bit).
You look at the image, and you see you haven't *quite* hit the right
gamma, so you "edit further" (and this surely involves a bit of "damage").
But, if you didn't tell the scanner to apply gamma 0.8 internally, it'd
have been even worse, as you'd have had to make a "bigger" edit!
[snip]
How do you decide what to do? Who knows. Looks like an impasse.
But we know we can get out of the impasse by scanning at 16-bit. So, you
see, 16-bit and profile *are two separate issues*.
Not the way you framed the original question.
Simply by stressing that the internal profile application is in
16-bit, *you* have made bit depth an issue! You can't have it both
ways:
You can't say "let's assume 16-bit internally" and the turn around and
in the same breath say "but bit depth doesn't matter".
It's a non-sequitur. You can't have one without the other.
Not really true. I'm sorry for the confusion of terms, and I see what
you are saying, but...
When people say "scan at 16-bit" or "scan at 8-bit", they usually refer
to the bit depth of the data *that comes out from the scanner to their
computers through their USB bus, or whatever*.
This is the "bit depth issue" I'm thinking about.
Sure, what the scanner does internally is also "bit depth". But heck,
I've repeated that I was assuming the scanner worked at 16-bit
internally, don't know, like 10 times!
Yeah, that's "bit depth" as well, OK. But I thought it was quite clear
that it wasn't the "bit depth" I was referring to when saying that "it
is a separate issue from profiling", as I think I've taken care to
specify "you scan at 8-bit, but the scanner processes 16-bit internally"
to the point of boredom...
Now, my assumption that the scanner processes at 16 bpc internally may
well not hold true for some, or many, scanners; now, *that* would
definitely *not* be a "separate issue".
But it's an assumption that I labelled as "assumption".
But the original is virtually *never* what the end product looks like!
So additional editing will be required in all but most trivial cases.
Except when the profile goes in the opposite direction, or goes in the
right direction but not far enough.
It both those cases additional editing will be required:
2 edits > 1 edit
2 edits = more damage/corruption
Exactly as I said at the outset. What you're ignoring is that:
2 small edits <> 1 big edit!!!
Don't confuse subjective perception of the image with actual data in
the image. Yes, 2 small edits with *conceptually* produce the same
*perceived correction* as one bit edit, *but* (!):
*Any* two edits are always going to cause more damage to the data than
a single edit! It's just simple math. Cumulative errors.
Not if one of those edits is done on infinite-precision data.
Now, 16-bit is not "infinite precision" by any stretch of imagination,
but it's definitely near enough if you are "scanning at 8-bit", i.e.
your scanner is only sending 8-bit data to the computer.
Heck, you could process in floating point (which is what I do in my
program, just to be on the very safe side) and gain nothing wrt 16-bit
integer, as long as your in-scanner "edit" isn't so extreme as to cause
quantization errors in the eight most significant bits.
So, in effect, when a scanner applies a profile (or anything else) to
its *internal 16-bit data*, that's not an "edit" that can really
contribute to a cumulative error: you can see it "as if" the scanner
applied the profile using infinite-precision floating-point.
This will remain true as long as scanners don't come near 16-bit of
meaningful data, and as long as the (non)-edit you apply inside the
scanner isn't "extreme", which color correction usually isn't (and if it
is, then your scanner is probably better thrown away).
by LjL
(e-mail address removed)
