Digital BW, The Print

Well?  Pardon the ignorance.

Thank you.

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "luisvcool" 
<lvictoria@t...> wrote:
> Well?  Pardon the ignorance.
> 
> Thank you.

It sure seems to leave one around here whenever we discuss it.<P>

B.O. stands for "Black Only", and it's one of the settings in the 
printer driver for Epson printers.   It tells the printer to ONLY 
use its black ink.

Making black and white prints with an inkjet printer is very tricky 
because most inkjet printers have 6 or 7 inks and render shades of 
gray by combining them.  Unfortunately getting them all to stay in 
balance across all tonal ranges, and to have the same tonal 
characteristics in all different kinds of light is like trying to 
TRAIN CATS TO MARCH IN FORMATION.

A variety of alternatives exist - - -  Using special third party 
inksets that ONLY have shades of gray (hextone or quadtone); using 
Raster Image Processors (RIPS) that have their own drivers and don't 
use all the different inks, in order to simplfy the problem; or 
outputting black and white digital files to conventional 
photographic paper via Lambda or Frontier technology, and B.O. 
printing.

B.O. printing is the poor-man's way of making neutral black and 
white prints with an inkjet printer.   The printer makes grayscales 
by printing black dots in various ratios to the underlying white 
paper.   Here's a greatly enlarged sample: http://studio-
nelson.com/inkjet/ijimages/edbo1a.jpg of a 5% black section of a 
wedge.

Because the dots have to be spaced at quite a distance to achieve 
light grays they are quite visible and tend to create a noticable 
texturing in skin tones, light sky tones and other places on the 
print where a hextone print would be smooth.   Some people don't 
find them objectionable, and some people even LIKE it, but most 
people switch to one of the alternatives as soon as they can afford 
it.

Hi Peter,

> B.O. printing is the poor-man's way of making neutral black and
> white prints with an inkjet printer.   The printer makes grayscales
> by printing black dots in various ratios to the underlying white
> paper.   Here's a greatly enlarged sample: http://studio-
> nelson.com/inkjet/ijimages/edbo1a.jpg of a 5% black section of a
> wedge.
>
> Because the dots have to be spaced at quite a distance to achieve
> light grays they are quite visible and tend to create a noticeable
> texturing in skin tones, light sky tones and other places on the
> print where a hextone print would be smooth.   Some people don't
> find them objectionable, and some people even LIKE it, but most
> people switch to one of the alternatives as soon as they can afford
> it.

Understood...but what is there to doing this aside from printing using the
standard driver and selecting "Black Only" that was being heralded in
another post?

Regards,

Austin

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Austin 
Franklin" <darkroom@i...> wrote:

> Understood...but what is there to doing this aside from
> printing using the standard driver and selecting "Black 
> Only" that was being heralded in another post?

Creating the right transfer function is ESSENTIAL, as it is in any 
digital printing practice.   There are many ways of doing this - the 
Curve adjustment tool in Photoshop is one way, creating a Curve 
adjustment layer is another.  Creating custom profiles is also a way 
to shape the transfer function.  One of my new favorites is creating 
a set of custom gradient maps in Photoshop.  I have ones for 
stretching the midtones, brightening the shadows, etc. 

All of these (and there are plenty of others) do the same thing - 
they determine how a particular RGB or grayscale value in the 
original image will be represented to the printer for output.  

Most of us have a test image we use.  Mine consists of a continuous  
0-255 wedge plus additional wedges with calibrated step functions in 
the shadow, midtone, and highlights, plus a sample image of a model 
with smooth slik tones from shadow to specular highlight. 

One of B.O.'s characteristics is that it produces a highly textured 
output (because of the dotting) in certain density ranges.   One of 
the goals of your transfer function is either
A. to place that texturing in parts of the image that are less 
prominent if you don't want to see it  . . . or . . . 
B. emphasize it, if that's why you're using B.O. in the first place.

The resident expert here on B.O. curve adjustment is Clayton Jones 
so he can give you detailed advice, depending on your goals.

> > Understood...but what is there to doing this aside from
> > printing using the standard driver and selecting "Black 
> > Only" that was being heralded in another post?
> 
> Creating the right transfer function is ESSENTIAL ...

Yes, but at a more simple level (one of the main points of BO
printing is to help newbies get started with minimal frustration),
I'd answer: after you select "Black Only" you'll get a warning
that it's suitable only for text; ignore this, and then
go to "Advanced Settings" and bump the resoultion up to 1440 or
2880dpi.

John

Peter,

> Creating the right transfer function

"transfer function"?  I've never heard this called "transfer
function"...where did you get that?

> There are many ways of doing this - the
> Curve adjustment tool in Photoshop is one way, creating a Curve
> adjustment layer is another.  Creating custom profiles is also a way
> to shape the transfer function.  One of my new favorites is creating
> a set of custom gradient maps in Photoshop.  I have ones for
> stretching the midtones, brightening the shadows, etc.

Everything you describe, from what I can tell, is simply tonal adjustment
curve...and in simpler terms, a LUT (Look Up Table)...I'm not sure why you
call it "transfer function", but I agree, that adjusting the tonal curve is
how one would move the tones around to make them "fall" where you might find
them more beneficial for different printing "methodologies"/dithering
algorithms.

