Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
> > Does this mean Gimp and gegl would be competing for my meagre 4gb of > ram? I didn't know gegl wrote cache files. Where does gegl write its > cache files? > ~/.cache/gegl-0.2/ Yes it will limit you to available ram for the image buffers; but if you're in a circumstance where you would actually need cache for a single image you'll already be in a lot of pain with the current GEGL code. > > When compiling Gimp, would any of the following compile options speed > things up while using Gimp? --without-libexif --without-aa > --without-libxpm --without-libmng --without-wmf --without-webkit > --without-librsvg --without-poppler --without-print --without-gvfs > --without-alsa --without-mac-twain --disable-gtk-doc > --without-script-fu --disable-python --without-dbus > --without-linux-input --without-hal > > And while I'm asking questions, what is the "Linux Input Controller > module"? Does it have anything to do with tablet support (I use a > tablet)? > > Sorry to be asking so many questions! I've been using Gimp a lot in > the last couple of weeks and liking it more and more and more, except > for the speed of execution. So I'm trying to figure out what the > options are for improving performance. > Nothing you can do at configure time is going to give you a meaningful performance improvement. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
On 2/28/13, Liam R E Quin wrote: > Quark Express used to have the notion of a "project folder", and if you > put fonts in it, they'd be activated only when working on the files in > that folder. I miss this, but gimp is scatterbrained when it comes to > folders, with export going to the last place where you saved something > two days ago for an unrelated project unless you are careful. I've noticed this odd behavior. A project approach would be nice. > Turning off 3D effects / compiz can increase drawing speed I use Icewm, which doesn't really have any "effects"; all the underlying kde eye candy (shadows on windows, hi-color icons, etc) has been eliminated. >> And do you have any idea what large file(s) might Gimp have been >> writing to its system configuration file that filled up 15GB? The undo >> history? > Yes, the tile cache and undo history. And if it was that big, your gimp > would *really* have had a limp. It was stopped in its tracks. I used "kill" to put it out of its misery. Elle ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
I followed Nicolas' suggestion and recompiled babl, gegl and gimp with CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3". The computer didn't blow up or anything. But I can't say whether Gimp runs any faster. The idea of optimization seemed promising and I found this thread: http://www.gimpusers.com/forums/gimp-user/14320-benchmarking-gimp-gegl#message66197 Does optimization depend on the actual processor? Is there a set of optimizations that makes sense for a circa 2005 AMD Opteron 252 (soon to be 262) processor? It has built-in floating point etc, was considered very fast when doing mathematical operations (that's why I picked it). What about these: -Ofast -ffast-math -ftree-vectorize ? Others? Is there any danger to the computer when recompiling packages using these flags? Or just the danger of the occasional math error? What about cairo, gtk, etc? Would it make sense to compile these from source using optimizations of some sort or another? Or are they already compiled with all sensible optimizations by openSUSE? On 2/28/13, Daniel Sabo wrote: > You might want to try running gimp with GEGL's swap turned off, this will > avoid filling up your drive with cache files: > GEGL_SWAP=RAM gimp-2.9 Does this mean Gimp and gegl would be competing for my meagre 4gb of ram? I didn't know gegl wrote cache files. Where does gegl write its cache files? > If you don't have OpenCL set up forcing it off will give a bit of a > performance boost (due to a bug in the detection code): > GEGL_USE_OPENCL=no GEGL_SWAP=RAM gimp-2.9 How does one set up OpenCL? Is it just a matter of having the right graphics card and driver? I will try both ways, with and without opencl, and with nvidia driver and nouveau driver (both have OpenCL support, it seems) and see if there seems to be a difference. Is there a way to tell Gimp to use or not use OpenCL? Or a way to tell if it really is being used? > Painting speed is due to bugs in GEGL and Gimp's paint core, there's really > nothing you can do right now to get it speedy. Ah, well, someday... Other things are also slow. Just hiding/unhiding a layer is slow, until the image is resized down. 768x512 is reasonably fast, though the brush is still slower than I'd like it to be (but useable). When compiling Gimp, would any of the following compile options speed things up while using Gimp? --without-libexif --without-aa --without-libxpm --without-libmng --without-wmf --without-webkit --without-librsvg --without-poppler --without-print --without-gvfs --without-alsa --without-mac-twain --disable-gtk-doc --without-script-fu --disable-python --without-dbus --without-linux-input --without-hal And while I'm asking questions, what is the "Linux Input Controller module"? Does it have anything to do with tablet support (I use a tablet)? Sorry to be asking so many questions! I've been using Gimp a lot in the last couple of weeks and liking it more and more and more, except for the speed of execution. So I'm trying to figure out what the options are for improving performance. Elle -- http://ninedegreesbelow.com - articles on open source digital photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
On Thu, 2013-02-28 at 14:51 -0500, Elle Stone wrote: > On 2/28/13, Liam R E Quin wrote: > I switched to the nonfree nvidia distributed by openSUSE because the > nonfree driver manages the fan better. Do you think the openSUSE > version might be properly patched? Yes, that's fine, just avoid downloading the drivers from Nvidia's Web site. > > so I have 2,500 fonts installed right now (and many more that are not > > installed). > That's a lot of fonts! There are about as many again in my Adobe Font Folio folder. Quark Express used to have the notion of a "project folder", and if you put fonts in it, they'd be activated only when working on the files in that folder. I miss this, but gimp is scatterbrained when it comes to folders, with export going to the last place where you saved something two days ago for an unrelated project unless you are careful. [...] > I need 16-bit precision for working with linear gamma files. I'm > already switching back and forth between grayscale and RGB as needed, > but I wasn't sure if it made much difference. I also wasn't sure if > 16f vs 32f made any difference as gegl processes at double? precision > 32f. OK, for 2.9 I have not measured. [...] > > For more detail, say which operations exactly are unbearably slow > > I do a lot of painting with large and small brushes on layer masks. > That brush just crawls across the screen, makes real-time painting > impossible. I think I will try working on scaled-down files until the > masks are right, then scale up to the original size and drag the masks > over to the full-sized image file. Years ago there were programs that could automate this workflow. Turning off 3D effects / compiz can increase drawing speed, and so can clearing the undo history often (that might be changed in 2.9 though). I'm still using 2.7/2.8 because of some filters that I used a lot not being ported (and I'm too busy to think about porting them, sigh), e.g. "sharpen". > Regarding how to make optimal use of the available hard drives, there > was a time when working on one drive, with swap files on another > drive, etc really did make a big difference for image editing > applications. It still does, but if you have enough memory GIMP won't be accessing the disk while you work, and it won't make as much difference apart from startup and image loading times. > And do you have any idea what large file(s) might Gimp have been > writing to its system configuration file that filled up 15GB? The undo > history? Yes, the tile cache and undo history. And if it was that big, your gimp would *really* have had a limp. My guess is that post-gegl gimp will need much more memory, and this has been my experience so far. I have just ordered a desktop computer with 32G of ram... next will be to try and get xsane to speak 16 bits per channel (the widest my scanner offers) to gimp without requiring an intermediate file. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
You might want to try running gimp with GEGL's swap turned off, this will avoid filling up your drive with cache files: GEGL_SWAP=RAM gimp-2.9 If you don't have OpenCL set up forcing it off will give a bit of a performance boost (due to a bug in the detection code): GEGL_USE_OPENCL=no GEGL_SWAP=RAM gimp-2.9 Painting speed is due to bugs in GEGL and Gimp's paint core, there's really nothing you can do right now to get it speedy. - Daniel ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
On 2/28/13, Liam R E Quin wrote: > In the meantime, > (1) look at what other processes are running - e.g. in "top" you can > press M (not m) to sort processes by size, and the results can sometimes > be surprising... Thanks very much! for the tip on how to sort in top. > (2) in gimp... > even with more memory gimp goes faster if you clear the undo history > frequently. Save snapshots as needed... and then... to do this... > i) make sure the Undo history dock is visible > ii) press the Rubbish/Waste/Trash/Clean/Broom icon (it depends on theme) > at the bottom of the undo history dock to clear the undo history. > iii) make sure the title or status bar of gimp shows you memory usage, > and when it grows by more than about 500MBytes, clear the history again. These are things I haven't been doing, will give it a try. > Make sure you have the latest driver offered by your Linux distribution; > the non-free drivers for nvidia and ati cards make a huge difference but > they ypically need ot be patched slightly by your Linux distribution or > things may go horribly slwoly and/or wrong (the drivers by default > overwrite some of the standard X libraries) I switched to the nonfree nvidia distributed by openSUSE because the nonfree driver manages the fan better. Do you think the openSUSE version might be properly patched? I was using nouveaux, could go back to it. > Turn off 3d desktop effects, as these can make gimp painting go two, > three, or more times more slowly (e.g. do not run compiz). >> *Does it matter how many system fonts are installed? > Doesn't seem to for me but I have 8G of ram. > so I have 2,500 fonts installed right now (and many more that are not > installed). That's a lot of fonts! >> 3. Image size, type, precision > 8-bit grayscale is fastest by far, and usually what I use. > Avoid transparency (alpha channel) if you don't need it, and flatten a > single-layer image after any transform operation. > For some filters you need RGB mode, and then can go back to greyscale > afterwards (sometimes it's surprising which filters they are - but as > the filters get ported to GEGL that will probably change) I need 16-bit precision for working with linear gamma files. I'm already switching back and forth between grayscale and RGB as needed, but I wasn't sure if it made much difference. I also wasn't sure if 16f vs 32f made any difference as gegl processes at double? precision 32f. >> *Does the total number of layers, masks, and/or alpha channels matter? >> Or is it just the overall image size in pixels? > It's (roughly) overall image size times number of image-sized layers. OK, good to know. Gimp seems to throw in alpha channels all over the place, not sure why. I never add alpha channels deliberately, but I've been deleting a lot of them. > For more detail, say which operations exactly are unbearably slow I do a lot of painting with large and small brushes on layer masks. That brush just crawls across the screen, makes real-time painting impossible. I think I will try working on scaled-down files until the masks are right, then scale up to the original size and drag the masks over to the full-sized image file. Regarding how to make optimal use of the available hard drives, there was a time when working on one drive, with swap files on another drive, etc really did make a big difference for image editing applications. I'm not sure about today's hard drives (and none of my drives are "today's"). Any thoughts on optimal layout of swap, GimpSwap, Gimp's temporary folder, and the actual working image files? And do you have any idea what large file(s) might Gimp have been writing to its system configuration file that filled up 15GB? The undo history? Thanks very much! for all the concrete information. I will be putting it to good use. One nice thing about having two processors instead of just the one is I'll be able to add twice as much ram, which seems to be the main thing needed for faster image editing. Elle ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
There is a little bit of c++ floating around here and there TTBOMK. - Make sure to wear safety goggles and a flak jacket. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
On 2/28/13, Nicolas Robidoux wrote: > Warning: Untested > > If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source, > maybe you should try > > CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ... CFLAGS is for c code CXXFLAGS is for c++ code, according to info gleaned from stackoverflow. Does Gimp, babl, and/or gegl have any c++ code? Does it hurt to use both? I think I'll give this a try, can't hurt, right? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
On Thu, 2013-02-28 at 12:16 -0500, Elle Stone wrote: > Short of building a new computer (not going to happen!), what else can > I do to improve Gimp performance? Which hardware upgrade(s) might give > the most performance improvement for the least amount of money? More memory. Max it out. In the meantime, (1) look at what other processes are running - e.g. in "top" you can press M (not m) to sort processes by size, and the results can sometimes be surprising... (2) in gimp... make the gimp tile cache be large - this is the amount of the image gimp will keep in memory, and for a 4G 64-bit system you want it to be 3G, for a 16G system I'd set it to 12 or 4G probably. even with more memory gimp goes faster if you clear the undo history frequently. Save snapshots as needed... and then... to do this... i) make sure the Undo history dock is visible ii) press the Rubbish/Waste/Trash/Clean/Broom icon (it depends on theme) at the bottom of the undo history dock to clear the undo history. iii) make sure the title or status bar of gimp shows you memory usage, and when it grows by more than about 500MBytes, clear the history again. > *We can replace the single processor with two slightly faster > processors. Will two processors make a difference? Somewhat, because one can be running gimp while the other is working on updating the screen, running the Web browser etc. > *Will reconfiguring the sata drives to use their fastest write speed > help? How much does write speed matter? Not significantly - read speed matters more on Unix/Linux systems, because writing todisk is done in the background aynchronously. > *Are there figures for optimal RAM, other than "as much as possible"? I have 8G for use with GIMP 2.7 or 2.8. I am about to order a system with 32G for using higher bit depths. > *How much does the GPU affect Gimp's processing speed? Would upgrading > the graphics card help? If so, how much of an upgrade would it take to > make a perceptible difference? Make sure you have the latest driver offered by your Linux distribution; the non-free drivers for nvidia and ati cards make a huge difference but they ypically need ot be patched slightly by your Linux distribution or things may go horribly slwoly and/or wrong (the drivers by default overwrite some of the standard X libraries) Turn off 3d desktop effects, as these can make gimp painting go two, three, or more times more slowly (e.g. do not run compiz). > *Does it matter how many system fonts are installed? Doesn't seem to for me but I have 8G of ram. $ fc-list | wc -l 2533 so I have 2,500 fonts installed right now (and many more that are not installed). > 3. Image size, type, precision > > Short of working on smaller files, what else affects how much > processing power Gimp needs? Specifically, > > *Does it make a difference what precision is used? 32-bit floating > point vs 16-bit integer? 8-bit grayscale is fastest by far, and usually what I use. Avoid transparency (alpha channel) if you don't need it, and flatten a single-layer image after any transform operation. For some filters you need RGB mode, and then can go back to greyscale afterwards (sometimes it's surprising which filters they are - but as the filters get ported to GEGL that will probably change) > *Does the total number of layers, masks, and/or alpha channels matter? > Or is it just the overall image size in pixels? It's (roughly) overall image size times number of image-sized layers. For more detail, say which operations exactly are unbearably slow Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] now: project ideas, was: unified transform tool
> Date: Thu, 28 Feb 2013 11:16:28 -0500 > From: l.elle.st...@gmail.com > To: pe...@mmiworks.net > CC: gimp-developer-list@gnome.org > Subject: Re: [Gimp-developer] now: project ideas, was: unified transform tool > > One thing I wish Gimp had is a better eyedropper tool for checking > color values. That is the one thing, practially the only thing, that > PhotoShop had (and presumably still has) that I wish Gimp had. The > PhotoShop eyedropper tool simultaneously showed RGB, CMYK, and LAB > values, at user-settable 8-bit, 16-bit, and 32-bit floating point > precision. Right now if I want to find a LAB value for a color I have > to export the image and open it with CinePaint or Krita. Speaking of LAB, GIMP can decompose an image into LAB layers but (1) the LAB decomp has problems with gamma encoding and (2) it's not something you can simply eyedrop whenever you want to. -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ways to improve Gimp 2.9 performance
Warning: Untested If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source, maybe you should try CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ... instead of the usual ./autogen.sh ... This may, or may not, make a noticeable difference. But if I was concerned about speed on my specific hardware, I'd try that first. And actually, if I do this with BABL and GEGL, make check within GEGL runs 26% faster on my modest laptop. So, my guess is that propagating the above suggestion to GIMP itself and a few key libraries may make things slightly less painful. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] now: project ideas, was: unified transform tool
On 2/28/13, Elle Stone wrote: > One thing I wish Gimp had is a better eyedropper tool for checking > color values. That is the one thing, practially the only thing, that > PhotoShop had (and presumably still has) that I wish Gimp had. The > PhotoShop eyedropper tool simultaneously showed RGB, CMYK, and LAB > values, at user-settable 8-bit, 16-bit, and 32-bit floating point > precision. Right now if I want to find a LAB value for a color I have > to export the image and open it with CinePaint or Krita. The Krita eyedropper is an even better model than the Photoshop eyedropper as the Krita eyedropper allows you to pick any RGB or CMYK color space to read values in, not just whatever is configured in preferences. That would be very useful for softproofing purposes when preparing an image for export/output. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Ways to improve Gimp 2.9 performance
When working with full-size camera files (3906 X 2602 px, not large compared to more recent cameras), Gimp runs at 100% CPU. Painting a brush stroke takes forever, my system swap drives fill up completely, etc. And yesterday Gimp filled up 15GB's worth of empty space in my home directory, leaving mere kilobytes of empty space - I'm not sure what file was taking up all the space, but it disappeared as soon as I closed Gimp. So I'm seeking advice on how to improve performance. I broke the question into 3 parts: 1. Hardware 2. Configuring Gimp 3. Image size, type, precision 1. Hardware What are the recommended (not miminal) system specifications for running Gimp? My system specs are: *1 single-core 2.6 GHz processor (the system board will take 2 processors, but only single core) *4GB ram; the system board will hold 16GB *256MB nvidia GeForce 7600 GTgraphics card *4 sata hard drives (I don't think I set the sata drives correctly to take advantage of their fastest write speeds) Short of building a new computer (not going to happen!), what else can I do to improve Gimp performance? Which hardware upgrade(s) might give the most performance improvement for the least amount of money? *We can replace the single processor with two slightly faster processors. Will two processors make a difference? *Will reconfiguring the sata drives to use their fastest write speed help? How much does write speed matter? *Are there figures for optimal RAM, other than "as much as possible"? *How much does the GPU affect Gimp's processing speed? Would upgrading the graphics card help? If so, how much of an upgrade would it take to make a perceptible difference? *Other possibilities? 2. Configuring Gimp: I'm running 64-bit openSUSE 12.2 with the Icewm minimal window manager. I set the Gimp tile cache size to 3GB, and I've followed much of Aaron Paden's Gimp setup advice: http://gimp.1065349.n5.nabble.com/gimp-2-8-prohibitively-slow-td34425.html Given that my computer has four physical hard drives, is there an optimal way to allocate GimpSwap, Gimp temporary folder, the location of the image files I'm working on, system swap, and etc? Here is my current arrangement: *HD1: all system folders, including the "tmp" folder that Gimp uses (Preferences/Folders). Also my home directory and all the Gimp configuration files are on HD1. *HD2: The GimpSwap (Preferences/Folders) is on this drive (along with other stuff, of course) *HD3: There is a 3GB system swap partition on this drive. Also this HD is where any images that I'm editing with Gimp are located. *HD4: There is a second 3GB system swap partition on this drive. *Would it help if I add a third system swap partition on the second hard drive? Or move the image being edited to the drive that doesn't have a system swap partition? *Does it matter how many dockers are open? *Does it matter how many system fonts are installed? *Would it help if the Temporary Folder and/or the GimpSwap had their own partition (not a whole separate drive, but a separate partition on an existing drive), instead of just their own folder? Should the Temporary Folder be on a drive separate from the Gimp configuration files? What are these two folders used for? *Anything else? 3. Image size, type, precision Short of working on smaller files, what else affects how much processing power Gimp needs? Specifically, *Does it make a difference what precision is used? 32-bit floating point vs 16-bit integer? *Does it make a difference if the image is grayscale rather than RGB (one channel rather than 3)? *Does the total number of layers, masks, and/or alpha channels matter? Or is it just the overall image size in pixels? *Anything else? I know Gimp 2.9 is a work in progress and likely things will get faster as times goes on. But in the meantime, any advice on how to improve performance would be greatly appreciated. Kind regards, Elle Stone -- http://ninedegreesbelow.com - articles on open source digital photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] now: project ideas, was: unified transform tool
On Thu, Feb 28, 2013 at 8:07 PM, Srihari Sriraman wrote: > Here's one thing that I've long wanted: > > Relative Layer Positioning > > I'm unsure about the name for such a thing, what I had in mind is: > > Often, I don't care much about exact positioning of a layer in the canvas. > I care more about where it lies with respect to another layer. > I care that one line of text is on the same level as another. > I would like one ellipse exactly at the same level as another. > I want to align all the elements of the footer in my poster. > I want to decide whether this layer I want to move should be horizontally > aligned or vertically aligned with the adjacent layer. Are you talking about adding more options to the existing Align/Distribute tool? Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] now: project ideas, was: unified transform tool
One thing I wish Gimp had is a better eyedropper tool for checking color values. That is the one thing, practially the only thing, that PhotoShop had (and presumably still has) that I wish Gimp had. The PhotoShop eyedropper tool simultaneously showed RGB, CMYK, and LAB values, at user-settable 8-bit, 16-bit, and 32-bit floating point precision. Right now if I want to find a LAB value for a color I have to export the image and open it with CinePaint or Krita. Another feature that would be nice (if it doesn't already exist and I just haven't found it yet), is the ability to highlight different "Zones" in an image. Lightzone had that ability. It's a pretty nice tool to have when working with curves and levels to alter image tonality, especially for people with monitors that are not properly calibrated/color-managed and so can't be relied on to give good visual feedback. Elle On 2/28/13, peter sikking wrote: > Alexandre Prokoudine wrote: > >> On Sun, Feb 24, 2013 at 4:09 PM, peter sikking wrote: >> >>> meanwhile, I am looking for a new small design project >>> to put before my students in a months time. any ideas. >> >> It seems that folks who create textures for 3D projects really want us >> to build advanced features on top of the new save/export model. >> >> One such feature is mentioned in the GSoC2013 page: being able to >> export/overwrite from sets of layers. > > > it would not be bad if some more ideas popped up. > > thanks, > > --ps > > founder + principal interaction architect > man + machine interface works > > http://blog.mmiworks.net: on interaction architecture > > > > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > -- http://ninedegreesbelow.com - articles on open source digital photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] now: project ideas, was: unified transform tool
Here's one thing that I've long wanted: * * *Relative Layer Positioning * I'm unsure about the name for such a thing, what I had in mind is: - Often, I don't care much about exact positioning of a layer in the canvas. - I care more about where it lies with respect to another layer. - I care that one line of text is on the same level as another. - I would like one ellipse exactly at the same level as another. - I want to align all the elements of the footer in my poster. - I want to decide whether this layer I want to move should be horizontally aligned or vertically aligned with the adjacent layer. I'm sure I could think of a few other use cases, but this I think is roughly it. The feature is quite evidently not new. We've all used it in many apps. I just thought I'd put my need out there. On Thu, Feb 28, 2013 at 9:26 PM, peter sikking wrote: > Alexandre Prokoudine wrote: > > > On Sun, Feb 24, 2013 at 4:09 PM, peter sikking wrote: > > > >> meanwhile, I am looking for a new small design project > >> to put before my students in a months time. any ideas. > > > > It seems that folks who create textures for 3D projects really want us > > to build advanced features on top of the new save/export model. > > > > One such feature is mentioned in the GSoC2013 page: being able to > > export/overwrite from sets of layers. > > > it would not be bad if some more ideas popped up. > > thanks, > > --ps > > founder + principal interaction architect > man + machine interface works > > http://blog.mmiworks.net: on interaction architecture > > > > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > -- Srihari Sriraman ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] now: project ideas, was: unified transform tool
Alexandre Prokoudine wrote: > On Sun, Feb 24, 2013 at 4:09 PM, peter sikking wrote: > >> meanwhile, I am looking for a new small design project >> to put before my students in a months time. any ideas. > > It seems that folks who create textures for 3D projects really want us > to build advanced features on top of the new save/export model. > > One such feature is mentioned in the GSoC2013 page: being able to > export/overwrite from sets of layers. it would not be bad if some more ideas popped up. thanks, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
