Selection moves after applying a filter

I believe there is a problem with how gmic is handling the new non-destructive cropping feature. When I make a selection and apply a gmic filter to the selection on a canvas that has been cropped, the canvas moves underneath the selection.

To recreate…

  1. Crop an image
  2. Make a selection
  3. Apply a gmic filter


I’ve also attached a small video showing the steps. I apologize if this is not a gmic issue, but this isn’t happening on the few stock gimp filters I’ve tried.

gmic-selection-moves.mkv (818.9 KB)

The video was helpful. Unfortunately, I can’t reproduce your issue. The only time I have a problem is when G’MIC changes the dimensions of the input image. Sharpen (inverse diffusion) doesn’t do that.

Which versions of GIMP and G’MIC are you using and have you updated your filters?

Which versions of GIMP and G’MIC are you using and have you updated your filters?

I’m sorry that I forgot to include that info.

Arch Linux 5.7.3-arch1-1
GIMP 2.10.20
gimp-plugin-gmic 2.9.1-2

I just updated the filters and also tried with about a dozen random filters and am getting the same result.

Will update my system and report back if anything changes.

Ah, you are more up to date than I. :face_with_hand_over_mouth: Perhaps a new bug or something else… Can anyone confirm @akovia’s issue?

Thanks for reporting this @akovia.
The non-destructive crop feature is indeed new in GIMP, and I suspect we have to manage it in the plug-in as well.
as it’s quite hard to find up-to-date documentation about this feature in the GIMP plug-in API, I doubt we can fix this easily, but maybe one of the GIMP developer could help
(@Jehan ?).

You can read a description of the non-destructive cropping here (not API, just behaviour).

Once sorted out, I hope it resolves the layer and canvas issue I get when resizing and aligning with the G’MIC plugin (preview and output).

Start here?

The “non destructive cropping” basically only allows redimensionning the canvas with the Crop tool. It doesn’t do anything particularly new and these were things which were already possible before (it just used to be a bit more cumbersome and less visual; the Crop tool changes allows on-canvas preview of the old canvas size feature basically).

I am guessing the issue which you encounter could also happen if you were to redimension the canvas with Image > Canvas Size… option or just if you moved the layer (with the Move tool) into a negative offset.

Basically my guess is that G’Mic is repositionning the layer after the filter with offset 0. If G’Mic needs to do anything relative to layer position, it should check its offsets first with gimp_drawable_offsets() and do appropriate computation to decide what are the right offsets afterwards. Offsets can be positive or negative. We cannot assume anything there.

Hope this helps! :slightly_smiling_face:

1 Like

OK, I’ve been able to reproduce the bug in GIMP 2.10.18 as well.
Will be easier to debug for us. Thanks for the suggestions, @Jehan !

1 Like

Hopefully, this commit should fix the issue.
Will be available in next version 2.9.2 of G’MIC.

@Jehan, also we have a slight issue.
We are using:

            gimp_item_transform_translate(inputLayers[p], 0, 0);

just to be able to ‘update’ the modified layer on the GIMP view (which is an ugly way of doing it indeed).
Without that, we can see that the layer has been modified, because of the layer preview in the Layer dialog, but the real view is not updated.
We haven’t found any other solution. I’ve tried other things as gimp_drawable_flush, gimp_display_flush and the merge_shadow stuffs, but nothing is working.
Do you have an idea ?

I am guessing you are modifying directly the GeglBuffer associated with a drawable, aren’t you? The sync with the drawable is “lazy”, it doesn’t happen with just a modification. You need to g_object_unref() it, which forces its content to be synced back into the drawable.

Alternatively, for instance if you want to refresh the drawable render but are not done with the buffer (you want to continue modifying it), you can gegl_buffer_flush() it instead. Then you keep the buffer reference and still get it to be displayed properly in the canvas.

Well, we already call g_object_unref(), and it doesn’t refresh the drawable render :slight_smile:

I don’t know what is happening. The GIMP API looks a bit obscure for us to be honest :slight_smile:
If you have any idea, just let us know !