[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Beginner's ColorSync Questions, more tenting...



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

Powered by Linux