gimp 2.9.x

[dinasset]

Help request from users of Gimp versions 2.9.x.
Does Gimp 2.9 version(s) support filters processing an image by tiles?
I have some of my filters which make use of tile processing to speed up the pixel by pixel processing.
At a first test of the newly released 2.9.6 it seems that none of those run.
If someone who is using already 2.9.x releases can double-check I'll appreciate.
Thanks.

(BTW another small concern about this release: it says that "add_layer" is deprecated and suggests "insert_layer", but the first one is executed the second one no(???))

---

(08-25-2017, 01:47 PM)dinasset Wrote: Help request from users of Gimp versions 2.9.x.
Does Gimp 2.9 version(s) support filters processing an image by tiles?
I have some of my filters which make use of tile processing to speed up the pixel by pixel processing.
At a first test of the newly released 2.9.6 it seems that none of those run.
If someone who is using already 2.9.x releases can double-check I'll appreciate.
Thanks.

(BTW another small concern about this release: it says that "add_layer" is deprecated and suggests "insert_layer", but the first one is executed the second one no(???))

Edit:
it seems the filters start correctly and create output for the first 2 colums of tiles than stop.
Hence it must be some other problem of incompatibility (the loop?)
An example of those filters

  DIEGO_ANCILLARY_COLOURS_Deblueish.zip (Size: 2.8 KB / Downloads: 330)

[rich2005]

Quote:..If someone who is using already 2.9.x releases can double-check I'll appreciate.

Just got my 2.9.7 up and running from 'buntu ppa

With --pdb-compat-mode=on (or off) I get a strip 128 pix wide, (2 columns ?)
Running from a terminal, no error messages after opening an image.

One for you clever guys, Is the syntax (parameter order) for add_layer/insert_layer all screwed up in the Python Procedure Browser?

Just for the record, the plug-in does work as expected in linux Gimp 2.8.22

[dinasset]

Thanks for the double-checking, Rich.
Yes, 128 means 2 columns (in tile mode processing, the image is subdivided into 64x64 tiles).
I don't know why the filter stops after 2 columns processing.
In 2.8 (as you also confirmed) the filter works.

[Ofnuts]

Yes, there is a know problem with inset_layer in python (hard to use for top-level layers IIRC). There is a work around. See
https://bugzilla.gnome.org/show_bug.cgi?id=777092

[dinasset]

Ofnuts,
do you have a (testing) environment with gimp 2.9.x?
Or -thru your experience- could you guess what makes my filter running up to the end in gimp 2.8 and stop after two tiles columns in 2.9.x?
Thanks

[Ofnuts]

No 2.9.X environment.

Not too surprised that something as low-level as tiles is broken (or works differently) on 2.9.x (what is the bit depth of the image)?

First thing to do is add messages/print statements to see where the script breaks (does it crash, or it is just ending early?).

If there is a Python exception thrown, you can catch it and display it like this:

Code:

import traceback


try
   # Code with suspected Python exception goes here
except Exception as e:
   pdb.gimp_message(e.args[0])
   pdb.gimp_message(traceback.format_exc())
   print traceback.format_exc()

[dinasset]

the error shown on the bottom line of the window is:
"none type object has no attribute e.width"

on the console where gimp 2.9 is launched there is a series of msg:
"..GEGL warning: blocking when trying to lock tile"

BUT, as said before, this happens after 2 full columns of tiles are properly processed (the blue is reduced)
what's wrong in the source?

thanks

---

resulting layer
   

[Ofnuts]

The message you report says  "none type object has no attribute e.width" but if it is more accurately "'NoneType' object has no attribute 'ewidth'" then:

1. There is a place in the code where an ewidth attribute is used
   
2. Since NoneType is the type of the object None (and there is no other object of that type) then the variable associate with ewidth has value None
   
3. So all this points to srcTile (used in "for x in range(srcTile.ewidth):" that has become None
   
4. None is traditionally used in Python function as the value returned when the function cannot return what is asked
   
5. So that would be "layer.get_tile(False, j, i)" which isn't returning the requested tile for some reason.
   

What are the values of i and j when this happens? Can you reproduce the problem in the Python console with just a few lines (get image, get layer, get tile->kaboom)? If so you have all the required input to file a bug in http://bugzilla.gnome.org.

[dinasset]

Using the console (after a painful -for me- series of trials) I do get :
- no partial result as when calling the filter (new layer is created but left white)
- no error msg on ewidth
- a new msg on the launch console which says:
"(gimp-2.9.exe:7060): Gimp-Core-CRITICAL **: gimp_drawable_merge_shadow_buffer: assertion 'GEGL_IS_BUFFER (drawable->private->shadow)' failed
EEEEeEeek! 3 GeglBuffers leaked"
Not able to proceed further, I give up with 2.9