Gimp 2.99.19 to RC1 Development (complete)

ajonsson · **Joined:** Sep 16, 2024 **Posts:** 1

Rod wrote:

I really like utilizing the Legacy Icon Theme as it is colored. It would be nice to see those Icons in it as well. :hehe

Yes, legacy is missing some icons. Another possibility for color icons is unchecking the symbolic icon checkbox for the Default theme.

Rod · **Joined:** May 16, 2010 **Posts:** 16167

ajonsson wrote:

Rod wrote:

I really like utilizing the Legacy Icon Theme as it is colored. It would be nice to see those Icons in it as well. :hehe

Yes, legacy is missing some icons. Another possibility for color icons is unchecking the symbolic icon checkbox for the Default theme.

Good to know! :coolthup

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

I just checked two issues off this.
viewtopic.php?f=7&t=20876&p=291518#p291518

The interger conversion xcf corruption bug is solved a week ago
The non rectangular selection tool drawable issue was solved today

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

CMYK Student and Jehan are investigating how to solve a bug relating to internal crop nodes in filters clipping layers
https://gitlab.gnome.org/GNOME/gimp/-/m ... uests/1862

to solve the following bugs
https://gitlab.gnome.org/GNOME/gimp/-/issues/11252
https://gitlab.gnome.org/GNOME/gimp/-/issues/11690

--
btw, a lot of stuff is going on in my life and I might not be able to actively cover GIMP 2.99.19 development anymore...

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

Jehan is adding code to GIMP now that detects what version of a GEGL filter/plugin is being used. Unfortunately I don't version number my plugins so this will have no effect with anything of mine.

https://gitlab.gnome.org/GNOME/gimp/-/c ... c8da628389
https://gitlab.gnome.org/GNOME/gimp/-/m ... uests/1660
https://gitlab.gnome.org/GNOME/gegl/-/m ... quests/175

quietreader · **Joined:** Apr 11, 2024 **Posts:** 307

Quote:

I don't version number my plugins

Might be a good idea to start versioning.
It would be easier for you, too. If s.o. has a problem, you can then ask them about the version number and see if it's the newest one.

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

GIMP's team, by the advice of Pippin to Jehan has decided to disallow GEGL Graph syntax as a non-destructive filter due to exploits that could overwrite/corrupt files on the users system. Explained simply the GEGL syntax I write could maliciously be used to overwrite files on the user's device. A malicious actor can send a intentionally harmful .xcf file with gegl syntax that overwrites their files.

gegl graph can only be used in GIMP 2.99.19+ non-destructively if the environment variable below is set

Code: Select all

GIMP_ALLOW_GEGL_GRAPH_LAYER_EFFECT

and currently I don't know how to set it.

Attachment:

envar.png [ 59.31 KiB | Viewed 6451 times ]

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

This bug relating to the color picker picking incorrect colors was accidentally solved somewhere a long the way.
https://gitlab.gnome.org/GNOME/gimp/-/issues/10998

The SF-VALUE reference in script fu bug was also solved
https://gitlab.gnome.org/GNOME/gimp/-/issues/8463
https://gitlab.gnome.org/GNOME/gimp/-/m ... uests/1866

Infact, all script-fu milestones in https://gitlab.gnome.org/GNOME/gimp/-/m ... tab-issues should be wrapping up soon.

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

I put this in my prefix file for GIMP 2.99.19 and I can now use non-destructive GEGL Graph's

Code: Select all

GIMP_ALLOW_GEGL_GRAPH_LAYER_EFFECT=1
export GIMP_ALLOW_GEGL_GRAPH_LAYER_EFFECT

For a normal linux install (.deb/.rpm/.pacman)

edit

/etc/environment

and put

Code: Select all

GIMP_ALLOW_GEGL_GRAPH_LAYER_EFFECT=1

For Flatpak Linux

Attachment:

2024-09-26_17-10.png [ 108.53 KiB | Viewed 6435 times ]

1. Install Flatseal

Under Variables put the same

Code: Select all

GIMP_ALLOW_GEGL_GRAPH_LAYER_EFFECT=1

This will allow Linux users to use GEGL Graph non-destructively in GIMP 2.99.19+

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

https://www.gimp.org/news/2024/10/05/de ... nt-update/

GIMP's team published a news report. Most of this is old news to me and I have mentioned it here before, but I'll review important things.

Applying GEGL filters non-destructively on layer groups has been around since March-April 2024 but the world doesn't really know because they are stuck on the broken 2.99.18 public release from Feb 2024. This is old news to me but new for the public. They use the term "adjustment layer groups".

Python and Script fu have been reworked, infact Python has been entirely reworked from python 2 in GIMP 2.10. Not only is it now using Python 3 but GIMP's team gave it a ton of new native UI options in GIMP. But what works in GIMP 2.10 won't work in GIMP 3. So think of it like this, all python is broke from 2.10 to 3. But only some of script fu is broke from 2.10 to 3. Still Python Filters CANNOT be used non-destructively.

