Re: [Gimp-developer] Unified transform tool
Ofnuts ofnuts at laposte.net writes: Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). As I did mention, it was not a complete spec. The points you raise are valid, but they are already treated well in the original spec, and I only wanted to present the differences. In distort mode, Symmetry is applied to the larger distort delta of the two axes, i.e. if you distort a corner point 20 px to the right and 10px to the top, the symmetry will be horizontal. IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. Actually, the original spec DOES mention that scale from center is toggled by the CTRL key. Moving the center point lets you scale from any given point. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gegl-vips
Hi all, I've had a stab at a quick hack of gegl-0.1.6 to use libvips (another demand-driven image processing library) as the backend for batch processing. I think it is maybe an interesting way to look at gegl performance, for this use case at least. https://github.com/jcupitt/gegl-vips This has some very strong limitations. First, it will not work efficiently with interactive destructive operations, like paint a line. This would need area cache invalidation in vips, which is a way off. Secondly, I've only implemented a few operations (load / crop / affine / unsharp / save / process), so all you can do is some very basic batch processing. It should work for dynamic graphs (change the parameters on a node and just downstream nodes will recalculate) but it'd need a display node to be able to test that. There's a README with some more detail on how it works, a test program and some timings. If I run the test program linked against gegl-0.1.6 on a 5,000 x 5,000 pixel RGB PNG image on my laptop (a c2d at 2.4GHz), I get 96s real, 44s user. I tried experimenting with various settings for GEGL_SWAP and friends, but I couldn't get it to go faster than that, I probably missed something. Perhaps gegl's disk cache plus my slow laptop harddrive are slowing it down. Linked against gegl-vips with the operations set to exactly match gegl's processing, the same thing runs in 27s real, 38s user. So it looks like some tuning of the disc cache, or maybe even turning it off for batch processing, where you seldom need pixels more than once, could give gegl a very useful speedup here. libvips has a threading system which is on by default and does double-buffered write-behind, which also help. If you use uncompressed tiff, you can save a further 15s off the runtime. libpng compression is slow, and even with compression off, file write is sluggish. The alpha channel is not needed in this case, dropping it saves about 5s real time. babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s. The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s. Finally, we don't really need 16-bit output here, 8 is fine. This saves only 0.5s for tiff, but 8s for PNG. Putting all these together, you get the same program running in 2.3s real, 4s user. This is still using linear float light internally. If you switch to a full 8-bit path you get 1s real, 1.5s user. I realise gegl is committed to float, but it's interesting to put a number on the cost. Does this sound useful? I think it's maybe a way to weight the benefits of the various possible optimisations. I might try running the tests on a machine with a faster hard disk. John ___ Gimp-developer mailing list Gimp-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, jcup...@gmail.com wrote: Linked against gegl-vips with the operations set to exactly match gegl's processing, the same thing runs in 27s real, 38s user. So it looks like some tuning of the disc cache, or maybe even turning it off for batch processing, where you seldom need pixels more than once, could give gegl a very useful speedup here. libvips has a threading system which is on by default and does double-buffered write-behind, which also help. On my c2d 1.86ghz laptop I get 105s real 41s user with default settings. Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping of tiles makes it run in 43s real 41s user. With the default settings GEGL will start swapping when using more than 128mb of memory for buffers, this limit can be increased by setting for instance GEGL_CACHE_SIZE=1024 to not start swapping until 1gb of memory is in use. This leads to similar behavior, the tile backend of GEGL is using reads and writes on the tiles, using mmaping instead could increase the performance. If you use uncompressed tiff, you can save a further 15s off the runtime. libpng compression is slow, and even with compression off, file write is sluggish. Loading a png into a tiled buffer as used by GeglBuffer is kind of bound to be slow, at the moment GEGL doesnt have a native TIFF loader, if the resources were spent on writing a proper TIFF backend to GeglBuffer GEGL would be able to lazily swap in the image data from TIFF files as needed. babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s. If the original PNG was 8bit, babl should have a valid fast path for using lookup tables converting it to 32bit linear. For most other conversions involved in this process babl would likely fall back to reference conversions that go via 64bit floating point; and processes each pixel with lots of logic perutating components etc. By adding/fixing the fast paths in babl to match the reference conversion a lot of the time spent converting pixels in this test should vanish. The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s. For smaller radiuses this is fine, for larger ones it is not, ideally GEGL would be doing what is optimal behind the users back. Finally, we don't really need 16-bit output here, 8 is fine. This saves only 0.5s for tiff, but 8s for PNG. Making the test case you used save to 8bit PNG instead gives me 34s real and 33s user. I am not entirely sure if babl has a 32bit float - 8bit nonlinear RGBA conversion, it might just be libpngs data throughput that makes this difference. save = gegl_node_new_child (gegl, operation, gegl:png-save, bitdepth, 8, path, argv[2], NULL); Putting all these together, you get the same program running in 2.3s real, 4s user. This is still using linear float light internally. If you switch to a full 8-bit path you get 1s real, 1.5s user. I realise gegl is committed to float, but it's interesting to put a number on the cost. This type of benchmark really stress tests the file loading/saving parts of code where I am fully aware that GEGL is far from optimal, but it is also something that doesn't in any way reflect GIMPs _current_ use of GEGL which involves converting 8bit data to and from float with some very specific formats and then only doing raw processing. This will of course change in the future. Does this sound useful? I think it's maybe a way to weight the benefits of the various possible optimisations. I might try running the tests on a machine with a faster hard disk. It is useful, but it would perhaps be even more useful to see similar results for a test where the loading/saving is taken out of the benchmark and measure raw image data crunching. Setting GEGL_SWAP=RAM, BABL_TOLERANCE=0.02 in the environment to make babl be lenient with the error introduced by its fast paths I run the test in, it should be possible to fix the fast paths in babl to be correct enough to pass the current stricter criteria for use; and thus get these results without lowering standards. Even adding slightly faster but guaranteed to be correct 8bit/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] Unified transform tool
On 04/17/2011 08:31 AM, Michael Grosberg wrote: Ofnutsofnutsat laposte.net writes: Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). As I did mention, it was not a complete spec. The points you raise are valid, but they are already treated well in the original spec, and I only wanted to present the differences. In distort mode, Symmetry is applied to the larger distort delta of the two axes, i.e. if you distort a corner point 20 px to the right and 10px to the top, the symmetry will be horizontal. IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. Actually, the original spec DOES mention that scale from center is toggled by the CTRL key. Moving the center point lets you scale from any given point. Assuming we are both talking about http://gui.gimp.org/index.php/Transformation_tool_specification, this is not how I read it... there is the rotation axis, and the centre, that is defined as the point where the two diagonals through the corner points cross. The spec for the rotation does specify that the rotation axis can be dragged (that part would have been moved outside of the rotation transform it were usable with other transforms) The spec for the scaling, when using the from centre constraint, says translate the opposite side by the same distance which implies that the centre is equidistant to both sides and thus is still the centre defined above. An arbitrary fixed point would have implied the use of proportional somewhere in the spec. I may be wrong. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: Re: Unified transform tool (mouse gestures)
oops, only sent reply to Michael. Forwarding to list. Original Message Subject: Re: [Gimp-developer] Unified transform tool (mouse gestures) Date: Sun, 17 Apr 2011 10:33:10 +0200 From: g...@catking.net To: Michael Grosberg grosberg.mich...@gmail.com On 04/17/11 08:31, Michael Grosberg wrote: Ofnutsofnutsat laposte.net writes: Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). As I did mention, it was not a complete spec. The points you raise are valid, but they are already treated well in the original spec, and I only wanted to present the differences. In distort mode, Symmetry is applied to the larger distort delta of the two axes, i.e. if you distort a corner point 20 px to the right and 10px to the top, the symmetry will be horizontal. IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. Actually, the original spec DOES mention that scale from center is toggled by the CTRL key. Moving the center point lets you scale from any given point. Hi, having read the spec by Mitch I like the idea which could remove a hole bunch of icons from the toolbox and make life a bit easier all round. I started getting a bit uncomfortable with all the special keystrokes, this is one area where I find 2.6 confusing, non-inutitive and hard to remember. These are not easy to discover and have no logical connection to their function, you just have to commit it all to memory. Maybe the idea of mouse gestures could be useful here (as used in Opera browser and now available as extensions for firefox). This may be a good short cut for rotation and flip transformations (that does relate to function so easy to remember) . The rotations are a pain at the moment because they require navigating to a submenu, three mouse operations for a trivial action. One could imagine , once the transform tool is in operation mouse gestures could trigger H,V flip , the fixed rotations and mirror: drag down : v flip drag left/right : h flip drag up then left : anti-clockwise 90 drag up then right: clockwise 90 drag up then L/R then down : rotate 180 drag left , right, left : h mirror etc. In the context of Mitch's pre-spec document, these could operate in the outside the box area defined for the free-hand rotation. These could have keyboard equivalents (up arrow , left arrow) for disabled access or special hardware requirements. Some modifier key could be held at same time to differentiate between image transformation and layers If the floater is used , it probably should be interactive rather than display only and be draggable in case its placement is inconvenient. One word of caution , although I like the way the move tool fits into the plan, I think there is a possibility of confusion of this being billed as a transformation. Although mathematically linear translation can be done as a matrix transformation, it probably is not a transformation to a graphics user. A user would skip past it thinking I don't want to transform the image I want to move it ! Some care will be needed in how this is presented to avoid this point making access to the move tool less obvious, not more so. I think the whole idea has a lot of potential for cleaning up the interface and making things more accessible with less of a time spent learning. I like it. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting
Hello, The next GIMP Developer Meeting (#4) was scheduled for this week on tuesday, April 19th 2011 on 20:00 UTC. For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T20 As usual, the meeting will take place on #gimp-devel Developers who mentor at GSoC or any other person who has something to do with GSoC administration, should come 20 minutes earlier (a room for that will be announced on #gimp on that time) to finalize the GSoC applications and finish the process of GSoC student application. This is important! The agenda for this meeting isn't yet well defined - basically it's just discussing 2.8. The meeting page can be found on http://wiki.gimp.org/index.php/Hacking:Dev_Meeting_19_Apr_2011 Finally, due to request of some people, there is now a GIMP Developer Calander. For an online view in gmt/utc time, use the following link: https://www.google.com/calendar/embed?src=gj9trunel7ik41rhev111knfao%40group.calendar.google.comctz=Etc%2FGMT The ICS file for the calendar is available at https://www.google.com/calendar/ical/gj9trunel7ik41rhev111knfao%40group.calendar.google.com/public/basic.ics ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl-vips
Hello Øyvind, thanks for the reply. On 17 April 2011 14:24, Øyvind Kolås pip...@gimp.org wrote: On my c2d 1.86ghz laptop I get 105s real 41s user with default settings. Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping of tiles makes it run in 43s real 41s user. I found GEGL_SWAP=RAM, but on my laptop the process wandered off into swap death before finishing. Is there some way to limit mem use? I only have 2gb. 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 :-( 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. 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. 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. Yes, good point, it should be easy to instrument it for this kind of test. I'll have a go. John ___ 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, jcup...@gmail.com wrote: On 17 April 2011 14:24, Øyvind Kolås pip...@gimp.org wrote: On my c2d 1.86ghz laptop I get 105s real 41s user with default settings. Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping of tiles makes it run in 43s real 41s user. I found GEGL_SWAP=RAM, but on my laptop the process wandered off into swap death before finishing. Is there some way to limit mem use? I only have 2gb. My laptop has 3gb of RAM and thus doesn't end up crunching swap on such a test. Setting GEGL_CACHE_SIZE=1300 or so, should have a similar effect, hopefully GEGL wouldn't need to make everying swap. (not that in doing so you should _not_ set GEGL_SWAP=RAM). I noticed that setting GEGL_THREADS=anything_more_than_1 causes things to crash, along with other things that more subtly break.. are the reason GEGL doesnt default to keep all cores busy yet. Loading a png into a tiled buffer as used by GeglBuffer is kind of bound to be slow, at the moment GEGL doesnt have a native TIFF loader, You can work with tiled tiff straight from the file, but for sadly for striped tiff (as 90%+ are, groan) you have to unpack the whole file first :-( I'm not sure what a striped tiff is, if it stores each scanline separately GeglBuffer could be able to load data directly from it by using 1px high tiles that are as wide as the image. babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s. If the original PNG was 8bit, babl should have a valid fast path for using lookup tables converting it to 32bit linear. For most other OK, interesting, I shall look at the callgrind output again. I'd recommend setting the BABL_TOLERANCE=0.004 environment variable as well, to permit some fast paths with errors around or below 1.0/256 avoiding the rather computationally intensive synthetic reference conversion code in babl. The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s. For smaller radiuses this is fine, for larger ones it is not, ideally GEGL would be doing what is optimal behind the users back. Actually, it works for large radius as well. By separable convolution I mean doing a 1xn pass then a nx1 pass. You can bake the sub/mul/add into the coefficients you calculate in gblur. I thought you meant hard-coded convultions similar to the crop-and-sharpen example, baking it into the convolution might be beneficial, though at the moment I see it as more important to make sure gaussian blur is as fast as possible since it is a primitive that both this, and dropshadow and other commonly employed compositing things are built from. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
- Forwarded message from Mukund Sivaraman - Date: Mon, 18 Apr 2011 07:28:06 +0530 From: Mukund Sivaraman m...@mukund.org To: LightningIsMyName lightningismyn...@gmail.com Cc: gimp-developer gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting User-Agent: Mutt/1.5.21 (2010-09-15) Hi LightningIsMyName On Sun, Apr 17, 2011 at 11:39:05PM +0300, LightningIsMyName wrote: Hello, The next GIMP Developer Meeting (#4) was scheduled for this week on tuesday, April 19th 2011 on 20:00 UTC. For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T20 As usual, the meeting will take place on #gimp-devel Sorry, the scheduled time is not fine for me. I had asked for this to be changed on IRC, but nothing was done for the last meeting's time too. The previous meetings have happened at around 1:30 AM localtime and 2:00 AM localtime. As there's a rather large Pacific ocean, there must certainly be a suitable time for this meeting that doesn't occur during the middle of anyone's sleeping hours. :) Mukund - End forwarded message - pgpfZzrbQVBQF.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
