Chris Cox wrote:

In article , Mike
Russell wrote:

Mike Engles wrote:
...
[re linear encoding of specialized pixel data values]

Is the same true for imaging from spacecraft, interplanetary or
otherwise or is gamma encoding done before transmission?

Yes. Gama encoding compresses some data values, and there is no reason to
do this to raw data from a spacecraft.

Here's an article that may interest you, by Alvy Ray Smith, on the
distinction of work and display color spaces.
http://alvyray.com/Memos/MemosMicros...rAlphaQuestion

Actually, Alvy has a number of mistakes in that paper.
I'm still not sure if he understands gamma encoding...

Chris


Hello

Yes there does seem to some confusion about PC Gamma, but he is
absolutly clear about the need for linear processing. As for not
understanding Gamma encoding, that is not clear from the article. He has
been around a long time, and does know a thing or two. If gamma encoding
were that important he would have mentioned it. He is totally clear
about not applying any non linearity to a image, just to the display
device. I assume from this he means the same for storage, but I don't
know.

Suffice to say that he and his collaborator are MAJOR digital graphics
imaging authorities who on the face of it supports Timo Autiokari's
lonely stance. His last words in the gamma article are telling.

Mike Engles

Mike Engles wrote:
[re alvy gamma article]

Hello

Yes there does seem to some confusion about PC Gamma, but he [Alvy] is
absolutly clear about the need for linear processing. As for not
understanding Gamma encoding, that is not clear from the article. He
has
been around a long time, and does know a thing or two. If gamma
encoding
were that important he would have mentioned it. He is totally clear
about not applying any non linearity to a image, just to the display
device. I assume from this he means the same for storage, but I don't
know.

Suffice to say that he and his collaborator are MAJOR digital graphics
imaging authorities who on the face of it supports Timo Autiokari's
lonely stance. His last words in the gamma article are telling.

Mike Engles

Right on. Alvy has another article, written in 1995, that goes into further
detail re gamma issues:
http://www.cs.princeton.edu/courses/...s/smith95d.pdf
.. In this 1995 article, Alvy states:
"Nonlinearity should never be stored in an image. Or, if it is, then this
nonlinearity must be noted in the storage format in such a way that it is
known how to remove it to retrieve linear data."

This comment, as fundamental as it is to graphics algorithms, plus others
relating to the concept of working versus display space, came years before
Photoshop 5 commercially introduced the concept of working spaces, as part
of color management. Not bad for someone who "doesn't understand gamma".

As for Timo's lonely stance - he appears to be in good company now, having
been debunked together with Alvy Ray Smith and Dan Margulis, all in the
space of a few days. :-)
--
Mike Russell
www.curvemeister.com
www.geigy.2y.net

Mike Russell wrote:

Mike Engles wrote:
[re alvy gamma article]

Hello

Yes there does seem to some confusion about PC Gamma, but he [Alvy] is
absolutly clear about the need for linear processing. As for not
understanding Gamma encoding, that is not clear from the article. He
has
been around a long time, and does know a thing or two. If gamma
encoding
were that important he would have mentioned it. He is totally clear
about not applying any non linearity to a image, just to the display
device. I assume from this he means the same for storage, but I don't
know.

Suffice to say that he and his collaborator are MAJOR digital graphics
imaging authorities who on the face of it supports Timo Autiokari's
lonely stance. His last words in the gamma article are telling.

Mike Engles

Right on. Alvy has another article, written in 1995, that goes into further
detail re gamma issues:
http://www.cs.princeton.edu/courses/...s/smith95d.pdf
. In this 1995 article, Alvy states:
"Nonlinearity should never be stored in an image. Or, if it is, then this
nonlinearity must be noted in the storage format in such a way that it is
known how to remove it to retrieve linear data."

This comment, as fundamental as it is to graphics algorithms, plus others
relating to the concept of working versus display space, came years before
Photoshop 5 commercially introduced the concept of working spaces, as part
of color management. Not bad for someone who "doesn't understand gamma".

As for Timo's lonely stance - he appears to be in good company now, having
been debunked together with Alvy Ray Smith and Dan Margulis, all in the
space of a few days. :-)
--
Mike Russell
www.curvemeister.com
www.geigy.2y.net


Hello

This curiuosly was the article I was referring to.
I was not sure of the legality of quoting from it. Since you have I will
also.

These are the last words.

"Gamma can be confusing, as the above probably illustrates. Here are the
simple rules Altamira Composer uses and what I am advocating that
imaging applications do as a matter of course: Images are always assumed
to be linear. Gamma is applied only to the display of images and not to
the data of the images.The display is assumed to be nonlinear (because
it is). Applications separate computation from display cleanly, and
gamma correct for the local display only in the display process.

