Pages: 1 ... 19 20 [21] 22 23 24   Go Down

Author Topic: Color management myths and misinformation video  (Read 84514 times)

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #400 on: September 05, 2014, 04:08:17 pm »

While I appreciate that, my copy of W&S is an indication of aspiration rather than knowledge. I'm just a photographer (and hobbyist programmer)— definitely not a color scientist.

Then you're learning to swim at the deep end of the pool.

Jim

Steve Upton

  • Newbie
  • *
  • Offline Offline
  • Posts: 23
Re: Color management myths and misinformation video
« Reply #401 on: September 05, 2014, 04:25:48 pm »

In that case, can we agree that colorimetrically characterized virtual emissive displays -- like sRGB & Adobe RGB -- are decidedly on the "color" side of the wall, not the "device" side?

Not by my definition, no.

Specifically, "colorimetrically characterized virtual emissive displays" as you refer to them are not one or the other. They, like any other ICC profile, are both - and the means to convert between them.

Or perhaps I'm misunderstanding you and thinking you were referring to ICC profiles rather than the virtual devices. Then still no, by my reckoning. They're devices right? We send device values to them (for storage in a working space rather than display on a physical device) and we get device values from them (the working space).

Or am I totally missing something?

Steve
Logged

louoates

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 836
    • Lou Oates Photography
Re: Color management myths and misinformation video
« Reply #402 on: September 05, 2014, 04:31:57 pm »

This thread has totally flushed my non-nerd-like brain of all color space understanding. PLEASE, someone just look at my simple work flow chart and tell me how far right or wrong it is.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Color management myths and misinformation video
« Reply #403 on: September 05, 2014, 04:33:23 pm »

I'm with Steve on this one, I have no issue with theoretical devices being labelled devices (device values). Why add yet another label into the mix? We do need to be careful with such spaces like ProPhoto RGB when it defines colors we can't see but this has been an outlier and oddity from day one in this discussion. But then those have been issues we've been struggling with for awhile now, namely device values that don't represent something we can see.

Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Alan Goldhammer

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4344
    • A Goldhammer Photography
Re: Color management myths and misinformation video
« Reply #404 on: September 05, 2014, 04:34:00 pm »


But grand pianos is not actually a measure of volume.  ;D
The one in my living room certainly is!  Less room for furniture.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Color management myths and misinformation video
« Reply #405 on: September 05, 2014, 04:35:11 pm »

This thread has totally flushed my non-nerd-like brain of all color space understanding. PLEASE, someone just look at my simple work flow chart and tell me how far right or wrong it is.
I don't see anything wrong with it per se. It doesn't address a slew of questions we've been trying to nail down.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #406 on: September 05, 2014, 05:26:33 pm »


Also, I'm digging the geek level of this group. As a dog-eared Wyszecki & Stiles owner, I appreciate just how deep the rabbit hole can go.


Welcome, Steve. Here's the story of my first encounter with W&S. The time is February or March of 1989. I'd left Rolm and set up shop at the Almaden Research Center and was looking around for something to do. I messed around with HDTV and co-authored a report recommending that IBM stay out of that business. I worked with RAID architecture, and proposed some strategies for improving performance. Neither project excited me much. Then some people from Kodak started knocking on the door asking if we were interested in joining together to create standards for interchange file formats for color images. I found out about it by accident and invited myself to an early meeting. At that time, the only thing I knew about color was how to put together filter packs for making C-prints.

Three guys from Kodak showed up for a two-day meeting: a manager in a product division and one of his engineers, and someone from Research. The Research guy opened his briefcase, took out a copy of W&S, and plunked it on the conference table, where it sat throughout the meetings. He never opened it, but seemed comforted by its presence. At one on the breaks, I asked if I could look at it, and he said, "Sure." I was seriously impressed as to how much there was to this color stuff. Over the next six years, I did my best to master my little part of the color science world, and was relieved to find that I could make some contributions while understanding a fraction of what's in that book.

While looking for the Kodak researcher's name (Eric somebody), I found a little riff on what I thought was important in an interchange color space a few months into what turned out to be a task force with Kodak (by the way, the task force never went anywhere because the PhotoCD folks preempted the Kodak people we were working with).

Anyway, from the time capsule:

Quote
Desirable characteristics for Device-Independent Interchange Color Spaces