Pippin's (GEGL's developer) work on a app he made called ctx vector, which is a small library in GIMP 2.99.19 that can be called through GEGL. btw, one day it might make vector layers.
Learn more about CTX here
https://ctx.graphics/

A ton of bugs were solved and they thank me and others

The color space invasion is mostly done but a few pesky issues remain
https://gitlab.gnome.org/GNOME/gimp/-/issues/6933
https://gitlab.gnome.org/GNOME/gimp/-/issues/10998
https://gitlab.gnome.org/GNOME/gimp/-/issues/3015

Darktable is a photography processing app, A famous Dark Table GIMP plugin broke for GIMP 2.10. If you use the latest version of Dark Table. Its obviously broke on GIMP 3, but the news is it a sad story that it broke on 2.10. GIMP's team recommends people downgrade Dark Table to solve it but the problem is Linux makes downgrading difficult as its compile only to get older version of stuff.

GIMP 3 RC1 is implied to be right around the corner.

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

Two important bugs were solved

1. The bug where render filters like (gegl:spiral, gegl:cell-noise) stay the same size when the canvas up scales, has been solved. Though it may have created a new bug.

2. The GIMP multi non-destructive filter clip bug has been solved
https://gitlab.gnome.org/GNOME/gimp/-/m ... 619cd07fab

Multiple filters such as drop shadow can be applied on top of each other without clipping. Before they would clip as a rectangle as if the user applied "crop to content" on them. I noticed this bug Jan 1st 2024 day one of using NDE GIMP 3 and it was only solved a few days ago.

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

News update

1.
GIMP 2.99.19 is going extremely slow and has new bugs because the update (linked below) was suppose to allow chaining filters without clipping
https://gitlab.gnome.org/GNOME/gimp/-/t ... mitigation

https://gitlab.gnome.org/GNOME/gimp/-/issues/12144
https://gitlab.gnome.org/GNOME/gimp/-/issues/12125
https://gitlab.gnome.org/GNOME/gimp/-/issues/12154
https://gitlab.gnome.org/GNOME/gimp/-/issues/12161

It appears gegl:crop may be fundementally flawed. This is serious road block for GIMP Team and it effects my plugins

2.
I made an inaccurate claim last month that every trace of GIMP rgb was removed. Well now that claim is accurate, GIMP is 100% gimprgb free and uses proper geglcolor from Space Invasion.
https://gitlab.gnome.org/GNOME/gimp/-/issues/9947

3.
Filters like Brightness-contrast that converted to curves would duplicate themselves under certain conditions, this bug has been solved.
https://gitlab.gnome.org/GNOME/gimp/-/issues/12141

-
If there is anything to take note from this update its that GIMP team is having serious problems with gegl:crop and the only known way to stop it is to just keep GIMP 2.99.19 the way it was historically and allow clipping. Based on what I know it seems less likely but not impossible GIMP 3 will release in 2024.

CmykStudent · **Joined:** Dec 28, 2023 **Posts:** 67

With respect, contrast_ is mistaken on several points.

GIMP 2.99.19 as a whole is not going any slower (in fact, Jehan just made an update to babl that speeds up several color processing filters like Hue-Saturation). There is also nothing wrong with the gegl:crop filter, and it will not need to be rewritten.

The problem regarding the filter cropping code is related to the function that gets and updates the "area" of the filter (so we can resize smaller filters on top to prevent them from cropping larger filters below them). We didn't realize it until after it was merged, but the GEGL function we call to get the area is quite slow. Because the refresh resize code runs often, this causes a good amount of slowdown if you stack multiple filters on top of each other.

I'm currently designing a fix that should improve performance, which I hope to post for review this week. I do not foresee this having any impact on the development schedule however, as we are now down to 8 blocking issues remaining.

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

CmykStudent wrote:

With respect, contrast_ is mistaken on several points.

GIMP 2.99.19 as a whole is not going any slower (in fact, Jehan just made an update to babl that speeds up several color processing filters like Hue-Saturation). There is also nothing wrong with the gegl:crop filter, and it will not need to be rewritten.

The problem regarding the filter cropping code is related to the function that gets and updates the "area" of the filter (so we can resize smaller filters on top to prevent them from cropping larger filters below them). We didn't realize it until after it was merged, but the GEGL function we call to get the area is quite slow. Because the refresh resize code runs often, this causes a good amount of slowdown if you stack multiple filters on top of each other.

I'm currently designing a fix that should improve performance, which I hope to post for review this week. I do not foresee this having any impact on the development schedule however, as we are now down to 8 blocking issues remaining.

Allow to explain why I wrote that.

My plugins are going extremely slow due to clip-mitigation. 10 seconds to update a text character. I have faith it will be fixed.

