Lightroom vs Photoshop when printing.

Eric Stevens wrote:
On Sat, 28 Mar 2015 00:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

If you print... use sRGB and calibrate the monitor at a
brightness, gamma and color temperature that is as close
as possible to the specific printer.

But how can you? Your monitor is an illuminated additive RGB device
while a print is a subtractive CMYK device. The closest you can get to
what you advocate is soft proofing.

Ah, the light went on?

It's been on here for some time.

It isn't perfect, and what I said was "as close as
possible".

... and frankly that is a most peculiar idea which is almsot
impossible to realise in practise outside the world of soft proofing.

I don't understand your comment.

"Soft proofing" is exactly what is done. And if it is
otherwise impossible to do, then that is why it is
suggested as the thing to do.

I guess it depends how the soft-proofing is defined.

All of the applications I have (NX2, Photo Paint, Paintshop Pro, DxO,
Photoshop, Lightroom) take into account the ICC (colour) profile of
the target device (the particular paper in the particular printer).

The ICC profile describes the device's colour gamut, the black and
white points, and the tonal response. The nearest thing to an ICC
profile is your prescription to "If you print... use sRGB ...".

The nearest thing to an ICC profile was the comment
about adjusting brightness, gamma and color temperature
to match the "specific printer". That isn't just the
physical printer regardless of the paper, it's the
logical printer that includes whatever adjustments are
made to the driver (the RIP) and includes the effects of
different papers that those adjustments target.

1. It is safe to say that virtually no printer/paper combination has
an sRGB profile so there is no way that a screen calibrated to sRGB
can simulate it. [Calibrating the screen does not entail calibrating
it to any particular colour space, sRGB or otherwise. Calibrating a
screen entails discovering what it's particular characteristics may be
so that it can properly interpret the output of CMM (colour management
engine) of the graphics software.]

Calibrating the monitor does specify a color space.
What it doesn't specify is the brightness, gamma, and
color temperature. It adjusts for variations in the
linearity device's actual output. But a "calibrated"
monitor can be calibrated for whatever brightness, gamma,
and color temperature you choose.

2. The gamma of the target device is described by tonal response data
of the device's ICC profile.

Gamma is the slope of the brightness curve. You are
talking about how closely it matches the response of the
device. That's a correction curve.

3. The brightness of the target device is established by the whiteness
of the print paper. In fact, it is a misnomer to talk about the
brightness of a screen and that of a sheet of paper in the same
context.

Gamma is gamma, whether a screen or a paper. Same with
brightness, though in both cases obviously one is a
light source and the other is reflective and therefore
depends on the light source used to view it.

4. Printers do not have a colour temperature. The question of colour
temperature only arises when interpreting the colours of the original
image.

Papers have color tint. So do printers and drivers.

Your advice at the head of this article is both wrong and unsound in
my opinion.

Because you aren't necessarily understanding most of the
technical aspects, in particular how they relate to each
other.

--
Floyd L. Davidson http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)

On Sat, 28 Mar 2015 15:58:02 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sat, 28 Mar 2015 00:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

If you print... use sRGB and calibrate the monitor at a
brightness, gamma and color temperature that is as close
as possible to the specific printer.

But how can you? Your monitor is an illuminated additive RGB device
while a print is a subtractive CMYK device. The closest you can get to
what you advocate is soft proofing.

Ah, the light went on?

It's been on here for some time.

It isn't perfect, and what I said was "as close as
possible".

... and frankly that is a most peculiar idea which is almsot
impossible to realise in practise outside the world of soft proofing.

I don't understand your comment.

"Soft proofing" is exactly what is done. And if it is
otherwise impossible to do, then that is why it is
suggested as the thing to do.

I guess it depends how the soft-proofing is defined.

All of the applications I have (NX2, Photo Paint, Paintshop Pro, DxO,
Photoshop, Lightroom) take into account the ICC (colour) profile of
the target device (the particular paper in the particular printer).

The ICC profile describes the device's colour gamut, the black and
white points, and the tonal response. The nearest thing to an ICC
profile is your prescription to "If you print... use sRGB ...".

The nearest thing to an ICC profile was the comment
about adjusting brightness, gamma and color temperature
to match the "specific printer". That isn't just the
physical printer regardless of the paper, it's the
logical printer that includes whatever adjustments are
made to the driver (the RIP) and includes the effects of
different papers that those adjustments target.

You are now talking about a work flow which is very different from the
ordinary. It's almost certainly different from the ones used by
subscribers to the newsgroup. In fact, it sounds very much like an old
fashioned procedure from before the days of colour-managed work flow.

Except for a few specialised cases, RIP = Raster Image Processor and
is used to convert vector image data into the raster image used by
inkjet and laser printers. It's not relevant to the processing of
photographic images.

You are also talking about a 'logical printer' which is very different
from a 'specific printer'.

