Digital BW, The Print

Peter,

> > I disagree that it's "more correct".  "Transfer function"
> >is far less precise term than LUT
>
>
> Being less precise is EXACTLY why it's more correct.
>
> As I said in my prior post, I wanted a generic term.  "Generic"
> and "precise" are opposites.

Come on.  On one hand you say you're not generalizing, but on the other you
say you are being generic?  So you are trying to be generic, but pedantic?
That makes no sense.

> The problem with LUT is that it's specific to a particular
> implementation, and furthermore we don't even know which, if **ANY**
> Photoshop or driver features are implemented with LUTs (although I
> suspect many are).   So LUT is about as bad a term as you can get
> because there's no way to know when it's correct.
>
> The problems with "curves" is twofold -  1,  The actual term "Curves"
> is used for some Photoshop tools, which makes it ambiguous because
> the reader doesn't know if you are speaking gererically or about a
> specific tool, and two, not all transfer functions are represented
> with curves.
>
> "Transfer Function" has two advantages:
> 1. It's generic - it describes ANY module, tool, or stage, where one
> set of values is mapped to another, thus encouraging users to think
> outside the box.

No, that is NOT what transfer function means.  It is means ANY operations,
not simply "mapping".

> 2.  It is the technically correct term.

I disagree.  As I've said, it is TOO generic, and therefore describes not a
single thing.  Every operation that takes an input and gives an output is a
transfer function.

> I work in image processing

Right, Peter, I understand, you've said that...and I also "work in" image
processing and have for 25+ years.

> and my colleagues and I were discussing this today.  The consensus
> was that if we don't say "transfer funtion" then the only other
> correct term would be "mapping function".

Mapping describes the function, and is not synonymous with transfer
function, as transfer function encompasses far more than simply mapping
function.  BTW, can you describe a mapping function that can't be
implemented in a LUT?

> > What you were describing is merely addition, typically
> > implemented as a LUT.
>
> A LUT doesn't do addition; it takes an index and outputs a value.

A LUT very much so can "do" (provide the function of) addition, along with
many other functions.  Yes, it takes an index and outputs a value, but, as I
said, many different operations can be implemented in a LUT.  A LUT is
typically how offset correction is done, especially in calibrated systems
(such as a film scanner calibration for linearity), and that is in fact
simple addition implemented as a LUT.

When used as we are talking about, for storing tonal correction curves, it
is providing a predetermined/deterministic output value for input value, and
that output value was determined by addition.  When you move the tonal
curve, you are taking the original value (with is typically output == input,
linear), and adding some offset to it, by moving the curve up or down.  What
gets put in as the new value in the indexed location is determined by the
original value, plus that new offset, which is why I said the LUT is
implementing addition.  I've designed tonal curve manipulation functions,
implemented in both hardware/firmware and done as pure software, and this is
how they worked.

Regards,

Austin