Re: Scanner Profiling: Critical or Luxury?

On Sun, 16 Oct 2005 04:02:51 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:

>>>"Often"? Why "often"?
>>
>> 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.

We are not talking about film profiles but about scanner profiles. But
even film profiles only go so far. Basically, the front end should not
be loaded with irreversible edits especially when it's the very first
step.

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

Bit depth doesn't matter in this context. It's still an edit! Just
because a profile is an "automatic correction" makes no difference.
It's still an edit because data is changed.

>Now, of course, it's still technically an edit no matter how many
>bits...

Exactly!

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

That doesn't matter. The subject is how useful a scanner profile is.

>> 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"

If it changes data, it's 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.

No, there will be *less* information because the original information
has been "corrupted" by the profile which in the above case
*amplified* the error! Now, that's bad enough but it will also reduce
"useful" dynamic range and, most likely, cause radical clipping!

>Take an easier example than color correction: gamma.
.... cut ...

Gamma is totally different because it doesn't cause clipping. Scanner
profile can and does!!! Especially when it amplifies unwanted image
bias.

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

That's inconsistent. You seem to pick and choose i.e.,

"Let's assume 16-bit internally, but let's not talk about bit depth"
or
"Scanner profile changes data, but let's not consider it an edit"

You can't have it both ways.

>>>And in the cases you end up with a step backwards, well... if you did
>>>not apply the profile, you would end up with an equal (but actually
>>>greater) number of such cases.
>>
>> 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).

None of that matters... Any time you make a change, no matter how
small, it's a change. That's all there is to it. You can't pick and
chose.

A profile changes data, irretrievably. It serves no useful purpose
unless the image is biased "the right way" *and* you do no edits
afterwards. That's all there is to it.

Of course, to each his own, as they say. If the scanner profile works
for you that's fine. But that doesn't change the fact that scanner
profiles (not to be confused with monitor or printer profiles) are of
very limited (if any) use.

Don.
.

Relevant Pages

  • Re: color profile embedding (not conversion) utility?
    ... >"embedded profile" is quite clear. ... >describes the color space of its associated file. ... e.g. raw scanner) into that color space. ... I only have Photoshop version 6 here so John's remarks are ...
    (comp.periphs.scanners)
  • Re: Profiling 35mm film scanner with IT8 targets
    ... I was wondering if anyone would care to comment on their experiences profiling a film scanner this way. ... I also use Minolta DSE 5400 with Vuescan and I am in no way a professional scanner operator however I spent some time profiling my DSE 5400 a couple of weeks ago. ... when using the scanner with built-in profile of Vuescan and color balance set to neutral I noticed my scanned slides had consistently red/magenta cast - very annoying as these were from my winter holidays ...
    (comp.periphs.scanners)
  • Re: color profile embedding (not conversion) utility?
    ... >The OP wanted to know how to assign a profile to his image ... >scanner group), and that the profile he wanted to attach was the ... Once this were done the image file could be ... While the former (color space) profile may be useful it can always be ...
    (comp.periphs.scanners)
  • Re: Scanner Profiling: Critical or Luxury?
    ... >> Not if you have to remove the damage the profile has done. ... And since scanner profile corrections are virtually always non-linear ... >dark area noise. ... Box of tone response - which is non-linear. ...
    (comp.periphs.scanners)
  • Nksagar todays paper
    ... links View profile Category: all ... Edit the title or description. ... talk back | Tell a friend ... NDA Chief Ministers strategy meet in New Delhi ...
    (uk.politics.electoral)