1. It is safe to say that virtually no printer/paper combination has
an sRGB profile so there is no way that a screen calibrated to sRGB
can simulate it. [Calibrating the screen does not entail calibrating
it to any particular colour space, sRGB or otherwise. Calibrating a
screen entails discovering what it's particular characteristics may be
so that it can properly interpret the output of CMM (colour management
engine) of the graphics software.]

Calibrating the monitor does specify a color space.
What it doesn't specify is the brightness, gamma, and
color temperature. It adjusts for variations in the
linearity device's actual output. But a "calibrated"
monitor can be calibrated for whatever brightness, gamma,
and color temperature you choose.

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

It is true that I can nominate a value for the printer's gamma but
only if I have the printer do the colour management, which I don't.
Having the printer manage the colour is generally not recommended.

2. The gamma of the target device is described by tonal response data
of the device's ICC profile.

Gamma is the slope of the brightness curve. You are
talking about how closely it matches the response of the
device. That's a correction curve.

Printers and their inks rarely exhibit the classical Gamma curve. It's
because they have so many color-dependent kinks and wiggles that their
profiles have to make use of Look Up Tables (LUT). That's why I wrote
"The gamma of the target device is described by tonal response data of
the device's ICC profile". It's not a simple single vaue for gamma.

Any way, what is the 'it' that 'matches the response of the device'?
Never mind: this getting well away from the subject of proofing an
image.

3. The brightness of the target device is established by the whiteness
of the print paper. In fact, it is a misnomer to talk about the
brightness of a screen and that of a sheet of paper in the same
context.

Gamma is gamma, whether a screen or a paper. Same with
brightness, though in both cases obviously one is a
light source and the other is reflective and therefore
depends on the light source used to view it.

The appearance of a printed image depends on the circumstances under
which it is viewed. This affects both the white point and the black
point from which the gamma is (in part) derived.

4. Printers do not have a colour temperature. The question of colour
temperature only arises when interpreting the colours of the original
image.

Papers have color tint. So do printers and drivers.

That's not the same as colour temperature.

Your advice at the head of this article is both wrong and unsound in
my opinion.

Because you aren't necessarily understanding most of the
technical aspects, in particular how they relate to each
other.
--

Regards,

Eric Stevens

Eric Stevens wrote:
On Sat, 28 Mar 2015 15:58:02 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sat, 28 Mar 2015 00:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

If you print... use sRGB and calibrate the monitor at a
brightness, gamma and color temperature that is as close
as possible to the specific printer.

But how can you? Your monitor is an illuminated additive RGB device
while a print is a subtractive CMYK device. The closest you can get to
what you advocate is soft proofing.

Ah, the light went on?

It's been on here for some time.

It isn't perfect, and what I said was "as close as
possible".

... and frankly that is a most peculiar idea which is almsot
impossible to realise in practise outside the world of soft proofing.

I don't understand your comment.

"Soft proofing" is exactly what is done. And if it is
otherwise impossible to do, then that is why it is
suggested as the thing to do.

I guess it depends how the soft-proofing is defined.

All of the applications I have (NX2, Photo Paint, Paintshop Pro, DxO,
Photoshop, Lightroom) take into account the ICC (colour) profile of
the target device (the particular paper in the particular printer).

The ICC profile describes the device's colour gamut, the black and
white points, and the tonal response. The nearest thing to an ICC
profile is your prescription to "If you print... use sRGB ...".

The nearest thing to an ICC profile was the comment
about adjusting brightness, gamma and color temperature
to match the "specific printer". That isn't just the
physical printer regardless of the paper, it's the
logical printer that includes whatever adjustments are
made to the driver (the RIP) and includes the effects of
different papers that those adjustments target.

You are now talking about a work flow which is very different from the
ordinary. It's almost certainly different from the ones used by
subscribers to the newsgroup. In fact, it sounds very much like an old
fashioned procedure from before the days of colour-managed work flow.

Except for a few specialised cases, RIP = Raster Image Processor and
is used to convert vector image data into the raster image used by
inkjet and laser printers. It's not relevant to the processing of
photographic images.

Eric... *every* print driver has a RIP internally.

You are also talking about a 'logical printer' which is very different
from a 'specific printer'.

The physical printer is the mechanical device, loaded
with a set of inks and a paper. The logical printer is
what you get by configuring the device driver. You can,
for example, load selectable profiles for half a dozen
different papers, which makes each one different. Hence
that one physical printer is now half a dozen different
logical printers.

If you configure an image to be printed it has to match
the specific logical printer that it will be sent to.

1. It is safe to say that virtually no printer/paper combination has
an sRGB profile so there is no way that a screen calibrated to sRGB
can simulate it. [Calibrating the screen does not entail calibrating
it to any particular colour space, sRGB or otherwise. Calibrating a
screen entails discovering what it's particular characteristics may be
so that it can properly interpret the output of CMM (colour management
engine) of the graphics software.]

Calibrating the monitor does specify a color space.
What it doesn't specify is the brightness, gamma, and
color temperature. It adjusts for variations in the
linearity device's actual output. But a "calibrated"
monitor can be calibrated for whatever brightness, gamma,
and color temperature you choose.

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

