<html style="direction: ltr;">
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
text="#000000">
Thanks for clarifying.<br>
We always have to answer claims such as: "...but Arc* does like
this...".<br>
<br>
We noticed the problem when compositing Landsat tiles in an area
with very uniform landscape. The slight shift in RGB values with
the default level=32 led to many adjacent pixels getting the same
color value, and the result looked very "blocky".<br>
<br>
<div class="moz-cite-prefix">On 30-Jan-15 2:33 PM, Glynn Clements
wrote:<br>
</div>
<blockquote
cite="mid:21707.31280.69887.439120@cerise.gclements.plus.com"
type="cite">
<pre wrap="">
Markus Metz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Jan 28, 2015 at 10:34 PM, Micha Silver <a class="moz-txt-link-rfc2396E" href="mailto:micha@arava.co.il"><micha@arava.co.il></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">When I use r.composite to create, i.e., a false_color composite from three
Landsat bands, the RGB values in the composite are slightly different than
the values in the original bands. Why is that?
</pre>
</blockquote>
<pre wrap="">
Because the number of levels to be used for each component is by
default 32, not 256 [0].
</pre>
</blockquote>
<pre wrap="">
You can use levels=256 if you want 256 levels. But the resulting map
will have a very large colour table (65536 rules), which will
negatively affect the performance of anything which reads the colour
table. Which is why the default is 32 levels rather than 256.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Moshav Idan
D.N. Arava, 86840
cell: 0523-665918
<a class="moz-txt-link-freetext" href="http://www.surfaces.co.il">http://www.surfaces.co.il</a></pre>
</body>
</html>