<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/2.0.12-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>Jeffrey Friedl's Blog</title>
	<link>http://regex.info/blog</link>
	<description>Not a photo blog, but sometimes I play one on TV</description>
	<pubDate>Wed, 20 Aug 2008 02:17:09 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.12-alpha</generator>
	<language>en</language>
			<item>
		<title>Digital-Image Color Spaces, Page 6: Design Tradeoffs</title>
		<link>http://regex.info/blog/photo-tech/color-spaces-page6/</link>
		<comments>http://regex.info/blog/photo-tech/color-spaces-page6/#comments</comments>
		<pubDate>Tue, 03 Oct 2006 08:45:30 +0000</pubDate>
		<dc:creator>Jeffrey Friedl</dc:creator>
		
		<category>General</category>

		<guid isPermaLink="false">http://regex.info/blog/photo-tech/color-spaces-page6/</guid>
		<description><![CDATA[

 

Article:
Table of Contents &#160; &#160; &#160; Page:
1 &#183;
2 &#183;
3 &#183;
4 &#183;
5 &#183;
6 &#183;
7
&#160;&#160;&#160;&#160;&#160;&#160;This is the sixth page of a seven-page article


<br style='display:block;margin:5px'/>So, what factors make a color space good? Many of the issues can be
summarized with two statements, both of which describe a good color space:
&#8220;bigger is better&#8221; and &#8220;smaller is
better.&#8221; The mutually-exclusive nature of these goals indicates
the contentious tradeoffs that must be made during color-space design.



<br style='display:block;margin:5px'/>Illustrative Example: Length


<br style='display:block;margin:5px'/>Just to give a feel for the issues and tradeoffs facing color-space
designers, let's take a simplistic look at how we might encode something
far simpler than color: length.

<br style='display:block;margin:5px'/>

(To be [...]]]></description>
			<content:encoded><![CDATA[

<style type='text/css'>
a.btn    { background-color: #555; border: solid 1px #888; padding: 2px 5px }
span.now { background-color: #533; border: solid 1px #888; padding: 2px 5px; font-weight: bold }
</style>
<div style='display: block; background-color: #444; padding: 7px; border: solid 2px gray'>
<b>Article:</b>
<a class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page0/'>Table of Contents</a> &nbsp; &nbsp; &nbsp; <b>Page:</b>
<a title='Introduction' class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page1/'>1</a> &middot;
<a title='Test Images' class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page2/'>2</a> &middot;
<a title='Color Mis-Management' class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page3/'>3</a> &middot;
<a title='Color Management' class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page4/'>4</a> &middot;
<a title='Chromaticity Diagrams' class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page5/'>5</a> &middot;
<span class='now'>6</span> &middot;
<a title='Conclusions and Links' class='btn' href='http://regex.info/blog/photo-tech/color-spaces-page7/'>7</a>
<small>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This is the sixth page of a seven-page article</small>
</div>

<p>So, what factors make a color space good? Many of the issues can be
summarized with two statements, both of which describe a good color space:
&#8220;<b>bigger is better</b>&#8221; and &#8220;<b>smaller is
better.</b>&#8221; The mutually-exclusive nature of these goals indicates
the contentious tradeoffs that must be made during color-space design.

</p>

<p><b>Illustrative Example: <i>Length</i></b></p>


<p>Just to give a feel for the issues and tradeoffs facing color-space
designers, let's take a simplistic look at how we might encode something
far simpler than color: <b>length</b>.

</p><p>

(To be clear, this example has nothing to do with photography &mdash; it's
just an example to illustrate the nature of digital &#8220;space
encoding&#8221; tradeoffs. Being familiar with these issues helps you to
understand discussions of the relative merits of color spaces).

</p>

<p><b><a name='Unlimited'>Perfection is Possible, For a Price</a></b></p>
<p>

First, it seems prudent to note that if we had unlimited space to encode
our length, we would not have to make any tradeoffs. With unlimited space,
we could pick any unit (say, millimeters) and know that we could exactly,
unambiguously, perfectly encode any length we wished, from the <a
href='http://en.wikipedia.org/wiki/Planck_length' class='quiet'>Planck
length</a> (<tt
style='font-size:85%'>0.000000000000000000000000000000001616241</tt>) to
the guesstimated size of the visible universe down to more significant
digits than can ever be known (<tt
style='font-size:85%'>137198261174792827472661283376.9087225566893726264897726289572</tt>).

</p><p>

Modern digital images can have tens of millions of pixels, so it can be
unwieldy to let the encoding space requirements expand without bound.
People like fitting a lot of pictures on their memory cards and hard disks.
Finding a way to encode as much information as possible in the minimum
space brings us face to face with the need for tradeoffs.

</p>
<p><b><a name='Trivial'>Trivial Attempts to Encode Length: Width vs. Precision</a></b></p>
<p>

Back to our length example, let's say that file-size concerns dictated that
we use only three digits to encode the length, which means raw numbers from
0 to 999 for each length we wish to encode. It's up to us now to design a
&#8220;length space&#8221; as best we can within that limitation.

</p><p>

If we select the millimeter as our unit, we could encode lengths up to 999
mm (just over a yard) with fairly fine granularity (our 1 mm units). This
might be fine for encoding the lengths of some things (say, shoes and car
tires), but remains woefully lacking for most things (widths of hairs and
the heights of mountains).

</p><p>

If we choose a larger unit to apply to the raw numbers, such as a foot,
then we can encode lengths up to about a third of a kilometer &mdash; a
much <b>larger gamut</b>, so to speak. The tradeoff is that the level of
<b>precision</b>, or granularity &mdash; how fine a point along the full
encodable range that can be defined &mdash; has become more rough (in
encoding-space lingo, the &#8220;quantization errors&#8221; are larger). We can now
measure building heights fairly reasonably (to within a foot), but people
heights become iffy because everyone's height gets rounded off to the
nearest foot. In this case, the loss of precision has totally eliminated
encoding the size of marshmallows.

</p><p>

Regardless of the unit we pick, when we use a strictly linear approach as
we have above, we run into the same tradeoff: gamut size vs. precision.

</p>

<p><b><a name='Shift'>Shifting the Range</a></b></p>

<p>

One idea is to shift the starting point so that the gamut lies over the
area we might be interested in. Consider this:

</p>

<div style='margin: 30px'><center><big><i>length in millimeters</i> &nbsp;&nbsp;<b>=</b>&nbsp;&nbsp; 457 + <i>value</i> &times; 2</big></center></div>

<p>This allows our values from 0 through 999 to encode lengths from 457mm
through 2,455mm (18 inches through 8 feet) to a granularity of 2 mm, which
would be a useful length gamut for encoding the height of people. I'm not
sure it would be much use for anything else, but it illustrates the
point.</p>

<p><b>(Having shown an equation, I should remind you that this is all just
an example to illustrate tradeoffs with encodings &mdash; I'm making this
up as I go along, so there's no need to memorize or even pay any real
attention to these equations!)</b></p>

<p><b><a name='NonLinear'>Going Non-Linear</a></b></p>
<p>

One technique to achieve better encoding performance is to bring an
understanding of human perception into the equation. When considering the
heights of people, an inch or two either way can be a big deal, but the
same difference is generally much less relevant when considering the
distance between cities. So, one technique is to use a non-linear encoding
such that the precision increases as the length gets shorter. Put another
way, the difference between adjoining encodable lengths is smaller when the
length is smaller, and larger when the length is larger. This fits to the
way people generally think.

</p><p>

For
example, using this equation (which I just made up off the top of my head) in our encoding:

</p>


<table border='0' align='center' style='margin:30px auto'>
<tr>
  <td valign='bottom'><big><i>length in millimeters</i> &nbsp;&nbsp;<b>=</b>&nbsp;&nbsp;</big> <span style='font-size:280%'><i>e</i></span></td>
  <td valign='bottom'><center><small><u>&nbsp;&nbsp;&nbsp;37&nbsp;&nbsp;&nbsp;</u><br/><i>value</i><br/>&nbsp;<br/>&nbsp;</small></center></td>
  <td valign='bottom'><span style='font-size: 180%'>- 1</span>
</tr>
</table>


<p>

with <i>values</i> from 0 through 999 allows us to represent lengths from
between 0.027 millimeters through more than half a million kilometers.
That's from about 1/<sub>1,000<sup>th</sup></sub> of an inch (thinner than
the width of an average human hair) to a distance beyond the moon. That's a
<b>wide</b> length gamut.

</p><p>

Yet, despite the convenient width, it still allows the lengths of many
things to be encoded with &#8220;reasonable&#8221; precision &mdash; to
within a percent or so of their actual length. For example, it can encode
the length and width of a pencil to within 0.3%, the length of my foot to
within 1.2%, the length of a soccer field to within 0.6%, the height of Mt.
Everest to within 0.4%, the diameters of the earth to within 0.1% and of
the moon to within 0.3%, and the distance to the moon to within 0.2%.

</p><p>

That's not too bad, and if someone like me can come up with that off the
top of my head, someone with real mathematical skill might be able to make
one that's even better.

</p>

<p><b><a name='Shift'>Back to Color Spaces</a></b></p>

<p>

There are a lot of things about color that can be used to one's advantage
when designing a color space:</p>

<ul>

<li><p>A lot of colors look the same. Whole ranges of wavelengths look more
or less exactly the same to most people, so those regions of color need not
be encoded with much precision. An encoding space is better if it can use
the available precision where it counts the most.</p></li>

<li><p>The same can be said of the range of colors covered. This is one
reason that the monochromatic colors are <a
href='http://regex.info/blog/photo-tech/color-spaces-page5/#Monochromatic'>not
generally included</a> in RGB color spaces: exceedingly similar colors can
be included in their place without having to extend the gamut all the way
to the edge. Most people just can't tell the difference, so the smaller
gamut is used to provide more precision across the encoded space.</p></li>

<li><p>As mentioned on the <a
href='http://regex.info/blog/photo-tech/color-spaces-page5/'>previous
page</a>, the eye's perception of brightness is not linear with the
intensity of light. Thus, it's a more efficient use of the available
precision if the brightness component of the color can be encoded in
proportion to how the eye perceives brightness. This is usually done with a
<a href='http://en.wikipedia.org/wiki/Gamma_correction'>gamma</a>.
</p></li>
</ul>

<p>In the end, the width vs. precision tradeoff is always there. If a color
space is designed for a specific purpose, at least it can use features of
the intended use to squeeze out extra efficiency (sRGB bothered to encode
only the colors that circa-1996 common monitors could display, for
example). A general-purpose color spaces are a more difficult subject;
hopefully, this page has provided some insight into some of the issues.</p>

<p><b>Continued on the Next Page</b></p>
<p>
This article continues on <a href='http://regex.info/blog/photo-tech/color-spaces-page7/'>Page 7: Recommendations and Links</a>.
</p>









]]></content:encoded>
			<wfw:commentRss>http://regex.info/blog/photo-tech/color-spaces-page6/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
