|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
I thought there might be list members here who would find this excerpt of a post from another list interesting... >>The numbers are the same in all RGB spaces: what colors the represent >varies. >>If the space is bigger, then the numbers represent larger increments, >for a >>smaller space, lesser increments.If you know where in the colorworld the >>three tent pegs of maximim R, G, and B were placed, you know the footprint >of >>the tent. Add the height of the ridge post (white point) and you've defined >a >>3d color space. If you know the definition of a second such space, you >can >>take the location of any object in one tent, and make it be in exactly >the >>same spot in the other tent. So even though the color spaces are of differnt >>sizes and shapes, you can convert from one to another. Different tents >just >>serve different uses. > > >Wow! I think I almost understand that! Oh good, I was afraid I might be leaving you out in the desert without a tent... >So, this raises a few more questions >(sorry!): > >So are these wider "increments" defined within the file by its >embedded profile? Or are they only relevant to the RGB values as >they're being edited in a given color space and *not* stored in the >file at all? Lets say the tent's triangular floor is latex. It has a grid of 256 units laid out on it each way. If you stake out a larger claim on the face of the RGB planet by placing your R, G, & B pegs further from the center, then you define a larger space, but in the process you stretch the units, so that the increments are larger, and coarser. The numbers at each of these intersections are still the same, but the color they represent is more saturated as you stretch the tent floor, and define a larger gamut. Take a breather now, because it gets complicated with the next step: color space conversions, or how to get all the furniture in your tent the same color when you move it to a different tent. If you forget to note the tent size (tag the RGB space to the file) when you write down the numbers that a given object is at (define a specific color in the look up table), then later, in a different tent, you will only know where on the grid the object was previously placed, not how far the floor had been stretched, so you can't accurately reproduce that color location, because the grid means different things as it is stretched or shrunk. 128,128,128 no longer means a given color, it depends on how much you have stretched the tent when you pegged it out. In perceptually uniform ideal spaces such as workingspaces this set of numbers will still mean a neutral gray, however, but not in a device profile, where more or less of each color or another may be required to balance a gray. So now the big question: If you stake the tent out very large, and stretch the grid, and set an object on the floor in a particular spot, so it is a nice rusty orange color, how will you get that object that same color in a different smaller space, where the tent pegs are much closer together, and the numbers mean different things? Well, that color location will now be closer to the walls of the tent, since its a smaller tent, and the numbers on the grid will be larger under it, since the floor is not as stretched, and if you know the RGB peg locations of both spaces then you can do the math to convert one RGB space number to the other. Of course you don't need to figure this conversion yourself, the math is done by the Color Management Module (CMM) and the related RGB values for this and all the other color locations can be figured through the Color Look-Up Tables (CLUTs) in the profiles for the spaces involved. But if you don't tag your image, then the software can't do its job and convert properly. It will ask you to tell it what space the file is in if the tag is missing, and if you know the answer (and its a stock space that is available to you in Photoshop) you can select it. Otherwise you are left with a lot of rather meaningless (or at least inexact) RGB numbers. > >2. If the increments represented by the individual RGB pixel values >of a file being edited in, say, "Wide Gamut RGB" are much wider than >those of, say, "sRGB," would this make Wide Gamut RGB more prone to >posterization? (Given that there are still only 256 values per >increment.) > Yes, it will, but whether a given space will actually posterize to a given output device is the practical queston. The answer is that "reasonable" spaces (Bruce RGB, AdobeRGB) are not prone to this unless abused, while extra wide ones (WideFormatRGB) may sometimes show banding in the results. >3. If the gamut of my color space is larger than my monitor's gamut, >how can my monitor accurately display that too-large gamut? The >monitor profile can't perform magic (I think!). So what's the point >of using a wide gamut if I can't see those wide RGB values? Likewise, >if the gamut of my file's embedded profile (assuming that's how it >works) is larger than my Epson printer's gamut, how can my Epson >accurately print that too-large gamut? (I'd guess that the profiles >simply map them as best they can to the device's more limited gamut?) > Monitor profiles are currently colorimetric, which means they show in gamut colors accurately, andw hen they reach a point where they can't show them accurately (out of gamut colors), these colors are shown as if they were at the gamut limit; making for flat areas in brilliant colors. It would be nice to have an option of perceptual intent for monitors, so when we are in a large space, we could take a look at the whole image, with distinctions visible between out of gamut colors (no flat areas in the bright colors) but all the colors would be a bit off, bacuase the space would have been squeezed to fit. I'm not suggesting this as the default, but as a button you could push once in a while... C. David Tobie Design Cooperative CDTobie@designcoop.com - Turn off HTML mail features. Keep quoted material short. Use accurate subject lines. http://www.leben.com/lists for list instructions.
[Photo] [Yosemite News] [Yosemite Photos] [Scanner] [Gimp] [Gimp] Users