So if a printer can produce 99% of the colors in aRGB
any calibration process is going to discover that, and
calibrate for aRGB eh?

In fact when you set up the calibration device you'll
have to tell it which colorspace it is supposed to use.

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

Sigh... If it automatically determines the brightness
for you based on ambient light, that's wonderful. I
don't do that. I tell it what brightness level I want
the monitor set for.

If you let it automatically choose gamma 2.2 and a
temperature of 6500K, good luck to you (that is an
abomination in my opinion).

It is true that I can nominate a value for the printer's gamma but

That isn't the printer's gamma.

only if I have the printer do the colour management, which I don't.
Having the printer manage the colour is generally not recommended.

2. The gamma of the target device is described by tonal response data
of the device's ICC profile.

Gamma is the slope of the brightness curve. You are
talking about how closely it matches the response of the
device. That's a correction curve.

Printers and their inks rarely exhibit the classical Gamma curve. It's
because they have so many color-dependent kinks and wiggles that their
profiles have to make use of Look Up Tables (LUT). That's why I wrote

The LUT implements the correction curve.

"The gamma of the target device is described by tonal response data of
the device's ICC profile". It's not a simple single vaue for gamma.

That's the correction, not the gamma.

Any way, what is the 'it' that 'matches the response of the device'?
Never mind: this getting well away from the subject of proofing an
image.

3. The brightness of the target device is established by the whiteness
of the print paper. In fact, it is a misnomer to talk about the
brightness of a screen and that of a sheet of paper in the same
context.

Gamma is gamma, whether a screen or a paper. Same with
brightness, though in both cases obviously one is a
light source and the other is reflective and therefore
depends on the light source used to view it.

The appearance of a printed image depends on the circumstances under
which it is viewed. This affects both the white point and the black
point from which the gamma is (in part) derived.

4. Printers do not have a colour temperature. The question of colour
temperature only arises when interpreting the colours of the original
image.

Papers have color tint. So do printers and drivers.

That's not the same as colour temperature.

Yeah, right.


Your advice at the head of this article is both wrong and unsound in
my opinion.

Because you aren't necessarily understanding most of the
technical aspects, in particular how they relate to each
other.

No wonder this is a mystery to you.

--
Floyd L. Davidson http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)

On Sat, 28 Mar 2015 20:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

So if a printer can produce 99% of the colors in aRGB
any calibration process is going to discover that, and
calibrate for aRGB eh?

Calibration of what? A printer or a monitor? Do you know which one you
are talking about?

In fact when you set up the calibration device you'll
have to tell it which colorspace it is supposed to use.

Nonsense. The "calibration device" has to discover the limits and
characteristics of the device being calibrated. How does some other
colorspace come into it?

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

Sigh... If it automatically determines the brightness
for you based on ambient light, that's wonderful. I
don't do that. I tell it what brightness level I want
the monitor set for.

Then you have no control over the extent to which your screen image is
(or is not) going to be washed out by ambient light. Of course, you
could always guess. Do you guess?

If you let it automatically choose gamma 2.2 and a
temperature of 6500K, good luck to you (that is an
abomination in my opinion).

That puts you out on a limb, for a start.

It is true that I can nominate a value for the printer's gamma but

That isn't the printer's gamma.

Oh, what is it then?

only if I have the printer do the colour management, which I don't.
Having the printer manage the colour is generally not recommended.

2. The gamma of the target device is described by tonal response data
of the device's ICC profile.

Gamma is the slope of the brightness curve. You are
talking about how closely it matches the response of the
device. That's a correction curve.

Printers and their inks rarely exhibit the classical Gamma curve. It's
because they have so many color-dependent kinks and wiggles that their
profiles have to make use of Look Up Tables (LUT). That's why I wrote

The LUT implements the correction curve.

The penny has dropped then?

"The gamma of the target device is described by tonal response data of
the device's ICC profile". It's not a simple single vaue for gamma.

That's the correction, not the gamma.

The gamma is only an approximation to the required correction. There
is nothing magic or fundamental about it, except in mathematical
models.

Any way, what is the 'it' that 'matches the response of the device'?
Never mind: this getting well away from the subject of proofing an
image.

3. The brightness of the target device is established by the whiteness
of the print paper. In fact, it is a misnomer to talk about the
brightness of a screen and that of a sheet of paper in the same
context.

Gamma is gamma, whether a screen or a paper. Same with
brightness, though in both cases obviously one is a
light source and the other is reflective and therefore
depends on the light source used to view it.

The appearance of a printed image depends on the circumstances under
which it is viewed. This affects both the white point and the black
point from which the gamma is (in part) derived.

4. Printers do not have a colour temperature. The question of colour
temperature only arises when interpreting the colours of the original
image.

Papers have color tint. So do printers and drivers.

That's not the same as colour temperature.

Yeah, right.

Damned right.


Your advice at the head of this article is both wrong and unsound in
my opinion.

Because you aren't necessarily understanding most of the
technical aspects, in particular how they relate to each
other.

No wonder this is a mystery to you.

All that is a mystery to me is quite what you are thinking about.
I'm going back to 'proofing' an image.
--

Regards,

Eric Stevens

Eric Stevens wrote:
On Sat, 28 Mar 2015 20:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

So if a printer can produce 99% of the colors in aRGB
any calibration process is going to discover that, and
calibrate for aRGB eh?

Calibration of what? A printer or a monitor? Do you know which one you
are talking about?

Sorry, the wrong word got typed, which should be clear enough.

In fact when you set up the calibration device you'll
have to tell it which colorspace it is supposed to use.

Nonsense. The "calibration device" has to discover the limits and
characteristics of the device being calibrated. How does some other
colorspace come into it?

You have to compare it to some standard.

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

Sigh... If it automatically determines the brightness
for you based on ambient light, that's wonderful. I
don't do that. I tell it what brightness level I want
the monitor set for.

Then you have no control over the extent to which your screen image is
(or is not) going to be washed out by ambient light. Of course, you
could always guess. Do you guess?

I tell it what brightness level I want. It's not a guess.

If you let it automatically choose gamma 2.2 and a
temperature of 6500K, good luck to you (that is an
abomination in my opinion).

That puts you out on a limb, for a start.

Doesn't make sense to you, eh?

It is true that I can nominate a value for the printer's gamma but

That isn't the printer's gamma.

Oh, what is it then?

only if I have the printer do the colour management, which I don't.
Having the printer manage the colour is generally not recommended.

2. The gamma of the target device is described by tonal response data
of the device's ICC profile.

Gamma is the slope of the brightness curve. You are
talking about how closely it matches the response of the
device. That's a correction curve.

Printers and their inks rarely exhibit the classical Gamma curve. It's
because they have so many color-dependent kinks and wiggles that their
profiles have to make use of Look Up Tables (LUT). That's why I wrote

The LUT implements the correction curve.

The penny has dropped then?

"The gamma of the target device is described by tonal response data of
the device's ICC profile". It's not a simple single vaue for gamma.

That's the correction, not the gamma.

The gamma is only an approximation to the required correction. There
is nothing magic or fundamental about it, except in mathematical
models.

Any way, what is the 'it' that 'matches the response of the device'?
Never mind: this getting well away from the subject of proofing an
image.

3. The brightness of the target device is established by the whiteness
of the print paper. In fact, it is a misnomer to talk about the
brightness of a screen and that of a sheet of paper in the same
context.

Gamma is gamma, whether a screen or a paper. Same with
brightness, though in both cases obviously one is a
light source and the other is reflective and therefore
depends on the light source used to view it.

The appearance of a printed image depends on the circumstances under
which it is viewed. This affects both the white point and the black
point from which the gamma is (in part) derived.

4. Printers do not have a colour temperature. The question of colour
temperature only arises when interpreting the colours of the original
image.

Papers have color tint. So do printers and drivers.

That's not the same as colour temperature.

Yeah, right.

Damned right.


Your advice at the head of this article is both wrong and unsound in
my opinion.

Because you aren't necessarily understanding most of the
technical aspects, in particular how they relate to each
other.

No wonder this is a mystery to you.

All that is a mystery to me is quite what you are thinking about.
I'm going back to 'proofing' an image.

You probably shouldn't try discussing this with
anyone else either. At least until you study a
lot more and find out how the mechanics of it
work.

And learn what gamma is, not to mention sRGB.

--
Floyd L. Davidson http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)

On Sun, 29 Mar 2015 00:24:18 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sat, 28 Mar 2015 20:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

So if a printer can produce 99% of the colors in aRGB
any calibration process is going to discover that, and
calibrate for aRGB eh?

Calibration of what? A printer or a monitor? Do you know which one you
are talking about?

Sorry, the wrong word got typed, which should be clear enough.

It should be, but it isn't. Even on your second try you haven't told
us. What are you talking about.

In fact when you set up the calibration device you'll
have to tell it which colorspace it is supposed to use.

Nonsense. The "calibration device" has to discover the limits and
characteristics of the device being calibrated. How does some other
colorspace come into it?

You have to compare it to some standard.

You need units of measure. Usually this is one of the CIE varients
such as CIELAB, CIEXYZ or similar. These are used to define the
various colour spaces such as sRGB, AdobeRGB, Pro PhotoRGB etc. They
are also used to define device dependent profiles for monitors,
pprinters, scanners, cameras etc. There is no reason why you have to
define a colour space before you measure a device dependent profile
for the purpose of calibration.

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

Sigh... If it automatically determines the brightness
for you based on ambient light, that's wonderful. I
don't do that. I tell it what brightness level I want
the monitor set for.

Then you have no control over the extent to which your screen image is
(or is not) going to be washed out by ambient light. Of course, you
could always guess. Do you guess?

I tell it what brightness level I want. It's not a guess.

How do you determine the brightness level you want?

If you let it automatically choose gamma 2.2 and a
temperature of 6500K, good luck to you (that is an
abomination in my opinion).

