Re: [Gegl-developer] Returning to python-gegl
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 -- 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] RFC: Including operation source code as op class metadata
Merged, since there were no objections. Can now get the source code of majority of components provided by GEGL (primary exception is the generated ones) using: const gchar *source = gegl_operation_get_key(opname, source); On 11 January 2015 at 17:55, Jon Nordby jono...@gmail.com wrote: In some development environments using GEGL, like imgflo+Flowhub it is useful to be able to see the source code of an operation in used. Both to understand how existing operations work and as a basis when writing new ops*. The following branch allows operations to include their source code as operation class metadata (using the source key) by using GEGL_OP_C_SOURCE instead of GEGL_OP_C_FILE in their op. The app can then query and display this like any other metadata. https://git.gnome.org/browse/gegl/log/?h=operation-source If there are no objections I'd like to merge this some time next week. - Jon * As mentioned to pippin at 31c3 I've found a way to basically implement live-code operations. Compile new/changed operation code as a .so file, using a unique suffix on the operation name, and then trigger gegl_load_module_directory() This will leak/keep the old operation class data, but this is small amounts of data for even long-ish development sessions compared to the images being processed. https://github.com/jonnor/imgflo-server/blob/master/components/example.c https://github.com/jonnor/imgflo/blob/master/lib/library.c#L357 -- Jon Nordby - www.jonnor.com -- 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] directory structure of opencl in gegl, and unit test framework for each plugin?
The majority of tests are in tests/compositions, both OpenCL and not. On Dec 25, 2014 6:06 AM, kcle...@users.sourceforge.net wrote: I had a go at tests/opencl, but found out that the opencl is NOT included in Makefile.am and Makefile.in under opencl/ so no tools are made to test the opencl plugins. How can I get the scripts compiled that can read the XML tests for the opencl plugins? On Thu, Dec 25, 2014 at 12:48 PM, kcle...@users.sourceforge.net wrote: I just had a good look at the gegl git repository, it looks to me that plugins and filters are implemented in the directory operations where plugins are subdivided into subdirectories such as core, transform, generated, common and workshop. Then I see some of these plugins have opencl versions in the directory opencl but implementations in opencl/ are not separated into corresponding subdirectories. I just wonder are there any plan to group opencl the same way as operations? Also is it true that unit test scripts of opencl are placed at: tests/opencl that compares output of opencl and CPU implemenations? If so, then the number of tests seems to be much fewer than number of opencl plugins. If I am correct, then would it be most productive for me to write XML test files for the plugins which has no corresponding test XML file? ___ 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
Re: [Gegl-developer] porting a GEGL filter to OpenCL
On 17 December 2014 at 01:33, Qichang Liang kcleung.sourcefo...@gmail.com wrote: Currently I am working on MacbookPro Retina installed with OS X 10.10. I have a VMware virtual machine on my USB 3 hard drive, which I can run using VMware Fusion 7.1 However for correctness and performance testing, which option is the best? * compile the gegl directly on OS X (which I can't get it compiled) * compile on a Linux VM that runs on VMware Fusion 7.1 * install Linux on my USB hard drive, boot my retina macbook from the Linux USB hard drive and compile from there? Test something that typical users use. That would be a plain OSX or Linux install. USB harddrive will make boot, application startup a bit slow but should not impact perfomance otherwise. And as long as your compare performance on the same system, comparisons will stay valid. GEGL should compile on Mac OSX. If it does not, it is probably not so hard to fix. And it needs to be fixed for applications using GEGL (like GIMP) anyways. Post your compile error along with what you did here if you are stuck with a problem. ___ 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] [Gimp-developer] babl roadmap
On 16 October 2014 21:37, Øyvind Kolås pip...@gimp.org wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/15/2014 01:46 PM, Simon Budig wrote: If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work. Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? Once we have the vocabulary to also describe this aspect of the pixelformats used by operations, the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries, then we will be able to continue refactoring, profiling and optimizing; without breaking existing functionality/rendering. Not only in terms of making more operations request directly userRGB, but also doing things like make some linear operations accept any of userRGB or bablRGB (or other linear RGB); and creating output buffers in the same format – to avoid unnecessary conversions in such cases. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl. The further along on the roadmap, more of the road will have to be laid/determined as we walk it. Hi pippin, you are answering in detail 'how we will get there' but Elle (as I see it) is asking more 'do you agree that we want to go there'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different there in mind, or if you think it is too early to decide this. There being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.' -- 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] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 11 October 2014 13:41, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/10/2014 07:49 PM, Øyvind Kolås wrote: This is not about how images with no embedded profile are handled. sRGB derived 8bit (and to a lesser degree 16bit) formats are used for many other things than images with no embedded profile. You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images. No-one said always. sRGB is however the most common for 8-bit images. These pixel formats are crucical for integrating with existing file formats and libraries; File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB. Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. -- 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] imgflo: Visually programming image processing pipelines with GEGL Flowhub
On 14 April 2014 08:17, Victor Oliveira victormath...@gmail.com wrote: It looks cool! Sorry for not having much time to give a look at the code now, but how does it run gegl in the browser? It's calling the gegl lib through node.js? Only the IDE runs in the browser. Flowhub has a standardized protocol for talking to runtimes[1], and imgflo implements that over WebSocket using libsoup. So GEGL runs on the server as normal, just with an additional API. There is some node.js code in the repo, for implementing an image processing server with an HTTP API that allows to specify input file(s), a named graph to run them through and creates the output image on-demand (or serves from disk). We might use the same infrastructure for interactive preview in Flowhub, not decided yet. 1. http://noflojs.org/documentation/protocol/ ___ 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] Qt bindings and gegl_node_set*
On 27 June 2013 09:15, Alberto Mardegan ma...@users.sourceforge.net wrote:
Hi all!
I don't know when (or even if) I'll start working on that, but I'm
considering extending the gegl Qt bindings to include almost everything
which is currently available to the C/glib bindings, so that a developer
writing an application using gegl in Qt wouldn't have to use the C/glib
API at all.
Hi Alberto,
which gegl Qt bindings are you referring to?
One thing I'm concerned about is the lack of a gegl_node_setv()-like
method, which would allow to set a list of properties on a node at once
(I'm aware of gegl_node_set(), but that's unsuitable for language
bindings).
So the question is: is calling gegl_node_set_property() multiple times
exactly equivalent to a single call to gegl_node_set() containing all
the properties, or are there performance issues?
I see that gegl_node_set_va() calls g_object_{freeze,thaw}_notify(),
what is that needed for?
There is gegl_node_set_valist()
Does setting a property have any immediate effect on the rendering, or
does that happen only when gegl_node_process() is called?
Could the order of setting properties have any effect on the rendering
results or performance?
Setting properties on a node in a graph invalidates the graph.
Computing/rendering the invalidated regions is done as a separate step, and
it is the application code which controls this. So whether multiple
invalidation are coalesced or not depends on that code.
--
Jon Nordby - www.jonnor.com
___
gegl-developer-list mailing list
gegl-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gegl-developer-list
