[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: GMIC in Krita
From:       Paul Geraskin <paulgeraskin () gmail ! com>
Date:       2013-09-15 2:43:40
Message-ID: CAJ6j8mJWGTpZOy05X=n8ufTuaXjQEc4=Bnc8rwjsWsdPZG3_yQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Super! Just let me know if you need a tester :-)

15.09.2013 0:58 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "Lukast dev" <lukast.dev@gmail.com> =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:
>
> Hi,
>
> I just wanted to let you know that Gmic plug-in for Krita was merged to
master.
> It is very experimental currently and it eats kittens (crashes can be
expected)
>
> Here are banch of working filters
> http://i.imgur.com/WvDHxhz.jpg
>
>   Curent status of gmic filters in Krita:
>     - total filters: 260
>     - known failings (blacklisted filters): 18
>     - known success: 80
>
> The testing of filters is automatic but takes time, so I will blacklist
all crashing filters.
>
> Multi-layer input filters are not working yet. That is my next priority
to fix (so that recolorize works etc.)
>
> Cheers
> Lukas
>
>
>
> 2013/4/21 Lukast dev <lukast.dev@gmail.com>
>>
>> Hi Jay,
>>
>> >  - Re-Use of Parameter Information
>> > You can see there are lines within gmic_def.NNNN that define "Poster
Edges"
>> > filter and also specifies the types and ranges of the input variables.
 The
>> > gmic_gimp plugin uses those definitions to present a user interface.
>> > Perhaps "#@gimp" lines should change to "#@interface" or something mor=
e
>> > Krita friendly.
>>
>> Krita friendly? It's ok to let it be :)
>>
>> >  - Version Control of Core "DEF" file
>> > If you did split-out just those parts of the gmic_def then you may
need to
>> > maintain your fork
>>
>> I don't want to fork at all.
>> I'd like to be able to link dynamically against gmic,
>> so that Linux distributions provide always up-to-date
>> gmic.
>>
>> >  - Rewriting 8-bit scripts : TO DO
>> > Since 2.9/2.10 are moving to higher bit depth and deprecating the
existing
>> > plugin interface, it seems likely a GMIC Script GEGL node will be made
that
>> > always requests a 32bit-float RGBA format, in which case many GMIC
scripts
>> > that assume a 0-255 8bit value from the current plug-in will need to b=
e
>> > amended to cope.
>>
>> It's little bit confusing with 255.0 values of pixels and this options
>> and 8-bit encoding.
>>
>> GMIC is using Float32 bit internally but expect that the picture is in
range
>> 0.0 - 255.0 to work nicely with parameters of filters.
>>
>> Krita is representing pixel in Float32 in range 0.0-1.0.
>> So for now I normalize it on input and output.
>> David showed me command in gmic that can do that, no problem.
>>
>> >  - ColourSpace Assumption
>> > As far as I understand values passed from GIMP are for an sRGB
Colourspace
>> > but most of the plugins currently make no adjustment to linearise
before
>> > processing - this is something better curation of filters could solve.
>>
>> Do we need linear rgb? What would be the real benefits for users?
>>
>>
>> > There are also some "features" of the Alpha channel handling.  Most
scripts
>> > that ignore Alpha will delete the transparency rather than retain it.
>> > Again, it's a matter of curation.
>>
>> Uh, good to know this! Thanks!
>>
>> > I'd be interested in a more database driven system to track versions o=
f
>> > filters and maximise user interaction.  There was something in KDE
that Boud
>> > mentioned at LGM as being worth looking at but I am a Windows user
myself
>> > and have not found it yet.  A hosted repository with some kind of
upload,
>> > search, tagging, user-feedback but also version control and regression
>> > testing would seem desirable in addition to curation metadata about
>> > colourspace and transparency etc..
>>
>> GetHotNewStuff http://ghns.freedesktop.org/
>>
>> Regards,
>> Lukas
>
>
>
> _______________________________________________
> Krita mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>