That puts you out on a limb, for a start.

Doesn't make sense to you, eh?

A gamma of 2.2 and a colour temperature of 6500K are virtually
industry standards and you usually need some special case before you
depart from them.

--- long tail of nothing new snipped ---
--

Regards,

Eric Stevens

Eric Stevens wrote:
On Sun, 29 Mar 2015 00:24:18 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sat, 28 Mar 2015 20:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

So if a printer can produce 99% of the colors in aRGB
any calibration process is going to discover that, and
calibrate for aRGB eh?

Calibration of what? A printer or a monitor? Do you know which one you
are talking about?

Sorry, the wrong word got typed, which should be clear enough.

It should be, but it isn't. Even on your second try you haven't told
us. What are you talking about.

"Calibrating a monitor doesn't specify a colour
space. It discovers a colour space: the colour space
within which the monitor is capable of working." *Is* *not*
*correct*.

You *specify* the color gamut for *monitor* *calibration*.

In fact when you set up the calibration device you'll
have to tell it which colorspace it is supposed to use.

Nonsense. The "calibration device" has to discover the limits and
characteristics of the device being calibrated. How does some other
colorspace come into it?

You have to compare it to some standard.

You need units of measure. Usually this is one of the CIE varients
such as CIELAB, CIEXYZ or similar.

What are *you* talking about? What "units of measure"?
Those describe a color model, they are not a unit of
measure.

My monitor calibration can use aRGB, sRGB, EBU, REC709,
REC1886, REC1885, SMPTE-C, DCI, or it can use the
monitor's native color gamut. Of course in practice
only aRGB and sRGB are practical options for my use.
DCI is "Digital Cinema Standard" and the others are all
"Broadcasting" Standards.

These are used to define the
various colour spaces such as sRGB, AdobeRGB, Pro PhotoRGB etc. They
are also used to define device dependent profiles for monitors,
pprinters, scanners, cameras etc. There is no reason why you have to
define a colour space before you measure a device dependent profile
for the purpose of calibration.

But when you do calibrate a monitor, you do have to
specify what you want.

Stop talking in circles. And get a clue about the
difference between calibrating a monitor and making a
soft profile used by your editing software.

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

Sigh... If it automatically determines the brightness
for you based on ambient light, that's wonderful. I
don't do that. I tell it what brightness level I want
the monitor set for.

Then you have no control over the extent to which your screen image is
(or is not) going to be washed out by ambient light. Of course, you
could always guess. Do you guess?

I tell it what brightness level I want. It's not a guess.

How do you determine the brightness level you want?

Same way I determine what speed to drive at, how much to
cook dinner, when to get a drink of water, and when to
decide Eric is playing games. Experience!

I don't set the brightness level to 120 cd/m2. I don't
let the calibration software set it either. And while I
don't really know, my bet is that you don't do that
either!

My calibration setup measures ambient light, and tells
me what it is, but it does not change anything because
of it.

If you let it automatically choose gamma 2.2 and a
temperature of 6500K, good luck to you (that is an
abomination in my opinion).

That puts you out on a limb, for a start.

Doesn't make sense to you, eh?

A gamma of 2.2 and a colour temperature of 6500K are virtually
industry standards and you usually need some special case before you
depart from them.

Industry standard for sRGB as is used on the Internet.

Prints are not!

Just in case you are interested, my monitor is
calibrated at 80 cd/m2, with the color temperature at
5000 K, a gamma of 2.4, and for a color gamut of sRGB.
All of those values are entered manually.

My calibration absolutely is a little different than
yours. I calibrate every two weeks. And you do a
software calibration that changes what the video card
sends to the monitor, while I do a hardware calibration
of the monitor itself, which changes how the monitor
displays what comes from the video card.

--
Floyd L. Davidson http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)

On Sun, 29 Mar 2015 16:34:21 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sun, 29 Mar 2015 00:24:18 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sat, 28 Mar 2015 20:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---

Calibrating a monitor doesn't specify a colour space. It discovers a
colour space: the colour space within which the monitor is capable of
working.

So if a printer can produce 99% of the colors in aRGB
any calibration process is going to discover that, and
calibrate for aRGB eh?

Calibration of what? A printer or a monitor? Do you know which one you
are talking about?

Sorry, the wrong word got typed, which should be clear enough.

It should be, but it isn't. Even on your second try you haven't told
us. What are you talking about.

"Calibrating a monitor doesn't specify a colour
space. It discovers a colour space: the colour space
within which the monitor is capable of working." *Is* *not*
*correct*.

You *specify* the color gamut for *monitor* *calibration*.

You and I seem to have a fundamental difference of opinion at this
point and yours makes no sense to me.

In a modern colour managed work flow the gamut of the PCS (Profile
Connection Space) is wider than any colour space one is likely to
encounter in the real world (other than, possibly, Pro Photo RGB).
Before the colour values stored in the PCS can be displayed on the
monitor, or printer, or other output device it is necessary to
establish the full range of colours that the device can display and
the relationship of those colours to the colour values within the
colour space.

An image within a colour managed work flow will be associated with a
particular colour space (This may have been changed from the colour
space with which it came in). That colour space will almost certainly
be smaller than that of the PCS. The first step of displaying the
image is converting it to the colour space associated with the image.

The first question which arises is 'can the colour gamut of the
converted image fit within the gamut of the monitor?'. If the answer
is 'yes', then go ahead and squirt the image on the screen. If the
answer is 'no' then we enter a whole new ball game which I have no
desire to pursue at the present.

Exactly the same situation applies to a printer. Either it can, or
cannot, reproduce all the colours that are contained within the image.
If it can't, then matters get even more complex than in the case of a
screen.

Virtually all screens can display the gamut of sRGB. Many have a gamut
very close to that of AdobeRGB. Printers are more variable but with
the right paper the better printers are very close to AdobeRGB.

There are so many variables that it never has been practicable to set
up the entire production to match one particular set of circumstances.
One does not calibrate a monitor to suit a colour space. One uses the
power of the computer to manipulate the image data so that a correctly
colored and toned image emerges from the discovered characteristics of
the monitor.


In fact when you set up the calibration device you'll
have to tell it which colorspace it is supposed to use.

Nonsense. The "calibration device" has to discover the limits and
characteristics of the device being calibrated. How does some other
colorspace come into it?

You have to compare it to some standard.

You need units of measure. Usually this is one of the CIE varients
such as CIELAB, CIEXYZ or similar.

What are *you* talking about? What "units of measure"?
Those describe a color model, they are not a unit of
measure.

They describe colour models in which (usually) groups of three
numerical values are used to describe particular hues and intensities.
It is these numerical values which are used to define all the various
colour spaces for which you have gone mining (by the way, you missed
some :-).

My monitor calibration can use aRGB, sRGB, EBU, REC709,
REC1886, REC1885, SMPTE-C, DCI, or it can use the
monitor's native color gamut. Of course in practice
only aRGB and sRGB are practical options for my use.
DCI is "Digital Cinema Standard" and the others are all
"Broadcasting" Standards.

These are used to define the
various colour spaces such as sRGB, AdobeRGB, Pro PhotoRGB etc. They
are also used to define device dependent profiles for monitors,
pprinters, scanners, cameras etc. There is no reason why you have to
define a colour space before you measure a device dependent profile
for the purpose of calibration.

But when you do calibrate a monitor, you do have to
specify what you want.

So you have to change monitor profiles every time you get an image
with a different color space?

Stop talking in circles. And get a clue about the
difference between calibrating a monitor and making a
soft profile used by your editing software.

I have a soft profile which is usedy every application on the computer
(unless I select a different profile).

With regard to brightness, gamma and colour temperature, I use the
Datapoint Spyder and the first thing it does is measure the ambient
light level. Then it specifies the target brightness for the monitor
at that light level. When that has been achieved I can carry on and
have the monitor calibrated to the generally accepted values of a
gamma of 2.2 and a colour temperature of 6500K. Nowhere in the process
is any consideration given to to the brightness or colour temperature
of the printer, as if printers had these things.

Sigh... If it automatically determines the brightness
for you based on ambient light, that's wonderful. I
don't do that. I tell it what brightness level I want
the monitor set for.

Then you have no control over the extent to which your screen image is
(or is not) going to be washed out by ambient light. Of course, you
could always guess. Do you guess?

I tell it what brightness level I want. It's not a guess.

How do you determine the brightness level you want?

Same way I determine what speed to drive at, how much to
cook dinner, when to get a drink of water, and when to
decide Eric is playing games. Experience!

Another name for guessing.

I don't set the brightness level to 120 cd/m2. I don't
let the calibration software set it either. And while I
don't really know, my bet is that you don't do that
either!

With my current setup I have set the brightness to 200 cd/m2. If it's
not close to that, Spyder will tell me it can't properly calibrate the
monitor.

My calibration setup measures ambient light, and tells
me what it is, but it does not change anything because
of it.

If you let it automatically choose gamma 2.2 and a
temperature of 6500K, good luck to you (that is an
abomination in my opinion).

That puts you out on a limb, for a start.

Doesn't make sense to you, eh?

A gamma of 2.2 and a colour temperature of 6500K are virtually
industry standards and you usually need some special case before you
depart from them.

Industry standard for sRGB as is used on the Internet.

Prints are not!

Hmm.

On page 69 of 'The Digital Print' Jeff Schewe writes "I suggest D65
and a gamma of 2.2 ...".

On page 133 of the second edition of 'Real World Color Management'
Bruce Fraser, Chris Murphy and Fred Bunting write:

