GMIC in Krita

[Lukast dev]

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 at 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 more
> > 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 be
> > 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 of
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130914/495b9cf2/attachment.html>