Re: [Gimp-developer] Plug-in problem
What platform are you on? I presume a form of Windows given that you have a task manager, but what version? Lourens Ronald Cornelissen wrote: L.S., When I open a dialog box wich involves plug-ins (i.e. Xtns Plugin Details... or when I try to save a picture) the box pops up, but stays blank. When I wait, it stays the same for a very long time, after which I had to use the task manager to close the dialog box. Can you tell me what the problem is and what I can do about it? Thanks in advance. With kind regards, Ronald Cornelissen. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [GIMPI] Unwanted blurring Side-effect
I tried it, and it looks very wrong indeed. Try creating the circle, then blurring at 48x48, then using treshold. The circle has changed into a weird shape. I took a look at the gaussian blur plugin but was unable to positively identify a bug. I do however have an idea as to what might be happening: gimp only takes pixels into account within a rectangle enclosing the selection. Pixels inside the rectangle but outside the selection are taken into account as if they have a colour of 128, 128, 128, pixels outside the rectangle are not counted at all. Therefor, if you consider a pixel at the top of the circle, the gaussian blur is calculated by taking into account the white pixels inside the circle, and a few grey ones that are outside the circle but inside the bounding rectangle. Compare this to a pixel on the edge at 45 degrees along the circle, now we take into account the same amount of white pixels from the inside of the circle (the gaussian filter is circular so it's the overlapping area is equally large), but many more grey pixels inside the bounding box but outside the circle, resulting in a darker colour. A solution if this turns out to be the case would be to enlarge the bounding rectangle on all sides by the blur radius, or to simply count pixels outside the bounding box as 128, 128, 128 as well. I've CC'd this mail to the gimp-developer mailinglist, hopefully the maintainer of the plugin or one of the Gimp developers can shed a light on this. I'll send a summary of the replies on gimp-developer to GimpI to keep everybody informed. Lourens Andrew J Fortune wrote: Hi all, Try the following : (1) Create a new image with a black background; (2) Draw a circle from the center and fill with white; (3) Leave the circular selection on; (4) Gaussian Blur IIR, using 48x48; (5) Repeat blur with 24x24; (6) Repeat blur with 12x12. The result is that you get a nasty side-effect. Instead of blurring evenly (radially), it leaves a bump on the top, bottom, left and right extremities of the white circle (see attached). What is causing this, and how can it be rectified ? regards, Andrew ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Blur bug
Hmm, this post seems to have turned into a big mess. It was late...Anyway, please respond to this one, as the others have the reply-to set wrongly. For the record, I'm referring to http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg00359.html Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Bucket fill, Fill with foreground and gradient
Ok, first idea for poll: -Do you use the bucket-fill 1. All the time 2. I normally use fill with foreground/background-color 3. Only to fill with pattern. 4. What is bucket fill? Ralf Hmm, I use the bucket fill all the time, both for patterns and filling selections. If I want to fill a region with a similar colour with another one I usually select it with the magic wand and then bucket fill. It's easier to see how far you'll get that way. As far as I'm concerned the threshold can disappear, making it default to always fill the entire selection (or the entire image if there is no selection). Magic wand can do the selecting. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] JPEG comment in existing files
Peter wrote: I found how to change the comment in a JPEG when I save as, and how to change the default for the save as, but I could not find how to view the comment in an input file or edit the comment prior to performing a normal save. I think this is built in the save routines, I don't think there is a separate comment attached to an image. It sounds like a useful feature to me though. I found how to change the compression level in a JPEG when I save as but could not find out how to view or change the compression level prior to a normal save. I think, from what I see of the JPEG format, the compression level is not stored anywhere but it could be indicated by displaying something like the colour range (I do not remember the JPEG term, it is the part that indicates the 24,000,000 colours are squashed down to an actual range of n colours. There is no such thing. Indeed, JPEG uses vector quantisation, but it's a little bit more complicated than just making a palette. The encoder has a q factor (ranging from 0.0 to 1.0 in Gimp) which determines the quality, but other than that 0.0 is worst and 1.0 is best, it's undefined and may vary in meaning from encoder to encoder. I think that if you Save As with a certain q factor, and the save the same file again with Save, you get the same q factor again. If you want to save with a different q factor, use Save As. I also could not find out how to change the default JPEG quality setting from .75 to 1 and only discovered the setting when I found a few files were damaged after minor adjustments. damaged. You mean they were saved at a lower quality? Please note that a q factor of 1 does not mean lossless compression. There is indeed a lossless JPEG mode, which is prediction based and totally different from the lossy DCT and vector quantisation scheme that is used in Gimp. AFAIK Gimp cannot save lossless JPG's. If you want to save your files losslessly then I recommend PNG, it has good compression, is an open standard and works with web browsers. Which leads to the next thing. If I start with a JPEG that has zero compression then edit the file then save as a jpeg with 25% compression, I see the change image from editing but not after compression. Is it possible to view the file as saved to disk, without having to close the file then open the saved file? Yes, when you save it there is checkbox preview in image window. Make sure it's checked, and watch the image window. Note that a q factor of 0.75 does not mean 75% filesize or 75% of the quality. It is a meaningless number. I am looking forward to replacing some more proprietary software with open source and Gimp is 98% of what I need for image editing. Good! Feel free to ask. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Bucket fill, Fill with foreground and gradient
Sven Neumann wrote: Hi, this sounds reasonable to me. On the other hand, this would render the bucket fill tool almost useless since you can do the color and pattern fill much easier using DND. The sole advantage of the Bucket Fill tools is the threshold functionality and the fact that the possibility to fill using DND is not obvious. I feel that that last one is a problem. The GUI needs to be consistent. Why not stick to three basic things: tools, filters, and scripts. The tools should all be in the Gimp main window as buttons (or maybe only partially in beginner mode if we do the config/skin thing, sounds good to me btw, ICQ has it too for example), and the filters should be in Image-Filters, scripts would go into Image-Scripts. These should then be subdivided into logical groups, from the user side, not from the programmer side. The user doesn't care if a script was written in Perl or in Scheme, he cares about what it does to his image. The unobvious things can stay, but please, keep them as hidden functionality for power users, not as the only possible way to do it. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI comment from an NT user
Peter wrote: Can GIMP be started with all the windows grouped the way I want? It simply reloads the previous configuration on Linux. But I don't know about the Windows version. That way, when I am in GIMP, the whole screen is working the Gimp way, and when I am in Word, the whole screen is working the Word way. Last time I used Gimp and tried to resize a window, I ended up in the Word document (which was underneath Gimp) and had to undo a text move, as the mouse movement had translated to moving text. Basically, Windows is lacking workspaces. I don't know if MacOS has them, but my Linux desktop has 16 workspaces (separate screens). So if I open up all the Gimp windows on workspace 1, and I want to open a second program which also has a few windows, then I simply switch to another workspace and open the second program there. Go back to workspace 1 and all Gimp windows are there as they were. It seems that the problem is that Linux desktops (at least UNIX-style ones, KDE is a lot more like Windows) like GNOME and Windowmaker differ from Windows desktops. I prefer the UNIX desktop by far, since it allows me much more freedom and thus increases productivity. But Linux programs fit in with Linux desktops, and thus they don't fit in with Windows. I think putting everything into a main window in Windows isn't a bad idea. It could even have the right-click menu _also_ at the top of the main window so that users of other programs can easily find it. 2c.. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Kelly Martin wrote: [snip] If GTK stable release (1.2) is not acceptable for further development in the GIMP (which it probably is not), I would strongly urge picking a relatively stable snapshot of GTK+ current development (possibly, but not necessarily HEAD today) and use that. We might have to adjust later to any changes GTK+ makes to its HEAD after that snapshot, but at least we won't have to adjust to them willy-nilly as they make them. Kelly Sorry for jumping into this discussion in the middle, but I happen to have an opinion on this :). What about all the bugs in the chosen snapshot? I mean they get ironed out during the GTK+ development, but the Gimp developers are stuck with them during development. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Alright, this is turning into a flamewar and that's the least productive of all. Let me try to wrap up this discussion: The question: Will the gimp-1.3 developer releases depend on Gtk-1.3 HEAD CVS, or do we make certain every gimp-1.3.x release compiles with gtk-1.3.y? Arguments for depending on HEAD: - The Gtk-1.3 API is frozen, so using the latest won't break anything, it will only be better code - These releases are for developers only, normal users don't need to have anything to do with CVS. - Gtk will be tested well prior to release, avoiding the possible need of major changes after release of Gtk-2.0. Arguments against depending on HEAD, and just using the latest Gtk-1.3.y release to work with: - Gtk HEAD may not always compile, making it difficult for users to try out the development releases in the gimp-1.3 branch - If there are major advantages of CVS HEAD over the latest development release they will probably do a new release anyway, and besides, this is unlikely as Gtk-2.0 is late in its development cycle already. I might have missed one or two arguments, apologies in advance if that's the case. I think we need to ask ourselves why users would want to try the latest developer releases of Gimp. If they want to have the latest because of having the latest, I don't think they'll mind getting CVS HEAD branches and weeding out possible compile problems. But I think for gimp-1.1 there was a different reason. Gimp-1.1 had a whole lot of features that weren't in gimp-1.0. In fact, to me (as a user) Gimp-1.1 was a good graphics program, while Gimp-1.0 was hopelessly limited. So my question is, will Gimp-1.3/2.0, in the early stages of development, add much functionality? It seems to me it won't be an advantage, as for now it's basically the functionality of gimp-1.2 with a whole new implementation. But if there are no functional advantages the average user will be happy to keep using 1.2 for a while (I know I will at least). So in that case, it doesn't really matter, as long as the developers are happy. Once gimp-1.3 actually starts being a useable graphics package with more features than gimp-1.2 I think we need to worry about users being able to compile things easily, and I do believe simply depending on a fixed Gtk-version (which will then probably be at 2.0.x anyway) is a part of that. As for pango and atk, if I understand correctly they are simply part of Gtk-2.0, or at least standard companions to it. In that case why not use them? I'm sure there are gimp-users in Israel who'd like a Hebrew translation, and if that work is done already by the pango developers, why not make use of it? With Gtk-2.0, people will have it anyway. The same goes for atk. Please, try hitting the ball and not your opponent. It's not a nice thing to do, and given that your opponent is on your own team, pretty stupid as well. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Kelly Martin wrote: Think plugin authors. These people are going to want to start working on porting their plugins to 2.0 well in advance of 2.0's release but are not likely to want to cope with being GTK debuggers on top of being GIMP debuggers. Kelly I may be misunderstanding, I'm not a project expert, but if the Gtk API is frozen, the only difference between the CVS HEAD branch and the latest developer release is bugfixes right? So then there should be actually less bugs in the CVS HEAD. The only risk you are running is of it not being compilable, well, as we saw today, that might happen with a release as well ;). In the end it's a matter of trusting the Gtk developers, or rather the CVS maintainers. Do we trust them not to break things too often, and if the compile is broken, fix it quickly. I have no experience with the Gtk CVS, so I can't say anything about it. Maybe we should ask them? Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Stephen Robert Norris wrote: Yes, this is a way the application can avoid the problem; it's not a way the library can. My point was that it's impossible with modern OS's to avoid the possibility of the library crashing. Ah, we agree then, that was the point I was trying to make as well :). Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Stephen Robert Norris wrote: I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets the mutex, then calls the library with a pointer to some part of the shared memory. Make sure thread 2 checks the mutex before unmapping and there's no problem at all. Thing is, how is the library going to know whether the pointer is valid or not? All the standard C functions that expect pointers will happily write wherever you point them to, even if it causes a segfault. I don't see how this is a problem with the library. If I divide by zero (which is essentially calling the divide function with illegal values) I get an exception as well. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On Tuesday 27 November 2001 02:18, Branko Collin wrote: snip 3. A page on the GIMP site should be dedicated to the topic of How to transition from Photoshop to the GIMP successfully. The community would be a lot larger if more people realized that 'you get what you pay for' is a false statement; get professional artists interested in GIMP and the development potential would skyrocket. Once professionals depend on GIMP, then we may even see some corporate funding for making GIMP do all the things that need to be done: CMYK, serious halftoning, and easy font work come to mind, but that's just the tip of the iceberg. I thought you were working on such a tutorial? Has anyone looked at any Photoshop books? I use Gimp at home under Linux, and yesterday I happened to find myself at a Mac with Photoshop. The experience reminded me of my first days with Gimp. So how did all those Photoshop users learn how to control the program? How about getting a popular Photoshop book and copying the structure, but using Gimp instead? Having said that, I think the tutorials and the manual are pretty good, it's just not that easy to find them. I like the idea of having the website be an extension of the UI, however, do remember that not everybody has 24/7 web access, and needing a web link to look up some feature quickly is not yet a viable option I think. Last thingy, about professional use of Gimp, isn't this a bit of a chicken-and-egg thing? I can't imagine anyone using a program that doesn't do CMYK, serious halftoning and easy font work (with the added note that my X server crashes regularly on TrueType fonts rendered larger than 100 px or so) for professional print graphics. Having worked together with those professionals quite a bit lately I think Gimp needs to be quite a bit better still. snip The new gimp.org will in all probability have more sections for more parts of the community. So far, gimp.org has been the prototypical Corporate Website, the folder-on-the-net. Address and product information you can get, but if you want support, communities, downloads, what have you, you will have to look elsewhere. Gimp.org at least did one better than most other corporate sites by at least linking to all the elsewheres. Lastly, the mentality of we don't care if you use it, we develop GIMP for us is the keystone of exclusivity and elitism, There is nothing wrong with exclusivity and elitism per se... snip Maybe. I think that is your personal opinion. Me, I do it for my itch to be scratched and because it looks good on my portfolio and because I like the GIMP development community. In the end, you decide what is rewarding for you. I think the problem we have here is that there's quite a big difference between the developers and the users of the program. The people who make open source racing games probably do that because they like to play racing games as well. The average Gimp developer seems to do it because they like to write image manipulation software, things like writing filters and scripts and stuff, not necessarily because they like making digital art. The users of the program aren't very interested in the technology behind it all, they just want something to help them create their images. What I think the new website should do is explain to the programmers that doing something like this for your CV is nice, but nobody will be impressed if the program isn't used by anybody. And that the maintainers won't accept contributions that don't help the users in some way. On the other hand, the users should know that there are a bunch of developers who make it possible for them to use this great program, and that that's where they should go with feature requests and proposals for improvement of the program. Or in other words, these two groups of people, developers and users, should become one group of Gimp enthusiasts. I'd like to suggest a way to try and achieve this. About three years ago, game development company Lionhead (www.lionhead.com) started a discussion board on their website. There were different fora within the board, for different subjects. Amongst others there was a programming board and a board to discuss the (then upcoming) game BlackWhite. What happened was that the programmers, who normally aren't that gamesy, started posting on the BW board as well, discussing the game with the gamers, while the gamers ended up on the programming board with questions such as hey, seen this screenshot, how did they do that? and I'd like to start programming too! How?. Ofcourse there are mailinglists for developers and users, but these are more or less separate entities, just like the Gimp user community and the Gimp developer community are separate entities. Web boards are a bit more userfriendly than mailinglists (ie they are easier to grok for Jon Foo who just yesterday bought his new computer at
Re: [Gimp-developer] Professional use of Gimp (was: Developers and users (was: Bug week like thing for GIMP?))
On Tuesday 27 November 2001 13:10, Robert L Krawitz wrote: snip I can imagine professional use of a program without any of these things these days (the font stuff is most likely to be an issue). A lot of printers that get professional use have Mac/Windows drivers that take exclusively RGB data. A more serious issue is the lack of color matching, so that there's no guarantee that what shows on the screen will match what's on the page. Yes, but then we're still talking about printers here. The colour posters I designed were printed as well (on a digital press as they called it, which from what I gather is just an industrial strength printer), but that only goes up to A3, and the colours aren't that good (especially the orang bits came out a bit faded). All the other stuff my university printed for the anniversary was four-colour printed, which means CMYK. The website at http://www.bobs.co.uk/print/4colourProcess.html suggests that most stuff is CMYK too. Anyway, we're getting off-topic here. Perhaps I was wrong and CMYK isn't that important as you can always convert to it from RGB in Photoshop. But then you still need to have Photoshop. Colour matching is a problem anyway, because you'd need to tune your monitor as well. With xgamma and the gimp-print drivers I managed to match my monitor and printed output reasonably well, perhaps good enough for an amateur like me, but I guess a professional would like WYSIWYG colour-wise. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On Tuesday 27 November 2001 14:50, Seth Burgess wrote: snip Allow me to correct some impressions... Very little has happened recently in the way of scripts or filters; saying that gimp developers concentrate on that is ridiculous. Sorry, my bad. Jargon problem it seems. In Gimp, scripts and filters are Perl and Scheme programs that do things to the image via the Gimp API, which is not really what I meant. I'm no Gimp expert, but what I meant was the whole drawing engine part, ie memory management, brush strokes, layers, etc. Attached to it are the scripts and filters, and on top of that is the GUI, right? I think you seriously overestimate the amount of developers working on it. The few that do make regular contributions are more than swamped with their ambitious primary goal of making it cleaner and easier to hack. (Look through the ChangeLog for the past 12 months - only Mitch and Sven are at all regular contributors). Okay, so I misjudged the state of development Gimp is in. I remember trying to find out some time ago how hard it would be to contribute things to Gimp, but I gave up pretty soon. In another thread Rebecca Walter suggested creating a TODO for developers that want to help. I'd like to suggest they make a HOWTODO, because even if you want to help, you have this 15MB pile of source in front of you and not much of an idea of where to start. Some time ago I read the documentation that comes with GEGL, which is quite a lot of code too with a weird pseudo-language as an added bonus, but it's much easier to understand the structure of the code if you have a nice doc that explains what's what. Also, the fact is that the codebase has really outgrown the developer power to support it; it needs cleaning and restructuring so a developer can go in, see a sane structure in place, and change what needs to be changed easily. This is extremely dull work (for me anyway) and we're lucky we have a couple guys that love the program enough to put the huge amount of time into fixing it. Amen. This wasn't an attempt to put down Sven, Mitch or any of the other developers. I'm a computer science student and I can certainly appreciate the amount of work that's being put into Gimp. What I didn't realize was that Gimp isn't at all ready for new, user-oriented features at the moment. When they do get around to making user-centered choices, they tend to do a good job IMHO. But they are few, and thier task is large - its not all thats on their plate. And that the maintainers won't accept contributions that don't help the users in some way. Most of the work being done right now doesn't help the user one little bit, but should help developers make it easier to help users in the future. Putting a restriction like this in place would result in complete stagnation of the tree simply because nobody has the time to learn all the stuff needed to go in and hack right now. It makes difficult tasks impossible. You're right, this is nonsense. Some things won't happen for a while. For example, take CMYK support (or other colorspace support for that matter). To do this successfully requires an internal representation thats different throughout. A lot of work has been done towards this goal (changing spots to use GimpColor, or separating out colorspace operations from the UI for instance), but a lot remains as well. The idea is to hopefully get it into 2.0. At our current release cycle, thats probably 5 years out. Well if you use GEGL for 2.0 it shouldn't be hard as GEGL has been designed from the start with different colourspaces in mind. I like GEGL quite a lot actually, apart from the we don't need no C++ thing which I understand but disagree with. However, that discussion is closed, and let's keep it that way. snip - better fonts are coming up I think the current regular developers (both of them) as well as the occasional contributors are all doing great things for the program. They find time to respond to most feature requests submitted through gnome bugzilla. If you have specific, well thought out ways of progressing gimp along without radical change to everything, please do submit your feature request. Things do get implemented this way, and coders do pay attention. I have a few things in the back of my head (layer trees, a 4x4 matrix for every layer to encode transformations, etc.) but I think those are better suited for GEGL an Gimp 2.0. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On Wednesday 28 November 2001 15:17, Sven Neumann wrote: Hi, Lourens Veen [EMAIL PROTECTED] writes: Okay, so I misjudged the state of development Gimp is in. I remember trying to find out some time ago how hard it would be to contribute things to Gimp, but I gave up pretty soon. could you explain how you tried to find out? I can't really imagine what difficulties you had and it would be interesting to know. I browsed things for a bit, and I think I know the problem I had back then. I totally missed the devel-docs directory. *DOH*. I had a look around now (in the past 5 minutes, I'm in the middle of exams here) and it's pretty good. What I miss though is a rather high-level overview, something along the lines of Gimp consists of libgimp, which contains the drawing functions, gimpui, which is the user interface, . insert pretty diagram These are connected by . Having all the interface definitions is very good, but I think it would be handy if you could read how it's being used rather than how to use it. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] BW digital, compose w/weighted color channels?
On Monday 17 December 2001 20:18, [EMAIL PROTECTED] wrote: snip Is there some combination of existing functions that would let you re-compose an image as: 0% red, 50% green, 50% blue (i.e., a red-blocking filter) Is there some way to use blending of layers and opacity to do this? Or some other tools or scripts? Maybe this is more a question for gimp-user, but since it's here...It's possible, but a bit tricky. Here's what I can come up with (using your 0:50:50 example): Decompose the image into R, G and B images. For each channel image, add a greyscale layer, black for 0% for that channel, white for 100%, or anything in between. In your example, red would get a black layer on top while red and green would get 128,128,128-coloured layers. Set the layer mode on these new layers to multiply. Flatten the R, G and B images. Create a new image the size of the others, and add three layers, a red one (255, 0, 0), a green one (0, 255, 0) and a blue one (0, 0, 255). Set the layer mode to addition for the topmost two layers. Now add layer masks to each of the layers, and paste the corresponding channel image into the layer masks. In your example, this would give you 0*R + 0.5*G + 0.5*B, which is the image you're after. The only problem I can see is that you might run into rounding errors, 8 bits isn't that much accuracy, but given the simplicity of the operation I think you should be fine. I think this would also be easy to make into a script, but I'll leave that to someone else. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] BW digital, compose w/weighted color channels?
On Monday 17 December 2001 20:47, Lourens Veen wrote: snip - complicated stuff I just realised that you could just add a layer with colour (0, 255, 255) and put it in front of your image, then set its layer mode to multiply. Much easier. Brightness might be a problem though, make sure your highest percentage is always equal to 255 (so for 25%/75% you would do 85/255) and I think it should be ok. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Tools vs. Plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, With people talking on this list about plugin distribution and management again recently, I figured it'd be nice to have some document which is worked out a bit more than the ideas that have been thrown up so far. So I've started to make such a preliminary design for a plugin distribution system, however, I'm a bit stuck due to lack of knowledge on Gimp internals. So, to be somewhate less vague and more specific: What's the difference between a tool and a plugin, on the technical side? Is there any difference at all or is it all in the GUI? Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RH12vmNyqZHWDvURAl5zAKC2YvmfUcVt1Zo1TmpcNhMb92LPwwCdHVcB OgsZ6ONwR+PEgTsjjGI7aJ4= =qkDl -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tools vs. Plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 20:39, Sven Neumann wrote: Hi, snip if I'm informed correctly someone is already working on a plug-in manager but I'd like him to speak up here on himself. If you're reading this, yes, please do so. That'll save me another 10k of text :). So, to be somewhate less vague and more specific: What's the difference between a tool and a plugin, on the technical side? Is there any difference at all or is it all in the GUI? at least with the current design there is tremendous difference: a tool is just a function in the gimp core while a plug-in is a separate process. A tool can do just everything, a plug-in is limited to the libgimp API. Ah, right. So distributing tools through the plug-in manager is nonsense then. Thanks. Lourens PS: no need to CC, I'm on the list - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RIqOvmNyqZHWDvURAlJzAKCIAzXLYOqXeGUJY8Pe03DcNhJO5gCglN71 Sv5EsYnVVozUt76RWV48JSY= =K9jL -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tools vs. Plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 21:14, you wrote: Hi, snip I said with the current design. A plug-in manager should definitely be designed to also work for pluggable tools (Bex, how would I spell this correctly?) which is something we definitely want to have in the future. This brings the question back up: how is a plug-in different from a plugable tool? I'd say, a tool allows the user to do image manipulation directly on the image window. It needs a different (not yet existant) API to be able to do this. I agree. For me a tool is something that can be dragged across the image and leave a trail of changes, to put it very inprecisely. Oh, and my guess is plugable. Another nice question is: how is a script different from a plug-in? I tend to call perl scripts scripts while other people call them plug-ins. Anyway, a plug-in manager should be able to handle scripts as well. Let me quote from my unfinished and as-yet unpublished doc: To be able to design a plug-in distribution system, we need to know exactly what a plug-in is first. Currently, a plug-in in The GIMP is a small program, written in C, which is compiled at install time and loaded at GIMP startup. However, there are a number of other objects that are functionally similar, and from an end-user perspective could be regarded as identical. These are Tools, and Perl-fu and Script-fu scripts. I think it's silly that these technical differences are even visible in the GUI. I'm all for just sorting things based on function, not on their technical background. An exception would be tools, but then this too should be independent of technical implementation. I think it's strange that Colors-Curves is a tool, since it doesn't fit the above definition. It is, for technical reasons, but the end-user shouldn't need to concern herself with that. Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RJEbvmNyqZHWDvURAuNvAJ9GzNLEaH5j2FzZahr3Wjv1trMPZgCdHnqL x6dajEIsnOzXroZspth4Xuk= =6Yvo -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tools vs. Plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 17:44, Dave Neary wrote: Please, please, please try to get this right. When discussing GIMP, it is NEVER Gimp. It is NEVER plugin. GIMP has plug-ins. Surely The GIMP (or the GIMP) has plug-ins? :-) Must be THE GIMP then. I mean what other significant GIMPs are there? Lourens (greetings from the Dvorak-peninsula) - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RxfCvmNyqZHWDvURAsGuAKC5CJnd4G6rfPrSQGqEQ3ZWM7XcjACfV573 pboOM68s7JSFjYntT3ck8D8= =MasW -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib version question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 22 January 2002 21:10, Carol Spears wrote: what is a good, generic, quick way to find which version of glib you have installed on your computer? glib-config --version Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TcmRvmNyqZHWDvURAozUAJ9WkWQvv7VHbD8tpW/dFs4n3BkVBQCfcHbK VMh1VQEryLQzCAAtA56SNs0= =jhOJ -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Plug-in distribution system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've been working on a design document for a plug-in distribution system for The GIMP. I paid a visit to #gimp today to ask a question, and was told that yosh was working on plug-in management as well. I wanted to finish my document before publishing it, but in the light of others working on similar things I decided to publish the unfinished document, so that we can synchronise efforts and not waste time duplicating them. You can find what I have so far on http://home.student.utwente.nl/l.e.veen/gimp/ Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8V/iEvmNyqZHWDvURAsHnAJ9486Ks7zlIksZ+hgGmIH5XdaYXFACeJVD/ ScabSdGp8CQWcppV87HW9q0= =zgiN -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Menus, keybinding et al, first draft
On Saturday 16 February 2002 00:06, Guillermo S. Romero / Familia Romero wrote: Hi: This is the doc I have now. Any comments? Suggestions? Fixes? Well done! I still have some comments though, see below. snipped lots of stuff I think atm is fine Xtns Script-Fu Tools Default Colors D Swap Colors X --- Color PickerO Magnify Shift+M Measure Paint ... Selection ... TextT Transform MoveM Crop and Resize Shift+C Transform Shift+T FlipShift+F Image Transform Rotate 90 degrees Rotate 180 degrees Rotate 270 degrees --- Autocrop Guillotine Layers Transform Rotate 90 degrees Rotate 180 degrees Rotate 270 degrees --- Offset... Shift+Ctrl+O Zealous Crop Filters Show Last FilterCtrl+F Repeat Last Ctrl+R --- [Lots of things here] I think we need to think very hard about Plug-ins, Filters, Script-Fu, and Tools. I'd like to define a Tool as something that changes the image depending on the coordinates sent by the pointer device. This means that Flip and Transform (which always work on the whole image or the whole selection) aren't tools at all. Things like the Image-Color-* functions, which seem to be implemented as Tools in 1.2, aren't tools either. I'm not quite sure what to do with the remaining functions. I don't think the user should be able to see the difference between Plug-ins, Script-Fu scripts, and Perl scripts in the interface. That means that the Xtns-Script-Fu menu entry should go. Throwing them all in one big menu under Filters may be overkill though. I'm open to suggestions for splitting this up (in a way that is based on the function of the plugins) into smaller more manageable parts. Thirdly, we now have three different Transform options. I know that Unix gives you enough rope to shoot yourself in the foot, but with this you can't see the trees for the forest. Why not just a single transform tool, and an option there to do the whole image or just the current layer? Or better even, allow the selection of multiple layers in the layers dialog box, so that you can have finer-grained control over what you are changing and what not. Lastly, I think we should look at the names of the functions in relation to their locations in the menu. In GIMP 1.2, there is a function Image-Filters-Color-Map to Gradient..., which is rather confusing. Thing is, there's also an Image-Filters-Map submenu, and I always end up looking for Map to Gradient in the Map submenu. Function-wise I think this is a logical way to organise things, but linguistically it's confusing. Well, that's it for now. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Menus, keybinding et al, first draft
On Saturday 16 February 2002 06:59, Marco Lamberto wrote:
On Sat, 16 Feb 2002, Guillermo S. Romero / Familia Romero wrote:
Zoom In + [Yes, changed, a bit more logical, no?]
Zoom Out-
If you have an US keyboard you'll notice that while the minus - is
immediatly accessible, the plus + is obtained by pressing Shift + =. I
think that +/= it's a faster keybinding for an US-keyboard layout user.
What about of a bit nationalized keyboard layout, they should be selected
through the Options menu and NOT by using the locale, just because it's
possbile that someone uses a keyboard layout different from the specified
locale (just think a programmer often needing {} ).
I agree, = should also work as a Zoom In key. I really like the keyboard
nationalisation thing. I use a Dvorak keymap myself (on a Qwerty keyboard,
but that's beside the point) which means that some key combinations get
rather cumbersome without some form of remapping (for example, the z is
located underneath the / key. As my right hand is on the mouse when drawing,
I need to move my left hand to the righthand side of the keyboard to be able
to do right-control-z. Being able to remap it to Ctrl-; would be very nice,
then I could just use the normal Qwerty Ctrl-z keycombo again.
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Menus, keybinding et al, first draft
On Saturday 16 February 2002 09:29, Lourens Veen wrote: I'd like to define a Tool as something that changes the image depending on the coordinates sent by the pointer device. This means that Flip and Transform (which always work on the whole image or the whole selection) aren't tools at all. Things like the Image-Color-* functions, which seem to be implemented as Tools in 1.2, aren't tools either. Something I forget: note that by this definition, the Text Tool isn't a tool either, at least when using Dynamic Text, since the placement of the text depends only on the option in the dialog box. I think Text should be a tool, and, unless otherwise specified in the dialog box, the text should appear in the image at the location that was clicked by the user. This also prevents the problem of having to scroll around to find the text you just made when you are zoomed in. If the text were at the point where you clicked (which is ofcourse within the viewport) you could just finetune it and go on. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] testing a press release
On Thursday 28 March 2002 01:40, Branko Collin wrote: Hi, Argh! Rather late, I put up the press release I promised to make at http://www.xs4all.nl/~collin/gimp/pr/gimp123pr.html. If you want to comment on it, please go ahead. I think I found one small language error. In the last paragraph you write He has translated part of the program to Dutch and tries to get bugs fixed now and again. which I think should be He has translated part of the program into Dutch and ... Google seems to agree (1 million hits on translated into, only 235000 on translated to) but since both have quite a large number of hits I suspect it's not that sharp a contrast. Maybe it's just another British vs. American thing. Anyway, looks good otherwise! Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On Fri 29 November 2002 18:33, Raphaël Quinet wrote: On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland [EMAIL PROTECTED] wrote: Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the virtual layer, only the layers inside of it are done, no outside layers interact with these except through the final virtual layer.) There has been some discussion about layer grouping, but I do not think that any concrete implementation proposals have ever been agreed upon. So anyone who could come up with a GUI mock-up is welcome. Code is even more welcome, of course. ;-) Funny. I did just that (a mockup, not code) a little while ago in a different forum. See http://boards.lionhead.com/showthread.php?s=threadid=32671#post298059 Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bug hunting -- squashing windows bugs
On Mon 2 December 2002 21:35, David Weeks wrote: I fixed all my windows bugs: 0) Backup your data. 1) Boot from rescue disk, no CD support (or don't worry for win95, that had to be made manually). 2) Utilize the Microsoft built, Microsoft bug squashing tool: fdisk 3) In fdisk you'll likely see these bugs, they're called partitions. You want to delete them. 4) Note that some bugs are harder -- namely extended partitions. In those you'll have to first squash the logical drive bugs, then you can delete the extended partition bugs. 5) Save changes and exit. Congratulations! Your system is now bug free! 6) Insert Red Hat 7.3 (NOT 8.0 -- IT HAS THE GNOME BUG!) disk one, to finish the bug proofing your windows machine. Proceed with screens, but chose custom (cause this is a bug squashing thing), and both install and make default the KDE desktop. (That's the special bug protection. Though it too, has some bugs ((sorry)), though not as badly as the rest.) 7) This works for NT and XP as well. For persistant bugs, like the administrative rights bug, in NT or XP, just boot from the Red Hat 7.3 disk 1, and when it offers disk druid, use it to delete the windows partition bugs, as mentioned in step 3. 8) Bug squashing is fun, and you can do it at home and work. 9) Oh, squash at your own risk. You'll find that this fixes not only the windows gimp bugs, but your vulnerability to email attacks, all kinds of viruses, the blue screens of employment bug, and the dreaded exposure to legal liabilities for pirated software/BSA where coming to Fed. you away bug. (YIKES!) And guess what, it fixes all GIMP bugs too!. After all, GIMP is part of GNOME, so if you don't install GNOME, there won't be GIMP, so there won't be any GIMP bugs! Yay! Seriously, you've made your point on free software and free OSes. I agree wholeheartedly, but if you want others to respect your opinion, you should respect theirs too. Trying to convince them is fine, but this is a technical mailinglist, and as such not an appropriate place to do so. Cheers, Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