"For CRT displays the three of us, by separate paths, have come to
the same recommended calibration settings: calibrate your monitor
to a white point of 6500 K and a gamma of 2.2. You can just take
our word for it, but we think it's useful to understand why we like
white point-6500 K, and gamma-2.2, so we'll discuss that in the
next section.
For LCD displays, the only thing you can typically adjust on the
monitor itself is the brightness of the backlight. Changes to the
color temperature are carried out in the videoLUT, so we recommend
using the native white point for LCDs whenever the software allows
us to do so. If native white point isn't an option, we use D65
because the color temperature of most LCD backlights is closer to
D65 than to anything else."


Just in case you are interested, my monitor is
calibrated at 80 cd/m2, with the color temperature at
5000 K, a gamma of 2.4, and for a color gamut of sRGB.
All of those values are entered manually.

My calibration absolutely is a little different than
yours. I calibrate every two weeks. And you do a
software calibration that changes what the video card
sends to the monitor, while I do a hardware calibration
of the monitor itself, which changes how the monitor
displays what comes from the video card.

--

Regards,

Eric Stevens

On Mon, 30 Mar 2015 15:54:23 +1300, Eric Stevens
wrote:

Just in case you are interested, my monitor is
calibrated at 80 cd/m2, with the color temperature at
5000 K, a gamma of 2.4, and for a color gamut of sRGB.
All of those values are entered manually.


I meant to add 'You mention nothing which tells you how faithfully the
display will reproduce the colour of the image".
--

Regards,

Eric Stevens

Eric Stevens wrote:
On Mon, 30 Mar 2015 03:21:29 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sun, 29 Mar 2015 22:10:59 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sun, 29 Mar 2015 16:34:21 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sun, 29 Mar 2015 00:24:18 -0800, (Floyd L.
Davidson) wrote:

Eric Stevens wrote:
On Sat, 28 Mar 2015 20:28:05 -0800, (Floyd L.
Davidson) wrote:

--- snip ---


Calibrating a monitor doesn't specify a colour space. It discovers a

Lets not forget that you still haven't admitted how
wrong you were on the basis for this entire discussion.

Nice diversion.

I say " ... then we enter a whole new ball game which I have no
desire to pursue at the present."

But you then do go right ahead with a diversion trying to find at
least something that you can talk about without showing off a how
you've said things out of ignorance.

....
Now you call my response to you a "Diversion".

Because all it amounted to was distancing yourself from
admitting that calibrating a monitor requires specifing
the color space. It isn't "discovered", it is one of
the paramenters the user sets.

Exactly the same situation applies to a printer. Either it can, or
cannot, reproduce all the colours that are contained within the image.
If it can't, then matters get even more complex than in the case of a
screen.

Actually it is exactly the same problem.

Duh!

Read the first line of my previous paragraph.

And then read how you contradict yourself with that last
sentence in the paragraph.

There is no contradiction.

"Exactly the same" to start with, but "even more complex"
when it isn't exactly the same. Yes Eric, that is a
contradiction.

In fact "aRGB" is a common abbreviation for Adobe RGB (1998). It has
nothing to do with 8-bit color. It is a color space.

I've never heard or seen of AdobeRGB being referred to in that way
before. On the other hand I have heard of aRGB as a reference to a
common 8-bit encoding. There is also RGBa which is different.

You cannot provide anything that relates it to "common
8-bit encoding", whatever that is supposed to mean.
RGBA is indeed something different than aRGB. "DUH!"

However, if Google searches on these words:

"aRGB" "sRGB" color space

it comes up with thousands of examples of using "aRGB"
as shorthand for Adobe RGB (1998). Which is not in the
slightest new or surprising, considering how much easier
it is to type "aRGB" and how similar it is to sRGB.

The real problem here is how can you presume to claim
any kind of authority on this topic when you are that
unfamiliar with it?

Stop pronouncing what is, and start asking!

It's a misleading misuse of the descriptor.

Meaning you just aren't at all well versed on this subject.

...
You need units of measure. Usually this is one of the CIE varients
such as CIELAB, CIEXYZ or similar.

What are *you* talking about? What "units of measure"?
Those describe a color model, they are not a unit of
measure.

They describe colour models in which (usually) groups of three
numerical values are used to describe particular hues and intensities.

So they are not "units of measure" at all.

Of course they a three dimensional coordinates.

That is not a unit of measure. Inches, Hertz, gallons and
such are units of measure. A ruler is not a unit of measure, and
neither is a graduated beaker.

Colour spaces are defined numerically. See
http://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/CIE1931xy_blank.svg/300px-CIE1931xy_blank.svg.png
or http://tinyurl.com/obq6zfz

The container is not a "unit of measure".

You were just trying to work "buzz words" into your
commentary in order to appear as if you knew something.
But not knowing what the buzz words actually meant, you
used them in a way that very clearly demonstrated how
little you understood the topic.

It is these numerical values which are used to define all the various
colour spaces for which you have gone mining

That defines the color space, it is not a unit of
measure. It is not a color gamut either, it's a way to
define and compare a color gamut within that color space.

You are rambling.

Precision is just the opposite of rambling.

At least we agree on something.

So don't you be claiming my precision with terminaology
is some form of rambling just because you don't have
enough familiarity with the subject to understand.

