[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: 30-bit displaying with Krita?
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2009-12-24 13:01:37
Message-ID: ae32c1ef0912240501y27d80834j428409d1f3d31ea5 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> > representation, so 16-bit won't help anyway ;)
>
> HDMI-1.3 can use more than 8-bit per component as well as DisplayPort. For
> DVI you might be right.
> 10+10+10+1 RGBA == 30-bit RGB packed into 32-bit pixel. The monitor must
> obviously support decoding that. These device support as well todays
> typical 8+8+8+8 RGBA in 32-bit per pixel. (I dont know exactly of the
> channel order.)
>
Ok, i didn't know about that.
> > Could you publish the test, please?
>
> Create a simple gradient from black to white, say 4000 pixel wide. The
> stepping is obvious on good calibrated display hardware.
>
> > Maybe you mean "stripes" on gradients, don't you?
>
> That is the easiest test case. So far I came not arround to watch much of
> imagery as I have only one rudimentary test application. Perhaps I can
> integrate that capability in Oyranos' image_display example.
>
> > If so, the problem is a bit worse, than just "16-bit" canvas. As it might
> > not help. Most of the editors, afaik, uses "dithering" during conversion
> > from 16-bit to 8-bit. They add a special noise to the image to hide this
> > stripes (at least Photoshop does).
>
> This conversion to 8-bit reduces of course the colour resolution. You are
> discussing a workaround not a solution to the initial request?
>
No, i'm discussing the roots of the problem. I'm not sure Qt's QPainter
supports painting more than 8-bit RGB.
The point is we have *non*-openGL canvas as well. And it does not support
this. More important, if we don't pay attention to the dithering, we will
face with problems when "industry people" working in 16-bit decide to
convert their images to 8-bit (for e.g. publishing in the web or printing as
a photo)
I wrote in the hope that supporting GL_RGB16/GL_UNSIGNED_SHORT would be a
> minor task given that Krita can already use the well supported industry
> standard OpenGL API.
>
I think Lukas will be able to fix this in OpenGL-canvas =)
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<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"> > representation, so 16-bit won'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'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"> > 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>
> Maybe you mean "stripes" on gradients, don'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' image_display example.<br>
<div class="im"><br>
> If so, the problem is a bit worse, than just "16-bit" canvas. As it \
might<br> > not help. Most of the editors, afaik, uses "dithering" \
during conversion<br> > from 16-bit to 8-bit. They add a special noise to the \
image to hide this<br> > 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'm discussing the roots of the problem. \
I'm not sure Qt'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't pay attention to the dithering, we will face with problems \
when "industry people" 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>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic