plugin or filter distribution, resynthesizer

[Boudewijn Rempt]

On Mon, 19 Oct 2015, lloyd konneker wrote:

> OK, thanks.
>
> Now I need a little more motivation.  Is the resynthesizer something that Krita user’s would actually use?

Well, part of Krita's vision is that krita can be used for matte painting, and that's where a resynthesizer plugin will come in very handily :-)

>
> Again, I have a very shallow understanding of Krita, but it seems it has a slightly different use case: creative painting rather than photo retouching.   Resynthesizer (in its most useful variant, “Heal selection”) does “I don’t like this area, please replace it to look like its surroundings.”  But does the user think of “strokes” or other objects that they can edit/move, and does a filter such as resynthesizer need to understand those objects?  Or would that all be transparent to the filter code (as well as the Undo mechanism?)  I guess my question is related to the GIMP’s move towards GEGL and a pipeline/graph of forever editable operations.
>

No -- strokes in Krita are actually actions with a begin, middle and end that can be started and run on while you can start another stroke. Brush strokes end up as pixels, so all that is transparent to you, it would just be that you have a selection and run the filter on the selected pixels.

> I’m not sure that there is a Debian maintainer, or what distribution streams resynthesizer is in.

Chances are that if there are two users for your library that, if you do releases, distributions will start packaging it. We also got them to package Vc, for instance.

> Maybe it makes more sense to port resynthesizer to Gmic but maybe they already have a different algorithm (seam carving?) for the same operation.

Hm, that's a bit outside my field of experience. To port it to gmic, you'd probably need to rewrite it in g'mic's scripting language.

Boudewijn