I found a ton of new bugs that came after the clip-mitigation

Today after I gave gegl:crop an aux some bugs went away. I assued GEGL crop was the culprit.

I will try not to spread misinformation thanks for correcting me but I insist my plugins are extremely slow. I triggered the same problem with 3 dropshadows.

Rod · **Joined:** May 16, 2010 **Posts:** 16167

contrast_ wrote:

CmykStudent wrote:

With respect, contrast_ is mistaken on several points.

GIMP 2.99.19 as a whole is not going any slower (in fact, Jehan just made an update to babl that speeds up several color processing filters like Hue-Saturation). There is also nothing wrong with the gegl:crop filter, and it will not need to be rewritten.

The problem regarding the filter cropping code is related to the function that gets and updates the "area" of the filter (so we can resize smaller filters on top to prevent them from cropping larger filters below them). We didn't realize it until after it was merged, but the GEGL function we call to get the area is quite slow. Because the refresh resize code runs often, this causes a good amount of slowdown if you stack multiple filters on top of each other.

I'm currently designing a fix that should improve performance, which I hope to post for review this week. I do not foresee this having any impact on the development schedule however, as we are now down to 8 blocking issues remaining.

Allow to explain why I wrote that.

My plugins are going extremely slow due to clip-mitigation. 10 seconds to update a text character. I have faith it will be fixed.

I found a ton of new bugs that came after the clip-mitigation

Today after I gave gegl:crop an aux some bugs went away. I assued GEGL crop was the culprit.

I will try not to spread misinformation thanks for correcting me but I insist my plugins are extremely slow. I triggered the same problem with 3 dropshadows.

Could it be the blur filter slowing them down?

CmykStudent · **Joined:** Dec 28, 2023 **Posts:** 67

Rod: Hi! Not exactly.

We had this issue where if you had a filter that goes outside the layer (like drop shadow), putting another filter on top would crop the effect - cutting off anything outside the layer.

This is because internally, we set the filter area to match the layer size, so if you put another filter on top it would cut out anything outside the layer below it.

The fix was to calculate the actual size of the filter using a function called gegl_node_get_bounding_box (). This returns the total size of the filter. What we didn't realize was that it does this by re-running the filter - and every other filter below it. So it requires the entire image to be redrawn each time it runs. As you can imagine, this can become very slow.

The fix I'm working on is to reduce how often that function is called - only when the filter is first created or resized. There will be a "global" filter size that all new filters will just pull from instead of recalcuating it each time.

Rod · **Joined:** May 16, 2010 **Posts:** 16167

CmykStudent wrote:

Rod: Hi! Not exactly.

We had this issue where if you had a filter that goes outside the layer (like drop shadow), putting another filter on top would crop the effect - cutting off anything outside the layer.

This is because internally, we set the filter area to match the layer size, so if you put another filter on top it would cut out anything outside the layer below it.

The fix was to calculate the actual size of the filter using a function called gegl_node_get_bounding_box (). This returns the total size of the filter. What we didn't realize was that it does this by re-running the filter - and every other filter below it. So it requires the entire image to be redrawn each time it runs. As you can imagine, this can become very slow.

The fix I'm working on is to reduce how often that function is called - only when the filter is first created or resized. There will be a "global" filter size that all new filters will just pull from instead of recalcuating it each time.

Thank you for the explanation of the exact problem. Thank you developers as well for taking your own time to develop Gimp for all of us. I commend you all for your efforts. It sounds like you all have this bug under control. :bigthup

contrast_ · **Joined:** Oct 31, 2020 **Posts:** 2013

CmykStudent wrote:

Rod: Hi! Not exactly.

We had this issue where if you had a filter that goes outside the layer (like drop shadow), putting another filter on top would crop the effect - cutting off anything outside the layer.

This is because internally, we set the filter area to match the layer size, so if you put another filter on top it would cut out anything outside the layer below it.

The fix was to calculate the actual size of the filter using a function called gegl_node_get_bounding_box (). This returns the total size of the filter. What we didn't realize was that it does this by re-running the filter - and every other filter below it. So it requires the entire image to be redrawn each time it runs. As you can imagine, this can become very slow.

The fix I'm working on is to reduce how often that function is called - only when the filter is first created or resized. There will be a "global" filter size that all new filters will just pull from instead of recalcuating it each time.

I think it reloads each node individually in filters like dropshadow and my plugins. That is why they are even slower.

Anyhow even if it is speed up performance wise we still have GIMP 3 blocking problems like the three visual bugs with clip-mitigation I reported and the one clipping bug I reported.

Rod · **Joined:** May 16, 2010 **Posts:** 16167

There is no download link for this commit.
https://gitlab.gnome.org/GNOME/gimp/-/jobs/4407951

quietreader · **Joined:** Apr 11, 2024 **Posts:** 307

There are compiler warnings, so maybe the packet wasn't built.