> All of these (and there are plenty of others) do the same thing -
> they determine how a particular RGB or grayscale value in the
> original image will be represented to the printer for output.

Perhaps this is what you meant, but were being more simplistic, but they
don't "represent" anything to the printer, they "represent" it to the
dithering algorithm, as the pixel values are converted to dots before being
printed.

Regards,

Austin

Please forgive my limited English understanding (and expression ability)
but when one talks about a LUT I understand "a list consisting of
limited amnt. of rows consisting from actual value -> converted value",
if one talks about a transfer *function* there are no limited samples
such a LUT but a "mathematical equation giving converted values for
every possible actual values"... A tonal adjustment curve is a transfer
function not a LUT (if it were so, we would have different set of curves
for 8 and 16 bit modes - and the 16bit mode curve files' size would be
256K)

Regards,
Loris.

> -----Original Message-----
> From: Austin Franklin [mailto:darkroom@...] 
> Sent: Tuesday, July 29, 2003 4:39 AM
> To: DigitalBlackandWhiteThePrint@yahoogroups.com
> Subject: RE: [Digital BW] Re: What is BO!!!!!? Bad odor?
> 
> ...
> Everything you describe, from what I can tell, is simply 
> tonal adjustment curve...and in simpler terms, a LUT (Look Up 
> Table)...I'm not sure why you call it "transfer function", 
> ...

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Austin 
Franklin" <darkroom@i...> wrote:
> Peter,
> 
> > Creating the right transfer function
> 
> "transfer function"?  I've never heard this called "transfer
> function"...where did you get that?

That's the general term.  Professionally I'm an engineer 
specializing in image processing.  I say transfer function because 
it's more correct.   Same reason I distinguish PPI from DPI.  

The problem with saying "curves" like lots of people here do is that 
some people are likely to only think in terms of Photoshop Curves 
tool or a Curve Adjustment Layer.   Transfer function is the generic 
term for anything that defines the relationship between some input 
value and some output value.  (or as we say in my R&D lab, "the 
relationship betweenthe the gazintas and gazoutas")<P>

And I really should say "functionS" because there's actually a 
pipeline of transfer functions between the original image file and 
the dots of ink on the paper and they all need to be characterized.

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Loris Medici" 
<lorism@t...> wrote:
> Please forgive my limited English understanding (and expression 
ability)
> but when one talks about a LUT I understand "a list consisting of
> limited amnt. of rows consisting from actual value -> converted 
value",
> if one talks about a transfer *function* there are no limited 
samples
> such a LUT but a "mathematical equation giving converted values for
> every possible actual values"... A tonal adjustment curve is a 
transfer
> function not a LUT (if it were so, we would have different set of 
curves
> for 8 and 16 bit modes - and the 16bit mode curve files' size 
would be
> 256K)

I work as an image-processing engineer in an R&D lab and there is 
incomplete agreement among my clleagues whether "transfer function"  
continous values - most people accept that it could be discrete 
values but a few prefer "mapping funtion" for anything implemented 
in a LUT.  My guess is that most of the curves we see in Photoshop 
and profile-creation tools are actually implemented somewhere as 
LUTs simple because they are easy to implement that way, easy to 
edit, and readily accomodate pixels values that are already in a 
discrete domain (i.e., a pixel might be 253 or 254 but not 253.5).  
But, nonetheless, I chose the term "transfer function" instead 
of "curves" or "LUT", because I wanted a generic term that wasn't 
specific to a particular tool or implementation, and because it's a 
term regularly used in image and signal processing, which IS after 
all, what we're talking about here.

Peter,

> > > Creating the right transfer function
> >
> > "transfer function"?  I've never heard this called "transfer
> > function"...where did you get that?
>
> That's the general term.  Professionally I'm an engineer
> specializing in image processing.  I say transfer function because
> it's more correct.

I disagree that it's "more correct".  "Transfer function" is far less
precise term than LUT, or any more descriptive term for this...even tonal
curve adjustment is more precise, as that IS what is happening, no matter
how it's implemented.

> Same reason I distinguish PPI from DPI.

But these are two distinct things, and they should be distinguished.

> And I really should say "functionS" because there's actually a
> pipeline of transfer functions between the original image file and
> the dots of ink on the paper and they all need to be characterized.

I believe you're being overly pedantic calling it a "transfer function".
It's too general a term, as it doesn't describe what is happening, and it's
also not commonly used by imaging engineers when discussing simple tonal
curve adjustment..we certainly don't say "well, we'll just use a transfer
function here", we describe what is to happen, not that something is to
happen.  At least no one in my 25 years in the imaging industry has ever
used that term for simple tonal curve adjustments.  What you were describing
is merely addition, typically implemented as a LUT.  Yes, more happens after
the tonal curve adjustment before ink gets to the paper, but we weren't
talking about that.

Regards,

Austin

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Austin 
Franklin" <darkroom@i...> wrote:

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

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.
2.  It is the technically correct term.  I work in image processing 
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".


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

> Yes, more happens after the tonal curve adjustment before 
> ink gets to the paper, but we weren't talking about that.

I was.  That's why I brought it up.  It's important for us to 
understand, and be able to manipulate as much as possible every step 
in the processing pipeline from the RGB values in our original image 
before Photoshop ever touches it, to when the printer sprays dots of 
ink on the paper.

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