Strange G'MIC behavior.
Sun Jul 03, 2022 12:57 pm
Gimp-2.10.32 Win10 Home 64bit, G'MIC-3.1.5.
Such strange mistakes:
1. Open any image.
2. Close it.
3. Open an image with transparency.
4. Run G'MIC: the preview and result remembers the first image for some filters:
5. Some, however, work properly:
Such strange mistakes:
1. Open any image.
2. Close it.
3. Open an image with transparency.
4. Run G'MIC: the preview and result remembers the first image for some filters:
5. Some, however, work properly:
Re: Strange G'MIC behavior.
Sun Jul 03, 2022 1:05 pm
I have noticed this when I deleted certain layers before using GMIC and then they will show up while running it. I had to totally close out GIMP and start all over, as it would not go away unless I did.
Re: Strange G'MIC behavior.
Sun Jul 03, 2022 9:31 pm
Maybe a Windows problem? I did tried many times, this does Not happen on Linux & G'MIC 3.1.5
Re: Strange G'MIC behavior.
Mon Jul 04, 2022 7:06 am
No problems here either running Linux & Gmic 3.1.0 in Gimp 3.10.32
Re: Strange G'MIC behavior.
Mon Jul 04, 2022 8:54 am
@MareroQ
I have noticed that some of the gmic filters do not respect transparency and in addition where many image viewers will show white gmic shows black.
All depends on the png export, the Save color values from transparent pixels check box
These 3, all portrait (Lena) with transparent background and the gmic frame (blur) filter
(1) Exported with "Save color values.....ON
(2) Exported with "Save color values ... OFF
(3) PNG with alpha removed to lose the BG pixels, transparency restored, then same as (1)
Using kubuntu 20.04 / Gimp 2.10.32 / gmic 3.1.5
I have noticed that some of the gmic filters do not respect transparency and in addition where many image viewers will show white gmic shows black.
All depends on the png export, the Save color values from transparent pixels check box
These 3, all portrait (Lena) with transparent background and the gmic frame (blur) filter
(1) Exported with "Save color values.....ON
(2) Exported with "Save color values ... OFF
(3) PNG with alpha removed to lose the BG pixels, transparency restored, then same as (1)
Using kubuntu 20.04 / Gimp 2.10.32 / gmic 3.1.5
- gmic.jpg (99.91 KiB) Viewed 1457 times
Re: Strange G'MIC behavior.
Fri Jul 08, 2022 8:42 am
Thanks for the comments.
I have ruled out that it might be a problem with the Windows clipboard.
I have tried to determine if this also happens in older versions of G'MIC and Gimp (this time I saved the image sample_lena.png with a square cutout as xcf).
This is not a Windows problem - I can repeat it on Linux.
As a result, probably all versions of QT (in G'MIC GTK worked fine) have this problem (or the advantage of recovering "deleted" pixels!).
But I tried GIMP-2.8.22 and here I noticed the differences - the reason is the behavior of Gimp 2.10 - it doesn't delete information from the channel (with Cut or Delete operation) if the image has an alpha channel (when Gimp-2.8 was deleting!).
Maybe there is some unknown to me option to set in Gimp 2.10 - because now it looks like a bug (or maybe I missed the information that now "it is better")?
I have ruled out that it might be a problem with the Windows clipboard.
I have tried to determine if this also happens in older versions of G'MIC and Gimp (this time I saved the image sample_lena.png with a square cutout as xcf).
This is not a Windows problem - I can repeat it on Linux.
As a result, probably all versions of QT (in G'MIC GTK worked fine) have this problem (or the advantage of recovering "deleted" pixels!).
But I tried GIMP-2.8.22 and here I noticed the differences - the reason is the behavior of Gimp 2.10 - it doesn't delete information from the channel (with Cut or Delete operation) if the image has an alpha channel (when Gimp-2.8 was deleting!).
Maybe there is some unknown to me option to set in Gimp 2.10 - because now it looks like a bug (or maybe I missed the information that now "it is better")?