[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request: Implement color correction (per output)
From: Thomas_Lübking <thomas.luebking () web ! de>
Date: 2012-08-27 16:04:15
Message-ID: 20120827160415.12215.30901 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Aug. 25, 2012, 2:58 p.m., Fredrik Höglund wrote:
> > kwin/libkwineffects/kwinglcolorcorrection.cpp, line 672
> > <http://git.reviewboard.kde.org/r/106141/diff/1/?file=80372#file80372line672>
> >
> > I'm pretty sure you want GL_CLAMP_TO_EDGE here.
>
> Casian Andrei wrote:
> Thanks, who knows how much time would have taken me to figure this out. \
> (I took the code from CompICC without looking on the documentation, \
> thinking it's correct for this case).
FYI: it's a SUCH popular mistake that the nvidia driver until now \
(conditionally) took GL_CLAMP as GL_CLAMP_TO_EDGE Since the 300 drivers \
there's a GUI option for this (defaults to "on" ie. you suddenly got \
clamping errors (black lines) all over the place ;-)
> On Aug. 25, 2012, 2:58 p.m., Fredrik Höglund wrote:
> > kwin/libkwineffects/kwinglutils.cpp, line 322
> > <http://git.reviewboard.kde.org/r/106141/diff/1/?file=80375#file80375line322>
> >
> > You can't do this unconditionally. KWin has shaders that operate on \
> > pixels that have already been color corrected.
>
> Casian Andrei wrote:
> This is a tricky issue.
>
> I guess the applications should use the X Color Management stuff to \
> specify which regions are color corrected and if there are some that \
> don't need any correction. If they do that, Kolor Server will see it and \
> update the regions that will end up in KWin. So for areas not to be \
> corrected by KWin, a dummy lookup table will be used for correction, sRGB \
> -> sRGB (basically does nothing).
> If the applications don't use the X Color Management and color correction \
> is enabled in KWin too, then I think it sucks.
> Perhaps my mentor could give details :/
I don't think this is what Fredrik meant - some shaders will operate on a \
previously buffered (and color corrected) output. If you inject color \
correction here as well, you'll "correct" twice.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106141/#review17979
-----------------------------------------------------------
On Aug. 23, 2012, 2:56 p.m., Casian Andrei wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106141/
> -----------------------------------------------------------
>
> (Updated Aug. 23, 2012, 2:56 p.m.)
>
>
> Review request for kwin, Thomas Lübking and Martin Gräßlin.
>
>
> Description
> -------
>
> These are the results of my GSoC project, for KWin.
>
> This color correction needs KolorManager installed, 'kded' branch. That \
> one needs Oyranos. git://anongit.kde.org/kolor-manager.git \
> http://www.oyranos.org/downloads If it's not installed, the \
> ColorCorrection class should fail without causing any issues to the user \
> (that's if it's enabled from the KCM). Probably a notification could be \
> appropriate in that case? "Failed to initialize CC because cannot contact \
> Kolor-Server KDED..." something like that?
> Change summary:
> --
> Add an option to kcmcompositing in the 'Advanced' tab, to enable or \
> disable color correction. It is specified that it's experimental and it \
> needs Kolor Manager. This implies some small changes to options.h and \
> cpp.
> In composite.cpp, the ColorCorrection class instance is initialized or \
> cleaned up (it's like being owned by the compositor). In workspace, \
> there's a signal connected to reset compositing if the color correction \
> setting is changed.
> Scene::finalPaintWindow code is moved into SceneOpenGL::performPaint.
> SceneOpenGL has the declarations of some methods changed to include the \
> screen number - those could be changed to pass around PaintData's \
> probably. SceneOpenGL's newly implemented finalDrawWindow splits the \
> rendering if color correction is enabled and there are multiple screens. \
> Before painting for a particular screen, ColorCorrection::setupForOutput \
> should be called.
> There was a problem with the blending function causing artifacts with \
> color correction enabled so it is set up to src_alpha, one_minus_src \
> alpha in that case.
> Now, inside KWinEffects:
> --
> A screen property is added for WindowPaintData.
> In kwinglutils, The fragment shaders are intercepted before being \
> compiled and they get a couple of lines of code inserted in order to do \
> the color stuff. This happens only when color correction is enabled, of \
> course.
> And there is the big ColorCorrection class. The public and private stuff \
> are well separated. More additions to the public stuff shouldn't be \
> necessary in the future as far as I see it. Everything is there I think. \
> The region stuff is not used at the moment, and the 2 reset methods \
> aren't used either (for now).
> The private stuff consists of the private data and the D-Bus interface. \
> Regarding D-Bus, everything is async (I think).
> The implementation basically manages a set of color lookup tables for \
> different outputs and for different window regions. These are taken via \
> D-Bus. Each lookup table has around 700 KB. I hope I am not wrong in \
> assuming it's not that big of an issue time-wise, since they are \
> transferred only once or twice for an entire session. I hope D-Bus \
> doesn't do any time consuming business to transfer those QVector's.
> There is an issue with OpenGL ES, apparently it doesn't support 3D \
> textures (probably it needs an extension or something). Until we envision \
> a clear solution, I have disabled the color correction for OpenGL ES.
> In case of problems, it should not affect the rest of KWin in any way.
>
> Next priorities:
> --
> Implement per-window-region stuff. It should be a matter of extending \
> KolorServer's capabilities and doing some small modifications in \
> SceneOpenGL::Window. The ColorCorrection class from KWinEffects has \
> everything prepared.
> Fix issues with transparency / some weird colors.
>
> --
> There's another thing... I don't know when I'm supposed to be able to do \
> improvements and modifications, since the GSoC project ended. Probably if \
> I keep the new modifications well separated, there should be no issues.
>
> Diffs
> -----
>
> kwin/composite.cpp c65716b
> kwin/kcmkwin/kwincompositing/main.cpp 7a89db4
> kwin/kcmkwin/kwincompositing/main.ui cff0f63
> kwin/libkwineffects/CMakeLists.txt 14a2747
> kwin/libkwineffects/kwineffects.h 2c2f7bf
> kwin/libkwineffects/kwineffects.cpp bae85e7
> kwin/libkwineffects/kwinglcolorcorrection.h PRE-CREATION
> kwin/libkwineffects/kwinglcolorcorrection.cpp PRE-CREATION
> kwin/libkwineffects/kwinglcolorcorrection_p.h PRE-CREATION
> kwin/libkwineffects/kwinglutils.h 7a7c3c9
> kwin/libkwineffects/kwinglutils.cpp 016d31e
> kwin/options.h 9e4fcc6
> kwin/options.cpp 72f168d
> kwin/scene.h 3891198
> kwin/scene.cpp 5782510
> kwin/scene_opengl.h de33ce4
> kwin/scene_opengl.cpp cbcc0ca
> kwin/workspace.cpp cf3f308
>
> Diff: http://git.reviewboard.kde.org/r/106141/diff/
>
>
> Testing
> -------
>
> Restarted KDED making sure Kolor-Manager is installed properly - this \
> should make the KDED module available.
> Restarted KWin, enabled color correction in KCM compositing, advanced \
> tab.
> Played a bit with commands like:
> oyranos-monitor -d 0 XYZ.icc
> oyranos-monitor -d 1 Lab.icc
> Those set up particular profiles for the monitors. However, it seems \
> there is a problem with reverting to the normal ones. The code regarding \
> that is taken directly from CompICC, so I don't know whether it's a bug \
> or a feature. Anyway, it's from Kolor-Server.
> Apparently, everything works as planned. But I cannot distinguish visible \
> differences for the profiles used for the different monitors by default.
> There is an issue with the transparent areas - they are darkened somehow. \
> This should be easy to fix, I have left the issue around because I hadn't \
> time to finish before the GSoC deadline and it makes it possible to \
> quickly find out whether color correction is enabled or not :). Perhaps, \
> it's because of the blending function and not because of the correction. \
> Also, there's something wrong with the highlights in gitk, I don't know \
> exactly what. So, small issues are present.
>
> Screenshots
> -----------
>
> Output 0 Lab.icc Output 1 XYZ.icc
> http://git.reviewboard.kde.org/r/106141/s/695/
>
>
> Thanks,
>
> Casian Andrei
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px \
#c9c399 solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/106141/">http://git.reviewboard.kde.org/r/106141/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <p style="margin-top: 0;">On August 25th, 2012, 2:58 \
p.m., <b>Fredrik Höglund</b> wrote:</p> <blockquote style="margin-left: \
1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid \
#C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid \
#C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="http://git.reviewboard.kde.org/r/106141/diff/1/?file=80372#file80372line672" \
style="color: black; font-weight: bold; text-decoration: \
underline;">kwin/libkwineffects/kwinglcolorcorrection.cpp</a> <span \
style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: \
center;"> <tr>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: \
0; "></pre></td> <td colspan="2"><pre style="font-size: 8pt; line-height: \
140%; margin: 0; ">void ColorCorrectionPrivate::setupCCTexture(GLuint \
texture, const Clut& clut)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th> <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; \
"></pre></td> <th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; \
border-right: 1px solid #C0C0C0;" align="right"><font \
size="2">672</font></th> <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "> <span \
class="n">glTexParameteri</span><span class="p">(</span><span \
class="n">GL_TEXTURE_3D</span><span class="p">,</span> <span \
class="n">GL_TEXTURE_WRAP_S</span><span class="p">,</span> <span \
class="n">GL_CLAMP</span><span class="p">);</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">I'm pretty sure you want GL_CLAMP_TO_EDGE here.</pre> \
</blockquote>
<p>On August 27th, 2012, 2:56 p.m., <b>Casian Andrei</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Thanks, who knows how much time would have taken me to figure \
this out. (I took the code from CompICC without looking on the \
documentation, thinking it's correct for this case).</pre> \
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">FYI: it's a SUCH popular mistake that the nvidia driver \
until now (conditionally) took GL_CLAMP as GL_CLAMP_TO_EDGE Since the 300 \
drivers there's a GUI option for this (defaults to "on" ie. \
you suddenly got clamping errors (black lines) all over the place ;-) \
</pre> <br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <p style="margin-top: 0;">On August 25th, 2012, 2:58 \
p.m., <b>Fredrik Höglund</b> wrote:</p> <blockquote style="margin-left: \
1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid \
#C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid \
#C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="http://git.reviewboard.kde.org/r/106141/diff/1/?file=80375#file80375line322" \
style="color: black; font-weight: bold; text-decoration: \
underline;">kwin/libkwineffects/kwinglutils.cpp</a> <span \
style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: \
center;"> <tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: \
0; ">bool GLShader::loadFromFiles(const QString &vertexFile, const \
QString &fragmentFile)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2">321</font></th> <td bgcolor="#fdfebc" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> \
<span class="k">const</span> <span class="kt">char</span><span \
class="o">*</span> <span class="n">src</span> <span class="o">=</span> \
<span class="n">ba</span><span class="p">.</span><span \
class="n">constData</span><span class="p">();</span></pre></td> <th \
bgcolor="#e9eaa8" style="border-left: 1px solid #C0C0C0; border-right: 1px \
solid #C0C0C0;" align="right"><font size="2">320</font></th> <td \
bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: \
140%; margin: 0; "> <span class="c1">// Inject color correction code for \
fragment shaders, if possible</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">You can't do this unconditionally. KWin has shaders that \
operate on pixels that have already been color corrected.</pre> \
</blockquote>
<p>On August 27th, 2012, 2:56 p.m., <b>Casian Andrei</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">This is a tricky issue.
I guess the applications should use the X Color Management stuff to specify \
which regions are color corrected and if there are some that don't need \
any correction. If they do that, Kolor Server will see it and update the \
regions that will end up in KWin. So for areas not to be corrected by KWin, \
a dummy lookup table will be used for correction, sRGB -> sRGB \
(basically does nothing).
If the applications don't use the X Color Management and color \
correction is enabled in KWin too, then I think it sucks.
Perhaps my mentor could give details :/</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">I don't think this is what Fredrik meant - some shaders \
will operate on a previously buffered (and color corrected) output. If you \
inject color correction here as well, you'll "correct" \
twice.</pre> <br />
<p>- Thomas</p>
<br />
<p>On August 23rd, 2012, 2:56 p.m., Casian Andrei wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px \
black solid;"> <tr>
<td>
<div>Review request for kwin, Thomas Lübking and Martin Gräßlin.</div>
<div>By Casian Andrei.</div>
<p style="color: grey;"><i>Updated Aug. 23, 2012, 2:56 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description \
</h1> <table width="100%" bgcolor="#ffffff" cellspacing="0" \
cellpadding="10" style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">These are the results of my GSoC project, for KWin.
This color correction needs KolorManager installed, 'kded' branch. \
That one needs Oyranos. git://anongit.kde.org/kolor-manager.git \
http://www.oyranos.org/downloads If it's not installed, the \
ColorCorrection class should fail without causing any issues to the user \
(that's if it's enabled from the KCM). Probably a notification \
could be appropriate in that case? "Failed to initialize CC because \
cannot contact Kolor-Server KDED..." something like that?
Change summary:
--
Add an option to kcmcompositing in the 'Advanced' tab, to enable or \
disable color correction. It is specified that it's experimental and it \
needs Kolor Manager. This implies some small changes to options.h and cpp.
In composite.cpp, the ColorCorrection class instance is initialized or \
cleaned up (it's like being owned by the compositor). In workspace, \
there's a signal connected to reset compositing if the color correction \
setting is changed.
Scene::finalPaintWindow code is moved into SceneOpenGL::performPaint.
SceneOpenGL has the declarations of some methods changed to include the \
screen number - those could be changed to pass around PaintData's \
probably. SceneOpenGL's newly implemented finalDrawWindow splits the \
rendering if color correction is enabled and there are multiple screens. \
Before painting for a particular screen, ColorCorrection::setupForOutput \
should be called.
There was a problem with the blending function causing artifacts with color \
correction enabled so it is set up to src_alpha, one_minus_src alpha in \
that case.
Now, inside KWinEffects:
--
A screen property is added for WindowPaintData.
In kwinglutils, The fragment shaders are intercepted before being compiled \
and they get a couple of lines of code inserted in order to do the color \
stuff. This happens only when color correction is enabled, of course.
And there is the big ColorCorrection class. The public and private stuff \
are well separated. More additions to the public stuff shouldn't be \
necessary in the future as far as I see it. Everything is there I think. \
The region stuff is not used at the moment, and the 2 reset methods \
aren't used either (for now).
The private stuff consists of the private data and the D-Bus interface. \
Regarding D-Bus, everything is async (I think).
The implementation basically manages a set of color lookup tables for \
different outputs and for different window regions. These are taken via \
D-Bus. Each lookup table has around 700 KB. I hope I am not wrong in \
assuming it's not that big of an issue time-wise, since they are \
transferred only once or twice for an entire session. I hope D-Bus \
doesn't do any time consuming business to transfer those QVector's.
There is an issue with OpenGL ES, apparently it doesn't support 3D \
textures (probably it needs an extension or something). Until we envision a \
clear solution, I have disabled the color correction for OpenGL ES.
In case of problems, it should not affect the rest of KWin in any way.
Next priorities:
--
Implement per-window-region stuff. It should be a matter of extending \
KolorServer's capabilities and doing some small modifications in \
SceneOpenGL::Window. The ColorCorrection class from KWinEffects has \
everything prepared.
Fix issues with transparency / some weird colors.
--
There's another thing... I don't know when I'm supposed to be \
able to do improvements and modifications, since the GSoC project ended. \
Probably if I keep the new modifications well separated, there should be no \
issues.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing \
</h1> <table width="100%" bgcolor="#ffffff" cellspacing="0" \
cellpadding="10" style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Restarted KDED making sure Kolor-Manager is installed properly \
- this should make the KDED module available.
Restarted KWin, enabled color correction in KCM compositing, advanced tab.
Played a bit with commands like:
oyranos-monitor -d 0 XYZ.icc
oyranos-monitor -d 1 Lab.icc
Those set up particular profiles for the monitors. However, it seems there \
is a problem with reverting to the normal ones. The code regarding that is \
taken directly from CompICC, so I don't know whether it's a bug or \
a feature. Anyway, it's from Kolor-Server.
Apparently, everything works as planned. But I cannot distinguish visible \
differences for the profiles used for the different monitors by default.
There is an issue with the transparent areas - they are darkened somehow. \
This should be easy to fix, I have left the issue around because I \
hadn't time to finish before the GSoC deadline and it makes it possible \
to quickly find out whether color correction is enabled or not :). Perhaps, \
it's because of the blending function and not because of the \
correction. Also, there's something wrong with the highlights in gitk, \
I don't know exactly what. So, small issues are present. </pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> \
</h1> <ul style="margin-left: 3em; padding-left: 0;">
<li>kwin/composite.cpp <span style="color: grey">(c65716b)</span></li>
<li>kwin/kcmkwin/kwincompositing/main.cpp <span style="color: \
grey">(7a89db4)</span></li>
<li>kwin/kcmkwin/kwincompositing/main.ui <span style="color: \
grey">(cff0f63)</span></li>
<li>kwin/libkwineffects/CMakeLists.txt <span style="color: \
grey">(14a2747)</span></li>
<li>kwin/libkwineffects/kwineffects.h <span style="color: \
grey">(2c2f7bf)</span></li>
<li>kwin/libkwineffects/kwineffects.cpp <span style="color: \
grey">(bae85e7)</span></li>
<li>kwin/libkwineffects/kwinglcolorcorrection.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/libkwineffects/kwinglcolorcorrection.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/libkwineffects/kwinglcolorcorrection_p.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/libkwineffects/kwinglutils.h <span style="color: \
grey">(7a7c3c9)</span></li>
<li>kwin/libkwineffects/kwinglutils.cpp <span style="color: \
grey">(016d31e)</span></li>
<li>kwin/options.h <span style="color: grey">(9e4fcc6)</span></li>
<li>kwin/options.cpp <span style="color: grey">(72f168d)</span></li>
<li>kwin/scene.h <span style="color: grey">(3891198)</span></li>
<li>kwin/scene.cpp <span style="color: grey">(5782510)</span></li>
<li>kwin/scene_opengl.h <span style="color: grey">(de33ce4)</span></li>
<li>kwin/scene_opengl.cpp <span style="color: grey">(cbcc0ca)</span></li>
<li>kwin/workspace.cpp <span style="color: grey">(cf3f308)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/106141/diff/" \
style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots \
</h1>
<div>
<a href="http://git.reviewboard.kde.org/r/106141/s/695/"><img \
src="http://git.reviewboard.kde.org/media/uploaded/images/2012/08/23/cc_alter_6_400x100.png" \
style="border: 1px black solid;" alt="Output 0 Lab.icc Output 1 XYZ.icc" \
/></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic