Re: [Gimp-developer] Finding out what happens when compositing layers
On Sat, Sep 17, 2011 at 8:36 AM, Ofnuts ofn...@laposte.net wrote: ** On 09/16/2011 02:20 AM, David Gowers (kampu) wrote: In GEGL, the layer mode code is autogenerated from formula strings -- see operations/generated/math.rb The opacity behaviour is not documented there, but my understanding is that the alpha of the underlying composite is preserved, and opacity only effects how much of the layer's COLOR channels are applied (per the standard blending formula). On Fri, Sep 16, 2011 at 7:09 AM, Ofnuts ofn...@laposte.net wrote: I'll trying to find out what happens when a layer is in subtract mode with a global opacity not one or zero (i.e. what computations are done with the pixels values of the composite image of the layers below, the pixel values of the layer, and the general opacity). I have a git extract of the Gimp source code (and of gegl babl) but got lost... Can someone help? Well, I know that in Normal mode, I have in each RGB channel: Composite=Over*alpha+Under(1-alpha) (assuming Under is fully opaque), but in Subtract mode, I would have several possibilities No, you just subtract Over from Under with no multiplication, then you perform a RGB (not RGBA) Composite of the result and Under, to produce the final composite. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Finding out what happens when compositing layers
In GEGL, the layer mode code is autogenerated from formula strings -- see operations/generated/math.rb The opacity behaviour is not documented there, but my understanding is that the alpha of the underlying composite is preserved, and opacity only effects how much of the layer's COLOR channels are applied (per the standard blending formula). On Fri, Sep 16, 2011 at 7:09 AM, Ofnuts ofn...@laposte.net wrote: I'll trying to find out what happens when a layer is in subtract mode with a global opacity not one or zero (i.e. what computations are done with the pixels values of the composite image of the layers below, the pixel values of the layer, and the general opacity). I have a git extract of the Gimp source code (and of gegl babl) but got lost... Can someone help? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tab in Single Window-Mode
I thought we had cycling by some means.. AH, yes. Alt+Tab. Also, Alt+[123456789] works to switch to a particular tab, in a similar way to tabs in Firefox. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool
Hello, On Sat, Mar 26, 2011 at 8:20 PM, Mohit _ mtan.n...@gmail.com wrote: Hi, In the undo section it is mentioned that until the final pixel recalculation is done user should be able to undo every single step, though after that user should be able to undo the aggregate transformation only. Does this means that we would have to maintain another action stack just for unified transformation tool, or does gimp currently also maintains two different stacks, one for the current tool and one global stack for actions. If this is the case some reference to where it happens in code would be great. Although I'm nobody official, I believe that this would happen through the undo-group mechanism. That is, when the latest group of undos was not 'closed', we should undo within the group, and once it is 'closed', we should undo the group as a unit (undoing an undo group as a unit is what currently happens in general) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
On Sun, Mar 20, 2011 at 9:22 PM, Ashok1288 asok1...@gmail.com wrote @Alexandre Prokoudine Actually I was referring about the algorithm (Existing in current GIMP Versions) to get familiar with... Do you mean the heal tool? app/tools/gimphealtool.* app/paint/gimpheal.* are where you should look for a start! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] X stuck on to start of all libtool options...
Conclusion: The issue was, I had somehow managed to install a copy of the various autotools in /usr/local/ and they were being used instead of the ones in /usr/. My solution was simply to delete those binaries. GIMP is now happily compiling :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] X stuck on to start of all libtool options...
Looks like this is the actual issue: After removing 'configure', it's apparent that 'autogen.sh' doesn't regenerate it, instead giving ambiguous errors/warnings.. For anyone else's reference, this occurs with autoconf 2.68 automake 1.9.6 + 1.11.1 glib 2.26.1 gtk 2.22.1 output log of './autogen.sh --prefix=/usr' follows: WARNING: aclocal's directory is /usr/local/share/aclocal, but... no file /usr/local/share/aclocal/glib-2.0.m4 You may see fatal macro warnings below. If these files are installed in /some/dir, set the ACLOCAL_FLAGS environment variable to -I /some/dir or install /usr/local/share/aclocal/glib-2.0.m4. [... (repeats x 4)] aclocal:configure.ac:425: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library aclocal:configure.ac:450: warning: macro `AM_PATH_GLIB_2_0' not found in library aclocal:configure.ac:479: warning: macro `AM_PATH_GTK_2_0' not found in library configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/local/share/aclocal/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is expanded from... /usr/local/share/aclocal/libtool.m4:5560: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from... /usr/local/share/aclocal/libtool.m4:2783: _LT_AC_LANG_C_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:2782: AC_LIBTOOL_LANG_C_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... /usr/local/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... /usr/local/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... /usr/local/share/aclocal/libtool.m4:6548: AM_PROG_LIBTOOL is expanded from... configure.ac:157: the top level configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/local/share/aclocal/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is expanded from... /usr/local/share/aclocal/libtool.m4:2864: _LT_AC_LANG_CXX_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:2863: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:1908: _LT_AC_TAGCONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... /usr/local/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... /usr/local/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... /usr/local/share/aclocal/libtool.m4:6548: AM_PROG_LIBTOOL is expanded from... configure.ac:157: the top level configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/local/share/aclocal/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is expanded from... /usr/local/share/aclocal/libtool.m4:5560: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from... /usr/local/share/aclocal/libtool.m4:4177: _LT_AC_LANG_GCJ_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:4176: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:1908: _LT_AC_TAGCONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... /usr/local/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... /usr/local/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... /usr/local/share/aclocal/libtool.m4:6548: AM_PROG_LIBTOOL is expanded from... configure.ac:157: the top level configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:369: _LT_AC_SYS_LIBPATH_AIX is expanded from... aclocal.m4:5554: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from... aclocal.m4:2789: _LT_AC_LANG_C_CONFIG is expanded from... aclocal.m4:2788: AC_LIBTOOL_LANG_C_CONFIG is expanded from... aclocal.m4:86: AC_LIBTOOL_SETUP is expanded from... aclocal.m4:66: _AC_PROG_LIBTOOL is expanded from... aclocal.m4:31: AC_PROG_LIBTOOL is expanded from... aclocal.m4:6542: AM_PROG_LIBTOOL is expanded from... configure.ac:157: the top level configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679:
Re: [Gimp-developer] X stuck on to start of all libtool options...
'export ACLOCAL_FLAGS=-I\ /usr/share/aclocal' before running the './autogen.sh --prefix=/usr', solves the problem. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] X stuck on to start of all libtool options...
actually no, it only allows the autogen to complete successfully, silliness like: /bin/sh ../libtool --tag=CC --mode=link gcc -Os -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -Wmissing-format-attribute -Wformat-security -o gimptool-2.0 gimptool.o -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpng14 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 ../libtool: line 869: X--tag=CC: command not found ../libtool: line 902: libtool: ignoring unknown tag : command not found ../libtool: line 869: X--mode=link: command not found ../libtool: line 1036: *** Warning: inferring the mode of operation is deprecated.: command not found ../libtool: line 1037: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../libtool: line 2281: X-Os: command not found ../libtool: line 2281: X-Wall: command not found ../libtool: line 2281: X-Wdeclaration-after-statement: command not found ../libtool: line 2281: X-Wmissing-prototypes: command not found ../libtool: line 2281: X-Wstrict-prototypes: command not found ../libtool: line 2281: X-Wmissing-declarations: command not found ../libtool: line 2281: X-Winit-self: command not found ../libtool: line 2281: X-Wpointer-arith: command not found ../libtool: line 2281: X-Wold-style-definition: command not found ../libtool: line 2281: X-Wmissing-format-attribute: command not found ../libtool: line 2281: X-Wformat-security: command not found ../libtool: line 2450: Xgimptool-2.0: command not found Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. Please consult the The X.Org Foundation support at http://wiki.x.org for help. still happens. Haven't found a solution, yet. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] X stuck on to start of all libtool options...
I've just tried compiling BABL, with similar results. compiling GLib says, point blank, You must have libtool = 2.2 installed to compile GLib. Install the appropriate package for your distribution, or get the source tarball at http://ftp.gnu.org/gnu/libtool/ so, it looks like recent Arch Linux libtool setup is somehow FUBARed (In a way I can't fix by recompiling+installing the official source over the top.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dropping Scheme with gimp 2.8?
IIRC there was some discussion of this idea - script-fu ending up as an independent plugin rather than one maintained within the GIMP code base. Basically, script-fu ending up in the position that PyGimp has been in -- an optional extra rather than part of the core installation. That's the idea. There has only been discussion. No concrete plans have been made. On Fri, Dec 17, 2010 at 12:24 PM, Andreas_P kyel...@yahoo.com wrote: In the German Gimp Forums I've had a little discussion with Michael Schumacher and houz (don't know real name for now) schumaml wrote: I would give Python a go, instead of Scheme... schumaml; wrote: Mittelfristig fliegt Scheme eher raus, und alle Skripte in GIMP werden in Python sein. Die einzige Hürde dafür ist noch die Verfügbarkeit für Microsoft Windows - dort ist der typische Nutzer nicht in der Lage, Python und drei Module zu installieren - aber das wird sich spätestens mit den 2.8-Installerpaketen geben. On the longterm, Scheme isn't going to stay, and all scripts in GIMP will be written in Python. The only hurdle against it is, the availability for GIMP on MS-Windows - the typical (dumbnut user) can't install Python and three modules for using GIMP - but this thing will be history - ultimately with the installer packages within 2.8... I would be glad when Aliens were behind it, it seems more serious. Schumaml; was one of the first persons to push a python integration into GIMP on Windows... And he has some sort of credibility when saying... Scheme isn't to survive here and later houz wrote: It is a thing of parting ressources, Scheme would be wasting them, we (GIMP Dev-Team) cannot support every backend for scripting. So, your turn GIMP-Dev Community (Hopefully I am soon good enough to get my code accepted within git) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Cage transform questions
On Sat, Nov 6, 2010 at 11:29 PM, Rob Antonishen rob.antonis...@gmail.com wrote: Another 'bug' is that the cage tool doesn't work on indexed images. Not that I would expect it to. Can it be disabled for indexed images? Doesn't work how? It works for me.. just not 100% like I want it to. (ie. interpolation is not helpful). I'm using git master (31aa09a11f2a2486c4cf9ab69104019d97c1d68a) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Cage transform questions
On Sun, Nov 7, 2010 at 2:45 AM, Rob Antonishen rob.antonis...@gmail.com wrote: Doesn't work how? It works for me.. just not 100% like I want it to. (ie. interpolation is not helpful). I'm using git master (31aa09a11f2a2486c4cf9ab69104019d97c1d68a) I just did a pull make/make install. I don;t know how to get the git master number :( type git log in your shell Providing you haven't added additional patches or switched to an alternate branch, the hash belonging to the topmost entry will be the one you want. I started with this image: http://gimpchat.com/files/196_funnydog1.png And using a simple (4 point) cage deform get this: http://www.majhost.com/gallery/ffaat/gimp/more2/196_funnydog1.png Aha! I can reproduce this! The interpolation is actually completely borked in all indexed cases (it interpolates as if the indices were grayscale values).. but if the image color map is sorted by brightness, this often produces approximately correct results anyway. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Cage transform questions
Hi,
I've just been trying out the cage tool (recently merged into GIT head)
I really like that I can just sketch up something like
http://img.photobucket.com/albums/v449/neota/tech/1.png
and gooily bend it into something like:
http://img.photobucket.com/albums/v449/neota/tech/2.png
I have two questions...
* What does 'Fill from first point' do?
('first point' is likely the first point you clicked when defining the
cage.. but if fill from first point is NOT checked, where does the
cage code fill from?)
* Are there any plans to provide an option to use nearest-neighbour
sampling? The interpolating sampler works well for photographic
images; for indexed or low-color images, I so far find that the
interpolation makes the result uglier than the original, due to a)
destruction of intentional hard edges or b) colors being remapped
after interpolation
Curious,
David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Cage transform questions
Also (should I file a bug report for these?) * Frequently, when closing the cage by clicking on the first point, the point that was just placed ends up next to the first one * When =1 point is outside image bounds, pixels outside the resultant shape become black (regardless of the current BG color). For greyscale images, mid-grey is the color which appears ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Indexization seems to be broken
Just messing around with GIT head, I found that indexized images appear to be displayed in grayscale (ie as pure index-values rather than colors.)* Hopefully this is an intentional temporary measure and not an accidentally caused bug. * saving an image and then reloading it makes it display properly in color. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Detecting closure of selection
On Sun, Oct 10, 2010 at 7:47 AM, Ofnuts ofn...@laposte.net wrote: Assume I have a selection on small area (for instance a 20px circle), and I invert it. Now, if I grow the selection by a sufficient amount (10px in this case), everything gets selected. Is there a practical, fast way, to detect this case, i.e, that the selection covers the whole layer (or image?) and that no pixels remain unselected? I assume that inverting the selection again and testing for empty would work, but that would be two selection inversions in the normal case and that may be a bit costly. Testing for empty and for full are the same operation (an empty sel is equivalent to a full one) HTH ___ 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 4:24 AM, Jacopo Corzani corz...@gmail.com wrote: Well, adjustment layers is what GIMP developers seem to refer to as layer abuse :) There are different ways to implement non-destructive editing. Would you be interested to find out more? Alexandre Prokoudine http://libregraphicsworld.org Hi Alexandre, i could agree with your consideration of layer abuse but adjustment layer is a quick and robust solution to manage effects whenever i want. Changing a curve (or any other effect) dynamically without duplicate layers would be a great. Sure,i'm interested to find another quick way to handle effects during time without do an layer abuse, but i don't have any ideas that speed up work like adj layers... :) Thanks for your response. Peter Sikking has already expressed a way of doing this: you attach a list of effects to a layer or layer group. 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Getting new layer modes fit for inclusion
On Tue, Aug 24, 2010 at 10:22 AM, Rupert Weber g...@leguanease.org 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) 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 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. So, as I already said, I consider the patch done now. Things I will still be glad to change: - Location/name of new file, name of exported functions, etc. - Any bug fixes, of course. - The open issues I had mentioned earlier (file formats, GIMP_COMPOSITE_BLEND et al.) Things I won't change: - Optimization. I currently see no further optimization potential without uglifying the code. - As to putting the conversion outside the loop: Yes it can be done, but even if it is done, it doesn't belong in this patch. The current implementation in gimp_composite_generic.c is symmetric to the existing layer modes. So any such un-looping would be a general change to that file, not specific to the new layer modes. - Inlining: Brutally inlining everything can be done and gives some 12%-15% performance increase. -- But I don't want to get my hands dirty with that.. :o) 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). GEGL modes are something else. I believe what Sven was suggesting is to implement your conversion code in a BABL extension, and use that to do color conversion in the layer modes; Not to use GEGL for that whole thing. That said... 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 absolutely agree that this patch should be applied promptly. It implements much-wanted functionality in an effective and efficient way. Separating the new color conversions into their
Re: [Gimp-developer] new layer modes patch posted
On Sun, Aug 15, 2010 at 3:22 AM, Rupert Weber g...@leguanease.org wrote:
I posted a new version (v3) of the layer modes patch (split in two) to
http://bugzilla.gnome.org/show_bug.cgi?id=325564
The libgimp functions and the layer mode stuff are each in a separate
patch now.
[The message I wrote there is misleading. along with the other v3
patch was just supposed to mean that it accompanies the first patch.
There is no third patch missing.]
Works quite well (and fast!) IMO. Infinitely better than the old modes :)
I noticed when I tried to pull the latest changes from GIT HEAD, that
the automatically-generated changes to :
app/base/base-enums.c
libgimp/gimpenums.h
tools/pdbgen/enums.pl
(which, while being auto-generated, also change infrequently enough
that they *are* version-controlled),
have not been included. That means, after applying the 2 (or 3)
patches and rebuilding GIMP, these outstanding changes prevent you
from pulling the latest changes.
I suggest merging these changes with the patch to libgimp, since that
is the one that introduces the new enums.
Actually, I can do that..
But you might still want to know how..
1. Create a commit containing the missing changes
2. Use 'git format-patch' to generate a patch from it
3. Rewind to just before your first patch ('git reset --hard commit id')
4. Apply the libgimp patch, then the patch created in step 2
5. 'git rebase -i commit id' to rewrite part of your local history
(where commit id is the hash of the commit immediately before the
libgimp commit)
6. change the line relating to the commit created in step 1, to say
'squash' instead of 'edit', save, and exit.
7. 'git format-patch HEAD~..HEAD'. This will output the amended libgimp patch.
I'll attach the amended patch to bug #325564.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer modes - open questions
On Mon, Aug 16, 2010 at 4:46 AM, Rupert Weber g...@leguanease.org wrote: There are still some issues that I either blissfully ignored or took the least-cost route on: (3) paint-funcs layer modes Is the layer mode code in app/paint-funcs ever used? grepping the entire codebase only lists paint-funcs.c as a user of dissolve_pixels() and of layer_*_mode() [therefore *_pixels() are dependencies too] AFAICS the code in paint_funcs.c which depends on the layer-modes.c code is used indirectly by: * the merge-down code [app/core/gimpimage-merge.c] * the projection code [app/core/gimplayer-project.c] * the fade code [app/core/gimpdrawable-combine.c] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
On Thu, Aug 12, 2010 at 7:24 AM, Alexia Death alexiade...@gmail.com wrote: On Wednesday, August 11, 2010 06:04:36 David Gowers wrote: On Wed, Aug 11, 2010 at 12:12 PM, David Gowers 00a...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR fam...@infernal-iceberg.com wrote: GIMP is a jerk (I get cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA. It is. Looks like I have a bug to file. Not with GIMP. Its a bug in the wacom driver. Top end of the pressure scale ends up with pressure 0. And I have a vague memory thats fixed somewhere in development pipeline. I have the fixed version already.(0.10.8) Believe me, after experiencing THAT problem, I would know about it. Generally that problem resulted in the stroke ending and no more drawing until I eased off on the pressure. This is a different bug (and, MyPaint also uses the GTK+ input code and does NOT experience this bug at all no matter how fast I move) ___ 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 5:58 PM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, On Tue, Aug 10, 2010 at 9:27 AM, Martin Nordholts ense...@gmail.com wrote: 2. We need to define a usable plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser... I don't think registering a fixed preview image is good enough, it Believe me, I really want a dynamic preview on the current image :-) But, it's not practical as some plugins take way too long to operate - trying to create a preview on the current image might take way too long to be any good. Create the previews in an idle handler (ie. let the user select the operation even when the preview is not rendered, and cancel any pending preview rendering when a selection is made) We could combine this with the stored previews idea: show the stored preview with an overlay that indicates rendering of the preview for the current image is in progress... On Tue, Aug 10, 2010 at 3:31 AM, David Gowers 00a...@gmail.com wrote: On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility The reason I made the description above is that the plugin browser is very limited.. you cannot activate non-plugin menu items (for example, I'd like to be able to access 'scale image' and 'scale layer' via a search -- I don't use them enough to warrant keyboard shortcuts, but enough that some acceleration is warranted. The same thing goes for virtually all GIMP-GAP operations). Sorry for my bad phrasing of the question - let me rephrase it: what is left other than exposing the searchbox from there? Supporting '*' wildcards would be helpful IMO, but I agree that the shortcuts search is pretty adequate for this, when connected to activating the chosen action. The searchbox there allows to find non-plugin actions, and these are very neatly organized under several categories. When you search, the categories are already expanded so you can see all the results, organized, right away. That aspect is certainly good. What I suggest, it is possible to embed binary data in script-fu scripts, but it's not easy/fun/simple. What I suggest is that as a part of the refactoring process of the plugin system, we will allow procedures to register a sample procedure. This procedure will be called once to generate a preview image. But this procedure is probably a bad idea (since generating the preview will take time, and this can be long...) The other option is to ship example images with script-fu scripts and to allow them to return a pointer to that image for their preview. This sounds more reasonable to me. Yes. However IMO, if we do that, we should not stop at previews for script-fu. We should provide a directory for general storage of these previews for any plugins. That way, it is much easier for ordinary users to provide improved previews for their most used plugins. One of the things we should remember is that we should still have some sort of seperation between the plugin/script browser and between the general procedure browser. Because if we want things like preview for every action, it would be rather useless to have previews for internal operations such as raise layer. Certainly; there are actually four classes of actions: 1. actions owned by plugins, which have a menu item 2. actions owned by the GIMP core, which have a menu item (eg 'Raise layer') 3. actions owned by the GIMP core, which don't have a menu item (eg. 'Increase Aspect') Mostly we will want to search the union of 1 and 2, IMO. And sometimes, we will want to search 3 (eg. I would use this for tweaking the color picker radius, setting the brush scale to default (=1.0)) . That is possible without any need to change current code. I would like to point out anyway, that the PDB browser and the current keyboard shortcut dialog search, search different things... PDB browser searches PDB entries, KB shortcut dialog search searches action internal names+ user-visible names. It's definitely important to make that distinction apparent to the user, so that they don't expect to see PDB entries popping up in the action search box which is the subject of current discussion. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
In view of what Alexia just said: Your problem is interesting, because its contrary to what I would expect and experience myself. For me GIT version performs about twice as good as 2.6, especially with large brushes, and thats with compositing on. To get the 25px round brush to lag at all I have to move lightningfast. and then it usually catches up in under 2 seconds. My hardware configuration is admittedly slightly better than yours... But 25px brushes really shouldnt be a problem anywhere. I am suspecting your Xorg server version, config, or video hardware has changed as well as your GIMP version. I found myself, that redraws in paint programs were intolerably slow until I added the Option AccelMethod XAA to the video card config in my xorg.conf. (EXA is the default, and makes 3d performance much better, but unfortunately seems to cripple 2d painting performance on my card. XAA might effect compositing (as in WM compositing) speed significantly instead.) Perhaps you could try the above option and see if it makes any difference. FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this problem does not occur on NVidia cards and newer ATI cards. [incidentally, 2.7 uses Cairo more for display related things (not for rendering brushes IIRC, but of course in order to see the rendered brush strokes, the area must be displayed). It's possible that this impacts your system significantly while using the default EXA acceleration. So it could be a combination of a change in GIMP and annoying hardware/driver misconfiguration.] HTH, another Dave :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR fam...@infernal-iceberg.com wrote: Hi, 00a...@gmail.com (2010-08-11 at 0928.56 +0930): I found myself, that redraws in paint programs were intolerably slow until I added the Here it was general. GIMP's interface took a couple of seconds to redraw, but so did FF while scrolling (slideshowing would describe it better). Option AccelMethod XAA to the video card config in my xorg.conf. (EXA is the default, and makes 3d performance much better, but unfortunately seems to cripple 2d painting performance on my card. XAA might effect compositing (as in WM compositing) speed significantly instead.) Perhaps you could try the above option and see if it makes any difference. FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this problem does not occur on NVidia cards and newer ATI cards. Other thing to try is keeping EXA but with: Option MigrationHeuristic greedy I've just tried this and it works for me. MyPaint becomes is just as responsive as with XAA, except for the panning. GIMP is a jerk (I get cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA. 3d performance in Blender is fairly poor (but noticably better than with XAA) Panning in both MyPaint and GIMP (and Firefox) is still noticably slower. Fast smooth panning is important to me, so I will switch back to XAA. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
On Wed, Aug 11, 2010 at 12:12 PM, David Gowers 00a...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR fam...@infernal-iceberg.com wrote: GIMP is a jerk (I get cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA. It is. Looks like I have a bug to file. ___ 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 6:21 AM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility As far as I know, menus are searchable and the best example is the keyboard shortcuts dialog which has a searchbox to find the GIMP action you'd like to use. However, that action is not immediately activateable. What I personally envision is something like the completion dialog that you can find in GTKTreeViews (for example, typing something in when the file list in a file selection dialog is focused, offers you a choice of the possible items. And upon selection from that sub-list, the file is immediately chosen.) So I asked on #gimp and I was told there was a discussion on IRC about finding a more usable replacement to the plugin browser. The reason I made the description above is that the plugin browser is very limited.. you cannot activate non-plugin menu items (for example, I'd like to be able to access 'scale image' and 'scale layer' via a search -- I don't use them enough to warrant keyboard shortcuts, but enough that some acceleration is warranted. The same thing goes for virtually all GIMP-GAP operations). So, to get a formal record of this discussion, I'm starting it on the mailing list again. Here are points which should be considered: 0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree? one or more strings, per your Tags suggestion. 1. GEGL ops should really be integrated in the GIPM menus. As What's a GIPM ? :D someone said, it's like the old script-fu menu - it was wrong. We don't have to force the user to remember what's a GEGL op (which will be accessed using the GEGL tool) and what's a regular plugin/script. It's a bit offtopic, but we should find a way to implement gegl plugins with a custom GUI, and register them like regular plugins in the menus. Having a search that will once point to a plugin and once activate the gegl tool, is a very bad idea... Though we need to consider, that a GEGL op can do much more than simply be applied to the image once, destructively. If we make GEGL ops available in the menus, we should aim to do so in a way which does not trap us in a corner if, for example, we want to in the future be able to add that op into the image as a non-destructive effect on the current layer/layer group. 2. We need to define a usable plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature I agree with you, but believe that we need to be more definite than that: previews should show clearly the before and after. I favor GMIC's horizontally split preview style for this -- it avoids wasting space, and instead of tiling two complete images next to each other, you get to see half of the image as it would be if it were filtered. In some cases, the vertically split style may be more appropriate. request of having a logo script browser... Well, if we did what you outline here, how would Script-Fu scripts handle the necessary embedding of binary data (I don't mean to imply that they couldn't, just that I do not know exactly how well they can handle this kind of binary string literal). 4. Another option, instead of categories and sub-categories, is tagging - like the brushes work in 2.7 (unlike categories - there are no sub-levels, and each plugin can be in many places) The current api allows this, minus the 'no sublevels' criteria, since a procedure can register in multiple menu paths. I like the tagging concept, especially if it turns out to be a cheap solution to menu editing (If I could make my own tag, tag all the stuff I use most with it, and assign a shortcut to bring up that menu, that would really help my efficiency... Or, if I could remove the 'FILE' tag from the 'Print' menu item, I would no longer have to contend with a menu item that I never ever use. Note that if we could untag, we need a virtual 'tag' that items without a tag could belong to.. '-' or '!' possibly.) I think we should tag, and predefine a tag set that should be adequate for most existing plugins. User tagging is important because plugin authors may not always be available or be willing to add this information. [this sort of ties into the 'Get Hot New Stuff' proposition -- it would be nice to be able to distribute the task of correct plugin tagging across users via a web interface) Hope I've given you something to think about :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please fix Color and/or Value transfer mode
On Wed, Jul 28, 2010 at 4:20 PM, Charlie De charlieco...@yahoo.com wrote: Since we released stable versions with this broken behavior we now have to maintain backward compatibility to it. It is considered very important that you can open your old XCF files in a new version of GIMP and get the same result as in the version you created them in. I suggest that implementing the improved functionality is of much higher priority than backwards compatibility with the old. Particularly in a project such as GIMP, where development resources are as precious as they are. You can tackle this with a marketing thought experiment: if you were to ask a group of GIMP users what they would prefer, speedy fixing of broken features, or insistence on backwards compatibility, which would the majority vote for? This is an erroneous dichotomy, because a failure to preserve backwards compatibility is itself a 'broken feature' GIMP is the definitive loader of XCFs. Any other format, it is nice if it supports perfectly, but hardly needed. Its own format, it MUST support perfectly, however it achieves that. It must load any sane XCF in such a way to produce just the same result as it ever did. Otherwise you create a situation where you are silently changing the meaning of people's XCF images. It's like you changed the symbol '2' to mean 'twice twice twice one' (that is, 8); People will still expect 2+2 to equal 4, not 16. Some people will notice that their maths comes out weird, some people won't. Regardless, it's just not reasonable to indirectly change the meaning of people's creations in this way. Besides, the appropriate and established way of addressing backward compatibility is through the handling of old files, not by refusing to implement improvements. Reading some of the discussions among the GIMP development team in relation to the issue of broken Color transfer mode was the first time I encountered the argument that it was preferrable to keep the broken functionality over fixing it, because a user might want to keep old rendering in the new version. What a nonsensical argument! Implausible, rather. Almost all of the improvements we could look at would be much more readily coded and tested with solid GEGL integration. This is something that we do not currently have, it's more like a well-constructed Frankenstein, with some systems having an option to use GEGL, others not, and none with GEGL as the default/only rendering system. Really solid and complete GEGL integration, IMO, would be far more of an asset to GIMP than any one other user-visible improvement, because of it's major synergistic effect on our ability to quickly write and test new image manipulation operations / combinations of operations. Old file handling only goes so far: XCF is not only GIMP's fileformat, but represents the way GIMP conceptualizes the notion of a complex image. When basic concepts change, it is normal to not be able to map the old information 100% accurately onto the new format. (that time is not yet, though.) Has there been a single user outside the dev team who expressed this view? At this stage I'd prefer to avoid the argument and let the team focus on the positive task of bringing out the next version. However, there will be bugs in new stable releases, in 2.8, 2.10 and beyond. So the argument of how those bugs are to be dealt with and what priority backward compatibility is to have will not go away. We might as well tackle it as we go along instead of delaying it. My understanding is that breaking compatibility is on the table for 3.0, *and no earlier*. Because of the change of paradigm between classic GIMP and GEGL-based GIMP, GIMP 3 XCFs would naturally be quite a different beast to GIMP 2 XCFs. This makes it a natural point to break compatibility at, since users will need to learn to do quite some things differently anyway. Before then, GIMP won't work differently enough to flag to the users that hey, things may not work quite the same as you're used to. If GIMP 2 can load GIMP 2 XCFs 'perfectly', and GIMP 3 loads GIMP 3 XCFs 'perfectly', then this is straightforward from a user point of view, no? OTOH if we change in the middle of a major version, it is not: GIMP 2 XCFs would be loadable by, say GIMP =2.8, and GIMP 2.8 would load GIMP 3 XCFs. That's unfriendly behaviour and much harder to remember. tl;dr version: There are good user-friendliness and programmer-efficiency reasons for leaving compatibility breakage until GIMP 3, and you have not presented any particularly compelling reasons for breaking compatibility earlier Have a nice day. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please fix Color and/or Value transfer mode
On Thu, Jul 29, 2010 at 12:28 AM, Liam R E Quin l...@holoweb.net wrote: Having said all that... I'd wondered myself why that photoshop trick of blurring a layer in mode colour didn't work well in gimp, but I don't know that this means gimp is wrong here. The right answer is to work out what the behaviour should be, for each mode, and do some tests to see if the implementation matches expectations. Be the same as some-other-program is not, of course, a goal for GIMP. And of course it would be nice to be able to fix camera noise, especially from lower-end and older cameras, in this way! BTW, of course this method requires a plugin, but GMIC can do this quite well (the a / b smoothness sliders in the LAB mixer can effectively smooth the coloration without effecting brightness; the denoising filters like 'anisotropic smoothing' also may be set to operate only on AB channels) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about getting involved in developing Gimp
On Thu, Jul 22, 2010 at 1:49 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Wed, Jul 21, 2010 at 5:43 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: xianghang liu xianghangliu at gmail.com writes: Hi, I am very interested GIMP and want to join the Gimp project as C developer. I am a first-year PhD student in computer vision. I would like to start with fixing some bugs and then implement new features and my final objective is gsoc 2011. Do you have any suggestions? Xianghang Liu This is just a suggestion from a user, so I have no idea how difficult or easy it might be - but if you are interested in adding a very helpful feature to Gimp please consider working on implementing automatic layer boundary management. I'll explain: currently a layer's boundary is managed by the user. after you create a layer, if you move it, say 100 pixels to the left, there will be a 100 pixel wide area on the canvas that you can't paint on. The user then has to set the layer boundary himself to include all the canvas. It would be great if this was managed by the software, so that whenever a user wanted to draw on an area outside the layer boundary, it would be automatically enlarged to allow him to do that. I've presented GIT master for a large audience today (200+ people) - after the presentation, the most requested feature at questions time, was also this one. Just noting that we still need the option to manage layer bounds ourselves. In particular, it seems common to paste something with the expectation that after anchoring it will be cropped to the underlying layer bounds, rather than expanding it. That should be straightforward. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about tools (and other) icons in GIMP.
On Thu, Jul 15, 2010 at 3:30 AM, Эллина Петухова ellinestu...@gmail.com wrote: Hello everybody. I want to sorry for my English because it's not my native language and i am not familiar with it. Also i am not a serious developer so if i talk something wrong or even bother you please tell me about that. Since i migrate to open-source programs i am using GIMP often and everything is great (and i am very much obliged to you). But one thing that has been distracting my attention at work is a bright and coloured icon theme. Searching the way to change them i founded a source code and icons inside in uncompiled form. It seems to be very good and i am tried to change them and compile package. So it works but it's not the way to share them with somebody. (and even install them convenient) I found some information about which compiled files are responsible for icons here: http://www.gimpusers.com/forums/gimp-developer/1-Gimp-Toolbar-Icons.html#msg56152 (it seems like your correspondence) And it's indicate that icons contained in the gimp-stock-pixbufs.h, gimp-core-pixbufs.h and gimp-wilber-pixbufs.h as i remember. But i can't find even one of them in my system. And there i get stuck. I think you understand that i want to find some files which are responsible for icon themes to be able to replace them. Adwise me please if it is not prevented and if it possible at all. P.S.: if you interested in what i want to do here is the example: http://gimper.net/viewtopic.php?f=1t=7764 http://gimper.net/viewtopic.php?f=1t=7764. Thank you very much and good luck! For an example of what Sven's talking about, see http://jimmac.musichall.cz/log/?p=30 Jimmac has made a Grayscale icon theme for GIMP, though it is probably somewhat out of date now, you can still see how the icon theming works. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
On Fri, Apr 9, 2010 at 6:51 PM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello Tor, I forgot to include the actual sources with my build (they were way to big and I forgot I had to do this), so I removed my build. Thanks for reminding me =) Did you modify the GIMP source? If not, you don't need to include the source itself; you just need to provide a up-to-date link to somewhere the source can be obtained. The GPL is specific on this point. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong font size
On Tue, Mar 16, 2010 at 11:20 AM, bruno brunomend...@gmail.com wrote:
Hi all,
I am web designer and I trying Gimp 2.6.8 in Debian Lenny (2.6.26-2) and
Ubuntu Karmic (2.6.31-14).
I found that, when I set font size to X pixels, Gimp converts it into
wrong size, i.e. 16 px at 72 ppi are 12 px, 16 px at 96 ppi are 12 px,
16 px at 300 ppi are 12 px, ... What's wrong?
Is it a bug?
I can understand that if Gimp use 72 ppi for fonts when I set 16 px it
converts it into 12 px. But what about other cases?
In Gimp 2.6, font sizes are based upon your monitor ppi, not the ppi
of the image. There is a section in Preferences ('Display', if I
recall correctly), which allows you to override this. This could be
regarded as a bug (particularly for anamorphic images (ie. those that
do not have square pixels.. like: 48x96ppi)
In recent development versions of GIMP, I understand that text size is
proportional to image ppi.
Hopefully that helps. I found your email confusing, as in my opinion,
if you input 16px, then what you should get is always 16px. However,
there are also other factors -- many fonts seem to be badly adjusted
(baseline too low, overall scale too small,...), so that you must
request much larger sizes to get the ordinary size you want (not only
in GIMP, but in all programs.). Have you checked your results with
different fonts?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding ability to reverse curves dialog
On Wed, Mar 10, 2010 at 8:19 AM, Jay Smith j...@jaysmith.com wrote: On 03/09/2010 04:39 PM, Jon Senior wrote: On Tue, 09 Mar 2010 16:30:58 -0500 Jay Smith j...@jaysmith.com wrote: I am not sure where the standard that you mention comes from. I had never seen black at bottom left (by default) until I started to use Gimp. Is there some actual scientific standard underlying that? Or just majority of programs? Or the programs you have used? Or? Maybe the programs I have used in the past were backward. I would suggest that they were. The curves are graphs plotting value in (x) against value out(y). Traditionally a graph starting at 0 for both axes would be drawn with the origin in the bottom-left. This naturally leads to a curves graph where black (0) is in the bottom-left and white (255/1023/...) is in the top-right. What programs have you used where this situation was reversed? Jon Jon, That is certainly possible. The one that most comes to mind is Photoshop 5.x. I have no idea what modern Photoshop and successors do. http://www.adobe.com/designcenter/photoshop/articles/phscs2at_learncurves_02.html White on the right, Same as GIMP, PSP, etc. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)
On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: I agree with Joao S. O. Bueno and disagree with David Bowers. Well, I'm glad you don't disagree with me, but who is that? Its better to make plugins meet the normal expectations of Python programmers (you can import any Python file to use pieces of it) than to add new conventions and directories for shared Python plugin code. Simpler is better? The normal expectations of Python programmers are that the main loop will be guarded. This is exactly the thing that allows you to import otherwise executable modules; without it, no guarantees can be made that the code you are importing will not interfere with global state in a way which causes your plugin to crash. You can depend on a specific version of a plugin which has known behaviour; In that case you prevent the user from upgrading that plugin, and you rely on knowledge of the internals of that plugin, which is very likely to get you into trouble if you ever need to upgrade it. The same principle applies to python scripts that are unguarded: importing them will, at the least, have significant side effects. Often they are entirely incapable of being cooperative. Hence, it's not practical to import a plugin module unless it specifically indicates that it is fit to be imported (by guarding the main loop) Often, authors don't plan their code will be useful to others. It's just serendipity. If authors don't plan to share code and put it in these new directories, it thwarts serendipitous reuse and experimentation. It is inconsistent for a duplicate call to register() to be harmless with a warning while a duplicate call to main() is fatal. Currently, the latter is serving the function of preventing the previously mentioned possibility of side effects of importing a plugin in this way. If there is another way of preventing that problem, then we could look at removing that aspect of main() calls. Otherwise, we absolutely must not. Also, new conventions and directories does not solve my wish to call pydoc on plugins (which is not very important. I hope to download a prototype Inspect plugin to gimp registry soon.) But it illustrates that you can't always anticipate what people will want to do. I wanted to do that too. Just because you want to do something, doesn't mean it's wise to do so. Calling pydoc on unguarded python modules is just as unpredictable as importing unguarded python modules. Why? Because the way it gets the documentation is by first importing the module in question. Furthermore, all GIMP plugins' dependency on the 'gimp' (and/or gimpfu, etc..) modules mean that even if they are in the module search path, pydoc's attempt at importing them will fail (because the gimp and gimpfu,etc.. modules are only available to Python scripts that are being run by GIMP).Changing the mechanics of main() would not effect that. If you don't believe that, it's easy to check; set PYTHON_PATH to your plugins directory (full, absolute path like /home/llkk/.gimp-2.7/plugins), start Python, and try to import one of those plugins as a module. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On Wed, Mar 3, 2010 at 10:16 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann s...@gimp.org wrote: On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: I wonder if importing a plug-in from another plug-in is really something that we want to support. If the goal is to share code, then perhaps the code that is worth sharing should be factored out into a Python module that the plug-ins can import. Every Python program is also able to be a python module that plug-ins can import. We should preserve this feature of the language. (For example, one can implement an app with a comand line interface, and then just add a GUI in another file that uses the functions defined on the stand-alone first file). I've considered this problem a fair bit, and my opinion is that if you want this functionality, you should simply guard your register()s. We cannot safely 'co-opt' python plugins that are not written with this functionality in mind, as they are designed to be run always in an independent process (hence they may do initialization which confuses the calling program, or vice versa); there is no modification to GIMP which could permit that, it is a logistical problem not a technical one. Allowing python plugins to make separate modules available on installation, similar to Sven's suggestion, seems to me the most practical suggestion. This means we would add two items to sys.path -- one the site modules* directory, and the other the modules* directory belonging to the specific user, which the installation of the plugin package could put modules into. We could further postulate that the normal python modules directory should be the destination of modules that do not require GIMP running in order to function, and only GIMP-requiring modules would be installed in it's modules* directory. I make this distinction because there are various good reasons not to install gimp-dependent modules in the global namespace (for example, pydoc and the general help() facility get confused because the imports of gimp modules fail.. so you can look up a specific module, but not search.) * I realize 'modules' is a term already used in the gimp directory structure. This is meant as a placeholder for something else...python-modules? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
On Wed, Feb 17, 2010 at 6:07 PM, Olivier oleca...@gmail.com wrote: For several weeks now (I compile the git version every Monday), the windows in normal mode (i.e. multi-window mode) behave in a weird way: I place them where I want them on one virtual screen, and then I move to another one virtual screen. When I come back, the windows have moved to a different place, always the same. I'm with Debian testing and GNOME. I can confirm this (although I'm using Arch Linux + AwesomeWM) : I put the toolbox over at the right edge of the screen. When I come back, it's squashed ridiculously narrow near the left edge of the screen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
On Wed, Feb 17, 2010 at 8:24 AM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death alexiade...@gmail.com wrote: 2. The painting of the matrix as showed in the specifications seems very hard, and I doubt it worths it. We can easily implement different colors for each row, and users will have to settle for a little border between the columns. http://www.pygtk.org/docs/pygtk/class-gtktreeview.html Looks like it is possible to disable cell borders (and I think it may be necessary when the cells are small like this-- we want to avoid the borders visually overwhelming the cell content. If we agree to give up the proposed matrix painting and choose what I suggested, it can be done with GtkTreeView without any special changes, but it will leave the simpler GtkTable our of the question (which is fine with me). 3. Adding the images with the link's color should be a bit tricky, but I assume that it can be done dynamically (by drawing those images after acquiring the link's color, instead of embedding ready bitmaps). 4. Popup window: Part 1 - the curves widget. This can definetly be stolen from the curves tool, no need to work twice. The only needed modification is that we can show some other curves at the background, and that we add min and max arrows. 5. Popup window: Part 2 - switching the tabs. This doesn't seem to bad, especially since we already have similar functionality in the curves tool. only two things seem problomatic: A treeview widget can't have a bitmap in it's header, And adding the bitmaps as the first row is ugly and probably not the right way to do this. The guys on the GTK mailing list will probably be able to help us out here. And another questions is, why do we have the same header images at the bottom? Adding a footer to a GtkTreeView isn't possible. Do we really need that? Here i'm defintly sure it's not worth the coding amount that it will require, and I personally find it confusing. I believe that this kind of measure is usually taken when the number of input variables is anticipated to increase (so perhaps you won't be able to see the top and bottom at the same time) I haven't seen anything that scary in here, but I doubt that I'll have time to touch it in this month. If I implement something like this on a dummy GtkWindow (instead of hacking GIMP's source code, which I don't excel at) as a stand-alone Gtk application, will it help? If so, I'll try to give it a shot. If you want to see how to use the TreeView and the CellRenderer, the gtk-demo program (which comes with GTK) has a nice example under Tree View/List Store. The code is very simple and in one of the columns you'll see the Toggle renderer. for example, one dock needs to hold 2.5 distinct views I haven't understood that sentence. Can you please explain (or, have I referred to it already)? I think I understood it: one dockable must hold a) the matrix, b) the input mapping, and c) the output mapping I thought this was a fairly simple problem in GTK terms. 1. Put the matrix inside its own VBox. Pack it at the start of the window. (This may require nesting inside another VBox.) 2. Put the input and output mapping in another VBox (one they share.) in the following manner: 1. Presets (shared between input and output) 2. Inputs selector 3. Outputs selector 4. Curve display (shared?) 5. 'Inputs' label 6. 'Outputs' label 7. Inputs treeview 8. Outputs treeview 9. 'Show current INPUT NAME input' 3. When switching modes, we: 1. If switching to matrix mode, hide the input/output vbox. Show the matrix vbox. Done. 2. If switching away from matrix mode, hide the matrix vbox. 3. If switching to inputs or outputs mode, we need to iterate over the widgets in the VBox; Hide any widgets not specific to the mode in question. I think there is a widget grouping mechanism in GTK that allows for this kind of distinction. That is in fact somewhat ugly. There is probably another solution involving packing the input/output widgets on the fly. That would be neater code-wise, and somewhat slower. I don't know whether the above would argue with the dockable's idea of how tall it ought to be. That might be what Alexia was talking about. Just one offtopic comment: Some of the icons seem very unintuitive - even as an old GIMP user I'm still confused by the fifth one from the left. What does it stand for? It looks like it's probably meant to be 'random'. I got that from the list, not the graphic, though. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz j...@joncruz.org wrote: However, the answer to the base question is Yes, X and Gtk support that to a very good degree, and all the low-level API's support delivering all the required information. and No, X does nothing with the colorspaces. It is left to the application to implement It also is more of a per-monitor issue, rather than per-pixel. So one generally will have to deal with a small set of rectangles (two being the most common) to adjust. So it's not *quite* up to the complexity of a purely per-pixel problem. I also would question the assertion that it is an uncommon use case. Those most likely to be working seriously with images are generally much likely to have two (or more) monitors. They also have a higher chance of caring about color fidelity. I agree; GIMP windows should support color management for individual image windows according to these atoms, absolutely; What it would be of little use to do, is to support showing the SAME image in a single window spanning multiple monitors, with different colormanagement for each monitor-segment of that Single window. As I understand, that is what Christopher was requesting and yahvuu was accurately describing as an uncommon use case, rather than the general case of one image window on this monitor, one on that, and they are color managed differently because of it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira shirakawa.ak...@gmail.com wrote: On 2010-02-09 19:52, Martin Nordholts wrote: GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content. Also don't forget that the various color picker/selectors aren't color managed at the moment, so selected colors (FG/BG colors) will look differently when painted on a color managed image. I think color management of individual colors and color selectors is a tricky subject. * Color selector colors must be stored in a profile independent colorspace (LAB?[1]). This ensures that we can paint any color onto any image and get the right result. Otherwise, we'd have to know the profile that the color was specified in, in order to use the correct color on the image we're painting in now.. which makes color storage way too heavyweight. * We should consider improving the color history system. MyPaint has one with the property that I think is important here: A color gets added to the history once it is 'read' (in Mypaint's case, when you paint with it; In GIMP's case, this would also be if it was read via the PDB (ie plugins or scripts)). And the previous color is shown in the color selector side-by-side to the color you're now adjusting. This makes it easier to do color comparisons, which are pretty important to get right when the previous color and current color are based on different color profiles. * We should be able to a) specify colors outside of the color profile gamut and b) clip the current color to the limits of the current color profile when painting, previewing etc. b) should probably be a toggle, then it could be quite helpful in quick soft-proofing * Some of the color selectors are already quite slow (eg. the 'scales' one). We should avoid making them slower if possible. [1] correct me if I'm wrong here... scRGB might do the job okay, I'm not 100% sure. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] TAB in single-window mode
I decided I couldn't quite submit a gimp-brainstorm item with this little content: TAB normally toggles the visibility of the docks, including toolbox. In single window mode it doesn't (and IMO it would be good if it did -- single non-fullscreen window is a lot more cooperative with other app windows than simply toggling fullscreen is.). I wanted to mention that in case it was simply overlooked rather than difficult. Looking at the code in display/gimpdisplayshell-callbacks.c and widgets/gimpdialogfactory.c, I found it difficult to tell. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule
On Wed, Jan 13, 2010 at 8:57 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 1/11/10, Martin Nordholts wrote: Then the ETA of GIMP 2.8 becomes 2010-12-02 which is more reasonable. And still somewhat scary :) The plan however does not seem to mention Python scripting improvements branch. (which will make estimations only scarier :)) I thought that had already been merged. Was it only a partial merge? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PF_FILE of the register function in python plugins with 'new file' support (Scott)
On Wed, Jan 13, 2010 at 5:52 PM, Mathias Lindner mathias.lind...@web.de wrote: My way around this was to use a PF_DIRNAME immediately above the PF_STRING and combining them for the total path. Ah, thank you very much. I wasn't aware of PF_DIRNAME. It's missing in the GIMP Python docs. This way I have a nice workaround which totally fits my needs. What else PF_ data types are missing in the docs? Or the other way around: Where can I read about all currently existing types? /usr/lib/gimp/2.0/python/gimpfu.py defines the types on a standard Linux install of GIMP. I think all except PF_DIRNAME are documented, though. (there's no steady maintainer for PyGimp or its documentation, so making sure it's up to date is currently somewhat a matter of luck) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gtk-doc 1.13 problem with recent gimp git (+solution)
Recently I found that GIMP from git would not compile, as it couldn't get past the ./autogen.sh step.. It would produce quite a few errors, like this: gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL devel-docs/app/Makefile.am:116: `gtk-doc.make' included from here gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL devel-docs/app/Makefile.am:116: `gtk-doc.make' included from here gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL devel-docs/libgimp/Makefile.am:64: `gtk-doc.make' included from here gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL devel-docs/libgimp/Makefile.am:64: `gtk-doc.make' included from here gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL devel-docs/libgimpbase/Makefile.am:52: `gtk-doc.make' included from here gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL devel-docs/libgimpbase/Makefile.am:52: `gtk-doc.make' included from here gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL devel-docs/libgimpcolor/Makefile.am:46: `gtk-doc.make' included from here I noticed in my pacman logs, I had upgraded gtk-doc recently: [2009-12-21 10:55] upgraded gtk-doc (1.11-2 - 1.13-1) So I eventually decided these BUILD_PDF and BUILD_HTML flags were new in 1.13 (or 1.12 if it exists) and required in configure.ac, and I hacked around this, by adding AM_CONDITIONAL(GTK_DOC_BUILD_HTML, test x$jpeg_ok = xyes) AM_CONDITIONAL(GTK_DOC_BUILD_PDF, test x$jpeg_ok = xyes) after AM_CONDITIONAL(BUILD_JPEG, test x$jpeg_ok = xyes) AC_SUBST(JPEG_LIBS) to configure.ac Of course, that is somewhat nonsensical.. perhaps 'true = xyes' would work instead of 'test x$jpeg_ok = xyes'. The above fix allowed me to build GIMP successfully (actually is in progress now, so I'll check it actually finishes OK.. yep:) It does seem odd to me that I get the above errors even if building devel docs with gtk-doc is disabled... Is that a bug in configure.ac? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new brainstorm...
On Thu, Dec 17, 2009 at 10:25 AM, peter sikking pe...@mmiworks.net wrote: guys, I have pushed into service something that I brainstormed (no pun intended) ages ago with Roman Joost: a brainstorm where anybody can contribute a tip-of-the-day for GIMP: http://gimp-totd.blogspot.com/ I expect this to quickly give a lot of input that (with some manageable editing by the docs team) will grow our tips db by an order of magnitude (or two). when that point has been reached, we can talk again about the original plan to give tip-of-the-day a new home in the no-image-window. --ps Just a quick note on something you might want to correct: Send your image to us, put the word ‘GIMP tip’ ^ image - tip :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Making dockable tab style a global setting
On Mon, Dec 7, 2009 at 6:48 PM, Martin Nordholts ense...@gmail.com wrote: GSR - FR wrote: Hi, ense...@gmail.com (2009-12-05 at 1330.57 +0100): I don't understand who would want a UI where tabs doesn't have the same style, what a mess I use icons for things that have true info in visual sense (colour, pattern, brush, palete, gradient) and text for the rest. For me it is a matter of less visual noise and more constant interface. Is there any particular reason you don't show this information in the toolbox (Edit - Preferences - Toolbox - Show brush, patter etc) instead of showing it in individual tabs? Wouldn't that decrease the visual noise even more? In my case, the colors display (the only display I'm interested in) occupies much too much vertical screen space. It's also awkward to have this color display up there but the color editor below (I know you can edit colors by double clicking on them. I find that more irritating and prone to be accidentally triggered, for my usage (in which I constantly want to inspect hex color codes, so seeing the color swatches is only part of what I want anyway.)) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Airbrush/Brush Banding Effect At Low Pressure/Opacity
On Thu, Nov 19, 2009 at 11:17 AM, James Cox jay...@gimp.org wrote: Christopher Howard wrote: Thinking about this some more, the error diffusion is probably not even necessary. You should be able to get by with some random dithering like the following (if it wasn't slower than molasses): result = floor(input * opacity + g_random_double()); If you pregenerate a lookup table (say 256 entries), keep a counter which cycles 0,1,2,255,0,1,2,255, and only add a random integer to that counter at the start of every dab, you could get that going at decent speeds. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re branding ....
On Sat, Oct 31, 2009 at 2:12 PM, vabijou2 vabi...@yahoo.com wrote: Christopher Howard-3 wrote: Its about having a product you aren't afraid to advertise. . As soon as I say GIMP, you can see the doubt on their faces, because they associate the word with being weak or lame. I agree with this. Many people shy away from using products that aren't mainstream, and have little to do with (or knowledge of) open source I have to agree that Photoshop *is* mainstream to the degree that image editing is -- as a verb at least.. people use PAINT.NET or whatever and say they 'photoshopped' it. I think Patrick is missing that 'mainstreamness' is relative (theres 'mainstream for the culture', 'mainstream for artists in that culture', 'mainstream for digital artists in that culture', 'mainstream for pixel artists in that culture'.. these levels of detail nest to produce the overall context in which something can be said to be mainstream or not. software alternatives. There is nothing about the current name that inspires confidence or denotes competence. Personally I don't recall ever encountering a program whose name inspired confidence or denoted competence to me, in this out-of-context way you are talking about. Except perhaps Lotus 1-2-3. For example, the following inspire confidence in me and I feel they are competent. Perhaps they have some common factor, I think it's more likely that it's just an understanding of how they work (and that that way is a good way to work) that inspires confidence and 'denotes' competence Python IPython PyTables NumPy SciPy Allegro Grafx2 Charm DosBox Lua Inkscape FontForge SQLite Lynx Midnight-Commander Thunar It looks like there is a 'Mildly witty' theme going there, along with a preference for literality and brevity. OTOH it could be simply that witty, literal-minded people tend to produce software I find competent. I think that the time to change the name would be when a release comes out that has an option to run in a single window. This is a major change that people have requested for some time and this new configuration is sure to be discussed widely on the internet. That version could be called something like Gimp+. Over time this might become shortened in blogs, forums, etc. to G+, 'jeeples'? lol. I'm sure the FSF people would like it :) How do we verb it though? jeepling? BWAHAHAHAHAHA. (more seriously, G+ is extremely close to the name of the gnu C++ compiler, G++) At the 'G+' point, the major internal renaming would need to take place, and that would require far more developers and far more organization than the GIMP project currently has. Even simply switching from GIMP to GIMP+ (I'm -1 on 'Gimp+') would involve considerable effort (mainly in keeping I18N current). and then a later major release could use that as the name. The whole time, Wilber the mascot would remain basically the same to provide continuity. I'm no ad wizard so I don't claim this is the best naming strategy, but I think it provides an example of how the rebranding process could go. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Fri, Oct 30, 2009 at 9:43 AM, Brendan mailingl...@endosquid.com wrote: On Thursday 29 October 2009, you wrote: On Thu, Oct 29, 2009 at 2:07 PM, Brendan mailingl...@endosquid.com wrote: All the above comprise a significant factor in why forks are regarded, at best, as a necessary evil. All forks dilute branding, which introduces user confusion and repels potential users. I think it's incorrect to say it repels potential users and leave it at that. It will also just as likely ATTRACT new users who were put off by the lame name. That's speculative. We know from past software history that what I The extent is speculative, the same as you. I know an entire office who said they would use it if it changed the name, so it's not nearly as speculative as you think. Fair enough. Call it the Gnu IMP. This has to be facetiousness, doesn't it? Most of what I say is at least slightly facetious. If they simplify it themselves, that's their problem, and not something that is super-obvious. If we look at the way the photoshop family of products are abbreviated by people(PS7/CE4/Elements),and GNU projects (bc, bash, tar, Octave, etc), just plain IMP is reasonably likely. (in fact, GIMP is an oddity in that the GNU is actually included in the acronym.. if it were more canonical, people would already be calling it Gnu IMP or IMP). That's fair enough.. IMP *is* a better name (and people who object to it on religious grounds probably are terminally humorless), we just should expect it to still manage to be taken as objectionable. Actually, I'm in favor of your proposition now, you've convinced me. Gnu IMP is 'backwards compatible' as you say, more in line with other GNU projects' naming, and could result in image* improvement in the future. As long as it's not a fork -- that is, the renaming would need to be official. * The kind that doesn't have pixels in it :) but, well, the other kind too I suppose :) A list of files that would need modification: HACKING NEWS gimpui.pc.in [a few utility scripts like gimp-zip] [most files with 'gimp' in the filename would need renaming. that is 1686 files to rename] [All enumerations which include 'GIMP' in them] [.gimp-2.x would need to be migrated to .imp-2.x .. and then symlink .gimp-2.x to that] [On Linux, create a symlink 'gimp' pointing at 'imp' (or something like that)] [We'd need to deliberately avoid changing the XCF and rcfiles format, which refer to such object types as 'gimp-image-grid', 'GimpDeviceInfo', 'gimp-channel-list'. Note: some rcfiles include 'gimp' in the names of objects, others do not. I don't fully understand why.] [themes would need to be updated to refer to 'imp-*' widget classes rather than 'gimp-*' widget classes] All active/'pending' branches would need to be updated to match (this would be mostly trivial, I expect situations where new enumerations or files were introduced to be more involved) This would be quite time-sensitive in order to maintain a functional GIT repository -- it would need to compile successfully again within 3 days. So it might take a small team just to complete this. Then the documentation would need to be synchronized with the change (screenshots, textual references to 'GIMP') fairly promptly after that -- which is IMO quite hairy due to I18N concerns. All *gimp* pdb functions would have to be deprecated in preference to *imp* versions. .po files would all need to be updated, however this would not need to be done all in a lump but could be spread over time. All the above would be best done at the beginning of a development cycle (eg. when 2.8 has just been released). It would be relatively free of the potential for invisible bugs -- most problems would show up as compilation errors. I believe the above is the minimum required to seriously do that change. Though of course we could begin with the user-visible things (binary names, and strings) and progress to the developer side (filenames and enumerations).. it would still be vital for it's success to quickly do the migration on the developer side, which is the majority of the work involved. I can see why GIMP developers would want to avoid such a thing. I do believe that the migration wouldn't require more than a very basic understanding of the GIMP code base. What it would really need is a) a great deal of organization and b) an active and moderately large team. (doing only the user-visible side is a possibility.. but this may result in confusion where eg. a PDB function is named gimp-* where the program says it is 'IMP') PS. 'The GIMP' is anachronistic AFAIK -- GIMP (no 'the') is canonical currently. PPS. I believe (haven't tested, my GIMP GIT clone is not in working order currently), that the option '--program-transform-name=s/gimp/imp/g' to configure would result in appropriately named binaries (imp-2.7 etc) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU
Re: [Gimp-developer] The name Gimp
On Sat, Oct 31, 2009 at 8:56 AM, Christopher Howard chow...@indicium.us wrote: Alexia Death wrote: On Fri, Oct 30, 2009 at 12:40 PM, David Gowers 00a...@gmail.com wrote: On Fri, Oct 30, 2009 at 9:43 AM, Brendan mailingl...@endosquid.com wrote: A list of files that would need modification: ... SINP LONG LIST... And all of GIMP code. 98% functions are prefixed as gimp. You can try to grep for gimp on gimp source tree. Forget it. Some English speakers discomfort at the name is getting a bit ridiculous IMHO. A note: The end users don't care what the functions are called. Just the name of the binary, the logo, and the title bar. That's sort of beside the point. Having the developers see things differently than the users disincentivizes people to be both users and developers (which is definitely the optimal choice for ongoing improvement of software quality). If the program is called imp but all the functions are gimp_, that introduces cognitive dissonance (which amounts to confusion+annoyance in this case) which discourages the users from developing. The discomfort at the name for me has nothing to do with some moral objection. Its about having a product you aren't afraid to advertise. When I start extolling the virtues of open source to my buddies, one of the first three objections I usually get are but there is no good graphics software like Photoshop. As soon as I say GIMP, you can see the doubt on their faces, because they associate the word with being weak or lame. If Mozilla's browser today was name Mozilla Slug, or Bloat Browser, how many people do think would be wearing the tee-shirt or showing off the desktop wallpaper? The difference being that slug or bloat are not narrowly-scoped cultural references: almost everyone knows what a slug is, and a majority of computer users end up understanding what bloat is. By comparison, the first time I heard of gimp meaning anything -- except, well, the program we're talking about! .. was a thread here about this very same subject. Others have expressed similar sentiments. You're acting like 'gimp' is a universal English cultural artefact. It's not (it's mainly an American one). It seems to me that such threads simply manufacture means of objection for trolls who don't want to adopt something new, because it's new. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
On Sat, Oct 31, 2009 at 10:59 AM, peter sikking pe...@mmiworks.net wrote: guys, would like to tap the wisdom of this crowd here. say I have made a selection in GIMP, done what needed to be done to the pixels in the selection and now want to get rid of the selection. the obvious way is Select-None. how many more ways are there? 1. Use rectangle/ellipse select to select nothing (single click) 2. Activate QMask, drop black on the image, exit QMask 3. Use the Move tool in Selection mode to throw the selection mask off canvas. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
On Sat, Oct 31, 2009 at 12:30 PM, Liam R E Quin l...@holoweb.net wrote: On Sat, 2009-10-31 at 01:29 +0100, peter sikking wrote: the obvious way is Select-None. how many more ways are there? Save the image as png, quit gimp and restart. :D go to channels dialogue, make an empty channel, and do, channel to selection. (and then go to layers and select a layer in the image) use rectangle tool to marquee round the whole image in subtract from selection mode, and press Enter single-click with rectangle tool, outside the image (or ellipse tool probably, but not freehand tool) It doesn't need to be outside the image, just outside the selected area. several others that other people suggested, I generally do shift-control-a. I view that as performing the exact same action as Select-None, which is why I omitted it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, Oct 29, 2009 at 5:35 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Worse, I seem to recall the Gimp mascot being referred to as a gimp in multiple occasions on the website. You got it wrong. Mascot's name is Wilber and he thinks you should apologize. No, John is correct: GIMP's mascot Wilber(sp?) is a gimp. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, Oct 29, 2009 at 9:25 AM, Christopher Howard chow...@indicium.us wrote: John B wrote: Well, if it's out of the question, then I guess I'll just shut up before this becomes a big argument. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer It seems to be out of the question as far as convincing the developers here to ever do that. Under the terms of the GPL3, however, there is nothing to stop you from forking the code and doing that yourself. Probably the best way, I would imagine, would be to keep nearly all the code the same, but to add a configure options (like --better-name) that causes the logo and title bar name to be replaced. But if you were to go to all the trouble, you would want to come up with a really classy name and well-designed logo or else no one would care. I'm sure that has been mentioned in the archives as well, but I thought I'd mention it again in case you actually had the time and interest to do it. Personally, I don't like the name GIMP either, as it's not a very selling name. I know that annoys many of the (dedicated, hardworking) developers, but we all have the right to our own opinion. It doesn't really matter that much to the developers *what* it is called, as far as I know. The point is really the branding... changing name will definitively LOSE a lot of users, no matter what the current name is or the intended name is. There may be solutions to this problem (though commercially, rebranding seems to involve a lot of expensive advertising). So far, no-one has proposed one (or demonstrated that the current name is problematic in an actual provable way -- just assertions that it is offensive or not offensive in so-or-so region.). All the above comprise a significant factor in why forks are regarded, at best, as a necessary evil. All forks dilute branding, which introduces user confusion and repels potential users. So I do agree with one thing you said -- If you were to fork the project you would need to do so really well. This would probably involve forking the gimp-docs and gimp-gap similarly (and maybe also FX-Foundry) in order to cover the 'gimp' references in these most commonly installed accessories. It would also be important to make it very clear that it is compatible with GIMP plug-ins, and therefore to search GIMP's global plug-in/resource directories for resources as well as the fork's plugin/resource directories (identifying and ignoring duplicate resources). It would require the mascot to be changed (and therefore also some of the icon set, as they include Wilber), and also some (all?) of the gimp-docs screenshots, as well as some of the example images in gimp-docs which use Wilber. It would require a strategy for dealing with existing .gimp-2.7/ directories. That's my understanding at a glance. Actually doing it well would be more involved than the above, I expect. (for example, we use the phrase 'happy GIMPing!' and similar verb-ing of the GIMP name.. so it would help to have the replacement name be easily verb-able too) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, Oct 29, 2009 at 10:41 AM, vabijou2 vabi...@yahoo.com wrote: So just because some old farts in Scotland may have good associations with the word, you think that renders the rest of the English-speaking world's interpretation silly? %-| Personally, I think the question you just asks renders you silly (and arrogant) for presuming to speak for 'the rest of the English-speaking world'. This is an issue on which opinions *are* divided within 'the English-speaking world'. I personally have never seen the movie 'Pulp Fiction' on which the interpretation of GIMP as offensive seems to come, and while I agree that 'Pulp Fiction' is fairly famous, I believe it's rather America-centric to assume every English speaker holds that association. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, Oct 29, 2009 at 12:16 PM, Christopher Howard chow...@indicium.us wrote: Stephen Griffiths wrote: When I mentioned forking the project I wasn't thinking of having a version of GIMP out there that was actually following a fully separate development path with a bunch of disgrunted GIMP developers. Rather, it could be the exact same thing except with a patched-in configure option or something that allowed rebranding. For example, in Gentoo (a source based Linux distribution) when you compile Firefox, you can pass in an iceweasel configure option that rebrands it with the Debian logos, or you can pass in a bindist option that rebrands it with generic branding. Sure.. except, I listed the things that would be needed for that. If you do not do at least most of those things, you would only be doing a partial rebranding. You would have parts of the overall package calling itself GIMP rather than the new name. If this would happen, the confusion caused by it almost certainly would be more 'expensive' in terms of user confusion/disgruntlement than simply leaving GIMP branded as.. GIMP. I'd also like to mention that I find the iceweasel/icecat/shiretoko/minefield/firefox thing quite confusing. It seems kind of useful in an abstract sense (minefield is .. dangerous, iceweasel is strictly FOSS,..). There is significant differentiation of mascots happening, though, unlike what you seem to be suggesting. Rebranding could be automatic, but it couldn't IMO be simply a matter of substituting text strings as you suggest with your 'configure option' idea. You would need to also have a different mascot, and consequently regeneration of images would be needed (using a set of unbranded screenshots + a set of mascot images). It just occurred to me: the 'text substitution' would need to rewrite PO files in order for I18N to function correctly. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, Oct 29, 2009 at 2:07 PM, Brendan mailingl...@endosquid.com wrote: All the above comprise a significant factor in why forks are regarded, at best, as a necessary evil. All forks dilute branding, which introduces user confusion and repels potential users. I think it's incorrect to say it repels potential users and leave it at that. It will also just as likely ATTRACT new users who were put off by the lame name. That's speculative. We know from past software history that what I described actually happens. (I'm not opposed to a rebranding. I just think that it would need to be done a) really thoroughly and carefully, b) in cooperation with GIMP developers, and c) released with very calculated timing. And also that such a rebranding is very far from trivial to achieve.) Call it the Gnu IMP. This has to be facetiousness, doesn't it? In what parallel universe do you live in, that people will not simplify 'Gnu IMP' down to 'gIMP'/'GIMP'? For that matter, how is 'GIMP' (which may be considered offensive by people who've seen Pulp Fiction, or by disabled people) better than gIMP (which may be considered offensive by religious nutcases)? It seems to me that there are far more people in the latter category. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
Incidentally, I like Stephen's 'Wilber/ Wilber Image Editor' suggestion (in another related thread). I'm envisioning someone using the latest GIT version because they *have* to be up-to-date with the newest stuff, the program crashing and destroying their work, and they cry 'No! WIEEE?' :D /silly (I do genuinely like that suggestion, just to be clear) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] single-window fix and WMs
On Sat, Oct 24, 2009 at 6:43 PM, Ilya Zakharevich nospam-ab...@ilyaz.org wrote: On 2009-10-21, Karl Günter Wünsch k...@mineralien-verkauf.de wrote: IMHO the move to a single image window with dockables would solve quite a lot of interoperability problems. For example there are plenty of broken window managers out there. Relying on them (WM developers) getting it right in the end for the GIMP is proving to be a long wait. You are right, somehow I assumed that the problems of GIMP's window management would be solved. Taking into account the history, this was a short-sighted assumption. There are no problems of *GIMP*'s window management. Your failure to understand this is the reason that people are getting annoyed at you. As desktop environments go the window managers that work with the GIMP as intended tend OTOH to be the ones that don't play well with KDE for example (if you even have the choice, which you haven't really in KDE4). Oh and windows is a beast that isn't handled easily as well BTW, I see again and again this assumption that the responsibility for observed problems of GIMP may be shifted to WM's problems. I never could understand it. WM is only responsible insofar as having the WM behaves in a consistent and predictable way is very helpful. On Linux, virtually all WMs conform to the ICCCM window management standard (the window management hints in GTK+ were designed based on ICCCM, I think). On Windows, the management conforms to no recognized standard. So the WM holds some responsibility in such misbehaviour. The main responsibility is GTKs. In the case where I confirmed the TAB behaviour, I suspect that's because I haven't configured AwesomeWM correctly: in my case it is focusing the toolbox window when it reappears, instead of keeping the focus on the image window.. this is what is preventing TAB from working, and it's definitely outside of both GIMP and GTK+'s scope to address this. I'm currently looking at how to fix my configuration. [Keep in mind that my experience in apps--WM interaction is rather minimal - I participated in porting Perl/Tk toolkit from X11 to non-X11 system, and watched the corresponding mailings lists for slightly more than a decade.] Here is the picture as I understand the rare morcels I saw: a) on window creation, GIMP registers a few bits of information with GTK++; b) the exact meaning of these bits is not documented, and is known to vary widely; Completely false. http://library.gnome.org/devel/gtk/unstable/GtkWindow.html http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#GdkWindowTypeHint Provides comprehensive documentation, even though it may not be in the language you most easily understand. Missing content for certain languages is not at all the same as missing content for all languages. c) the observed results are most of the time not what one would want; This is true. Even on the stated standard, Metacity, some odd behaviour with TAB seems to be happening (Every time the toolbox reappears, it has moved down and to the right somewhat.) I'm not sure if there is any problematic behaviour on other WMs like the KDE window manager, XFCE, fvwm, blackbox/fluxbox/etc, WindowMaker.. d) the interpretation is that it's somebody else's fault. 'somebody else'.That's vague. GIMP devs have been specific and definite about this problem for a long time: it's GTK+'s fault. GIMP provides specific information, which it is GTK's job to interpret and pass onto the WM in a way that it can understand. GTK+ currently fails to translate certain information accurately for the Windows WM. You can scream until you're blue in the face and it won't make this any less true. Obviously, I'm missing something... I hate to ask for somebody else's time, but I would appreciate a correction (or at least a reference to older discussions...). the window manager there sucks at managing applications that consist of multiple single windows that don't have a proper native inheritance structure I'm pretty sure that this is NOT how it happens in Windows. AFAIK, there is no window manager; each application is responsible to arrange the x/y/z-order of its toplevel windows itself (there is a simple callback interface for such arrangements). There is window management -- otherwise you could not close windows, or minimize or maximize or move or resize windows (or switch between windows like with ALT-TAB or clicking). In fact window management covers more than the initial creation of windows, but also their movement, resizing, reordering, delivering keyboard and mouse events to the right windows, etc. The callback interface is not unique (in fact GTK implements it in a way that works on all platforms and WMs I've tried, which are many, so the 'callback' behaviour appears to be ubiquitous rather than unique to Windows.). With most WMs, the client program has a high degree of control over the particular behaviour of the
Re: [Gimp-developer] Icons for layer modes
On Sat, Oct 24, 2009 at 9:48 AM, Ilya Zakharevich nospam-ab...@ilyaz.org wrote: On 2009-10-21, yahvuu yah...@gmail.com wrote: The analogy was given to show why the the current interface to blending (i.e. choosing among a discrete set of layer modes) is a poor one: And my message was intended to show why the current interface is a very good one... it is both limited and mostly non-intuitive. IMO, non-intuitive is 100% fault of GIMP developers. The current documentation is plain insulting... At this point I support banning you from this list for your repeated insults and self-righteous attitude towards people who are freely volunteering their time and effort. Further, insulting people who have very little to do with the subject is even worse (GIMP documentation is managed by different people, there is very little overlap between GIMP docs development and GIMP development) Layer modes is a very simple and intuitive concept. The only thing missing is documentation (I'm going to address it in more details when the waves from my previous posts would subdue...) The documentation of layer modes is outstandingly clear and thorough -- this is largely due to 'scb' and later 'j.h's excellent work, as you can see in the comments. http://git.gnome.org/cgit/gimp-help-2/tree/src/concepts/layer-modes.xml The only thing I would change about that documentation if I knew how, is make the images showing the effect of specific layer modes change to the base image on mouse-over so you can easier discern the exact effect. Rather than better documentation, I believe better visualization is the path to improvement of user understanding: Using the layer thumbnails (and GEGL cache?) to build a 'preview' composited thumbnail for each mode and show it (next to the text or as a tooltip) would help the user to understand at a glance the general working of a layer mode they are considering. The composite thumbnails could be generated on-demand and otherwise in idle time (so the person who knows exactly which layer mode they need would not be impacted -- they could select layer mode just as fast as before, and if they did need the thumbnails, they'd only need to wait a fraction of a second longer.) ___ 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 Wed, Oct 21, 2009 at 1:42 PM, Ilya Zakharevich nospam-ab...@ilyaz.org wrote: On 2009-10-21, Tor Lillqvist t...@iki.fi wrote: It is pointless to describe the misbehaviour of GIMP windows on Windows to GIMP developers, as they don't use Windows themselves. Let me restate it: it is pointless to fix bugs/problems on windows, since they do not happen (and if they happen, developers do not want to see reports). No, it means the bugs are in GTK+, not GIMP, and it requires GTK+ developers who run Windows to fix these bugs (or a GIMP developer who runs Windows and has some knowledge of GTK+ and an inclination to fix these bugs). Do you seriously think a person running Linux is going to be able to reliably fix a bug that only shows up on Windows? Are you sure that the situation is as you describe it? To see GIMP behave as it is supposed to, you need to use it on Linux. The reference window manager is metacity, as far as I know, but also other window managers might work well enough. Sorry, but I find this attitude as misplaced as one in the previous paragraph... Your expectations that GIMP will exert such extreme control over the window management are also unreasonable. Your window manager manages your windows, GTK+ communicates to the window manager what window behaviour GIMP is asking for, GIMP communicates to GTK+ what window behaviour it wants. The particular 'communications breakdown' is between GTK+ and the Windows window manager, GIMP is not involved in the problem, only a casualty of it. ___ 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 Wed, Oct 21, 2009 at 11:22 AM, Ilya Zakharevich nospam-ab...@ilyaz.org wrote: On 2009-10-02, peter sikking pe...@mmiworks.net wrote: However, I do not see how much this would affect the (AFAIK) main complaint about multi-window GIMP: that having several windows with several possibilities of what is focused requires many extraneous mouse clicks and/or keypresses. the introduction of a single window mode is in no way related to that. Good to know; so let me refine: is there ANYTHING in the move to single window which would not be achieved by a) restricting the maximal size of image window to the gap between two toolboxes; and b) making z-order changes syncronized between the main window and toolboxes? (I mean: whenever z-order of main GIMP window changes *wrt non-GIMP windows*, the z-order of dependent windows changes accordingly. Same for toolboxes: similar changes in THEIR z-order should be reflected in the z-order of the current image window) When the windows are merged into one, STILL only one of subwindows has a focus? So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)? that is a serious bug. in what version(s) of GIMP does this happen? 2.6.6. Tested on Windows. Examples: a) Press TAB (toolboxes disappear); Press TAB (toolboxes reappear, focus on Layers); Press TAB - now you navigate Layers toolbox. I can reproduce this very annoying behaviour. I have to refocus the image window in order to get TAB to work again, and basically gave up on using TAB at all. Platform: Arch Linux (i686), GTK 2.16.5, Window Manager: AwesomeWM 3.3 I believe my WM always focuses the newly shown window, which may reflect on this behaviour. b) Focus to Layers. Press F11. Nothing. Press o. Nothing. Press 4 (user configured to 1:4 zoom). Nothing. I can't reproduce this; all keyboard shortcuts work as expected, except where they conflict (for example, when a text-entry field like palette or color name is in focus, you have to be able to type o as an ordinary letter). May be Windows-only. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
On Sun, Sep 20, 2009 at 8:30 PM, jolie S for...@gimpusers.com wrote: Also I've slept on it and given it some more thought and I'd like to ask again if you would please give having multiple images open at the same time some more thought. IMO being able to work on more images at the same time is VITAL for a professional image editing program. (just think of cloning to name 1 example) Please give your users the options to do so in both modes, single and multiple windows. Peter's specification does give the option to have multiple images open at once. Perhaps you mean having multiple images both visible and workable-upon at once. That's certainly important for things like cloning, as you said. Perhaps a split-panel option for single window mode would resolve this. (I believe we could still only reasonably show a maximum of 2 images at once; this is simply a limitation of the single-window format AFAICS.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
On Sun, Sep 20, 2009 at 8:57 PM, Liam R E Quin l...@holoweb.net wrote: On Sun, 2009-09-20 at 20:51 +0930, David Gowers wrote: Perhaps a split-panel option for single window mode would resolve this. (I believe we could still only reasonably show a maximum of 2 images at once; this is simply a limitation of the single-window format AFAICS.) Do you mean that the windows would be too small, e.g. on a 30 cimena display or with 5 LCD monitors :), or do you mean that the toolkit only supports two panes?? Too small (except on a 30 single display. 5 LCD monitors is not a situation in which I can reasonably imagine you would want to use single-window mode; feel free to contradict me if you have experience with this.) There are no relevant GTK+ limitations. However I understand that with the current GUI setup of GIMP, horizontal splits like |IMG|IMG| are easier to implement in terms of visual organization. For cloning you only need a tiny part of the source visible... This is only true IMO if the source auto-scrolls as you clone. Otherwise, especially when you need to be reasonably precise, you may need a relatively large display (for example, 150x150 area @ 300% zoom = 450x450) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug #164774
On Fri, Sep 11, 2009 at 6:54 PM, peter sikking pe...@mmiworks.net wrote: second try sending this... Liam wrote: On Thu, 2009-09-10 at 00:00 +0200, peter sikking wrote: [///] grab the top-left square where the 2 rulers cross and drag+drop it anywhere on the canvas. the place that currently gives a pop-up menu? damn. yes. can somebody tell me why we have a tiny replacement for the menu bar right below the menu bar? The obvious answer here is that it's visible when the menubar is not. (being that it belongs to the rulers) Not that that is a good reason. I think it's confusing being able to access menus 3 different ways, and the tiny icon is really not very easy to click. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
On Sun, Sep 13, 2009 at 10:22 AM, Rob Antonishen rob.antonis...@gmail.com wrote: Peter- To clarify, you are suggesting the on screen pointer icon/sprite could show the actual brush as it would look painted with a single mouse click, but once painting/holding the mouse down it would render as a cross hair? And once the mouse is released it would turn back to a static sprite? That should keep the response faster when painting then, right? That would great for a mouse user, but would it work for a size dynamic tablet user? As a tablet user, the above is exactly what I want; I certainly don't want an outline while painting (may not be completely accurate, and I tend to move too fast for the outline to have any real use) When using a mouse, visual response to movement tends to be predictable enough that I don't really gain anything from the brush outline during painting either. +1 on crosshairs-only during painting ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tags on presets.
On Mon, Aug 24, 2009 at 3:28 PM, Martin Nordholtsense...@gmail.com wrote: I immediately thought of Akira Shirakawa's proposition to move a majority of paint tool options into the concept of brushes. IMO doing that and using the already existing tagging for brushes would simplify the user interface and also the user experience. I have also thought a bit on how to clean up the concept of brushes, and in my mind, we could do it like this: We make a brush be just a bitmap/svg/whatever (possibly also an animation). Note that a brush would not even have a spacing as the current GIMP gbr brushes. Right, so what you call a brush here is really more like a 'tip shape' (assuming that tip shapes can change over time, which seems reasonable) definitely +1 on the transferral of spacing -- that illogicality is really annoying of having that lone option there. This would mean that we would also need to transfer the concept of ranks -- that is, a tip shape could specify what ranks it specified, and the actual meaning of those ranks would be specified in the other part you specified (the one I'm tempted to call 'tool tip') Mind you, I'm not sure that the flexibility of GIH brushes is a good tradeoff for the increase in complexity introduced by essentially multidimensional arrays of brush images; If it is, then it would help a lot to have a better way to lay them out (layer grouping functionality sounds like a good fit here -- one grouping level per rank. A brush preset is a brush + dynamics, and this is actually what the user typically picks. If we would have tags for brush presets, we would be one step closer to make brush options be part of the brush, so to speak. .. and I can't help thinking of this as a 'tool tip' :) This sounds like the best idea yet on this subject. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tags on presets.
On Mon, Aug 24, 2009 at 5:06 AM, Martin Nordholtsense...@gmail.com wrote: On 08/22/2009 05:48 PM, Christophe Buffenoir wrote: Hello, I use the GPS set of presets and I think that tags system will be good on presets and not only on brushes. Nothing is done yet, the screens are just fakes to show my purpose. But, even if I've not enough spare time to do it quickly, I can code it. I think tagging of presets makes sense, in particular since brush dynamics keep getting more and more sophisticated. I immediately thought of Akira Shirakawa's proposition to move a majority of paint tool options into the concept of brushes. IMO doing that and using the already existing tagging for brushes would simplify the user interface and also the user experience. (like I've mentioned before in reply to Akira's topic, We have an example of how to make this work very well in MyPaint; the way MyPaint treats brushes really 'fits my brain' IMO and makes painting processes simple to think about, uncomplicated, and quickly done.) IMO tagging is sort of a patch over the real problem: part of the qualities influencing a brush are in the brush itself, with others in the tool options. Maybe we need tagging, but for the current situation, tagging would make the separation less ugly, while leaving the disjunction of 'brush' meaning in place. http://www.nabble.com/Improved-brush-editing-interface-mock-up-td24628609.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?
On Sun, Aug 2, 2009 at 7:49 PM, SHIRAKAWA Akira shirakawa.ak...@gmail.comwrote: Martin Nordholts wrote: Does anyone see any problems with using CIE LCH instead of HSV for these layer modes? We can ignore backwards compatibility issues for now. I very rarely use layer modes (and I'm not a GIMP hacker so I'm probably missing something), but if using internally CIE LCH for image processing instead of HSV leads to more correct results, then I wouldn't see any reason to not use it. Except for the final results, will there be any change at a user interaction level? Or any practical drawback resulting from this? LCH processing is definitely slower than HSV or HSL (whether optimized or not), so this may have an impact on display update speed (and consequently on user experience) There are a few different ways of applying a 'Color' like operation, varying in quality and speed. LCH is certainly the best quality, Yiq is lesser quality but faster, HSL is even lesser quality and very fast, HSV is the fastest (but so inaccurate it's laughable) Since GEGL provides a number of operations that are inherently expensive (eg bilateral-filter), it may be worth considering the idea of graphs with quality controls built in. For example, while you are painting on your Color layer, it switches from paint application using LCH to Yiq (which is a nice compromise and has been used for heavy-duty tasks with good results -- see http://www.cs.huji.ac.il/~yweiss/Colorization/). When you stop painting, it updates with the actual LCH results. This would allow more responsive painting (and could also be applied to paint modes) Martin: I have made use of GIMP Value mode in the esoteric kind of way you mention. I agree it is not worthwhile to support such uses (imo more like abuses -- this kind of use is really begging for the use of PIL or NumPy on a chunk of image, not the application of an image *editor*) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?
On Mon, Aug 3, 2009 at 5:13 AM, Martin Nordholts ense...@gmail.com wrote: The input I've gotten so far removed any remaining doubt about porting those layer modes to LCH, so I've done that now: commit 18603ac192493296b191197a3e2b62c710398afd Author: Martin Nordholts mart...@src.gnome.org Date: Sun Aug 2 21:35:10 2009 +0200 Bug 401754 – Port Hue, Saturation, Value to CIE LCH When using GEGL for the projection, use CIE LCH for the Hue, Saturation and Value layer modes, just as we already do for the Color layer mode. The Value layer mode will later be renamed to Lightness since that is the semantics it has now. oh, BTW, since LAB already separates the color element (AB) from lightness, it's probably better to just use LAB for that -- it should produce identical results, faster. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Tue, Jul 28, 2009 at 5:11 PM, Jason van Gumster ja...@handturkeystudios.com wrote: Sparr spa...@gmail.com wrote: Circle and Fuzzy Circle should be two brushes. I've been following this conversation with a bit of interest, but I've noticed that a lot of discussion has echoed this sentiment. Why should there be two circle brushes? Couldn't there be a single circular brush with fuzziness as an attribute of that brush that you could adjust with a percentage slider? .. You can already do that for any circle brush. The attribute is called 'Hardness' We would not seriously consider such a level of reduction because it's bad for usability -- it's much more painful for the user to adjust a slider each time they want to paint with different hardness, than to just switch between two brushes. I personally think there should be a few different brushes in a basic set. * 'fill' brush (large, hard edge) -- because often painting is more convenient than select+fill * 'sharp' brush (moderate size -- say 25px (== radius 12), hardness 1.0) (general purpose) * 'fuzzy' brush (for blending) If we moved towards Akira's idea of moving brush-related tool options into brushes themselves, I would also suggest * a single pixel, Hard Edge (as in, pencil-style sharp rendering) brush for pixel.precise adjustments. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
I think this is a very good idea -- moving the 'different ways of painting' into brushes so that we don't need Paintbrush, Pencil, Airbrush but just one : 'Paintbrush'. I use GIMP mainly for pixel art, and I find that I really want the paintbrush/pencil/airbrush tool distinction to go away, so I can just select 1px hard edge brush and not care about tool, and be assured that I paint with hard edges and will therefore not smudge the picture. Mypaint (http://mypaint.intilinux.org) does it like you suggest and it works very well -- especially the way that you can toggle erasing, I think that is a very useful improvement to workflow. It's true that 'much more could be added' -- MyPaint gives an extreme amount of brush settings, but it is not punishing to the user because you do not need to negotiate these options most of the time (nor do they occupy any screen space usually). I would like to see the possibility to make specific brushes for erasing or anti-erasing. My experience with MyPaint suggests that this is a very simple and effective way to do erasing. One issue I have found in MyPaint is that of committing changes -- say I select the 1px brush, and change the spacing to 50%. should that be automatically saved to disk, or discarded at the end of the session? (MyPaint opts to discard these changes at the end of the session. I think GIMP should visually indicate 'dirty' brushes and give the option to save changes) MyPaint also makes Opacity into a property of brushes. My experience is that this often makes it much easier to quickly get to work. I am very interested to see more. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
- Leave the old tool selection concept to the new taggable brush selection window With a new generic brush system in most of the brush behavior is described by the brush settings, it's possible to leave the old tool selection concept to the new (and possibly even more improved) taggable brush presets window. What do you mean here? I think we need at least these paint tools: Paint (this would be able to do all of what Pencil, Paintbrush, and Airbrush do currently, and perhaps also Eraser), Ink (this does not use 'brushes'), Clone (also Heal?) , Perspective Clone , Blur/Sharpen, Dodge/Burn, Smudge. Do you really have a proposition to unify all of those, or do I misunderstand you? David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
2009/7/22 Fredrik Alströmer r...@excu.se On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudinealexandre.prokoud...@gmail.com wrote: On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote: Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user. So far I only heard from users thanks, but why is it not by default? :) I guess you wouldn't hear from people who like it the way the default is set, would you? :) Well you can hear from me: I like the global-brush setting; if it is accidentally turned off I find it very annoying, having to reselect brush between tools... usually I *do* want to keep just the same brush between tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off, there is an unavoidable mental 'thunk' to accommodate for the possible change of brush as you change tool; global-brush == off seems in this way to inherently slow the user's workflow (regardless of what workflow they use -- having to think 'oh, what is the brush of this tool' == slowdown.) A related issue is the difficulty of reliable brush selection. ideally I would hit a shortcut (say CTRL+B) and then type part of a brush name and hit enter to select it. The current brush selection methods either require direct pointing, are inaccurate, or only allow relative selection (ie. next brush, prev brush) (note: you can do absolute brush selection by this method IIRC: make sure your brushes dialog is set to List, then when you want to select a brush by name, hit [the shortcut for the brushes dialog], then CTRL+F and type the name fragment. This has two downsides - a) it's too much keyboard work for a common operation, b) it changes the focus, which means I have to mouse back to the image window or ALT-TAB before I can continue as before (say, adjusting the drawing opacity before I start painting)) Also, Alexandre says: Clear separation of default settings for different tools is such an obvious thing... I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow (and everyday workflow takes priority IMO.. A person remains a newbie for only so long, but the general consistency of workflow is something they will need to deal with as long as they use GIMP -- including any bureaucratic lumps such as (global-brush == off)) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Wed, Jul 22, 2009 at 10:47 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: 2009/7/22 David Gowers wrote: tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off Don't wonder -- they do. And I do too :) (Speaking of which, the fact that tools presets don't save/restore scale value isn't helpful either.) AFAICS that isn't a generally true fact. Works for me -- I just checked by choosing 1.06, saving that as a preset, setting it to 0.01 and loading the preset (which correctly reset scale to 1.0). What version are you using (I'm using a recent git version, I'd guess that if there was a bug, any 2.7 version would have it fixed.) I guess also it is possible that one of your preset files is corrupt and causing problems. Clear separation of default settings for different tools is such an obvious thing... I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow Contrary to that I would yell every time I switched from Paintbrush to Eraser if I didn't have global brush disabled. It's way too convenient to use e.g. smaller eraser *automatically* Hmm, I tend to forget that there are people who use mice for general GIMP work. I can see how this could actually save time then, if you only ever use Eraser with one or two different fixed brushes instead of switching a lot. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
On Thu, Jul 23, 2009 at 11:41 AM, Martin Cracauer craca...@cons.org wrote: Martin Nordholts wrote on Thu, Jul 23, 2009 at 12:40:06AM +0200: On 07/23/2009 12:27 AM, Martin Cracauer wrote: Do I understand that correctly that you will move to single-floats/color? [...] If you in the yet not officially released GIMP 2.7 do View - Use GEGL, then the layers will be composited using GEGL. In other words, we have the layers etc ported to a GEGL graph. It is worth mentioning that it is technically trivial to insert non-destructive nodes in the graph, but our focus now is getting GIMP 2.8 out. I use the git version of last week. Lost my tablet (probably due to some dbus API issue) but works otherwise. Let me just poke some more. And does all this survive layer copying and other changes? GEGL graphs are completely non-destructive (of course, you can flatten part or all of a graph to destroy information at any time.) The plan for GIMP here is that it will only modify the graph in the course of usual operations, which will enable the option of fully non-destructive workflow. In this system, we simply have to decide the way to present this ability to insert arbitrary nodes at arbitrary positions to the user. The idea I regard as most sensible here is simply treating nodes like a container -- that is, the input being made up of 1 or more node outputs composited together. With this idea, you would be attaching an effect to a group of layers (and effects There are issues with the above (primarily, I oversimplified -- we need to deal with nodes that simply produce, like eg. checkerboard, constant color, as well as filtering nodes), but that's a reasonable overall way to think about it for now. IMO GIMP is heading towards providing a fairly thin abstraction layer over the abilities of GEGL graphs, which in general is good news for anyone concerned about possible leaky abstraction (does all this survive layer copying and other changes) -- thick abstraction layers tend to be much leakier (for example, Photoshop's Adjustment Layers idea -- they are only layers in an absurdly broad sense (so broad as to be nearly meaningless), so they tend to disobey common-sense rules followed by other types of layer.) In short: the capacity for inserting arbitrary nodes is available in GEGL, but GIMP does not currently adulterate the constructed layer graph in any way; When some ability to control the graph in a finer way (like I described) is implemented, we ought to have moved on to the next-generation file format, which should support it in a straightforward way Even shorter: A completely theoretical yes, since such functionality is currently available in GEGL, not leveraged by GIMP or presented to the user yet. Let's use an example: I like to use the levels tools with a non-destructive adjustment first and although 2.6/2.7 allow me to take the levels I found right to curves I usually don't do this. I prefer to commit the level change, then duplicate the layer and mess with the curves in the new layer. This, of course, causes me losses from interpolation with the 8-bit channels, where it would not if I would edit levels and curves in the same moment without committing levels first and start over with curves. Does current 2.7 carry floating point layers through all of this? There are no floating point layers yet. During the composition, the layer pixels are automatically converted to floating point, and converted back after composition. to display the finished projection. Thus, the difference in the resulting image is minimal. During the application of a color tool, a similar thing happens: pixels are converted to float, the change is applied, and pixels are converted back. Eventually, using a color tool will just modify the image graph rather than directly writing pixels; at this time, floating point values will be preserved through that operation (and presumably most subsequently operations -- obviously if there is an explicit 'convert to 8bit' operation in use, floating point values are not going to last beyond that. I just tried this and I get the same teeth in the histogram in 2.7 no matter whether I asked it to use GEGL or not, but I'm not sure I activate it the right way. This was just on a layer originating from a JPEG. Does 2.7 as is support storing and reloading the floating point format in *.xcf files? Again, floating point currently has nothing to do with the normal representation of image in the GIMP, yet. This should answer your question. I believe we are planning to move to a new native image format for 3.0, which will address such problems as: metadata support being bolted on rather than a standard part of the file format, more sophisticated ICC support, support of higher bitdepths, support of different color models (LAB, YCbCr etc)... David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU
Re: [Gimp-developer] New color mode
I'm pretty sure Emil refers to the Color drawing /layer mode and the way that it tends to 'burn out' colors -- the result of applying a colorization is often far more vivid than could reasonably be expected; Basically the same as the bug regarding improvement of Color mode cf. Photoshop. A few theories have been advanced on how Photoshop does it; they both agree that an RGB-based application such as the current HSL application is incorrect, and IIRC argue for either LAB or YIQ/YCbCr based color application. In my opinion LAB is higher quality, however YIQ/YCbCr get the job done with acceptable quality and higher speed. I can do some visual comparisons sometime soon if needed. Exactly what do you mean by color mode here? Do you mean that the default RGB - CMYK conversion produces too saturated colors? Best regards, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hacking GIMP - Gimp top level menu
toolrc On Wed, Jun 17, 2009 at 11:00 AM, Jordan Stinsonjordan.stinso...@gmail.com wrote: Thanks for the quick response. It looks like this will get me closer to what i'm actually after. When I use this method to add the hue saturation tool to the toolbox, it persists after I close gimp and reopen it. Could anyone tell me what file it's saved to? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH 1/4] Tile caching performance patches
I'd like to mention also that there are also some minor problems with whitespace i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0002*.patch Applying Add additional profiling to tile usage in order to analyze efficiency and behavior of the tile cache. Profiling includes run-time indication of idle swapper activity. .dotest/patch:193: trailing whitespace. guint zorched : 1;/* was the tile flushed due to cache pressure .dotest/patch:255: trailing whitespace. #endif .dotest/patch:304: trailing whitespace. #ifdef TILE_PROFILING .dotest/patch:318: trailing whitespace. .dotest/patch:319: trailing whitespace. #ifdef TILE_PROFILING warning: squelched 12 whitespace errors warning: 17 lines add whitespace errors. i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0003*.patch Applying Replace two list 'flush clean first' cache strategy with an LRu strategy. Although the clean-first strategy gives fast light-load performance, it also degrades catastrophically under moderate cache pressure. LRU is not as efficient under light load, but degrades more gracefully under moderate and heavy load. .dotest/patch:148: trailing whitespace. .dotest/patch:191: trailing whitespace. .dotest/patch:196: trailing whitespace. .dotest/patch:202: trailing whitespace. .dotest/patch:205: trailing whitespace. warning: squelched 8 whitespace errors warning: 13 lines add whitespace errors. i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0004*.patch Applying Correct startup flaw in idle swapper start: Don't watch only UI idling, but also watch that the cache itself is idle. Previously it would start during transforms and long pyramid rendering ops and toss writes and large seeks into the tile cache while it was potentially under heavy pressure. .dotest/patch:149: trailing whitespace. .dotest/patch:157: trailing whitespace. .dotest/patch:158: trailing whitespace. if(count=IDLE_SWAPPER_TILES_PER) .dotest/patch:186: trailing whitespace. .dotest/patch:194: trailing whitespace. warning: squelched 1 whitespace error warning: 6 lines add whitespace errors. (patch 0001 applies with no problems.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement for eraser/brush tools: resurrect erased/cleared
On Tue, May 26, 2009 at 4:52 PM, Alchemie foto\grafiche fotocom...@yahoo.it wrote: How does this differ from the current anti erase tool option (quickly enabled also by holding Alt key)? Maybe does not differ BUT there is a Problem there is not any documentation in the help on a anti-erase option or tool so i believe almost only who contribute to implement it know about it This is simply not true. http://docs.gimp.org/2.6/en/gimp-tool-eraser.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please, Please Bring Back Old GIMP.
On Tue, May 26, 2009 at 9:00 AM, Sue for...@gimpusers.com wrote: Hi GIMP Developers, I am a longtime GIMP fan, and I am highly disappointed with the Version 6.6 UI. One thing I have always enjoyed about this program is the fact it was not like Photoshop, because I could multitask with other programs (I could be searching for other pictures in the background in the Windoze file explorer), minimize what I wanted, detach windows whenever I wanted (veery nice), and resize the brush in the Brush Editor on will, and minimize it when I needed. Now I can't do those things, and it looks like Photoshop. I find it irritating now that I've got keep the Brush Editor open all the time and it If you just use the Brush editor to resize the brush, I suggest you begin using the Brush Scale slider in the tool options instead; It's probably faster. resets its size whenever I re-open it. I find the new Navigator tool disorienting to use, and I can't be as precise either when I need to go to the exact pixel on the corner because the thing moves. I also don't like not having control over my windows anymore. Not having control over your windows is not caused by GIMP. I certainly have all the control over GIMP windows I need, and individual dockable windows keep their size and position as you seem to desire. Of course, if you close a dockable, you are saying 'throw away all information about this dockable', so in that case, naturally when you open a dockable of the same kind, it is simply put in a default position and size. However, with the various systems (which have been there before 2.0 even), like TAB and F11, you should usually not ever need to close a dockable. Especially if you dock them together to form a joined window or a set of tabs. Also, you might be thinking of the change of a default preference, which effects whether dockables are shown on top of all other windows. This change occurred somewhere after 2.4, I think. Anyway it does not impede you -- just change the preference back. GIMP 2.6 is also not single-window. It's a minimum of two windows (image window + toolbox), and can be much more according to how many images you open at once or dockables you open. There are plans to allow a full single-window interface, however this behaviour is a) not implemented yet... at all, really b) intended to be completely optional, allowing you to use either a single or multi-window setup according to your preference. c) not ever going to be Window-inside-Window as some people claim to want. Some people even perceive 2.6 to be Window-inside-Window, but it's not (as demonstrated eg. when you move the toolbox) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please, Please Bring Back Old GIMP.
On Tue, May 26, 2009 at 9:41 AM, Sparr spa...@gmail.com wrote: I disagree with of course and naturally. When I close [child/sub] windows[/tabs] in most applications, then reopen the [functionally] same window, I expect it to come back in the same state it was in when I closed it. I regularly open and close the dockable windows, and add/remove things to them, and the amnesiac nature of all apsects of this process is very annoying. This issue was actually discussed before -- IIRC it was decided that implementing this behaviour would cause even more confusion (essentially because the 'functionally' same dockable is not actually the same dockable. The other technical problem is that there can be more than one instance of some dockables instantiated, in which case there is no clear way to decide which 'old' positioning and parameters to use.. this would certainly be very confusing.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi, On Tue, May 12, 2009 at 6:48 PM, David Hodson hods...@ozemail.com.au wrote: On Mon, 2009-05-11 at 12:57 -0700, Stuart Axon wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. Exactly. A more accurate description of what I was looking for would be mark this point in the undo stack and revert to the marked undo point. (With an error code if the undo point no longer exists.) This approach seems more reasonable -- if the point to undo to must be explicitly identified (in the same manner that each version of a GIT repository has a unique id), there is no ambiguity involved; you are undoing a specific known part, and if that was already undone, a clear error can be raised. In order to do this, each undo step should have a unique ID. Currently, the GimpUndo structure includes a 'time' field; This might be sufficient as a unique ID if it is precise enough (eg. measured in microseconds) Photoshop has a similar feature called 'snapshots' which is user-accessible. I'm not sure whether that kind of thing is a wise thing to implement. Providing an API to programmatically do such things seems fairly uncontroversial to me, though. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au wrote: I can find the functions in the pdb to manipulate the undo stack - is there a function call that just does an undo? No. Although this might conceivably change in the future as GIMP integrates GEGL. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi David, On Sun, May 10, 2009 at 10:34 PM, David Hodson hods...@ozemail.com.au wrote: On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote: On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au wrote: I can find the functions in the pdb to manipulate the undo stack - is there a function call that just does an undo? No. Although this might conceivably change in the future as GIMP integrates GEGL. What does it have to do with GEGL? There's already an undo button there, it just needs to be connected to the API. No it doesn't (in fact, I'm sure a few GIMP developers might argue that it definitely needs to NOT be connected to the API (ie. stay as it currently is)). This has come up before, to the response essentially 'why would we court trouble by implementing such a thing?' While it *could* be connected to the API, that would introduce various logical inconsistencies (for example, plugins could not rely on having a sensible image state because other plugins (running concurrently, or called by the plugin itself) might roll back the image state. Then the user can still make sense of the image state, but the plugin has no idea what it is, it could be anything. This is particularly bad if a crash is happening, as it also reduces your ability to correctly deduce the cause of the crash.) GEGL would allow a graph-based image structure, in which conventional plugins might not be needed (rather, new GEGL Operations could be implemented via a much simpler type of plugin.) This might help address the above concerns, as well as helping to support more sophisticated undo/versioning structures than our current 'piece of string' model, like trees. Hmm, I take it back, GEGL would not help the likelihood of such a thing being implemented.. it's just a Bad Idea. For just the same reasons that Global Variables are a bad idea. As the Zen of Python says: Explicit is better than implicit. Complex is better than complicated. In the face of ambiguity, refuse the temptation to guess. If the implementation is hard to explain, it's a bad idea. David ___ 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 Thu, May 7, 2009 at 7:54 AM, Martin Nordholts ense...@gmail.com wrote: Hi I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize, merge and push to GNOME master. The patches are attached to the bug report http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and test: cd ~/source/gimp tar -zxvf save-plus-export-2009-05-06.tar.gz git checkout -b save-plus-export-2009-05-06 master git am save-plus-export-2009-05-06/* this will create and switch to a new branch based on top of your local master branch, and apply the patches to that branch. Then you build and install as usual. This doesn't seem to work -- patch #0010 fails: Applying app: Add an 'export' mode to the file save dialog error: patch failed: app/dialogs/file-save-dialog.c:138 error: app/dialogs/file-save-dialog.c: patch does not apply Patch failed at 0010. The patch appears to be offset by about 10 lines. I applied it manually, and then ran git-am --skip Patch 0011 applied ok, Patch 0012 had problems: Applying app: Improve save and export error messages error: app/dialogs/file-save-dialog.c: does not match index Patch failed at 0012. Applied that manually, Patches 013..017 applied OK. 018 says : Applying app: Remember last export URI for each image error: app/dialogs/file-save-dialog.c: does not match index error: patch failed: app/file/gimp-file.h:27 error: app/file/gimp-file.h: patch does not apply Patch failed at 0018. Done manually, 019 fails similarly, done manually, same for 020, 021 022 applied ok. It's possible that I didn't understand how to 'resolve' a problem ( now I think it is, apply the patch manually, 'git add' the relevant files, and 'git am --resolved') I'm now trying to build it.. Trying it out.. This works REALLY well! I 3 it! It behaves much more comfortably than the old setup, I anticipate no longer needing to awkwardly 'save copy' so frequently simply to get a web-usable version of the image. I like how, if I hit 'revert', it properly reverts to the source image (eg 12.gif rather than the working document 12.xcf) I was confused by how 'export to foo.png' was only usable once the image became dirty (ie. I changed it ). If that is considered appropriate behaviour, then your ability to 'save' should also depend on the dirtiness of the image David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi Jon! On Thu, Apr 30, 2009 at 4:35 PM, Jon Senior j...@restlesslemon.co.uk wrote: On Thu, 30 Apr 2009 11:01:08 +0930 David Gowers 00a...@gmail.com wrote: X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors) So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone. I didn't understand it at first, and believed that the idea was that 'x' would cycle through the colours in a palette. Meaning that the user would press 'x' once to change to a new colour and another four times to go back to the original. Looking at your animated gif it all makes a lot more sense, although I suspect that the timings will be critical. I would also (as a user) want some method of adjusting or loading those five colours, either via 5 swatches in the tool box, or a single choose colours dialog. Thanks for the feedback ! :) I envision that you would just choose colors whenever you want, and that new color would enter slot #1, and push back the other items (knocking the item in the old slot #5 out). This is how it works in MyPaint, and it's pretty effective. However, this may take some consideration as to when to adjust the color history, as the color selection dialog of GIMP allows you to tweak colors continuously, with no clear indication of when you're 'done' selecting a color. I guess we'd store a copy of the color which was in slot #1 before changing it, and then adjust the history (slots 2,3,4 - slots 3,4,5; stored color - slot 2; new color = slot 1) after a certain time delay(1.5 seconds?). In this way slot 1 would always be current, while avoiding overpopulating the history with minor tweaks of a single color. In the case of clicking to sample colors from gradients, the history ought to update each time the user releases the left mouse button. (Note: my understanding is that there is a distinct lack of users who are aware they can left-click to sample colors from gradients, sadly.) In the case where the popup dialog, or palettes, or eyedropping, or drag-n-dropping colors, is used, no delay is necessary (because the user is explicitly specifying when the color is 'ready'; the meaning of their actions is entirely unambiguous.) If you wanted to fill all 5 slots with 5 specific colors from the image, you'd just ctrl+click 5 times (assuming you're currently using a paint tool), or click one after another on 5 colors in your palette, or one of the other methods I mention above (that currently only effect the FG color). Simple. With that, I believe there is no need to edit anything other than a single color (slot #1, the current color) On a related note: The popup color editing dialogs have color history (A ColorNotebook?) (for example, doubleclick on a palette color) This is slightly different in nature to the kind of history I'm suggesting -- the popup history list is like a list of 'colors I like' (10 long; colors are only added explicitly with the '' button), whereas my history list of course is of 'colors I'm using right now (or recently)'. These two lists would not interact in any way, due to their fundamentally different application. It's important to depict these two color histories in a differing way, so that there is no confusion between the two types of history (semi-permanent vs transient) If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' - 'previous' It does also resolve a question that was floating around in my head as to what the new non-background colour would be called. The gradient tool is an obvious example of one where the foreground/background naming convention is strong, and easy to understand. This might require that the choose colours dialog allows a method for swapping the colour order, because having to do it using only 'x' could get annoying when arranging two colours for use in a gradient. Again, a maximum of two eyedroppings/ your method of choice should easily arrange the color history appropriately. Also, my experience with MyPaint is that needed keypresses are few -- remember, you would only have to press X a maximum of 8 times to get any two colors to the front. The '8' example comes from if you want slots #5, #4 transferred to #2, #1. You press X four times to select #5, and wait a short time (1.5s?); then press X another four times to select #4 (which became #5 after your previous selection). the history looked like this (letters represent colors rather than slots) ABCDE and after the first step it looks
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 9:13 PM, yahvuu yah...@gmail.com wrote: Hi David, here's a mockup idea on your proposal; might or might not help to identify the current-previous color pair... just brainstorming. I hope you're not bothered i'm sending private mail - it's just i can't contribute anything generally useful on the topic, much along the lines of what Martin said. When Martin said that, I thought that just means it's inappropriate for us to make the decisions. It doesn't mean we shouldn't do research -- in fact, I'm sure Peter Sikking would appreciate it. Hence, I've CCed this to the list. All i know (or imagine to know ;) is that the only tool which requires the background metaphor is the eraser, including the 'selection erasers' delete and cut. I don't even see a conflict with bg-color-layer, despite that's where i started to question the bg color swatch.. So from my point of view, everything is open for the tool box, be it mypaint style, or even mypaint+bg color, color swatch plugins, left-right+bg color, you name it. I've looked at your image, and I'm not sure what it's supposed to be. A layout for the OSD? or a toolbox status display? Or something else? When you say 'toolbox' I'm also not sure whether you mean the optional colors display at the top of the toolbox, or the 'Colors' dockable (or both) Have you looked at MyPaint? It doesn't *have* a status display :) It allows you to edit the current color (via a shortcuttable menu item) and move through the color history; that's the only time you see the color history, via the Onscreen Display. The OSD I mocked up before is pretty close to what MyPaint's OSD looks like, though. I've created a mockup of my own idea of a toolbox status display. It's based on the old color display (I think we should try to take the same amount of space as before).. It's attached. I believe it makes the current + immediately previous color obvious, while clearly prioritizing the current color, and showing the other indication. I left the 'reset' and 'swap' icons there, because they still make some sense. In the OSD I mocked up, the current + previous color are always the rightmost color , and the color immediately next to it. So IMO no further indication is needed in the OSD. many thanks for taking the time for discussion and all the great work on GIMP, Thanks for starting this thread that so much interesting discussion has come out of :) David attachment: toolbox-color-mockup.png___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 10:36 PM, Rob Antonishen
rob.antonis...@gmail.com wrote:
I just ran through my scripts.
In the .scm files distributed with gimp, there were:
38 files containing gimp-context-set-foreground
65 files containing gimp-context-set-background
The ones I have looked at, mainly set background and then do a
edit-fill with BG or a drawable-fill.
looking at the scripts I have installed in my home directory, there were:
49 files containing gimp-context-set-foreground
29 files containing gimp-context-set-background
This is my no means a thorough assessment. Perhaps the individual
operating the gimp plugin registry could grep all the plugin files and
give a better count of the third party scripts using these calls.
There is no question of removing either of the above PDB functions,
AFAICS. It's just a matter of what to do to emulate the old FG / BG
behaviour. In the case of my proposition, FG would remain (as slot #1
-- 'current') and BG would map to slot #2 ('immediately previous').
However, one side effect is that setting FG could change BG (through
the normal history cycling mechanism). Erk.
David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hello, On Wed, Apr 29, 2009 at 11:17 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote: guys, here is sort of a review of what has been discussed here: To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch. How is one supposed to paint on mask without bg/fg color swatch? That's not included in yahvuu's proposal, but I proposed something that could neatly solve that, and address gradient issues: replace the FG/BG color concept with FG + cycleable 4-long color history. In this situation, you could still press a single key to swap between two colors (you would be swapping the previous color with the current color). Pressing it multiple times could cycle further back (in both cases you could get a simple OSD -- see MyPaint for example.). 'previous color in the color history' still can have roughly the same usage, we would just not be giving that color special treatment by labelling it 'BG'. The 'FG to BG' gradients still make sense in this context, they could just become 'Current to old color' (and usage patterns should be virtually identical.) Peter's done a good job synthesizing the 'BGcolor' with the requirement to specify whether alpha channel is desired in any exported/flattened image, and also notices similar problems to you. The problems brought up by both of you, Alexandre and Peter, are addressed neatly by my proposal above. Perhaps it needs a mockup.. I feel it fits very well into yahvuu's proposition, turning its weakpoints into strong points. Something that hasn't been brought up, BTW: Flatten Image vs Merge Visible layers. Not exactly the same, but would become closer to each other if Peter's description was implemented. Maybe we need to attempt to rationalize that. The behaviour of Sample Merged seems fairly obvious here, but I'm bringing it up also, just in case. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com wrote: 2009/4/29 peter sikking pe...@mmiworks.net but some crucial things depend on the bg color. the gradient tool being the big show-stopper for me. the tool needs a redesign, but up to then the fg-bg type of interaction looks to be the most (universally) usable to me. Unless you make a ease and nice way of swathing (or alternating) colors, I'm against it. When you are painting (making a digital painting or painting on a mask...) in the current version you just hit X to alternate between bg / fg colors. Its just ease that way. I've already made a proposal that thoroughly addresses this twice in this thread. It is based on a system MyPaint (http://mypaint.intilinux.com) uses, so I've already tried a very similar system and found it very effective. It's simply a 5-slot color history, with X selecting from it (when a color is 'chosen', it goes into slot #1 in the history (slot #1 == FG/ actual painting color), the old color moves into slot #2, and the rest of the items are moved back if needed. Just standard history operation.) X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors) So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone. In case people have read it and simply not understood what I meant, I'll provide an animated GIF, and perhaps submit a derivation of the GIF to gimp-brainstorm.blogspot.com http://img.photobucket.com/albums/v449/neota/alphazero/animation.gif I'm not sure whether or not Yahvuu was alluding to my proposal when he says i think the gradient tool would work equally well if the swatches were named left - right. If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' - 'previous' David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi saulgoode, On Tue, Apr 28, 2009 at 7:00 PM, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting David Gowers 00a...@gmail.com: The eraser currently does change color values, in the case of layers without alpha (it's like using paintbrush or pencil with the background color). Yahvuu's proposition would make sure it never changed color values because there would be no layers without alpha. I don't understand the last sentence (perhaps I don't understand Yahvuu's proposition correctly). If color values are never changed, the only place that erasures would result in an image background color (being revealed) is on the bottommost layer. Is that what is being proposed? No, because your reasoning is oversimplified. The above situation could occur, but it depends on the image content. Some images would have transparent areas even on the bottom layer (this is common in web graphics and icons) If so, then I would consider the lack of consistency in the tool's behavior across layers to be a problem. Is there an inconsistency to be had? It will behave just the same as before, really. Only it will never ever change the colors on any layer, because it will never encounter a layer without alpha that requires it to paint with BG color instead. If it is not so, what determines whether or not erasure results in the RGB part of the image background color being blended with the layer contents? The alpha channel of the respective layers. Erasure never results in the image background color being blended with the layer contents. The effect on the layer contents is only a change in alpha channel, just like it currently is provided your layer has an alpha channel. Yahvuu's proposition is essentially a) have a 'virtual layer' always at the bottom of the stack, filled with a color and b) make all layers have an alpha channel Nothing more. It does have some ramifications to certain functions (like Cut and Float) but none really to Eraser (just that the eraser code can be simplified. most likely) David ___ 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 4:10 AM, Martin Nordholts ense...@gmail.com wrote: yahvuu wrote: Hi all, Alchemie foto\grafiche schrieb: The possibility to add CUSTOM layer modes [..] that sounds interesting. Just curious: i wonder how custom layer modes differ from filters that take a second layer as input (e.g. LIC)? i mean, other than that filters currently work destructively. Hi, A layer mode is a formula for blending two pixels together, producing a result pixel. That is, the set of all layer modes is a subset of the set of all filters that blends two layers together, producing a result layer. There is one exception to this nice classification of layer modes; an output pixel when using the Dissolve layer mode does not only depend on two pixels, also on the position of these pixels. Spontaneously I don't think custom layer modes is a good idea. Might be fun for programmers to play with, but graphic professionals? While this is generally true... when switching apps, with a strongly established workflow including an app-specific layer mode, I can see this being quite useful. OTOH, this could also be implemented by a drop-in replacement for layer merging that supports additional modes (ranging 0x80...0xfe in ID, perhaps), providing that contributing a new mode to such a GEGL op could be as painless and simple as writing the formula. And that method would be faster. Alternatively If you really need 'custom' layer modes, I see no reason why it cannot be applied as a layer effect, building a bit of GEGL graph from the existing layer modes and ops. So now that I've thought that out loud, My conclusion is: Could be quite helpful, we don't need full custom layer modes, If we support them in one way through layer effects, someone else could write a GEGL Op that implements formulaic customization separate to GIMP's codebase. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi saulgoode, On Tue, Apr 28, 2009 at 12:29 PM, saulgo...@flashingtwelve.brickfilms.com wrote: Perhaps I am misunderstanding this proposal, but the ramifications seem to be more confusing than the present method. And while I realize that GIMP does not make any guarantees about retaining the colors of transparent pixels, its current behavior is quite useful for editing files destined for applications which employ the alpha channel in unconventional ways. It also offers a few other atypical benefits, but mainly it is consistent and easy to comprehend what is happening. Some questions: I don't understand some of your following objections (or I think they are based on false premises) The eraser currently does change color values, in the case of layers without alpha (it's like using paintbrush or pencil with the background color). Yahvuu's proposition would make sure it never changed color values because there would be no layers without alpha. Thus, several of the things you brought up have no relation to the proposition (because they could not possibly occur through implementing this proposition) If a PNG is loaded as a layer, should the image background color be updated to the PNG file's background color? or should it remain what it was originally? If a JPEG is loaded as a layer, should the image background color be set to white? Good questions! It's pretty clear to me, that if the PNG provided a background color, we should keep it; otherwise, we should assign our own. It looks like my proposed 'image has an alpha-channel' flag is needed here to avoid occasionally changing the meaning of pictures. There is no right or wrong behaviour for JPEGs imo, since they are completely opaque and predicting a good BG color automatically would be more troublesome than it is worth. I think 50% grey (#bababa) is a better default BG color for when a default is needed. Should gradients be using the image background color or the second color in a color slot history? I think, given a slot history such as I described, it would be helpful to provide the ability to 'virtually point at' any of the 5 slots (considering 1 = current, 5 = oldest) and deprecate the notion of 'background color' (or even precisely 'foreground color') from gradients; automatically convert references to BGcolor into slot #2, yes. The 'slots-based' history would serve the same purpose in terms of gradients -- allow quick building of gradients -- just that it would be even more flexible and quite often more quick :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
Hi LIMN, On Sun, Apr 26, 2009 at 7:07 PM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, Gimp 2.6 allows to use brush dynamics to control opacity, size, hard and color. These features greatly increase the drawing capabilities of gimp, and many users find them very useful. However, we don't have any way to access these from inside the PDB... I think that it would be nice to be able to access these using the PDB, however I'm not sure about the right method: Do we want to allow the user to specify velocity, and pressure for each coord, or should we use the emulate brush dynamics feature (the same one we have in the libart stroking)? Personally, I believe that the emulate brush dynamics is the right method. We should definitely make dynamics available, but IMO both of these methods is quite unsuitable and would only add to the current inconsistencies of the pdb interface to paint tools. In my opinion this is what needs to happen: A) Migrate paint tools at least partially to GEGL (so that the actual rendering of strokes is done by evaluating a 1-node GEGL graph). This will help us define a consistent, expansion-compatible way of communicating and storing stroke information. B) Make a system for handling both full strokes (where each point specifies parameters such as brush scale, rotation, aspect ratio, spacing directly) and simple strokes (where each point only specifies the 'source' information -- pressure, velocity, angle, etc.), and converting simple to full strokes C) Work out a way to pass this information through the PDB, in a backwards + forwards-compatible way -- so that older scripts work in newer versions because their missing fields are automatically expanded and filled in with sensible default values, and that newer scripts work (in a limited sense) in older versions of GIMP. D) Provide a method of constructing and communicating GEGL graphs through the PDB. This can be used by scripts to actually do the required painting. E) Use it (and deprecate the current 'gimp-paintbrush' etc API) I also think we need to look harder at our current inability to communicate various tool options such as Jitter, Color from Gradient, and Incremental; possibly communicate these via a keyword-argument sort of interface (ala Python) I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc. Do you understand that you must not change the api of gimp-paintbrush, gimp-airbrush, etc? Because that would break a lot of scripts and plugins. This is part of the problem with the current PDB interface to tools; supporting new options must be done through additional PDB functions. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
Hi Theodore, On Sun, Apr 26, 2009 at 8:00 PM, Theodore Imre blurym...@gmail.com wrote: gimp is not a good choise for digital painting because it doesnt have a blending tool. Paint tool sai in the respect is far superior because its brush engine is much more advanced for smooth blending Please keep your replies on topic. This thread is about improving the plugin API to the painting system of GIMP (which is not, anyway, a program for digital painting, but a 'Image Manipulation Program'; naturally tools designed for digital painting, Like MyPaint or Krita, will be better for digital painting.) As Paint Tool Sai is also not open-source, it definitely has no relevance to this thread, unless it also possesses a programming API for plugins or scripts to non-interactively paint which solves this same problem, and which you will describe. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hello yahvuu, On Sun, Apr 26, 2009 at 9:31 PM, yahvuu yah...@gmail.com wrote: Hi all, peter sikking schrieb: I like the innovative nature of the idea. it would not be without a hint of irony if, after 40+ years of digital image processing, GIMP were the first to finally introduce the concept of a background color ;-) And i'm not aware of a raster file format which features that concept. Let's see if it's any good. Yes, this is certainly an interesting idea, worth trying, and I agree it has potential to address quite a few problems. the secondary workflow gets simplified: importing e.g. a JPG creates a GIMP document with one layer and the image background color set to opaque white. Any modification other than making the background color transparent preserves the image projection's property of being fully opaque. Thus on export, the projection can be converted to JPEG format without asking the flatten? question (which actually asks wether to fill transparency with a bg color). For file formats which support transparency, e.g. PNG, import initializes the image background color to neutral, say transparent white. For a cycle of import and export this doesn't introduce any change: - if the PNG was fully opaque before, the imported bottom layer will be fully opaque, thus covering the background color. - if the PNG has transparent pixels, the projection will have them, too. The image bg color does not introduce any change as it is fully transparent. In both cases the flatten or merge layers? question becomes obsolete. As a side-effect, the automatically chosen image bg color gives a non-intrusive hint about the imported file's transparency capabilities. (That's another reason why GIMP should not try to be smart in choosing the image bg color, e.g. from image content. The first reason beeing that this can't be done reliably, e.g. trying to recall the image bg color of an exported JPG on re-import) This all sounds pretty good to me - I would like to see some more thinking on how this is related to the background color in the color chooser. coupled/decoupled? in short: decoupled, definitely. An explicit image background color actually questions the very existence of a color named background as part of tool state. Having several colors available for instant access is undoubtedly very handy in the sense of a core mini-palette. See MyPaint -- it provides a 5-slot color history. You'll need to try it to see how it works. (the 'previous color' action swaps between the 2 most recent.. but it pops up all 5 visibly, and pressing it quickly multiple times moves further back. From my experience, this works much better than having FG and BG color and swapping them as needed. MyPaint is a dedicated painting app, I think we could really learn from it here; the way it handles color history is comfortable, discoverable, and non-intrusive. Labelling the second color staticly as background - although being a good mnemonic - is somehow a remainder of evolution from the days of non-alpha, single-layer images. Totally agree, it's always seemed a bit odd to me. This shows up in the case of the eraser tool. Cleary it should erase to background color. But what is the background color of a layer? Currently, the answer depends on layer state - wether it has an alpha channel or not. This can be unified according to the rationale that layers are just transparent sheets in order to prevent mode errors. Then the answer is to erase to transparency, on the alpha channel. Consequently, the eraser doesn't require a background color as part of tool state anymore (and which other tool does?). I see where you're going with this. One bump I see is things like Cut and Float -- quite often I want them to fill the source area with a solid color rather than with transparency. When this doesn't happen, it's awkward (as the layer) The benefit of an image bg color in that context is that the bottom layer doesn't need to be special-cased: a newly created GIMP image consists of a transparent layer and an opaque white bg color by default. The other important tool which utilizes the toolbox bg color is the fill tool. From my experience here, the tool box's bg color serves more as a lay-by for smooth interplay of multiple tools than actually as a background color. Even when working on a single layer, i tend to change the bg color quite often; YMMV. Anyway, binding the 'CTRL+.' shortcut to the image bg color will limit it's usefulness. Another tool which accesses the tool box's background color is export. The cases where the export process needs to eliminate transparency will probably still arise, though much less often - e.g. exporting an XCF with transparent bg color to JPEG. This could just utilize the RGB part of the image bg color. Might not be very intuitive, though, as it's difficult to visualize the difference between transparent white and, say, transparent
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
On Mon, Apr 27, 2009 at 4:42 AM, Rob Antonishen rob.antonis...@gmail.com wrote: Here is another question... Should the basic paint calls (I.e. Those with the description using current brush) that have no parameters just be changed to paint respecting all the current brush options, like scaling, jitter, etc. ? We cannot do that, unfortunately, as it would substantially change the meaning and effect of some existing scripts and plug-ins. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP - Request for a feature - Animated GIF from a Video File.
Hello, On Mon, Apr 27, 2009 at 12:23 AM, Krishna Revuru krev...@hotmail.com wrote: GIMP-Dev-team, I was trying to create an animated GIF on a Linux-machine and after quite some google-ing I came across the below site http://nativeraving.blogspot.com/2007/11/creating-animated-gif-files-with-ubuntu.html The summary of steps described in this site to create an animated GIF from a video file are: First you need a program called Avidemux Once you have that installed you need to launch it and open the video that you want to chop. Select the part of the video that you want to use as an animation using the A/ and /B buttons. A/ = Beginning /B = End Now you need to save your selection as JPEG files. In Avidemux go to FileSaveSave Selection as JPEG images... Save the project to a new folder, then view the files in their folder and delete any unwanted frames. Next, fire up F-Spot photo manager, import the folder: FileImport To resize the frames we will need to export them. In F-Spot you will need to click on browse and then hit CTRL+A to choose the frames Then export them: FileExportExport to folder... Then reduce the amount of pixels to resize the frames. Next you need to fire up the GIMP and open the first frame. Next we need to open all the frames as layers. To do this we need to go to our first frame and go to the menu: FileOpen as layers Browse to the folder with all the frames in it and hit CTRL+A Then hold CTRL and click on your first frame to deselect it and then open the files. Hit CTRL+L, that will bring up the layers. To preview your animated image simply go to the picture window then: FiltersAnimationPlayback and hit play. To help reduce the file size go to: FiltersAnimationOptimize (for GIF) All you have to do now is save the image as a GIF and choose to save it as an animation. Given this scenario, I wanted to request a feature that I believe will be handy for a lot of users with similar requirements. Is there any way we can add a feature that takes in a pre-cut image and makes an animated GIF out of it? I understand GIMP is more for Image-editing and not Video-editing, but if there is a provision from within GIMP to cut specific section from a video file and convert to an animated GIF then it will be a superlative feature. Use GIMP-GAP. This makes such a task very simple AFAIK: 1. Load (part of) a video file as a GAP animation, using the Video-Split video into Frames submenu 2. Convert it to a conventional GIMP animation using Video-Frames to Image 3. Save the resulting image as a GIF. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Mon, Apr 27, 2009 at 2:20 AM, yahvuu yah...@gmail.com wrote: Hi all, David Gowers schrieb: One bump I see is things like Cut and Float -- quite often I want them to fill the source area with a solid color rather than with transparency. When this doesn't happen, it's awkward (as the layer) Did I really write that (as the layer)? I meant (as fuzzy/foreground-selection then stops working 'correctly' on that part of the layer) in terms of the model under discussion, this is a shortcut for cut fill. I wonder, doesn't CTRL+C.V do the trick? No, think about it, once you have 'Cut' something the selection is gone. All that would achieve is to fill the entire layer with a color ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