A device-independent color space should see colors the way that color-normal people do; colors that match for such people should map to similar positions in the color space, and colors that don’t appear to match should be farther apart. This implies the existence of exact transforms to and from internationally-recognized colorimetric representations, such as CIE 1931 XYZ.  Defining transforms between a color space and XYZ implicitly defines transforms to all other spaces having such transforms. A further implication is that a device-independent color space should allow representation of most, if not all, visible colors.

A device-independent color space should allow compact, accurate representation. In order to minimize storage and transmission costs and improve performance, colors should be represented in the minimum number of bits, given the desired accuracy. Inaccuracies will be introduced by quantizing, and may be aggravated by manipulations of quantized data.  In order to further provide a compact representation, any space should produce compact results when subjected to common image-compression techniques.  This criterion favors perceptually-uniform color spaces; nonuniform spaces will waste precision quantizing the parts of the space where colors are farther apart than they should be, and may not resolve perceptually-important differences in the portions of the color space where colors are closer together than a uniform representation would place them.

Most image compression algorithms are themselves monochromatic, even though they are used on color images.  JPEG, for example, performs compression of color images by compressing each color plane independently.  The lossy discrete cosine transform compression performed by the JPEG algorithm works by discarding information rendered invisible by its spatial frequency content.  Human luminance response extends to higher spatial frequency than chrominance response.  If an image contains high spatial frequency information, only the luminance component of that image must be stored and transmitted at high resolution; some chrominance information can be discarded with little or no visual effect.  Effective lossy image compression algorithms such as DCT can take advantage of the difference in visual spatial resolution for luminance and chrominance, but, since they themselves are monochromatic, they can only do so if the image color space separates the two components.  Thus, a color space used with lossy compression should have a luminance component.  

The existence of a separate luminance channel is necessary, but not sufficient.  There also should be little luminance information in the putative chrominance channels, where its presence will cause several problems.  If the threshold matrices for the chrominance channels are constructed with the knowledge that those channels are contaminated with luminance information, the compressed chrominance channels will contain more high-frequency information than would the compressed version of uncontaminated chrominance channels.  Hence, a compressed image with luminance-contaminated chrominance channels will require greater storage for the same quality than an uncontaminated image. If the threshold matrices for the chrominance channels are constructed assuming that the channels are uncontaminated, visible luminance information in these channels will be discarded during compression. Normal reconstruction algorithms will produce luminance errors in the reconstructed image because the missing luminance information in the chrominance components will affect the overall luminance of each reconstructed pixel.  Sophisticated reconstruction algorithms that ignore the luminance information in the chrominance channels and make the luminance of each pixel purely a function of the information in the luminance channel will correctly reconstruct the luminance information, but will be more computationally complex.  

A device-independent color space should minimize computations for translations between the interchange color space and the native spaces of common  devices.  It is unlikely that the interchange color space will be the native space of many devices.  Most devices will have to perform some conversion from their native spaces into the interchange space.  System cost will be minimized if these computations are easily implemented.

Note that I really missed the mark, because I defined the boundary conditions in a way that precluded what eventually turned out to be the most common solutions: various flavors of gamma-corrected RGB. The criteria are especially hard on RGB spaces with small gamuts, like sRGB.


Jim
« Last Edit: September 05, 2014, 05:50:36 pm by Jim Kasson »
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #407 on: September 05, 2014, 05:31:44 pm »


Specifically, "colorimetrically characterized virtual emissive displays" as you refer to them are not one or the other. They, like any other ICC profile, are both - and the means to convert between them.

Or perhaps I'm misunderstanding you and thinking you were referring to ICC profiles rather than the virtual devices. Then still no, by my reckoning. They're devices right? We send device values to them (for storage in a working space rather than display on a physical device) and we get device values from them (the working space).

Or am I totally missing something?

I think it must be some kind of communication problem, or else I'm about to learn something important. Would you call the triplets in an Adobe RGB file colors? I would.

Jim

Steve Upton

  • Newbie
  • *
  • Offline Offline
  • Posts: 23
Re: Color management myths and misinformation video
« Reply #408 on: September 05, 2014, 05:51:34 pm »

Good stuff in your history lesson. Great wording of some of the basic building blocks of the architecture - and what it should be like.

I think it must be some kind of communication problem, or else I'm about to learn something important. Would you call the triplets in an Adobe RGB file colors? I would.

Well, to try to stick to the Chinese wall idea of separation, no. The triplets are RGB values so they are device values. They don't become colors until sent to a device OR converted to color values using a profile.