[Attachment #5 (text/html)]

<p>Super! Just let me know if you need a tester :-)</p>
<p>15.09.2013 0:58 ÐÏÌØÚÏ×ÁÔÅÌØ &quot;Lukast dev&quot; &lt;<a \
href="mailto:lukast.dev@gmail.com">lukast.dev@gmail.com</a>&gt; ÎÁÐÉÓÁÌ:<br> &gt;<br>
&gt; Hi,š<br>
&gt;<br>
&gt; I just wanted to let you know that Gmic plug-in for Krita was merged to \
master.<br> &gt; It is very experimental currently and it eats kittens (crashes can \
be expected)<br> &gt;<br>
&gt; Here are banch of working filters<br>
&gt; <a href="http://i.imgur.com/WvDHxhz.jpg">http://i.imgur.com/WvDHxhz.jpg</a><br>
&gt;<br>
&gt; š Curent status of gmic filters in Krita:<br>
&gt; š š - total filters: 260<br>
&gt; š š - known failings (blacklisted filters): 18<br>
&gt; š š - known success: 80<br>
&gt;<br>
&gt; The testing of filters is automatic but takes time, so I will blacklist all \
crashing filters.<br> &gt;<br>
&gt; Multi-layer input filters are not working yet. That is my next priority to fix \
(so that recolorize works etc.)<br> &gt;<br>
&gt; Cheers<br>
&gt; Lukas<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; 2013/4/21 Lukast dev &lt;<a \
href="mailto:lukast.dev@gmail.com">lukast.dev@gmail.com</a>&gt;<br> &gt;&gt;<br>
&gt;&gt; Hi Jay,<br>
&gt;&gt;<br>
&gt;&gt; &gt; š- Re-Use of Parameter Information<br>
&gt;&gt; &gt; You can see there are lines within gmic_def.NNNN that define \
&quot;Poster Edges&quot;<br> &gt;&gt; &gt; filter and also specifies the types and \
ranges of the input variables. šThe<br> &gt;&gt; &gt; gmic_gimp plugin uses those \
definitions to present a user interface.<br> &gt;&gt; &gt; Perhaps &quot;#@gimp&quot; \
lines should change to &quot;#@interface&quot; or something more<br> &gt;&gt; &gt; \
Krita friendly.<br> &gt;&gt;<br>
&gt;&gt; Krita friendly? It&#39;s ok to let it be :)<br>
&gt;&gt;<br>
&gt;&gt; &gt; š- Version Control of Core &quot;DEF&quot; file<br>
&gt;&gt; &gt; If you did split-out just those parts of the gmic_def then you may need \
to<br> &gt;&gt; &gt; maintain your fork<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t want to fork at all.<br>
&gt;&gt; I&#39;d like to be able to link dynamically against gmic,<br>
&gt;&gt; so that Linux distributions provide always up-to-date<br>
&gt;&gt; gmic.<br>
&gt;&gt;<br>
&gt;&gt; &gt; š- Rewriting 8-bit scripts : TO DO<br>
&gt;&gt; &gt; Since 2.9/2.10 are moving to higher bit depth and deprecating the \
existing<br> &gt;&gt; &gt; plugin interface, it seems likely a GMIC Script GEGL node \
will be made that<br> &gt;&gt; &gt; always requests a 32bit-float RGBA format, in \
which case many GMIC scripts<br> &gt;&gt; &gt; that assume a 0-255 8bit value from \
the current plug-in will need to be<br> &gt;&gt; &gt; amended to cope.<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s little bit confusing with 255.0 values of pixels and this \
options<br> &gt;&gt; and 8-bit encoding.<br>
&gt;&gt;<br>
&gt;&gt; GMIC is using Float32 bit internally but expect that the picture is in \
range<br> &gt;&gt; 0.0 - 255.0 to work nicely with parameters of filters.<br>
&gt;&gt;<br>
&gt;&gt; Krita is representing pixel in Float32 in range 0.0-1.0.<br>
&gt;&gt; So for now I normalize it on input and output.<br>
&gt;&gt; David showed me command in gmic that can do that, no problem.<br>
&gt;&gt;<br>
&gt;&gt; &gt; š- ColourSpace Assumption<br>
&gt;&gt; &gt; As far as I understand values passed from GIMP are for an sRGB \
Colourspace<br> &gt;&gt; &gt; but most of the plugins currently make no adjustment to \
linearise before<br> &gt;&gt; &gt; processing - this is something better curation of \
filters could solve.<br> &gt;&gt;<br>
&gt;&gt; Do we need linear rgb? What would be the real benefits for users?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; There are also some &quot;features&quot; of the Alpha channel handling. \
šMost scripts<br> &gt;&gt; &gt; that ignore Alpha will delete the transparency rather \
than retain it.<br> &gt;&gt; &gt; Again, it&#39;s a matter of curation.<br>
&gt;&gt;<br>
&gt;&gt; Uh, good to know this! Thanks!<br>
&gt;&gt;<br>
&gt;&gt; &gt; I&#39;d be interested in a more database driven system to track \
versions of<br> &gt;&gt; &gt; filters and maximise user interaction. šThere was \
something in KDE that Boud<br> &gt;&gt; &gt; mentioned at LGM as being worth looking \
at but I am a Windows user myself<br> &gt;&gt; &gt; and have not found it yet. šA \
hosted repository with some kind of upload,<br> &gt;&gt; &gt; search, tagging, \
user-feedback but also version control and regression<br> &gt;&gt; &gt; testing would \
seem desirable in addition to curation metadata about<br> &gt;&gt; &gt; colourspace \
and transparency etc..<br> &gt;&gt;<br>
&gt;&gt; GetHotNewStuff <a \
href="http://ghns.freedesktop.org/">http://ghns.freedesktop.org/</a><br> &gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt; Lukas<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Krita mailing list<br>
&gt; <a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
&gt; <a href="https://mail.kde.org/mailman/listinfo/kimageshop">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
 &gt;<br>
</p>



_______________________________________________
Krita 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