To get compatible results between imaging applications written under the
(I trust you believe sensible) “new” guidelines offered here and those
written the “old” way: Set the monitor gamma assumption in all the “old”
imaging applications to the same (greater than 1) value—presumably to
that matching one’s usual display monitor. Most applications provide a
way to do this. This transfers the nonlinearity correction in those apps
from the computation process to the display process, as it should be,
leaving linear data in the images themselves.
A desirable consequence of all this is that it would be very convenient
for imaging software if display devices provided gamma correction tables
settable by software. That way, each imaging app could work completely
in linear space,knowing that the display step would be correctly
compensated by the local monitor for its local nonlinearities.

Believe it or not, this was the way it was done
20 years ago, but the idea got lost along the way, leading to the mess
described in this memo. Unfortunately, it is probably too late to
change. The technique offered here is the best that can be done short of
changing all the hardware."

It seems that there was a differnt way and the only people who use it
now are the scientists.

I honestly do not know which is right and do not know enough to be able
to know, but feel in my bones that the old way was right.

Mike Engles

Mike Russell wrote:

Mike Engles wrote:
[re alvy gamma article]

Hello

Yes there does seem to some confusion about PC Gamma, but he [Alvy] is
absolutly clear about the need for linear processing. As for not
understanding Gamma encoding, that is not clear from the article. He
has
been around a long time, and does know a thing or two. If gamma
encoding
were that important he would have mentioned it. He is totally clear
about not applying any non linearity to a image, just to the display
device. I assume from this he means the same for storage, but I don't
know.

Suffice to say that he and his collaborator are MAJOR digital graphics
imaging authorities who on the face of it supports Timo Autiokari's
lonely stance. His last words in the gamma article are telling.

Mike Engles

Right on. Alvy has another article, written in 1995, that goes into further
detail re gamma issues:
http://www.cs.princeton.edu/courses/...s/smith95d.pdf
. In this 1995 article, Alvy states:
"Nonlinearity should never be stored in an image. Or, if it is, then this
nonlinearity must be noted in the storage format in such a way that it is
known how to remove it to retrieve linear data."

This comment, as fundamental as it is to graphics algorithms, plus others
relating to the concept of working versus display space, came years before
Photoshop 5 commercially introduced the concept of working spaces, as part
of color management. Not bad for someone who "doesn't understand gamma".

As for Timo's lonely stance - he appears to be in good company now, having
been debunked together with Alvy Ray Smith and Dan Margulis, all in the
space of a few days. :-)
--
Mike Russell
www.curvemeister.com
www.geigy.2y.net


Hello

This curiuosly was the article I was referring to.
I was not sure of the legality of quoting from it. Since you have I will
also.

These are the last words.

"Gamma can be confusing, as the above probably illustrates. Here are the
simple rules Altamira Composer uses and what I am advocating that
imaging applications do as a matter of course: Images are always assumed
to be linear. Gamma is applied only to the display of images and not to
the data of the images.The display is assumed to be nonlinear (because
it is). Applications separate computation from display cleanly, and
gamma correct for the local display only in the display process.

To get compatible results between imaging applications written under the
(I trust you believe sensible) “new” guidelines offered here and those
written the “old” way: Set the monitor gamma assumption in all the “old”
imaging applications to the same (greater than 1) value—presumably to
that matching one’s usual display monitor. Most applications provide a
way to do this. This transfers the nonlinearity correction in those apps
from the computation process to the display process, as it should be,
leaving linear data in the images themselves.
A desirable consequence of all this is that it would be very convenient
for imaging software if display devices provided gamma correction tables
settable by software. That way, each imaging app could work completely
in linear space,knowing that the display step would be correctly
compensated by the local monitor for its local nonlinearities.

Believe it or not, this was the way it was done
20 years ago, but the idea got lost along the way, leading to the mess
described in this memo. Unfortunately, it is probably too late to
change. The technique offered here is the best that can be done short of
changing all the hardware."

It seems that there was a differnt way and the only people who use it
now are the scientists.

I honestly do not know which is right and do not know enough to be able
to know, but feel in my bones that the old way was right.

Mike Engles

Mike Engles writes:

Actually, Alvy has a number of mistakes in that paper.
I'm still not sure if he understands gamma encoding...

Yes there does seem to some confusion about PC Gamma, but he is
absolutly clear about the need for linear processing. As for not
understanding Gamma encoding, that is not clear from the article.