If I do that, why not just say you don't understand and
ask for a different description on a lower plane of
complexity?

When we started this discussion I actually took you at
your word on your level of familiarity. Then we go down
a list of differences, all the result of non-familiarity,
and it seems a simple case that you unnecessarily
misrepresented yourself.

Everyone with using a managed workflow changes profiles
depending on the image and the output device.

I don't.

Your editing program does, where you realize it or not.

Of course I realise that. That's why I don't have to change it myself.

So why claim you don't use different profiles when you
do! Just trying to be obstinate, and not really
understanding the discussion...

I've described in detail that it is measured. I'm sorry
that went over you head. I tell the calibration program
what brightness I want, it measures the output adjusts the
brightness control to get that value.

This is the first time you have mentioned a calibration program. What
do you use?

I've mentioned it several times. Obviously I use
various programs, none of which you have ever used. It
makes no difference what they are as you will not be
able to relate the name to anything useful.

The way the Spyder 4 (and some other similar devices) operates is,
after a sensor is placed on the screen, to run a quick series of both
gray scale and color blocks from (0,0,0) to (255,255,255). This
enables it to make a quick evaluation of the dynamic range of the
monitor. It has already measured the incident light at the work
station and from this it is able to calculate the screen brightness
required for the proper setting of the white point. There is no
guessing, estimation or experience required for the determination of
the screen brightness. It is calculated from the measured lighting of
the screen and it's environment.

The program is taking a guess at what will be
appropriate screen brightness for the ambient light
level. It might well be more appropriate than what you
personally would guess at. The program will match only
what the "average" knowledgeable choice would be.

For users that need higher or lower brightness that will
be the wrong choice.

I then have to adjust the on-screen brightness control and have Spyder
take a measurement. If the brightness is too high or too low I have to
make an adjustment and try again. When it is sufficiently close to the
brightness calculated by Spyder it can then proceed with the rest of
the calibration procedure.

You don't even know what yours is set to, other than
whatever the default is!

You still haven't been able to specify what it actually is!

....
So why not give a value??? It absolutely is not 200 cd/m2!
That is only what monitor hardware is set to, and after
calibration you video card literally cannot send a signal that
will produce anything near that bright!

That's the white point!

That's one term for it! A good one too. So what is the
target "white point" on your monitors when you calibrate
them?

....
See, you think you are calibrating the monitor to 200 cd/m2, and
that is not the case.

See above. I most definitely am.

Hilarious. You aren't.

....
Eizo puts out a nice calibration package, and has an online
pdf format user manual ColorNavigator_6_How-to-Use-Guide.pdf
that you can download and read.

I've just looked at this. The CG series of Eizo monitors have built in
sensors. The CX and CS make use of what is clearly a Spyder 4, which
is what I use and employs the procedure I have described above.

The CG series of Eizo monitors are the ones designed for
photography.

You still are missing the difference between you using
software calibration that sets an LUT for the video card
and being able, as the Eizo CG monitors are, to use
hardware calibration the set the LUT in the monitor.

....
"Compared to software, hardware calibration is much
more accurate and there is no need to modify color
output through the graphics card." Nasim Mansurov
https://photographylife.com/how-to-p...u3014-monitors

It is significant.

That's interesting. I have a pair of matched (slightly earlier) Dell
2410 monitors. They are calibrated in exactly the same way by Spyder 4
as the article describes the 2413 being matched by the X-Rite. As
described by the paragraph '6) Hardware LUT Calibration Process' I
have the choice of setting it up to a number color spaces. I use
AdobeRGB. That does not mean that it is suited to displaying only
AdobeRGB images. It means that images that pass through the monitor's
LUT are converted to the AdobeRGB range of colours and gamut.

The Dell U2410 is a fairly decent monitor, and a very
good value for the money. It does have an internal
12-bit LUT that is used for *factory* calibration to
provide gamut emulation.

Your calibration software cannot access the monitor's
LUT. What you can set is your video card. The cited
URL above, if you had read it carefully enough, even
specifically says that only the models listed, all high
end and newer, are capable of hardware calibration.

Who cares whether the calibration is done in the monitor or the video
card. The point is the monitors are calibrated.

Well, who cares if you don't need accurate repeatable
results, that is true. People calibrate laptop monitors
too. Is that part of your 'who cares'?

It makes a difference. That's why it exists in high end
monitors.

....
You are not able to read very well. Go back and read it
carefully where I said it is calibrated every two weeks.
And unlike you, I can actually do a hardware calibration,
which everyone says (for good reason) is more accurate.

It's more accurate only in the light of a number of assumptions which
are not necessarily relevant.

Oh, you know better than Dell, NEC or Eizo eh?

Name such an assumption and explain how it is not
relevant. Sounds like another of your empty headed bits
of stubborness in the face of facts that contradict what
you've claimed in ignorance and been called on.

The fact is you won't find anyone that agrees with you.
Worse you will find that every expert on the subject
says that hardware calibration is more accurate.

--
Floyd L. Davidson http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)