Re: [Gimp-developer] Recent Gegl-0.1.7 build fails
On Sat, Jun 4, 2011 at 12:14 PM, Partha Bagchi wrote: > I tried again. The error still persists: > > gegl-buffer-save.c: In function 'gegl_buffer_save': > gegl-buffer-save.c:227: error: 'S_IRGRP' undeclared (first use in this > function) > gegl-buffer-save.c:227: error: (Each undeclared identifier is reported only > once > gegl-buffer-save.c:227: error: for each function it appears in.) > gegl-buffer-save.c:227: error: 'S_IWGRP' undeclared (first use in this > function) > gegl-buffer-save.c:227: error: 'S_IROTH' undeclared (first use in this > function) > gegl-buffer-save.c:227: error: 'S_IWOTH' undeclared (first use in this > function) > make[4]: *** [gegl-buffer-save.lo] Error 1 That is the same error, but elsewhere, if you provide git formatted patches fixing such issues I will integrate them with GEGL. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposed patch for bug 335975
On Tue, May 31, 2011 at 11:31 PM, Dominic Canare wrote: > I think I was unclear about my misunderstanding, and maybe I was unclear > about what my proposed patch does. > With the proposed patch, GIMP can export a layered image as a single, > multi-image TIFF file. That is to say, each layer in the original will be > saved as a separate image (or "page", if you prefer) WITHIN the TIFF file. > > I hope I've cleared up any confusion. If not, hopefully you can clear up > mine. I don't understand the difference between a "multi-layered" tiff and a > "multi-image" tiff. Just to chime in on other software that also likes multi layered TIFFs,. hugin the free software panorama stiching tools (or at least some of the components it is built from) prefer such a format. If there really is one preferred way of doing this with TIFFs - I think should welcome a patch that implements it. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Recent Gegl-0.1.7 build fails
On Wed, May 25, 2011 at 9:38 AM, Partha Bagchi wrote: > Thought I would mention it here. When building GEGL (downloaded from > ftp://gimptest.flamingtext.com/pub/nightly-tarballs/ at 5:35 EST), I > am getting the following error: > > gegl-buffer-save.c: In function 'gegl_buffer_save': > gegl-buffer-save.c:227: error: 'S_IRGRP' undeclared (first use in this > function) > gegl-buffer-save.c:227: error: (Each undeclared identifier is reported only > once > gegl-buffer-save.c:227: error: for each function it appears in.) > gegl-buffer-save.c:227: error: 'S_IWGRP' undeclared (first use in this > function) > gegl-buffer-save.c:227: error: 'S_IROTH' undeclared (first use in this > function) > gegl-buffer-save.c:227: error: 'S_IWOTH' undeclared (first use in this > function) > make[3]: *** [gegl-buffer-save.lo] Error 1 > > I noticed that this bit of code has changed from a previous tarball > that I downloaded before. On what platform/distribution/compiler do you get this? (these constants can be replaced by a numeric constant though; but it would still be good to know where this does not work.) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl-vips
On Sun, Apr 17, 2011 at 9:40 PM, wrote: > On 17 April 2011 14:24, Øyvind Kolås 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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl-vips
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, 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/16bit <-> float conversions would likely improve this type of benchmarking. 16bit output: real: 28.3s user: 26.9s 8bit output: real: 25.1s user: 23.6s Thank you for looking at this - and I do hope my comments above help explain some of the reasons for the slower processing. /Øyvind K. -- «The future is already here. It's just not very evenly distributed
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
On Sat, Apr 2, 2011 at 3:24 AM, Jim Michaels wrote: > help me to understand. GIMP plugin authors will now be required to write > their plugins in GEGL? GIMP has for a long time (decade) been moving towards using GEGL for it's imaging core. GEGL plugins do support higher bit depths like 16bit and 32bit floating point/high dynamic range. As of GIMP 2.6 you can already use GEGL operations in place of GIMP plug-ins with the GEGL tool, but GIMP has not yet migrated its storage of actual raster layer data to GEGL. There might in the future be a GEGL operation that permits running legacy GIMP plug-ins in a an "emulator" such emulated execution will however be rather destructive to higher bitdepth images as well as for strictly color managed workflows where the 8bit limitations will be leading to data/precision loss. > as of what version of GIMP, if anyone knows? Hard to tell, but the actually useful plug-ins, and in particular the ones shipping with GIMP should be migrated, to gain benefits like on canvas preview, multi-threading and more. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
On Fri, Apr 1, 2011 at 9:55 PM, Marek Rogalski wrote: > Hello, everybody. > I have a quite simple proposal for this year GSoC: make a nice editor > for GEGL pipelines. > > Why do we need it: because the GEGL eats XML files. GIMP could eat > them too. It would introduce much greater reusability in the work of > designers. > > Who will use it: graphic designers (who else? :p). The concept of GEGL > operations is sufficiently simple to be used even by casual users. > > How it could be used: GIMP could show a list of GEGL XML files that > can be applied to current layer. Very similar to how the filters are > exposed right now. The editor itself could be located in GIMP (I would > like that :) ) or as a separate program. The meta-operations should be loaded from XML definitions and not defined in C, allowing such an editor to program composite filters, that effectively will replace many of the current uses of script-fu in GIMP. For instance the logo scripts and quite a few other such scripts should be possible to easily reimplement as meta-ops visually with such an editor in place. See https://bugzilla.gnome.org/show_bug.cgi?id=465743 for a bug tracking the long standing desire to load these ops from XML instead of hard-coding them in C. > Request for comment: > - what do you think of the whole idea? Would it be useful or not? It would defintely be useful. > - should it be merged with GIMP or work standalone (or both :) )? Making it work stand-alone first is probably best, a stand alone tool would also allow easier testing of GEGL operations (GEGL used to ship with a tree based editor UI sandbox (http://pippin.gimp.org/tmp/gegl-foo/) that I removed since the code was scraped from somewhere else and rather ad-hoc.) If a good graph editor surfaces, GIMP might be interested in incorporating portions of it in some way, but it would defintely be useful on its own as well. > - what gui toolkit would be appropiate? GTK or Clutter? > (I fell in love with clutter, but there may be reasons not to use it > for such program) If the program is stand-alone, the choice would be up to the implementor ;) > Other ideas: > - shebang at the beginning of the GEGL XML - drop files on the script > and get them processed > - automatically generate GtkBuilder XML for marked parameters of GEGL > operations - could > be used to display filter-like dialogs of arbitrary GEGL pipelines. Generting XML is not neccesary, both the GEGL tool in GIMP and the sandbox I linked to were generating their property editors on the fly based on inspecting the GParamSpecs. Going through GtkBuilder XML might not neccesarily be easier than building the UIs only in code. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
On Sat, Apr 2, 2011 at 12:00 AM, Nicolas Robidoux wrote: > Since GEGL structures its operations in tree form, what you may want > to think about is that you want to display a tree in a form > understandable by a user. GEGL does not structure operations in a tree form but as a graph, the XML file format of GEGL uses a tree with clones. Both are valid options, though there are some types of graphs that might be desirable that are not possible to express as graphs. For an editor for meta-operations (like unsharp mask, dropshadow etc. a proper graph editor could be mose suited.) > My personal take is that there probably is a topological sort > algorithm which "effortlessly" leads to an easy to understand > description of the tree in list form. (This list could then be broken > up in "sublists." GEGL already does this topological sort when saving the in memory graph structure out to the tree in XML. But that does not have to impinge on how a UI is done. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira wrote: > Hello everyone. My name is Victor Oliveira. I'm a master's student at > the School of Electrical and Computer Engineering - University of > Campinas, Brazil. > > I work with Image Processing and Machine Learning and I've been using > GPUs (CUDA) in my work since 2009. More recently, we've migrated our > projects to OpenCL, which has given me more experience with GPU > programming. I have a strong background in C/C++ and Python. > > Also, I've been using GEGL for some time in my projects. I noticed a > while ago that there is a branch > [http://git.gnome.org/browse/gegl/tree?h=gsoc2009-gpu] that wasn't > merged in GEGL's main tree. > > If I understood it correctly, this specific branch is able to do > pixelwise operations using OpenGL shaders and automatic memory > management beetween the cpu and gpu. My idea is to use this memory > management scheme to allow gegl operations with OpenCL. I've already > presented this idea in #gegl without further details and I'd like to > discuss it here. If moving to OpenCL, (and if OpenCL needs separately managed memory; which I think it does) basing it on the existing unmerged GPU branch would be the best plan moving forward. The general gist of the work that was done in the previous gsoc was to extend GeglBuffer with the ability to have a separate, internal backend/cache of gpu side tiles, that have their own revision; when tiles are requested either on the gpu or cpu side, migration is done automatically to ensure that the newest version is used. This management scheme was succesfully implemented for GLSL based shaders and proof of concept implementations of some point operations were done. Repeating the things that were done in this gsoc for OpenCL should not take as long as it did for the original GPU branch since a lot of the issues would already be solved. If core color correction, compositing ops and gaussian blur have vfuncs for GPU side processing; many simpler compositions would be possible to do fully on the GPU - while compositions with some cpu based ops would do the migration back and forth as needed (with incurred performance impact). Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). One thing that could be interesting to do is to make it possible to turn on a runtime flag that tests the OpenCL paths against the cpu paths when running GEGLs test suite, thus ensuring that the results are really interchangeable. > The first step would be adapting the existing code and re-implementing > the pixelwise operations in OpenCL. Meanwhile, we have to remember > that OpenCL can be compiled to run in the cpu also, so we don't need > to make memory transfers in this case. I do not know enough details about OpenCL and its data buffers to asses how this best would be done. Though it would be interesting to see how the code generated compares with the existing cpu code; if fully free software toolchains for OpenCL (perhaps using LLVM) emerges, it could be interesting to use OpenCL as the officially encouraged way of implementing GEGL ops. /Øyvind K - GEGL maintainer -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode "Color"
On Tue, Mar 15, 2011 at 10:28 PM, Jacek Poplawski wrote: > On Tue, Mar 15, 2011 at 8:47 PM, Charlie De wrote: >> Why?? Rupert Weber finished this last September and you promised it would be >> in >> 2.8. Is this how you show respect for the most stellar effort by a new >> talent? >> Shame, truly, shame on you. It's now been 5 years since the issue was first >> reported, you're going to add another year even though the work is done. That >> is, if you don't break your promise again. Where's your integrity? > > This is very sad. I am not among the people working on GIMP itself - in the context of GIMP is primarily do work on GEGL - but I can tell both of you that this type of email does not serve to motivate any developer. At best they ignore it; at worst they get discouraged and decide that spending some of their spare time contributing to the common good/free software/GIMP is not worth it. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek wrote: >> > I've got a dream about visual editing program consisting of >> > different components, each taking care of one of presentation >> > aspects with one underlaying rendering engine (target aware >> > angine—I don't like cairo's “I don't care what's on the end” >> > attitude ;)). >> >> It's what we, utter geeks, call a framework :) > > That adds +10 to "coolness" but don't let everybody know ;) > >> Deneba/ACD Canvas was an attempt to create such one, but it was done >> on top of software started in mid 80s. Sometimes a whole week passes >> when I don't wake up in cold sweat seeing it in my dreams. > > Funny stuff… :). But seriously, sometimes it's good for somebody to try > a thing that didn't work out last time. Because of that stubborness > we're able to fly by airplanes nowadays ;). > > I consider idea of one flexible uberapp much more sensible and > appealing than implementing wee bit of “alien world” in different > apps—just seems half-solution for me. So do I,. and a "framework" that can make something like that happen is called GEGL ;) http://pippin.gimp.org/tmp/gegl-foo/ Buried in history of the GEGL repo is a GTK+ based UI with at various revisions both freehand painting with simple dynamics, as well as.. node based both bezier and spiro curve editing bits, integrated with generic layer filters and more.. it is/was not really that much code, but it was sloppy code thrown together with left-over pieces from a video editor. I am from time to time toying with resurrecting that project as a minimal thing show-casing what is possible to achieve. If I do get around to do that I would probably avoid doing it with C though, so it would be a complete rewrite and not really a resurrection. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 7:47 PM, Bogdan Szczurek 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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg wrote: > Olivier gmail.com> writes: >> 2011/3/8 Michael Grosberg gmail.com> >> Could you explain why retouching photos should be made in CMYK rather than >> RGB? > > Photo retouching is usually done by print magazines. It stands to reason that > they would use tools that are able to work with CMYK. Please see my longer response about why doing this _in_ CMYK is usually wrong, premature optimization by using device dependendt color spaces if the result might go to many different printers, profiles etc. > As for the other things... > Modern Photographic work also relies on a higher bit depth. Photoshop is able > to process raw camera input as opposed to GIMP which has to first convert it > to 8-bit before being able to work on the image. Some of these are true, and GIMP is working towards lifting some of these limitations by migrating to GEGL. > There are also various selection tools, color adjustment tools and retouching > tools (such as the healing brush) that work better in Photoshop. These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek wrote: >> Considering the use cases where fine grained control over the >> resulting offset plates/actual ink used for C,M,Y,K to be a subset of >> the more general cases where individual ink control is desired >> (spot-colors (including metallic, glossy and other overprints) as well >> as duo tone and more). > I also have high hopes for GEGL, but I'd rather have it use some more > abstract color model for that. I know it's not so simple—maybe even > undoable–that way, but I do like the idea of color model that has > complete coverage of visible spectrum. Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Spectral processing is not similar to subtractive models like CMYK models needed for simulating print, mixing aspects, subsurface scattering, ink interactions and more (some of which are better indirectly modeled by ICC transforms backed by actual test-runs). >> with almost enforced >> strict working spaces for the algorithms to ensure predictability. The >> ability to do separation to CMYK, spot colors and more with associated >> processing on such will most easily be done as abstractions >> implemented using a planar approach where each ink is represented by a >> graylevel buffer. > > True enough, but we mustn't forget about target material > characteristics when considering print (and soft proofing), paint > printing order and their attributes (opacity among them too). All of these, like the simulation of glossiness or reflectiveness of metallic inks are things for the final separation/composite/simulation though - which very well can take into account both substrate and perhaps even an animated illuminant ;) Such soft-proofing would not be a space that GEGL itself would be doing processing in however, even though it might have op(s) to take the individual grey level buffers to create an RGB simulation to be shown on a display,. taking into account the RGB profile. Allowing the user to configure a largeish set of predefinable inks for separation and simulation/softproofing would possibly allow some very nice workflows in GIMP and other softwares using GEGL. Implementing the capabilities of doing such workflows is something that only can happen after GIMP itself has more naive initial support for storing its image data in GeglBuffers of higher bit depths. So if someone wants to play with, research and make prototypes for such a thing it would be a nice and welcome addition. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek wrote: > have nice black background. Most of the times CMS will try to simulate > that with all colors while it's better to use e.g. just full black and > cyan. Another example: you need to do some trapping. Sometimes it can > be done in RIP but you need to trust that to RIP itself and print > house. These are only a couple of arguments, leaving aside quite > similar cases of printing with paints different than C, M, Y and K. There are use cases where direct control over the separated result to CMYK is desired, this is however the corner cases and not the generic sense, it is my impression that a lot of people are editing in CMYK without understanding color management at all, effectively circumventing proper color management to happen. In the few cases where you need to include text or vector elements on top (or embedded within) an image and want to ensure a matching color with the (adjusted) photo,. or do other things to avoid problems with registration problems yes I see this as beneficial. To edit photos in a device specific (or even geography specified least common denominator CMYK profile) by default is however in my opinion not good advice. Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more). This the direction I have encouraged GIMP to move in on the UI level. This distances it from color managed, photo retouching etc. In the foreseeable future I see GEGL as primarily aiming to provide the core to do color manipulation, processing and image processing in colorimetrically managed (RGB) color spaces; with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Fri, Feb 25, 2011 at 1:30 AM, Bogdan Szczurek wrote: > And let me throw in another thing. It's been in my head for some time > but now I think it's good to show it to the world. Just in the matter > of shear curiosity: I'd like to see some conceptual work/code/working > example/whatever about automatically configurable grid processing. It > may be more of GEGL project than GIMP one, but I believe still > beneficial in the end. Since 3D rendering engines do that, maybe it > would work nice in 2D world too. Of course a metric and some kind of > benchmark would be needed to decide if sending some part of work over > network to another node is beneficial. Anyway I think it have chances > to make things snappy even on slow machines. I see it as a something > between freakin' fat workstations, thin clients with some heavy “mother > goose” and mighty cluster. It would (hopefully ;)) help to use what is > at hand more optimally. GEGL is designed to be able to split up the rendering requests from the public part of it's API internally and to distribute it among threads/processes/hosts without needing changes to the application using GEGL. At the moment there is only experimental support for using threads in this fashion, but the architecture has been made with distributed processing in mind. This also applies to the GeglBuffers for which there a few years ago already was done experiments with doing multi process/user concurrent manipulation of the same buffers. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sat, Feb 12, 2011 at 11:31 PM, Liam R E Quin wrote: > On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: > Integrate vector layers with gegl GEGL already has all the support for rendering vector layers, so it is a case of adding the code to deal with as part of the nodes in the projection. Thus doing work on this would not really be possible until compositing the layers using GEGL is the default (or only) way this is done by GIMP. > Better HDR support - e.g. aligning layers, (I think there may be patents > on the various hugin algorithms for combining images though) Through gsoc last year, GEGL already has operations to combine multiple exposures into a HDR image as well as operations for tonemapping HDR images to standard dynamic range. Thus this is a task mostly about integrating UI bits with GIMP, once the drawables in GIMP are (and are backed by) GeglBuffers. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-item-transform-scale vs gimp-drawable-transform-scale
On Fri, Feb 11, 2011 at 1:13 PM, Ofnuts wrote: > > On 02/11/2011 01:02 PM, Alexander Rabtchevich wrote: >>> I apologize, you are right. I apparently only added links to >>> the new context functions from the new selection API. >>> >>> It's the new context API, e.g. gimp_context_set_interpolation(). >>> Will add the docs after work today. > > Hmmm. What proportion of existing plug-ins working in 2.6 will have to > be rewritten for 2.8? In my neck of the IT woods, within the same > version backward compatibility is implied... And if a rewrite is > necessary we will have to support both versions for quite some time > (some people fall in love with some plug-ins and won't upgrade Gimp > until there is a new version of their beloved plug-in). And do it again > when 3.0 shows up... But the rewriting needed for 3.0, porting to be GEGL ops, can be done already now, and I would strongly encourage GIMP to make use of GEGL ops more on an equal footing to GIMP plug-ins (and not be hidden in an own menu under the GEGL tool like it is now) so that freshly developed plug-ins can be done as GEGL ops already now and be more future proof. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://gegl.org/contribute.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
On Tue, Feb 1, 2011 at 2:39 AM, gespert...@gmail.com wrote: > A couple of days ago a voluntary coder (with an impressive CV) arrived > to this list offering his help and he only got a couple of replies. > This pointless discussion got a lot more of attention. This discussion is almost entirely thin air and bikeshedding, I spent a couple of days formulating one of the texts linked to in one of those replies. (http://gegl.org/contribute.html) People serious about contributing would perhaps have to spend quite a bit of time thinking, investigating and digesting before being able to follow up. I am glad that discussion tapered out; and maybe have responses in the terms of actual code. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
On Thu, Jan 27, 2011 at 10:02 PM, Pete Bergstrom wrote: > On Thu, Jan 27, 2011 at 3:43 PM, Eric Grivel wrote: >> I am getting the impression that the Gimp project is trapped in a >> chicken-and-egg problem with regard to attracting new contributors, >> where the few core developers are too busy maintaining the product to >> spend a lot of time helping new developers come on board. >> >> Gimp is an extremely large and complex system. I am a fairly experienced >> coder myself, and have recently submitted patches for two open bugs. But >>... >> At this point, knowing how busy the core Gimp developers are, and >> recognizing that it will take more time for them to walk me through a >> problem and a solution than it would take them to just fix the issue >> themselves, I am hesitant to ask for a lot of help. On the other hand, >> the idea of just delving in and figuring it out myself is quite daunting. >> >> Which is where my thought of a "boot camp" came in. What if there was a >> group of potential new developers all struggling with the same learning >>... >> This would require some serious commitment of time by one or more of the >> Gimp developers, and would mean other work wouldn't get done. The >> potential payoff however in the form of bringing one or more additional >> Gimp developers up to speed could be significant. > > I find myself in the same situation. I popped up in late December with > an interest in getting GEGL more fully integrated into GIMP (I'd like > to see 8+ bpc support), and Øyvind gave me some pointers and partial > code for what he wants to happen next (so I'm one of the time sinks he > referred to a couple of days ago). I'm still working to figure out the > seemingly recursive concepts. Feel free to drop by the #gimp and #gegl IRC channels to ask directed smart questions for understanding the code. Also be aware that some of the existing core contributors both dislike email in the first place, and are "cursed by knowledge" thus not the best people to write introductions to how things work; new-comers are in a better situation to do this. For the last few years GIMP (and GEGL) have been involved in Google Summer of Code which can be considered some form of such a boot camp - some of the students have also stuck around after their last money from google arrived, the common practice in the last years has also been that the domain experts have not neccesarily been direct mentors for students but "meta-mentors", giving guidance on irc in the public channels for any problems that might crop up. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] Where can I help?
On Tue, Jan 25, 2011 at 8:40 AM, Stephen Greenwalt wrote: > Where can I help? Here's an ultra-short overview of my background: > * Have some extra time I could devote . . . but will wait to quantify that > until I hear where you need help. This happens from time to time, sometimes people actually have the time and capability to help, quite often they ask for help - consume time to get up to speed, and then nothing happens. To avoid wasting more time on a reply to this email as well as other requests via mail, IRC and other places I have started writing up a list of pointers about the current state of GIMPs refactoring to use GEGL and where help would be appreciated. See http://gegl.org/contribute.html for this list. /Øyvind Kolås. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Ang: Why GIMP is Inadequate
On Fri, Jan 14, 2011 at 11:01 AM, ronald.arvids...@privat.utfors.se wrote: > >snip< I though would like to urge you to fix the 16 bit depth > asap. Its true that many end figure don't have 16 bit/channel but > before you get there its a VERY good thing to have. particularly for us > who edit photos with a large dynamic range. GIMP developers have been painfully aware that this is a serious short-coming of the current architecture for the last decade. There is no need to reiterate this :). Besides what needs fixing is the 8bit per component limitation, 16 bits/component isn't how it will be fixed though. The internal processing will jump straight to 32bit floating point allowing HDR processing and other advantages. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why GIMP is Inadequate
On Thu, Jan 13, 2011 at 6:02 PM, Martin Nordholts wrote: > On 01/13/2011 01:39 AM, Malix wrote: >> Hi all, >> >> on this blog there is a post about Gimp that generate a lot of user comments. >> http://troy-sobotka.blogspot.com/2011/01/why-gimp-is-inadequate.html >> I think that someone of you that can replay to false things must post a >> replay. >> > > To me, most of his criticism is legitimate. I don't agree with all of > it, but it's not all "false". I don't see the point in treating him as > hostile; it just help him prove his point that we can't take criticism. > > If we keep improving GIMP and stick to our plan, I am confident we will > eventually address all of the shortcomings he points out. Most of the short-coming he is pointing out are things we are well aware of, and that the existing developers have invested copious amounts of our time towards fulfilling. We are well on the way towards having addressed quite a few of them, the post and many of the commenters are perpetuating opinions and attitudes that might cause even fewer people contributing; and existing volunteers of open source software to stop bother volunteering their time and knowledge towards creating tools for users without sense of neither tact nor gratiude. I am not at all amused. The only sane response to the shit storm he has caused is to be responsive and friendly towards people who seriously do contribute to GEGL and GIMPs future, on bugzilla, mailinglists and irc. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
On Tue, Jan 11, 2011 Øyvind Kolås wrote: > http://git.gnome.org/browse/gegl/tree/operations/ (GEGL plug-in ops) > ... http://git.gnome.org/browse/gimp/tree/app/gegl (GEGL ops statically > compiled into GIMP) Note these two ways of creating GeglOperation subclasses lead to almost exactly the same compiled code, the first one uses custom C-preprocessor macros to avoid the boiler plate needed to define GObject subclasses and properties. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
On Tue, Jan 11, 2011 at 5:47 PM, andy gill wrote: > That certainly looks like something I could help with. Is there a priority > list of missing operations, or is it more a case of just going through the > gimp filters one by one? Is it the final intention that all gimp filters > will be implemented by gegl one day? Yes, the expectation is that one day all the code that directly modifies pixel values are GeglOperations, when it comes to core (non-plugin) functionality a lot of this migration has already been done and can be seen in http://git.gnome.org/browse/gimp/tree/app/gegl /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
On Tue, Jan 11, 2011 at 4:19 PM, andy gill wrote: > Hello, I'm a coder with some spare time, wondering how to spend it. > Are there any jobs that could be usefully picked up by someone who isn't one > of the core developers? One thing that will prove beneficial in the future, is the porting more of the plug-ins GIMP ships with by default to also be available GEGL ops. (thus preparing for the time when GIMP is internally using GeglBuffers and having >8bpc ways of processing is more important. Looking at various files in common/ and other subdirectories of http://git.gnome.org/browse/gegl/tree/operations/ should provide a guide to how such ops can be implemented. Such contributions would be completely self-contained and thus not need any changes to infrastructure. Such ops would at first only be available through the GEGL tool with automatically constructed property UIs. I expect at some point that there will also be seperatly loadable plug-ins providing custom UIs for specific GEGL ops. (This is something I believe might belong in GIMP not GEGL; or perhaps even in a gegl-gtk-ui convenience library). /Øyvind K. -- http://pippin.gimp.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] donations for GIMP 2.8
On Mon, Jan 10, 2011 at 5:39 PM, Alexia Death wrote: > On Monday, January 10, 2011 19:17:51 Øyvind Kolås wrote: >> Code documentation is also one of the tasks that are not permitted for >> instance in the Google summer of code, perhaps we could come up with a >> set of bounties, or find someone motivated and fund them on a task by >> task basis or even part time for documenting? > > I think this is a frightfully good idea too. One of those tasks could be > writing the GIMP code Codex. Coding standards and best practices and so on. It > could give us much easyer to merge forks for example. Its extremely annoying > having to rewrite most of a great feature to make it fit for merge And > yes, I do remember my starting days trying to make sense of the GIMP on the > inside. Note that many of the documents/the start of the documentation described or desired do already exist but might not be appropriately pointed to, and it has already been created and contributed to without monetary reward. Lets hope use of rewards wouldnt scare off people from contributing such work for free. /pippin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] donations for GIMP 2.8
On Mon, Jan 10, 2011 at 5:05 PM, Michael Muré wrote: > You may know me as the student who coded the cage tool during this summer. > > I'd like to add something about these bounty. For me, the key point > for the health of the community dev of Gimp is the current difficulty > to be used to the codebase. I myself had a hard time to understand how > things works in the code, and how to do things. The main cause of > these difficulty is the lack of technical documentation. We sometimes > need to read hundred lines of code just to know what an objet actually > do. The code architecture is obscur for most of the dev, and if we > loose the key dev, we will have hard time. If i haven't the pressure > of the GSOC program, I probably abandoned. > > I once asked why we don't have these documentation. The answer i had > is that writing documentation is boring, that's like that in free > software, you just have to deal with. > > That's a vicious circle. The less we have docs, the less we have dev. > And so, and so ... > >snip< > My idea is to use this money to reverse the trend. Lets give bounty > for these docs. Here is some example of documentation I think is > needed: > >snip < Code documentation is also one of the tasks that are not permitted for instance in the Google summer of code, perhaps we could come up with a set of bounties, or find someone motivated and fund them on a task by task basis or even part time for documenting? For a while, almost all the time I spent on GEGL (to the detriment of progress wrt features and performance) was spent on cleaning it up, and documenting it, website - references and more; this in case I decided to completely drop the ball or get consumed by other things, what I added was far from enough; and being the actual originator of much of the things in GEGL I am almost a bit "cursed by knowledge" and thus not the person best suited for it. Getting more documentation sure will be one of the best ways of making it easier to involve more people (and I am sorry for any bits of almost existing docs that aren't fully integrated yet.) /pippin -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On Wed, Nov 24, 2010 at 4:25 PM, Bill Skaggs wrote: > Maybe it would help to have a general explanation of the principle behind > the filter. > > The basic idea of the Unsharp Mask is to enhance the difference between the > original image > and a blurred version of it. The algorithm first blurs the image, then > calculates the difference > between the original image and the blurred version, and then alters the > original image by > moving each pixel farther away from its blurred value. > > The convolution is simply a way of blurring the image. There are countless > ways of > doing a blur -- the filter is using a rather crude approximation of a > Gaussian blur, which > is the most commonly used blurring algorithm. In GEGL unsharp mask is implemented at a higher level of abstraction than low-level filters and reuses gaussian blur directly, thus speed improvements to gaussian blur in GEGL will also benefit unsharp mask directly. See http://git.gnome.org/browse/gegl/tree/operations/common/unsharp-mask.c this version of unsharp mask can already be used in GIMP through the GEGL-tool, it would probably be good if the unsharp-mask in GIMP was properly replaced with the GEGL one. /Øyvind Kolås ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Graphic Tablet Sponsoring
On Wed, Nov 24, 2010 at 11:02 AM, Michael Natterer wrote: > in order to get gimp properly running with a tablet again, > and in order to make sure GTK3 does what it should together > with GIMP, I need a graphics tablet. > > Since the GIMP account is full of money, and I don't use > it for anything else that hacking GIMP, I'd like to get > it sponsored. > > There is no GIMP commitee deciding such things, so please > object here, or give an OK if you feel "entitled" to :-) > > It's a Wacom Intuos4 in size A5, around 300€, since that > supports all the stuff we want to support and is not > a piece of garbage. OK++ (assuming my opinion carries sufficient weight in such matters) I am all for you obtaining a physical artefact reminding you of continued promises to ensure extended input devices of various kinds continue working as expected. /Ø ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] astronomical use of GIMP
On Fri, Nov 19, 2010 at 10:47 AM, Alexandre Prokoudine wrote: >Another limitation of using GIMP for a 3 color image is that GIMP does > not use what are known in Photoshop as "Adjustment Layers". How about adding this missing feature to GIMP? >>> >>> You know how to submit patches, don't you? :) >> >>That's not a very useful reply. Adjustment layers have been discussed >> extensively in the past, and they are not something that a new user could >> simply code up and send in a patch for. Even PhotoShop only allows >> adjustment layers for a specific set of adjustment types, because it's >> essential that adjustments can be calculated very rapidly. >> Anyway, one of the advantages of GEGL is that it may make this sort of >> thing easier to implement. Adjustment layers should be added to the GIMP FAQ http://www.gimp.org/docs/userfaq.html under the section of frequent feature requests,.. so that we can point to a FAQ and laugh instead of wasting more time in this echo chamber :d Almost all the foundation work for supporting this is already done in GEGL/GIMP, the only missing bits is making a real decision on how things are done in the UI as well as probably starting to let GIMP use OpenRaster instead of XCF for composition storage. The projection of GIMP can be made to render using a GEGL graph, in this graph any arbitrary operation can be inserted anywhere in the hierarchy providing a combination of the features photoshop call adjustment layers/layer effects. Artificially limiting the selection of ops doesn't seem good. A couple of years ago I tried exchanging the opacity op in the GIMP code for the layer stack with a dropshadow op, this worked fine and allowed to have live drop-shadows with an adjustable parameter... thus one can almost say that GIMP can already do these things and more, it just doesnt expose them to the user in any useful form. > Well, my point is that adjustment layers have been discussed to death > already (sorry, Alexia :)) So there is not much point saing "How about > implementing them" once again. At some point someone should JFDI. We are waiting (and kind of blocking) on our interaction designer trying to come up with a solution as good or better solution than a hierarchical list Last time the topic was brought up no further input on the problem was provided ... that last email in that thread was: https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-August/025446.html I and other core developers would welcome a contribution providing such integration, then we can later change what is being done iff peter comes up with a better solution in a decade or two. /Ø ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] LAB in Info Window
On Thu, Oct 21, 2010 at 10:03 PM, Sven Neumann wrote: > On Thu, 2010-10-21 at 21:26 +0200, Martin Nordholts wrote: >> On 10/21/2010 09:10 PM, Jacek Poplawski wrote: >> > The question is - can I do it? Can I submit a patch somewhere and it >> > could be commited into development branch? >> Of course you can! >> I suggest you create a patch and attach it to a new bug report filed at >> bugs.gimp.org. Don't forget to take the active color profile into account. > > You can't really take the active color profile into account unless we > decide to add a dependency on littlecms to the core. The whole color > management system would basically need to be rewritten. This has the > potential to allow some important improvements all over the place. But > we really need someone willing and capable to finish this work if we > want to open this can of worms. Shedding some light on this can of worms from my perspective babl and GEGL perspective: I think the best thing for now is to not take the color profile into account, and make that assumption that GIMP is working on sRGB data... The responsibility for color management in GEGL is distributed among the operations. Raster Buffers passed around are tagged with a BablFormat describing the pixel format (color space, bit depth and component permutations). When files with ICC profiles are loaded they should either be converted upon load to a predefined BablFormat, or a BablFormat depending on lcms should be dynamically constructed referencing the ICC profile. Operations are performed in whatever is their preferred working space, some natural spaces here are RGBA float, RaGaBaA float, CIE Lab float and Y float. The meaning of these formats is well defined thus the behaviour of operations will be predictable and fully color managed. The "active profile" is the final transformation to be applied to the color data after it leaves GEGL/gets saved (within GEGL data is most likely mostly stored as RaGaBaA float). User interface elements showing color triplets or quadruplets like the color picker would use babl to transform single pixels of data to and from CIE Lab, R'G'B'A u8 and similar. When using an output target profile lcms should either be used directly or indirectly through babl. The profile of your display as well as soft proofing and rendering intents is not relevant for these bits. /Øyvind Kolås ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wish: A better animation system inside GIMP
On Mon, Oct 4, 2010 at 9:24 AM, Jim Michaels wrote: > in GAP I would like to see > - repaired .APNG support (import and export) > - .MNG (import and export) > - numbered .BMP's as frames (used in a number of video frame conversion > programs) (import and export) > - .AVI (import and export, but you can limit the kinds of video formats you > want to support, since there are MANY) > - .flv (import and export) (I think it already does this) > - .swf (import and export) > > and if someone really feels like doing it, .mpg and .vp8 files and some of > the modern formats. I believe mplayer can read a lot of these formats, and > what mplayer does not read, ffmpeg does. ffmpeg even does AVI[MJPEG] which > is what my camera puts out. GEGL being a graph based image processing/compositing framework is lends itself well for building animation based systems as well as static image things like GIMP. One of the projects that I abandoned development of and folded into GEGL when GEGL development was restarted some years back was a combined video sequencing/compositing system. Some of the examples in the GEGL source tree are also simple animations driven from C or ruby/python. GEGL has input nodes and output nodes built on top of the ffmpeg libraries (quite probably bitrotted, but salvagable). Perhaps similar nodes should be created along the same pattern as well that use GStreamer instead. /Øyvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Native RAW support
On Mon, Sep 20, 2010 at 7:44 PM, Sven Neumann wrote: > ... GEGL will also use third-party libraries to read and > write RAW files. We are certainly not going to reinvent the wheel. GEGL already supports using dcraw to load raw files using the operations gegl:raw-load uses the dcraw binary, reading back the decompressed data using pipes. http://git.gnome.org/browse/gegl/tree/operations/common/raw-load.c There is also an operation in the operations workshop called gegl:rawbayer-load that can be used to only get the grayscale matrix allowing to use a custom operation for the demosaicing. /Øyvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 2:10 PM, wrote: >> Oliver - >> >> this rant has no reason to be. Sorry for that. >> It makes no sense to start working in a project the size of GIMP >> without having to learn the code already in there first. > [...] > > I didn't say people should not look into the code. > > I meant: before looking into the code, an OVERVIEW on the code base > would be helpful. > > Looking into the code without an overview yields to people with > too narrow view on the code. Maybe that is good for other people, > but not for me. I'll bite ツ There is various libraries that GIMP depends on: glib - does portable reusable low level data structures, and includes GObject which provides the basis for OOP in GIMP gtk+ - is a UI toolkit that was created for use with GIMP that is now widely used also elsewhere babl - is a pixelformat conversion library that provides dynamic and efficient conversion of pixel formats. GEGL - is a graph based image processing framework that together with its plug-ins is destined to replace almost all code in GIMP and its plug-ins, doing work on the legacy 8bit code in GIMP will most often result in the brave new world promised by GEGL to be further postponed. I maintain two of these projects, babl and GEGL, the following links point to overviews of the directory structures used for their source codes: http://gegl.org/#_directory_overview , http://gegl.org/babl/#DirectoryOverview /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization & tricks (getting Blender's 2.53 UV layout as path into GIMP).
On Mon, Sep 13, 2010 at 11:05 AM, yahvuu wrote: > On 13.09.2010 11:47, Alexia Death wrote: >> No. Just... no. XOR needs to die. Badly. > > just curious: what coloring options exist to enshure sufficient background > contrast > when drawing non-XORed/anti-aliased? One good way of doing it is drawing two strokes with slightly different width and contrasting (perhaps transparent) contrasting colors you will achieve sufficient contrast. An old example of such rendering using cairo can be seen here: http://pippin.gimp.org/curve.jpg /Øyvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths.
On Fri, Sep 10, 2010 at 7:57 AM, Mirza Husadzic wrote: > I'm afraid that path rendering in GIMP requires a major change. > Why not take this step further and make it more flexible and easier to > maintain for future development? Depending in any way on librsvg would in my opinion not be a move in the right direction, the next generation rendering infrastructure of GIMP called GEGL has it's own path class that allows specifying paths beyond what SVG deals with (though it probably does not deal with some of the corner cases for terse condensed path representations in SVGs). http://git.gnome.org/browse/gegl/tree/gegl/property-types/gegl-path.c The grammar parsed by GeglPath is dynamically extendable to also incorporate for instance spiro curves http://libspiro.sourceforge.net/ or other non bezier curves. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On Wed, Sep 1, 2010 at 6:35 AM, Martin Nordholts wrote: > My point was that we either decide that GEGL should render just like > legacy, in which case we would need to implement both kinds of color > layer modes in GEGL, or we decide that some incompatibilities are OK, in > which case we don't need the legacy color modes in GIMP. -- > Right now, the Overlay layer mode actually renders differently in GEGL > than in legacy, so we would also have to introduce an "(obsolete)" > version of Overlay. (The legacy Overlay is exactly identical to legacy > Soft Light, but the GEGL Overlay is different from the GEGL Soft Light.) GEGL will do compositing in linear light RGB, while GIMP will do compositing in sRGB (unless profiles are attached to the image, then it will do compositing in that random space). The results of GEGL compositing when GIMP is not lying to GEGL about the pixel format of the pixels will in most cases result in slightly different results. /Øyvind K. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GPU-accelerated Image Filtering w/ CUDA
On Sun, Aug 29, 2010 at 11:40 PM, Alan Reiner wrote: > I forgot that CUDA is not OSS. We don't have to worry about that because we > only use it for in-house simulations. I only remembered it was free for > such use. > > I know that similar stuff can be done with OpenGL, but that's a completely > different beast. There's also OpenCL but I don't know anything about that > either. At least those two solutions should work on both NVIDIA and ATI, > but I believe the code still needs to be tailored specifically for each > architecture. > > As for portability, I don't see that as a concern for any of these. For > various platforms, it would be preprocessed out. For everything else it can > detect and disable itself if it won't work on the resident card. > > I might look a little bit into the OpenGL solution to see if that's > feasible, but my understanding is that it's more archaic and not as > powerful. And I personally don't have a reason to learn it. Perhaps one > day when I have time to contribute directly to an OSS project. Doing image processing on the GPU using OpenGL and GLSL for GIMPs next generation engine is planned and the initial proof of concept of such a system deeply integrated with GEGL exist in a branch of the git repository at http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu , The approach taken there is to implement automatic migration of tiles between cpu and gpu. /Øyvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dummy Layer with particular dynamic effect
On Sun, Aug 29, 2010 at 12:39 PM, Jacopo Corzani wrote: >> http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html >> >> As he observes, this avoids the problem of 'adjustment layers' not >> actually being layers in any normal sense (that is, their lack of >> content) while allowing the same or greater functionality. >> > This kind of layer's effect stack is currently under develpment (you > post is dated to may 2007)? . It can be a great step to make gimp > totally non destructive and easy to use.If this feature is under devel i > would contribute in a development or test phase. Anyone know > anything?There is an open task about that? There is an ongoing architecture refactoring of GIMP towards migrating the internal representation of buffers (or rather what is traditionally seen by the user as layers) and all processing happening on them to use GEGL (http://gegl.org/). An initial refactoring has been done for color processing tools and the processing of the layer stack. This can be enabled by the user through the menus of the development version. Once GIMP uses GEGL by default for the composition of the layers adding any GEGL based operation as a filter on a layer is easy from a programming perspective. I have myself done an experiment where I replaced the per opacity slider in the layers dialog with a gaussian blur and it works as expected for both text and other layers. The UI for this is not fully decided upon, and when it comes to the UI side and this proclaimed "layer-abuse", I am personally in favor of adding adjustment layers within the layer tree. This keeps the flow of compositing in one place in the UI, making it more readable. The styling and interactions with these operations can be a bit different from the actual content layers, allowing to collapse the list, simplifying the layers dialog to a tree of just the "content layers". Having this chain embedded within the layer tree solves an otherwise problematic recursion issue if the list is kept external to the layer tree, you want to be able to use layer subtrees as masks/parameters for operations performed on a layer or layer-group. Note that the transition to GEGL would also also enable you to use other render nodes in addition to text like gradients, noise, fractals, checkerboards, vector layers and more. Thus helping out with this refactoring, and improving both GEGL and how GIMP uses GEGL is probably what would be most beneficial. One thing that probably would aid in accelerating the refactoring of various subsystems is adding a tile backend to GeglBuffer that is backed by a GIMP TileManager, This would simplify the code used during transitioning, at the moment proxy GEGL operations are used that both makes more code required and also adds some overhead that could be avoided. /Øyvind K. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On Tue, Aug 24, 2010 at 4:30 PM, Rupert Weber wrote: > On 08/24/2010 04:20 AM, David Gowers wrote: >> I hope you're not associating the quite suboptimal way in which GIMP >> currently uses GEGL, with BABL's speed or lack of speed. >> > > Just did a quick test: > 1Mio random pixels passed to babl as one buffer (=one function call) vs. > passing the same buffer pixel by pixel (=1Mio calls) to the integer > conversions. > babl still comes out 35x slower. This is expected since there are no additional fast paths in babl for the specific conversion you probably used. At the moment babl will have to do quite a bit of internal work going via double precision floats and manually permuting components. The purpose of babl is to provide an API that provides correct color conversions and allows accelerating these with extensions that are conformance tested and performance ranked at runtime. Your integer code could be added as such an extension and will be chosen automatically if it is good enough (or if the environment variable BABL_TOLERANCE is set to for instance 0.02 or higher, indicating that babl shouldnt be as strict about which fast paths are permitted.) Fast conversions added to babl do not only benefit the conversion of the implemented source/target pixelformats since babl can also string together such conversions in a chain). /Øyvind K. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On Tue, Aug 24, 2010 at 1:52 AM, Rupert Weber wrote: > On 08/22/2010 02:45 PM, Sven Neumann wrote: >> New code in GIMP should use babl for pixel format conversion. There's no >> need to introduce new API for that as we have babl which is available to >> the core and plug-ins and provides a much superior API. > > The short answer is: No. I won't do that. > For the long answer see further down below. (Sorry if this post becomes > a bit longish) > > First about the current state of affairs: > I posted the last update to the patch to > http://bugzilla.gnome.org/attachment.cgi?bugid=325564 > > From my point of view, it is now done. > > Some performance numbers, comparing redraw times of legacy modes to the > new LCH modes and to current GEGL LCH modes: > (Tested with a very large picture to get measurable numbers; still these > are ca. numbers, obtained with a stop watch) > > Mode | Legacy | New LCH | GEGL/babl > -++-+-- > Hue | 3.6 | 6.4 | 396 > Saturation | 4.6 | 6.2 | 405 > Color | 4.7 | 4.1 | 431 > Value/Lightn.| 3.5 | 4.1 | 416 > > So I'm in the ball park of the legacy modes, Color is even a little > faster. Compared to current GEGL/babl the new modes are about 60 to 100 > times faster. (Yes, no typo) Due to the hacky way it is implemented, to enable using the GEGL code paths alongside the legacy code paths without breaking the legacy code paths. Additional conversions back and forth between 8bit and 32bit float are needed, and the processing is not done in non-optimal amounts. > As to accuracy, these are the round-trip pixel errors for Lab and LCH > conversions: > Error after round-trip [in 8bit RGB space]: > L*a*b* L*C*H* > 0: 16561783 ( 98.716%) 0: 16527659 ( 98.513%) > 1: 214941 ( 1.281%) 1: 248244 ( 1.480%) > 2: 492 ( 0.003%) 2: 1313 ( 0.008%) > 3: 0 ( 0.000%) 3: 0 ( 0.000%) > > The worst we get are off-by-two errors. You won't notice without > diff'ing two layers. > If you don't just stack no-op layers on top of each other, out-of-gamut > errors will be *far* greater than these. Such an error should be unacceptable, the conversion code for CIE Lab in babl are symmetric. > So, as I already said, I consider the patch done now. > And then there is babl. > I feel very bad about that request. Because I expect it to be the first > step in a relatively short sequence of if-we-do-that-why-don't-we's that > will end with these modes not getting in but rather be added to the GEGL > agenda. > As that is effectively what you are asking me to do: work on the GEGL > modes instead (or duplicate them, which would be even sillier). > But that is not what I signed up for. The idea was to get something done > and usable now. Not something that will be great in some uncertain future. > > When this is done I will be glad to take a look at babl and see if the > conversions can somehow be integrated. But I don't expect that to be a > trivial task. > > The patch is here. Now, and it works. The conversions add 17k of code. > Once GEGL takes over, they'll simply removed again. No one gets hurt. I suspect that the code is already triply duplicated now then, the original GIMP CIE Lab code in app/base/cpercep.c , it's copy in babl/ectensions/CIE.c and your conversion code. If you add your conversion code to babl as well it will be picked instead of the existing conversion, if it is both symmetric and faster than the existing implementations. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weber wrote: > On 08/24/2010 04:20 AM, David Gowers wrote: >> I hope you're not associating the quite suboptimal way in which GIMP >> currently uses GEGL, with BABL's speed or lack of speed. >> BABL just processes raw pixel buffers. A converter function just >> accepts a source and a destination pointer, along with a pixel count, >> and should convert that number of pixels. It doesn't have any heavy >> architecture or processing, aside from what may be in each individual >> converter function >> >> looking at your code in gimpcolorspace.c, making that code work with >> BABL looks like it's pretty much a case of cut+paste, modify the way >> the input is referred to, add some registration code. >> >> (getting your layer mode code to USE that, is a different issue, and I >> agree that would be non-trivial, although you might get significant >> speed gains from it because of greatly reduced function call overhead >> -- probably about as much as you describe for inlining below.) > > As I indicated, I'll be happy to make the babl integration of those > conversions my next little project, but I also expect a bunch of > questions to come up in the process (color management comes to mind). Color management does not have much to do with this, since the pixels are already assumed to be in a well defined pixel format and color space. Babl is nothing more than a collection of conversion functions, meta data about the color spaces and data types used and the ability to assess the conversion speed and quality of these conversions at runtime. Thus as long as the claim as to what pixel format a buffer is in is correct, use of babl is correctly color managed. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rendering GIMP widgets entirely in OpenGL/FBO?
On Mon, Aug 16, 2010 at 5:31 PM, Martin Spindler wrote: > this is my first contact to GIMP/GTK+ from a developer's point of view. A GTK+ mailing list would probably be more appropriate than the gimp-developer mailing list :) > For a research project I need to be able to render UI widgets/palettes > of a graphics editor (like GIMP) entirely in 3D space. In other words, I > would like to apply 4x4 Matrices (rotation, translation, shearing) onto > the widgets' bounding rectangles and then render these transformed > rectangles directly in 3D space and texture them with the widgets' content. You can do this by combining Gtk+ and Clutter. Clutter is a 3d scene graph library based on the same technologies GTK+ is built from. Clutter-GTK is an intergration library that allows you to place GTK widgets inside a ClutterStage (scene graph), as well as use ClutterStages as GtkWidgets. Both Clutter and Clutter-GTK are available from http://clutter-project.org/ /Øyvind K. -- Intel Open Source Technology Centre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On Fri, Aug 13, 2010 at 4:17 PM, Rupert Weber wrote: > On 08/13/2010 01:57 PM, Øyvind Kolås wrote: >> That code is never used (gggl-lies contains a bunch of conversions, >> some which are expected to fail - but only the correct ones pass the >> runtime regression testing all conversions are subject to). CIE.c in >> the same directory is what is used. >> > > Thanks. > The comment in the code also explains the current difference: > /* The gamma related code has been removed since we do our > * calculations in linear light. [...] > > When I remove gamma correction, I get the same result with layermodes as > GEGL. > > Does that mean GEGL should do the gamma correction before passing the RGB > data to babl? Only babl is doing color model, gamma, bit depth etc conversions, never GEGL. If the data is "R'G'B'A float" babl would take care of making it linear before doing the real conversion. Though that is unlikely as GEGL prefers to pass around "RGBA float" or "RaGaBaA float" data which is linear., I do not know the details, but I suspect GIMP is lying about most buffers being passed to GEGL. It probably is lying and pretending that sRGB data is linear.. by passing pixel data to GEGL as "RGBA u8" instead of "R'G'B'A u8" ... to maintain rendering compatibility with the legacy GIMP core, layer modes etc. which all assume compositing done in gamma corrected rather than using linear light. /Øyvind K. -- NB: please include the mailinglist itself in replies to posts on the list. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On Thu, Aug 12, 2010 at 2:39 PM, Rupert Weber wrote: >> Regarding BABL: i've had a look at extensions/CIE.c and found conversion >> routines >> using linear light RGB with the sRGB primaries and white point -- that is >> scRGB. >> Everything fine here. >> >> Now i'm not familier with BABL -- possibly i've checked at the wrong >> routines? > > What I found was conv_rgbF_xyzF() in extensions/gggl-lies.c > But I'm just as unfamiliar with babl, so I might be the one who looked > at the wrong place. That code is never used (gggl-lies contains a bunch of conversions, some which are expected to fail - but only the correct ones pass the runtime regression testing all conversions are subject to). CIE.c in the same directory is what is used. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On Fri, Aug 13, 2010 at 9:06 AM, wrote: > On 13 August 2010 02:57, James Cox 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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
On Tue, Aug 10, 2010 at 11:02 AM, Jon Senior wrote: > On Tue, 10 Aug 2010 08:27:59 +0200 > Martin Nordholts wrote: >> I don't think registering a fixed preview image is good enough, it >> should be a preview of the effect if applied to the current image. > .. > to create the demonstration image (which will show off "real" use of the > effect), but forcing it to be based on a specific image (Wilber springs > to mind). That way it's using a known base image but can be tweaked to > provide maximum visual effect for the preview? This is how I would see something like this added for GEGL operations: The desired end result would be to have a directory where previews of the results of gegl-operations can be found. Probably just pngs with the same name as the op it is a preview for. During the build of operations that come with GEGL a small set of illustrative images would be provided. By default if no extra work is done in the operation the default image will be used as input with default parameters. If this does not provide a good preview of the operation the op can add a string to GeglOperationClass containing the XML needed to apply the effect well to one (or more) of the sample images. These images would also be used in the GEGL documentation http://gegl.org/operations.html -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another idea for GSoC: "Plugin mixer"
On Fri, Apr 16, 2010 at 8:34 PM, Avgoustinos Kadis wrote: > Hello, > > I got this idea while studying and I wonder if its possible / hard / > done already and I didn't spot it: > > Plugin-Mixer: > > A window that allows you to select a few plugins, put them in order > you want them to be applied, modify their parameters and apply them on > the current image. The window should allow the user to save the > "combination" and reuse it for other combinations. *snip* > Advantages it offers: > + Users can create and reuse easily their "combinations" of plugins > that they use often. This increases productivity. > + When you normally apply few plugins over a picture, there is no easy > way to modify the parameters of the first plugins you applied (undo > works from the end). This would allow more control over using plugins. > + Could potentially generate plugins (generate their code) [not so > sure about this though..] This is related to what in GEGL is known as meta-ops, processing operations that are implemented in the terms of other GEGL operations. For instance the dropshadow operation is a combination of the operations gegl:over, gegl:translate, gegl:opacity, gegl:gaussian-blur, gegl:src-in and gegl:color. (unsharp mask is another example of such a composite meta op). At the moment these operations are written in .C, but it would be possible to define them as XML or some other serialization format. Editing such operations could also be done in a visual way using nodes connected with hoses or other metaphors. There is a bug in GEGL about loading such operations from non C files: https://bugzilla.gnome.org/show_bug.cgi?id=465743 -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] About the idea: Basic gegl based paint tool
On Mon, Mar 29, 2010 at 5:41 PM, Alexia Death wrote: > On Mon, Mar 29, 2010 at 6:34 PM, Jenny wrote: >> Here is my draft proposal >> https://docs.google.com/Doc?docid=0ARZjTPkuA386ZGRmY3JteG1fOTRoZmJ4cm1keg&hl=en >> thanks, >> Jenny > > No, that was not even in the same ballpark as the idea. Integration > with gimp was said to be optional but the project is for a paint tool > in gimp sense. Like paintbrush tool or airbrush tool using gegl as the > back end. The aim of this idea is the creation of that back end with > optional GIMP integration. That back end should support paths with > outputs and rendering of those paths either using stamping of a bitmap > or some other sort of creation of a stroke(for example the kind ink > tool in gimp uses now). Essentially an implementation of paint core in > gegl. Note that there already is code in GEGL that could serve as a starting point/inspiration that does stroking of paths using bitmaps/potato stamps with a procedurally generated brush, as well as a minimal experiment testing it. Since performance of GEGL based things in GIMP is going to be hampered by the lack of native use of GeglBuffers it probably makes sense to also be able to experiment with such new infrastructure outside GIMP. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gegl-0.1.2
GEGL 0.1.2 ⎺⎺ 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.2 you will also need babl-0.1.2 Changes in this release ⎺⎺⎺ • GeglLookup, configurable floating point lookup tables for lazy computation. • Use GFileIOStream in GeglTileBackendFile. • Optimizations: in-place processing for point filters/composers, SIMD version of gegl:opacity, avoid making unneccesary sub-buffers, removed some manual instrumentation from critical paths, improved speed of samplers. In some cases with current GIMP this leads to a doubling of the performance. • Added xml composition/reference image based regression tests. • Added performance tracking framework. • Syntactic sugar using varargs for constructing gegl graphs from C. • Build fixes on cygwin, • Gegl# fixes. • Initial, but unstable code towards multithreading. • Improvements to lua op in workshop. • Added new resamplers upsize, upsharp, upsmooth, downsize, downsharp and downsmooth. • Removed gegl:tonemap and gegl:normal ops. This release of GEGL brought was brought to you by: Martin Nordholts, Sven Neumann, Nils Philippsen, Adam Turcotte, Danny Robson, Michael Schumacher, Ruben Vermeersch, Øyvind Kolås, Javier Jardón, Yaakov Selkowitz and Michael Natterer, Kaja Liiv and Eric Daoust. 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.2.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.1/gegl-0.1.2.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.0.tar.bz2 34b4a6be9e472324d6dd1233713a1f8851fcdc04 gegl-0.1.2.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 -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "Artistic" extensions to Gimp with (Wacom) drawing pad
On Mon, Nov 30, 2009 at 5:59 PM, Markus Koskimies wrote: > with Python, it's much quicker and easier :) Why use python? Use ruby it is a lot more beautiful ;) GEGL have bindings for both languages and more for various sketching or photo-filtering apps that potentially could be built on top. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] DAG in GEGL and its role in GIMP
On Mon, Nov 23, 2009 at 3:46 AM, Tim Chen wrote: > Recently, I have spent my time reading source code of both GIMP and GEGL, > and got few questions about GEGL and its future role in GIMP. > > 1. Why DAG in GEGL? Intuitively, say if we have two operations that are > applied on two independent regions, they should be located in two separated > sub-tree (sub-graph), so that we can save save some traverse time and > potential redraw time. Time spent on graph traversal is neglible compared to pixel computation time. > However, it seems like that there is no such > mechanism (correct me if I misunderstand the code) and all operation > cache/reuse are determined according to the spatial relationship between the > rectangle associated with the operations. If that's the case, won't a simple > link-list suffice? GEGL doesn't evaluate the full image at each evaluation, but only a smaller region of interest (roi). This allows GEGL to compute the minimall needed roi of the input nodes to reduce the amount of needed computation, in addition caches might allow GEGL to skip some of the pre-computation needed to satisfy the demands made by a single node. > 2. Following question one, it seems like that GEGL has not been fully > integrated into GIMP (2.7) yet, and I am wondering that for some common > image manipulation case, say red-eye removal or skin smooth, what will the > DAG in GEGL look like? Will it look like a tree with height of two > (connecting all operations to the root display node) or a simple 1-D list? One of the goals of GEGL integration in GIMP is to make GIMP be a non destructive image editor. This means that instead of destructing a layer (and saving the previous state in undo tiles), the layer will be augmented with an operation that performs, and perhaps retains a cache of the result for the operation(s) applied to it. It is also possible, if I understand the idea you propose correctly to feed the result of applying an application back to the original buffer, this is what GIMP already does for its tentative GEGL integration for the color tools. > Ideally, how should GIMP build the graph to maximize the rendering > efficiency? This is yet to be determined, but ideally GIMP builds the graphs it needs, and it is GEGLs responsibility to restructure and/or evaluate them efficiently. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
On Thu, Oct 22, 2009 at 9:50 PM, wrote: > - a simple static pipeline is a big performance win: a year ago (when > I last timed GEGL) VIPS was always 10 and sometimes 100 times faster, > though perhaps I messed up the benchmarking > - with more than one CPU, large shared caches become a lot less useful > and can begin to limit scalability > - you can keep a display cache between pipelines to make panning and > zooming quick (the VIPS GUI does this) VIPS has received significant work on performance and refactoring after it started working (doing what it is meant to do). GEGL has not gone much beyond reaching the stage of doing what it says on the tin. Display caches between renderings is essentially what GEGL does as well, but it also permits doing this at check-point stages, (like for instance a full layer subgroup, meaning that that subgroup never would need to be recomposited if it doesnt change, GEGL also tracks all minor changes.) The GEGL code is structured in such a manner that the public application API (the one using nodes) can be kept while replacing all the internals as well as the plug-in API either as a fork (or later if such a fork proves itself as an alternative backend). Feel free to spearhead such an effort, personally I prefer continuing my efforts at completing the existing GEGL plans. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaus wrote: > Am Mittwoch, 8. Juli 2009 schrub Danko Dolch: > I personally love the node editor of blender and would like to see something > like that in GIMP. The only problem with these node setups (like the one in > your screen shot) is that they are only graphs but no trees. And AFAIK GEGL > uses trees of nodes. Thus the cool things like several sources or forward > edges (think of a bumpmap on a layer which uses the same layer as source) are > not possible. GEGLs XML serialization format is a tree, the data structure exposed in the API is a fully general directed acyclic graph. As long as you restrict the set of node types involved to: sources, sinks, filters and composers with two input pads and one output pad, any graph can be expressed as a tree with clones. In earlier incarnations (not in GEGL) of the same tree serialization I also allowed embedding free-form graphs as one of the nodes in the tree, thus more complex ops with multiple inputs and outputs could be inserted there. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL-0.1.0
GEGL 0.1.0
⎺⎺
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.
This is the first release in the 0.1.x development series, APIs have been
overhauled the graph API is now considered pretty stable. Note that to
migrate existing 0.0.x series code to 0.1.x you need to prefix operation
names with "gegl:"
To build gegl-0.1.0 you will also need the newest version of babl.
Changes in this release
⎺⎺⎺
• Renamed gegl:load-buffer to gegl:buffer-source and gegl:save-buffer
to gegl:buffer-sink (but the old names still work)
• Represent colors using doubles instead of floats (this change is
independent from internal processing)
• Removed the GTK+ UI parts of the gegl binary and turned gegl into a
pure command line tool (which can still visualize stuff with help
help the SDL based display operation)
• Consider {x=G_MININT/2, y=G_MININT/2, width=G_MAXINT, height=G_MAXINT}
as the only valid region wichin processing may occur. Processing
outside of this region is undefined behaviour.
• Added support for storing allocation stack traces for GeglBuffers
so that debuging buffer leaks becomes much easier
• Made small changes and cleanups of the public API, e.g.
• Removed gegl_node_adapt_child()
• Made GeglConfig an explicit object
• Removed most of the ifdeffed stuff to mask away internal
structures
• Added gegl_rectangle_infinite_plane() and
gegl_rectangle_is_infinite_plane()
• Added new sampler GeglSamplerSharp
• Added format property go gegl:buffer-sink
• Cleaned up and made gegl:introspect work again
• Add a bunch of test cases using the automake test sytem (make check)
and also port buffer tests to automake
• General cleanups, bug fixes, increased robustness and improved
documentation
This release of GEGL brought was brought to you by:
Øyvind Kolås, Sven Neumann, Étienne Bersac, Hubert Figuiere, Martin
Nordholts, Nicolas Robidoux, Michael Natterer, Ruben Vermeersch,
Kevin Cozens, Manish Singh, Gary V. Vaughan, James Legg,
Henrik Åkesson, Fryderyk Dziarmagowski, Ozan Caglayan and
Tobias Mueller.
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.0.tar.bz2
ftp://ftp.gimp.org/pub/gegl/0.1/gegl-0.1.0.tar.bz2
ftp://ftp.gtk.org/pub/glib/2.20/glib-2.20.4.tar.bz2
The integrity of the tarballs can be verified with:
sha1sum *.bz2
6e95e24c48b8018fefbf8e69ad62f4a4de56640c babl-0.1.0.tar.bz2
ede1789ce318b9afe4ec7dcb42c1065b4f278b64 gegl-0.1.0.tar.bz2
a0cee2b75bb485de926fa43b33887adc8f9c19bb glib-2.20.4.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/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm talk, part 2...
On Fri, Jun 19, 2009 at 6:56 PM, Alexandre Prokoudine wrote: > On Fri, Jun 19, 2009 at 8:05 PM, yahvuu wrote: > >> there's one thing i don't understand, may be a misconception: >> why is it necessary to have separate modes for editing the RGB data >> and the plates? >> >> For example, if i have an RGB image in the composition and want to apply >> 'value curves', that has to be done in the RGB area > > In 21st century there are no RGB curves :) There are LAB and L*c*h* ones ;) Not that the difference really matter as both linear light RGB and CIE Lab are fully mutually transformable into each other. For CIE Lab or Lch it would only make proper sense to control the L, other controls can be used for tuning white point etc in those color models though. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
On Sun, May 31, 2009 at 10:36 PM, Robert Krawitz wrote: > Omari Stephens wrote: > - This requires more computation to use because of the "odd" > shape of the space of valid coordinates. That is, not all > valid coordinates are valid colors. > > What I don't like about this is that it leaves a large fraction (well > over half) of the color space unused and functionally meaningless. I > agree that this representation is more accurate, but functionally it > seems more difficult to work with. Think about the UI implications. > > - HSL and HSV are in wide use, and this is neither HSL nor HSV > (though it's just a coordinate transformation away from both > HSL and RGB) > > It's a simple coordinate transformation from HSL: > > H' = H > S' = S * (1 - ((|L - .5|) * 2)) > L' = L > > but it's not any simpler than RGB->HSL. The colors selected in this manner will likely be used in a different color space than the one they are selected in anyways. This means that undefined regions of the colorspace and computational complexity are only a concern of the color picker interface. CIE Lch is another options that can be considered. I haven't studied it but suspect that the current computation of Lightness has crude 8bit/gamma assumptions in it. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
On Wed, May 20, 2009 at 9:07 PM, Daniel Johannsen wrote: > Hi, > yes, your assumption is right. I start the painting process with layers > only for shapes and silhouettes. > Then i add a "layer group" with the mask property (or in photoshop-terms > a group of "clipping mask"-layers) > to each of the shape-layers. The layers inside the layer group mask define > volume, texture, athmospheric perspective, etc. of the shape they are > connected to. > > So to say, the layer group mask has the property of a transparency > value. This value is defined > by the alpha-value of the layer the group is assigned to. > > Here is a link that shows the photoshop approach quite well: > http://photoshopcontest.com/tutorials/23/clipping-mask-101.html > > You are absolutely right, every layer in the layer group should maintain > their independent transparency, > but in addition inherit the transparency of their layer group mask. GEGLs XML format implements such per composition subtree masks. It even allows building these masks using other filters, allowing for instance to create a mask for a layer group using a blurred text layer. I've found the underlying technical approach used to represent the GEGL compositing graph as a tree in those systems to provide all the power that should be needed. Finding sufficiently rich mappings to a user interface most probably using some higher level abstract compositing operations remains a challenge for GIMP in exposing such functionality. An example composition following the underlying model of OpenRaster using low-level operations: crop over translate apply_opacity gaussian blur render text hue-saturation subtract some more noise multiply some more noise some noise pattern checkerboard Some of the low-level ops like the combination of translation and a compositing operation like over (and perhaps even the application of opacity) can be folded into a single UI level concept to avoid having too many individual items in the compositing tree. What the aboive example renders is three noise layers that are combined with different layer modes, a blurred piece of text is used as the overall group opacity for the noise and the noise itself is composited over a checkerboard background. Finally the whole image is cropped (this crop op would probably in fact be the canvas dimensions). See http://create.freedesktop.org/wiki/OpenRaster , http://pippin.gimp.org/oxide/ and http://gegl.org/ for more information. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Tue, May 12, 2009 at 6:16 PM, Alexander Rabtchevich wrote: > Peter, I think you (or me :) ) will be surprised if know the statistics > on the percentage of photos which really need complex retouching or > complex actions with layers. The most common cases I can give are face > retouching, "repairing" of a photo with too high dynamic range or > correcting perspective distortion. If a photo is properly exposed, has > not excessive noise and is not a portrait of a person you need to > improve, there is no need to retouch it after proper RAW conversion. Such adjustments will at some point in the future conceptually be layer-like as well. White balance, exposure control, unsharp-masking and noise reduction, cropping and rotation will be done non-destructively and be possible to tweak later, perhaps even when you re-open your GIMP composition (xcf, xcf2, OpenRaster or whatever,. native GIMP document). If you want to share the resulting image you might as well export it as a JPG, or perhaps even in some other format suited for some particular use. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The old bugs in merging modes > are fixed now?
On Wed, Apr 29, 2009 at 5:51 AM, Martin Nordholts wrote: > Alchemie foto\grafiche wrote: >>> Spontaneously I don't think custom layer modes is a good >>> idea. Might be >>> fun for programmers to play with, but graphic >>> professionals? There is a patch for such a thing for GIMP in bugzilla (with GEGL as a product). I do not think this is a very good idea though. >> Actually Graphic professional do complain ,but for missed option: >> for the absence in Gimp of modes they learned to use in Photoshop as >> Exclusion,Vivid light or Pin light. >> > > I'm all for adding the missing layer modes. But just as David I think > the customizability part should be in the form of programmers writing > custom GEGL ops. GEGL already has too many blending modes (36) to be meaningfully presented to most users. I guess it would make sense to trim down the existing set, and perhaps offer the more arcane modes (both existing GIMP ones and arcane ones from other software, in an additional sub-menu.) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2009: OpenGL GPU resampling in GEGL (an update)
On Wed, Apr 1, 2009 at 7:00 PM, Jerson Michael Perpetua wrote: > (1) Extend the current GeglBuffer implementation to store a copy of > "some" image sub-buffers/mipmaps in volatile GPU memory (textures, > VBOs). The image data in the GPU memory will be potentially > accelerated as they are already cached in the GPU as opposed to the > ones that are stored in primary memory. >snip< > Furthermore, Nicolas expressed that instead of resamplers, I could > implement other things. I elected that that "other thing" could be > GeglOperations. Some GeglOperations could be accelerated through > shaders. So instead of doing point no. 2 above, I could implement one > or two GeglOperations through shaders instead. GEGL gurus, do you > think this is at all feasible? Am I misunderstanding anything? Implementing the framework for letting GEGL do processing on the GPU is an interesting topic. Last year GeglBuffer hadn't matured enough to advise someone to start the task; now it is. Here is a plan containing my thoughts on what is needs to be done from a GEGL perspective. GPU based GeglOperations would be needed to implement and test GPU based resamplers for GEGL. Doing only one GeglOperation in a graph on the GPU will most likely be slower than doing all operations on the CPU; we need multiple operations to offset the performance cost of the CPU->GPU GPU->CPU transfers. Hopefully it is feasible to use shaders on tiles (or compose and split up larger buffers on the GPU), this would make it possible to keep track of where the valid tiles for a GeglBuffer reside; CPU or GPU side (using two revision counts). I hope this would make us able to use the same GeglBuffer handle for both CPU and GPU access in the same process minimizing the changes needed to the rest of GEGL. The type of GeglOperation that is most important to get going is GeglOperationPointComposer operations or as a starting point the op gegl:over which is the normal layer mode in GIMP, all other such ops behave the same with regards to input and output buffers but use a different formula. GeglOperationPointFilter is even simpler and would accommodate for the needs of operations like brightness contrast, desaturation and more. None of these would be using resamplers but they are the bulk of operations that needs to be performed. The operations that are likely to need a resampler (GPU built in or custom) are the more complex ones that can have varying input and output buffer sizes. The most needed one is the transformation class of operations. (Currently only affine transformations are in GEGL, but we need perspective as well to avoid a feature regression from GIMP which does this.) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
On Thu, Mar 26, 2009 at 10:14 PM, Andrew A. Gill wrote: > As little as I trust Pantone to CMYK, I trust Pantone to RGB > even less. > >> By this i mean anything which can't be done by processing >> the "plates" as separate grayscale channels (see ?yvind Kolas's post). > > This is not fun. What you are suggesting is a very laborious > process, and having such a process work properly would probably > result in tens of minutes to hours of wasted time, depending on > the image in question. > > And it still would result in one of the following: > > 1.) A helper application which creates the CMYK image > 2.) GIMP still is unable to deal with trapping or rich black. I was not describing user interface anywhere in my mail, I was describing underlying implementation mechanisms. GEGL stores pixels in buffers that can store and on demand convert to and from RGB, YCbCr, CIE Lab and Grayscale (dynamically extendable with other color models). Allowing image processing operations to be implemented using the models best fit for a particular operation. GeglBuffers are not designed to deal with the special cases of multi spectral images (lets say 32bands), spot colors (print plates). Render layers as present in EXR files (blender for instance produces multiple layers that are useful in post processing of the render). These will have to be dealt with on top. For CMYK the following ops need to be implemented: CMYK-from-RGB - takes a GeglBuffer as input, has options for black subtraction, ICC profile selection, gamut handling and similar, provides four gray scale GeglBuffers as output. CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input and provides an RGB soft proof. CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl actually support very naive CMYK buffers, these buffers are fragile and should probably only be used as a prestep to passing the buffer to a TIFF or similar saving op. Similar duotone-from-RGB and a configurable duotone-to-RGB or special five channel ops for use with CMYK with additional spot colors, or perhaps even a generic configurable ink-mixer op could be implemented. If a person with interest in these things want to he could also add support for 1bit GeglBuffers and generate the final raster to be printed at the printers native DPI. The primitives above should provide both preview and control over CMYK the fact that the innermost core doesn't care about CMYK would probably bleed into the user interface in the form that not all operations operate on CMYK images like they do on RGB images, it might not even make sense to accomodate for having layers of CMYK objects but only cater to the hard-core CMYK needs of pre-press, with a core set of the tools (color picker, color balance, curves, color picker) aware of how to deal with the CMYK bundle. Doing things like blurs and pastes would normally operate on the single selected plate, but electing to process for all plates should be possible. At the moment I do not have interest in CMYK but the above outline is in line with my ideas on how GEGL should evolve. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
On Wed, Mar 25, 2009 at 7:06 PM, Chris Mohler wrote: > On Wed, Mar 25, 2009 at 12:44 PM, peter sikking wrote: >> Mix master tape (in rgb) and then cut >> the lp (in cmyk). > > I can express any CMYK color in RGB - but not the other way around. > Therefore, I "master" all of my print jobs in CMYK, and if I "cut" > something like a preview for a client then I use RGB space. So you > see, it's actually quite the opposite in my world. This is why GIMP > is only a small portion of my day to day work flow - it is not > printer-friendly (yes, friendly to the device sitting on your desk, > but not a person who is a printer). > > And I agree that Scribus is coming along nicely and will (hopefully) > become a robust page layout program - but I think where GIMP comes > into the arena is creating a single image that will be printed (in a > magazine, screen printed, newspaper, whatever). Something like > PDF+CMYK export is a good first step, but ultimately CMYK editing and > channel operations are needed to make GIMP suitable for preparing an > image for print. I consider spot colors much more important than CMYK. I also consider CMYK a special case of spot colors. Spot colors could be implemented using GEGL ops that take a set of grayscale buffers (plates) as input and provides RGB soft-proofing (potentially even animated for gloss/metallic inks). This would leave the image processing algorithms dealing with sane or mildly sane color models like gray scale, RGB, YCbCr or CIE Lab, while allowing the user direct control over the contents of spot colors and seeing a preview of the resulting processing. If the above is considered CMYK support I would be supportive of it. CMYK support in the form of CMYK and CMYKA pixel buffers as a first class citizen (or even a third grade citizen) with support in most operations and routines is something I will continue to oppose. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp license
On Fri, Jan 9, 2009 at 7:49 PM, Michael Natterer wrote: > On Fri, 2009-01-09 at 15:36 +0800, C Wang wrote: > So finally, I hereby suggest to move to GPL3 asap. > > Comments from any developers appreciated. I am also in favor of a GPL version upgrade (as could probably be inferred from both GEGL and babl being licensed under LGPLv3+) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] develop web-based image editing application with gimp as backend engine
On Thu, Dec 11, 2008 at 12:34 PM, Laxminarayan Kamath <[EMAIL PROTECTED]> wrote: > On 12/11/08, Øyvind Kolås <[EMAIL PROTECTED]> wrote: >> GEGL is moving it's backend to GEGL. > > > I guess you meant GIMPis moving it's backend to GEGL. Good guess :d /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] develop web-based image editing application with gimp as backend engine
On Thu, Dec 11, 2008 at 12:00 PM, Vu The Cuong <[EMAIL PROTECTED]> wrote: > Hi all > > The subject says it all. Currently I'm considering to > > develop web-based (PHP) image editing application with gimp as backend > engine for intranet use. > > > > But I don't know where to start from. Could anyone point me to the right > direction? GEGL is moving it's backend to GEGL. So building a web front-end directly on top of GEGL would be the approach I would have taken (and have considered in the past). This would involve making it possible to serve tiles from GeglBuffers (the render cache is such a buffer) over the wire, this would be similar to how maps.google.com / google earth and other similar software transmit only the shown pixels. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Higher-bit depth and plug-in filters.
On Tue, Nov 18, 2008 at 5:06 PM, Austin Donnelly -- yahoo <[EMAIL PROTECTED]> wrote: > Hmm, so how would a filter like Newsprint work in the GEGL framework? User experience (accuracy might vary): = The user might want to newsprint the full layer stack of the implicit layer group that the image itself is (The image is a collection/group of layers). Or the user might want to newsprintify an individual layer in this layer or one of the children of a layer group in the image. User says: "layer-select image" The top-most layer in the image compositing stack is selected (if a different layer was selected the layer dialog would expand the parent groups it belongs in and scroll to the correct position.) User says: "add-operation newsprint" A newsprint filter is added as a filter at the end of the toplevel layer stack. It starts rendering the result immediately to the image and if the user is satisfied with the results he is done. (He could now merge the effect down if the layer below was a pure raster layer to achieve destructive image editing, but to get a flattened image most people would export to png, jpg tif or similar.) The newsprint filter is the active filter/transform/effect applied to the currently selected layer. This means that a property pane somewhere, kind of like the tool options would allow control over Input SPI, Output LPI, Cell Size, plates, spot function etc. Perhaps even the controls for setting the angle per channel can be manipulated directly in place on the canvas (a bit far fetched, but useful for other things.) Developer experience: The function currently called newsprint() becomes the process() implementation for a subclass of GeglOperationAreaFilter[1], since the operation needs a constant neighbourhood around each source pixel depending onthe oversampling used. . This is done by copying for instance box-blur.c[2] to newsprint.c and replacing all references to box-blur with newsprint. Then type make && sudo make install in this directory as the new .c file is automatically added to the build. Now replace the chanted arguments at the top of the file with the parameters for newsprint, as well as replacing the process function. Now replace the geometry setup done in prepare with something that indicates the number of pixels needed to be provided to our area-operation at the left, right top and bottom sides of our source pixel. As well as specify the format we want the data in. When this is done GEGL can use this operation like any other operation, in XML, Python, Ruby, C, C#, the GIMP GEGL tool and other software using GEGL and with live preview as a layer effect, etc. (accuracy starts varying again:) Optional: add a custom GUI control mechanism that provides controls for editing the parameters of the new GeglOperation, (default ones with sliders/entries/color pickers/font choosers/file pickers can be provided by the core during development and for simple dialogs). To reproduce a user experience similar to the existing one you would have to create a custom dialog to get the groupings, radio buttons and tabs for the different channels and preview for the spot functions. For some other operations it would also be useful to add callbacks for handling tweaking of some on image parameters for newsprint controls for setting the angle per channel could be added. Other ops such as iwarp have a much larger need for such hooks. At some later point additional logic to render at power of two halving factors from lower resolution source data might be added to support live previews on large images (operating on mipmap levels of the caches for nodes in the graph). 1: http://gegl.org/gegl-operation-filter.h.html 2: http://svn.gnome.org/viewvc/gegl/trunk/operations/common/box-blur.c?view=markup Hope this helps, happy hacking. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Higher-bit depth and plug-in filters.
On Mon, Nov 17, 2008 at 7:31 PM, Martin Nordholts <[EMAIL PROTECTED]> wrote: > 1. Extend the plug-in API to deal with high bit-depth images What needs to be done is to get rid of, or stop relying on all the existing GIMP plug-ins that change image data (the ones changing image structure by rearranging layers, layer masks etc and in other ways change the state of GIMP are in a different category and are valid. But these plug-ins should not care about the datas bit-depth). We might need a way to specify GUIs / dialogs for GEGL operations but I do not see how GIMP plug-ins should need to deal with higher bit-depth data. For some legacy third-party plug-ins a GIMP legacy plug-in GEGL operation wrapper could be created. In the future the only API to care about if you want to modify actual pixels in an image should be the GEGL operation API. GEGL operations should be inserted into the layer list (work on this could probably start before the real switch, making the filters be no-ops in the non GEGL-projection case). If a user really wants to destructively modify a layer it would be achieved by merging the filter layer with the buffer containing the raw pixel data. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 73, Issue 16
On Thu, Oct 9, 2008 at 1:43 PM, Alexandre Prokoudine <[EMAIL PROTECTED]> wrote: > On Mon, Oct 6, 2008 at 9:13 AM, Stephen DeLear wrote: >> operation_class->name= "sdv-unsharp-mask"; >> >> and leave the standard unsharp mask. >> >> The current unsharp mask uses radius, amount and threashold. The new one >> uses scale and standard deviation. The function it is performing an unsharp >> mask but it's done the equivalent of going from Farenhight to Kelvin without >> telling anyone. This results in somebody using one image editor not being >> able to spec actions for somebody using a different editor. This can be a >> big deal where multiple photographers are trying to produce a consistent >> output (for example a primary and secondary shooter at a wedding). > > Ah, I see what you mean. That's a question to author of the GEGL op then. The names of properties of GEGL operations are as far as I am concerned API, when creating a user interface in a photo manipulation application like GIMP, f-spot or other applications on top it would be the responsibility of the programmer to map the scientific terms used to describe the properties to sliders that maybe uses terms more useful to a casual non expert image processing person. Using the standard deviation instead of an approximate radius of the gaussian blur is much more mathematically correct and is also the way the SVG 1.2 filter specification specifies the parameters for a gaussian blur. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl resize script, anyone?
On Wed, Aug 27, 2008 at 11:53 PM, Nicolas Robidoux <[EMAIL PROTECTED]> wrote: > > Hello all: > > Maybe I am stupid, but I have looked all over the web for a code > snippet/script/howto which would be easy to adapt to allow me take an image > (any standard format) as input and resizing it using, say, the gegl cubic > sampler, and saving the output image in some generally readable format. > > I understand that gegl is not meant to be particularly script friendly, but > not finding anything on the web (the examples found on the gegl web site are > helpful, but not enough) > is quite surprising to me. > > Any pointer? > > (What I want to do: replace the innards of the gegl cubic resampler with > something the code for the simplest coconvex resampler, recompile, and see if > I like the results. I have already written the suitable coconvex resampler > code based on the current gegl cubic resampler one.) > > I am finding getting gegl to do what I want much harder than understanding > its source code! When I did some simple testing of the current resampling code (some more extensive tests with rotations showed be that there were some flaws in the new code, but it works well most of the time) I dropped a series of xml files into the gallery directory under docs. [ cubic-5.0.xml ] --- Then by issuing make in the gallery dir this should be included in the generated html. Alternatively you could issue: gegl cubic-5.0.xml -o cubic-5.0.png To process only that file. It might also be possible to test thing using either the ruby or python bidings. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] possble replacement(s) for Gimp Lanczos
On Thu, Aug 21, 2008 at 3:01 PM, Nicolas Robidoux <[EMAIL PROTECTED]> wrote: > David Gowers has suggested using LittleCMS (or GeGL) to linearize colour > profiles during the computation. In our experience, our plug-ins produce good > results when used in a "gamma OBLIVIOUS way." This being said, back of the > envelope computations suggest that "light" haloing is likely to decrease if > the colour profile is properly taken into account (because sRGB has a linear > component near black, "dark" haloing is probably not going to change much for > such images; again, this is from a very rough back of the envelope > reasoning). Given that GeGL will perform all the heavy lifting for the Gimp > in the future, I am not sure that fixing the gamma correction at this point > is really something I want to do. However, I will try to integrate profile > information in the profile if it is felt that it is important. > > The current "gamma" versions of the plug-ins use "naive" gamma correction > (and do not take into account the linear piece of sRGB). David's plan is a > much better one. A summary of image resampling in GEGL: GEGL is being designed to operate correctly on images, the current samplers operate on "RaGaBaA float" buffers, which is the babl notation for premultiplied alpha linear light RGB with opacity. This causes a resampling and resumming of the buffer behaving like phyiscal light, ray tracing and compositing operations are other operations that give the most correct result when operated upon in linear light. http://www.4p8.com/eric.brasseur/gamma.html details some of the problems with correcting sRGB data directly. Sampling types in GEGL are subclasses of a generic base class providing a a cache. This is less efficient than having the different samplers directly in the scaling code, but allows reusing them for all affine transformations, displacement maps, iwarp or other similar image deformations. Fast paths for scaling with specific samplers could probably be added later and tested against the generic extendable sampler framework for correctness at a later point. The cache that is used is a 64x64 linear circular buffer guaranteed to contain the entire needed spatial context of pixels. To see how the current samplers are implemented see: http://svn.gnome.org/viewvc/gegl/trunk/gegl/buffer/gegl-sampler-linear.c?revision=2489&view=markup Currently nearest, linear, cubic and lanczos scalers have been implemented. Scaling down is currently not handled correctly by the implementation, but for equal scaling on both x and y axis the sampling API should be sufficient to express the needs. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
On Sun, Jul 27, 2008 at 7:34 PM, Souichi TAKASHIGE <[EMAIL PROTECTED]> wrote: > 2008/7/28 Liam R E Quin <[EMAIL PROTECTED]>: >> On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote: >>> [...] >> >>> But it costs too much memory when we >>> make a lot of strokes -- and we *DO* make thousand of strokes when we >>> draw an image -- compared to the current implementation which has a >>> buffer per each layers. >> >> That's something that needs to be measured. > > I see. > It takes much memory when we draw brushmarks many times on the same > area, I think that is very usual situation. > Perhaps we should study the memory usage for this situation. > >> Don't forget that right now, the strokes are stored individually in >> the undo history anyway. > > Yes and no. GIMP copies previous tiles prior to its modification, but > that is part of previous layer image, not a stroke itself. GIMP can > forget the undo cache, and do forget the undo cache (on program > termination for example.) > On the other hand, GeglBuffers for each strokes should be kept > persistently. That is a big difference between undo cache and contents > of GeglBuffer. > But we can estimate the rough memory usage for the situation above > from the memory usage of the undo cache. The situation would be the same for GEGL once the bug in http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since the part of the processing graph underneath the top most added stroke doesn't change, and it can be recomputed from the parameters of the nodes in the graph there is no need to always persist the actual pixels. This is a general optimization that also will help other parts of GEGL. Experimenting with the gegl-paint example in the GEGL sources will be a natural thing to do when fixing this bug. (The code in there should be easily modifiable to become full non-destructive again). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
On Sun, Jul 27, 2008 at 4:46 AM, Souichi TAKASHIGE <[EMAIL PROTECTED]> wrote: > Sorry, I'm currently working on another program, so I have not > maintained the patch any longer. > > GIMP will be fully non-destructive editor in the future, but I think > that is not a good news for users who use GIMP as a painting tool. > Non-destructive editing is convenient in some situations, but a lot of > brush painting processes don't need to be non-destructive, and making > all of them non-destructive is a waste of time and resources. They do not need to be made fully non-destructive, for the paint core I have been experimenting with on top of GEGL[1] I have both a destructive and a non destructive version. The difference between them being that the destructive one continuously replaces the contents of a GeglBuffer instead of building a graph. Making things non-destructive doesn't necessarily imply additional work when creating brush painting processes if the infrastructure to do so exists. (I've mainly experimented with the destructive version thus far when I've had time since it is significantly faster than the non-destructive one which depends on better automatic cache purging to be more efficient. 1: http://pippin.gimp.org/tmp/soft-strokes.png > GEGL and GIMP are great work of cource, it is very powerful photo > retouching tool. But it's not good for painting images from scratch > since it lacks a lot of features specialized for painters (like view > rotation and flipping.) These are features that might easily be added on top of a GEGL based, both destructive and non-destructive paint core. At least if using hardware acceleration like the ClutterGegl view widget to display the final composite. At GUADEC this year I showed a mini painting app embedded in a presentation tool where I could freely rotate the GEGL paint demo and paint at it at any angle. > I think being general purpose program is a waste of time: code size > will grow constantly and the architecture will be more and more > complex. No one can maintain it. So GIMP should focus on the photo > retouching, and other programs like Artweaver, Gogh, and MyPaint > should focus on painting features. For some things, like natural media simulation using cellular automata like approaches I tend to agree, this is also one of the few types of simulations that I think would be difficult to make work in a non-desctructive fashion. For other types of user empowering painting features I do think they can belong in GIMP as well, or perhaps in other applications built on top of GEGL. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
On Thu, Jun 12, 2008 at 10:56 PM, <[EMAIL PROTECTED]> wrote: > Dreaming of "Adam's Pupus Pipeline"[3] for nearly a decade now, i doubt > the upcoming GEGL goodness will fill in that role anytime soon. GEGL is basically Pupus, it doesn't do network transparent buffers yet, but it has an infrastructure already used for shared disk swap between processes on the same machine. Almost all of what Adam outlined in his mail about pupus applies to todays GEGL. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl-buffer-load
On Thu, May 22, 2008 at 7:51 PM, Geert Jordaens
<[EMAIL PROTECTED]> wrote:
> I was browsing trough the buffer coding in svn and noticed following in
> gegl-buffer-load.c
> Is it normal that the width and height parameters are inversed?
That is a coding/refactoring mistake that has not been chaugt, thanks.
> GeglBuffer *
> gegl_buffer_load (const gchar *path)
> {
Fixed in svn.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp User Filter
On Thu, May 22, 2008 at 4:49 PM, Torsten Neuer <[EMAIL PROTECTED]> wrote: > The general idea behind the whole thing is to provide a means to be able to > write filters without the need of going through the whole process of studying > the SDK (Glib, Gtk+, libgimp in our case), compiling, and installing. > Instead, the plug-in offers an editor with which filters can be implemented by > writing a formula for each color channel that manipulates the pixel data of > the image. If the goal is not reuse of existing filter but creating new ones from scratch there are already at least two solutions tackling it in slightly different ways. http://www.complang.tuwien.ac.at/schani/mathmap/ and http://pippin.gimp.org/plug-ins/gluas/ Addding new functionality to GIMP when a compile cycle should also be a bit easier now with the ongoing integration of GEGL which provides a more modern API for writing plug-ins than the evolved mechanisms of GIMP plug-ins. GEGL operations get automatic user interfaces for user controllable parameters and live in viewport previews when used with the GEGL-tool (same infrastructure as the migrated color adjustments tools in GIMP). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gsoc project
On Tue, Mar 18, 2008 at 11:01 PM, rafael mesquita <[EMAIL PROTECTED]> wrote: > My name is Rafael, I am an Brazilian student of Computer Engineering from > Universidade de Pernambuco and about one year ago i have been studying image > processing, so i become interested in working in an gimp project. > People usually want to process image for specifics reasons : noise > extractions, signatures analysis, historic documents analysis, activation > areas detection from an human brain studies, and for so many other reasons. > In addition to this, those images can be of n different types. My general > idea is to make a plugin to help people doing new Filters, for their > specific reasons, without the need of writing new code. The idea consists on > creating those filters from basic Morphologic Operators (dilate, erode, > opening, closing and morphological gradient) and , in the future, creating > new filters based on other filters (combining them). If the goal is to write filters suitable for scientific processing I would think it makes sense to implement the filters for GEGL instead of GIMP, since GEGL operates with 32bit floating point buffers. Combining operations in GEGL to create new combined ops is something that already is possible, but needs further work (it is currently hard-coded in C while it should be done using an XML based format or similar (as well as have a usable UI.). /Øyvind K. (responding from somewhere near Shopping Recife) -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Error comiling GIMP 2.5 on Kubuntu 7.10 64 bits
On Sat, Mar 1, 2008 at 3:29 PM, Pedro Fuentes <[EMAIL PROTECTED]> wrote: > make[1]: *** [all-recursive] Error 1 > make[1]: se sale del directorio `/home/pedro/build/gimp' > How could i fix it? You seem to be building a revision of GEGL that isn't the very latest, either build GEGL from the 0.0.16 tarball at ftp://ftp.gimp.org/pub/gegl/ or upgrade your svn checkout of GEGL to the latest version. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Fri, Feb 15, 2008 at 10:57 AM, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > >snip< > Hopefully this is a question with an obvious answer, and there is some > tool that already works like this... > > Or is it really so that a warp tool, and the "filter brush" kinds of > tools that Ankh asks for, and all other nice cool things will need to > wait for a complete geglification? At least when it comes to doing such a warp tool, after a complete GEGLification this would be seen as a nondestructive editing operations that warps the image. By using specialised paint tools when the iwarp effect layer is selected, the painting would be affecting the deformation masks, the deformation masks would be stored with the the iwarp effect layer. For such an iwarp effect, as well as for most other effect layers like unsharp masking, gaussian blurring etc. The way to discard the state would be to "merge down" the effect into the original drawable thus losing the non-destructive ness of it. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP WebAccess via ajax-webinterface
On Dec 23, 2007 9:20 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'm not saying that a web hosted image > > someone interested in creating such a thing in the first place) I > > doubt it would be hosted as a free service due to the much larger > > overhead of keeping something like that going rather than allowing > > downloads. > > > May be this could be provided by several server as a test. Main > gimp.org/xxx could only redirect on these servers to tka the best > benefits of several ressources. > I'm not administrator but i have a server on which i could put this > solution for tests, and then see. Per simultaneous user using the service I expect that you would have to donate ~1ghz of processing power, 256mb of memory and a couple of gigs of swap space. But do note, I do not see this as a direction it is likely the current set of GIMP/GEGL developers neither should nor have strong desires to be directing development efforts, thus even thinking about gathering resources for a non existent vapour project is extremely premature. If someone has real plans for a system using AJAX or an other form of rich client image manipulation/processing application, I'd suggest they'd outline a road map or general plan for what they'd want to achieve and I'll be willing to comment on it on the GEGL-development mailing list. On the GEGL mailing list I'd outline what bits might be missing in GEGL to achieve the goals as well as give some feedback on the feasibility of the concrete plans. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP WebAccess via ajax-webinterface
On Dec 23, 2007 12:50 AM, anybody <[EMAIL PROTECTED]> wrote: > I am an Internet programmer and developer, but I am not as good as I want to > be because of a resource problem. > But I am looking for a long while onto the WWW platform and its technologies. > AJAX with GEGL and some sort of > a rich Internet Client could provide amazing contents to the open and free > source community. GEGL is designed with such developments in mind, and would already be easily adaptable to provide changing images in a tiled manner with micro updates, scaled down versions and other efficient communications of updates to the changed image. Hosting such a solution is a completely different thing though, since both bandwidth and disk space are needed for the imagery, as well as not insignificant processing power on the server side. Running such a service will also require resources for administration. I'm not saying that a web hosted image manipulation/processing/compositing application is in any way unfeasible on top of GEGL. Thoughts have been put into making the design fit such scenarios as well in the process of making it versatile. If a web server front-end shows up (which would need someone interested in creating such a thing in the first place) I doubt it would be hosted as a free service due to the much larger overhead of keeping something like that going rather than allowing downloads. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL 0.0.14
GEGL 0.0.14 ⎺⎺⎺ 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 ⎺⎺⎺ • Relicensed under LGPLv3+. • Per node caches (faster recomputation when properties of nodes in composition change) • Sampler framwork for interpolation. • Modified API for retrieving scaled buffers gegl_node_blit / gegl_buffer_get. • Renamed XML serialization and parsing API to be descendants of GeglNode. • Progress monitoring for GeglProcessor • New operation base class GeglOperationAreaFilter • API reference installed and browsable using devhelp. • New operations: ff-load, mono-mixer, contrast-curve, save-pixbuf, compositing ops from SVG-1.2 draft, value-invert, convert-format, bilateral-filter, snn-mean A new release of babl is also available, GEGL will work with babl-0.0.12 as well, but the constant overhead per conversion performed by babl has been significantly reduced in 0.0.14 and thus it is recommended that this version is used. This release made possible with contributions from: Étienne Bersac, Kevin Cozens, Manish Singh, Mark Probst, Martin Nordholts, Michael Schumacher, Mukund Sivaraman, Shlomi Fish, Tor Lillqvist and Øyvind Kolås 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.16.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.14.tar.bz2 ftp://ftp.gimp.org/pub/glib/2.12/glib-2.14.4.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 68f03e6d1810b9319c48691b4793103669219957 babl-0.0.16.tar.bz2 6bf6ddd6f85061e2c156ec526306c6c23504db5e gegl-0.0.14.tar.bz2 29f5d74ab83c36f98e86f560b993fce5ac60dedf glib-2.14.4.tar.bz2 Where to get more information about GEGL Information about GEGL can be found at the GEGL website http://www.gegl.org/ /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Automatic white balance
On Nov 27, 2007 7:00 PM, Stephane Chauveau <[EMAIL PROTECTED]> wrote: > Øyvind Kolås wrote: > > You could start out by studying the following paper, as well as it's > > references: > > http://www.ivl.disco.unimib.it/papers2003/WB%20Combining%20%20EI%206502-12.pdf > > > > /Øyvind K. > > > Nice article. The following Wikipedia pages does not describe so many > methods but are probably easier to start with: > > http://en.wikipedia.org/wiki/White_balance > http://en.wikipedia.org/wiki/Color_temperature > > The following article is even less technical but is also a nice read and > it explains the most common issues with automatic WB. > > http://www.cambridgeincolour.com/tutorials/white-balance.htm > > Anyways, a plug-in providing several WB methods would be cool but, in > most cases, I believe that it would be even better to extend the Color > Balance tool with the ability to manually pick the grey point in the > image. The easiest way to implement that feature could be to add a 'Set > White Point' button to the Color Picker tool. This functionality exists in the levels tool already. Personally I'd prefer a gui similar to: http://pippin.gimp.org/plug-ins/color_correct/ for a combined levels (on luminance) and white point/gray point/black point offset. Since I don't find it entirely natural to modify the white point using levels. /Øyvind K. (Doing full quote and replying to the list since the message I reply to didn't seem to be sent to the list.) -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Automatic white balance
On Nov 26, 2007 2:42 PM, Alexandre Prokoudine <[EMAIL PROTECTED]> wrote: > > On Nov 26, 2007 5:22 PM, Weber, Dr. Martin (Allianz ASIC) wrote: > > > I think the automatic white balance of many programs as well as of GIMP is > > not always leading to optimal results. So I want to deleope a new better > > algorithm for GIMP. To be able to I would like to get as many information as > > possible about the commenly used ones. So if you know an automatic white > > balance algorithm please tell me. > > Relevant part of DCRaw/UFRaw source code? > > Alexandre > ___ > Gimp-developer mailing list > Gimp-developer@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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Automatic white balance
On Nov 26, 2007 2:22 PM, Weber, Dr. Martin (Allianz ASIC) <[EMAIL PROTECTED]> wrote: > > > I think the automatic white balance of many programs as well as of GIMP is > not always leading to optimal results. So I want to deleope a new better > algorithm for GIMP. To be able to I would like to get as many information as > possible about the commenly used ones. So if you know an automatic white > balance algorithm please tell me. You could start out by studying the following paper, as well as it's references: http://www.ivl.disco.unimib.it/papers2003/WB%20Combining%20%20EI%206502-12.pdf /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gaussian blur in GIMP compared to Photoshop
On Nov 20, 2007 12:05 PM, Jesper de Jong <[EMAIL PROTECTED]> wrote: > > > Is Gaussian blur not a standard algorithm that has a well-defined > meaning > > > for the radius? See for example > http://en.wikipedia.org/wiki/Gaussian_blur > > > > > > If it is, then which one is doing it wrong, CS3 or GIMP? The amount of blurring achieved by a gaussian blur is specified by the standard deviation of the blurring kernel not the size of the blurring kernel. This probably means that GIMP and Photoshop use different ways of computing the standard deviation used from the user specified radius. Using the size of the kernel (which probably is ~2.5x the standard deviation) might be leading to behavior similar to what GIMP is doing. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap items
On Nov 13, 2007 6:16 AM, Henk Boom <[EMAIL PROTECTED]> wrote: > On 12/11/2007, peter sikking <[EMAIL PROTECTED]> wrote: > > - GEGL vs. vector, where is the dividing line when in the > >future with GEGL everything added to the image remains > >modifiable and removable? > > I'm not sure what the question here is, wouldn't vector layers only > help this philosophy? As far as I understand their purpose is to avoid > having to do permanent "stroke path" operations, instead making the > shape easily modifiable and impermanent. > > > Somehow we need to find a balance here where trivial stuff > > can be done in an obvious way within GIMP, we do not branch > > out into specialised inkscape territory and come up with > > something that fits the GEGL architecture. > > I see vector layers as being a replacement for most uses of the > current stroke/fill path. It accomplishes the same thing, but has the > advantage that you don't have to keep re-doing it when the path is > changed, as it updates automatically. When it comes to SVG integration with other applications, a layer tree or similar based on GEGL would probably automatically support this not much differently from how text layers would be supported, and the SVG-loading operation for doing so is already in place. I plan to make an experimental stroke-history based paint engine on top of GEGL. Doing experiments with this is soon becoming possible since the caching infrastructure I've been adding to GEGL in the last half year seems to be getting solid enough. This would work by storing stroke path, pressure, tilt etc information along with the brush settings for every stroke in a sequence of operations that apply paint/dabs to the underlying drawable. Each ops would contain it's own cache to speed up the application of another stroke on top (this per-node/op caching infrastructure is getting it's final polish for the next GEGL release). This will allow editing the properties of the strokes of a regular paint tool, and even removing an individual stroke after it has been made. The interesting question to be answered when a prototype is mocked up is whether it will be responsive enough for interactive painting. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL is now being developed under LGPLv3+
>From the ChangeLog: 2007-11-09 Øyvind Kolås <[EMAIL PROTECTED]> Upgraded GEGL from (L)GPLv2 to (L)GPLv3. The library itself and the operations are under LGPLv3 and the sample programs using the GEGL library are licensed under GPLv3. Copyright statements in all files have been updated to reflect this change, the permission to use leter versions of the GNU licenses have been retained in all instances.) * COPYING: changed to GPLv3 * COPYING.LESSER: added (LGPLv3 's exceptions over GPLv3) This has no impact on GIMPs usage of GEGL as since GIMP is licensed under GPLv2+ and can thus start adopting GEGL before deciding whether to upgrade from from GPLv2+ to GPLv3+. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] floating selections and other annoyances
On 10/27/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > Layer boundaries > > It would be nice if layers would enlarge themselves when needed. It is > annoying that the user has to care about this. > > This should be looked at from a user perspective first. When we have > figured out the details (like how to align a text layer if it doesn't > have a border), we can look how to best implement it. GEGL supports > sparse tiles, doesn't it? At the moment the GeglBuffer system is only catering to the immediate needs of rendering from input buffers (what would be considered drawables in GIMP) that do not change size after they have been initially constructed. Internally in the GeglBuffer itself this limitation is manifested by GEGL only keeping one (huge) buffer for each pixel format, and handing out pieces of this as buffers are constructed. This is something that is open for change, and I very much subscribe to the idea that layer boundaries should be dealt with automatically. Another part of GeglBuffer that is lacking in this regard is that it doesn't automatically replace a fully erased tile with a clone of the blank tile of the buffer, similar optimizations could probably be applied for tiles that have completely uniform color. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.4.0 rc2 access violation in WinXP - what to do?
On 9/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have several times received an AV crash when double-clicking on a file to > open it. > >From what I've gathered lurking, this is more likely to be a GTK+ problem > than a GIMP problem but with 2.4.0 final presumably just around the corner I > thought I shouldn't just ignore it. This problem has been addressed and fixed in SVN, a new pre-release with this crasher fixed should appear soon. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/27/07, Amit Kumar Saha <[EMAIL PROTECTED]> wrote: > Hello all, > > On 8/27/07, Øyvind Kolås <[EMAIL PROTECTED]> wrote: > > > According to the plan GEGL will replace all code in the GIMP that is > > accessing and or modifying pixels, some forms of GIMP plug-ins will > > most likely be entirely replaced by GEGL plug-ins instead. And as > > mentioned elsewhere in this thread, GEGL plug-ins can either be > > descriptions of graphs, or actual C code. Another option that should > > already be possible if someone is thus inclined, is actually to write > > a GIMP plug-in for GIMP 2.4 that allows GEGL plug-ins to be used > > directly by current versions of GIMP, this is less interesting than > > another bridge that will have to be written, which is a wrapper for > > (at least some of) the exisitng GIMP plug-ins to work from within > > GEGL, this will be needed to provide legacy support for > > some of the older plug-ins (these plug-ins will thus still work, but > > have limitations wrt bit-depth and such). > > > My current work at hand will possibly require me to write a plugin for > GIMP (current version) which will use GEGL for its image processing > operations. So if I proceed, I shall let the list know. > > Here a couple of more queries: > > 1. Does any of the developers here have some demo C code which takes > in a XML file specification of the operations and performs the image > processing tasks using GEGEL? The gegl binary found in the gegl/bin/gegl.c does just this, it can even be compiled without support for the GTK+ GUI which makes almost all the logic of processing happen in gegl.c, please do note that the format of the XML is not a finalized part of the interface to GEGL, and that there are some parts that are not even implemented yet. (The ability to specify a operation as a graph, stored as XML for instance, right now such meta operations need to be written directly in C which is a bit cumbersome for rapid prototyping.) > 2. Can I assume safely that most of the image processing operations > are "applying the same operation" to each pixel of the image? I do not understand what you mean by this question. It might also be an idea to take this discussion to the GEGL mailing list instead of continuing it here. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/26/07, Amit Kumar Saha <[EMAIL PROTECTED]> wrote: > Also, I would like to know, when GEGL is integrated into the GIMP, > will it be available for the Plugins to access the GEGL as well? The plan is that GEGL integration into GIMP will start after 2.4 is released and the 2.5 development cycle will be devoted to a process of gradual replacement, without changing the GUI significantly, thus 2.6 should be a version of GIMP that hasn't changed a lot of the GUI, but a development cycle that leads up to a GEGLified version of GIMP that can see further development and innovation. According to the plan GEGL will replace all code in the GIMP that is accessing and or modifying pixels, some forms of GIMP plug-ins will most likely be entirely replaced by GEGL plug-ins instead. And as mentioned elsewhere in this thread, GEGL plug-ins can either be descriptions of graphs, or actual C code. Another option that should already be possible if someone is thus inclined, is actually to write a GIMP plug-in for GIMP 2.4 that allows GEGL plug-ins to be used directly by current versions of GIMP, this is less interesting than another bridge that will have to be written, which is a wrapper for (at least some of) the exisitng GIMP plug-ins to work from within GEGL, this will be needed to provide legacy support for some of the older plug-ins (these plug-ins will thus still work, but have limitations wrt bit-depth and such). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
