Re: [Gegl-developer] GEGL + QT, another proposal
On Thu, Jul 21, 2011 at 5:24 PM, Jon Nordby jono...@gmail.com wrote: After some hacking this weekend, we now have a minimally useful gegl-qt library: https://github.com/jonnor/gegl-qt Currently it a set of a basic view widgets* showing the output of a GeglNode. A bit more info can be found in the README.txt file, and examples showing the usage can be found in the examples/ directory. Testing, usage and contributions welcomed! Unless there are any objections I propose to do the same as with gegl-gtk: Put on git.gnome.org, create a gegl-qt component in bugzilla and add to Jenkins. Even though it uses Qt.. I think the gnome git repository is the most natural place to stick this convenience library since it is based on GEGL and all the other GEGL pieces, including a gegl-clutter library which I added there today are hosted. So unless there are any other objections I do not see why not. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] save 32 bit float as exr file
On Mon, Jul 18, 2011 at 6:13 PM, Rasmus Hahn rassa...@googlemail.com wrote: i have written an operation for gegl that writes OpenEXR float images, since i noticed there does not seem to be one already and i could use it. This version is quite usable within it's limitations. Limitations currently are: Thank you :) I am not sure if the current way the format of the buffer is determined is the most robust, but it probably works well enough. I added the op to master and made the coding style more consistent with the rest of GEGL/GIMP. I would like to see it included in the distribution; for now i have attached a patch, which creates a new file gegl/operations/external/exr-save.cc and makes a modification to the Makefile.am to build it. The patch is against version gegl-0.1.6, but works with the git-version (as of 2011-07-13), too. Sorry, for not providing a URL, but i do not have one right now. --- Author: Øyvind Kolås pip...@gimp.org Date: Mon Jul 18 21:08:56 2011 +0100 AUTHORS: add Rasmus Hahn commit 5470164d7a8677d9ea1ea67282650476b4d17aa4 Author: Øyvind Kolås pip...@gimp.org Date: Mon Jul 18 21:08:30 2011 +0100 exr-save: normalize coding style commit d9512a262c845bb59f47ba103c1b7a32790ccf37 Author: Øyvind Kolås pip...@gimp.org Date: Mon Jul 18 20:56:50 2011 +0100 exr-save: add new op from Rasmus Hahn snip It would have been slightly nicer if you used git format-patch and included a commit message for the patch yourself. Thank you :) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] save 32 bit float as exr file
On Mon, Jul 18, 2011 at 6:45 PM, Piotr Stanczyk piotr.stanc...@gmail.com wrote: Thanks for adding ... Any thoughts on adding 16-bit floating point support? You could then consider using the RGBA interface ... The op already supported Y, YA, RGB and RGBA - but all only with 32 bit floating point support. If support for half floats were to be added this would have to be added to babl, either as an extension or to the base of babl (the latter probably makes most sense). Looking at the additional data types added for CIE Lab could act as inspiration. I do however think having support for half-float exr is less important than 32bit float so this is a great start in itself :) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL and GTK+, a proposal
On Mon, Jun 13, 2011 at 11:17 AM, Martin Nordholts ense...@gmail.com wrote: 2011/6/12 Jon Nordby jono...@gmail.com: So I propose to: - Create a new gegl-gtk repository, containing the new library (alternative is to have it as a toplevel in gegl repo, if anyone can present good arguments for that I don't mind) First of all, I think the name should be gegl-ui, not gegl-gtk, in case we want to provide a widget for say Qt. I support moving the UI stuff into a separate git repository; it will be nice to have separate commit histories. Having a library that depends on a lot of different UI frameworks might not be conductive to encourage adoption. Since this would mean that in distributions you would be pulling in the packages for all the possible dependencies when wanting only one of them. There is already a Clutter based GEGL integration library, and to me it makes sense for there to be separate ones for different ui toolkits. http://git.clutter-project.org/clutter-gegl/ /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL and GTK+, a proposal
On Mon, Jun 13, 2011 at 6:38 PM, Jon Nordby jono...@gmail.com wrote: I had the same thought, and eventually ended with the same conclusion: different repos. I actually started some Qt stuff but realized I get enough of that in my day-job. So GTK first, then we'll see. Øyvind: please give your explicit OK to the relisencing. I am fine with the GeglView code being relicensed to LGPLv3+ :) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] [Gimp-developer] Recent Gegl-0.1.7 build fails
Platform/Distribution HP Pavilion dv8t Intel Core i7/ Windows 7, 64bit $ gcc -v Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../gcc44-svn/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-multilib --enable-checking=r elease --prefix=/mingw64 --with-sysroot=/mingw64 --enable-languages=c,c++,fortran,objc,obj-c++ --enable-libgomp --with-gmp=/mingw64 --with-mpfr=/mingw64 --disable-nls --disable-win32-registry Thread model: win32 gcc version 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] (GCC) Note that this error did not happen a couple of weeks ago. The error might be fixed in git master now, you can either do a git checkout; or wait for new nightly tarballs to appear. I hope this fixes it. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Compiling GEGL in Windows
On Fri, May 20, 2011 at 7:05 AM, Sayak sayak...@yahoo.com wrote: Hi All, I am new in GEGL development. For some times, i was using OpenCV library in Visual Studio 2010 to create an image manipulation application in Android. C - JNI - Android. because of the limitation of the OpenCV library, i am interested to use the GEGL library for a wider scope. Unfortunately, i didnt get any proper guide about how to compile GEGL in visual studio. I would like to know the steps that i need to do. Personally, and as far as I know; most people on this mailinglist, do not use visual studio and do not know how to integrate the libraries with them, even though this should be possible as all of the code should be cross platform and standards compliant. Please report back if you figure out an easy way to do this. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Compiling GEGL in Windows
On Mon, May 23, 2011 at 2:29 PM, Jasper van de Gronde th.v.d.gro...@hccnet.nl wrote: What about just plain MSYS/MingW? Has anyone ever managed to successfully compile GEGL on Windows? I tried it quite a while back, without much success. In the end I did manage to compile it, but then it didn't work in some weird way. GIMP does work on windows using GEGL, as far as I've understood compiled both from windows and cross compiled from Linux. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl: format comparison
On Sun, May 22, 2011 at 10:26 AM, Daniel Hiepler
ri...@boogiepalace.hopto.org wrote:
Vom: Sat, 21 May 2011 22:37:41 +
if(babl_format_get_type(format) == babl_type(u8))
{
/* u8 type */
}
else
{
/* no u8 type */
}
Yes, all Babl objects are effectively singletons - and the same
internal object will be returned for all subsequent calls that refer
to one.
BablFishes never change their source nor destination formats, and at
the moment the source and destination formats of fishes are not
exposed bu the publicly installed headers for babl.
Then it looks like I have to remember the formats of all created fish
myself :(
This depends on what you are trying to do, if all you are trying to do
is to avoid creating multiple fishes referring to the same two formats
than babl already does this for you internally. Just like pixel
formats and types, you should be getting the same fish, with
significantly less computation needed. On subsequent requests.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl: format comparison
On Sat, May 21, 2011 at 12:03 PM, Daniel Hiepler
ri...@boogiepalace.hopto.org wrote:
Hi,
what would be the best-practice to check if two BablFormats are the
same? I would need something like:
Babl *format1 = babl_format(R'G'B' u8);
Babl *format2 = babl_format(CIE Lab float);
if(is_same_format(format1, format2))
if (format1 == format2)
{ ... } else { ... }
But do note that internally babl will provide you with a memcpy
instead of a conversion if the passed in formats are the same; thus
this should only be neccesary if direct access with no copies
whatsoever is an option where used.
{ ... } else { ... }
Also I would need to get the current source- and destination-format of
a fish.
Is that possible?
BablFishes never change their source nor destination formats, and at
the moment the source and destination formats of fishes are not
exposed bu the publicly installed headers for babl.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] Fwd: [Gimp-developer] gegl-vips
-- Forwarded message -- From: jcup...@gmail.com Date: Sun, Apr 17, 2011 at 10:22 AM Subject: [Gimp-developer] gegl-vips To: gimp-developer gimp-develo...@lists.xcf.berkeley.edu Hi all, I've had a stab at a quick hack of gegl-0.1.6 to use libvips (another demand-driven image processing library) as the backend for batch processing. I think it is maybe an interesting way to look at gegl performance, for this use case at least. https://github.com/jcupitt/gegl-vips This has some very strong limitations. First, it will not work efficiently with interactive destructive operations, like paint a line. This would need area cache invalidation in vips, which is a way off. Secondly, I've only implemented a few operations (load / crop / affine / unsharp / save / process), so all you can do is some very basic batch processing. It should work for dynamic graphs (change the parameters on a node and just downstream nodes will recalculate) but it'd need a display node to be able to test that. There's a README with some more detail on how it works, a test program and some timings. If I run the test program linked against gegl-0.1.6 on a 5,000 x 5,000 pixel RGB PNG image on my laptop (a c2d at 2.4GHz), I get 96s real, 44s user. I tried experimenting with various settings for GEGL_SWAP and friends, but I couldn't get it to go faster than that, I probably missed something. Perhaps gegl's disk cache plus my slow laptop harddrive are slowing it down. Linked against gegl-vips with the operations set to exactly match gegl's processing, the same thing runs in 27s real, 38s user. So it looks like some tuning of the disc cache, or maybe even turning it off for batch processing, where you seldom need pixels more than once, could give gegl a very useful speedup here. libvips has a threading system which is on by default and does double-buffered write-behind, which also help. If you use uncompressed tiff, you can save a further 15s off the runtime. libpng compression is slow, and even with compression off, file write is sluggish. The alpha channel is not needed in this case, dropping it saves about 5s real time. babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s. The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s. Finally, we don't really need 16-bit output here, 8 is fine. This saves only 0.5s for tiff, but 8s for PNG. Putting all these together, you get the same program running in 2.3s real, 4s user. This is still using linear float light internally. If you switch to a full 8-bit path you get 1s real, 1.5s user. I realise gegl is committed to float, but it's interesting to put a number on the cost. Does this sound useful? I think it's maybe a way to weight the benefits of the various possible optimisations. I might try running the tests on a machine with a faster hard disk. John ___ Gimp-developer mailing list gimp-develo...@lists.xcf.berkeley.edu https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] Fwd: [Gimp-developer] gegl-vips
I didn't see that the discussion was on gimp-devel, forwarding my reply as well, in case someone are following GEGL developer/digging in its archives. -- Forwarded message -- From: Øyvind Kolås pip...@gimp.org Date: Sun, Apr 17, 2011 at 2:24 PM Subject: Re: [Gimp-developer] gegl-vips To: jcup...@gmail.com Cc: gimp-developer gimp-develo...@lists.xcf.berkeley.edu Thank you for taking a serious look at GEGL, I've trimmed away the bits relating to the VIPS backend and rather focus on the performance numbers you get out and will try to explain them. On Sun, Apr 17, 2011 at 10:22 AM, jcup...@gmail.com wrote: Linked against gegl-vips with the operations set to exactly match gegl's processing, the same thing runs in 27s real, 38s user. So it looks like some tuning of the disc cache, or maybe even turning it off for batch processing, where you seldom need pixels more than once, could give gegl a very useful speedup here. libvips has a threading system which is on by default and does double-buffered write-behind, which also help. On my c2d 1.86ghz laptop I get 105s real 41s user with default settings. Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping of tiles makes it run in 43s real 41s user. With the default settings GEGL will start swapping when using more than 128mb of memory for buffers, this limit can be increased by setting for instance GEGL_CACHE_SIZE=1024 to not start swapping until 1gb of memory is in use. This leads to similar behavior, the tile backend of GEGL is using reads and writes on the tiles, using mmaping instead could increase the performance. If you use uncompressed tiff, you can save a further 15s off the runtime. libpng compression is slow, and even with compression off, file write is sluggish. Loading a png into a tiled buffer as used by GeglBuffer is kind of bound to be slow, at the moment GEGL doesnt have a native TIFF loader, if the resources were spent on writing a proper TIFF backend to GeglBuffer GEGL would be able to lazily swap in the image data from TIFF files as needed. babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s. If the original PNG was 8bit, babl should have a valid fast path for using lookup tables converting it to 32bit linear. For most other conversions involved in this process babl would likely fall back to reference conversions that go via 64bit floating point; and processes each pixel with lots of logic perutating components etc. By adding/fixing the fast paths in babl to match the reference conversion a lot of the time spent converting pixels in this test should vanish. The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s. For smaller radiuses this is fine, for larger ones it is not, ideally GEGL would be doing what is optimal behind the users back. Finally, we don't really need 16-bit output here, 8 is fine. This saves only 0.5s for tiff, but 8s for PNG. Making the test case you used save to 8bit PNG instead gives me 34s real and 33s user. I am not entirely sure if babl has a 32bit float - 8bit nonlinear RGBA conversion, it might just be libpngs data throughput that makes this difference. save = gegl_node_new_child (gegl, operation, gegl:png-save, bitdepth, 8, path, argv[2], NULL); Putting all these together, you get the same program running in 2.3s real, 4s user. This is still using linear float light internally. If you switch to a full 8-bit path you get 1s real, 1.5s user. I realise gegl is committed to float, but it's interesting to put a number on the cost. This type of benchmark really stress tests the file loading/saving parts of code where I am fully aware that GEGL is far from optimal, but it is also something that doesn't in any way reflect GIMPs _current_ use of GEGL which involves converting 8bit data to and from float with some very specific formats and then only doing raw processing. This will of course change in the future. Does this sound useful? I think it's maybe a way to weight the benefits of the various possible optimisations. I might try running the tests on a machine with a faster hard disk. It is useful, but it would perhaps be even more useful to see similar results for a test where the loading/saving is taken out of the benchmark and measure raw image data crunching. Setting GEGL_SWAP=RAM, BABL_TOLERANCE=0.02 in the environment to make babl be lenient with the error introduced by its fast paths I run the test in, it should be possible to fix the fast paths in babl to be correct enough to pass the current stricter criteria for use; and thus get these results without lowering standards. Even adding slightly faster but guaranteed to be correct 8bit
Re: [Gegl-developer] [Gimp-developer] gegl-vips
On Sun, Apr 17, 2011 at 9:40 PM, jcup...@gmail.com wrote: On 17 April 2011 14:24, Øyvind Kolås pip...@gimp.org wrote: On my c2d 1.86ghz laptop I get 105s real 41s user with default settings. Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping of tiles makes it run in 43s real 41s user. I found GEGL_SWAP=RAM, but on my laptop the process wandered off into swap death before finishing. Is there some way to limit mem use? I only have 2gb. My laptop has 3gb of RAM and thus doesn't end up crunching swap on such a test. Setting GEGL_CACHE_SIZE=1300 or so, should have a similar effect, hopefully GEGL wouldn't need to make everying swap. (not that in doing so you should _not_ set GEGL_SWAP=RAM). I noticed that setting GEGL_THREADS=anything_more_than_1 causes things to crash, along with other things that more subtly break.. are the reason GEGL doesnt default to keep all cores busy yet. Loading a png into a tiled buffer as used by GeglBuffer is kind of bound to be slow, at the moment GEGL doesnt have a native TIFF loader, You can work with tiled tiff straight from the file, but for sadly for striped tiff (as 90%+ are, groan) you have to unpack the whole file first :-( I'm not sure what a striped tiff is, if it stores each scanline separately GeglBuffer could be able to load data directly from it by using 1px high tiles that are as wide as the image. babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s. If the original PNG was 8bit, babl should have a valid fast path for using lookup tables converting it to 32bit linear. For most other OK, interesting, I shall look at the callgrind output again. I'd recommend setting the BABL_TOLERANCE=0.004 environment variable as well, to permit some fast paths with errors around or below 1.0/256 avoiding the rather computationally intensive synthetic reference conversion code in babl. The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s. For smaller radiuses this is fine, for larger ones it is not, ideally GEGL would be doing what is optimal behind the users back. Actually, it works for large radius as well. By separable convolution I mean doing a 1xn pass then a nx1 pass. You can bake the sub/mul/add into the coefficients you calculate in gblur. I thought you meant hard-coded convultions similar to the crop-and-sharpen example, baking it into the convolution might be beneficial, though at the moment I see it as more important to make sure gaussian blur is as fast as possible since it is a primitive that both this, and dropshadow and other commonly employed compositing things are built from. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 7:47 PM, Bogdan Szczurek thebod...@gmail.com wrote: Yes, but why use RGB at all if one can use e.g. XYZ from the start? So wide RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with. It is a matter of which well defined color space the operations desired provide sensible outputs. For some types of operations doing them in premultiplied linear light RGB is superior to doing them in sRGB, CIE Lab or other more or less perceptual spaces, for other operations the opposite is true. My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color - whis is why the operations of GEGL request temporary working buffers in their preferred working space (this is where babl does the; optimized; conversions you correctly state have to happen) rather than blindly handling incoming numbers. The RGB space defined by and used by babl uses the same primaries as sRGB, and has well defined conversions to CIE Lab, Xyz and others. The preferred^Wenforced working space of some operations in GEGL might need some scrutinization and review, though for compositing; gaussian blurs; interpolation etc I think the current choice of linear light RGB. GEGL also does not support working in an internal 8bit or 16bit mode, it is floating point with high precision and additional headroom/footroom (wide gamut/HDR) for all temporary buffers, if the desired output is 8bit it happens when displayed or exported. Operations like for instance unsharp-mask does not work correctly if termporary results are clipped. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] gegl_init(),gegl_exit() and modules
On Tue, Feb 15, 2011 at 5:29 AM, Jan Kovanda kovandajan11...@gmail.com wrote: At first I thought that using gegl_exit() should delete (unref and free) module_db. A bit of testing revealed some unpleasant surprises. Even after gegl_exit() I am still able to access GeglNodes a gegl methods as if no exit was called. Then what is method gegl_exit() good for? GEGL is not designed to be torn down and reinitialized, gegl_exit will cause unreferencing some of the runtime data as well as report any problems detected by sanity checks. Patches making it possible to reload the GEGL ops would be welcome, do however note that the GType system underlying GObject is likely to provide some unexpected hurdles. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL 0.1.6
GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides a graph based API and framework to do demand driven, cached, non destructive image editing of larger than RAM images. Through babl it provides support for a wide range of color models and pixel storage formats for input and output. To build gegl-0.1.6 you will also need babl-0.1.4 Changes in this release: • Fixed a bugs in matting-levin that made GEGL halt due to errors detected by babl sanity code, this made 0.1.4 be unusable if you had all dependendency when building. • build/test improvements. • New operations: max-rgb, pixelise, motion blur • Added extension points for GeglBuffer to use external tile backends, allowing to plug-in alien tilebackends, for legacy GIMP tilemanager/Krita/OSM and similar. This release of GEGL was made possible by contributions from: Tobias Ellinghaus, Øyvind Kolås, Barak Itkin and Martin Nordholts Where to get GEGL: The latest versions of GEGL and it's hard dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.1/babl-0.1.4.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.1/gegl-0.1.6.tar.bz2 ftp://ftp.gtk.org/pub/glib/2.20/glib-2.20.5.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 1abe98b11e67737b6f74d6993d45046eec93bcda babl-0.1.4.tar.bz2 27bedcfd077da7a6913b82966dbec904b22c121d gegl-0.1.6.tar.bz2 19e2b2684d7bc35a73ff94eb7fd15fc70cc6f292 glib-2.20.5.tar.bz2 Where to get more information about GEGL More information about GEGL can be found at the GEGL website, or by joining #gegl or #gimp on the irc network GIMPnet. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] internal structure of GEGL
On Tue, Jan 25, 2011 at 3:30 PM, Jan Rabusic jrabu...@gmail.com wrote: For example my problem: I would like to extend color operations. I would like to rewrite every operation which depends on color model of input (invert, brightness-contrast, etc.) to have in arguments an color model format, and according to this variable would be perform the appropriate version of the operation. Example: I have sRGB 8bit integer data and I would like to call invert, so ...(gegl, operation, gegl:invert, c_m_format, sRGB 8bit, NULL) would call invert for 8bit and three channels... The working space of most of GEGLs processing ops are by design 32bit linear light RGB, this allows both headroom and footroom allowing for intermediate results that go beyond the 0.0-1.0 / 0-255 range, which is neccesary for some operations like unsharp mask and provides more predictable results than having separate implementations for a wider range of pixel formats, babl is used as a universal translator to implicitly convert between various pixelformats/colorspaces. See http://gegl.org/babl/ for more details about babl. For some of the color operations currently used in GIMP doing the processing in 32bit float with conversions back and forth from 8bit is already as fast as GIMPs old code operating only in 8bit, adding code to deal with gamut limited formats seems like something that would bring mostly problems and not many obvious benefits. - Second question about this is: can be get_gegl_buffer_format usefull for this? can I call it in operation invert on its input? if yes, what points the pointer Babl*, which is returned? an array of chars? Do you mean gegl_buffer_get_format ? This does return a reference to an opaque data structure that can be queried for information with the babl API, see that babl documentation/headers for further insight into what can be done with it. Adding paralell implementations that specially deal with other color models, or code paths that deals generically with multi component color models is something I would primarily see as beneficial for CMYK - and at least initially that is something that I would not consider necessary during processing of photos/drawings, but something to be done after GEGL/GIMP has dealt with the image when the final printing color space is known and well defined. Most users desiring a CMYK mode should be satisfied by working in properly color managed RGB with CMYK soft-proofing, and perhaps attaching an ICC profile later, perhaps separating to CMYK at export if the software/hardware used further down a printing pipeline does not support PDF/X. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL 0.1.4 and babl 0.1.4
GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides a graph based API and framework to do demand driven, cached, non destructive image editing of larger than RAM images. Through babl it provides support for a wide range of color models and pixel storage formats for input and output. To build gegl-0.1.4 you will also need babl-0.1.4 Changes in this release: • Operations: save (chooses delegate save op automatically) rgbe load/save jpeg200 load/save ppm load/save map-absolute (GIMP cage tool gsoc helper op) whirl and pinch mirrors grid render fixed imagemagick fallback load op fixed pipe based dcraw wrapper GSoC 2010 ops: exp-combine, reinhard05, fattal02, mantiuk06, matting-levin • Various source and build improvements. • improvements towards threaded rendering • Buffer: refactored away some constant overhead made GeglBufferIterator API public This release of GEGL was made possible by contributions from: Michael Natterer, Øyvind Kolås, Vincent Untz, Kaja Liiv, Nils Philippsen, Étienne Bersac, Martin Nordholts, Debarshi Ray, Danny Robson, Stuart Axon, Kao, Mukund Sivaraman, Ruben Vermeersch, Barak Itkin, Michael Muré, Mikael Magnusson, Patrick Horgan and Andy Gill. Where to get GEGL: The latest versions of GEGL and it's hard dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.1/babl-0.1.4.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.1/gegl-0.1.4.tar.bz2 ftp://ftp.gtk.org/pub/glib/2.20/glib-2.20.5.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 1abe98b11e67737b6f74d6993d45046eec93bcda babl-0.1.4.tar.bz2 dcb437205850e598a48e314add68b13cd26f542c gegl-0.1.4.tar.bz2 19e2b2684d7bc35a73ff94eb7fd15fc70cc6f292 glib-2.20.5.tar.bz2 Where to get more information about GEGL More information about GEGL can be found at the GEGL website, or by joining #gegl or #gimp on the irc network GIMPnet. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] various blurs
On Wed, Jan 19, 2011 at 10:29 AM, andy gill andygg...@gmail.com wrote: Could you explain how the tests work, it's not obvious to me what I need to add. Do the tests make sure that the results match a reference image in some way? XML files in gegl/tests/compositions are rendered and their output is tested against the PNG files by the same names in gegl/tests/compositions/reference, visual files indicating where the outputs differ are also produced if the tests are wrong. It would probably be good to have a section on the website explaining how these regression tests work. There are also bots the build the GEGL code base nightly and will complain to us on IRC if the build breaks or the tests fail passing. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL run -- heavy resources consumption
On Tue, Oct 19, 2010 at 10:12 PM, Jan Kovanda kovandajan11...@gmail.com wrote: A testing picture is 8.5 MB RGB jpeg image 6000px x 6000px. uncompressed this is 103 MB as 8bit RGB data, 549 MB as 32bit float RGBA data which is what GEGL prefers to work with internally. Why GEGL needs so much resources for such simple program? I am not so familiar with inner workings of buffers and caching, but I would expect smaller use of the resources. At least the load and save ops themselves need a buffer the full size of the image to be able to do all the png processing in one go, there is potentially also caches for some of the other operations in a graph. Why those swap files are created? In the program I didn't set any properties for swapping to disk. GEGL defaults to swapping to disk, see the various environment variables in http://gegl.org/#_environment for how to tweak this, these settings are also available in the singleton object returned with gegl_config() You would probably want to increase the tile cache size which defaults to 256mb by setting GEGL_CACHE_SIZE Disable swapping to disk by setting GEGL_SWAP=RAM in the environment, this will cause GEGL to swap unused tiles to RAM instead. /Øyvind K. -- ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl: Floating point suffix
On Sun, Oct 3, 2010 at 12:44 AM, Rupert Weber g...@leguanease.org wrote: Many floating point constants in babl are suffixed with an 'F', even though they are used (i.e. converted soon thereafter) as doubles. (And again recently on GIMP with the Megapixel-patch). While my reflex would be to just change that whenever I come across it, I first wanted to make sure there isn't some rationale behind it that I'm not seeing. Is there? I do not think so, feel free to change this. /Øyvind K. ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Sat, Sep 11, 2010 at 8:28 PM, Rupert Weber g...@leguanease.org wrote: So it's a three-liner now. Hope it's ok that I include it here. I decided to insert a declaration instead of pulling up the static function to the top, so the patch wouldn't look like stuff has changed that hasn't. If you want it the other way, let me know or just change it. Either way, Thank you, commited to git. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Fri, Sep 10, 2010 at 11:55 PM, Rupert Weber g...@leguanease.org wrote: Something else I don't understand about models/formats: If babl automatically creates a double-format for every registered model, how can there be models without a double-format? Namely RaGaBaA, RGB, R'G'B', YaA, Y'A, and Y'? Looking at the code babl doesn't create a double-format, but when registering a color model conversions to/from a (perhaps synthesized) double format is provided to be able to regression test. Also, why are there so many empty spots on the introspection? E.g. Lab float/u8/u16: shouldn't babl find it's own way from double to float? And type conversions to/from u8 and u16 are supplied by CIE.c. (Actually, those are buggy in several ways, but fixing it doesn't help) Empty spots in what, if you are referring to http://gegl.org/babl/BablFishPath.html then the empty spots are the spots where babl is finding its own way, the single dots are where there are direct conversions and the bars of varying vertical height indicate how many steps a multi step conversion takes. The 8bit / 16bit data types for CIE lab are very different beasts from the 8bit types used for sRGB and will be used when those pixel formats are used. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Sat, Sep 11, 2010 at 1:21 PM, Rupert Weber g...@leguanease.org wrote: On 09/11/2010 10:14 AM, Øyvind Kolås wrote: Looking at the code babl doesn't create a double-format, but when registering a color model conversions to/from a (perhaps synthesized) double format is provided to be able to regression test. I'm sure you think this all totally obvious, but it's actually really confusing. ;o) An example: - I registered a color model HSV and its components, but no format. - Now I can successfully register a conversion between RGBA and HSV, all components are (implicitly) double - BablFishPath.html shows a format HSV double - But HSV double doesn't actually exist as a format. Trying to register a conversion to/from babl_format(HSV double) gives an error: babl_format(HSV double): not found - In contrast, when I _use_ babl (i.e. not inside babl) babl_format (HSV double) works just fine. - Then again, babl_format (RGB double) always fails, both inside babl and in userland. Maybe there is a red line somewhere in there which I fail to see, but right now I'm just hopelessly confused and wouldn't know how to sanely describe the situation in the docs. My knee-jerk proposition would be: Automatically register a double format for every model that is registered. Is there any downside to that? I do not see a downside to this, it would probably result in a net code size reduction which is only a good thing. (I thought before that happens already but failed to realize that I had followed the call hierarchy to somewhere in babl/tests) Empty spots in what, if you are referring to http://gegl.org/babl/BablFishPath.html then the empty spots are the spots where babl is finding its own way, I still don't understand that. What is 'its own way'? E.g. the CMYK float row has only empty spots. Picking one of them, I get e.g. 'Reference CMYK float to CIE Lab u16' in the popup window. How can babl possibly find its own way from CMYK to CIE Lab u16 without hopping over several extension-supplied conversions? When there are no direct conversions available, and no way to use multiple registered linear conversions to get from the source format to the destination format babl uses the generic conversion code in http://git.gnome.org/browse/babl/tree/babl/babl-fish-reference.c It can do this because a BablFormat contains knowledge of the color model used, the permutation (order) of the components as well as the types of the individual components. This reference conversion is bound to be quite a bit slower than a direct conversion between two pixel formats, since it contains intermediate conversions to the relevant double pixel formats, it takes the permutation of the components into account etc. This reference conversion is also used to verify that shortcuts registered in extensions actually provide sufficiently accurate results. - Those two even I understood. ;) But I'm still riddling over the red bars. Something changed making the stats output a little bit less useful than it used to be, only conversions that are using the reference fishes[1] and are used to convert a significant count of pixels should be marked like this, as an indication that the given conversion is a likely bottleneck in processing. 1: The reason for both babls name, and for classes to be called fishes can be found in the hitchhikers guide to the galaxy http://en.wikipedia.org/wiki/Babel_fish_%28leech-like%29#Babel_fish -- «The future is already here. It's just not very evenly distributed» -- William Gibson ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Thu, Sep 9, 2010 at 10:18 AM, Rupert Weber g...@leguanease.org wrote: On 09/09/2010 08:03 AM, Martin Nordholts wrote: That's pretty nice, could you provide a patch against the docs part in babl? http://git.gnome.org/browse/babl/tree/docs Sure: https://bugzilla.gnome.org/show_bug.cgi?id=629146 Yep it is nice to get someone to document some of this process :), I wonder if you can be tricked into documenting how to interpret the statistics in /tmp/babl-stats that occur when the environment variable BABL_STATS is set as well; to guide the understanding of which slow paths are being taken decreasing overall performance. Comments for the editnotes, it would have been easier to reply to these, in context if you asked them as questions here on the mailinglist rather than embed them in the document. linear, plane, planar linear is for converting a buffer of n pixels with a given pixel format, the pixels are expected to contain the components packed/interleaved/chunky in the order specified in the pixel format. plane is for converting a single plane, this can be used internally by babl when constructing reference/fallback conversions, it allows doing processing on one and one component and as guessed with individual pitch changes (to skip the other components if needed). planar is for converting full images where the components might be stored separately, like it is done for some YCbCr formats in video compression (where the dimensions of the images for the Cb and Cr components might be smaller than the Y image), this feature in babl is not used by GEGL and migh not be completely functional. ... yes, you should re-register color models and used pixel formats in extensions that are not present in the babl-base, since the order extensions are loaded in are not guaranteed. ... the use of babl_type_new and ... integer, unsigned indeed seems to be wrong. .. the return value of conversion functions was intended to be the number of samples actually converted, the value is not really used anywhere in babl though and could probably be removed and be made void. .. the chroma, alpha and luma flags have no meaning inside babl but can be useful in determining behavior for image processing algorithms in a manner that is independent of the actual color model used. At one point it was also used to detmine whether conversion would incurr a loss of features thus blacklisting possible multi-step conversion paths, this is now achieved through other means. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Development step
On Sat, Sep 4, 2010 at 6:52 PM, Jacopo Corzani corz...@gmail.com wrote: I have a stupid question about gegl devel workflow... I readed documentation and i saw gegl's bugzilla page, it seems that there aren't any ufficial open task to complete (associate to any person or group), only a open bug or feature that i can't say if is under develop and who is a developer. It seems that someone (that wants to contribute) writes any patch without knowing that will be accepted or will be useless (and don't know if anyother working at the same things). Who can manage developer's task and its priority/human resources? Patches the solve issues kept track of in the bugzilla are welcome, please also use the bugzilla and/or the mailinglist to clarify something that is being worked on - this would act as a sign to others that there is current interest in a particular topic or area. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On Fri, Aug 13, 2010 at 9:06 AM, jcup...@gmail.com wrote: On 13 August 2010 02:57, James Cox jay...@gimp.org wrote: You don't need to worry that the sRGB gamut is rather small since, because GEGL is using float, it can represent values outside the gamut as less than 0 or greater than 1. That sounds good in theory, but there will be some very sharp edges in practice. What does the UI for the curve tool look like when possible values are -FLOATMAX to +FLOATMAX. What does the contrast tool do with values above 1.0. When I blend some layers with multiply mode they can only get darker right? scRGB actually does define a range, -0.5 to +7.5, according to wikipedia, so tools like the levels dialog are not totally in the dark. That is just due to the encoding chosen, (fitting in 16bit) GEGL uses normal IEEE floats just like EXR and thus has the range -FLOATMAX to +FLOATMAX supporting HDR buffers with huge range. Thus the native pixel format used by GEGL isnt directly scRGB, but IEEE floating point RGB(A) with linear light and primaries like in sRGB. Some additional comments about color management in GEGL, confirming what has already been stated/suggested. GeglBuffers have a specified pixel-format, as defined by babl, babl's pixel formats are (at least supposed to be) well defined and accurate conversions between both precisions and color models. Thus once data is in a babl governed pixel format the color values should already be well defined. If the color space of a source image is in a device-dependent color space it either is converted upon load to for instance RGBA float or a dynamically created babl pixel format with an attached/referenced ICC profile and lcms2 powered conversions would be used. GEGLs image processing is intended to all operate in device independent color spaces, no matter which camera you took a picture with gaussian blurs, color adjustments etc, should behave the same. For many operations RGBA float, linear light RGBA in 32bit floating point is good. For other operations RaGaBaA float is good this being the same as RGBA float but with pre-multiplied alpha, this is used by most compositing operators. Some operations might prefer to operate in (and generate) CIE Lab float buffers, like the color layer mode. If the previous operation generated buffer data in the preferred format of our current operation the conversion will be a no-op or babl will fall back to a memcpy (in cases where direct access to underlying tiles is not possible). The net-effect of this is that GEGL should provide a color managed result that can ultimately be converted/separated according to a target profile. To force operation in a non-color managed, paint by numbers-mode you would have to force the format of a buffer, casting a device-dependent pixel format to RGBA float before the operations - and casting it back to the device-dependent format after the device-dependent processing is done. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] [Inkscape-devel] Cairo rendering proposal
2010/4/8 Krzysztof Kosiński tweenk...@gmail.com: On 4/7/10, Krzysztof Kosiński wrote: Here's my Cairo rendering proposal. I made it public so that all people can comment. (linking to archived mail instead of full quoting original message) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33871 To me this looks like a good approach for a cairo based renderer for inkscape, since I maintain GEGL which could possibly considered an alternative I'll post some thoughts on whether GEGLs rendering model could possibly fit into inkscape. (Note, until the last paragraph I list thing that are similar to what is needed, but at the moment probably would be a much worse option than what you have outlined). GEGL deals with many or most of the concerns of an interactive SVG canvas. And at least the long term it should be an eligible candidate for such SVG rendering (I've probably deleted an old naive SVG - GEGL graph compiler I had lying around, as well as experiments with stroking SVG paths with soft brushes and variable line widths). GEGL already does various caching of intermediate rendered surfaces and propagation of dirty rectangles in the compositing graph based on graph re-arrangements/property changes. Rendering is at the moment split into spatial regions that are processed sequentially (work is slowly under way to paralellize this processing of rectangular subregions with threads). The biggest disadvantages I see with doing something primarily vector focused using GEGL at the moment is that GEGL uses sparse tiled buffers, which are not currently supported cairo, thus additional copies are needed for vector rendering. The GEGL model is also currently avoiding any possible in-place compositing of vectors and thus ends up using more copies. The naive approach to convert an SVG document to a GEGL graph also yielded various resampling artifacts as shapes were rasterized prior to transforms being applied, this is an issue that might be possible to work around by making all nodes in the GEGL compositing graph have/be aware of transformation matrices that apply, I have also entertained the idea of passing bezier paths between nodes, allowing nodes in the graph to simply be 2geom filters manipulating vector data similar to how raster data is manipulated. Replacing the full inkscape rendering with GEGL would probably not be a good idea (long term, _I_ probably want to experiment with some such hybrid non-SVG raster/vector authoring UI, with features such as stroking with soft brushes, variable line widths, non SVG 1.2 filters and more, so perhaps it will more sense at some point in the future). Where GEGL and SVG overlap most is SVG 1.2 Filters, it would make sense to use GeglBuffers ability to wrap other in-memory linear buffers (like cairo image surfaces) and do such raster ops using GEGL. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://gegl.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] [Inkscape-devel] Cairo rendering proposal
On Fri, Apr 9, 2010 at 12:33 PM, hend...@topoi.pooq.com wrote: On Fri, Apr 09, 2010 at 03:52:03PM +0100, Øyvind Kolås wrote: 2010/4/8 Krzysztof Kosiński tweenk...@gmail.com: On 4/7/10, Krzysztof Kosiński wrote: Here's my Cairo rendering proposal. I made it public so that all people can comment. (linking to archived mail instead of full quoting original message) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33871 To me this looks like a good approach for a cairo based renderer for inkscape, since I maintain GEGL which could possibly considered an alternative I'll post some thoughts on whether GEGLs rendering model could possibly fit into inkscape. (Note, until the last paragraph I list thing that are similar to what is needed, but at the moment probably would be a much worse option than what you have outlined). GEGL deals with many or most of the concerns of an interactive SVG canvas. And at least the long term it should be an eligible candidate for such SVG rendering (I've probably deleted an old naive SVG - GEGL graph compiler I had lying around, as well as experiments with stroking SVG paths with soft brushes and variable line widths). GEGL already does various caching of intermediate rendered surfaces and propagation of dirty rectangles in the compositing graph based on graph re-arrangements/property changes. Rendering is at the moment split into spatial regions that are processed sequentially (work is slowly under way to paralellize this processing of rectangular subregions with threads). A few years ago, Henk Boom did a google summer-of-code project to integrate svg rendering into the Gimp. His code was placed on hold until enough bogs were fixed in the Gimp to make it prectical to add new features. If people are starting to look at connecting Inkscape and Gegl, perhaps it's time to dust off his code and have a look at it. I'm not sure. GEGL already does more/other vector graphics than the vector layers feature that was added in the GSOC, and in a manner that would seamlessly intergrate with how effect-layers, GEGL based text layers and other composition based enhancements will be done. As I recall it, the vector layers as implemented in that branch feels like a proof of concept and the UI integration with the rest of GIMP is rather ad-hoc. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Some Questions about GEGL library
On Mon, Mar 29, 2010 at 4:58 PM, Nicolas Robidoux nicolas.robid...@gmail.com wrote: Øyvind (and all): Long term development question: If one was to try to optimize gegl operations which involve resampling (image rotation, affine and perspective transformations), do you think this should be done on the GPU, or should be done, outside of the GPU, by exploiting SSE-type operations? Any other idea? Note that multiple other ops will eventually also be using the resampler infrastructure, at least when using C code, among these are displacement maps, mirrors/kaleidoscope (already exist in git), ripples/waves ported from GIMP, mapping to and from polar coordinates and more. It is likely that such transformations would, at least initially reuse the texture resampling units found in the GPU and thus probably only provide standard samplers. It is not obvious to me that the goal should be to port everything to the GPU. Is it obvious to you? To get the benefits offered by the GPU, at least in a scenario where texture data has to be migrated between the systems, any operations that does not exist on the GPU will slow down GPU based acceleration, potentially to the degree where benefits from using the GPU will be lost. The approach I think makes sense for GEGL is to allow ops to opt-in to be able to do GPU processing. With the GSOC GPU branch GPU and CPU usage of the same GeglBuffer is transparent and tiles are automatically migrated from RAM to texture memory and back as needed. What parts of GEGL are more likely to benefit from having a GPU version? Least likely? Image processing algorithms that are embarassingly parallel will benefit from having GPU versions. This at least includes compositing, with good caching in place it might be possible to do fast gpu recomposition of cached subgraph results from slow/non-gpuable renderings. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Some Questions about GEGL library
On Fri, Mar 26, 2010 at 7:37 PM, Rahmati Fateme ftm.rahm...@gmail.com wrote: Hello, I'm a master's student in computer science at Strasbourg university (France). I start working on a project related to GEGL library, my goal is to study how to optimize operators' graph to reduce execution time.It would be nice if I could have some information about the optimizations which are already implemented in GEGL. I would be grateful if you can give me some informations about these questions: 1. Is there any optimizations done on the graph in the last version of GEGL? For instance, one could think of several optimizations: · Precomputation of node compositions: If you apply several nodes maybe the composition of the nodes is computable and easier to compute. Lets say that we have two nodes increase lightness by 10 then increase lightness by -20, the graph could be automatically simplified to increase lightness by -10, is it already the case in GEGL ? Of course one could assume that the application which is using GEGL should not generate such graphs, but maybe for more complicated composition it would be easier to do it in GEGL. For instance, is the composiion of two gaussian blur another blur operation ? Another example could be to combine, Lightness and Curves operations into a single Curves operation with different parameters. Currently GEGL does not do any extensive optimizations on the graph level, some operations make sure that when the given parameters are a no-op the pixels are not touched but the original buffer passed through (blurs with radius == 0.0, rotations, and scales or translates with no change). The porter duff over (normal layer compositing) op also optimizes to a passthrough when only one input buffer is provided. Consecutive affine operations (a scale and then a translate) is also collapsed to be a single affine operation (avoiding the inherent loss of multiple resamplings). This is handled within the affine ops by making them all be subclasses of a common operation. Ideally this would be extended in such a manner that GEGL would be able to re-arrange all affine operations to happen only once, immediately after loading the pixel data - this would reduce the number of resamplings as well as reduce total processing time. · Precomputation of operators' graphs for several pictures: If you want to apply the same graphs to several pictures it could be nice if some precomputation is done on the graph before it is evaluated on all the pictures. For instance, given a point operators f which performs the same operation on the different channels of the image (r,g,b) (lightness, contrast, ...), if one is working with 8 bits pictures, one could precompute an array containing f(x) for x in 0-255, and then using this same array for evaluating the graph on all the pictures. Is it already the case in GEGL ? GEGL has lazily initialized lookup tables that even work for floating point, doing processing on 8bit image data is best avoided. · Evaluation in parallel of several nodes of the graph using OpenMP There is an experimental multi processing configure option, the paralellization is done by having separate threads compute separate parts of the final render. There is no need to use OpenMP to achieve this. · Evaluation of the nodes using GPU, I have read it was the subject of a Google summer of code, what is the current status of this ? The result of last years summer of code was proof of concept code allowing automatic migration of tiles for GeglBuffers between system memory and GPU memory. Large gains can not be made until many ops exist in a GPU version thus avoiding excessive migrations back and forth. 2. How the operator's graph is maintained and how the nodes are saved? Can you also give me some references where I could find more related information? Please study the source code, for further questions please join the irc channel #gegl on gimpnet (irc.gimp.org). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] error message when executing gegl-paint
On Wed, Nov 11, 2009 at 4:42 PM, Øyvind Kolås islew...@gmail.com wrote: On Fri, Nov 6, 2009 at 6:11 PM, Tim Chen timc...@cs.nthu.edu.tw wrote: Today I pull babl / gegl clone from git ... However, when I tried running the gegl-paint in the example folder, a blank window poped up. And whenever I click on the window, I got error message : ... How should I fix this problem? The hardness property has been renamed stroke-hardness. Something else has broken elsewhere in GEGL at some point as well since fixing that still doesn't seem to cause any rendering to happen. Both problems have been resolved now, and the example works again. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Passing parameter to sampler from XML file
On Wed, Jul 8, 2009 at 8:43 AM, Nicolas Robidouxnrobid...@cs.laurentian.ca wrote: Suggestion implementing the s/nohalo family and the nohalobox family without an explicit, visible, parameter: Would it be possible/desirable to use the current code (which has a parameter) as some sort of template? Sure, for most uses both developers and users will desire a default sampler that just works and needs no tweaking. Additional properties to configure some of the samplers will make it harder both for users of GUIs as well as developers implementing or using operations that use the samplers. Fewer presets that cover normal use cases is probably better than many; this trimming down of the presets might be done in GUI layers code as well. The names for samplers would need some serious thought, linear, cubic and lanczos in current GIMP is already too techical for many users, most people would have no clue what box refers to in the suggested names. When exposes as for instance a drop down in the GUI these names need to be translatable into other languages as well. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Passing parameter to sampler from XML file
On Wed, Jul 8, 2009 at 1:08 PM, Nicolas Robidouxnrobid...@cs.laurentian.ca wrote: PS Let me know if you'd rather I think about all this off list. I dislike writing email, and you are almost using email like IRC, feel free to continue but do not expect much response from me in particular :d /pippin -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Passing parameter to sampler from XML file
On Tue, Jul 7, 2009 at 10:25 AM, Nicolas Robidouxnrobid...@cs.laurentian.ca wrote: Adam Turcotte and Eric Daoust are implementing samplers (alternatives to nearest neighbour, bilinear, bicubic, lanczos... interpolation), names snohalo1 (tuned for upsampling) and nohalobox (tuned for downsampling), which both have a natural parameter. This parameter is basically the amount of extra antialiasing which is applied. The way the extra antialiasing is done is with a customized blurring operator in the case of snohalo1, and by enlarging the integration box (like for exact area box filtering) for nohalobox. Adam is nearly done (fingers crossed) implementing the paramter so that it is settable through xml commands. My question: We've settled on the name blur for this paramter, because for most people this is the visible effect, and I think most people understand that blurring can be useful to smooth out jaggies. Would you guys prefer another name for this visible parameter? Antialiasing, for example, seems like a good candidate, although it sounds a little too technical to my taste. I would feel more comfortable if this parameter was not exposed, but rather that sane presets were added and given names. In most cases the additional properties of for instance a displacement map operation might be visual and conceptual clutter getting in the users way. When it comes to naming it; I think perhaps smoothing is a good candidate. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Cache strategy
On Tue, Jun 16, 2009 at 8:58 AM, johannes hanikahana...@gmail.com wrote: this is handled well because changing the last operation in the graph will need the output of the previous one, thus incrementing the ``more recently used'' value of this one, preventing the important previous cache line from being swapped out. if this swaps out other important cache lines on the way, a mechanism to detect such a situation can be implemented (only changing parameters of the same op very often and quickly), such a thing is required for the history stack anyways, as it would also overflow. so i was thinking if maybe such a global (in the parent gegl node?), straight forward LRU cache with an appropriate hash could work for the tiles in GEGL as well (one tile = one cacheline, or one mip-map level of a tile = one cacheline..)? did you try it already? if so, how did it go? Having caches for all nodes effectively implement what you suggest, since the caches are just GeglBuffers and GeglBuffers that are unused will end up having all their tiles in swap on disk. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Cache strategy
On Tue, Jun 16, 2009 at 11:11 AM, jcup...@gmail.com wrote: Another thing worth mentioning is that caches on every node doesn't scale well to concurrent evaluation of the graph since the evaluators would need to all the time synchronize usage of the caches, preventing nice scaling of performance as you use more CPU cores/CPUs. In most instances, this would only incur synchronization of a few tiles where the chunks/work regions overlaps. Unless you are stupid and compute with chunk-size~=tile-size the impact of this should be mostly neglible. You would still need a lock on the cache wouldn't you? For example, if the cache is held as a GHashTable of tiles, even if individual tiles are disjoint and not shared, you'll still need to lock the hash table before you can search it. A couple of locks on every tile on every node will hurt SMP scaling badly. You do not need to make this be a global hashtable the way it is done with GeglBuffers it would end up being one hashtable per node that has a cache, not one cache for for all nodes. If I understood your concern correctly it was about having a global lock that is locked. Also note that GEGL does not use the tile-size for the computations, tile dimensions are a concept that only belongs on the GeglBuffer level that should be ignored when using the GeglBuffer API and at higher levels of abstraction. For what it's worth, vips handles this by keeping caches thread-private. If threads are working in disjoint areas of the image, there's no benefit to a shared cache anyway. As you say, there will be a degree of recomputation for some operations (eg. convolution), but that's a small cost compared to lock/unlock. vips has two types of cache: a very small (just 1 or 2 tiles) thread-private cache on every image, and a large and complex shared cache operation that can be explicitly added to the graph. The GUI adds a cache operator automatically just after every operation that can output to the display, but you can use it elsewhere if you wish. This type of cache is the cache that is currently in use in GEGL, although it isnt an explicit member of the graph, but contained within the preceding node (it is the sparse tiled buffer written to by the operation contained in the node instead of allocating/recycling temporary one-off buffers). The caches are GeglBuffers. Each GeglBuffer (and thus cache) has a tile-cache as well that keeps frequently used data from being swapped out to disk. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Cache strategy
On Mon, Jun 15, 2009 at 8:12 PM, Patrik Östmanpa.ost...@gmail.com wrote: node 1 to node 2. Are there any significant changes of cache handling done between 0.0.20 and 0.0.22 or are there a setting that must be turned on to get 'per node caches' functionality? The caching policies and mechanisms in GEGL are still basic and rough. At the moment the GeglOperationClass has a boolean no_cache member that is checked. Which operation subclasses automatically do cache have changed lately since the memory consumption of caching every single node probably outweighs the benefits of caches for every single node. In particular I think point operations now explicitly do not cache their results. Ive entertained the idea to use special nodes to indicate caches, but that would to some extent muddle the graph. Perhaps a better solution is to allow turning the caches on dynamically on demand and not only define such hints in the class, the existing implementation should be possible to bend in both ways. Another question: What is the difference between GEGL_BLIT_CACHE and GEGL_BLIT_DEFAULT flags of the 'blit' function? GEGL_BLIT_DEFAULT will not create a cache for the node but render directly, using GEGL_BLIT_CACHE instead will create a cache that results are rendered into and provided from, making subsequent requests when properties and the graph has not changed be much faster. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL Perf tools - plan
On Thu, Jun 4, 2009 at 3:33 PM, Henrik Akesson h.m.akes...@gmail.com wrote: This is the moment to let me know for anyone who wants me to include a certain tool in the survey. I'm currently at: - gprof, sprof - valgrind (cachegrind, callgrind) - ltrace, ptrace - oprofile GEGL itself contains built in instrumentation that allows breaking down the time spent in pixel format conversions (babl) as well as the different nodes of a composition. The small sample gallery at the website used to be part of an automatic regression testing facility operated by OSDL called crucible which did nightly builds and performance/rendering regressions. See http://www.gegl.org/gallery/clones.txt for examples of how this infrastructure breaks down processing time. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] geglbuffer-add-image writes GeglBuffer to disk only after a gegl_buffer_flush()?
On Wed, Jun 3, 2009 at 8:45 PM, Giuseppe Rota rota.giuse...@gmail.com wrote: I got stuck with the geglbuffer-add-image example, though. I expected to find, after a successful run, a file (first argument) containing the serialization (or dump, if you will) of a GeglBuffer (I used data/surfer.png as input). That did not happen so I inserted a gegl_buffer_flush(buffer); instruction before the 2 g_object_unref near the end of the main(). That did the trick, I now have a binary file with the serialization of a GeglBuffer (first 4 bytes are GEGL). This happens (on Linux) both with version 0.0.22 and with the HEAD svn version (both babl and gegl) (GIO enabled). Can you please explain the rationale behind this behaviour? GeglBuffer currently lacks multi process support which it can (could?) be enabled by patching GIO to allow simultanous read/write access from different processes. With such extra tweaks I suspect that the example would produce the desired output as written, this should be changed. GeglBuffer was developed againt GIO it would have been better, and will be better to mmap the file and share the tiles between processes in that manner instead. On a unrelated note, what's the difference between gegl_buffer_load and gegl_buffer_open? gegl_buffer_load loads a on disk buffer into RAM, swapping into the users swap directory for tiles that are not stored in memory. gegl_buffer_open opens an existing on disk GeglBuffer using the buffer itself for swapping. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] alignment of pixels with coordinates
On Thu, May 14, 2009 at 4:57 PM, Nicolas Robidoux
nrobid...@cs.laurentian.ca wrote:
My working assumption is that GEGL should be as consistent as possible
with GIMP.
gegl/gegl/buffer/gegl-sampler-cubic.c, for example, contains the
following code:
--
...
gegl_sampler_cubic_get (GeglSampler *self,
gdouble x,
gdouble y,
void *output)
{
...
gint dx,dy;
...
dx = (gint) x;
dy = (gint) y;
sampler_bptr = gegl_sampler_get_ptr (self, dx, dy);
...
--
Ignoring the issue of the asymetric behavior of int casting when one
crosses 0 vs the right boundary (see gegl-sampler-linear.c or
gegl-sampler-sharp.c for a fix) I want to double check that pixels are
understood to be centered at points with integer coordinates (for
example (0,0) is a possible pixel location, but not (.5,.5) throughout
GEGL and GIMP (excluding plug-ins, of course). If there are
exceptions, are they relevant to resamplers and abyss policies?
If there is a discrepancy between GEGL and GIMP, I will have Adam and
Eric align GEGL with GIMP as much as possible.
I agree that the convention should be that pixel sampling sites are at
integer coordinates. I also feel it would be natural to let the extent
of a pixel be half way towards the neighbour pixel sites, this however
has the issue of not matching the display GIMP provides when zoomed
into the image.
At the moment the display code in GIMP assumes that we want to see big
pixels when zooming in and hence uses nearest neighbour interpolation
for zoom levels 100%. The pixels themselves are displayed as squares
that extend to the right and down from the pixel. This is useful for
some tasks, like for instance filling subpixel bezier curves based on
analytical geometric coverage.
GEGL might in the future also offer other resamplers for blitting /
display purposes, the best would of course be if all resamplers could
be plugged in and interchangeably used for different purposes, at the
moment the resampling that happens in gegl_node_blit does not use the
resamplers to do its job for the general cases it probably shouldn't
either since it needs to be as fast as possible.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Introduction to GEGL Buffers
On Wed, May 13, 2009 at 6:08 PM, utkarsh shukla utk.shu...@gmail.com wrote: So you are suggesting to parallelize the Gimp image operation means that multiple GEGL processes should run at the same time. So currently the GEGL has graph manipulation and then the rendering. I am not sure how you tried to split the rendering from graph manipulation. By having a dedicated thread that does the actual processing work, and reporting that results have finished rendering in the main thread (which is with the application/GUI/graph manipulation code). Dou you mean to say that curretnly Gimp first processes the graph and then renders the whole of the image afterwards. So if I get a clear overview then what I feel that this thing is much different than the GPU thing as here the parallelization is needed at much higher level and just very below the Gimp interface infact on the interface the things should be parallel threaded. Am I correct?? Not quite sure I understand what you mean. The paralellization in GEGL should occur within the existing API and be splitting up the workload into paralell rendering tasks for different subregions of the output image. GEGL is a demand driven caching data-flow based rendering system. First the graph is set up, nodes connected and properties set. Then either a sink node is processed or more normally like in a GIMP use case; a GeglProcessor is set up with a full region to be computed. GEGL doesn't compute all data at once but splits the requested region into rectangular chunks and processes these chunks in paralell. As chunks are computed GEGL signals will be emitted on the node reporting which areas have been computed. Behind the scenes a GeglProcessor could be doing it's real work in a thread, or even create multiple GeglProcessors that operate on separate parts of the output in paralell. Going beyond this, with buffers shared between processes and hosts it should be possible to extend the processing even further. After this GSOC I hope to have the means to have a unified memory architecture for GeglBuffers, at that stage GEGL could perhaps even do portions of the processing and|or compositing on the GPU (IO will be a concern in this case). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Introduction to GEGL Buffers
On Tue, May 12, 2009 at 3:50 PM, Nicolas Robidoux nrobid...@cs.laurentian.ca wrote: I'm not making promises on the following (given that they are not part of the original GSoC) but they are related to Adam and Eric GSoCs, but it would make sense to have them have a look at the following (I may give more programming help with the resampler parts to free them for what's below): - Detect when a tile is set to be a solid block of the background color, and make the tiled shared with the empty tile. - Detect uniformly colored and perhaps other types of tiles and store them more compactly, perhaps even just compressing tile contents and share duplicate tiles detected through hashing of their compressed data. I forgot to add one more item to my list of potential/desired enhancements of GeglBuffer and that is to make the extent (width and heights) of the buffer be updated on demand when tiles are changed, allowing automatically growing buffers that are auto-clipped to the bounding box of content that differs from the configured background color. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Introduction to GEGL Buffers
On Tue, May 12, 2009 at 9:55 PM, utkarsh shukla utk.shu...@gmail.com wrote: hi, Actually I am not a GSOC student but I was very much interested in writing some code or some patch for gimp. Please guide me in case you feel I can be of bit help. I am not a mentor in the summer of code but I am interested in GEGL becoming a powerful framework for both using and developing image processing algorithms. I welcome you to discuss and help implement and improve any part of GEGL. You've got knowledge of relevant technologies like OpenGL, GLSL as well as development in general and can be valuable in guidance on prototype code and ideas as that project gets off the ground. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GPU support
On Mon, May 11, 2009 at 7:49 PM, Richard H. for...@gimpusers.com wrote: Hello, Implementing multi-threading in GEGL is out of my scope and I'm not even sure if it's in GEGL's scope. I understand that as your project's task is adding OpenGL support. In my opinion, multi-CPU support would be more important, but that is of course another big task/project. GEGL has been designed to have an API that will allows using it without concern of whether it internally is single threaded (like its current incarnation), threaded, multi-process, multi-host or multi-process with parallel tasks driving GeglProcessors for different subregions, or perhaps even with the workload divided in a stream processing like manner. GEGL is pretty low-level and threading can be implemented on top of GEGL by the relevant client (i.e. GIMP). Nope,. see above. My work will be concerned with accelerating pixel-level operations by parallelizing each pixel operation in the GPU. The key in my work is that all pixel operations should (theoretically) work in parallel. That would indeed be very nice to have. A GPU based backend should be possible to integrate with some of the above outlined possible approaches of dividing labour, ideally it would be possible to use GEGL and let GEGL itself figured out how to best make use computational resources available. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL 0.0.22
GEGL 0.0.22 ⎺⎺⎺ GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides infrastructure to do demand driven, cached, non destructive image editing of larger than RAM rasters. Through babl it provides support for a wide range of color models and pixel storage formats for input and output. This is a release introduces a feature freeze the current feature set perhaps with some features will become the basis for the first 0.1.0 release, the APIs which will receive some changes (removal of feature) is GeglPath, apart from that most of the current API seems to be sufficient for a quite wide range of uses. After the introduction of gegl_node_add_child and gegl_node_remove_child calls gegl_node_adopt_child call might be removed. Please note that documentation of unstable APIs is not complete. Happy new year. /pippin Changes in this release ⎺⎺⎺ • GeglOperation • operation names are now prefixed, the ops in GEGL use 'gegl:' as prefix. • gegl:opacity - combine value and aux mask input when both are available. • gegl:src-in - deal correctly with extens. • gegl:path - new op covering the stroke/fill needs of SVG. • deprecated gegl:shift, the affine familiy of operations now uses the same fast code paths for integer translations. • GeglBuffer • Profiling motivated speed ups in data reading/writing. • Remove left-over swapfiles from dead processes at startup. • GeglNode • made gegl_node_add_child and gegl_node_remove_child public API. (#507298) • GeglPath Vector path representation infrastructure, supporting poly lines and beziers by default, the infrastructure allows extensions from applications with other curve types (smooth curves, spiro curves and others.). The improvements in GEGL in this release brought to you by: Hubert Figuiere, Sven Neumann, Øyvind Kolås, Michael Natterer, Kevin Cozens, Sam Hocevar, Martin Nordholts, Manish Singh, Étienne Bersac and Michael Schumacher. Where to get GEGL ⎺ GEGL and it's dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.22.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.22.tar.bz2 ftp://ftp.gtk.org/pub/glib/2.18/glib-2.18.1.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 9de50fb5833f41691f50f6e735d6422aad52ea94 babl-0.0.22.tar.bz2 de684d4c8d9eaa9b7e283c55c5f779e5bdabee78 gegl-0.0.22.tar.bz2 d34a30cfccc8322dfe4198d26cf6bfc0210f141b glib-2.18.1.tar.bz2 Where to get more information about GEGL More information about GEGL can be found at the GEGL website http://www.gegl.org/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] tile size in filters
On Mon, Oct 20, 2008 at 3:56 PM, Dierk Fröhling [EMAIL PROTECTED] wrote: Hans Petter Jansson wrote: On Thu, 2008-10-09 at 11:08 +0200, Dierk Fröhling wrote: I need to handle all pixels of an image in one tile for my new filter. The problem is that every pixel in the filtered image should depend on values from all other pixels... .. I wrote a color reduction filter that does Floyd-Steinberg dithering, where each pixel depends on all previous pixels (the bottom-right pixel depends on the entire image). It should be among the workshop filters. Maybe that'd be useful to look at. This worked up to a certain size of images - but with an image with 3112 x 4200 pixels I get this message from gegl: ** Message: unable to write tile data to self: No space left on device (-1/131072 bytes written) There is enough space in my /tmp directory and all other possible working directories for gegl - 2GB of memory should be enough as well... It's not that my filter won't work at all with these big images - but only in parts. It seems that gegl splits it into tiles again... The place that GEGL probably tries to swap is ~/.gegl/swap I'm not sure what is going on here. Does this happen with the color reduction filter as well? Please open a bug so we can track this issue, perhaps even with an example XML file provoking the issue (perhaps using fractal-explorer as source data or some similar synthethic buffer as input.) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL 0.0.20
GEGL 0.0.20 ⎺⎺⎺ GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides infratructure to do demand driven, cached, non destructive image editing of larger than RAM rasters. Through babl it provides support for a wide range of color models and pixel storage formats for input and output. Changes in this release ⎺⎺⎺ • Build and code clean ups and fixes. • RAW loader using libopenraw. • GeglBuffer • Linear buffer support, amongst other things enabling GeglBuffer API access to external linear buffers in memory. • Reworked samplers using a shared caching neighbourhood infrastructure. • YAFR - a new resampler contributed by Nicolas Robidoux. • GeglOperations • Marked user visible strings for translation. • Added a fill operation (might be a bit fragile) that allows rendering SVG like paths backed by a GeglVector. The improvements in GEGL in this release brought to you by: Martin Nordholts, Øyvind Kolås, Sam Hocevar, Manish Singh, Hubert Figuiere, Sven Neumann, yahvuu at gmail.com and Michael Natterer. Where to get GEGL ⎺ GEGL and it's dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.22.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.20.tar.bz2 ftp://ftp.gtk.org/pub/glib/2.18/glib-2.18.1.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 9de50fb5833f41691f50f6e735d6422aad52ea94 babl-0.0.22.tar.bz2 37be399b58d50a87134f2dfad389a476e1155874 gegl-0.0.20.tar.bz2 d34a30cfccc8322dfe4198d26cf6bfc0210f141b glib-2.18.1.tar.bz2 Where to get more information about GEGL Information about GEGL can be found at the GEGL website http://www.gegl.org/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] How to get bounding box from inside a sampler
On Sat, Sep 20, 2008 at 3:41 AM, Nicolas Robidoux [EMAIL PROTECTED] wrote: Hello all: This question will make clear that I don't understand c++. Suppose that, in the code for, say, gegl/gegl/buffer/gegl-sampler-cubic.c, I want to use information about the bounding box of the input data. More precisely: I (believe that) I already know that the relevant pixel values start at indices 0,0. Requested values to the left and above those are created by the (currently 0,0,0,0) abyss policy. Which is to say that 0 and 0 are the smallest x and y for which I have real data. Not true, the valid pixel values can be in any rectangular sub region of the buffer, negative values should also be supported. GeglBuffer supports dynamically growing (will be useful for GIMP having auto-growing layers when painting.) What I want to know is the width and height (in pixels) the area with valid pixel values. This is almost the same as: I want to know the lowest positive indices at which the abyss policy kicks in. Which is almost the same as: What is the index of the rightmost/lowest pixel with real data associated to it. From within the sampler you cannot really know the extent of the buffer being handled. It would often be a rectangular sub-buffer of the real buffer so you cannot check the extent of the buffer being sampled from. One way to achieve the desired behavior from a sampler is to pass the extent of the rectangle in when using the sampler. This could then be done from bits of the code that knows what extents to use. Haven't thought about how to add or change API to well accommodate such a need. For most cases though I think that extending GeglBuffer to support more abyss models like mirror and smear as well as constant value of different kinds would allow simplifying the code needed for many samplers. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Is there a reason why -ffast-math is not included in the CFLAGS?
On Tue, Sep 16, 2008 at 10:09 PM, Nicolas Robidoux [EMAIL PROTECTED] wrote: At least on my machine (recent Intel Ubuntu laptop), it makes a small, but noticeable, difference. Why not include it? I doubt very much that any of us is doing something which depends too closely on exactly how floating point is done. I certainly trust that the samplers will not be affected (maybe nearest neighbour, but nitpicking about a discontinuous method...). In the gegl/gegl/buffer Makefile, for example: CFLAGS = -g -DGEGL_ENABLE_DEBUG -g -O2 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -mmmx -msse It probably doesn't harm, though I do not know in which circumstances it would matter either. If it doesn't cause any problems it could probably be added to the build system. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Optimisations
On Sun, Sep 14, 2008 at 5:01 PM, Henrik Akesson [EMAIL PROTECTED] wrote: Hi, This is the first time I write on this list, so I'll introduce myself briefly: I've been working/developing for the european space industry for 7 years, but have decided that I want to do SW research, which is why I'm currently doing a Master (to be followed by a PhD). During this MSc I'm specialising in parallelism. The second half of this master, (first half of 2009) is a research project. This will be on the subject of optimising image treatment algorithms using different parallel languages/addons such as : - CUDA - AMD Stream - OpenMP - MPI - the Barcelona Supercomputing Center's Cell/SMP Superscalar So, now to the point: I'd like to know if you would find it useful if I do and contribute this work on algoritms in GEGL? At the moment GEGL is not paralellised beyond usage of SIMD instructions. The usage of SIMD instructions follows the add-on like approach that you suggest, this is currently done by having GEGL switch to different implementations of the core algorithms. A runtime regression testing framework for different implementations based on the readable C version is on the wish list for GEGL. With the public API of GEGL as stable as it is now, it would be possible for you to create an API compatible fork of GEGL where you significantly changed how it worked internally as well, doing perhaps a subset of what GEGL can do built around other ways of traversing the data when rendering it. I can imagine such an approach could be potentially easier to implement some possible ways of parallellising GEGL. The planned approach is to use existing divide and conquer for dividing the rendering task, and it's dependency graph computation as currently used to segment the work when GEGL is rendering result pixels. Different parts of the final result would be distributed to rendering slaves that would be doing the computation for the controlling process. The slaves are planned to be either on the same machine or on the network. The rendering host will be able to share it's open GeglBuffers with processes on the same machine or even over the network. The slaves will be given graphs of nodes to render that have the rendering hosts GeglBuffers as sources and destinations for rendered data. IO of pixel data will be a potential bottleneck. The way it is planned done is by extending the tiled buffer storage backend to work over the network. (Proof of concept of sharing the same GeglBuffer objects for local processes through a shared swap file is already implemented.) Would you have any restrictions on which technologies to use (availability of open source compiler/runtime, size etc...) ? As long as additional dependencies are optional and are freely available for download and compatible with GEGLs existing licensing, good code contributions are always welcome. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Speeding up/documenting the gegl code
On Sat, Sep 13, 2008 at 1:49 PM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sat, 2008-09-13 at 08:41 -0400, Nicolas Robidoux wrote: One thing which I would not mind seeing throughout the gegl code is the systematic use of the const keyword. We will happily accept patches that introduce more constness. Pippin, do you agree? Yes, more usage of const is a good thing. I think most of the public API has const arguments in the places where it should be, omissions there would be most important to get fixed. For the internals cleaning up the code will aid the future refactoring and make development of new features like parallel processing easier. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] libopenraw support
On Fri, Aug 1, 2008 at 2:44 AM, Hubert Figuiere [EMAIL PROTECTED] wrote: Here is my patch to provide (optional) libopenraw support to GEGL. Is it OK to commit? Feel free. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] [Gimp-user] Is CMYK off the table for Gimp?
On Mon, Jun 30, 2008 at 12:29 PM, Øyvind Kolås [EMAIL PROTECTED] wrote: I am happy with GEGLs current limited focus on three-dimensional (plus alpha) color models, this might be expanded with something resembling spot colors, for z-buffers from 3d renders for use in compositing, as well as native support for multi-spectral pixels if I find the need. Native CMYK compositing and processing is something I consider to be of little benefit to most and of minimal interest to myself, thus I am unlikely to spend much time on it. Just to add a note, this wouldn't stop someone from modifying GEGL to be capable of having a set of CMYK processing operations, or alternate code paths for dealing with CMYK buffers in existing operations. If done correctly without intruding much on the existing code - patches that implement the missing functionality would be welcome. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Area filters
On Thu, Jun 26, 2008 at 4:33 PM, yahvuu [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 2:31 PM, Øyvind Kolås [EMAIL PROTECTED] wrote: Anyhow, implementing these filters as new operations solves the problem for now. Having two kinds of gaussian blur seems awkward at first, but it is a user choice which edges to blur and not GEGL's. The filter pairs can be merged later on by implementing one as a meta operation of the other or simply by an option property like preserve bounding box. I'll derive the new filters from GeglOperationEdgedAreaFilter if no better naming comes up. For the filters probably: gaussian-blur-edged, box-blur-edged It is much better to extend GeglBuffer to have an abyss policy, this means that requests for pixels outside the define area gets read back as if they were smeared/mirrored (or like now all 0). After this the gaussian blur could be changed to not expand it's result rectangle beyond the original input, and still use the current easily managable code paths for the actual filtering. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Area filters
On Fri, Jun 27, 2008 at 10:31 AM, yahvuu [EMAIL PROTECTED] wrote: handling the bounding box inside the filter is kind of a PITA, yes. But anything else will be a rough approximation (at least for blur filters). I feel it somewhat contradicting to utilize floating point arithmetic for the calculation of low quality results. I do not see how allowing to specify that pixels outside the defined rectangle for a buffer by definition is for instance the smeared out values (or the mirrored values) of the defined content would yield a different result from handling this inside the operation itself. Doing it this way keeps the blur operations clean and simple and moves the complexity down in the abstraction layers. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] New GEGL logo
A new GEGL logo has been created by me with help and advice from others. This mail sent out also to test whether the mailing list has become unclogged after recent problems. /Øyvind K -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ attachment: GEGL.png___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL-0.0.18 released
GEGL 0.0.18 ⎺⎺⎺ GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides infrastructure to do demand based cached non destructive image editing on larger than RAM buffers. Through babl it provides support for a wide range of color models and pixel storage formats for input and output. This development release will include optimizations for the cpu capabilities of the host system. Pass --disable-mmx and --disable-sse to configure to disable these when building packages that should work on a wider range of hardware. Making GEGL adapt at runtime is a blocker for the next release. There is no new API in this release thus bindings do not need to be updated. Changes in this release ⎺⎺⎺ • Configuration both from commandline arguments and at runtime. • GeglBuffer • New raw tiled raster file format, used both as swap and stored buffers. • Sharing between processes through synced swap. • Babl powered scan iteration infrastructure for efficient access. • Cubic and lanczos samplers re-enabled. • Operations • Use scan iterator for point-filter, point-composer and point-render base classes internally for minimal amount of copies. • Optimized variants of some point and compositing operations reimplemented using a new data type /g4float/ that allows writing cpu agnostic vectorized code for GCC. • New temporal filter base class, for operations operating on color values from neighbouring frames in a video stream. • Autogenerated operation reference installed for use with devhelp. • New operations: write-buffer, v4l, color-temperature. A new release of babl is also available for the quickest operations GEGL work best with babl-0.0.22 or newer. This release appears due to contributions from: Øyvind Kolås, Kevin Cozens, Sven Neumann, Manish Singh, Martin Nordholts, Étienne Bersac, Hans Petter Jansson, Jan Heller, dmacks at netspace.org, Sven Anders, Hubert Figuiere and Geert Jordaens. Where to get GEGL ⎺ GEGL and it's dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.22.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.18.tar.bz2 ftp://ftp.gimp.org/pub/glib/2.14/glib-2.14.5.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 9de50fb5833f41691f50f6e735d6422aad52ea94 babl-0.0.22.tar.bz2 f8113ad33161337eb107ad84c0ac968dca1d02d2 gegl-0.0.18.tar.bz2 d8ae9dcb744ebfcb23809c3c552f4d724cb2458c glib-2.14.5.tar.bz2 Where to get more information about GEGL Information about GEGL can be found at the GEGL website http://www.gegl.org/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL XML library
On Tue, May 27, 2008 at 11:52 AM, Ferran Basora [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 11:56 AM, Øyvind Kolås [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 9:09 AM, Ferran Basora [EMAIL PROTECTED] wrote: Hello, I have been watching the code about reading and generation of XML in GEGL. I think it is obsolete and pour extensible. This code should not be extended much, if at all, it should perhaps be cleaned up, but that also pends on reaching agreement/consensus on the OpenRaster specification at freedesktop. Right now the current code serves the purpose and it is not meant to be extended much even when reshaped to be more inline with the OpenRaster plans. We may not have to extend the code but clean. This cleaning could just as well take place without adding a huge external dependency, after all serialization to an XML format as well as loading it is quite far outside the core functionality of GEGL and might be suited for frameworks, libraries or applications on top. As you say we have to wait for a final specification of OpenRaster format, but is propable that OpenRaster format will be a structure in XML, as OpenDocument. For this reason GEGL will need an interface to load OpenRaster format from an XML. I do not see feasible to remove completely all the XML functionality. It shold be possible to implement all of the XML funcitonality using the other API and thus make the XML handling be an external library, perhaps called gegl-openraster or similar, for such a library a dependency on an external XML handling framework makes more sense. For internal XML need for GEGL (meta operations for instance), GMarkup which is currently used is sufficient. Waiting for a final specification of OpenRaster doesn't make sense, we need to prototype things and check out how much of what has been created would be possible to push into OpenRaster, open raster is in part specified due to how the XML handling is done/being planned to potentially be done in GEGL. GEGL never has promised to handle OpenRaster in any way, and the API documentation warns that the current XML is a stopgap measure that might be radically changed. OpenRaster is probably too domain specific since it might be difficult to push for instance the more video editing and compositing like things people would want to do with GEGL (ref http://pippin.gimp.org/oxide/) which is a precursor/inspiration for OpenRaster, that extends the scope to animations and sequences of clips. Going down a route of making the OpenRaster/tree based XML less prominent in GEGL is probably sane since the pure internal representation of GEGL does not use trees. A more free form XML for describing the graph for use with the meta operation as well might replace all of the existing XML. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL XML library
On Tue, May 27, 2008 at 9:09 AM, Ferran Basora [EMAIL PROTECTED] wrote: Hello, I have been watching the code about reading and generation of XML in GEGL. I think it is obsolete and pour extensible. This code should not be extended much, if at all, it should perhaps be cleaned up, but that also pends on reaching agreement/consensus on the OpenRaster specification at freedesktop. Right now the current code serves the purpose and it is not meant to be extended much even when reshaped to be more inline with the OpenRaster plans. One of the things that is pending with regard to the XML format is finding a way to make the meta operations be described as XML instead of C, this should also be easily doable continuing to use gmarkup (this might be unrelated to OpenRaster, or might be something that could be folded into the set of things specified there.) I would like to see a significant advantage over the current parsing approach for dragging in an external library. For the serialization (generation of XML) I doubt that other approaches would yield any siginificantly saner code. It might even be better to completely remove all XML based functionality than to add a new dependency on an external library. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Patch: GIO dependency made optionnal
On Sat, May 17, 2008 at 11:59 PM, Geert Jordaens [EMAIL PROTECTED] wrote: Is what you are trying to do for gegl_buffer not possible with the GIOChannel? http://library.gnome.org/devel/glib/2.12/glib-IO-Channels.html#GIOChannel It probably is, but I would like to use one API to do this, namely the GIO API and start out with a GFile. I guess the port to GIO was premature, since this part of the code at some point might want to do quite a lot of it's work using mmap instead of reads/writes as well. Using GIO on the other hand would be very sweet if it worked. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Patch: GIO dependency made optionnal
On Sat, May 17, 2008 at 9:22 PM, Hubert Figuiere [EMAIL PROTECTED] wrote: Here is my initial patch for GEGL to make gio an optional dependency for those who run an already obsolete version of glib. This isn't only about obsolete versions of glib since there is no version having a GIO supporting all the features GeglBuffer would want it to, see bug #533547. Thus unless this gets resolved in glib we might have to fall back to regular posix calls anyways. The only non-trivial part is GFileMonitor, and I actually scraped that part. Could be reimplemented using polling, or perhaps even better using mmap for at least the buffer header. Also another caveat is that I had to change the prototype of two functions that wanted a GInputStream *. These are internal for now so it isn't an issue. Any comment? Commit this change at will to GEGL when you think it has recevied enough polish. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] speeding up GEGL operations in GIMP
On Wed, May 14, 2008 at 8:14 AM, Sven Neumann [EMAIL PROTECTED] wrote: currently the GEGL operations in GIMP are very slow. I have done some basic profiling yesterday and it appears that the main problem is the conversion from floating point to 8bit. Here is where the most time is being spent. So it doesn't really make much sense to optimize the operations in GIMP or the point filters in GEGL. We need to look at the babl conversions first. Some of the extra overhead spent in the GeglOperationPointFilter base class has now been optimized away in a fast code path. The new code paths is markedly faster. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] gdb messages
On Tue, May 13, 2008 at 5:37 PM, Zhang Junbo [EMAIL PROTECTED] wrote: Hi, I'm just starting to write my code for gegl, I spent the whole day to debug but failed. My code(svn 2287) can be found on http://svn.gnome.org/viewvc/gegl/branches/branch_zhangjb/ . Here is some messages from gdb. The reason the code segfaults is that you are passing buffer of 32bit floating point to a function in the underlying library that expects 64bit floating point. The attached patch creates the needed pixel formats to represent 64bit buffers since babl doesn't know this format yet. The format could have been created with: babl_format_new ( name, RGB double, babl_model(RGB), babl_type (double), babl_component (R), babl_component (G), babl_component (B), NULL); and then referred to, I chose to just create it directly without giving it a name. If the fftw library has functions working on 32bit buffers it might be more suited for integration, if not I guess we just have to live with these larger buffers. I've attached a patch that makes the operation operate in 64bit like the function used. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ dftdiff Description: Binary data ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Color temperature correction GeglOperation
On Fri, Apr 25, 2008 at 6:52 PM, Jan Heller [EMAIL PROTECTED] wrote: I wrote it to better familiarize myself with Gegl and I am posting it here in hope it will be useful for others. I think it is a good operation to have, so I have commited a slightly modified version to svn. GEGL and babl deals with the out of gamut handling themselves at a later stage, during processing we preserve headroom and footroom. This allows us to change the contrast of the image to bring details back in later. The implemented gamut handling also seemed to introduce banding that the conversions in babl does not. It would also be nice to replace the planckian locus lookup table with a function that approximates it. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Scanline processing in a GeglOperation
On Tue, Apr 22, 2008 at 7:59 AM, Hans Petter Jansson [EMAIL PROTECTED] wrote: On Mon, 2008-04-21 at 20:36 +0100, Øyvind Kolås wrote: http://hpjansson.org/temp/meadow-dithered.png The picture has one bit per channel for a total of 8 colors, making it a true retro experience. From left to right -- original, thresholding, Bayer, F-S, covariant random and random dithering. This might indeed be useful at some point, but right now I do not think the GEGL architecture is flexible enough to warrant compilation and installation by default. Thus I will drop this .c file into the workshop directory where various works in progress reside. It is possible to write specialized ops that would read the RGBA u16 and output the required file. (Using R'G'B'A u16) would probably give slightly better results assuming the displays and data involved are roughly sRGB data. A plan for supporting pallettized images is forming somwhere on the horizon for GEGL. It would probably involve a specialized babl format and the ability to attache a floating point RGBA pallette to the format. Another similar issue for babl is that it isn't currently capable of generating pixels for formats where the components are not a multiple of 8, it is due to these short comings in GEGL I've placed color-reduction in the workshop for now. For some ramblings about indexed/palettized images take a look at: http://codecave.org/?weblog_id=indexed_metamers /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] compile failed with GCC4.0
On Mon, Apr 21, 2008 at 12:58 PM, lode leroy [EMAIL PROTECTED] wrote: (sorry, my previous mail was too fast...) Please svn up, should work in svn trunk now, I've changed the USE_GCC_VECTORS define to be possible to check with both #if and #ifdef. (I think this should work at least) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Scanline processing in a GeglOperation
On Mon, Apr 21, 2008 at 7:51 PM, Hans Petter Jansson [EMAIL PROTECTED] wrote:
On Mon, 2008-04-21 at 16:43 +0100, Øyvind Kolås wrote:
On Mon, Apr 21, 2008 at 11:18 AM, Øyvind Kolås [EMAIL PROTECTED] wrote:
Thus to correctly implement floyd steinberg you would actually have to
request the processing of the entire image and not piece by piece thus
losing the ability to handle larger than RAM images.
This isn't entirely true as you can fetch and store individual
scanlines when reading/writing from the involved GeglBuffers as the op
is processing for the entire image, nevertheless such an op would need
the entire image as source data to update the bottomrightmost pixel.
And it would make future scheduling and paralellization of graphs
involving such ops much harder than needed.
Yeah, that's what I thought. But insofar as my implementation is
concerned, I don't care about speed, as long as it can be done.
You need to do the following:
static GeglRectangle
get_required_for_output (GeglOperation*operation,
const gchar *input_pad,
const GeglRectangle *roi)
{
/* request that we have the entire bounding box to operate on */
return *gegl_operation_source_get_bounding_box (operation, input);
}
static GeglRectangle
get_cached_region (GeglOperation *operation,
const GeglRectangle *roi)
{
/* request that all of the op should be cached for this request */
return *gegl_operation_source_get_bounding_box (operation, input);
}
As well as setting the corresponding methods on the
GeglOperationClass, see other operations for examples.
At this stage:
The input and output regions requested for processing
should be the same and you can start reading/writing linear
rectangular subregions to the input buffer as well as writing results
to the output buffer. You could at this stage choose to do the entire
buffer in one chunk, this is where an intelligent implementation
allows to still work on larger than RAM images, while a stupid one
needs the entire memory temporarily in memory as a linear buffer.
So I guess the question is: How do I request processing of the entire
image, on a row by row basis?
If you look at the stretch contrast operation it is operating on a
line by line basis when it is doing the actual stretching (it is slow
though and allocates a huge linear buffer for the min/max detection
instead of doing it in chunks).
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] BABL path vs. reference fish
On Sat, Apr 12, 2008 at 3:53 PM, Jan Heller [EMAIL PROTECTED] wrote: attached is a path that introduces logic to disallow creation of a fish path that is actually slower than appropriate reference fish. Thank you for yet another contribution further cleaning up babl, the patch has been applied. One issue in babl's current design is that other activity on the system at the same time as measuring is performed can skew results quite a lot for a given conversion, not sure if there is a good way to deal with this at runtime though. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] BABL fishing patch
On Mon, Apr 7, 2008 at 5:31 PM, Jan Heller [EMAIL PROTECTED] wrote: attached is a patch that improves logic of go_fishing code in babl-fish.c. The current code searches list of all fishes while looking for suitable preexistent BABL_FISH_PATH instance. The new code only searches relevant part of database's hash table. Further, the current code searches for fish path every time such a babl fish is requested, even though the same fish path has been requested before and not found. The new code creates dummy BABL_FISH instance with appropriate source/destination formats and inserts it into the fish database to indicate that fish path has been searched for and not found. See comments in the patch for details. One thing you could do to improve the process of applying your already excellent patches for babl is to provide a draft ChangeLog entry as well. If you continue at this pace we might have to start working on getting you commit access to the svn repository. Thanks a lot for the good work thus far. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] BABL list API patch
On Tue, Apr 1, 2008 at 8:13 PM, Jan Heller [EMAIL PROTECTED] wrote: attached is a patch that introduces minimal changes needed for removal of the old list routines. It ports several lists to the new API and deletes the unused old functions. The patch has been applied. There are still several plain C arrays in the code used as lists, however, these do not depend on the old routines and are left untouched by the patch. I can try to identify and port these as well. This would certainly improve things from the readability point of view, although it wouldn't IMO do much about the speed of the code. Improving the readability in babl is probably important the code hasn't been properly handled in years, and it contains half implemented and thus unused features. Someone cleaning up and perhaps thinking about how to make babl do more of what it could be doing is very welcome. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL-0.0.16
GEGL 0.0.16 ⎺⎺⎺ GEGL is a graph based image processing framework offering non-destructive image processing and compositing on large images. GEGL is suitable for projects ranging from small one-off projects to interactive applications. Changes in this release ⎺⎺⎺ • Install headers for development of external operation plug-ins. • Added rowstride argument to gegl_buffer_set () • Made it possible for sink operations to do cunkwise processing through GeglProcessor. when processed using a GeglProcessor. • constification of GeglRectangles and babl formats. • Build and dist fixes, plugged annoying buffer leaks, GEGL now also works on OSX • New operations: stress, c2g, mblur, grey. • Reorganized operations directories. A new release of babl is also available, GEGL will work best with babl-0.0.20 or newer. This release appears due to contributions from: Øyvind Kolås, Étienne Bersac, Kevin Cozens, Sven Neumann, Manish Singh, Michael Natterer, Hans Brauer, Deji Akingunola, Bradley Broom and Tor Lillqvist. Where to get GEGL ⎺ GEGL and it's dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.20.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.16.tar.bz2 ftp://ftp.gimp.org/pub/glib/2.15/glib-2.15.4.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 ac3ac25c3d77bc1c812b64e843cac74287a50688 babl-0.0.20.tar.bz2 de262a29fc3c6c5fc1a436828044cf22756fb54b gegl-0.0.16.tar.bz2 dacc3f4c810e69677846a9414374fd68f9073cd2 glib-2.15.4.tar.bz2 Where to get more information about GEGL Information about GEGL can be found at the GEGL website http://www.gegl.org/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Build problems on OS X
On Thu, Feb 21, 2008 at 11:05 PM, Ettore Pasquini [EMAIL PROTECTED] wrote: On 2/20/08 5:51 PM, Ettore Pasquini [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 11:50 PM, Øyvind Kolås [EMAIL PROTECTED] wrote: GEGL has not yet been successfully built on Mac OS X, please upgrade to the vrey latest version and try again and report back whether it compiles succesfully or not. I wrote a blog post about that: http://cubelogic.org/act/building-gegl-and-babl-on-mac-os-x.html GEGL has now finally been confirmed to be working correctly on Mac OSX and we're closing in on the 0.0.16 release. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] article about gegl
On Thu, Feb 7, 2008 at 9:01 PM, Valent Turkovic [EMAIL PROTECTED] wrote: I'm interested in writing an article about gegl. I can't find much information online so I came to the source. What has happened with gegl project in past 2 years? I saw this article: http://www.digg.com/linux_unix/The_GIMP_s_next_generation_imaging_core_demonstrated and I see that your site hasn't changed much since it was written so if somebody would be interested for few quick QA that would be great. The best source for information about GEGL is probably the ChangeLog and NEWS files in the subversion repositories of GEGL and GIMP. As well as peering into bugzilla to see what issues are open. Interviews tend to take away time that most often could be better spent improving code or internal project documentation. Feel free to ask further questions on the mailing list after looking through the pointers provided, a timely response is not guaranteed though. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Split Result?
On Jan 30, 2008 9:46 PM, Ferran Basora [EMAIL PROTECTED] wrote: the operation that I am creating renders a simple gradient from 0 to image width but in the middle of the image ends the gradient and starts again to the end of the image. I don't understand the reason. You probably want to look at either the mandelbrot or the checkerboard operations and how they deal with coordinates. Be aware that the operaiton will be asked to render a subrectangle (with an x,y offset as well) and not it's entire output in one pass. This applies to all operations and is due to GEGL supporting processing and generation of images larger than system RAM as well as that this design constraint will enable a future version of GEGL to be performing paralell processing. The API for writing operations is still settling, I hope you are looking at the latest version in SVN and not the last released version, since there has been considerable amounts of changes recently. (The next release of GEGL will be the first release where header files for writing custom operation plug-ins will be installed.) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL doubts
On Jan 11, 2008 5:05 PM, Ferran Basora [EMAIL PROTECTED] wrote: Nowadays, I think that all people that works with GIMP have a 3D Graphic card. It could be possible to integrate some of GEGL operations with the OpenGL library and delegate a part of work to be faster? For example, rotate, transform, blur, mask operations. Some operations of GEGL can potentially be accelerated by the means of a GPU. Accelerating things directly with OpenGL is not possible since OpenGL gives no warranties about the precision of the resulting rendering (it just has to look good enough). GEGL on the other hand aims for high precision rather than performance in it's output. It might be viable at some point in the future to add fast paths to GEGL that use GLSL or similar fragment shaders to do some of the work. One of the main issues with accelerating these things with a GPU is that moving data from the system memory to the graphics memory and back is slow. Another problem is that you restrict the portability of the software severely. Thus you will often end up with a problem if some of your operations are GPU accelerated and some are not, the net effect might be that the end result is slower than a pure software implementation. The only way I see it as viable to add usch acceleration to GEGL is to add optional fast paths in addition to the reference code already existing in C. This will be the same route GEGL will go down in accepting 8bit, 16bit, MMX, SSE and similar optimizations as well, they will be in addition to the sofware based floating point operations and it shall be possible to disable their use if they do not achieve sufficient precision. Another thing that GEGL currently is lacking but it will most certainly get support for before GPU based acceleration is proprly considered is other forms of parallellziation, two, four, eight and eighty cpu cores are things that seems to become more and more wide spread. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Gegl questions
On Jan 6, 2008 6:43 PM, Patrik Östman [EMAIL PROTECTED] wrote: To exemplify. If you want to make a fast preview by applying an operation on a scaled down version of an image, do you have to use separate graph representations for the scaled down version versus the full size image meaning that you need a scale operator in one of graph paths or will this be managed by the mipmap buffers and using the scale parameter in the blit-function. Meaning that the operation is only performed on the mipmap scaled version that is closest to the choosen scale. GEGL doesn't already do this in an efficient manner, but some of the infrastructure to do so is present, and the public API has been designed with such usage in mind. Some of the things that haven't received proper attention yet is how to deal with spatial properties for the ops. Blur radiuses need to be scaled, has issues with such operaiton, traditional convolve operations are only defined for a 1:1 pixel grid etc. Do note that GEGL doesn't do such optimizations yet, and GEGL is still in a state where the public API is very close to be declared ready while the internals will probably see quite a bit of refactoring to enable optimizations like the one you describe here as well as other optimizations. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Gegl questions
On Dec 12, 2007 7:50 AM, Patrik Östman [EMAIL PROTECTED] wrote: - The main idea of gegl is that you can build up graphs of nodes and that you decide when to process the graph. You are also able to specify a region, scale and output format. To get the best performance I guess that cropping and scaling is done early in the process stage. Correct? And is this true for all operations? Cropping should not be a problem but can imagine that scaling may cause problems for operations like filters there you have to adapt the filter to get the same effect as for a none scaled image. By requesting a subregion to be rendered, the minimal required regions to be computed for every node is first computed in a first pass (expanding as needed for context for blurs, and restricted by crop operations present in the graph.) Moving scaling to be performed as early as possible is something that has been considered but currently is not done since it would be in conflict with the per-node caches. - If a graph is processed and an operation is added to the graph I guess that when reprocessing the graph the cache of the previous rendering is used. This means that only the new operation is processed. But what if you have rendered the graph using different scales and regions, do you have separate caches for different render options? As mentioned there is only a single cache, but the buffers these caches are built on have built in capabilities for mipmap scaling. These things are not mentioned in detail on the webpage because they are things that might change for the better in the future independently of the public API. Another key element you didn't touch upon is parallellization of the processing which is also related to such future internal developments, please examine the GEGL bugzilla for some information on ideas in this regard. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Performance of GEGL
On 10/9/07, Lavergne Thomas [EMAIL PROTECTED] wrote: Hi, I've just installed GEGL and BABL and started to do some test. For example the following code : So does any of you have an idea about what can cause this slow down ? GEGL is still going through architectual level internal refactoring even though the public API haven't changed much lately. The slow down can come from quite a few different places, and it might even be slower if you try the SVN version since it is in, and has been in for a while, a intermediate state where a new caching framework is being integrated. If babl's extensions aren't being automatically picked up the interpolation that happens during affine transformations will be slower as well. To figure out where time is spent set the environment variable GEGL_DEBUG_TIME to some value and study the output, the results of which is meaningless for the last released version since the affine (scaling) operations has been significantly changed; as well as for the SVN version since there are some semi-known issues with the still fresh caching code. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Shortcoming in API or behavior of gegl_node_blit and gegl_buffer_get
On 9/16/07, Martin Nordholts [EMAIL PROTECTED] wrote: Øyvind Kolås skrev: [...] The rowstride should probably be added to gegl_buffer_get as well, keeping the current behavior of letting 0/-1 denote a default rowstride of bytesperpixel*width. Any comments? /Øyvind K. Just a little comment; to increase code readability I think a symbolic constant like e.g. GEGL_DEFAULT_ROWSTRIDE should be provided by the API for passing to functions when a default rowstride is desired. I suspect that's what you intended, just wanted to mention it. Perhaps #define GEGL_ROWSTRIDE_AUTO 0 Describes the meaning even more precisely, since it would be computing the rowstride based on the buffer width and the requested pixel format. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] stretch-contrast crash, Fourier transform, some questions.
On 8/15/07, Håkon [EMAIL PROTECTED] wrote: snip to stretch-contrast.c fixed it. This change has been committed. - I'm trying to implement a Fourier transform filter in GEGL. It uses RGB images with the real part of the complex numbers stored in red, and the imaginary part in green. This should allow for some interesting things, like implementing a frequency filter like this: Fourier processing is interesting, but not something I've put a lot of thought into myself. - Some questions: I guess storing complex data is a slight abuse of the RGB model... Are there any caveats in having negative or excessively large values in pixels? As long as it is not being passed through an operation that requests 8bit data there is no problem with neither negative nor very large RGB values, in fact this is explicitly supported to allow both high dynamic range imaging, as well as wide gamut RGB buffers. Could one have pads other than 'input', 'aux' and 'output', for things like composing/decomposing to channels? Yes, but then you can no longer use the nodes in the basic manner that is currently offered by the XML format. One operations that currently diverges from the normal set of inputs is operations/color/remap.c which takes three inputs. You'll also notice that this file is quite a bit more verbose, this is because it cannot use the preprocessor tricks employed by the more normal operations. To use such operations currently you have to construct the graph manually using the C/ruby/python APIs directly. The XML format should be extended to allow specifying meta operations (like drop-shadow and unsharp-mask) using XML files instead of .c files, the bug tracking this issue is: http://bugzilla.gnome.org/show_bug.cgi?id=465743 Can you have several versions of a node, taking different formats? Currently not, at the moment each operation (the actual processing of the node) requests the data, and babl is used behind the scenes to convert the data to the desired format. At a later stage, multiple implementations of operations might be possible to register. - I guess this is already known, but the GEGL tool currently exports XML with a '/' erroneously prepended to relative layer paths. The XML format isn't considered stable, but this sounds like a bug, could you please file a more throughout description of the issue in bugzilla? /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] Shortcoming in API or behavior of gegl_node_blit and gegl_buffer_get
The main rendering functino of GEGL is gegl_node_blit, gegl_node_blit is in essence a wrapper around gegl_buffer_get (), with a GeglNode instead of a GeglBuffer, a currently unused rowstride of the destination_buf, and the GeglBlitFlags describing the caching behavior desired. The rowstride should probably be added to gegl_buffer_get as well, keeping the current behavior of letting 0/-1 denote a default rowstride of bytesperpixel*width. void gegl_node_blit (GeglNode *node, GeglRectangle *roi, gdoublescale, Babl *format, gint rowstride, gpointer *destination_buf, GeglBlitFlags flags); voidgegl_buffer_get (GeglBuffer *buffer, GeglRectangle*rect, gdouble scale, Babl *format, void *dest); If the rowstride is going to be used it should be present in gegl_buffer_get as well. The real problem is using either of these as the primitive to build a zoomable panable display. Both of them are implemented in such a manner that the GeglRectangle (x,y,width,height) specifies the integer coordinates of the upper left corner to be rendered to the linear buffer as well as the width and height of the linear buffer and the scale argument specifies the scale to be used during rendering 1.0 == 1:1, 2.0 means that each source pixel becomes a 2x2 block of pixels etc. Using this API it isn't possible to request rendering of arbitrarily positioned buffers since the upper left pixel will always be fully rendered with the upper left edge at integer coordinates. Changing GeglRectangle to use floating point coordinates doesn't feel like a solution since almost all other places where GeglRectangles are used in GEGL it does literally mean a region of a raster in integer coordinates. Adding horizontal and vertical offsets to the functions would clutter the API quite a bit. What I think might be the best option will be making the scale be applied to the buffer before the rectangle is taken into account at all, and let this GeglRectangle specify integer coordinates of an already scaled buffer making the region rendered be (x/scale, y/scale, width/scale, height/scale). Any comments? /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Float/Curve patch
On 5/22/07, Mark Probst [EMAIL PROTECTED] wrote: Here's a small patch that corrects the floating point I/O problem for the curve and makes the contrast-curve operation use the curve instead of the object param type. Committed, one adjustment to how you create patches that would making commiting the patches easier is if you included an entry for the ChangeLog as well. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Curve - First iteration
On 5/18/07, Mark Probst [EMAIL PROTECTED] wrote: On 5/17/07, Øyvind Kolås [EMAIL PROTECTED] wrote: Speaking of color to gray scale, be sure to test the c2g operation also in the workshop. My first impression: With the default value of 3 samples it produces way too noisy images, even from very clean input. I'll play around with it more when I get to my application. Am I right in assuming that it's an implementation of the color2gray algorithm? The color2gray, it is a color2gray algorithm, and I would recommend increasing the number of iterations instead of increasing the number of samples. Think of running it with a low number of a iterations as a preview of the results of multiple iterations. (the method is work in progress and we're rtring to keep the implementation simple, rather than engineer ad-hoc noise reduction capabilities into it at the moment.) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] OCRopus and Gegl
On 5/18/07, Étienne Bersac [EMAIL PROTECTED] wrote: Hi all, You may have heard about OCRopus project launched by Google last month. As a developer of gnome scan, this is the project i needed for OCR. I wonder how it is possible to plug it as a GeglOperation. I mean, is GeglOperation intended for such features ? Sure, but such an operation would probably best ship with gnome scan initially, and perhaps be moved over to the core GEGL distribution if at a later point it is deemed to be generally useful. To speed the process toward getting a stable operation API, helping out with cleaning up and refactoring the existing Operation API as well as cleanups within the core would be welcome. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] CMYK and GEGL
I do not know when support for CMYK in GEGL will be added, but the initial support will most probably be as described below, and it can be added without being intrusive on the current code. The various tasks that needs to be done should probably be filed against GEGL as separate enhancement requests in bugzilla. GEGL itself at the moment focuses mostly at mixing and processing High Dynamic Range additive RGB light. When introducing CMYK subtractive mixing will be added but initially only for export purposes. The following new operations would be desirable: It should be possible to transform buffer data to CMYK buffers by supplying an ouput profile and a rendering intent, as well as rendering a mask indicating out-of-gamut colors. Both of these tasks will be implemented as operations. And should provide a core set of functionality allowing some control over generated CMYK values, and for most uses sufficient control. These operations will need some changes and additions to the GEGL code most specifically a ICC profile property on GeglBuffers that is propagated correctly through the graph. When matching colors in a print job between rasters originating mainly in photographs with CMYK vector graphics, it would be advised to use a color picker on the written output CMYK file intended for inclusion in print. Since if painting is done on RGB buffers in this model with colors picked in CMYK, the information about the black seperation in the user specified CMYK values is lost. It should then be possible to add CMYK specific operations, as well as making the existing internal ones CMYK aware. For some operations where abstracting away the number of colorant components, it might be desired, but in most instances I would argue that it adds unneeded complexity to the code. Being able to preview the range available, perhaps even using perceptual compression of values for display. The operations could perhaps be structured as follows: apply-profile - apples a color profile to a buffer, should be followed by an operation that expects CMYK data if the buffer has been converted to CMYK in the process to avoid information loss. properties: profile - ICC-profile intent - absolute colorimetric, relative colorimetric, perceptual. convert - boolean value, convert image default value is TRUE. gamut-distance -- generate a gray scale map indicating how far outside the gamut boundary a color is. properties: profile - ICC-profile being converted to. A sample chain of operations taking a photo from a raw file, and making a sharpened CMYK file tagged with a profile. load path:rgb.raw apply-profile profile:mycamera.icc convert:false apply-profile profile:sRGB convert:true auto-levels unsharp-mask std-dev:3.0 amount:0.2 apply-profile profile:swop.icc convert:true save path:cmyk.tiff /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Operations that I require
On 5/10/07, Mark Probst [EMAIL PROTECTED] wrote:
Ok, so here's my mono mixer, implemented as a generic filter.
Looks good, the filter plug-in API headers are not installed yet, this because
there will be changes made to it, already there have been changes to
the GEGL tree causing your filter not to compile with SVN trunk.
if ((result_rect-width 0) (result_rect-height 0))
{
gint num_pixels = gegl_buffer_pixels (input);
Replace this with:
gint num_pixels = result_rect-width * result_rect-height;
or use:
gint num_pixels;
g_object_get (input, pixels, num_pixels, NULL);
The function gegl_buffer_pixels was removed as gegl-buffer.h is being
prepared to be made more public.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Operations that I require
On 5/8/07, Mark Probst [EMAIL PROTECTED] wrote: Hi! I'm trying to implement a B/W processing application using Gegl, similar to my B/W Photoshop workflow: http://schani.wordpress.com/2006/05/23/my-digital-bw-workflow/ There are several operations that I need which, as far as I can tell (I'm completely new to Gegl), are not supported, directly or indirectly: * Channel Mixer. What it does is it generates a B/W image out of a color image by calculating a weighted sum of the color channels. There is no real equivalent to a Channel Mixer operation at the moment. * Gradient curves. I want to give the user a curve control to modify the contrast of the image, like the Curve filter in GIMP/Photoshop. There is no curves control either, the closest would be levels. Both of these are point operations and would live in the gegl/operations/color/ dir. The Channel Mixer is probably the one that would be easiest to implement. For a curves operation the main issue is how to pass the curve to the operation, there currently is no operations in GEGL that take an array of values as a parameter; thus you should probably bypass the gegl-chant mechanisms and write all the needed boilerplate yourself gegl/color/remap.c is an example of one operation that does this for other reasons. When it comes to how an array of values are best expressed, there probably are some examples in GIMP plug-ins. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Segmentation Fault at initial run
On 3/20/07, Kerem Kat [EMAIL PROTECTED] wrote: Hi, I checked out babl and gegl from svn and compiled them on fedora 6 with autogen.sh , but without success to run. gegl: rev. 1436 babl: rev. 230 When I run the gegl binary, it gives the following: WARNING **: Failed to set operation type for nop, using a passthrough op instead This mean that GEGL has failed to find any of it's plug-ins, you probably want trying to set the environment variable GEGL_PATH to point to the location where the .so's of the operations ended up being installed and make another attempt. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Segmentation Fault at initial run
On 3/20/07, Øyvind Kolås [EMAIL PROTECTED] wrote: On 3/20/07, Kerem Kat [EMAIL PROTECTED] wrote: Hi, I checked out babl and gegl from svn and compiled them on fedora 6 with autogen.sh , but without success to run. gegl: rev. 1436 babl: rev. 230 When I run the gegl binary, it gives the following: WARNING **: Failed to set operation type for nop, using a passthrough op instead This mean that GEGL has failed to find any of it's plug-ins, you probably want trying to set the environment variable GEGL_PATH to point to the location where the .so's of the operations ended up being installed and make another attempt. It seems like I responded a bit prematurely, there has been changes recently to make GEGL and babl work on win32, these seems to have broken the build on Unixes right now. I do not have the immediate time available to look into these issues right now, unfortunately this leaves us with broken trunk revisions, the changes to make it work again shouldn't be very large though. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Tiles Buffer and Pyramids question
On 3/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: hello, when brouwsing trough the bug reports Bug 378115 got my attention. I'm trying to figure out hou the buffer and tile's interact with each other. It seems to me that depending the call of gegl_buffer_get_scaled one pyramid level is calculated. Is there realy a image pyramid? Should the image pyramid not be included in the tiles? (As a consequence this would increase the tile size to 1 + 1/3.) When gegl_buffer_get_scaled is called the tiles needed at the level to satisfy the request is computed (and cached). Thus the tiles are generated on demand (and cached for later use). Level 0: is the base level, this level always exist (as things are currently implemented). Level 1: the tile size here is the same as tiles of the ones on level 0, but contains data from 4 tiles on level 0. Level 2: one tile consists of data from 4 tiles on level 1. This tile generation happens automatically within the tile architecture, gegl_buffer_get_scaled just requests tiles at the appropriate level, and retrieves either cached tiles or makes the tiles needed be generated. When tiles for level 2 is requested, tiles on level 1 are created and cached as well if needed. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] GEGL 0.0.12
GEGL 0.0.12 ⎺⎺⎺ GEGL is a graph based image processing framework offering non-destructive image processing and compositing on large images. GEGL is suitable for projects ranging from small one-off projects to interactive applications. Changes in this release ⎺⎺⎺ • Swapping out of image pyramid. • Speedups to text rendering. • GEGL compiles on win32 • GEGL_SWAP now specifies swapdir location. • Small refactorings of public API. • Changed the XML parser/serializer to not use attributes for node properties. • Improvements to documentation. • Automagic build environment for operations simplified. • Internal API for saving/loading GeglBuffers to/from disk. • Ruby, C# and Python bindings added to version control system (not included in distributed tarball) A new release of babl is also available that fixes the reference conversion from premultiplied to non-premultipled data making it work on platforms where the dynamically loaded performance extensions do not work yet. Contributions from: Kevin Cozens, Øyvind Kolås, Sven Neumann and Michael Schumacher. Where to get GEGL ⎺ GEGL and it's dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.14.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.12.tar.bz2 ftp://ftp.gimp.org/pub/glib/2.12/glib-2.12.9.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 fd344360c7ae900a4610951cd3dee855c2298f21 babl-0.0.14.tar.bz2 5d1e3b1a13d696fda4c9ca01df28435e58fb882f gegl-0.0.12.tar.bz2 387da30929047ef88a6f369831a34f41a3d027f7 glib-2.12.9.tar.bz2 Where to get more information about GEGL Information about GEGL can be found at the GEGL website http://www.gegl.org/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] (no subject)
On 2/8/07, cazaciuc gabriel [EMAIL PROTECTED] wrote: I want to give a little help to the development of gegl. Which is the recommended method to get started? You've already started that by attempting to build it locally from source ;) What are the operations that are considered usefull to be implemented? At the moment I would not encourage people to write tons of new operations. Documenting and re factoring the internal architecture should happen before the amount of operations using internal API's explode. This is also the reason GEGL is not currently installing the headers needed for plug-in/operation development that API is not stable yet. Another thing that would be useful is using the GEGL API from C, ruby or python (a new incarnation of the python bindings will be announced soon). To test the API and give feedback on the current shortcomings. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] New to GEGL, and HSL plugin
On 2/4/07, Sven Neumann [EMAIL PROTECTED] wrote: HSL layer modes have been requested for GIMP (see bug #401754 and also bug #404378 for another request that deals with layer and paint modes). It might make sense to consider adding these to babl/gegl. I'd rather add CIE Luv and use that in place of HSV/HSL. Adding HSV/HSL to babl should be a matter of writing an extension, but the slightly more perceptual CIE color space is probably more desirable. Ideally all possible candidate color spaces will be possible to use but implementing the saner ones first should be a priority. GEGL currently contains a large enough amount of plug-ins that changes to the API they use take time. It is expected that this API will go through considerable refactoring and thus getting a lot of new plug-ins into the main distribution is not desirable as it will make the refactoring take more time. This is part of the reason I want to be conservative with which plug-ins are added. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Core Features
On 1/30/07, Konstantin N.Kozlov [EMAIL PROTECTED] wrote: I have just subscribed to this list and would like to say Hello to everybody. I am working in the field of systems biology and my work includes processing of images and writing software for it also. I have several questions to the developers about the core features of GEGL. Can the node have several input and output pads? And can it have zero number of input or output pads? The current architecture allows both several input and several output pads, though some internal restructuring/maintenance might be needed to support multiple output pads correctly throughout the system. There are nodes that load/produce image data that have no inputs, as well as nodes that store image data (the png-writer for instance) that have no output pads. Where is the result of node execution stored - in memory or in temporal storage on disk? Out of the box GEGL swaps tiles to RAM, by setting the environment variable GEGL_SWAP to any non-zero value it will swap to disk instead and has in such a manner been successfully used for image processing on 12GB image rasters. There are several software packages that use DAG to store the list of operations called workflows or workspaces namely VisiQuest, TiViPe, SCIRUN, SIVIL and probably Matlab/Simulink. The image processing tools and api for nodes/connections are usually separated. What is the reason to put them in one library? Because they are closely connected, image processing operations in GEGL do not necessarily work on the entire image buffers but on the smallest possible sub rectangles needed to compute a desired region of interest. It is also possible to do other optimizations like reordering of operations, changing of parameters according to scale level etc. Are there plans to implement distributed processing? This is planned, the first step will perhaps be multiple threads (or processes on a single machine). The tiled buffer architecture of GEGL is designed with network distributed read/write access in mind. When multi-threaded/distributed processing becomes possible the aim is that this should happen without changes to the public API. Thus existing tools built on top of GEGL should automatically get the same capabilities without any code changes. Are there any efforts to implement visual programming environment for creating and editing DAG with GEGL? Right now the closest thing is the tree based test app the comes with GEGL. It implements a proxy between the graph and a tree (which allows clones, but not editing of them yet). A tree with clones can represent any DAG as long as you do not allow multiple output pads for any of the nodes. (all nodes have a single output pad). I've got an old graph editor[1] from the gggl[2] project (gggl has now been assimilated by GEGL). Which I probably will resurrect at some point. Thank you for your interest. /Øyvind K. 1: http://people.freedesktop.org/~pippin/cairo/bauxite_0_86.png 2: http://pippin.gimp.org/gggl/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Little GUI thought
On 1/10/07, Piotr Stopniak [EMAIL PROTECTED] wrote: I was just doing some work in Photoshop which involved multiple layer sets that had to have the same opacity and it was a pain to change them all each time so I had this idea that you could define global variables or, in the DAG paradigm, simple scalar nodes you could hook up to drive values in many layers/nodes from one location. Could be an interesting thing for the GUI: a variable list/editor. GEGL itself has no GUI since it is a library/framework that applications can use to drive the rendering of both graph based GUIs as well as other approaches. The GUI that comes with the GEGL distribution is a code sample/sandbox for developers to test plug-ins, as well as a way to test the current performance of the GEGL engine it is not, at least at the moment; aiming to become a useful tool for end users. For that you would have to wait for GIMP to integrate with GEGL or perhaps other applications built on top of GEGL to emerge. In DAG based GUIs the ability to use scalar values in the graph is common. The GEGL architecture has supported this in the past but it is possible that recent changes has made that ability disappear temporarily. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] GEGL 0.0.6
On 1/8/07, Øyvind Kolås [EMAIL PROTECTED] wrote: A new GEGL release a short time after the first, it should now build or be closer to building on more systems. Work is underway to make it possible to use GEGL from both python and ruby. A preliminary ruby binding can be found at http://pippin.gimp.org/rgegl/. Note: Do _NOT_ upgrade babl to 0.0.10 unless you are trying to make it build on Win32, since it contains a serious regression that should never have been let sneak into a released tarball. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Platform support and caching
On 10/22/06, Rasmus Bonnedal [EMAIL PROTECTED] wrote: 1. I have found no list of supported platforms so I tried to build it on Cygwin but it fails because of differences in the dynamic library mechanism between Windows and Linux. Are there any plans on Windows or Cygwin support? People who care about win32 will have to do that work, I do not care; and in my opinion there is no hurry to make it work on that platform. 2. When trying simple tests it seems to me that there are mechanisms present for caching the results of an entire filter chain, but no caching between nodes. What I would like to do is something like this: Image Loader - Expensive Filter - Cheap Filter - Result Then I would like to change parameters on the cheap filter without having to recalculate the expensive filter over and over again. Is this behaviour possible in the current gegl framework? This is something I do care about, and I am currently working on monitoring the graph and properties for changes to compute the bounding box of the region that needs recomputation when things have changed. This coupled with caching similar to what you describe (and also described in http://bugzilla.gnome.org/show_bug.cgi?id=357261 ) should speed up interaction speed. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] DAGs make users' eyes cross
On 10/17/06, Ken Bateman [EMAIL PROTECTED] wrote: I've independently been thinking of a similar imaging core for the last month or so. Of course, I think it's a good idea. Logically, behind the scenes, everything should be in the form of a DAG. But I think that a raw DAG does not make up a part of a good user interface. The current user interface used in the prototype GUI of GEGL is an abstraction above the DAG that is a tree with clones. This allows expressing all DAGs that have sources (one output) filters (one input and one output), composers (two inputs and one output). This is the interface model I used in bauxite[1] , with the added ability to make some of the nodes in this tree be embedded graphs I think you have the best of both worlds. It shold also be noted that one of the operations in GEGL at the moment is the layer, which is a composition of over (or another compositing operator), translate and opacity. Spreadsheets are in essence a DAG for performing numerical calculations, and I would suggest that the user interface should take the form of a spreadsheet since this is a model familiar to many users. Some cells would contain source rasters, other cells would contain paths, vector graphics, or masks (or even references to other functions), some cells would contain a function that referred to other cells for inputs, some cells could contain labels or comments, and most cells would be empty. Such a user inteface does not lend itself well to a user that wants to do image manipulation in the manner traditionally done by users of GIMP, an application that does something along these lines is nip2[2] the interface of the vips projects. 1: http://pippin.gimp.org/bauxite/ 2: http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2 /OEyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Proposition : GeglInterpolator
On 10/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you scale a image to 10% of the original size using cubic, you have a situation where the data for each destination pixel is taken from a region of 4x4pixel, whilst it should at least be taken from a region of 10x10pixels, 84% of the image data is thrown away. OK, the handling of scaling down is not yet in the proposition Could we not just add the scale factor to the API ? The scale factor is not enough, if we scale it to 10% horizontally and 70% vertically (or add some kind of rotation as well). A fixed scale factor would no longer be correct. Doing a reverse transform of the corners of the destination pixel would give us all the information we need, and work for perspective transforms as well, hence the method I suggested. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
