Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update resynthesizer heal selection plugin to work with recent 2.99 release #136

Open
wants to merge 8 commits into
base: deprecations
Choose a base branch
from

Conversation

WarpspeedSCP
Copy link

@WarpspeedSCP WarpspeedSCP commented Nov 14, 2024

This PR updates the resynthesizer plugin to work with recent gimp 2.99 versions.

@WarpspeedSCP
Copy link
Author

This probably wont work with 3.0 RC as is; Im still trying to figure out why the gobject code is failing to compile.

@WarpspeedSCP
Copy link
Author

I've managed to get the plugin working with the latest 3.0 build on my machine, could anybody try compiling it to verify?

@WarpspeedSCP
Copy link
Author

I'll probably use this PR as a springboard to fix up the rest of the python plugins as well.

@lilydjwg
Copy link

I can't build it with gimp 3.0.0-RC1+git:

make  all-recursive
make[1]: Entering directory '/ldata/src/resynthesizer'
Making all in lib
make[2]: Entering directory '/ldata/src/resynthesizer/lib'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/ldata/src/resynthesizer/lib'
Making all in src
make[2]: Entering directory '/ldata/src/resynthesizer/src'
Making all in resynthesizer
make[3]: Entering directory '/ldata/src/resynthesizer/src/resynthesizer'
gcc -DHAVE_CONFIG_H -I. -I../..  -DLOCALEDIR=\""/usr/local/share/locale"\" -DDATADIR=\""/usr/local/share/resynthesizer"\" -I../.. -I/usr/include/gimp-3.0 -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/atk-1.0 -I/usr/include/gegl-0.4 -I/usr/include/json-glib-1.0 -I/usr/include/babl-0.1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/sysprof-6 -pthread -I/usr/include/libpng16 -I/usr/include/pixman-1 -I/usr/include/cloudproviders -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/fribidi -I/usr/local/include -I./../../lib -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGIMP_DISABLE_DEPRECATED  -g -O2 -Wall -MT resynthesizer-plugin.o -MD -MP -MF .deps/resynthesizer-plugin.Tpo -c -o resynthesizer-plugin.o `test -f 'plugin.c' || echo './'`plugin.c
plugin.c:37:9: error: unknown type name ‘GimpParam’; did you mean ‘GimpPath’?
   37 |         GimpParam * param,
      |         ^~~~~~~~~
      |         GimpPath
plugin.c:39:9: error: unknown type name ‘GimpParam’; did you mean ‘GimpPath’?
   39 |         GimpParam **      return_vals)   // OUT
      |         ^~~~~~~~~
      |         GimpPath
In file included from plugin.c:91:
resynthPDBv2.h: In function ‘query’:
resynthPDBv2.h:27:3: error: unknown type name ‘GimpParamDef’; did you mean ‘GimpParasite’?
   27 |   GimpParamDef *return_vals = NULL;
      |   ^~~~~~~~~~~~
      |   GimpParasite
resynthPDBv2.h:28:23: error: ‘resynth_paramdefs’ undeclared (first use in this function)
   28 |   gint nargs = sizeof(resynth_paramdefs)/sizeof(resynth_paramdefs[0]);
      |                       ^~~~~~~~~~~~~~~~~
