Any chance to take this outside gimp?

[WindowsNT]

I am trying to take this outside gimp, mainly working on the original resynthesizer but perhaps you can help by providing me the basic ideas of design. I can see that the main engine is in engine.c. What's the corpus target? What's the input/output map?

It would be nice to see this as a general raw plugin not bound to gimp.

[bootchk]

Yes, that is definitely on the TODO list and I would be glad to help extensively, if the work is open.

The engine is already divorced from GIMP.

There have been other attempts to use it separately. I can't remember the issue # but it should still be open and easily found.)

If you mean give it a better API and better documentation, yes that could be done. If you mean put the engine in some other library, yes also, keep reading.

I am working on resynthesizer as we speak (mainly the issue of the Python 2 plugins and Gimp v3)

There are four "images" i.e. pixmaps involved. Mainly the target and the corpus. The target is an image that for most uses has a selection that is a hole to be filled in. The target is the searchee for patch searches. The corpus is the searchand, what is searched. More precisely, the hole in the target is the searchee, but the context, the surroundings in the target, are part of the searchee patches. Often the corpus is just a copy of the context of the hole in the target, but not always.

The maps are just another complication (weightings), you can probably ignore them for first study.

The engine has its own pixmap implementation. Lately I have been thinking of finding a barebones pixmap library and cutting the one out of the resynthesizer engine library. I looked at one (can't remember the name) but it stored pixels in channel order (all the red values in one array so to speak) I have been thinking that it is fit for a more object oriented implementation, say in C++ or Rust, but surely there is a generic pixmap implementation out there already. (The issue for the engine is that each pixelel combines the colors, the alpha, the selection masks, other masks, and the map bytes, as I recall. In other words, need a pixmap generic on pixelel type.)

Also considering whether to use any pixmap implementation from openCV, and/or make the engine part of openCV.

Also considering whether to use the pixmap implentation from GEGL and make the engine an operation in GEGL.

Also considering whether to write it in Python as a first step in documenting how it works and what objects are needed. Not caring whether it was fast, just as a step on the way to a more performant implementation.

You mean you are working with the code by Paul Harrison, v 0.16?

[WindowsNT]

Thanks a lot for your comments, you have helped me enough.

1. I tried to work with 0.16 but I didn't complete it, tbh I did not mess a lot with it but now with your clarifications I might be able to.

2. The idea is to use it in my image, audio and video editor as an additional tool. I also use OpenCV's inpaint which does not perform well as I can understand.

3. Keeping it in C++ would be best and perhaps use an abstract mechanism to read /write pixels, which can be implemented in Opencv or Windows WIC or Direct2D or whatever.

4. If everything in lib/ folder is the engine and its not gimp dependent then I will start working on it based on the valuable clues you have provided.

[WindowsNT]

I have successfully compiled the lib folder by replacing most gthread/pthread with std::thread and the mutexes with std::recursive_mutex; Soon I hope I 'll have results.

[bootchk]

See #73. I just merged a request from that issue that helps build the engine library without depending on GLib.

Sorry if you have already duplicated some of that. Although if you think the merged code (which uses posix threads) is inferior to std::thread, feel free to open another merge request.

As I said, I plan many changes. Most not affecting the library. Then I hope to start by documenting the library API, and only then possibly improving the library.