Re: [Gegl-developer] Returning to python-gegl
On 12 February 2015 at 20:50, Jon Nordby wrote: > > On 12 February 2015 at 06:30, Joao S. O. Bueno wrote: >> >> Hi - >> >> after several months I am taking back a look at my Python bindings for >> GEGL, >> which make use of gobject introspection. >> >> The situation with gobject introspection is none but frustrating - maybe >> one could use it, if he could live in #gobject on irc - but there seens to >> be >> no documentation resources wherever. >> >> Moreover, it does not work very well, >> whenever something is not available using the auto-generated bindings, >> there is no workaround, but to make/request changes on the upstream >> project >> and wait for a new release. > > That can be seen as a feature, it makes sure fixes go upstream, which makes > it work for every language supported by GI - not just with one particular > binding. No doubt about that - if it is being used. But for a moment looking at the state of lack of documentation, I thought it might have been given up. > >> >> Add to that things that simply stop working >> (I just found out I can no longer instantiate a geglBuffer with the >> gobject >> introspection - and the solution in my package is a hack already to >> workaround >> the constructor failing in the past) > > Due to bug in GI, or changes in GEGL? Probably changes in GEGL - I will try to take a look this weekend - I was already using a non-standard constructor as I said (maybe it was Sabo's wrapper you mentioned in the other message. If so, that is broken now) > >> >> Moreover, the latest GEGL stable release is still built with introspection >> off - >> so people can't make use of the Python bindings without rebuildoing >> GEGL themselves, >> as all distros ship the package without the "gir" files. > > If we have not changed the default go be --with-introspection, we should do > that now. But yes, it will only work for GEGL 0.3+ >> >> But -- I may be wrong --- people may be firmly committed to gobject >> introspection, >> and it may be the future, and it is my fault not learning it right - >> And this is the main motivation for this message: >> Doo anyone believe/think/can explain/ if gobject introspection has a >> future at all? > > > I think if we added testcases for consuming GEGL though Python/GI to > upstream GEGL we would catch (& hopefully fix) breakages early. If we > include the bindings library you have created in upstream GEGL to provide > more Pythonic syntax, we could also add testcases for that. We should then > ship it by default I think. > > I don't see the GNOME ecosystem switching away from GI anytime soon. And > despite the pains (docs, bugs, annotations upstream), I do think the model > is better than hand-writing bindings... There are tests in my module - possibly not many as there could be - I'd like to keep the its git separated due to the Python packaging ecosystem (and merging the histories would be a mess, I guess). Do you think it could work as a git submodule in GEGL? js -><- > > > > > -- > Jon Nordby - www.jonnor.com ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 13 February 2015 at 20:12, Jon Nordby wrote: > > On 13 February 2015 at 01:52, Joao S. O. Bueno >> >> >> I've been looking around, one problem seems to be that since BABL >> has no introspection, any functions relying on BABL parameters >> (even just babl formats, which are ordinary C strings with >> a fancy typedef) are not exported. > > > Daniel Sabo fixed this a good while back, by writing simple wrappers with > introspectable type signatures: > https://github.com/GNOME/gegl/blob/master/gegl/gegl-introspection-support.h > There are tests here that shows how it gets used > https://github.com/GNOME/gegl/tree/master/tests/python > > Adding introspection to Babl proved impossible without changing the API, due > to the strict conventions that GI requires. > https://bugzilla.gnome.org/show_bug.cgi?id=673422 > Thanks for the feedback on that. > -- > Jon Nordby - www.jonnor.com ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 12 February 2015 at 16:39, Michael Natterer wrote: > On Thu, 2015-02-12 at 14:30 -0200, Joao S. O. Bueno wrote: >> Hi - >> >> after several months I am taking back a look at my Python bindings for GEGL, >> which make use of gobject introspection. >> >> The situation with gobject introspection is none but frustrating - maybe >> one could use it, if he could live in #gobject on irc - but there seens to be >> no documentation resources wherever. >> >> Moreover, it does not work very well, >> whenever something is not available using the auto-generated bindings, >> there is no workaround, but to make/request changes on the upstream project >> and wait for a new release. >> >> Add to that things that simply stop working >> (I just found out I can no longer instantiate a geglBuffer with the gobject >> introspection - and the solution in my package is a hack already to >> workaround >> the constructor failing in the past) >> >> Moreover, the latest GEGL stable release is still built with introspection >> off - >> so people can't make use of the Python bindings without rebuildoing >> GEGL themselves, >> as all distros ship the package without the "gir" files. >> >> But -- I may be wrong --- people may be firmly committed to gobject >> introspection, >> and it may be the future, and it is my fault not learning it right - >> And this is the main motivation for this message: >> Doo anyone believe/think/can explain/ if gobject introspection has a >> future at all? > > Actually, yes, but I admit I have no clue whatsoever :) People seem > to be very committed to it. > > Without knowing much, proper doc annotations seem to be the key, > have you checked those? > > Also, I think the only way to get real help is #gtk+ Ok, if people are committed to it, that means it is not left to die, and it is a matter of fixing it in GEGL (and GIMP soon). I've been looking around, one problem seems to be that since BABL has no introspection, any functions relying on BABL parameters (even just babl formats, which are ordinary C strings with a fancy typedef) are not exported. js -><- > > --Mitch ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
So it looks like the right-thing-to-do now is to add introspection to Babl (otherwise we will need dirty workarounds in gegl). js -><- On 12 February 2015 at 21:01, wrote: > On 12 February 2015 at 16:30, Joao S. O. Bueno wrote: >> Otherwise, I think I will rewire the python bindings using another >> method to bridge to the C library, which is more predictive and better >> supported. > > I've made a Python binding for my largish C library using > gobject-introspection and not had any serious problems. It was a bit > wonky a year or so ago, but it honestly seems OK now. Performance is > good too, and I don't see any memory leaks. I'm very grateful for it. > > I've been trying to make a Ruby binding in the same way and oh dear oh > dear it's a lot harder :( > > John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Returning to python-gegl
Hi - after several months I am taking back a look at my Python bindings for GEGL, which make use of gobject introspection. The situation with gobject introspection is none but frustrating - maybe one could use it, if he could live in #gobject on irc - but there seens to be no documentation resources wherever. Moreover, it does not work very well, whenever something is not available using the auto-generated bindings, there is no workaround, but to make/request changes on the upstream project and wait for a new release. Add to that things that simply stop working (I just found out I can no longer instantiate a geglBuffer with the gobject introspection - and the solution in my package is a hack already to workaround the constructor failing in the past) Moreover, the latest GEGL stable release is still built with introspection off - so people can't make use of the Python bindings without rebuildoing GEGL themselves, as all distros ship the package without the "gir" files. But -- I may be wrong --- people may be firmly committed to gobject introspection, and it may be the future, and it is my fault not learning it right - And this is the main motivation for this message: Doo anyone believe/think/can explain/ if gobject introspection has a future at all? Otherwise, I think I will rewire the python bindings using another method to bridge to the C library, which is more predictive and better supported. (I also accept suggestions for that - since I prefer working in Python itself, my options would be ctypes or cython) js -><- ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Support for loading meta-operations from .json now in master
Yay! :-) On 20 January 2015 at 15:08, Jon Nordby wrote: > Hi, > > a long standing enhancement[1] in GEGL has been to allow loading > meta-operations from a serializable file instead of requiring them to be > coded in C. > At 31c3 I started working on this, and yesterday it reached a generally > working state. Today I merged the code to master[2]. > > Each .json file of right format that is found in the module path for GEGL > will create a new GeglOperationMeta subclass. It will be register it with > the specified operation name, and exported properties/pads. > When the operation is instantiated, it builds up the subgraph of GeglNodes > specified and connects. Property changes on the meta-operation are forwarded > onto the real node inside. > > An example of the .json format can be seen here: > https://git.gnome.org/browse/gegl/tree/operations/json/grey2.json > This is a format also used by other dataflow/flow-based-programming > tools[3]. > > This for instance allows one to use the node-based editor Flowhub+imgflo to > build a new image filter, save it as .json and then use it in GIMP[4] > (screenshot). One can of course also hand-write the json files, or implement > other editors for these. > It might make sense to also implement serialization of a graph/sub-graph to > this format directly in GEGL itself. > > Note: This adds json-glib 1.0 as a dependency of GEGL, so make sure you have > it installed (including development headers). > > References > 1. https://bugzilla.gnome.org/show_bug.cgi?id=465743 > 2. > https://git.gnome.org/browse/gegl/commit/?id=564f45bad76eb0f888e628ea70345912dd68cbbb > 3. http://noflojs.org/documentation/json > 4. https://twitter.com/jononor/status/557570481206099969 > > -- > Jon Nordby - www.jonnor.com > > ___ > gegl-developer-list mailing list > List address:gegl-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list > > ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Python-GEGL v0.2 released
Hello - During this year's LGM, I sprinted on these high-level wrappers for using GEGL through gobject-introspectinf from Python. One can use GEGL from Python without these wrappers - I think Manuel Quinõnes. is doing so in his demonstrations - the wrappers are an effort for having a truly easy-to-use from Python GEGL. I've just made the "0.2.1" release to Pypi, making the niceties I coded in Leipzig available to everyone with a recent GEGL build and who will type "pip install python-gegl" - For those intending to follow the development, the repository is currently at https://github.com/jsbueno/python-gegl During the LGM Pippin, Jon and me agreeded that this project could evolve to become the "de-facto" bindings for Python, replacing the long dead-by-bit-rot "pygegl" in the GEGL source tree. ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Gegl Operation : Retinex
Hi - just ressurrecting the thread to get the ball rolling again. It looks like this still remains to be rewritten for GEGL? (what lead me to do this? I've hit the "retinex" filter description while translating the GIMP manual, and went happily to gimp master to check how retinex would behave in a 32 bit per channel image - just to find it was not there) On 29 July 2010 11:08, Geert Jordaens wrote: > > > hello, > > I'm trying to port the retinex operation of gimp to a Gegl operation and > facing following problems. > > First approach : > > 1. a GeglOperationMeta since the Retinex algorithm depending on the > parameters needs multiple blurred images (gegl:gaussian-blur). > > 2. The difference between the original image and each of the blurred images > have to be summed an result in an intermediate image. > This seems not possible without implementing an operation with a specific > calculation : > > intermediate[n] += weight * (log (input[n] + 1.) - log (blur[n])) > > 3. The next step would be another specialised op that performs : > > logl = log(intermediate[0] + intermediate[1] + intermediate[2] + 3.) > dest[n+i] = (gain * ((log(alpha * (input[n]+1.)) - logl) * > intermediate[n]) + offset); > > 4. Finally the values have to be corrected with the variance and mean > calculated on the whole image. > > > Second approach : > GeglOperationAreaFilter implemented steps 1..3 of first apporach within the > process method. > The same problem for step 4. > > > Any suggestions on : > > How to go with step 4 since the operations process method can only calculate > a mean and variance for its ROI? > > Additional observation for Retinex and Gaussian Blur if the value of > scale/stdev is equal or bigger then the default size of the gegl ROI then > way the splitting in smaller chunks becomes a bottleneck. If the extra area > needed around the ROI is important in respect to the ROI what kind of > operation should be used? > > > > ___ > Gegl-developer mailing list > gegl-develo...@lists.xcf.berkeley.edu > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer > ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Making GEGL and Babl releases "soon"
Daniel - there is that bug in gobject about GParamSpecs segfaulting I
mentioned in the gimp-devel thread - I don know if it is listed in
bugzilla - but if you are talking about a release "right now", I think
it'd be worth taking a look at.
Steps to reproduce:
$ python
Python 2.7.3 (default, Jul 24 2012, 11:41:40)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
>>> from gi.repository import Gegl
>>> Gegl.init([])[]
>>> params = Gegl.operation_list_properties("gegl:png-load")
(python:21947): GEGL-gegl-operations.c-WARNING **: Adding
GeglChantinvert-linear_c shadows GeglChantinvert_c for operation
gegl:invert
/usr/lib64/python2.7/site-packages/gi/types.py:43: Warning:
g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed
return info.invoke(*args, **kwargs)
/usr/lib64/python2.7/site-packages/gi/types.py:43: Warning:
g_object_ref_sink: assertion 'G_IS_OBJECT (object)' failed
return info.invoke(*args, **kwargs)
** (python:21947): CRITICAL **: pygobject_register_wrapper: assertion
'PyObject_TypeCheck(self, &PyGObject_Type)' failed
>>> dir(params[0])
Segmentation fault (core dumped)
$
js
-><-
On 29 November 2013 11:21, Daniel Sabo wrote:
> Gimp 2.8 still has "GEGL Operation" under the Tools menu, which
> apparently some people are using because we get bug reports about it
> crashing. I don't see the time it would take to backport those fixes
> to the 0.2 branch as worthwhile; there aren't any significant changes
> required for Gimp to use 0.3 but the fixes in GEGL are intertwined
> with other changes that make backporting impractical.
> ___
> gegl-developer-list mailing list
> List address:gegl-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
>
___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Python wrappers for easier GEGL access -
Hi there - as you may know, i tis possible to use GEGL from Python and other languages by using gobject introspection - But the automated bindings generated make it too verbose, and make poor use of the introspection built-in GEGL itself - So I've created these lightweight wrappers over the automatic bindings, with the main objective of exposing GEGL's introspection facilities transparently in Python: https://pypi.python.org/pypi/python-gegl/0.1 https://github.com/jsbueno/python-gegl/releases/tag/v0.1 The little code that is in there now should be enough to get started in popularizing GEGL as a general purpose Imaging Library for people doing Python - if only we can make pygobject installation itself easier. :-/ js -><- ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Removal of bindings from GEGL repository
On 19 November 2012 15:43, Jon Nordby wrote: > At the moment the gegl repository contains the following binding projects in > bindings/: > pygegl, vala, rgegl, gegl-sharp > > None of these have had stable releases, have been updated to build/work with > GEGL 0.2 (released 6 months ago) or, as far as I know, have any applications > actively using them. For these reasons I propose that we remove these > bindings from the repository and focus on GObject Introspection based > bindings. And at least for Python, the fact it is in this tree, and not on the gnome tree, and does nto get built by default means there is almost _no one_ using Python + GEGL . (Still, Python is widely used in areas GEGL would excel, with less capable, generally 8 bpp only, libraries) In short, I am +1 for separation/removal. js -><- > Python and Vala both have very solid GI based tool-chains, and the > ruby-gir-ffi project also look to be healthy. For C#/Mono things do not look > so good however. So if anyone wants to further maintain gegl-sharp, I > suggest that is done in a separate repository, in a similar way to geglmm. > > To test the GI based bindings, pass --enable-introspect to configure when > building GEGL master. This option will hopefully soon become default, so > that we always build bindings and avoid bitrot. Some trivial automated tests > for the bindings exists under tests/python. Any additions to these would be > very welcomed. > > Note that due to limitations in gobject introspection Babl can currently not > be bound[1], and therefore some parts of the GEGL buffer API is unavailable. > > 1. https://bugzilla.gnome.org/show_bug.cgi?id=673422 > > -- > Jon Nordby - www.jonnor.com > > > ___ > gegl-developer-list mailing list > gegl-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gegl-developer-list > ___ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [gsoc] which GIMP filters are going to be ported?
On 6 June 2012 15:05, gfxuser wrote: > maybe the convolution matrix, too FYI, the convolution matrix is one of the most important filters for one of the aspects of GIMP product vision, namely: "GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;" The convolution Matrix is a generic tool for image processing, and is needed as a toolbox for implementing and experimenting with image filters. js -><- ___ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