resynthPDBv2.h:28:23: note: each undeclared identifier is reported only once for each function it appears in
resynthPDBv2.h:33:3: error: implicit declaration of function ‘gimp_install_procedure’ [-Wimplicit-function-declaration]
   33 |   gimp_install_procedure(
      |   ^~~~~~~~~~~~~~~~~~~~~~
resynthPDBv2.h:42:11: error: ‘GIMP_PLUGIN’ undeclared (first use in this function); did you mean ‘GIMP_PLUG_IN’?
   42 |           GIMP_PLUGIN,
      |           ^~~~~~~~~~~
      |           GIMP_PLUG_IN
resynthPDBv2.h: At top level:
resynthPDBv2.h:48:8: error: unknown type name ‘GimpPlugInInfo’; did you mean ‘GimpPlugIn’?
   48 | static GimpPlugInInfo PLUG_IN_INFO = {
      |        ^~~~~~~~~~~~~~
      |        GimpPlugIn
resynthPDBv2.h:49:3: error: initialization of ‘int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
   49 |   NULL, /* init_proc */
      |   ^~~~
resynthPDBv2.h:49:3: note: (near initialization for ‘PLUG_IN_INFO’)
resynthPDBv2.h:50:3: warning: excess elements in scalar initializer
   50 |   NULL, /* quit_proc */
      |   ^~~~
resynthPDBv2.h:50:3: note: (near initialization for ‘PLUG_IN_INFO’)
resynthPDBv2.h:51:3: warning: excess elements in scalar initializer
   51 |   query, /* query_proc */
      |   ^~~~~
resynthPDBv2.h:51:3: note: (near initialization for ‘PLUG_IN_INFO’)
resynthPDBv2.h:52:3: error: ‘run’ undeclared here (not in a function); did you mean ‘trunc’?
   52 |   run, /* run_proc */
      |   ^~~
      |   trunc
resynthPDBv2.h:52:3: warning: excess elements in scalar initializer
resynthPDBv2.h:52:3: note: (near initialization for ‘PLUG_IN_INFO’)
resynthPDBv2.h:57:1: error: return type defaults to ‘int’ [-Wimplicit-int]
   57 | MAIN()
      | ^~~~
plugin.c: In function ‘MAIN’:
plugin.c:105: error: expected ‘{’ at end of input
plugin.c:105: warning: control reaches end of non-void function [-Wreturn-type]
resynthPDBv2.h: At top level:
resynthPDBv2.h:48:23: warning: ‘PLUG_IN_INFO’ defined but not used [-Wunused-variable]
   48 | static GimpPlugInInfo PLUG_IN_INFO = {
      |                       ^~~~~~~~~~~~
make[3]: *** [Makefile:462: resynthesizer-plugin.o] Error 1
make[3]: Leaving directory '/ldata/src/resynthesizer/src/resynthesizer'
make[2]: *** [Makefile:355: all-recursive] Error 1
make[2]: Leaving directory '/ldata/src/resynthesizer/src'
make[1]: *** [Makefile:411: all-recursive] Error 1
make[1]: Leaving directory '/ldata/src/resynthesizer'
make: *** [Makefile:352: all] Error 2

@WarpspeedSCP
Copy link
Author

I did encounter something similar before. Can you check the values of the gimp major and minor versions? I added a few checks that section off the ui and gimp 2 related code but maybe I missed some parts.

@WarpspeedSCP
Copy link
Author

Oh, oops. I didn't commit certain changes. Fastforward and try again please!

@lilydjwg
Copy link

It compiles, but the installation seems wrong. GIMP 3 says plugins should be put in subdirectories inside the plugin-ins directory. It turns out the subdirectory name needs to match the filename too.

And then, a lot of No module named 'gimpfu' errors.

The "heal selection" plugin loads, but when I run it on a selection near the right border, an error complaining that new-height is out of range (-538 or so). It does the expected job though.

There are also error messages that look like memory correuption, e.g.

(resynthesizer:2257397): GLib-GObject-CRITICAL **: 22:11:54.967: g_object_get_is_valid_property: object class 'GimpProcedureConfigRun-plug-in-resyn
thesizer' has no property named 'P\u0012\xa7\xa4\x94U'                                                                                             

@WarpspeedSCP
Copy link
Author

WarpspeedSCP commented Nov 15, 2024

Yeah, the cropping code isnt fully fixed yet. Also, I've only updated the heal selection script at the moment which is why youre seeing the gimpfu errors.

Im still not sure whats causing the weird property bug though, thatll take a little time to debug

@bootchk
Copy link
Owner

bootchk commented Nov 15, 2024

I am following along. Ping me more directly (somehow?) if needed.

Thanks

@bootchk
Copy link
Owner

bootchk commented Nov 15, 2024

If you need help debugging the plugin, see the gimp dev website https://developer.gimp.org/resource/debug-plug-ins/

which is a work in progress, might be wrong or hard to follow.

Also, if you

export G_DEBUG=fatal-criticals

it should crash at that CRITICAL message, and might give you a stack trace.

If you have started the plugin in gdb per the website, it should stop in gdb and then >bt gives you the backtrace.
Generally I don't try to break into the running plugin, but set GIMP_PLUGIN_WRAP so that gdb starts automatically
when the plugin runs, and then you enter >r for run, and then it stops at the CRITICAL.

Need a backtrace.

It could be that the engine plugin has a bug that corrupts memory.
But it is not using properties, per se, so I suspect that it is in an outer plugin?
The plugin machinery (the GimpPlugin class in C) uses properties of a GimpConfig and of the GimpProcedure
to carry actual and formal arguments, among other things.

@WarpspeedSCP
Copy link
Author

WarpspeedSCP commented Nov 15, 2024

sounds like the way to go. I'm also seeing some very weird results with all around direction and random fill that I need to debug. In retrospect, I shouldn't have tried to be clever with how I tried to fix the out of range errors.

I think the property problem is likely because I forgot to specify the procedure API correctly.

The engine is working exactly as intended, I just need to fix the frontend.

Also, note that the current version of the plugin does not in any way attempt to retain the behaviour of the v2 plugin.

Copy link

@rautamiekka rautamiekka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also:

  • the indentations are all over the place.
  • function/method names both have and don't have a space before the opening parenthesis.

PluginScripts/plugin-heal-selection.py Outdated Show resolved Hide resolved
Comment on lines 152 to 160
frisketLowerLeftX = frisketBounds[0]
frisketLowerLeftY = frisketBounds[1]
frisketUpperRightX = frisketBounds[2]
frisketUpperRightY = frisketBounds[3]

targetLowerLeftX = target_bounds[0]
targetLowerLeftY = target_bounds[1]
targetUpperRightX = target_bounds[2]
targetUpperRightY = target_bounds[3]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
frisketLowerLeftX = frisketBounds[0]
frisketLowerLeftY = frisketBounds[1]
frisketUpperRightX = frisketBounds[2]
frisketUpperRightY = frisketBounds[3]
targetLowerLeftX = target_bounds[0]
targetLowerLeftY = target_bounds[1]
targetUpperRightX = target_bounds[2]
targetUpperRightY = target_bounds[3]
frisketLowerLeftX, frisketLowerLeftY, frisketUpperRightX, frisketUpperRightY = frisketBounds
targetLowerLeftX, targetLowerLeftY, targetUpperRightX, targetUpperRightY = target_bounds

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've used a different method to extract the coords now.

Copy link

@rautamiekka rautamiekka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nothing sticks out as wrong, but that ain't a guarantee.

@WarpspeedSCP
Copy link
Author

@lilydjwg can you try using the heal selection plugin with the new changes? You'll need to recompile.

@lilydjwg
Copy link

I see no issues except an error message saying gimp_plug_in_destroy_proxies: ERROR: GimpLayer proxy with ID 4 was refed by plug-in, it MUST NOT do that! and some logs from resynthesizer.

@bootchk
Copy link
Owner

bootchk commented Nov 16, 2024

Also, note that the current version of the plugin does not in any way attempt to retain the behaviour of the v2 plugin.

??? Is that correct? Just reading the code, it seems that it retains most of the behaviour, except regarding which selected layers are healed.

Re multi-layer select. Since that feature was added to GIMP 3, most plugins need to choose a strategy. I think that indeed the heal plugin should only heal one layer. I think it should warn if more layers are passed, saying something like "Will only heal the first selected layer."

But also, if many layers are passed, maybe the heal plugin should use as corpus: the flattened set of passed layers, in a copy. Because the user may expect to heal as it is visible, and the multiple layers may have a different visual appearance, due to transparency, and even compositing modes?

Some plugins might choose a strategy: iteratively operate on all passed layers. I haven't given this enough thought, what would it mean to iteratively heal many layers, from which corpuses?

While you are at it, could you please change the attribution of the plugin, from James Henstridge to Paul Harrison?
He is the original author of the plugin. Henstridge wrote PyGimp, and provided example plugins.
While Paul Harrison probably copied an example from Henstridge, I think that the essential credit belongs to Paul Harrison.You can other names too, as you see fit.

@bootchk
Copy link
Owner

bootchk commented Nov 16, 2024

Also, I see you have touched resynthesizer-gui.c. That is fine, if just to get it to compile.

But I think it needs a major rewrite OR replace with a Python or ScriptFu plugin. The C is in Gtk2 and probably needs much work to get to Gtk 3 (and then to Gtk 4 eventually.) But it is really just a GUI front end to the engine, and could be replaced by a plugin in a higher level language. (Possibly with minor loss of user-friendliness.) Which is the plan, see the roadmap. I can't remember whether I already have a prototype in Python or Scheme.

@WarpspeedSCP
Copy link
Author

??? Is that correct? Just reading the code, it seems that it retains most of the behaviour, except regarding which selected layers are healed.

Ah, not any more, I think. But I'm still not sure what being considered "active" entails.

Maybe I should include a switch for "merge all visible layers before healing".

Also, I see you have touched resynthesizer-gui.c.

This was just to add in version guards, simce all that code is meant to work only with gimp 2.

While you are at it, could you please change the attribution of the plugin, from James Henstridge to Paul Harrison?

Will do. Its just waht happens when you copy paste plugin code, I guess.

@Rizzlord
Copy link

sooo, awesome! But how do i try it out? Would love to finally abandon gimp 2.10

@WarpspeedSCP
Copy link
Author

WarpspeedSCP commented Nov 18, 2024

It'll take a bit of work (and time), especially on windows. I can try making a windows build at some point, but I have been a bit busy, so it's difficult to say when I can truly do it.

If you'd like to try compilimg it yourself, I believe ypu will need to use mingw and something like git bash to do so.

@rautamiekka
Copy link

Reminding just in case: as of Win10 you don't need to buy (or even crack) the OS anymore if you'll just use it for app dev, as the only restrictions will be the personalization options such as the wallpaper.

@WarpspeedSCP
Copy link
Author

I have win10 ready on a vm, I just haven't set up the dev env.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants