gimp 2.9.x - Printable Version +- Gimp-Forum.net (https://www.gimp-forum.net) +-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP) +--- Forum: General questions (https://www.gimp-forum.net/Forum-General-questions) +--- Thread: gimp 2.9.x (/Thread-gimp-2-9-x) |
gimp 2.9.x - dinasset - 08-25-2017 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. 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 [attachment=709] RE: gimp 2.9.x - rich2005 - 08-26-2017 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 RE: gimp 2.9.x - dinasset - 08-26-2017 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. RE: gimp 2.9.x - Ofnuts - 08-26-2017 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 RE: gimp 2.9.x - dinasset - 08-26-2017 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 RE: gimp 2.9.x - Ofnuts - 08-26-2017 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 RE: gimp 2.9.x - dinasset - 08-26-2017 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 [attachment=715] RE: gimp 2.9.x - Ofnuts - 08-26-2017 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:
RE: gimp 2.9.x - dinasset - 08-27-2017 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 |