<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
&gt; representation, so 16-bit won&#39;t help anyway ;)<br>
<br>
</div>HDMI-1.3 can use more than 8-bit per component as well as DisplayPort. For<br>
DVI you might be right.<br>
10+10+10+1 RGBA == 30-bit RGB packed into 32-bit pixel. The monitor must<br>
obviously support decoding that. These device support as well todays<br>
typical 8+8+8+8 RGBA in 32-bit per pixel. (I dont know exactly of the<br>
channel order.)<br></blockquote><div><br>Ok, i didn&#39;t know about that. <br></div><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
&gt; Could you publish the test, please?<br>
<br>
</div>Create a simple gradient from black to white, say 4000 pixel wide. The<br>
stepping is obvious on good calibrated display hardware.<br>
<div class="im"><br>
&gt; Maybe you mean &quot;stripes&quot; on gradients, don&#39;t you?<br>
<br>
</div>That is the easiest test case. So far I came not arround to watch much of<br>
imagery as I have only one rudimentary test application. Perhaps I can<br>
integrate that capability in Oyranos&#39; image_display example.<br>
<div class="im"><br>
&gt; If so, the problem is a bit worse, than just &quot;16-bit&quot; canvas. As it might<br>
&gt; not help. Most of the editors, afaik, uses &quot;dithering&quot; during conversion<br>
&gt; from 16-bit to 8-bit. They add a special noise to the image to hide this<br>
&gt; stripes (at least Photoshop does).<br>
<br>
</div>This conversion to 8-bit reduces of course the colour resolution. You are<br>
discussing a workaround not a solution to the initial request?<br></blockquote><div><br>No, i&#39;m discussing the roots of the problem. I&#39;m not sure Qt&#39;s QPainter supports painting more than 8-bit RGB.<br>The point is we have *non*-openGL canvas as well. And it does not support this. More important, if we don&#39;t pay attention to the dithering, we will face with problems when &quot;industry people&quot; working in 16-bit decide to convert their images to 8-bit (for e.g. publishing in the web or printing as a photo)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I wrote in the hope that supporting GL_RGB16/GL_UNSIGNED_SHORT would be a<br>
minor task given that Krita can already use the well supported industry<br>
standard OpenGL API.<br></blockquote><div><br>I think Lukas will be able to fix this in OpenGL-canvas =)<br></div></div><br clear="all"><br>-- <br>Dmitry Kazakov<br>