Actually, he does mention that the RGB data will be stored and
transmitted in nonlinear form. The paper is about the debate over
whether the alpha data should also be nonlinearly encoded (for
uniformity), or not. He also mentions another great debate in computer
graphics: whether partially-transparent pixels should have their alpha
already multiplied into the RGB values, or whether alpha should be
independent.

He has
been around a long time, and does know a thing or two. If gamma encoding
were that important he would have mentioned it.

He does mention it applying to the RGB data.

Suffice to say that he and his collaborator are MAJOR digital graphics
imaging authorities who on the face of it supports Timo Autiokari's
lonely stance. His last words in the gamma article are telling.

To know whether he supported Timo, you'd have to ask him. He's talking
about using a linear representation in one very particular place, not
commenting on Timo's obsession with everything being linear everywhere.

Linear and nonlinear representations both have their place.

Dave

Mike Engles writes:

Actually, Alvy has a number of mistakes in that paper.
I'm still not sure if he understands gamma encoding...

Yes there does seem to some confusion about PC Gamma, but he is
absolutly clear about the need for linear processing. As for not
understanding Gamma encoding, that is not clear from the article.

Actually, he does mention that the RGB data will be stored and
transmitted in nonlinear form. The paper is about the debate over
whether the alpha data should also be nonlinearly encoded (for
uniformity), or not. He also mentions another great debate in computer
graphics: whether partially-transparent pixels should have their alpha
already multiplied into the RGB values, or whether alpha should be
independent.

He has
been around a long time, and does know a thing or two. If gamma encoding
were that important he would have mentioned it.

He does mention it applying to the RGB data.

Suffice to say that he and his collaborator are MAJOR digital graphics
imaging authorities who on the face of it supports Timo Autiokari's
lonely stance. His last words in the gamma article are telling.

To know whether he supported Timo, you'd have to ask him. He's talking
about using a linear representation in one very particular place, not
commenting on Timo's obsession with everything being linear everywhere.

Linear and nonlinear representations both have their place.

Dave

"Mike Russell" writes:

. In this 1995 article, Alvy states:
"Nonlinearity should never be stored in an image. Or, if it is, then this
nonlinearity must be noted in the storage format in such a way that it is
known how to remove it to retrieve linear data."

Right. All you need to satisfy the above is a way to decode the pixels
back to linear space. PNG has that. OpenEXR stores pixels in a version
of floating point - but the decoding method is specified. sRGB also
specifies how to convert between linear and encoded pixels. Looks like
this problem is mostly solved now.

Of course, you *can* leave data linear, but you need more bits for it.
The Pixar Image Computer, deveoped under Alvy at Pixar, used 12 bits per
colour component in memory, and in data files, while arithmetic was all
16/32 bit.

As for Timo's lonely stance - he appears to be in good company now, having
been debunked together with Alvy Ray Smith and Dan Margulis, all in the
space of a few days. :-)

Shall we then place George Preddy above all the others you mention? If
being debunked is a virtue...

Dave

Mike Engles writes:

Believe it or not, this was the way it was done
20 years ago, but the idea got lost along the way, leading to the mess
described in this memo. Unfortunately, it is probably too late to
change. The technique offered here is the best that can be done short of
changing all the hardware."

There's more to the history than that. Computer graphics started out
using 8-bit linear images, because it was simple and obvious.
Television started out using analog gamma-corrected voltages, because
there were a bunch of good reasons to put the gamma correction in the
camera instead of in the receiver. But along the way, computers started
generating television signals, and digitizing television, and television
itself became digital, and then photography came along and borrowed from
all of these.

It seems that there was a differnt way and the only people who use it
now are the scientists.

The vast majority of digital images in existence are probably 8-bit
"gamma corrected" data, because that's a particular sweet spot that
makes a good tradeoff between cost and results. But there are people
working with fixed-point linear data and floating-point linear data,
and people who store one way and process the other.

Dave

what's RGB?

Aerticeus

"digiboy" wrote in message
om...
the surprise to me about color management is thats its a suprise to
everyone else.

I've always thought that the task of converting different gamuts,
white points, phosphers etc too much for the average / typical user.

How do you color manage when you have perceptive colors like RGB,
color mixed output colors like CMYK and fixed-by-dye colors like
Pantones, all on the same page?

Can't be done! How do you manage out of gamut colors. Shrink the
gamut, and if the image moves to a device with a larger gamut, what
happens then?

Do you shrink a gamut by chromaticity ie shrink towards the white
point, or do you do it so the perceptual colors are the same?

Just my 2p worth. I have color management turned off

DB

On Wed, 01 Dec 2004 01:39:24 GMT, "Aerticeus"
wrote:

what's RGB?

Aerticeus

Red, Green, Blue?
Like what your monitor uses.

--
Bill Funk
Change "g" to "a"