Re: [Gimp-developer] Paint core beyond 2.6
Hi Alexia, On Sun, Jun 8, 2008 at 6:18 PM, Alexia Death [EMAIL PROTECTED] wrote: * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? I mean both. The dream is that paincore would only need to worry about Yes, that's what I meant, sorry. painting a stamp at a given event, the where? part is all handled by paint core. The distance in this case is the stamp spacing. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for What you describe is redundant if you expose those separately... since they currently effect either color or opacity according to distance from start of stroke. That's why I said replicate. I think you could improve this idea a lot by making some mockups, where you can easily spot and eliminate unnecessary redundancies. (I'm certain that there are quite a few neither of us has noticed.) Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made This sounds pretty good! I'd like to suggest the use of bottom-scaling as well as top-scaling here: that is, allow the quick adjustment to either scale down like 0..1 becomes 0..0.5 (scale == 0.5) or scale down like 0..1 becomes 0.5..1.0 (scale - 0.5). I can certainly vouch that I've wanted this a lot of times for Size -- the minimum size ends up far too small sometimes. are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and unsaved tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent. Yes, mockup sounds like it would help. I think what you describe above doesn't yet warrant the description of creating new user-tools. Mainly because it does not support some things that are important at a tool-level: Hard Edge, Clone-like behaviour. Consider talking to peter specifically about this -- he has the 'Dabs of paint' idea, which IMO is more correct than associating settings with either a brush or a tool; In the same way that acrylic paint on a brush has quite different physics than watercolor paint on the same brush. What you are talking about might be called something more like a tool-tip (yes, unfortunate but accurate; how about pen-tip? paint-tip?) IMO a good distinction is like: * tool : what you are doing and how you are doing it * tip : the precise effect that occurs when painting * brush: the area and amount in which it is applied. * paint : all of the actual pixels that end up being applied. HTH, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint core beyond 2.6
Hi Alexia, On Sun, Jun 8, 2008 at 5:52 AM, Alexia Death [EMAIL PROTECTED] wrote: This is a planning idea for new PaintCore for GIMP 2.8 or beyond. [...] * support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box); A 'Dynamic selection'? what does this mean? Just that you are free to choose one of these? * If you treat random, etc as axis, you need to provide a method of scaling them, or can you guarantee that they all range 0 .. 1.0 ? I think sin and cos could be implemented as a subcase of 'custom': a custom curve input. * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? According to what you wrote above, a 'distance' axis might be good. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] community website
Hi Frank, On Mon, May 26, 2008 at 8:21 AM, Frank Karlitschek [EMAIL PROTECTED] wrote: Hi guys, I'm running openDesktop.org, KDE-Look.org, GNOME-Look.org and other websites for Free software. As a long time GIMP user I noticed that there is no real community site where GIMP users and developers can share Brushes, Images, Fonts and Tips and Tricks. Did you check out places like www.gimptalk.com? I think it is a big enough forum that having a link to it could be good. also gimp-brainstorm.blogspot.com, since you have a brainstorm section. So I created www.gimpstuff.org . It is part of the openDesktop.org network. So if you have an account on GNOME-Look.org on any other website you can login. I'm impressed! It's quite comprehensive. I'm about to submit my dithering/halftoning patterns there. I've been looking for such a site for a while, since I have some considerable amount of resources to contribute. I hope this is helpfull for you and the GIMP users. What do you think? I you have ideas or suggestions how to improve the site please send me a mail. Cheers Frank P.S. GIMP rocks. :-) -- Frank Karlitschek [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] community website
On Mon, May 26, 2008 at 11:51 AM, David Gowers [EMAIL PROTECTED] wrote: Hi Frank, On Mon, May 26, 2008 at 8:21 AM, Frank Karlitschek [EMAIL PROTECTED] wrote: Hi guys, I'm running openDesktop.org, KDE-Look.org, GNOME-Look.org and other websites for Free software. As a long time GIMP user I noticed that there is no real community site where GIMP users and developers can share Brushes, Images, Fonts and Tips and Tricks. Did you check out places like www.gimptalk.com? I think it is a big enough forum that having a link to it could be good. also gimp-brainstorm.blogspot.com, since you have a brainstorm section. So I created www.gimpstuff.org . It is part of the openDesktop.org network. So if you have an account on GNOME-Look.org on any other website you can login. I'm impressed! It's quite comprehensive. I'm about to submit my dithering/halftoning patterns there. I've been However, I could not do so. I filled out all the bold fields, selected 'upload', browsed to my 6k zip of patterns, provided two screenshots, and checked the copyright checkbox, clicked the 'Save' button and got this message 'Upload not successful! Missing required data or file too big?' Must I upload each pattern as a separate .pat file? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] An idea for resource management
It would be worthwhile to consider this kind of thing for gradients and palettes, too -- personally I find I often simply want a scratch area; and being required to create a new palette first is a bit troublesome, especially since I usually don't want it to be saved. I could write a plugin that clears a specific palette and then switches to it, that would be good, actual infrastructure in GIMP for scratching around would be better. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Edit-Copy bug/misbehaviour
Hello, I'm not yet sure I should file this as a bug, since I find myself confused about it. You may need 2.5 or SVN to reproduce this? Do the following in order to reproduce it: 1. Open an image 2. Make sure that nothing is selected, by using 'Select-None' 3. Edit-Copy 4. Notice how the Clipboard Brush goes blank, rather than changing to the copied data or a cropping of the copied data (since 512x512 is the limit of clipboard brush) 5. Check that the image data copied okay, with Edit-Paste as-New image 6. Go back to the first image 7. Select-All 8. Edit-Copy 9. Notice that now the clipboard brush correctly contains the copied pixel data. It is my understanding that usually, having nothing selected is treated the same as having everything selected. I guess that this behaviour is probably a bug, and likely just a simple mistake, readily fixed (I don't have easy access to a SVN checkout currently, So I cannot verify this) If not, I hope someone will inform me so that I can file a bug :) -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A simple (?) question...
Hi Torsten, On Thu, Apr 10, 2008 at 6:50 PM, Torsten Neuer [EMAIL PROTECTED] wrote: Hi Sven, On Wed, 2008-04-09 at 09:27 +0930, David Gowers wrote: What you are talking about is a hash function. There is a string hasher in GLib that should do what you want. The string hash function in GLib is not suitable for this job. Torsten doesn't want to hash a string, he is asking for a checksum over image data. Yes, I discovered that myself, since the string hasher would have difficulties with handling the binary data of the drawable passed on to the plugin. Oh. I had assumed that the glib string hasher worked similarly to the Python string hasher, meaning that binary data was perfectly okay. My mistake. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A simple (?) question...
Hi Torsten, On Wed, Apr 9, 2008 at 4:35 AM, Torsten Neuer [EMAIL PROTECTED] wrote: Hello everybody, I am currently updating an older plugin (one that is not in the distribution nor in the registry anymore) in order to bring it back to life (and, well, maybe learn something about Gimp programming as well). The plugin although it worked quite well, seemed never to have been finished. Now, there is a random function in this plugin, which according to documentation, would require a random number seed that is unique for every image that is going to be processed, i.e. the result of the random function should be identical for any identical image. This, however, has not been implemented as such in the old files. Now my idea was to use some sort or CRC on the drawable to get a seed for the random number generator, that would match these requirements. Since I haven't been able to find a function within the libraries that I could use as a starting point (and of course I do not want to re-invent the wheel), my question is, if there is such a function that would provide an identical value for any identical image - or would I have to write a kind of pre-filter in order to generate that value ? What you are talking about is a hash function. There is a string hasher in GLib that should do what you want. However, be aware, the criteria 'a random number seed that is unique for every image that is going to be processed,' cannot be fulfilled in an absolute way. With a hash value of 32bits, that's 4 billion possible hashes. Practically speaking, you are unlikely to encounter a hash collision* unless the amount of images in the set you're processing gets very large, you should be aware that it is always possible though. * when two different data produce the same hash value. Thank you very much for listening, Torsten ___ 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] Activating actions through the PDB
Hi Sven, On Wed, Apr 2, 2008 at 4:57 PM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2008-04-02 at 14:21 +1030, David Gowers wrote: This second class is really all I can see traditional plugins needing to do after GEGLification is complete and stable. Ie. the first class of plugins wouldn't need to use the PDB at all, probably. Do you agree with this idea? Absolutely not. The GEGL API is not sufficient for this class of plug-ins as plug-ins will still need access to GIMP objects such as layers and masks and whatever else. There are associated GEGL nodes for these objects, but that is by no means sufficient. Oh.. of course. Sorry, I was thinking about things like gradient-map, normalize, and tile. More complex things like warp, gimpressionist, or sample colorize didn't occur to me.. In that case, it makes sense that a plug-in would mainly provide actions. It is also useful to be able to trigger other actions, since many things aren't accessible through the PDB yet, only as actions. (for example, I would like to make a plugin that creates an additional display, zooms it to 200% and then shrink wraps it, so I have a 'working area' and a 'real size' view.) This is intentional. The PDB doesn't provide access to the GIMP user interface. Scripts and plug-ins are supposed to in non-interactive mode as well. What you are asking for is completely outside the realm of the PDB and it is not going to be added there, ever. If we really want to expose such user interface functionality to scripts, then we will need a different scripting API for it. Sven Okay. The kind of plug-ins I'm talking about are also too lightweight for the current framework -- it's best if they run quickly -- and my current workaround can run them quickly (20 times / second for the average one). Truthfully UI manipulation doesn't fit in that area, almost everything is either about a quick manipulation on the image (vector-smooth a binary selection, colorize a greyscale, 'apply' a layer) or a quick change to the context (interpolate colors, colorize a brush, sieve a brush). I really think there is a place for this type of simple 'macro' host. Hopefully I can get it into releasable state soon. I'll just have to hack around the rest.) Thanks for your time. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Activating actions through the PDB
I've been talking to a few people about the future of GIMP plugins,
and worked out that in terms of current plugins, there will end up
being two types:
Those that are related to GEGL (implementing GEGL operations,
modifying graphs, applying graphs) and those that are not (convenience
plugins that don't modify the image state directly, such as my plugin
to set FG to the average of FG+BG, plugins to generate resources like
brushes patterns palettes or gradients, plugins to analyze the image,
etc..)
This second class is really all I can see traditional plugins needing
to do after GEGLification is complete and stable. Ie. the first class
of plugins wouldn't need to use the PDB at all, probably.
Do you agree with this idea?
In that case, it makes sense that a plug-in would mainly provide
actions. It is also useful to be able to trigger other actions, since
many things aren't accessible through the PDB yet, only as actions.
(for example, I would like to make a plugin that creates an additional
display, zooms it to 200% and then shrink wraps it, so I have a
'working area' and a 'real size' view.)
Currently, I have to use xdotool to fake the input events required to
select the appropriate menu items, in order to implement my 'two
displays' action described above.
What would work a lot better, is something like the following:
display = pdb.gimp_display_new (image)
pdb.gimp_action_run ('view-zoom-2-1', display, 0)
pdb.gimp_action_run ('view-shrink-wrap', display, 0)
What do you people think of this? Is it worth pursuing, or would PDB
functions for every action be easier achieved? I'm certainly prepared
to work on either.
(incidentally, it may be relevant to this that I have made an
extension 'GPixMint' which hosts quick actions like these so they can
run a lot faster than the typical 'run an entire executable each time
the function is called' plugin, and plenty of actions for it)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about how Gimp displays multiple layers
Hello. I cannot address the issue of widgets. Anyway GIMP does not use widgets to display individual layers, only the final composition, app/display holds the code IIRC(quite a bit of code -- someone else might be able to narrow it down further.). The image is composited and THEN displayed (in one widget). With this sort of display there really is no reason to try to be clever by doing things as confusing as you described. You just need to do the composition (GDK will help you with that) and display the relevant area of it in an expose handler for your display widget. In short, this reminds me of when I used to make more work for myself by being clever about finding ways to reduce the work I needed to do. Do things the plain way first, try to be clever later if it doesn't work well enough, OK? On Mon, Mar 31, 2008 at 10:23 PM, Gregory Hosler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm working on a gtk application, and I have a need to display a composite image. i.e. a base image, with a 2nd (much smaller) image overlaying a part of the bigger 1st image. Periodically I may need to move the smaller image to a different location within the bigger image. My first attempt was to use the GtkFixed widget, and put both images into the GtkFixed container. The problem I faced is that GtkFixed will always layer the larger image on top of the smaller image (at least this is my observation, and I cannot figure out how to control the layering order for GtkFixed). In [minimal] playing around with Gimp, I am aware that Gimp has the ability to create a composite image, out of multiple layers. I'm kinda curious as to the algorithms (pointers to within the code welcome), and whether there are widgets that are more suited to this, rather than the GtkFixed (that I could not get to work for me). I do not mind loading a pixbuf, and then replacing a designated section of it with the smaller image's pixbuf, if that is what it takes... I cannot figure out from the gtk pixbuf devhelp pages how I might achieve this though. Any thoughts/comments are most welcome. Thanks, and best rgds, - -Greg - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH8NCq404fl/0CV/QRAnelAJ42K0vVFIy/4g6u1CCQGTdu+v2buwCbBpIZ 8xUITPrCcFIJqPbMpCu98Ew= =lmCC -END PGP SIGNATURE- ___ 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] shared layer mask or layer mask reference to previous
Hi, It won't happen unless someone puts in the work. GIMP development is entirely voluntary, so if you want this, submit a patch to make the necessary changes. Otherwise, you leave it to chance whether this ever gets implemented. Posting feature requests here tends to annoy the developers. It is a good place to discuss the details of a feature you'd like to implement, though. Only saying 'we need this' will not encourage anyone to work on implementing it; volunteer coders code because it's fun or personally rewarding, not because something is wanted by someone else that they do not know. On Mon, Mar 31, 2008 at 10:17 PM, Miroslav Talasek [EMAIL PROTECTED] wrote: I and my many friends need this feature. We want that layer mask can be as reference to previous layer as photoshop. I have several layers but i wont olny one mask for some of layer. Simply shared layer mask as photoshop thanks -- MSc. Miroslav Talasek Developer, Team leader Seznam.cz, a.s. Prague Czech Republic tel.:+420 234 694 722 fax: +420 234 694 115 gsm: +420 608 934 724 jabber: [EMAIL PROTECTED] work-email: [EMAIL PROTECTED] email: [EMAIL PROTECTED] ___ 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] 'no image' window: progress...
On Sun, Mar 30, 2008 at 11:14 PM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, the Open dialog is a poor replacement for a file manager. If you only use it as a drag source, then why not just use your file manager instead? ... My file manager is Midnight Commander :) I've just tried Rox-Filer, and it looks good, I'll try it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 'no image' window: progress...
Hi all, On Sun, Mar 30, 2008 at 5:33 AM, Kevin Cozens [EMAIL PROTECTED] wrote: jbaker wrote: o What would really be nice and make the dropzone a lot more usable... if there is was a file browser built into it... split the niw vertically, put a file browser on one side, and dropzone and whatever else on the other side... I don't understand why you would want to do that? If you need a file browser, use the File-Open menu item .. The 'Open' window can remain up as you DnD items from it to the toolbox. Rather important to know for this jbaker's use case, and I didn't find it obvious (the 'Open' button is obvious, and in fact deterred me from investigating DnD because it lead me to assume that that was the dialog's main functionality and it had no DnD. Does GIMP suggest to DnD in a tooltip? If it can, I think it should.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ‘no image’ window: progre ss...
On Fri, Mar 28, 2008 at 5:27 PM, Michael Grosberg [EMAIL PROTECTED] wrote: To give my $0.02, I think Gimp should simply emulate what is out there, namely the behavior of established applications such as Open Office and gedit. I am really struggling to say something nice here... ah: The perfect family car was invented ages ago: the volkwagen beetle. That did not stop designer from creating totally different cars for different needs. And customers from actually buying better cars. No reason to design a joystick-steered three wheeled car just to be different! Predictability of the UI is a very powerful tool and should not be dismissed. Applications don't work in a vacuum: they are used along with other applications, and asking users to switch mental gears when they switch from one app to another for no reason is not a good thing. The developers of those apps have struggled long with exactly the same problems Gimp is trying to solve and have come up with good solutions. Case in point: in your specification you state that the application will quit if: Close in the File menu is invoked and the no image' window is shown While usually in such cases the close command is grayed out and only the quit command is available. What good reason do you have to change that? I agree this is difficult. I believe the intent here is to make gimp more symmetrical, so you can close images, and then you close the final image (the no-image-window) The idea of a window with no document in it is already established. You yourself said no gimmicks and yet in the design there's a cute looking wilber in the window's background, which is nice but really, you think without it users won't know what this window is? give users some credit! it's a gimmick and by your own rules should be removed. I must disagree. It is not a gimmick, because without it, it is difficult to rapidly identify where to drop. If your window has a title bar (keep in mind that not all window manager's show a titlebar attached to the window -- eg the WM I use shows the title of the window that is currently focused only, at the top of the screen.), the icon that identifies it as a gimp window is small, and may be obscured by other windows. Since this window is a DnD target and the user may want to do multiple drops quickly, it must be identifiable to the user in the greatest number of situations. Standard icon+text titlebars do not provide this. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP to adopt this scripts
Wow, didn't notice I was repeating Alexia. Sorry, Alexia :) Although that makes me think -- something like python's easy_install would be terribly handy for resources.. If you're not familiar with it, basic usage is : 'easy_install foo' installs the latest version of foo. This would require a centralized repository (the resources needn't be stored there, metadata would need to be.) Would be a nice backend for a DnD app. Also,.. On Wed, Mar 19, 2008 at 7:43 AM, David G. [EMAIL PROTECTED] wrote: Sorry but I don't agree with that. I think GIMP should be more of a 'out of a box' term than just worrying about sizes and things that could be taken ?? worrying about sizes ?? Oh, you mean distribution size. This is undoubtedly an issue, it is less of a concern than simple cumbersomeness: the amount of files in the GIMP distribution is too much already.. for a sample, look at the plug-ins/common directory in a GIMP source tree. Approximately, each C file produces a plugin, there are a lot of plugins there.. (120+ IIRC); similarly I think we have too many gradients by default, too many palettes, and too many patterns. This is partly because there isn't a 'filtered/tagged' view, so that we only need to consider relevant resources. Also, GIMP developers are required to manage this multiplicity of resources, which becomes harder the more resources there are in the distribution. (there is infrastructure for tagging, and no UI or I/O for tagging, IIRC. I think it might take quite a bit of work to get the tagging UI right.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] installing patterns
Hi Andrei, Do you use GIMP 1.2 at all? If not, delete that second directory! it is irrelevant and is obviously the cause of your confusion. IIRC nothing changed about pattern fileformat between 1.x and 2.x, so you should be able to copy them across, yes :) Cheers, David On Tue, Mar 18, 2008 at 1:10 PM, Andrei Simion [EMAIL PROTECTED] wrote: Hi, I'd like to install some patterns in the Gimp version 2.0, the server version. The manual says that the patterns should go in system patterns dir. This is one of the two locations. Is this the location: /usr/share/gimp/2.0/ If yes, then I can copy some old patterns from ver 1.2 and use them, right. In ver 1.2 they should be installed here: /usr/share/gimp/1.2/ Thanks, Andrei ___ 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] Rotation for brushes
Hi, On Mon, Mar 17, 2008 at 9:07 AM, Bill Skaggs [EMAIL PROTECTED] wrote: David G. [EMAIL PROTECTED] wrote: Add a option to rotate brushes to compliment the scaling. I don't know if this has been requested but it would be very helpful than creating a layer + using the rotation tool. Wouldn't be all that hard to do. How often do you think this would be used? What kind of brushes would you want to use it for? Myself, I would use it for nearly every non-symmetrical brush (and wish for the ability to v- or h-flip it, too), particularly when I'd just copied something and was using the clipboard brush. Every brush that is remotely 'directional' needs this (or, possibly the option to rotate the brush to match the movement direction -- that would work fairly well much of the time.) Making aspect ratio controls independent of brush type also makes sense to me. hardness' also makes sense independent of brush type (hardness specifying the middle point of a curve, 0 would be a linear curve, .5 would be a gamma-ish curve where a majority of midpoint values become much more opaque, -.5 would be a gamma-ish curve where a majority os midpoint values become much less opaque. I may be getting a little OT, I believe that those controls do not belong in the VBR brush editor. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation for brushes
On Mon, Mar 17, 2008 at 10:45 AM, Bill Skaggs [EMAIL PROTECTED] wrote: David Gowers wrote: Myself, I would use it for nearly every non-symmetrical brush (and wish for the ability to v- or h-flip it, too), particularly when I'd just copied something and was using the clipboard brush. Every brush that is remotely 'directional' needs this (or, possibly the option to rotate the brush to match the movement direction -- that would work fairly well much of the time.) If the major usage case is to rotate to match the direction of movement, it would make more sense to support that directly, since it would be a p.i.t.a. for users to have to go into the options to set a direction for each stroke. I was envisaging it being settable via the keyboard. You can currently set VBR angle by keyboard shortcuts. In any case, you seem to have missed that the directional rotation requires a 'normative' rotation value -- since many brushes, while asymmetrical, have no obvious 'direction', we might want to allow a default rotation to be set per brush.. It *would* be necessary to allow normative rotation to be modified, in order for directional rotation to consistently remain sensible to the user. This shouldn't be too hard in principle: it is already supported as a mode for image pipe brushes. In practice it hasn't worked all that well, because it's not so easy to cleanly estimate the direction of motion -- especially at turning points or the start of a stroke -- so it has been hard to avoid getting anomalies every so often. The new motion-smoothing code that Alexia I think that we need some trickery to happen -- for example, the right thing for the start of a stroke is probably to match the angle for the first event to the angle of the following event, so we would need to draw the first dab, and then redraw it if the user continues the stroke. recently contributed might actually make this work better -- this should be investigated. Because it's inertia-based, it does.. as long as there is *some* smoothing happening, angle is much more coherent. (note: I'm currently using 2.4.2, rather than SVN trunk, sadly. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation for brushes
On Mon, Mar 17, 2008 at 10:59 AM, Bill Skaggs [EMAIL PROTECTED] wrote: David G. [EMAIL PROTECTED] wrote: I proposed this because it will actually boost the simplicity of managing brushes to adapt in effects and splashes, instead of doing the layer and rotation technique. ... I gather from this that you would like to be able to pick an arbitrary rotation, and that simply rotating in the direction of motion wouldn't fit your needs. There are indeed many brushes which would work best with a specific angle control -- they are mainly 'edge-effect' brushes. Anyway, I've already stated my belief that if you have directional rotation, a normative rotation angle control is necessary. Maybe in the eyes of a developer this might be considered 'bloat'. It isn't a question of bloat, it's a question of keeping the user interface as simple as possible while providing the capabilities that are wanted. Adding an option that doesn't get used is not harmless: it makes it harder to find the things that are important. As an artist, you wouldn't want to have the I believe that we can reduce the number of screen-real-estate-occupying options anyway, and use an interface like the ink tool nib adjuster to simultaneously set brush normative rotation and aspect ratio. Also possibly scale -- being able to use the scroll wheel on the nib adjuster to change brush scale makes sense to me, skew -- ctrl+drag to skew, flip -- shift-click near a border to flip on that axis, and aspect -- shift-drag. (to be congruent with the rest of the GIMP, it would probably be better to put skew on shift and aspect+flip on control, since shift typically adds and control typically constrains.) As far as the backend goes, I would expect values for skew, rotate, aspect, flip, scale to be independently stored and modifyable by keyboard shortcut*, and mostly combined** into one transform matrix after a value changes. *by which I mean that they can be shortcutted, not that they are by default. ** looking at the brush code, differently scaled versions of the brush are cached. If directional rotation was implemented, we'd want to cache rotations as well, I expect. So the transform might work better in two steps. An example of this kind of interface in a raster paint program is in Pixia (Windows). controls you need buried amongst 20 useless buttons and sliders, would you? That's why everything like this needs discussion and careful consideration. -- Bill ___ 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] no-image-open redux [start time]
Hi, I'd like to point out that startup speed is also dependent on what resources you have installed. With lots of brushes or patterns, startup time can be significantly inflated ( I have a set of 900 brushes that inflate startup times from 6sec - 35sec). So you should make sure that you test with only default resources, or else specify what extra resources you have installed. On Sat, Mar 15, 2008 at 1:17 PM, Liam R E Quin [EMAIL PROTECTED] wrote: On Mon, 2008-03-10 at 18:43 +0300, Alexandre Prokoudine wrote: On Sat, Mar 8, 2008 at 4:14 PM, Sven Neumann wrote: Starting GIMP takes about three to five seconds. It takes ~7 sec on my 4 years old laptop 25 seconds on my Dell Latitude d600, the first time, and closer to 7 seconds if I quit and start again immediately. About 10 seconds on my desktop. Both run Linux. For my part I really *like* the tips. Although I would like them more if they linked to tutorials and documentation either on the GIMP Website or locally (read more...). Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ 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] Brushes/input controllers changes idea
On Wed, Mar 12, 2008 at 9:21 AM, Alexia Death [EMAIL PROTECTED] wrote: On Tuesday 11 March 2008 21:46:41 Joern P. Meier wrote: I have been looking at the GIMP code recently to look for possibilities of implementing some features that could make GIMP more useful for artists that create paintings from scratch (which includes me ;)). Yay! Another art buff interested in brushes. A more powerful and flexible brush engine would be near the top of the list. So true. This would likely also cover the SVG brushes (very appealing idea) and adjustable input curves proposals. And dynamics,,, That's important too IMHO. Ability to bind any brush property to one or more motion dynamics, primary or derived (speed, tilt,pressure, angular speed, etc...) . Angular speed? Do you mean 'turning speed', otherwise known as torque? Maybe someone with more insight into the code could give an outline of how it currently works? I am willing to invest some time studying the code myself, but unfortunately it is very scarcely documented and so I am not sure how the various components interact. Gimp is large code wise. I opted for trying to understand the bits I'm working on and not the whole thing at once ;) I have been hacking in the event side of things since early this year and I'm slowly starting to get a clue how things relate to each other. Perhaps best for you to learn is to trace events stating from display shell callbacks to the drawing code in various tools to get the overview you need? As I understand it now paint core handles most of painting related stuff, different brush types are dervates of GimpBrush that overload the functions in witch thy differ. Making a new brush type should not be that difficult, but integrating it to UI... That part is a mystery to me. The UI is a mystery because no one has worked it out yet. The current design, with two places to control brush behaviour (brushes dialog, and brush editor) is clearly unsatisfactory. The design seen in mypaint is capable, and it uses up far too much space. Personally, I envision a GUI like [target selector] list | this of | source's sources | parameters [add] [remove] (keeping in mind that it would be very helpful for the dialog to be small enough to be a dockable. for example, the first item in Brian's first mockup would show like this [Opacity] Pressure % | CURVE | HERE The second would show up like [Size] Pressure -+ | CURVE | HERE [1] and the last would show up like [Angle] Direction =| CURVE | HERE [1] Doubleclicking on an item in the list of sources ought to allow it to be changed to another kind (different source, or different kind of modification). There should be a quick way to set a single constant value for the curve. shift+click? There should also be a quick way to enable or disable a particular adjustment Such a dockable should include targets such as size opacity hardness color from FG/BG (need way to specify opacity for color mix) color from gradient (see above) dissolve (yes, this sets a percentage of the pixels to transparent, just like dissolve does. I used this once in Pixia and found it a very useful fundamental adjustment) jitter (replacing the jitter options from paint tool options) rate/exposure (note: ignored for tools that have neither) airbrush pressure (note: airbrush normally inverts the size adjustment. how to account for this?) torque (as suggested by you, Alexia. Well, torque is the technically correct term, however none of the candidates, including 'torque', are very meaningful to a casual inspection.. the final name might be something different again.) and sources such as time (need some way to set length) -- this would allow you to do 'fade' in a more flexible way. speed tilt (note: this is a hardware-provided value, from eg. Wacom Intuos tablets) angle pressure This still leaves the matter of VBR editing and later, SVG brush editing. I think we could put them in an expander underneath the main part, in recognition of the fact that they are going to be accessed less often. We also need to ensure that only the things that really are specific to individual brush types go there. eg aspect ratio, rotation, hardness are things that make sense in context of any brush, not only VBRs or SVG. Oh yes, the UI separation of brush types.. IIRC it's more or less a hack (VBRs are the only editable type, and editing a brush brings up a VBR editor) When I get my system fully working again, I plan to prototype various UI possibilities in this area using PyGTK, and post the source+screenshots. A UI spec would be helpful, and probably not very possible until there is some UI to try. Also it would be nice to know if there are already more concrete plans for this (GEGL stuff?), or even if someone is already working on it. Somebody is working on some gegl
Re: [Gimp-developer] gimp_patterns_get_list
On Tue, Mar 11, 2008 at 2:04 PM, Andrei Simion [EMAIL PROTECTED] wrote: Hi, I have the following problem: when calling gimp_patterns_get_list on the Gimp server, version 2.2 I got an error: not enough arguments for function 'gimp_patterns_get_list' The function works on the Gimp server, version 1.2. I checked here: http://hans.breuer.org/gimp/pdb/alphabetic.html and it appears I can call it with no parameters. Can somebody point to the list of functions that can be used on Gimp 2.2? Yes. Use the pdb browser plugin found under /Xtns in the toolbox. Thanks, Andrei ___ 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] transparent transformation preview
Hi Patrice, On Sat, Mar 1, 2008 at 12:39 PM, Patrice Poly [EMAIL PROTECTED] wrote: Hello I have searched a lot about this, and couldn't find anything apart a few lines in an old summer of code page, and in this old webpage : http://www.re.org/tom/computer/gimp/index.html#preview unfortunately this patch only applies to 2.3 this is why I allow myself to post here as a feature wish, even though I am absolutely not a coder. I am using GIMP every single day for my 3D texturing work, and i have to blend together parts of photographies in an interactive way. Parts need to be lined accurately so that you don't create blur in the blending areas. ( someone told me Hugin does it perfectly, but at a first glance, it seems to involve complex settings and a lot of click work before it computes a solution, when you just need to move things on the fly and see how it goes . Hugin seems to be more suitable for assembling large images together than a lot of little parts ) As GIMP is now, you need to move/scale/rotate/shear/perspective a selection or a layer, apply transformation, check if it lines good, undo, transform again, check, etc, because the preview always turn to totally opaque , whatever the layer opacity is. Having a little slider to set the preview mode/transparency would be a real enhancement for this kind of workflow. Another clean solution would be that the preview simply follows the active layer mode/opacity . In order to have a genuinely clean solution, I believe that GEGL needs to be integrated for layer compositing. Because the main issue here is that, when you overlay an preview of N opacity over a layer of N opacity, the appearance is that of N opacity -- ie. such a preview is still not accurate. It's the same effect that occurs when you draw a dab of paint at 50% opacity and then draw another over the top -- the result is more than 50% opaque. What needs to happen is, the preview is composited onto the layer with 100% opacity, before that layer is composited onto the one below. This is rather tricky and without a graph-based image display, it is difficult to do in a non-kludgey way. I have read about Iwarp as a tool, that combined with a transparent transform preview would turn GIMP into a fantastic texturing tool. I have no clue how difficult it can be to code this, but I hope the developers of GIMP can find an interest in this. With all my thanks for all the work done, regards patrice poly ___ 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
[Gimp-developer] Fwd: improved drawing modes
Forwarding further explanation from Radoslav. -- Forwarded message -- From: Radoslav Schudich [EMAIL PROTECTED] Date: Mon, Feb 25, 2008 at 6:47 PM Subject: Re: [Gimp-developer] improved drawing modes To: David Gowers [EMAIL PROTECTED] the paint mode is displayed in the toolbox dialog. When user switches the paint mode, he mostly does not be informed of this event. Yes, the shortcuts were the same for some modes using f.e. F2-behind, pressing F2 again switched to replace and so on. The mode negative switched the colors using the current brush, it is simple and gives the invert function a more flexible usage. pitty, U cannot try the TV Paint on Tux. Et least, could there be an effort to make at least one more drawing mode - the erasing mode? thnx ssuuddoo Greetings from Slovakia :D thank you again for help and the effort ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: improved drawing modes
forwarding mistakenly privately sent message. -- Forwarded message -- From: David Gowers [EMAIL PROTECTED] Date: Sat, Feb 23, 2008 at 9:44 PM Subject: Re: [Gimp-developer] improved drawing modes To: Radoslav Schudich [EMAIL PROTECTED] I cannot try TVPaint; It is not for Linux. I know it can be run under WINE, that is something too involved for me to do currently. I think what you mean by 'NEGATIVE', though, is the idea of pairing paint modes together, and then being able to switch between them by pressing the same key. Like, if you wanted to select 'Replace' and the current paint mode was 'Behind' you would press F2 once. If the current paint mode was neither 'Replace' nor 'Behind', then pressing F2 would select behind. I am uncertain about the value of that idea*. However I think the other possibility, that you just have another item on the menu, named 'Opposite' or 'Negative', that is always adjacent to the current mode, so you can quickly select the opposite paint mode, is a good (and more predictable) idea. * that idea would be fine, if the statusbar would notify users when things such as drawing mode were changed. With GIMP as it currently is, the scheme described would give no feedback to the user about the change of paint mode. On Sat, Feb 23, 2008 at 9:25 PM, Radoslav Schudich [EMAIL PROTECTED] wrote: agree. I think, there is some mode that erases but just one color, so on more cases I cannot use it properly. The negative think is more a decorative part. for example the comparation of the drawing modes: TV Paint: (the * have those, I have used mostly) F1 color * F1 stamp * F2 replace * F2 behind * F3 erase * F3 pantograph * F4 merge F4 impress F5 shade * F5 light * F6 colorize * F6 tint * F7 grain F8 smooth F8 blur * F9 smear F9shift (there are plenty more in the new version, but now I do not remember them) GIMP ( I have GIMP in slovak, so I just translate them to EN) Normal Dissolve Behind Erase color --- Multiply Devide Picture Overlap ___ Lighten Darken Sharp light Soft light Grain Extraction Grain Merge Difference Sum ...?? Only darken Only lighten Tint Brightness from this information we can clearly see, that gimp uses a lot of drawing modes, but in my activities I mostly do not use them. Partly its my fault because I do not know them all, but the drawing modes in the other program were easier to use for me. If not others. I recommend trying the TV Paint program for better view on this issue. it is free for try. :D ssuuddoo On Fri, 22 Feb 2008 12:54:06 +0100, David Gowers [EMAIL PROTECTED] wrote: Hi, I admit that if Erase were a paint mode, I would use it much more. The eraser tool, I generally find does not happen to have brush settings convenient to my current task, and so i find it cumbersome. So, I think that erase as a paint mode is a good idea. I do not understand this 'Negative' paint mode, Radoslav, and I think you need to explain it. Now that we are speaking of paint modes, I know that I would personally find very useful one that recolors FG colored pixels to BG color. On Fri, Feb 22, 2008 at 9:35 PM, Radoslav Schudich [EMAIL PROTECTED] wrote: Hi, I know, it sounds like a waste, but trust me, it isnt. I firstly didnt even know what are those drawing modes for, but soon it fastened my work. I suppose they should have a shortcut key too. For example: You draw or edit an image with a simple brush, when you want to erase some stuff, you switch to the eraser, but this one has different brush size, shape, opacity than the first tool. Using different modes like erase and plenty more are efficent. (I admit, some of them I never used - solarise, and other modes, I do not use to use). Maybe I am explaining it wrong, but You can try it for your own. The program I used to work with is named TV Paint Animation, for someone it can be an unknown program, but believe me, it is very strong and when comparing prices you can see: PaintShopPro 105 € Photoshop 264-441 € TV Paint Anim. Pro/Std. 950 € / 475 € GIMPfree OpenSource :) that TVPA is not just a shit-program, but has features that really make work with images draw/edit more efficient. let me know what do U think ssuuddoo On Fri, 22 Feb 2008 10:49:48 +0100, Raphaël Quinet [EMAIL PROTECTED] wrote: On Fri, 22 Feb 2008 10:17:26 +0100, Radoslav Schudich [EMAIL PROTECTED] wrote: the available drawing modes should have these options too
Re: [Gimp-developer] improved drawing modes
Hi, I admit that if Erase were a paint mode, I would use it much more. The eraser tool, I generally find does not happen to have brush settings convenient to my current task, and so i find it cumbersome. So, I think that erase as a paint mode is a good idea. I do not understand this 'Negative' paint mode, Radoslav, and I think you need to explain it. Now that we are speaking of paint modes, I know that I would personally find very useful one that recolors FG colored pixels to BG color. On Fri, Feb 22, 2008 at 9:35 PM, Radoslav Schudich [EMAIL PROTECTED] wrote: Hi, I know, it sounds like a waste, but trust me, it isnt. I firstly didnt even know what are those drawing modes for, but soon it fastened my work. I suppose they should have a shortcut key too. For example: You draw or edit an image with a simple brush, when you want to erase some stuff, you switch to the eraser, but this one has different brush size, shape, opacity than the first tool. Using different modes like erase and plenty more are efficent. (I admit, some of them I never used - solarise, and other modes, I do not use to use). Maybe I am explaining it wrong, but You can try it for your own. The program I used to work with is named TV Paint Animation, for someone it can be an unknown program, but believe me, it is very strong and when comparing prices you can see: PaintShopPro 105 € Photoshop 264-441 € TV Paint Anim. Pro/Std. 950 € / 475 € GIMPfree OpenSource :) that TVPA is not just a shit-program, but has features that really make work with images draw/edit more efficient. let me know what do U think ssuuddoo On Fri, 22 Feb 2008 10:49:48 +0100, Raphaël Quinet [EMAIL PROTECTED] wrote: On Fri, 22 Feb 2008 10:17:26 +0100, Radoslav Schudich [EMAIL PROTECTED] wrote: the available drawing modes should have these options too (there are plenty (21) drawing modes, but I definitly miss these: ERASE (to be able to erase the drawing (not just one color) with any drawing NEGATIVE -it makes the drawing/editing easier, because when you want to erase something, you do not need to change your tool 2 eraser, but can choose to erase the painting with the brush you currently have. Could you explain why it would be easier to do this with additional drawing modes instead of using the existing shortcuts to switch to the eraser and then switch back to your previous drawing tool? If you use the existing shortcuts for the tools or if you define new ones, then you only need to press the key for the eraser, erase what you want, and then press the key for the other paint tool to continue drawing. You can do that without having to move the mouse to the tool options and change the paint mode, which is more cumbersome in my opinion. Also, for those who use a drawing tablet, it is much easier to switch tools than to play with drawing modes. -Raphaël ___ 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] no image open spec...
On Thu, Feb 21, 2008 at 10:12 PM, Michael Natterer [EMAIL PROTECTED] wrote: On Wed, 2008-02-20 at 11:34 +1030, David Gowers wrote: There is no guarantee that there will be any taskbar at all. On linux, there are plenty of WM's that either provide a taskbar that is not suitable to implement your described behaviour, or no taskbar at all ( i use one of these myself, DWM (http://www.suckless.org/wiki/dwm)). IMO taskbars are a kludge, and it is a mistake for an application to *depend* on them for basic usability. To quote from that Window Manager's web page: Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. I think you just disqualified yourself to say anything about usability here. That's a straw man. There are many tiling WM's, and only two of them are written by Anselm Garbe. It's quite common for tiling WMs (eg. dwm, Ion, wmii, ratpoison, stumpwm) to not have taskbars, because they are simply unnecessary when you can see the current windows at a glance. Mainstream WM's are a window management nightmare -- by which I mean the user is constantly being called on to manage windows, to make decisions that could in most instances be made well by the computer, and the need for a task bar in such WM's just reflects this basic demand for micromanagement imposed by an overconfigurable concept of window management. It's not bad that the user can configure their WM, or even their windows -- they should only rarely be called on to configure their windows, since it's perfectly possible to treat the majority of windows in a way that Just Works. In short -- taskbars save you some of the time that your WM otherwise calls upon you to waste. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Feb 20, 2008 5:24 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Tue, 2008-02-19 at 12:35 +0100, Daniel Hornung wrote: Well, perhaps not deprecated in the don't use this API sense. Their use is discouraged. And not by the GTK+ developers but by usability experts. Tearoff menus might sometimes be useful for the power-user but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use. I have to object here, since I have never seen any user unintentionally use tearoff menus. That is not the point. The point is that almost all of the time you don't need the tear-off functionality. But it's there, and it is slowing you down because you have to move the mouse a little further and your eye has to skip the extra visual clutter that it adds. On the other hand I find them very useful, especially with window manager features like window shading and unshade on mouse-over, I use them in my everyday work, not only in GIMP but also in e.g. xmgrace. Benefits I see are easy access to hidden parts of menus that are not used often enough (on the long term average) to deserve a key shortcut (I might need that special sub menu quite a few times only on this very special image) or for trying out several entries, as was discussed enough earlier in this thread. Exactly. This is why GIMP still has them enabled by default. Note that I didn't suggest to turn them off. With our deep menu hierarchy, tear-off menus are definitely very useful. Long term it would be nice if we could get rid of our insane menu hierarchies and at that point we should also consider to disable tear-off menus. I think something that would help here is if we could bind keys to menus. For example, the GIMP-GAP 'video' menu -- it would be more practical to access this way. And in general, it would be pretty effective for common tasks, if we could also do things like defining a custom menu that includes sel gauss blur selection to path path to selection fill selection with FG and then bind it to '2', so commonly done tasks were quicker to do and required less thought. In my experience, it would be useful to be able to define menus per: gimp -- ie tasks that are done a lot independent of what the current image is image -- common tasks for this specific ...image drawable -- ... drawable path -- ... path I'll have a go at making a mockup. My basic idea for this simple sort of menu editing is DnD based: open the 'gimp' custom menu, creating it if it doesn't exist, then leave it open in a window like a tearoff, and DnD menu items into it to add them, out of it to remove them, and move them in the normal DnD way. As a whole, I believe this would allow us to leave a lot more out of the default menus, and have the removed items instead in something like an actions treeview dockable (using a treeview would hopefully allow easy DnD of submenus) Sven ___ 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] no image open spec...
On Feb 20, 2008 11:07 AM, [EMAIL PROTECTED] wrote: peter sikking [EMAIL PROTECTED] said on Feb 19, 2008 13:46 -0500 (in part): You missed one of the mails in this thread then. If we use this window as a DND target, where should our users drop images when it is not there? I think the remaining question is: when GIMP is not the foreground application (toolbox and inspectors hidden, as they should) where can users d+d files apart from on the taskbar icon? I have Windows only experience (not Linux or Mac) so maybe I'm missing something here ... In Windows D'n'D, for a non-visible application works everywhere as drag to taskbar button which brings that application to foreground. User (still w/o releasing mouse button) then drags to to window which has just been brought to foreground and releases. This works now with current Gimp whether there is an image open or not so long as the first bring to foreground is done to the Gimp toolbox window. So wrt. remaining question: where can users d+d files apart from on the taskbar icon? . Why is there any need for anything else? That's how Windows user expect ALL applications to behave. Regards ... Alec -- buralex-gmail There is no guarantee that there will be any taskbar at all. On linux, there are plenty of WM's that either provide a taskbar that is not suitable to implement your described behaviour, or no taskbar at all ( i use one of these myself, DWM (http://www.suckless.org/wiki/dwm)). IMO taskbars are a kludge, and it is a mistake for an application to *depend* on them for basic usability. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Feb 17, 2008 5:46 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sat, 2008-02-16 at 10:47 -0800, Bill Skaggs wrote: Well, it would be very easy to make the layer mode menu support a tearoff. It can literally be done by adding two lines of C code. (I just tested.) There are very good reasons why tear-off menus are deprecated. They don't solve usability issues but introduce them. Please let us not even consider such ugly workarounds. I agree that tear-off menus are ugly -- I think the sensible thing to do is tear-off toolbars. For this, of course it helps if every menu item has an icon assigned. I think that if tear-off behaviour was changed like this then it would encourage icon coverage, and particularly, encourage users to contribute icons. If we can then rearrange this toolbar and hide items from it*, that would be ideal for the modes menu. Is there a toolbar equivalent of separators? * for example, I never use Hard Light, Soft Light, or Overlay; and scarcely use Screen. I use Normal, Grain Merge, Grain Extract, Darken Only, Lighten Only most, so I'd like them first on the toolbar. Similarly for the Select menu, I prefer my own potrace-based 'to path' command and find GIMP's sel2path plugin rather annoyingly inaccurate, and I also prefer my 'exact grow','exact shrink' commands to the GIMP grow/shrink commands. hmm. Maybe a popup toolbar would be best for common usage. So you could easily scroll it back and forth while it's just occupying only 1 button space, and get a visual menu with tooltips by activating it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Hi Tobias, I like the simple, functional design of this. Do you know, has what the toolbox would become, already been resolved? I notice this does not seem to concern people presently. On Feb 8, 2008 9:01 AM, Tobias Jakobs [EMAIL PROTECTED] wrote: Am Dienstag, den 05.02.2008, 11:26 +0100 schrieb peter sikking: GIMPsters, Let me state that I wrote my first email in this thread because (yes) I am struggling what to put there. It is easy for me to make the list of gimmicks that not should go in there. Every on of those sucks so much... But what is left? The window needs to be there, already outlined above the functions it does. So instead of just plain bgcolor, let's do something a bit more stylish, without drawing any attention to it. I thought about it and I created this mock-up: http://hagemaenner.de/stuff/gimp/PlanB/6.png The idea is to use a simple radial gradient from the upper left corner to the lower right. (This should be switched for RTL languages.) The gradient colours are calculated from the selected forecolour from the GTK theme. This way it fits nicely into every desktop environment. In the center of the area I've added a simpel text Drop Images here to open them. (Perhaps a native speaker should change the wording.) This is NOT the Tip of the Day and should NOT change. The colour of the text is the brightest colour from the gradient. This will give us a nice contrast and it will fit to the theme colours. the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction. Would you please care to explain this? I am going to let the slider rest until the window content is sorted out. Then redesign the whole package so it all fits together... I don't get you slider idea. But if you think about a small timewaster what do you think about adding a colour slider to my mock-up? Regards, Tobias ___ 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] no image open spec...
Alexandre, What Peter describes does not involve transparent windows. I agree it does not seem useful, in sense of literal opacity.. Rather, a waterlevel-type adjustment could suit this idea better..with widgets appearing or disappearing according to whether they are above waterlevel. It's important in this case that disappearance or appearance should not change widget positions or sizes-- the widgets should not be repacked after the initial packing.. (well, we could consider, if needed, more specific instances of a general kind of action that could, at one level, have a widget for the general operation, and then as the waterlevel drops, be replaced in the same space by several widgets that are the more specific instances.) On Feb 5, 2008 9:17 PM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Feb 5, 2008 1:26 PM, peter sikking wrote: And we can't (yet) make GTK+ widgets translucent. Are you 100% sure? http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent- widgets/ that is cool (but not for this UI design). I would like to know how universally (all linux WMs, windoze, OS-X) that can be rolled out... Murrine's developer writes in his blog: Then you need... a composite capable window-manager, like Compiz, future Metacity etc etc… I'm not quite sure about usefulness of transparence in a graphics editor (unless it's transparence of layers/selections/objects in a drawing). Sounds like distraction to me (and yes - I remember your argument on Aperture :-)) Alexandre ___ 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
[Gimp-developer] Fwd: GIMP Levels operation fix
Hi, I sent this simple fix to mitch, however I'm too impatient to
wait for mitch to check his inbox,
So I'm now passing it onto this mailing list.
Basically it fixes over/underflow in the Levels op; with the attached
image, the bug gives the appearance of a triangle wave repeating
gradient, instead of a readjusted single gradient for the channel
being adjusted.
-- Forwarded message --
From: David Gowers [EMAIL PROTECTED]
Date: Jan 31, 2008 5:45 PM
Subject: GIMP Levels operation
To: Michael Natterer [EMAIL PROTECTED]
I've just found a bug in the Levels op -- if the selected low/hi input
endpoints of a channel are
(low - more than the lowest non-empty histogram entry; or high -less
than the highest non-empty histogram entry for the channel)
then underflow/overflow happens.
Adjusting any of the input range sliders to fall into that range will
show this behaviour up.
Using the channels dialog to disable all but one channel also helps. I
would say you have simply forgotten to clip the input values before
mapping them to output values. *pokes around* indeed, I've attached a
very short patch that performs correct clipping. With this patch, GEGL
levels op matches old levels behaviour in all tests I could contrive.
attachment: testimage.pngIndex: app/gegl/gimpoperationlevels.c
===
--- app/gegl/gimpoperationlevels.c (revision 24754)
+++ app/gegl/gimpoperationlevels.c (working copy)
@@ -87,6 +87,8 @@
else
value = (value - low_input);
+ value = CLAMP (value, 0.0, 1.0 );
+
if (gamma != 0.0)
{
if (value = 0.0)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] toward a plan for 2.8
On Jan 27, 2008 8:52 AM, William Skaggs [EMAIL PROTECTED] wrote: One of the points that emerged from the ongoing discussion is that it is time to start making a tentative roadmap for 2.8. I hope this time that Peter and his group can be brought into the discussion as early as possible, and will play a role in shaping the plan. As I wrote earlier, Peter in his LGM talk listed the things he considered the top priorities at the UI level: 10. better printing support 9. painting with brushes 8. improve the text tool 7. save for web 6. organize brushes, palettes, gradients in categories 5. avoid pop-up dialogs 4. better painting tools 3. layer trees 2. adjustment layers 1. single window interface Of these items, #1 is controversial, and #2 and #3 depend on Gegl developments. Each of the remaining things are potential targets for 2.8 -- in fact, I don't see any reason why it wouldn't be possible to do several of them. In particular, I think it should be possible, and very cool, to implement the blobs of paint idea that is part of #4. I thought that #4 was dependent on (the use of, but not the overall adoption of) Gegl. Perhaps I've misunderstood you. At the moment, we do have some useful GEGL ops that could be used to back the 'blobs of paint' idea. At a casual glance, most of the approachable ops would work best for mask adjustment: * range adjustment (gimp-levels * halo adjustment (gimp-curves) * hardening (gimp-threshold) * blurring * inversion (good for stenciling, ie. layer masks) * noise There are some that work with colors: * colorbalance * colorify * white balance Can we use the transform ops (rotate/flip/etc)? That would be very nice. Initially, I figure we will only make the brush data available to ops, so it could be done with a linear stack of Ops. After a while, you might want to combine brushes, so that might develop into a normal tree. Actually, technically it would start as a tree, looking like this: brush-output (sink) | +- add_alpha | ++--- last_mask_op | |-- some_mask_op | +-brush-mask (source) +--- last_color_op |-- some_color_op +- brush_color (source) If we wanted to combine blobs of paint, that would amount to re-separating the mask and color, and connecting the output to the newly added blob. More advanced things, such as spatially-dependent paint (think of the clone tool in aligned mode), would have to wait until GIMP was using GEGL for images, so that a brush could know what region was requested in terms of the image coords. I think 'blobs of paint' would be a good place to experiment with GEGL graphing UI, that could later be refactored to be more generally usable for GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
Hi Alexandre, On Jan 25, 2008 9:52 PM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Jan 25, 2008 11:01 AM, Sven Neumann wrote: Actually, I don't think that we need to put action recording on our list as that will become obsolete with non-destructive editing. This is apples and oranges, Sven :-) Non-destructive editing boosts productivity as well, but has nothing (or very few things) in common with *automation*. It does, though. If you make a chunk of graph -- say you want to gaussian-blur a layer, gradient-map some part of it, and posterize the result to 32 levels; you could do this with the following snippet of graph: (graph root) | posterize (levels = 32) | +- atop | | | mask | | | gradient-map (gradient = how would you specify this?) | | +-gauss-blur (hblur = 5, vblur = 5) | +-sourcelayer In case that isn't clear: Source layer is gauss blurred, A gradient-mapped version is made, which is then masked. This image is then rendered atop the gaussian-blurred image, and the result is posterized. This is what is conventionally covered by macros, this kind of thing. All the users who ever bugged you asking for macros recording did it because they don't feel like programmers to learn Script/Python/Perl-Fu. With non-destructive editing, used as above, almost all the things that users want to do are things that can be expressed in terms of a modification of the image graph. The example you see above -- the only user input required would be to choose which layer becomes sourcelayer. twould probably be pretty easy to build a 'quick change' dialog where the user can change all the involved values (eg gauss blur radius.) The things which do not fall into that category.. * batch processing (trivial amount of programming. Just keep resetting the filenames at the leaf and root of a graph). * view handling (I'd like to be able to, say, tag an image or directory as 'pixel art', and when I opened one of those images, have an additional, 300% view appear (for real size preview). Personally I think views are one of the things that may end up needing a PDB interface*, despite the vast obsoletion that should otherwise happen (gauss blur, gradient map, colorize, what ever filter you name -- won't need a PDB interface any more, they just implement their gegl Ops) I've just gone through the menus.. and the vast majority of actions available are directly equivalent to inserting, deleting, or shuffling nodes in a graph. The remainder alter either the context (Tools menu, View menu) or the GUI (Dialogs menu, View menu). (We might want to consider implementing a 'meta-load' Op, that would load a graph from file and pass image data through it. That would be a pretty simple and flexible way of facilitating macros shared between images -- just connect the output at a place of the user's choosing.) What significant sequence of actions that you can take is there, that cannot be done by simple graph editing? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
On Jan 26, 2008 12:09 AM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Jan 25, 2008 4:20 PM, David Gowers wrote: What significant sequence of actions that you can take is there, that cannot be done by simple graph editing? Users do not think in terms of graphs, they think in terms of actions and sequences of actions. They want to click Record, mess around with filters etc., then just click Stop and be able to replay it to any number of other images, send this sequence of actions to a collegue or use his sequence of actions. This is about productivity. What I was talking about -- recording is automatic, it's always happening. Every change to the image can be recorded, because most changes (say, gaussian blurring) can be recorded with a trivial amount of memory (what type of node is it, where is it connected, what properties does it have and what are their values). This is easily seen when you look at GEGL's current XML format. In short -- what you call 'action recording', I call 'packaging up a chunk of the undo stack'. Really, your 'start' and 'stop' actions would be trivial to implement: mark the start location in undo stack; mark the end; and prompt the user for a filename. Applying them is similarly trivial (choose an action, load it, append to the undo stack) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tagged resources such as brushes, gradients, etc
On Jan 18, 2008 9:33 PM, Tobias Jakobs [EMAIL PROTECTED] wrote: On Jan 18, 2008 8:55 AM, Sven Neumann [EMAIL PROTECTED] wrote: My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files. One think I'm missing here is a way to share brushes with tags. The user scenarios I'm thinking about is: - Download package (ZIP-File) with a lot of brushes - Install them (btw. Finding the right folder and copying them into it looks like a problem for some users. At least it's an FAQ in the German gimpforum.de.) - Now I'd like to have this brushes tagged in Gimp and start working with this brushes and I don't want to tag them myself. Regards, Tobias An archive as follows: brushrc/aqua brushrc/charcoal brushes/aqua brushes/charcoal ,if extracted in your .gimp-2.4/ directory, should do the right thing. Provided that brushrc filename references are either relative or have no path component -- another implementation detail to work out. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview Windows in Python-Fu - Do they exist?
Hi Jim, On Dec 8, 2007 10:22 AM, Jim Sabatke [EMAIL PROTECTED] wrote: I've been searching the net for a couple days to see if Python-Fu supports Preview Windows in plug-ins. Depending on the search strings I No, it doesn't. PyGimp does, though. This means that if you want a preview window, you need to construct the GUI yourself -- you cannot rely on PythonFu to construct it automatically for you. In the 'gimpui' module, look up the help -- see 'GimpPreview','GimpAspectPreview', and associates. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] thumbnail generation for nautilus via gimp
Hi Eckhard, On Dec 6, 2007 6:29 AM, Eckhard M. Jäger [EMAIL PROTECTED] wrote: Hello, i found the problem why the script doesn't showed up, it needs the file permission Exexcute. Do not know why, i have written exporters for Blender and plugins for gEdit both in Python but they didn't need the permission Exexcute. Ok, i'm new to Python Gimp plugins. In fact, all Gimp plugins are executables; when you call a plugin, GIMP runs it and communicates with it through a pipe. GIMP does not implement any special behaviour for .py files. That is why Python plugins must be executable. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving QMask mode
Hi Sven, On Dec 1, 2007 9:37 PM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sat, 2007-12-01 at 18:05 +1030, David Gowers wrote: b) Push the context before entering qmask mode, and pop it when exiting qmask mode. For Chris's benefit : it means that the context that was being used is stored, and restored after qmask. so the FG and BG that you were previously using return. It would mean a lot more than that. Also any changes to the current brush, pattern, gradient, paint-mode, ... would be undone when the context is popped. I thought that you could mask it so that only FG and BG were effected. We currently use this to allow scripts to work in their own context. I am not sure if it is a good idea to use the context push/pop mechanism in the user interface. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] improving QMask mode
I believe that QMask mode could be made quicker to use, by providing an option to: a) Reset the FG/BG colors to black and white upon entering qmask mode and b) Push the context before entering qmask mode, and pop it when exiting qmask mode. With the sum effect that you needn't destroy the colors that you were using in order to paint on the QMask (I myself always find myself resetting the colors to default before I draw on the QMask), and you start out with the two most useful 'colors' set as FG+BG. What do you think of this? If I get the go ahead I'll implement this. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving QMask mode
Hi Liam, On Dec 1, 2007 6:15 AM, Liam R E Quin [EMAIL PROTECTED] wrote: On Fri, 2007-11-30 at 22:45 +1030, David Gowers wrote: I believe that QMask mode could be made quicker to use, by providing an option to: a) Reset the FG/BG colors to black and white upon entering qmask mode and b) Push the context before entering qmask mode, and pop it when exiting qmask mode. For Chris's benefit : it means that the context that was being used is stored, and restored after qmask. so the FG and BG that you were previously using return. Interesting idea. I admit I hardly ever use quickmask because most of the images I work with are grayscale, and if you paint with a soft brush in the gray quickmask you can't tell where you selection starts. That depends on what mask color you set. Set black or white instead of the default red, does that help? So I have to switch to RGB mode first right now. This makes me wonder if there should be separate sets of colours stored for different painting modes, rather than a push/pop model. For QMask (which is an editing mode), certainly. For 'paint modes' (eg multiply, screen, dissolve), it would be fast; I suspect it would also be confusing for novices. I would definitely like it as an option, because I almost never want the same colors for drawing in Multiply mode or Grain Merge mode as I do for drawing in Normal mode. Let's review the paint modes: 1. Normal, Dissolve, Behind, Color erase. 2. Overlay, Soft light, Hard Light, Grain Merge, Grain Extract 3. Multiply, Divide, Screen 4. Difference, Addition, Subtract, Dodge, Burn 5. Darken, Lighten, Hue, Saturation, Color, Value Each number represents a group of paint modes, in which a given color has more or less the same meaning. 1. Direct color change. 2. Linear color change 3. Cumulative color change 4. Linear one-way color change 5. Direct partial color change (effects only some components) Surely some people disagree with me here. I expect that, as GEGL approaches, this sort of control will become more important. Now, I'm talking about sharing color settings between each group of paint modes; Later, it will become sharing (X) settings between different Ops (since gegl will greatly diversify the available ways to paint, a static mode list becomes infeasible). Therefore I believe that a facility that allows the user to group modes which will share contexts is the way to go for future compatible handling of this issue. If I change the colour in quickmask mode, e.g. to 50% gray, next time I use quickmask it could go back to that. This is a good idea! Does anyone know how to do it non-hackishly? Is new support code needed? Liam -- Liam Quin - http://www.holoweb.net/~liam/ XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] some gimply thoughts
On Nov 23, 2007 6:03 AM, GSR - FR [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] (2007-11-22 at 1544.46 +1030): Hi Liam, On Nov 22, 2007 9:45 AM, Liam R E Quin [EMAIL PROTECTED] wrote: Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in The 'Value' controls are not effected by 'Auto'. Look at the R,G,B,(A) controls instead. And then you see it changes them, in a destructive way. All 'Auto' does, is: 1. Set the input range to min(CHANNEL), max(CHANNEL) -- ie the lowest used value of that channel in the picture, and the highest used value of that channel in the picture. No, it does not. It sets min and max inside the histrogram used range (play with Lin/Log setting if this is not clear). There is a way anybody can test it: 1 Create new image, 512*512 2 Render plasma, with seed 0 and turbulence 1 3 Run Levels, click the auto button, look at all the channels OOPS! You get: R 9 1.0 229 | 0 255 G 12 1.0 194 | 0 255 B 25 1.0 241 | 0 255 Those settings are destructive, Red 0-9 becomes 0, Red 229-255 becomes 255, and so on. You can look for such pixels before applying the operation, mark with guides or points, then look what they are after. You can also look at the code and see how it iterates over the histrogram until it decides it has eaten enough. It does not stop when it reaches the first non zero, which would be non destructive (as in any input channel value gets mapped to a new, different, output value, rounding and precission issues aside). Okay, well this is not what I expected and I won't be using Levels Auto in the future - I hate clipping. I had thought that Auto was supposed to perform the same function as Colors-Auto-Stretch contrast -- to stretch the current R,G,B range ends to 0,255, clearly it doesn't. It would be nice to have an Auto button in Curves that did achieve this result. 2. Set the output range to 0, 255 for each CHANNEL in R,G,B (and possibly A) Because the output range is full, there is literally no way that this operation can reduce detail. If the input range is not full, there is loss, as shadows and highlights are lost and become flattened, grouped in the same result. GSR ___ 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] some gimply thoughts
Hi Liam, On Nov 21, 2007 5:00 PM, Liam R E Quin [EMAIL PROTECTED] wrote: I saved these notes for when there was a 2.6, but then got swamped with other things... I can flesh them out more, but I'm not likely to have time to do any programming in the forseeable future, I'm afraid. I've scattered comments throughout, hopefully this helps.. selction optimization on subtracting (e.g. control is pressed), compute the bounding box of the current selection (including the feather radius) and don't try go outside it with the new one; you see this if you're using select-by-colour or the magic wand, say, and you have to wait ages for it to calculate the selection over a 500MByte image... images are getting bigger faster than computers are getting faster right now. Might be unneeded complexity. For a selection outline preview, it would be simpler to apply the magic wand to a shrunk version of the image while it is in operation, and only apply the magic wand to the complete image when the user releases the button. Preferences Create open file previews even if layer previews are off Allow the user to reset a single pref. category, nut just everything File-open show more detailed times and dates on files in tip of the day, learn more links to documentation and to tutorials in the manual in the undo window (I hope to do some pictures of this) creative explorer? click on image state, transitions shown between Right now to undo something you have to click on the previous operation -- e.g: create a new image, paint, then erase, Undo History looks like [thumb1] Base Image [thumb2] PaintBrush [thumb3] Eraser -- this is selected so to undo the Eraser you click on the Paintbrush. Duh. The icons should show image states: [thumb1] Base Image Paintbrush [thumb2] Erasor [thumb3] -- selected Now it's obvious what clicking thumb2 means. And look! there's the possibility of making a tree: suppose I click on thumb2 and now instead of redoing Eraser I do Curves... [thumb1] Base Image Paintbrush [thumb2] | Eraser | [thumb3] Curves [thumb4] (apologies for the bad ascii tree here) The undo history could also show more detail, e.g. scale to 25%, where it makes sense, and also show when files were saved and to what name. This also leads to the idea of redo select but add to selection instead of subtract if you right-click (e.g. redo with current tool options) and maybe clear undo up to this point quickmask to work wih red mask even in grayscale images This would require channels to be drawn after the gray-RGB internal conversion but before the display filters come into effect. drawing when you use shift to make a straight line, draw two lines, showing the outline of the brush (tangents), not just one line. This might be tricky, but doable. I would find it very useful. To be reasonable, this probably would need to just draw an extruded diamond (the points of the diamond being the midpoints of each side of the brush image. when you change hardness/size, e.g. with a keystroke or by pressing harder, show the actual brush in place for a moment Cairo might help here. filter brushes - paint with a filter (Krita has this by the way) beyond 2.6, but definitely something desirable in the long term -- one of peter's posts at his UI blog outlines a 'blobs of paint' idea that includes this. text justify-both doesn't seem to work, probably because there's no obvious way to control line length. kerning access to opentype features (e.g. small caps) access to arbitrary glyphs hung punctuation etc etc :-) plugins and filters colourise show the Hue by the Hue slider, or use a colour picker merge visible layers if all layers are the same size, and the same size as the image, don't ask whether to clip them. nice simple enhancement. condense/stretch font retain textness on image scaling and layer scaling automatic white balance - allow the user to pick black and white points .. It would then not be automatic white balance, but manual or partially-automatic white balance. menus rename Image-crop image to Image-Crop to Selection same with layer-crop dodge want to be able to specify what's meant by midtones, highlight, etc. really, want a curves brush. Is this really related to dodge/burn tool? Isn't a curves brush a case of 'filter brush'? tips the doge tool is usually most effective if you make lots of short, separate strokes. convolve select radius... colours-levels auto loses detail by default; change so it doesn't, but maybe have a highlight and depth crop amount of 3% Could you
Re: [Gimp-developer] some gimply thoughts
Hi Liam, On Nov 22, 2007 9:45 AM, Liam R E Quin [EMAIL PROTECTED] wrote: Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in The 'Value' controls are not effected by 'Auto'. Look at the R,G,B,(A) controls instead. All 'Auto' does, is: 1. Set the input range to min(CHANNEL), max(CHANNEL) -- ie the lowest used value of that channel in the picture, and the highest used value of that channel in the picture. 2. Set the output range to 0, 255 for each CHANNEL in R,G,B (and possibly A) Because the output range is full, there is literally no way that this operation can reduce detail. other words there are multiple pixel values that are used in the image that end up having the same value after levels. I'll 'Value' is invalid after applying Auto, cause you either use Value or R,G,B, not both. If you change the Value controls, then adjusting RGB individually is meaningless, and vice versa. GIMP makes some effort at showing sensible values for all controls though -- the range you show is probably the average of the R,G,B ranges. attach a screenshot that shows the triangle isn't at the end of all the values, but some way in. This behaviour is good in some cases and not others. Liam -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gaussian blur in GIMP compared to Photoshop
Hi Jespar, On Nov 20, 2007 9:23 PM, Jesper de Jong [EMAIL PROTECTED] wrote: I noticed that with Gaussian blur, the Radius setting in GIMP means something different than in Photoshop CS3. As a test, I made a black square on a white background and used Gaussian blur on it with Photoshop CS3 and the current development version of GIMP with radius 6.0 pixels. Photoshop blurs the image much more heavily than GIMP; to get the same effect with GIMP, I had to set the radius to approximately 19.0 pixels. Have you checked that the radius is in pixels in BOTH cases, and not in inches or points? Is Gaussian blur not a standard algorithm that has a well-defined meaning for the radius? See for example http://en.wikipedia.org/wiki/Gaussian_blur If it is, then which one is doing it wrong, CS3 or GIMP? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Idea: selection curve
Hi Stephane, On Nov 20, 2007 10:10 AM, Stephane Chauveau [EMAIL PROTECTED] wrote: Hello, I just got an idea about the curve tool: Why not use it as a selection tool? Apart from The Gimp, I do not know a lot of image manipulation programs so the feature might very well be common. I see it like that: A new tool called the 'curve selection' would be added probably in the Select menu. Like the original curve tool, the 'curve selection' tool would provide several curves for the different properties of the current layer (see the list below). The value of each curve would not provide a transformation of the property but an amount of selection (from 0.0 to 1.0) according to the property. The result of the curve selection tool would be a selection mask obtained by multiplying the values of all curves. For most curves, the initial value value would not be the identify function 'f(x)=x' but 'f(x)=1.0'. The following curves could be provided: - Red , Green and Blue ( default f(x)=1.0 ) - Hue, Saturation, Value/Lightness/Brightness (default f(x)=1.0) - Initial Selection Mask ( default f(x)=x ) - Alpha (default f(x)=1.0) With those defaults, the overall default result would be the initial selection mask. Because of it circular nature, the Hue curve may require a specific treatment. I don't understand your explanation of how this would work. How about showing some example results? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI redesign: 1 Dimensional Menu for GIMP
I may not understand your description. It gave me an idea, though: mouse-gesture-ish submenus.. That is, supposing that you have a top-level menu with items 1 2 3 and 3 is a submenu, then, to select 3, you move down -- then a menu folds out horizontally 1 2 345 you move across, and select 5, which is also a submenu: 8 7 6 345 And move up to the item you wanted, 8. During the time a menu is active, the mouse could be constrained to only move along that axis. Then, the above menu selection could be made by the mouse gesture Down-Right-Up-Click (with appropriate distances). With the cursor keys, it could be made by pressing Up-Left-Down-Down-Enter after bringing the menu up . In this way you can make menu navigation like maze navigation, or like performing special moves in a fighting game, rather than the fairly uncomfortable and unmemorable 'tree' movement used in most applications today. On 11/5/07, Esteban Barahona [EMAIL PROTECTED] wrote: Hi all, This is the 2º draft for the 1 Dimensional Menu: http://www.zensui.org/IxD/1DM.html I will be honored if the new GIMP UI is the first implementation of a 1DM. This, I think are the changes to make it possible: 0) separate the toolbar from the menubar(s) 1) make the toolbar customizable to show only the relevant tools (configurable by each user) to simplify 2) change it to a vertical layout with only one icon per line 3) move it to the left border of the screen by default 4) increase the right padding so that the mouse can be moved vertically more easily and quickly 5) add the name of each tool in this extra space I do understand the points you are making here, though. In addition to 4) I want to suggest that this extra padding only be visible during selection, so usable space is maximized I don't know which parts of this need a new GTK widget, but also think that the concept can be tested with current widgets. If the menubar is separated from the toolbar, the toolbar's window can be manually positioned as a 1xN column in the border. The only part that has to be coded (I think) is changing the padding of each icon. On another note, is a new mailing list dedicated exclusively to interface design needed? IMO, this can make possible a filter between design and engineering posts making this much welcomed redesign progress more smoothly. ___ 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] 2.6 roadmapping, the UI part of it...
On 10/29/07, Michael Natterer [EMAIL PROTECTED] wrote: On Mon, 2007-10-29 at 11:34 +1030, David Gowers wrote: On 10/29/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On 10/29/07, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. http://curlyankles.sourceforge.net/widgets_docking.html Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.) Gimp 2.4 already does that. How? Where? I'm currently using 2.4-rc3; it does not happen here. If i hover over a tab, it just shows a tooltip, never makes that tab active. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
On 10/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Monday, October 29, 2007, 14:15:28, Michael Natterer wrote: As Saul already responded that happens only if you use DND. Why on earth would a UI control activate just because you hover some seconds over it? That strikes me as utterly useless, what's the problem with pressing the mouse button if it is not otherwise occupied (e.g. by doing DND). It allows more casual inspection of tabs (move move move, not move click move click), and works particularly well with vertically-stacked tabs or tabs whose content is in a folded away NoteBook. I regard it as useful for inspectors, such as the Cursor tab and Histogram tab, that I do tend to check casually, and selectors, such as brushes, patterns, and brush editor, that can be used casually. Of the seven tabs I have docked to the toolbox, three (palette editor, pattern selector, brush selector) would be useful to access in this way. Ideally, each could be a fold-out window (like tooltips), which would be accessed by hovering or clicking on an icon, rather than blocking other dockables that *should* remain visible (eg. Colors, Layers). If tabs could behave in this way, trying to avoid covering the dockbook they are expanded from, and automatically reset to the previously selected tab when done, this would work rather neatly. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] weekend 2.6 UI roadmap roundup...
Actually I got the impression that it had changed, and now box-filtering was used, which does account for all input pixels. OTOH, Lanczos currently produces poor results. Geert Jordaans (sp?) was working on improving this. On 10/30/07, Guillermo Espertino [EMAIL PROTECTED] wrote: I'd add the quality of downscaling as a high priority need. Currently it's possible to downscale images using 50% steps at a time (it was discussed before) but it would be better if one single scaling step produces the best quality possible (maybe automating the 50% steps, as it was discussed before). IIRC Sven informed that this issue would be easier to address with GEGL, so I don't know if proposing this fix before GEGL is appropriate. Anyway I'd like to point that it's a need for people who work with graphics for the web. Gez. ___ 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] 2.6 roadmapping, the UI part of it...
On 10/29/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On 10/29/07, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. http://curlyankles.sourceforge.net/widgets_docking.html Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap
On 10/27/07, Valerie VK [EMAIL PROTECTED] wrote: Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. This makes sense. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases. Yes, that would be a good idea. It's easy to get lost in the GIMP code, so a way to limit what developers need to look at would probably attract more developers. It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;) Actually I think I didn't explain the difference between adjustment layers and layer effects. Adjustment layer: a layer that modifies the layers below it, without actually contributing pixel data. An adjustment layer as used in Photoshop, has a mask, but no pixel data. http://www.phong.com/tutorials/adjust/ provides some examples, including eg. Curves adjustment. Layer effect: an effect attached to a layer -- for example, Drop shadow is a layer effect provided by Photoshop. Takes the layer pixel data and applies some effect to it. May have a mask, and does not have its own pixel data, so the only difference is the way it's attached to a specific layer. Peter suggested here: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html that layer effects could be thought of (and displayed as) a stack per-layer, sitting underneath the layer. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap
On 10/27/07, Valerie VK [EMAIL PROTECTED] wrote: So... Gimp currently has 4 major goals? - Cairo - GEGL - Add named parameters and default values to the PDB - 6 months development cycle. Wouldn't it be easier to treat them as Separate goals for separate releases? Once Cairo and GEGL (I have no idea for the Parameters feature, so apologies for not being able to say more about it) have been properly implemented, Gimp should have the foundations for rolling out features more quickly. Wanting two at the same time though seems to be asking too much, and proper implementation of GEGL in my opinion justifies one final long development cycle. Maybe something like this can be considered: Gimp 2.6: - implementation of Cairo (get this out of the way) - start background work on GEGL, by dedicating more developer resources (if possible) to actually coding GEGL without necessarily implementing it yet Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. The only major point for GEGL that is currently known that would make integration with GIMP difficult, is 8bit-specific code; GEGL Ops that accept and output 8bit integral RGBA instead of 32bit float RGBA. I believe many of these can be created automatically by modifying the current code, which already handles generating float versions of porter-duff ops and blending ops. In the mean time, a single conversion op (float - 8bit int) could be made. - bunch of other easier features to keep people happy - development cycle: 6 months to a year. Gimp 2.8: - GEGL integration - the background GEGL work that started with Gimp 2.6 should have paved the foundations for slightly faster integration - the development cycle will probably still be long, but this will be the last long release cycle. Gimp 3.0+: - with GEGL properly implemented, from now on, development cycles will be 6 months. Once GEGL has been implemented, the following features seem to be the most demanded ones: - CMYK - 16 bit - layer effects - layer groups It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. (for the reference of anyone who was considering bringing this topic up ;) Any one of the above could justify a minor release. Having the first GEGL-version of Gimp ship with one of the above features would justify the time spent on it, especially if the developers explain that the other features will follow fast. Having said first GEGL-version of Gimp ship with Two of the above would be fantastic. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] Wacom support in GIMP RC3
I'm successfully running Ubuntu 7.10 with a Graphire 3; The appropriate Device sections for the tablet were correctly specified after installation. I had to uncomment the following lines in /etc/X11/xorg.conf to fully enable the tablet: InputDevice stylusSendCoreEvents InputDevice cursorSendCoreEvents InputDevice eraserSendCoreEvents Otherwise it would just operate like a mouse. On Tue, 2007-10-23 at 11:20 -0200, Filipe Soares Dilly wrote: I'm using the GIMP 2.4 RC3 in the new ubuntu linux (7.10). I can use my tablet Graphire4, but it doesn't show in the extended devices for Gimp. Is that a Problem in RC3, or a problem of the compilation of Ubuntu? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] calling a procedure in a plugin
On 10/19/07, Giuseppe Pasquino [EMAIL PROTECTED] wrote: I have modified the code as you suggested: GimpRGB *colore; GimpChannelOps parametri; gboolean success; gimp_rgb_set_uchar(colore, pixel[0], pixel[1], pixel[2]); parametri = GIMP_CHANNEL_OP_REPLACE; success = gimp_by_color_select(drawable-drawable_id, colore, termogramma.scarto, parametri, FALSE, FALSE, 0.0, FALSE); The compiler returns me no error but when I execute the gimp return a fatal error: segmentation fault. I think the problem is in one of this line but, with my few experience, I can't find it... You are attempting to modify a color at some random memory location, that's never been allocated (you didn't initialize colore) -- and then you passed this dodgy pointer to gimp_by_color_select. In most parts of the GIMP, GimpRGB are statically allocated, and you see that they are used more like this: GimpRGB colore; GimpChannelOps parametri; gboolean success; gimp_rgb_set_uchar(colore, pixel[0], pixel[1], pixel[2]); parametri = GIMP_CHANNEL_OP_REPLACE; success = gimp_by_color_select(drawable-drawable_id, colore, termogramma.scarto, parametri, FALSE, FALSE, 0.0, FALSE); ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adjustment Layers - How can I Help?
On 10/8/07, Andrew Young [EMAIL PROTECTED] wrote: David, Interesting. GEGL sounds very much in line with a lot of the ideas I have about how to approach the problem. Is this seen as the future of GIMP's core? Image representation, certainly. Gimp's core -- maybe. That would depend on how it interacts with the procedural database. How big an effort is the port to GEGL expected to be? It sounds like an exciting time to join the development team. We'll know once it's started :) You mentioned that GEGL integration is slated for 2.4...2.6 development. Where can I find more information on plans for GIMP's development cycles? Are these documented somewhere on developer.gimp.org? AFAIK no, it was decided fairly informally, like in many OSS things -- people talked, it became the accepted idea over time, and nobody much mentioned it outside of the GEGL-developer and GIMP-developer mailing lists where it was discussed. Officially I believe Sven has said something to the effect of 'there is no roadmap; people implement things because it's fun or they need it, not because there is a deadline.' ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adjustment Layers - How can I Help?
On 10/8/07, Andrew Young [EMAIL PROTECTED] wrote: Greetings! I have been an avid Gimp user for a number of years. I have always wished Gimp supported non-destructive image adjustments such those available with Photoshop adjustment layers. From searching around the internet, it seems I am not alone in this wish. However, I haven't been able to find solid information on whether they are planned, under development, or sitting in a pile of nice-to-have enhancements waiting for attention. Rather than continue to wish for them, I am considering joining the development team and implementing them myself. Are there others currently working on this feature? If so, how can I help? If not, has anyone put some serious thought into how this could be implemented? Hi, non-destructive adjustments are going to be implemented via GEGL (www.gegl.org) - after the final 2.4 is released will be the time to work on this in GIMP (indeed, GEGL integration is the entire purpose of the 2.4...2.6 development cycle.); other than that, there is http://gimp-brainstorm.blogspot.com/ for working out the UI (and http://www.mmiworks.net/eng/publications/labels/GIMP.html , the precursor). Feel free to contribute to the brainstorming process or to GEGL, and eventually to GIMP as it enters the 2.6 dev cycle. Is anyone looking for a new feature to work on and would be interested in helping me? Andy ___ 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] [Gegl-developer] PyGEGL instant crash
On 7/23/07, Kevin Cozens [EMAIL PROTECTED] wrote: David Gowers wrote: The what's new document for each release is a good resource for these kinds of problems, especially its porting section: http://docs.python.org/whatsnew/porting.html The last two items on that page seem to be the more likely candidates that could cause problems. I don't see any calls to *_Malloc() or *_Free(). There are a number of calls to g_free(). If any of them are being called on items that were not allocated by a glib routine that could be the cause of the crash. That page has also made me aware of at least one change needed for 64-bit machines. -- Cheers! Kevin. Was trying to investigate this further. It turns out that current SVN of pygegl will not compile: gegl.override: In function '_wrap_gegl_node_render': gegl.override:332: error: incompatible type for argument 2 of 'gegl_node_blit' gegl.override:332: error: incompatible type for argument 3 of 'gegl_node_blit' gegl.override:332: warning: passing argument 6 of 'gegl_node_blit' makes integer from pointer without a cast gegl.override: In function 'pygegl_register_classes': gegl.override:139: warning: dereferencing type-punned pointer will break strict-aliasing rules due to a change in the blitting api. Tiny patch is attached to fix it. The crash I originally reported still happens; none of the g_free calls seem to be freeing anything other than glib allocated memory. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] McCann Retinex plugin with python
On 9/15/07, John Fremlin [EMAIL PROTECTED] wrote: Yesterday I decided to implement the retinex algorithm described by John McCann in 1999 as a gimp plugin. I am using Python (in particular numpy for the main calculations) and consequently chose to put in some modifications to the algorithm to make it more efficient, but it makes generally the same effect as that described in Brian Funt, Florian Ciurea, and John McCann Retinex in Matlab, Proceedings of the IST/SID Eighth Color Imaging Conference: Color Science, Systems and Applications, 2000, pp 112-121. http://www.cs.sfu.ca/~colour/publications/IST-2000/index.html As this is my first foray into gimp plugging in, I'd appreciate if someone could look over the code. Is there a more efficient way of getting out one colour channel of the image at a time? At the moment I read in the whole image which takes a lot of memory. plug_in_decompose decomposes the image into a layer per channel. Searching the archives today I notice that Pedro Paf was suggesting implementing it as a Summer of Code project - as the algorithm is very simple (a day to make even starting no numpy or Gimp python knowledge), what enhancements where being contemplated? I find this odd -- your whole email odd, in fact, because -- there is already a retinex plugin (found at Colours-Retinex; plug-ins/common/retinex.c in the GIMP source tree.). If you want to add some enhancements, perhaps you could check that out first. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Vectors Object Documentation
I converted the script to python (useful script, btw -- thanks Simon.), and I cannot reproduce this. I did, however, find that I was occasionally tripped up by paint mode -- for example, if Addition mode was selected rather than Normal, then drawing black on a white background had no effect. The other condition that can cause this appearance is when the selection masks out all of the area you are stroking. On 9/12/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi Simon, what about the other issue that Barton reported? Apparently the stroke is being made with the background color though the pdb for gimp-edit-stroke-vectors says: This procedure strokes the specified vectors object, painting along the path with the active brush and foreground color This sounds like a bug to me. Sven ___ 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] Additional Default Brushes for 2.4?
I like these brushes a lot. They can be cut down to 20 rather than the original 154, since 2.4 includes brush scale adjustment, and I have mentioned this to iceytina at the last of your links. I would like to take this opportunity to plug my particular contribution to 2.4, the palette navigation actions (allowing you to move through the active palette, changing FG color to match; try pressing '9' or '0'. Requires having the palette editor open somewhere.) On 9/12/07, Máirín Duffy [EMAIL PROTECTED] wrote: Hey folks!! I know it must be terribly, horribly, ridiculously, and extremely late to suggest this at this point in the 2.4 cycle but - I recently got in contact with a very talented Gimp brush artist on deviantart.com; she's made a number of brushes that seem to be the sort that would be generally useful in a default Gimp install. She told me she is willing to license them under the GPL (they are currently Creative Commons BY-NC-ND) if they would be considered for inclusion into the Gimp. Links to the brushes are here: Watercolor Paint: http://iceytina.deviantart.com/art/GIMP-PaintBrushes-Watercolors-31117244 Waxy Pencils: http://iceytina.deviantart.com/art/Gimp-PaintBrushes-Pencils-31116570 Oil Pastels: http://iceytina.deviantart.com/art/GIMP-PaintBrushes-Oil-Pastels-31115517 Crayons: http://iceytina.deviantart.com/art/GIMP-PaintBrushes-Crayons-31087987 Airbrushes: http://iceytina.deviantart.com/art/GIMP-PaintBrushes-Airbrushes-31029257 Brushes: http://iceytina.deviantart.com/art/GIMP-PaintBrushes-Artist-31030053 If these seems like they'd be valuable to include, I can get you in touch with her. Thanks for listening! ~m p.s. BTW, AWESOME work on 2.4 so far, I've been using RC 1 for a while now and I have to say it feels a lot more comfortable to use - it's gotten me really excited about the Gimp all over again. :) ___ 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] Feature request, - liquid resize
On 8/22/07, Thomas Lytje [EMAIL PROTECTED] wrote: I am not sure you take feature requests like this, - but try to take a look. It seems quite cool. I don't know enough about image processing (but I am a software engineer) but to me it looks like it wouldn't be to hard to implement. Hopefully there isn't a lot of patens making it impossible Looks like a resizer in which the amount of source pixels per output pixel varies spatially, rather than being roughly constant. It seems to have a few requirements: a) Resizing can only be done on one axis at once b) two scalers would be needed, one iterating over X axis, one over Y. Basically the only change relative to normal accumulators is that the number of pixels resulting in a final pixel would need to be inversely weighted by the significance mask (that is, read more input pixels to produce an output pixel in insignificant areas.) There is also one coefficient involved that would need some experimentation with to get right: the exact ratio of scaling between completely significant pixels and completely insignificant pixels. (I mean, when you shrink that image, the significant features must also shrink somewhat -- at least once they begin to push up against each other.) Anyway, if you give a link to a paper describing the exact workings of the algorithym, then it's much more likely that something will get done in relation to it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hue-Saturation tool with gradients
On 8/18/07, Liam R E Quin [EMAIL PROTECTED] wrote:
On Thu, 2007-08-16 at 14:50 -0300, Guillermo Espertino wrote:
If somebody is interested in participating in this process please send
me an e-mail so we can coordinate efforts with Danko and Marius
My own feeling is that it would be better to wait until there is
some experience with the post-2.4 GIMP and higher definition
colour models before changing any of the colour tools.
* Different Color models are fairly irrelevant to Hue-Saturation
adjustment, because HSV is a simple transform of the RGB colorspace --
it's either going to expect RGB or (the currently not-implemented, and
of dubious use) HSV color format.
* Higher definition (HDR) could possibly be relevant -- but you would
need to keep in mind that an HSV tool which worked with HDR data would
no longer be an HSV tool (Saturation is a parameter that's dependent
on the blackpoint and whitepoint, which are both undefined in an HDR
image. Value is similarly dependent.)
* Higher precision might be something that UI people need to consider,
for Saturation and Value adjustment. But this just involves bumping up
the maximum values, more or less, so it's a change that can be made
readily at any time.
* I think what Guillermo, Danko, and Marius are doing is both good and
timely. ('now' is always a good time to work on enhancing such
technically simple tools.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
On 8/6/07, Guillermo Espertino [EMAIL PROTECTED] wrote: A couple of weeks ago somebody commented about the quality of the downscaling in Gimp. iirc there was a patch that improved the quality (that was bumped for future releases) and there was a discussion about the pertinence of the different names of the algorithms in the interface. Well, I know that this kind of requests are not welcome when a new release is so near, but I've been using Gimp a little more this days for small images (my previous works were for print or signs, so I didn't find this issue to be critic), but now I do and I'd like to share my experiences and my concerns. I'm working in a website right now, and one of the most frequent operations is to reduce images. I coudn't get a decent reduction using the different algorithms. If you have to reduce a very large image to, say 800 px, you can use oversampling and you get a decent result, but when you're working on images for the web, which are frequently smaller than 100px, the results are very bad. If you use oversampling, the result is a blurred image. If you don't you get jagged edges.This is particularly visible when you work with type, logotipes or high contrast images. You don't appear to be using oversampling, as you say: If you perform the transformation just once, the imperfections are visible. But the big problem comes when you have to perform transformations a couple of times. Oversampling cancels that out, because the increased resolution minimizes loss of meaningful data. (oversampling == editing at a increased resolution relative to intended final size.) Perhaps you mean supersampling? And this operations are not rare. It's very common to scale down an image, rotate it and then tweak the size again. For now, you should rotate before scaling down if possible. The last time I mentioned this, Sven replied: I might be wrong but I think the current algorithms are basically the same as the ones used in GIMP 2.2. So there's really no point in addressing this long-standing but minor issue before 2.4. I thought then that it was ok, but I've changed my mind. It's not minor at all. Since Gimp doesn't support CMYK, it is not a viable tool for image processing for print, so we have a tool mostly for screen works. One of the main professional applications for that is preparing images for the web, and this issue is critic for that kind of work. As a little example, I had to create a button for changing a website's language. I had a high resolution flag of the UK and wanted to reduce it. I coudn't get the image right, by any means. I had to re-draw it using single pixels (I know that diagonal lines are difficult to represent in small sizes, so don't start to call me stupid. I made the same work before with other software and got better results). This is an artefact of the way downscaling currently works: it examines 2x2 pixels for each output pixel. This means if you're downscaling to less than 50%, some source pixels are ignored. If Cubic was properly implemented for downscaling, it would examine 4x4 pixels for each output pixel, and some pixels would be ignored when scale 25%. Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.) Maybe GIMP could implement the above workaround before 2.4. It would be inefficient (scaling down the image N times instead of once) but it would mean that the result was correctly dependant on ALL the source pixels. Non-destructive transformation is something that would be more sensible to implement after 2.4. The release of the 2.4 will be a huge event. The program went through very important changes, and it's becoming a truly professional application. If you compare 2.3.x with 2.2.x the difference is impressive. Now Gimp looks and feel professional. It would be a shame to inherit that limitation from 2.2 series and have to wait until the next version (which, considering the whole GEGL thing. won't be ready soon). Please don't take this comments as another stupid user request. This is very important and for me is the major issue that obstaculizes my migation to Gimp. I'd like to have CMYK, of course, but color management is enough for now, since CMYK is not a small change. I'm not telling that's a small change either, but I think it's critic enough to take a look before 2.4 I've discussed this with several users and they share my point of view. I'd like to know what you guys think about it, and if it's possible, revise the situation before 2.4 Thanks in advance, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4 annoying things in Gimp
On 8/5/07, damianzalewski [EMAIL PROTECTED] wrote: 1. When designing complicated project for example cd cover I often have to chain and unchain layers. Would be nice if gimp would have option - unchain all. Maybe, but you can already do this in two clicks 1. shift-click on the layer chain to make a layer the only one chained 2. click on the layer chain to unchain that one too. 2. I can't make gradients bigger the current image area. Couldn't it work like other tools. ? Works for me. Are you running GIMP on the dreaded Windows OS? ;) 3. Every time I want to move layer using move tool I have to click on this layer first to be able to use arrows keys on keyboard At all, or on that layer? if at all, then see below about your WM. otherwise, you probably don't have that layer selected (== the active layer). If you can think of a way to improve this behaviour, then please say so. 4. I have to click on the top of image window to go to fulscreen mode (pressing TAB) That sounds like it's related to your window manager not giving the image window focus. Personally I find it best to set the focus to follow the mouse, then i needn't do any clicking. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
On 8/1/07, Anke Lange [EMAIL PROTECTED] wrote: Hello like everybody else, I am very exiting about the release of the Gimp 2.4. Though I was wondering, if GAP will be running on the new Gimp. I tried to install it to the 2.3.19, but as you proberbly would have known, it doesn't work and you just get lots of errors. Thanks for any information. Regards Anke Lange * Works for me - I'm using the latest GIMP and GIMP-GAP from SVN. * GIMP-GAP is relatively loosely binded to GIMP - it does not depend on the internal structure of things very much. When GIMP architecture starts changing significantly to use GEGL, much of GIMP-GAP might still work unmodified; but such changes to GIMP shall occur after the 2.4 release, not before, if I understand correctly. * You have omitted some details (What OS? What version of GIMP-GAP?). It's possible that you simply have a out of date version of GIMP-GAP or the packages it depends on. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 58, Issue 51
On 8/2/07, Esteban Barahona [EMAIL PROTECTED] wrote: and one of 1 Dimension Menus which is a bit more matured (see attachment... It looks like either you forgot to attach the file, or the mailing list software filtered it out because it was too big. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/31/07, Guillermo Espertino [EMAIL PROTECTED] wrote: David Gowers wrote: Yes, I'm aware of that. I mean to perform boolean operations on the paths tehmselves. Well I think that GIMP should avoid doing that, and instead expect you to do it with inkscape; transfer of paths between the two programs is very simple and inkscape's just plain better at path editing. I'm not talking about vector illustration. I'm rather thinking about options for combine visible layers in the paths dialog. It would be nice to have a pop up window when you choose that option, letting you choose between different boolean operations. For instance: if you have a road sign, and you created a path for the sign, and another for the pole, if you combine those layers the parts that intersect are excluded (that's the default behaviour of the combination and that's ok). But sometimes you need to join the paths or substract a part. I know that's possible using the selections and channels, but that makes you go through several steps. And sometimes you need a single path (most frequently for keep the file clean without hundreds of layers). Using the selection and turning it back to paths can be a workaround, but it's not 100% accurate and it's not the most handy thing. If you have a plugin that uses potrace instead, it's much more accurate. I noticed this issue a couple of days ago while creating a file for big format print and cutout. I needed to export the vector paths for the cutting shape, and -as I had to isolate the images using gimp, the most handy way to do it would be to make the path just one and re-utilize it later. It wasn't impossible and I made it with selections and exported the paths and combined them later in inkscape, but having a one-step combine would been a very important productivity enhancement. Doesn't 'merge visible' do what you want? If not, script it. Oh, btw. Another thing I was wondering: Is there a way to straighten a single path segment in the bezier tool? Yes; Ctrl+click on each handle (not the round ones; the square ones that control the shape of the curve) -- ie. once on the handle on one side, and once on the other; they will each disappear. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/30/07, Stephen Kiel [EMAIL PROTECTED] wrote: David, I found a gimp-2.3.18-i586-setup.exe and installed it (after a system backup). I wanted to check the functions you mentioned without having to set up a build from source code. Anyway, the way the freehand select is working in 2.3.18 is great, it was just what I was looking for. The advise about using the channels for the boolean operations on multiple selections worked out great as well, I didn't realize they had that capability. I had never thought of channels beyond the Red, Blue, Green decomposition of the image didn't have occasion to think of using them. I'm glad I could help. I tried the foreground select and found it pretty interesting. It looks like it wil be a real time saver. I did have a couple of observations which might be old news since this is one version back from 2.3.19, but here goes just in case: 1) There wasn't an obvious want to tell the tool you were done refining and ready to make the selection. It took a while to notice the message at the bottom of the window to hit enter. Seems like putting in a button would save some new user fumbling, but after they discover that Enter is the shortcut, they will probably not use the button any more. Don't know what to recommend for this. Yes, I noticed this too. An additional difficulty is that the statusbar is not guaranteed to be visible, so putting a button next to the status display would not guarantee the user sees it. I don't have any idea what to do here either. 2) The foreground select tool seemed to act differently depending on the image size (pixels) and the zoom level. Might be the version, might be the installation I picked up. With an image that is 2304 x 3072 which comes up with a default 25% zoom on my screen, the preview display covers the entire image after selecting a region to work on. Taking it up to 100% zoom displays it they way you would expect. Yes, this bug is known and fixed, release 2.3.19 includes this fix. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/27/07, Stephen Kiel [EMAIL PROTECTED] wrote: David, Thanks for the reply. I am using the Windows version of 2.2.17. In this version the issue that I am having an issue with can be reproduced in any image by selecting the freehand select tool, draw a circle in the image creating a selection, press the subtract from current selection mode button, move the cursor inside the selected region, depress the mouse button to start defining the region you want to subtract, and when you move the mouse you move the selection as a floating section instead of defining what you want to subtract. If there is a fairly stable version of the tool that has a fix for the issue I am having, that would be great. Which version should I be using? You could just wait for the next release, which IIRC should be 2.4, and thus a 'stable' release; you might even consider using 2.3.19, since it is right at the end of the 2.4 development cycle and so almost as stable. This problem you describe has been fixed for quite a while, although not as long as I thought (since version 2.3.12) -- this problem isn't quite what I thought it was. Anyway, it has been fixed in a way such that subtraction/adding/intersection is always predictable, but if you want to cut out/copy out the selected area, you need to either use 'float' in the menus to do that, or (CTRL+ALT+drag to cut the area out, ALT+SHIFT+drag to copy the area out.) Your comment See the Channels dialog -- that's exactly what it is for. for a providing a selection stack capability sounds interesting. Do you have a link or reference that elaborates on this? Hitting F1 in the channels dialog provides a pretty good description, including how to compose a selection from several channels. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/26/07, Guillermo Espertino [EMAIL PROTECTED] wrote: Stephen: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. I'd reccomend you this workflow for background extraction: -Draw a path along the edges of the shape that you want to extract, draw other paths for the holes (if you create them in the same path layer they are automatically combined with the other paths forming holes). -Turn path into selection -Add a mask channel based on that selection. So, imo, the existence of better tools for the same procedure makes this request questionable. If you ask me, I'd love to have the ability to apply boolean operations between different paths before seeing further work on the free selection tool. You can already do that. Right-click in the Paths dialog, all the standard operations (replace, add, subtract, intersect) are available. Unless you mean boolean operations that modify the paths themselves, rather than the selection. GIMP doesn't have that. Oh, btw. I'm experiencing some troubles with SIOX. In some images (I couldn't figure it out exactly when it happens) after the initial coarse selection the mask is displaced to the lower left of the image (with the right shape, but completely misaligned with the image) making it impossible to perform the extraction. Is that a known bug or it's just me? I thought this was a known bug that had already been fixed in SVN. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/27/07, Stephen Kiel [EMAIL PROTECTED] wrote: Guillermo, Thanks for taking the time to reply to my request. It appears that you and I have a fundamentally different point of view on how to best select regions in an image. Let me throw out a couple of observations before I address some of your points in the hope that I can avoid starting a religious argument about which technique is better (especially if my side is outnumbered). - In most applications most of the users focus on about 20% of the options and capabilities in a given tool whether it is an office tool, or an engineering Design Automation tool. I suspect this is true of almost any tool that is fairly flexible. This does not mean that the 80% that any one user doesn't normally use aren't valuable as different users solving different problems. - It is important that the work on an image has an intuitive feel. No one methodology or selection method works best across all of the images you might encounter. Users will develop favorite methods based on their own success and failures with features of a tool. Failure with a feature of a tool is not a reflection on the feature, it just points out that a variety of robust features are necessary for a well rounded tool. - The enhancement that I am asking for is for the current mode of operation to perform in a manner that would be expected by a reasonable user. When the user selects a mode of operation using the menu and switches, it seems reasonable for the tool to honor those choices rather than making a unilateral decision to change modes based on cursor location. The fact the behavior is called out in the specification doesn't really change the fact that it is kind of user unfriendly. The 'enhancement' that you describe, in my experience, has been included in the GIMP for at least a year. I cannot reproduce the problem you describe (and for the purposes of getting this changed, you will probably need to come up with some reliable way of reproducing it.) Let me try and address your points: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. If I believed this I would not have bothered to ask for the enhancement in the first place. I think of using the freehand select for precision work as part of my methodology rather than a bad idea. When I started using Gimp I tried the Path / Bezier tool but in practice I really haven't found much use for it. The notion that it is better is subjective and is not in line with my experience. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. This may have been the vision when the tool was put together, if it was I would say the Freehand select exceeded the original expectation. I believe that it is the best selection mode in Gimp for making precise selections. - How fine your control is for defining a selection line is determined by the level of zoom you are at, not whether you are drawing the line or defining it with a series of dots. The freehand select is as precise as the picture and tool will allow. That doesn't even make sense. The freehand tool and path tool have both exactly the same level of precision -- they both render polygons, so they're infinitely-precise; freehand can be faster if you have a steady hand; paths is more precise because it can draw shapes with holes in them in the same step as drawing the outside - freehand select must do such things in two steps, because it makes some assumptions about how the user wants to use it. Freehand select works under the exact same rules as path tool - including eg. what happens when a polygon self-intersects. The only difference is that freehand composes the path itself, so that you can select a complex shape with click+move... instead of one click per point as in paths selection. To demonstrate that, move your mouse in a circle with freehand select, and scribble through the circle before releasing the mouse button. - Describing a line with a series of dots is not inherently quicker or more precise than just drawing the line. If you have to start inserting more dots or fiddling with the handles to reshape the line, you are going to waste lots of time. I must point out that for simply-shaped selections, adjusting the path handles gives results of higher quality, faster. The trick with Freehand select is to do a rough selection and then do the precise work using small closed strokes to add or subtract onto the selection. The feedback is immediate, and is easy to draw a precise line with the mouse as long as it is short. Yes, agreed on all points here. Try using freehand select with a tablet though (if anyone you know has one you can borrow) -- it eliminates some of the complexities that you are describing, so that you can select an entire
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/26/07, Guillermo Espertino [EMAIL PROTECTED] wrote: David Gowers wrote: You can already do that. Right-click in the Paths dialog, all the standard operations (replace, add, subtract, intersect) are available. Unless you mean boolean operations that modify the paths themselves, rather than the selection. GIMP doesn't have that. Yes, I'm aware of that. I mean to perform boolean operations on the paths tehmselves. Well I think that GIMP should avoid doing that, and instead expect you to do it with inkscape; transfer of paths between the two programs is very simple and inkscape's just plain better at path editing. Anyway the current behaviour is functional (performing boolean operations on the selection using the paths layers as input) so this can be an interesting enhancement but not an urgent one. Actually, if you perform these operations on the selection and then convert the resultant selection back to a path, how does that work for you? I think, if GIMP got a better selection to path function (for example, the one that I made which uses PoTrace as a backend.), then this would work quite well for your purposes. Oh, btw. I'm experiencing some troubles with SIOX. I thought this was a known bug that had already been fixed in SVN. I'm having that problem in Gimp 2.3.18 and the fix is not announced in the latest realese. actually, it is.. 'Bug fixes' :) Yes, it really is. http://bugzilla.gnome.org/show_bug.cgi?id=448417 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] PyGEGL instant crash
BTW, Nick Coghlan said: The most likely culprit is that some of the code is using PyMem_Free on a pointer allocated with PyObject_Malloc (or vice-versa). This has always been illegal, but prior to 2.5 the Python memory allocator tied itself in knots to try to avoid crashing when client code broke the rules. The changes in 2.5 to release unused memory back to the OS required that those knots be cut. The what's new document for each release is a good resource for these kinds of problems, especially its porting section: http://docs.python.org/whatsnew/porting.html Which looks to me to be the most likely case, but I find the majority of the PyGEGL code inscrutable. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] PyGEGL instant crash
On 7/20/07, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: I have only tested pyGEGL with the 2.4 version of Python. It possible (or very likely?) that something has changed in the 2.6 version of Python. I don't have the 2.6 version installed at the moment so I can't investigate this further. Python 2.6??? The stable python is 2.5.1 - there is not even mention of a 2.6 release on teh python.org pages. David: do you mean python 2.5 instead? I mean python 2.6 -- that's SVN python's current version number. I believe a release is due fairly soon. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On deep-pixel (large number of bits per channel) support...again
On 7/14/07, Kevin Brown [EMAIL PROTECTED] wrote:
My question is this: where is the 8-bit per color channel limitation in
GIMP? That is, which bits of the source code limit the GIMP this way?
I ask because I took a brief look at the source, and it seems the
internal color representation is stored in a GimpRGB struct, but that's
one of these:
struct _GimpRGB
{
gdouble r, g, b, a;
};
Ah, GimpRGB is unrelated to the format a picture is stored in. It's
used for things like specifying colors in palettes and color
selectors.
If you look around some more, there are also structures like GimpHSV,
GimpHSL, GimpCMYK encapsulating other useful color formats.
In other words, it looks based on this naive examination like GIMP is
already capable of handling pretty much arbitrary resolution per channel.
What am I missing, and where do I need to look to see the limitations
that prevent GIMP from handling more than 8 bits per channel?
Uh... just about anywhere in the backend and plugins. There are
assumptions made all over the place that a single component is stored
in a single guchar (unsigned int, 0..255). There are assumptions that
the bytes per pixel determines directly how many channels are in the
image;rgba values are considered as having the range 0..255, etc...
If you want specific places, ignore everything outside the app/ directory.
base/ is the most blatant (and important) example of these assumptions
- a majority of the .c and .h files there include such assumptions.
Thanks, and sorry for the naive question...
Eh, you've gotta start somewhere, it's fine.. :)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
On 7/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler [EMAIL PROTECTED] wrote: I'll try to follow the analogy without this becoming rediculous: [misrepresentation and reactiveness cut] We all know that jpeg is lossy. You use it with suitable settings in relation to the result required otherwise you use a different format. There seems to be some underlying assumption here that jpeg loss is catasrophic. It is not. Sure, if I am going to post about the difference between lanczos and catmull-romm filters jpeg will not get a look in. However if I am messing with a photo of my solar panel at jpeg-84 I dont want some arse telling me I have to first save if in a format that takes up 10x more space because I may later want to reopen it and I may lose a bearly perceiptible bit of quality. The proposed scheme does not dictate that. The only thing needed to facilitate your described work flow, with no additional overhead is a 'Quick Export' command that just saves to the last 'non-native' filename (if I may introduce the idea of assigning both a native filename and a (possibly empty) render filename to each image; this would help with a number of things, eg. drawing with oversampling, quick photo editing, images for web..) As Raphael says we should try to cater for all users if possible. The suggested first time use message with dont show again option would seem best all round. Yes; just not only that. The full scheme described by Peter plus that. I should also point out the misuse of the import/export paradigm. This is used in other software of various sorts to indicate loading/saving data in a format which is not handled natively by the program. Gimp only handles XCF; the rest *are* implemented outside of Gimp; even gzip/bzip2 compression for XCFs is implemented as a plugin. If you remove all plugins, it's plain to see that Gimp only handles XCF natively, just like Photoshop only handles PSD natively; It's generally a Bad Thing for an editor to need to cope with multiple 'native' formats. GIMP's 'parasite' concept allows it to store arbitrary chunks of data, that may be acquired from importing (eg EXIF data from a jpeg) without needing to understand the meaning of that data; I understand how this may give the illusion that GIMP can handle something not XCF, but it is only an illusion. I think, highlighting this fact might be quite wise. We should not annoy the user in telling them this - something as outwardly simple as a parasite viewer/editor dockable could improve awareness. It is nonsense to talk of exporting a jpeg to gimp's internal format. I agree fully. Nobody has mentioned that*, only the opposite. 1. You load the jpeg. (foo.jpeg) 2. You work on it. Each time you save, it's in XCF format (foo.xcf) 3. You export a jpeg when finished (foo.jpeg, or maybe foo-final.jpeg) If anything, that says 'automatically import from jpeg' (which is the current behaviour, minus actually changing the on-disk image format.) and later 'export to jpeg'. The addition I suggested earlier in this email would be trivially easy to implement and use, logically consistent, and would not require the GUI's concept of Save to remain in its current, broken, state. I think, in short, this thread is mainly comprised of miscommunication; People seem to think it implies things that it just doesn't. * Maybe Valerie did. I found her post very confusing, so I'm not sure what she was suggesting. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] default vs. original vs. current settings
On 7/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007 01:23:39 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: Does current need to be saved as a third option? It is either equal to default or original unless it is set during a save in which case it become the new value of original. Are you suggesting the truely original settings are retained after a save with different values? If so how long? End of session perhaps. I thought this could be simpler -- if the original settings for an image are attached to the image as a non-persistent parasite, that parasite will expire when the image is closed. IMO this is more logical than keeping till end of session (keeping til end of session is what would happen if you attached a non-persistent parasite to GIMP itself.) Ah yes , I've just realised there are many of these extended settings that are not set in the save dlg so there is a real need for your third option. In theory, these parameters should work like this: all new images or images loaded from disk get the default setting except if some files have an original setting, which is then used instead of the default one. This then becomes the current setting, which is associated with that image every time it is saved. I think that works well with the above, since the original setting becomes the current in a suitable way. This would solve one of the problems that has started this long thread about the JPEG quality factor: saving one image in low quality will not cause other unrelated images to be also saved in low quality. The other improvement that can be implemented without waiting is to read or compute the original quality from JPEG files and to use it if and only if it is better than the default quality. I'm not sure about the ifing and butting. I think the program should work in one predictable and consistant way. There is also in problem artificially altering this value if it is better. That is subjective. A numerically higher jpeg_quality value is not better if you dont want you file to suddenly get huge next time you save it (obstencively without changing anything.) I think default values should be used only _by default_ , ie when no other value is available as you outlined at the top. If there is a perceived need to force these values (and that seems to be the main difference of option here) then perhaps the dlg for setting the user defined defaults should have an option force these settings for all jpeg images. This Yes, cool -- in what scope? (ie -- this session, or all sessions including and after this one? in the latter case we should provide a way to clear those.) defaults to false, so the user who sets default parameters has to actively select the forcing and takes legal repsonsabilty for the resulting bloat/degradation trade-off. We need a way to flag this to the user -- maybe in Image Properties dialog, something that is both unambiguous and not Jpeg-specific (eg. it could also apply when you are exporting to an indexed format). Honestly, this 'force' option seems necessary though hackish. I've made a few tries at writing such a message, but came up with nothing yet. That satisfies those who want to define across the board behavoir at the same time as providing a gimp jpeg save that does nothing more than is asked of it: save the image as it was loaded unless the user intervenes. To me this seems to be the only proper way to handle it. A Save should not be trying to do a furtive SaveAs. This is true. Perhaps Save could insist on prompting you for an xcf filename if the image filename is not xcf. I believe that resolves both inconsistencies - silent upgrading and saving-that-is-losing, as well as defining a more clear workflow for the individual cases of 'quick edit' and 'significant work over time' - in one case you edit and QuickExport*, in the other you edit, save, edit, save... and eventually export (maybe repeating that cycle if you need to revise things) * yeah, this name could be improved. Perhaps you could have Export and Export As instead (where Export performs the function I called QuickExport earlier, and Export As could probably replace 'Save a copy..') ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking [EMAIL PROTECTED] wrote: Really? Let's have a look at the product vision. 'High-end' is the word I want us to focus on. Please dont distort this by taking one word out of context. Gimp's aim to be a high-end image manipulation program does not mean everyone has to become a professional graphics artist. Nor has Peter suggested this. Take your own advice about not taking things out of context. What was suggested is essentially to make the 'Save' action more truthful - in order to a) Reduce confusion -- 'wait, every time I edit and resave this jpeg it gets worse. Why is that?'* -- by providing a standard editing format. Throwing away data is a pathological case, which is why GIMP should only allow this by a plugin, rather than explicitly supporting it; it should, probably, be considered 'deprecated'. b) Reduce corner cases (ie improve interface consistency) -- 'Save' shouldn't mean 'Lose.' in any case. c) Adhere better to the basic Unix tenet of 'Don't throw data away unless explicitly commanded to.' What is being proposed is both more effective for the general editing case, and more flexible. I appreciate the compression benefits of JPEG for photos, but IMO on todays multi-gigabyte hard drives, saving a single uncompressed working image per image you work on is unlikely to be any significant resource drain.. even for huge images. I want to mention the necessity of recording the original input image filename -- and maybe an action to 'Save over original'; I believe it hasn't been addressed yet, and I expect that someone like yourself would be satisfied by that. (I still think you should RTFM on the vision of gimp as high end graphics editor -- it was made by discussion with the GIMP team in-person. http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-overview.html http://gui.gimp.org/index.php/GIMP_UI_Redesign ) *as someone else already noted, any manipulation of large areas of the image is liable to cause further compression error, whether the compression parameters have been altered or not. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] selections workflow???
On 7/10/07, Tom Davidson [EMAIL PROTECTED] wrote:
Im going to go nuts - i do not understand the gimp work flow with selections.
When I paste an element on to a layer, i can no access the area of the layer
not covered by the element. In on specific example, I moved the contents of a
layer slightly to the right. This left a small column of transparency on the
left edge. I have tried to select this are to fill or brush but using several
different selection tools, but it appears that the element is currently
selected and I can not deselect it.
It looks to me like you moved the layer itself rather than its
contents, and you are attempting to draw on an area that is beyond the
bounds of the layer. What Chris Mohler said would help you in this
situation.
It is also more likely that the layer is active, not selected.
Selections normally show up as an animated outline ('marching ants')
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] selections workflow???
On 7/10/07, Tom Davidson [EMAIL PROTECTED] wrote:
yes, sounds like Chris suggestions may do the trick. I will try it our 1st
thing in the morn when I get back to work.
It looks to me like you moved the layer itself rather than its
contents,
i used the move tool with not hot keys. clicked on the element and drug it
to the right finalized move with the aarow keys. would that move the
layer?
Yes.
In this case, it was probably the right thing to do.. The only mistake
you made was not finishing with the floating layer (see below)
thank you for the heads up, i will pay more attention to this.
It is also more likely that the layer is active, not selected.
Selections normally show up as an animated outline ('marching ants')
so the layer must be active AND selected ? what i referred to as the
element or content, did have the marching ants, even when i deselected all.
AFAIK this only happens for floating layers (When you paste, that
creates a floating layer; The floating layer will remain active and
selected until you either delete it, anchor it, or turn it into a new
layer (by selecting 'layers-new layer' from the menus)
AND i could only fill/brush inside this boundary but i obviously need to
fill outside the boundary.
'Lock alpha' is enabled by default for floating selections (see the
Layers dialog, underneath the Opacity control.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make The image may well be quite unlike the input due to lossy compression -- see below. the existing choice of jpeg_quality irrelevant. It represents the users choice of size/quality trade-off. I see no justification to discard that choice as irrelevant. AFAICS, Sven is saying that it is irrelevant, because it is *impossible* to numerically represent the overall quality of the image to be saved. The quality setting of the input file, assuming that it is correctly calibrated to the IJG scale, would be multiplicative: when you save a jpeg file with quality 75, you are saying 'throw away a certain amount of the image data' -- and saving it again with quality 75, you are saying 'discard that much again'. You can't save with the same quality, because you've already thrown away much of the data that was used to create the first JPEG. Actually getting a quality that is notionally '75% of full detail' when saving a jpeg output from a jpeg input, is trial and error -- so really, presenting a preview would improve the situation. As for the practice of saving jpg outputs from jpg inputs, my personal experience has been that it's a BD thing; basically the only two possibilities are a) Image mutilation b) filesize inflation (ie. you can preserve quality.. by choosing something that effectively renders JPEG's compression ineffective (quality = 96 or above, IME) -- this often inflates the filesize beyond that of lossless image formats like PNG.) About the only thing GIMP could do to help here, is to warn the user if they are saving a jpeg file and the image was originally loaded from a jpeg file. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Doing an action for each color in an indexed color-palette
On 7/5/07, Roberto Uhlig [EMAIL PROTECTED] wrote: Hello and best thanks first, but it doesn't work correct on my xp-pc with gimp GIMP 2.3.10. After private consultation with saul some testing and some changes for windows (backslash \) now it works fine. Essential change is, that saul's ;; (set! blue (fmod (aref color-map (+ 2 index)) 256)) doesn't work. aref brings sometimes negative eg. -51 values. In that case you have to ad 256 to become the realy color-value for blue. So I implementet (set! blue (aref color-map (+ 2 index))) (if ( blue 0) (set! blue (+ blue 256))) and it does his job. I've tested it only under WINXP with Gimp 2.3.10 and also with 2.2.11. Because of a bug in save-tiff-plugin in gimp 2.3.x (I din't know which was the fix) it isn't possible to save black-white (1bit) indexed with older gimp's. In my 2.3.10 it works fine. Where can I find Informations about internals of the color-map int8array data storage, because I found that negative integer values? I don't know where you can find that info; but I know myself -- Each image's colormap is made up of sets of 3 bytes (R,G,B); these values are unsigned. Since you have found you had to add 256 to the values in that case, it seems to me that script-fu must be wrongly treating the colormap values as signed values, and this is a bug. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] valgrind results
Sven, you suggested that I run valgrind to locate the source of a bug related to eyedropping. These are the highlights of the results. This part is probably unrelated to the eyedropping bug (bug #450802), but may be serious: It happens after the image is loaded; don't know whether it's before or after i zoom in, but I scribble on the image with the pencil tool after zooming in, and afterwards, these messages are there. I take it as a strong suggestion that the tile pyramid code is still a bit dodgy. I plan to retry with '--error-limit=no' as it suggests, later, but perhaps these results will be helpful (I don't fully understand them myself yet -- eg. I only just figured out that the highest item on the stack is the first result.). A complete dump of the results is attached as a gzipped .txt, 5k. valgrind output follows: ==14080== ==14080== Conditional jump or move depends on uninitialised value(s) ==14080==at 0x82CC819: tile_pyramid_validate_tile (tile-pyramid.c:482) ==14080==by 0x82CAF56: tile_manager_validate (tile-manager.c:284) ==14080==by 0x82CA0A3: tile_lock (tile.c:162) ==14080==by 0x82CACFD: tile_manager_get (tile-manager.c:250) ==14080==by 0x82CC5AD: tile_pyramid_validate_tile (tile-pyramid.c:382) ==14080==by 0x82CAF56: tile_manager_validate (tile-manager.c:284) ==14080==by 0x82CA0A3: tile_lock (tile.c:162) ==14080==by 0x82CACFD: tile_manager_get (tile-manager.c:250) ==14080==by 0x82CC5AD: tile_pyramid_validate_tile (tile-pyramid.c:382) ==14080==by 0x82CAF56: tile_manager_validate (tile-manager.c:284) ==14080==by 0x82CA0A3: tile_lock (tile.c:162) ==14080==by 0x82CACFD: tile_manager_get (tile-manager.c:250) ==14080== ==14080== Conditional jump or move depends on uninitialised value(s) ==14080==at 0x8226FD3: gimp_drawable_get_sub_preview (gimpdrawable-preview.c:415) ==14080==by 0x822737C: gimp_drawable_preview_private (gimpdrawable-preview.c:205) ==14080==by 0x8227457: gimp_drawable_get_preview (gimpdrawable-preview.c:84) ==14080==by 0x82769A0: gimp_viewable_get_new_preview (gimpviewable.c:737) ==14080==by 0x81809E4: gimp_view_renderer_drawable_render (gimpviewrendererdrawable.c:178) ==14080==by 0x817F1E6: gimp_view_renderer_real_draw (gimpviewrenderer.c:716) ==14080==by 0x817F4C5: gimp_view_renderer_draw (gimpviewrenderer.c:606) ==14080==by 0x41EC289: gtk_cell_renderer_render (gtkcellrenderer.c:563) ==14080==by 0x43E5FAD: gtk_tree_view_column_cell_process_action (gtktreeviewcolumn.c:2796) ==14080==by 0x43E6828: _gtk_tree_view_column_cell_render (gtktreeviewcolumn.c:3129) ==14080==by 0x43D2522: gtk_tree_view_expose (gtktreeview.c:4617) ==14080==by 0x42C66D3: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) ==14080== ==14080== Use of uninitialised value of size 4 ==14080==at 0x817EBAF: gimp_view_render_to_buffer (gimpviewrenderer.c:1077) ==14080==by 0x817ECB5: gimp_view_renderer_render_buffer (gimpviewrenderer.c:930) ==14080==by 0x8180961: gimp_view_renderer_drawable_render (gimpviewrendererdrawable.c:213) ==14080==by 0x817F1E6: gimp_view_renderer_real_draw (gimpviewrenderer.c:716) ==14080==by 0x817F4C5: gimp_view_renderer_draw (gimpviewrenderer.c:606) ==14080==by 0x41EC289: gtk_cell_renderer_render (gtkcellrenderer.c:563) ==14080==by 0x43E5FAD: gtk_tree_view_column_cell_process_action (gtktreeviewcolumn.c:2796) ==14080==by 0x43E6828: _gtk_tree_view_column_cell_render (gtktreeviewcolumn.c:3129) ==14080==by 0x43D2522: gtk_tree_view_expose (gtktreeview.c:4617) ==14080==by 0x42C66D3: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) ==14080==by 0x46CA8EE: g_type_class_meta_marshal (gclosure.c:567) ==14080==by 0x46CAF1E: g_closure_invoke (gclosure.c:490) ==14080== ==14080== Use of uninitialised value of size 4 ==14080==at 0x817EBCA: gimp_view_render_to_buffer (gimpviewrenderer.c:1079) ==14080==by 0x817ECB5: gimp_view_renderer_render_buffer (gimpviewrenderer.c:930) ==14080==by 0x8180961: gimp_view_renderer_drawable_render (gimpviewrendererdrawable.c:213) ==14080==by 0x817F1E6: gimp_view_renderer_real_draw (gimpviewrenderer.c:716) ==14080==by 0x817F4C5: gimp_view_renderer_draw (gimpviewrenderer.c:606) ==14080==by 0x41EC289: gtk_cell_renderer_render (gtkcellrenderer.c:563) ==14080==by 0x43E5FAD: gtk_tree_view_column_cell_process_action (gtktreeviewcolumn.c:2796) ==14080==by 0x43E6828: _gtk_tree_view_column_cell_render (gtktreeviewcolumn.c:3129) ==14080==by 0x43D2522: gtk_tree_view_expose (gtktreeview.c:4617) ==14080==by 0x42C66D3: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) ==14080==by 0x46CA8EE: g_type_class_meta_marshal (gclosure.c:567) ==14080==by 0x46CAF1E: g_closure_invoke (gclosure.c:490) ==14080== ==14080== Use of uninitialised value of size 4 ==14080==at 0x817EBE5: gimp_view_render_to_buffer (gimpviewrenderer.c:1081) ==14080==by 0x817ECB5: gimp_view_renderer_render_buffer
Re: [Gimp-developer] Doing an action for each color in an indexed color-palette
On 6/27/07, Roberto Uhlig [EMAIL PROTECTED] wrote: Hello, has/knows anyone a script/plugin (an idea) to go color by color through an indexed color-palette and doing an action for each color? I d like to create from a picture with an optimized color-palette with ca. 5-10 (may be 1-256) colors new layers or new pictures for each color in palette. Layer(s) or pictures must have the same extensions like the original picture. The new picture must be a black and white (1-bit) palette binary tiff for using in geo information systems as visible and invisible. I do have an idea: 1. set the image's colormap to a grayscale gradient, where the intensity matches the index (eg. at index 0, #00, at index 9, #090909..) 2. copy that for each indice in the palette: 3. paste it as a new greyscale image 4. use the threshold function with (indice, indice) as it's range parameters 5. indexize to monochrome 6. save that image 7. delete the image from memory. loop... That can be completely automated by scripting ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few simple patches
On 6/27/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Tue, 2007-06-26 at 12:50 +0200, [EMAIL PROTECTED] wrote: Unless what he's implemented is bad why not just comit anyway until you get around to doing it better/diffeently? I rejected the patch for several reasons, all of them technical: (1) It adds a label for a potentially long string without taking any measure to avoid that the dialog gets too wide due to that. Okay (I don't know how to ellipsize a string in GTK, though of course I know how to truncate or ellipsize the content of it) (2) It mixes filenames with strings displayed in the GUI. Filenames can be of a different encoding and therefore need special treatment. In particular you must not call g_path_get_dirname() on the result of file_utils_uri_display_name(). So the filename should be recoded to ascii and then finally back to UTF-8? (IIRC URI's are encoded in UTF-8.) (3) Showing a directory name does only work for local files, it breaks for remote files. This is incorrect, I checked for that case and it shows what I believe to be the correct parallel to 'directory name': for 'http://foo.bar/baz/bif.gif' it shows 'http://foo.bar/baz/' (the only other parallel I could see making sense would be /baz/ -- which strikes me as not-very-helpful.) Sorry, but I couldn't accept the patches for the reasons given above. And now I have even put more time into this than it has taken David to come up with the patches in the first place. As a general rule, please ask before you write a patch. Okay, I will. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] A few simple patches
filepath.diff adds a 'file path' field to the 'Image Properties'
dialog; I did this after some discussion between gg and myself on the
importance of being able to find out the path easily.
Image_metadata.diff changes the title used by the 'metadata' plugin
for its window. Mainly, it's just so that there are not two different
dialogs both titled 'Image Properties' available.
Maybe the title should be 'File Properties' instead -- but, IMV, this
is ambiguous VS 'Image properties' -- 'metadata' is the more correct
term.
Neither of these patches seem controversial (although they do effect
translations), which is why I posted them here instead of on Bugzilla.
I hope that the ML software doesn't strip off these attachments :)
Index: plug-ins/metadata/interface.c
===
--- plug-ins/metadata/interface.c (revision 22834)
+++ plug-ins/metadata/interface.c (working copy)
@@ -653,7 +653,7 @@
gimp_ui_init (PLUG_IN_BINARY, FALSE);
- mgui.dlg = gimp_dialog_new (_(Image Properties), PLUG_IN_BINARY,
+ mgui.dlg = gimp_dialog_new (_(Image Metadata), PLUG_IN_BINARY,
NULL, 0,
gimp_standard_help_func, EDITOR_PROC,
Index: app/widgets/gimpimagepropview.c
===
--- app/widgets/gimpimagepropview.c (revision 22834)
+++ app/widgets/gimpimagepropview.c (working copy)
@@ -134,6 +134,9 @@
view-filename_label =
gimp_image_prop_view_add_label (table, row++, _(File Name:));
+ view-filepath_label =
+gimp_image_prop_view_add_label (table, row++, _(File Path:));
+
view-filesize_label =
gimp_image_prop_view_add_label (table, row++, _(File Size:));
@@ -329,6 +332,27 @@
}
static void
+gimp_image_prop_view_label_set_filepath (GtkWidget *label,
+ GimpImage *image)
+{
+ const gchar *uri = gimp_object_get_name (GIMP_OBJECT (image));
+
+ if (uri)
+{
+ gchar *name = file_utils_uri_display_name (uri);
+ gchar *path = g_path_get_dirname (name);
+
+ gtk_label_set_text (GTK_LABEL (label), path);
+ g_free (path);
+}
+ else
+{
+ gtk_label_set_text (GTK_LABEL (label), NULL);
+}
+}
+
+
+static void
gimp_image_prop_view_label_set_filesize (GtkWidget *label,
GimpImage *image)
{
@@ -424,6 +448,7 @@
gdoubleunit_factor;
gint unit_digits;
const gchar *desc;
+ const gchar *path;
gchar format_buf[32];
gchar buf[256];
@@ -515,9 +540,13 @@
/* filename */
gimp_image_prop_view_label_set_filename (view-filename_label, image);
+ /* file path */
+ gimp_image_prop_view_label_set_filepath (view-filepath_label, image);
+
/* filesize */
gimp_image_prop_view_label_set_filesize (view-filesize_label, image);
+
/* filetype */
gimp_image_prop_view_label_set_filetype (view-filetype_label, image);
}
Index: app/widgets/gimpimagepropview.h
===
--- app/widgets/gimpimagepropview.h (revision 22834)
+++ app/widgets/gimpimagepropview.h (working copy)
@@ -47,6 +47,7 @@
GtkWidget *resolution_label;
GtkWidget *colorspace_label;
GtkWidget *filename_label;
+ GtkWidget *filepath_label;
GtkWidget *filesize_label;
GtkWidget *filetype_label;
GtkWidget *memsize_label;
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL is no longer vapor. (was: improving image scale: reduction)
On 6/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote:
modifying that code base to deal with this properly will most probably
been seen as more lasting contributions than changing code that
eventually only will live on machines running legacy 2.4 series GIMP
due either to low performance hardware
hmm, just reread this. Does that comment indicate that GEGL is a lot more
resource hungry than gimp? I'd wondered if that might the case when I
initially looked at the way it was structured.
I thought it was fairly clear that Øyvind mainly meant CPU power
('low performance' -- RAM would correspond to 'low capacity').
Currently, my impression from using GEGL is:
a) it wants more memory for an equivalent layer-arrangement
b) it wants to use less memory at a time
relative to GIMP. a) because of the way that layers are composited of
multiple GEGL ops, and b) because of caching -- if a graph node is not
dirty, then it doesn't need to be recalculated from it's child nodes*.
So it uses more memory during calculation, and less memory during
editing (depending on the dependencies of the node you're editing).
*the caching system is still under development, as far as I can tell;
final caching behaviour is not determined except in that it will be
something like i described.
Per the above, it seems to me clear that GEGL will be more usable on
systems with low memory and lots of swap space VS the GIMP's current
infrastructure, with efficiency while editing varying more (initially
with all ops written in C, individual op speed will be less but
caching will tend to speed up editing past GIMP speeds.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Building imagemap plugin requires flex?
On 6/7/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2007-06-07 at 13:10 +0930, David Gowers wrote: Well, only if the source dependency for the various lexers has changed (eg. recently with the The GIMP - GIMP global replacement). A rebuilt version of the relevant generated files should probably also be updated into SVN before release. As far as I can see, updated versions of the generated files have been committed to SVN. What exactly is your problem? Don't know. I just did the standard './autogen.sh;make' after running 'svn update' and make eventually crashed with the mentioned messages. I hadn't modified any files and as far as the server could tell me, my copy was up to date. (I've checked this again, just now, and no relevant files were updated) Maybe it's an obscure bug in Subversion (my client is v1.3.1); In any case, I *DID* require flex 2.5.33 in order for the 'make' command to successfully complete. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Building imagemap plugin requires flex?
On 6/8/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2007-06-07 at 19:31 +0930, David Gowers wrote: As far as I can see, updated versions of the generated files have been committed to SVN. What exactly is your problem? Don't know. I just did the standard './autogen.sh;make' after running 'svn update' and make eventually crashed with the mentioned messages. Well, you didn't mention the message yet. That's why I asked you to describe the problem in more detail. Sven Something has gone badly wrong. I did quote them.. I may have even quoted them twice. I don't have a copy of the errors saved, but this is what happened roughly: 1. 'make' runs. Eventually it reaches the imagemap plugin directory. 2. imap_csim.l is used to generate imap_csim_(parse|lex).[ch] with flex. 3. Either imap_csim_parse.c or imap_csim_lex.c is complained about by the compiler: stdout:1839: warning: no previous prototype for 'csim_get_lineno' stdout:1848: warning: no previous prototype for 'csim_get_in' stdout:1856: warning: no previous prototype for 'csim_get_out' stdout:1864: warning: no previous prototype for 'csim_get_leng' stdout:1873: warning: no previous prototype for 'csim_get_text' stdout:1882: warning: no previous prototype for 'csim_set_lineno' stdout:1894: warning: no previous prototype for 'csim_set_in' stdout:1899: warning: no previous prototype for 'csim_set_out' stdout:1904: warning: no previous prototype for 'csim_get_debug' stdout:1909: warning: no previous prototype for 'csim_set_debug' stdout:1943: warning: no previous prototype for 'csim_lex_destroy' stdout:1347: warning: 'yyunput' defined but not used (In fact, these messages still occur even when building proceeds successfully. By themselves they are probably not significant.) Similar messages also appear for imap_cern 4. Compilation continues. At link time, the linker complains of unresolved references to symbols, which all are csim_* functions. I cannot reproduce this #4 any more, not even if I downgrade flex to 2.5.31. It just happily links. Maybe the version of flex provided by synaptic was glitched. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image indexed mode, major hole
On 6/7/07, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Sven Neumann One cannot do this, in general, because an indexed PNG stores a single alpha value for each palette entry. An image with an unrestricted alpha channel would most likely lead to more color/alpha combinations than the 256 palette slots available in PNG. But it's more likely that we will soon drop indexed mode completely and push handling of indexed color to the load and save plug-ins. I can see good software-engineering reasons to want to eliminate indexed representation internally, but from a usability standpoint it will be a loss not to be able to restrict the possible color values to a predetermined palette. That is not implied by 'push handling of indexed color to the load and save plug-ins'. Indeed, it would be rather easy to attach data dictating what colormap to indexize to, what parameters (eg dithering) to use.., via a parasite, and have indexed savers use that data. Imagine finding out only after several hours of editing that some of the pixels you intended to be (255,192,53) accidentally became (255,192,54), and others became (255,188,53) and a few of the (64,64,0) became (64,64,3), and this is a source of immense confusion to software later your build process, which recognizes exactly those colors to have a special meaning, and now you have to go through a few dozen layers to find all of the misfit pixels and correct their color one layer and color at a time. Indexed editing prevents making the mistake in the first place; if I have not explicitly added (255,192,54) to the palette I know that I'll not risk finding it in the output. Although I understand the problem posed by the above type of cumulative error - For example it can be easily caused by accidentally bumping drawing opacity down to 99 instead of 100, and with enough cumulative error it might quantize to an unintended color, not the color you meant to draw with... I believe the solution to that is to allow the user to quantize their image to an indexed palette at any time -- indeed, having such a quantization as a toggleable display filter would be abundantly useful. Note that this is a separate issue from indexization -- quantization only refers to dictating what colors are in the output, not the manner in which they are stored. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Building imagemap plugin requires flex?
Well, only if the source dependency for the various lexers has changed (eg. recently with the The GIMP - GIMP global replacement). A rebuilt version of the relevant generated files should probably also be updated into SVN before release. Currently, flex version 2.5.33 or higher seems to be required to successfully generate the needed files. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK palette info from Photoshop
On 4/1/07, Chris Mohler [EMAIL PROTECTED] wrote: On 3/31/07, Hal V. Engel [EMAIL PROTECTED] wrote: You might consider using a color transform using ICC profiles. For example you could use sRGB as your generic destination color space and perhaps a SWAP profile for the CMYK side. Once you have selected your two profiles doing the conversion is almost trivial using calls to lcms. Hal, Could you point me to an example? I see some functions in plug-ins/lcms, but have not figured out how to use them. Most seem to operate on drawables - I want to push CMYK number values into RGB. Chris, The lcms plugin is a different thing from the lcms library; GIMP's lcms plugin just provides an interface to the lcms library ( http://www.littlecms.com/) Try looking in the plugin to see how the plugin accesses LCMS, not to find out what functions the plugin provides. IIRC it basically just needs to know the input and output profiles, and be provided pointers to source and destination buffers. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory manage in python-fu
I am hereforth asking you to apologise, if possible, both in private and on the list for this message. We are runing a project needing I cannot sincerely do so, in this instance. I do not apologize for expressing my amusement, unless I judge that the situation was genuinely worsened by my behaviour. It's certainly true that my message can be misinterpreted -- on the net, it's probably wisest to just assume no hidden meanings -- if it looks like a fish, assume it is a fish (and nothing more). much of new developers and contributors, and are in no position of theating anyone like this. Please perceive I am no police - I am asking this personally, but I also have promised the people organizing the LGM I'd tlak to gimp developers to try to make the enviroment more frindly to newcomers. In my observation, friendly sometimes is not polite -- for instance, answering as I did rather than giving a detached commentary free of any emotional context at all. This is why I view the way I replied as better (and certainly more friendly) than most previous mails of mine on this list. (btw, having to explicitely delete a python object __is__ a bug - objects that are seeing in python should be garbage collected when they are no longer referecenced. ) I avoided commenting on that because it wasn't clear whether they actually were no longer referenced. I certainly agree that there is something wrong with the gimp.delete convention here -- it only behaves how I'd expect sometimes. I'd definitely like to see more PyGimp developers myself -- hardly anyone seems to make as extensive use of it as I do. Perhaps a standard module path for pygimp plugins could be worked out (arguably, the PDB removes this need, but the PDB is cranky to use compared to Python modules) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory manage in python-fu
On 3/12/07, D. Stimits [EMAIL PROTECTED] wrote: I have not found any python-fu way to close a file, or to reclaim memory after creating an image or layer. Is there such a thing? Is there instead some sort of garbage collection? hahahaha! gimp.delete(image) or gimp.delete(layer) #only do this if the layer isn't attached to an image. If it is attached to an image, then deleting the image will delete all the layers and other things -- no need to delete them directly. This *is* in the pygimp documentation (plug-ins/pygimp/doc/pygimp.html in the source tree)! RTFM! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] transformation drift [was: preview window does not work]
On 3/8/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, If you rotate by exactly 90 degrees, this is always done with INTERPOLATION_NONE, no matter what you select in the tool options. Perhaps this is the culprit? An offset seems unavoidable if the transformation is performed without interpolation. So perhaps all we need to do is to remove this optimization (which is supposed to speed up rotations by multiple of 90 degrees)? BTW, do you think the rotation centre should be snapped to 0.5 pixel increments when interpolation is NONE? It doesn't make sense to have any more precision at that point (and can introduce glitches -- for instance, try floating a rectangular region, then dragging the rotation centre to the top left as precisely as you can, setting it to rotate 90 degrees, and performing the rotation... -- compared to inputting the coordinates of the top left yourself and then performing the 90 degree rotation. In the first case, even fractional imprecision means the result is not even in the right place.) Anyway, in the case of a 90 degree rotation, it seems unlikely that the user would want it misaligned with the pixels -- in which case no interpolation is needed and the result should be exactly right. Simple test case that uniformly fails, currently: * Select a rectangular region of the picture. * Float it * Rotate it. Set the rotation centre to the exact top left (by first positioning the centre near it, then editing the coordinates in the rotation dialog to make them exact). Set the angle to 90 degrees and the interpolation to NONE. Supersampling option appears to have no effect in this case. * The result may be offset by 1 pixel in X and/or Y axis; It is also missing one line of pixels (which line is omitted varies.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 2/24/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: to be used (1x, 2x, 3x, 5x, etc.). It doesn't soom to differ significantly from existing Navigation window It does! Navigation window provides a zoomed out view of the entire image -- this provides a zoomed in view of the area that the cursor is in. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using layer/channel as mask
On 1/23/07, Kevin Galligan [EMAIL PROTECTED] wrote: I've been trying to script something that seems relatively simple, yet I've spent the better part of today stuck at one little step. I have started naming things with curse words, so I figured I'd reach out for help before I start throwing things. Sounds familiar .. although that's happened much less to me since I started using Python-Fu instead of Script-Fu. I have a layer that I want to serve as the mask for another layer. The values in the mask layer are white, so in theory, I could do the following... ;Somehow get the green Channel of the mask layer (set! greenChannelMask [magicFunctionHere]) (gimp-layer-add-mask myLayer greenChannelMask) I'm sure there's a more elegant way of doing it. If so, please let me know. However, if the above would work, I just need to know how to get that channel. Should be easy, but I have been beating my head agaist a wall. I just can't get it. I tried 'gimp-image-get-channels' in the console just to see if I could do it the hard way, but it always returns '(0 #()#0)', no matter what image, which leads me to believe I don't understand how that function works. I also tried 'gimp-image-get-active-channel' in The function returns a list of channels. ie. What you see in the bottom part of the Channels dialog. Anyway, you don't really need to get the green values, just get the intensity. The way to do this is: * Copy the mask layer (as in gimp-edit-copy -- or gimp-edit-named-copy if you want to preserve the clipboard) * Add a mask to the target layer *if needed* * Paste onto the mask * Anchor the console, but that comes back with -1. All the time. I probably wouldn't be so frustrated if this was a big deal, but should be easy to get the channel, yet I've burned much of the day and have made no other progress (other than, of course, having nowhere else to look). Thanks in advance, -Kevin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