They have the means to be color values by converting through the AdobeRGB profile but if the profile is not saved into the file and it's just another untagged RGB file then it's lost in device land until the appropriate profile is added to the mix.

Steve

PS - I don't want to give the impression that I'm so strict in my language that I don't sometimes say "hey, what's that color in sRGB? 127,23,145". But that still presupposes that I know the color space (sRGB, but it could be 'myDisplayRGB') and once I know the color space, AND have a profile, I can create actual color values for use elsewhere.

I think that's the beauty of a color managed workflow with embedded ICC profiles. As long as profiles are along for the ride, it doesn't matter too much what form the data is in, it can usually be converted to the next desired form.
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #409 on: September 05, 2014, 06:36:20 pm »

Good stuff in your history lesson. Great wording of some of the basic building blocks of the architecture - and what it should be like.

Well, to try to stick to the Chinese wall idea of separation, no. The triplets are RGB values so they are device values. They don't become colors until sent to a device OR converted to color values using a profile.

They have the means to be color values by converting through the AdobeRGB profile but if the profile is not saved into the file and it's just another untagged RGB file then it's lost in device land until the appropriate profile is added to the mix.


Steve, let me work through this and try to figure out when a triplet stops being a color. Andrew quoted you as saying; "Lab, Luv, XYZ, Yxy, etc are all color values."  So, if I'm editing in Lab, the stored representation of the image -- let's call it a file, even though it may not be stored on a disk -- has "colors" in it, right. Presumably, if I'm editing in 64-bit floating point linear XYZ, there are colors in the file, not device values.

So far, so good. Now, let's say I treat every triplet in the XYZ file as a column vector and multiply all of them by an arbitrary nonsingular 3x3 matrix. Are the triplets still colors? If you say no, what if the matrix is the one that gets from XYZ to the CIE 1931 RGB Color matching functions? They're the basis for XYZ, so they've got to be colors, right?

Let's say you say all of the above are colors. What if I apply an arbitrary monotonic nonlinearity to the three color planes of XYZ or a linear transformation of XYZ. If the nonlinearity is known, are the triplets in the file still colors? Does your answer change if the nonlinearity is a power function with a straight line near the origin? What if I scale the values into the range 0 to 2^16-1 and convert from floating point to 16-bit unsigned integers? You see where I'm going here.

Thanks,

Jim

Steve Upton

  • Newbie
  • *
  • Offline Offline
  • Posts: 23
Re: Color management myths and misinformation video
« Reply #410 on: September 05, 2014, 06:42:58 pm »

Steve, let me work through this and try to figure out when a triplet stops being a color.

I guess they are all colors, at least it seems that way to me. It's all about colorimetry right?

If you get to the point where you create a triplet that is intended to be treated as an RGB value and sent off to a display, then I'd say you're now in device space.

I think once you get to the point of doing the lower level calculations and transformations you're in a different reality than that for which I try to differentiate between the two types of information. The value of the differentiation breaks down until you emerge from the other side with either colorimetric data or device data....

Steve
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #411 on: September 05, 2014, 07:37:37 pm »

I guess they are all colors, at least it seems that way to me. It's all about colorimetry right?

I think so, and you'll notice that I got to the point where the image could have been in sRGB, right?

If you get to the point where you create a triplet that is intended to be treated as an RGB value and sent off to a display, then I'd say you're now in device space.

But what if it's just intended as an RGB editing space, maybe one that doesn't have, and can't ever have, a real-world device that works that way -- like PPRGB?

I'm really uncomfortable saying that if I'm editing in Lab, I'm editing colors, but if I'm editing in PPRGB (or aRGB, for that matter) I'm editing device values.


By the way, the interchange color space criteria above was incorporated into an incomplete book chapter on color reproduction in a never-published computer graphics book. I unearthed the chapter while looking for some information about my work with Kodak. Here's a link to an Acrobat document, FWIW. It assumes familiarity with high-school math, including elementary linear algebra. Steve, this isn't aimed at you, but might help anyone who wants a quick run through some basic color theory. Remember, it was written in the early 90s.

http://www.kasson.com/ll/ColorRepIntro.pdf

Jim

MarkM

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 428
    • Alaska Photographer Mark Meyer
Re: Color management myths and misinformation video
« Reply #412 on: September 05, 2014, 08:36:55 pm »

That's a good read Jim, it does a nice job using just enough math without being overwhelming.

If you ever revise or publish a version I can save you the trouble of looking up XXX Stiles: Walter Stanley Stiles. He almost always published under WS — I don't think many people even knew his first name. He died in 1985 and in one of the obituaries there is an account of a discussion between him and RWG Hunt (whose full name I actually don't know):

Hunt: "I think Dr Stiles should explain how he can study colours and dispense with sensations."
Stiles: "You put a man down behind a colorimeter, you guide his hand to three knobs and let him go ahead."
Hunt: "This tells you everything?"
Stiles: "Of course not. But you ask him to make certain settings based on the appearance of the colorimeter field. You draw your conclusions from the relations between the stimuli exposed in the fields, and the settings he makes. In expressing these relations it is not necessary to claim one is 'measuring a sensation' or in fact to 'regard a sensation' as having any particular meaning as scientific term. Of course, the word 'sensation' may be used colloquially to explain to the observer what you want him to do."

I think Dr. Stiles is wise to make this distinction and I think it is very close to the distinction I was attempting between color (the sensation) and stimulus the thing colorimetry quantifies.
 
I'm a little confused by the Chinese wall. The burnt toast metaphor, however, is a wonderful way to explain color management — thanks for that Steve.
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #413 on: September 05, 2014, 08:51:02 pm »

That's a good read Jim, it does a nice job using just enough math without being overwhelming.

If you ever revise or publish a version I can save you the trouble of looking up XXX Stiles: Walter Stanley Stiles. He almost always published under WS — I don't think many people even knew his first name. He died in 1985 and in one of the obituaries there is an account of a discussion between him and RWG Hunt (whose full name I actually don't know):

Hunt: "I think Dr Stiles should explain how he can study colours and dispense with sensations."
Stiles: "You put a man down behind a colorimeter, you guide his hand to three knobs and let him go ahead."
Hunt: "This tells you everything?"
Stiles: "Of course not. But you ask him to make certain settings based on the appearance of the colorimeter field. You draw your conclusions from the relations between the stimuli exposed in the fields, and the settings he makes. In expressing these relations it is not necessary to claim one is 'measuring a sensation' or in fact to 'regard a sensation' as having any particular meaning as scientific term. Of course, the word 'sensation' may be used colloquially to explain to the observer what you want him to do."

I think Dr. Stiles is wise to make this distinction and I think it is very close to the distinction I was attempting between color (the sensation) and stimulus the thing colorimetry quantifies.

Mark, thank you so much for that clip of the discussion with Hunt (my copies of both Hunt books are heavily tinted in fading highlighter). The key to the color matching experiment was that it didn't matter what the sensations associated with the two fields "felt" or "looked" like, only that they matched.

I am considering a revision to bring the thing forwards in time 20+ years, and I thank you for Stiles' given names. These days, MacAdam seems to get all the ellipsoid credit. Can you point me at something that sorts that out?

Thanks,

jim

MarkM

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 428
    • Alaska Photographer Mark Meyer
Re: Color management myths and misinformation video
« Reply #414 on: September 05, 2014, 09:03:58 pm »

I am considering a revision to bring the thing forwards in time 20+ years, and I thank you for Stiles' given names. These days, MacAdam seems to get all the ellipsoid credit. Can you point me at something that sorts that out?

There's actually a discussion in WS about this starting on page 665 in the 2nd edition.

Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Color management myths and misinformation video
« Reply #415 on: September 06, 2014, 01:48:06 pm »

There's actually a discussion in WS about this starting on page 665 in the 2nd edition.

Mark, thanks for the pointer. Here's how I rewrote the paragraph:

Quote
A problem with xy chromaticity space is that equal steps at various places on the diagram correspond to different perceptual changes: a large numerical change in the chromaticity of a green color may be barely noticeable, while a small change in that of a blue could dramatically change the perceived color.  In 1942, David MacAdam performed a study in which he measured the amount of change in color that produced a just-noticeable difference in a set of observers.  He presented his results in the form of a set of ellipsoids in XYZ.  Shortly afterward, Walter Stiles predicted the shape of a set of ellipsoids based on other testing. The two sets of ellipsoids are similar, but not identical. If Stiles’ ellipsoids are enlarged by a factor of ten and converted to xy chromaticities, they become ellipses.  Plotting the major and minor axes of these ellipses results in the following diagram:

The conception of the book wrt to my chapter is that it would be preceded by a chapter written by Bernice Rogowitz on human vision. The chapter I wrote assumes a lot of knowledge in that area. If I'm going to do anything with this material now, I'd have to write something along those lines myself. There should also be a follow-on chapter on spatial aspects of color perception.

Jim

Steve Upton

  • Newbie
  • *
  • Offline Offline
  • Posts: 23
Re: Color management myths and misinformation video
« Reply #416 on: September 08, 2014, 03:16:28 pm »

I think so, and you'll notice that I got to the point where the image could have been in sRGB, right?

yeah, I saw you getting there...

But what if it's just intended as an RGB editing space, maybe one that doesn't have, and can't ever have, a real-world device that works that way -- like PPRGB?

I'm really uncomfortable saying that if I'm editing in Lab, I'm editing colors, but if I'm editing in PPRGB (or aRGB, for that matter) I'm editing device values.

Why?

Also, again, my terminology is really intended for people at a much higher level (as in 30,000 foot view, higher) than someone like you who certainly understands the concepts and is involved in the sort of calculations usually left to CMMs & profiling software. So if you find it doesn't apply, I certainly don't take it personally.

Steve

Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Color management myths and misinformation video
« Reply #417 on: September 08, 2014, 05:09:01 pm »

Why?
I'm not sure why editing in Lab or ProPhoto RGB or Adobe RGB (1998) both don't share the same terminology (Device Values perhaps Color Values). But these are Steve's terms so if I'm understanding the distinction:

Color Value refer to human perception and specifically to colorimetry. Lab, Luv, XYZ, Yxy, etc are all color values.
Device Value* refer to the encoding of a pixel with a possible number based on that encoding but may not refer to human perception.

Is that about right Steve?
If those definitions are OK, when editing an image in Photoshop, in sRGB or Lab, one is certainly a Color Value and I suspect a Device Value and one is only a Device Value.

*SU:
Quote
device values are *not* color values and only become color if sent to a device or come from the device. They can be correlated with color values using an ICC profile or in a measurement file of some sort.
Are the Lab Color Values not Device Values by virtue of editing them using a display which of course isn't providing us Lab but RGB but none the less correlated with color values using an ICC profile?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Steve Upton

  • Newbie
  • *
  • Offline Offline
  • Posts: 23
Re: Color management myths and misinformation video
« Reply #418 on: September 08, 2014, 05:28:38 pm »

I'm not sure why editing in Lab or ProPhoto RGB or Adobe RGB (1998) both don't share the same terminology (Device Values perhaps Color Values). But these are Steve's terms so if I'm understanding the distinction:

Color Value refer to human perception and specifically to colorimetry. Lab, Luv, XYZ, Yxy, etc are all color values.
Device Value* refer to the encoding of a pixel with a possible number based on that encoding but may not refer to human perception.

Is that about right Steve?

Yep.

If those definitions are OK, when editing an image in Photoshop, in sRGB or Lab, one is certainly a Color Value and I suspect a Device Value and one is only a Device Value.

*SU:Are the Lab Color Values not Device Values by virtue of editing them using a display which of course isn't providing us Lab but RGB but none the less correlated with color values using an ICC profile?

I don't consider the editing a factor, only the type of data (like units of measurement).

Yes, the values of an sRGB file are traveling through Lab/XYZ in order to be displayed on your screen, but that doesn't mean they are color values. (any more than feet are metric simply because they can be converted to meters)...

The ability to convert from one to another is the beauty of color management. The state of the numbers in human space (colors) or device space (RGB, CMYK, etc) is separate.

Steve

Logged

joofa

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
Re: Color management myths and misinformation video
« Reply #419 on: September 08, 2014, 10:50:08 pm »

Now, let's say I treat every triplet in the XYZ file as a column vector and multiply all of them by an arbitrary nonsingular 3x3 matrix. Are the triplets still colors? If you say no, what if the matrix is the one that gets from XYZ to the CIE 1931 RGB Color matching functions? They're the basis for XYZ, so they've got to be colors, right?


That is true. There is no difference in 'structure' in XYZ and any other color 'space' derived from it by a 3x3 matrix. If XYZ has colors then an RGB derived from that XYZ by 3x3 matrix also has the colors, same colors. Many (early) people working with color did not realize that such RGB 'spaces' derived from XYZ actually coexist in the same space. They are not different spaces. They are what may be considered different coordinate systems within the same 3D space. 
Logged
Joofa
http://www.djjoofa.com
Download Photoshop and After Effects plugins
Pages: 1 ... 19 20 [21] 22 23 24   Go Up