Re: [Gimp-developer] ANNOUNCE: GIMP 2.4.0-rc1
Sven Neumann schreef: This is probably the last mail I write before going on vacation with the girl I am going to marry tomorrow. I hope that you guys can manage to fix the remaining issues and roll out the 2.4.0 release while I am away. Congratulations to you and your (soon-to-be) wife!! -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ 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.
Sven Neumann schreef: 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. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Perhaps not a bug, but IMHO gimp's JPEG handling violates the principle of least surprise. I had a quick look at the source code and found out that the quality setting (and other parameters) are saved in a global variable jsvals, which is initialized with the default values (85 for the quality), but gets overwritten after save as: 1. open a.jpg 2. save a.jpg - a.jpg is saved with the default quality, 85. Fine by me. 3. save a.jpg with save as, with quality say 55 - as expected it is saved with quality 55. 4. open b.jpg 5. save b.jpg - b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when save as is used. 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ 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.
[EMAIL PROTECTED] schreef: On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven [EMAIL PROTECTED] wrote: 1. open a.jpg 2. save a.jpg - a.jpg is saved with the default quality, 85. Fine by me. 3. save a.jpg with save as, with quality say 55 - as expected it is saved with quality 55. 4. open b.jpg 5. save b.jpg - b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when save as is used. 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). thanks for digging that out. is that from todays svn, Sven committed a patch earlier today that may affect that. I first tried with gimp/trunk from svn revision 22893 (from 2007-07-06 22:47:44 +0200); I now tried it again with svn revision 22902 (from 2007-07-08 17:34:25 +0200), which presumable includes the patch you mention; the behavior I described is still the same. the default setting now settable by the user (thanks Etienne). see bug #63610 I haven't tried changing the defaults to see if that changes anything. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: requesting a change in the defaults
Sven Neumann schreef: Hi, On Thu, 2006-09-21 at 19:37 +0200, Roel Schroeven wrote: It seems that more and more applications start to rely more or less heavily on middle mouse buttons and/or scrollwheels (Gimp and Google Earth come to mind), which is a bit annoying as my laptop is my main machine. GIMP doesn't rely on the mouse wheel for anything. It uses it if it's there and that's what the mouse wheel controller is doing. Carol is making a fuss out of nothing. Just ignore her. Well, there's one thing that doesn't work without the middle mouse button: panning. But as I said in another post, it's absolutely not a big deal to me. It might have been wiser not to give in to my desire to spout my opinion. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: requesting a change in the defaults
[EMAIL PROTECTED] schreef: On Wednesday, September 20, 2006, 20:46:24, Carol Spears wrote: is this such a common mouse and are the users of such a mouse unable to set the default themselves? Unless you're used to IBM workstations (or old Macs), then yes, wheel mice are common - I bought my first one about 10 years ago, and I haven't seen wheelless mice sold in a long time (except for Mac users). OTOH, touchpads and pointing sticks on laptops don't have scroll wheels. They often even don't feature middle mouse buttons, though I have never understood exactly why. And IIRC nowadays more laptops are sold than desktops. It seems that more and more applications start to rely more or less heavily on middle mouse buttons and/or scrollwheels (Gimp and Google Earth come to mind), which is a bit annoying as my laptop is my main machine. Of course, people can just attach a proper mouse to their laptop if/when they use it for serious graphical work. Which is a good idea anyway; a touchpad is way too imprecise. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Suggestion: Make the'Newlayer'commanddefaultto'New lay
Martin Nordholts schreef: For this particular button however, I think we are not even talking about a majority, but rahter as good as _all_ users. If you ask yourselves, how often do I need to adjust the settings of a layer, and how often do I just click OK on the dialog, what is your answer? FWIW, I think this is one thing (in fact the only thing, I guess) that Microsoft Visual SourceSafe got right. Many functions show a dialog box with options when you first use it. The dialog box has a checkbox From now only show this dialog if Shift is pressed (or something to that effect; I don't remember exactly). If you check the checkbox, that specific function from then on doesn't display the dialog anymore; it just uses the default (or current) option values. If you want to change the options, you just press shift while selecting the function. I believe there's also some preferences menu to reset the shift-behavior. Works pretty good, I think. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Lanczos algorithm funnyness?
Sven Neumann wrote: Hi, John Leach [EMAIL PROTECTED] writes: I just downloaded the 2.3.5 snapshot and had a go with the Lanczos resizing algorithm. It seems to bring out some strange artifacts in one photo (actually, the first I randomly tried). The Lanczos implementation in CVS is buggy and unless someone shows up who fixes it, it will most likely end up being removed before the 2.4 release. I might take a shot at fixing that, if I can find enough time to do it. Is it bug 305928 you mean? On first sight that is more about the interaction between Lanczos and the perspective tool than about Lanczos itself. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: 16bit channels, doh
Alexandre Prokoudine wrote: On 11/1/05, Øyvind Kolås [EMAIL PROTECTED] wrote: Much of the GIMP development over the last few years have been about modularizing and gobjectifying the code this has lead to a separation that will make a merge with GEGL easier in the future. At the moment I think the GIMP code base is in a phase where gradual replacement of the code with GEGL based bits could happen if GEGL was ready, but GEGL isn't ready. Would it be a good idea to create a TODO list for GEGL, so that everyone interested could have a look and pick a task that he would be able to accomplish? http://www.gegl.org/TODO.html seems to be something like that. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] use of the Space key
Akkana Peck wrote: Do a lot of gimp users not have a middle mouse button? Maybe tablet users who don't want to put down the stylus and switch to a mouse? (That would be understandable.) Or is this just because ... that other program does it that way, and its users are used to it? My laptop, and I suspect other laptops too, doesn't have a middle mouse button. Not that it matters that much, since I can attach a real mouse when I want to do serious graphic work. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-remote
Sven Neumann wrote: Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine. I don't know about problems on multi-user machines, but I've had problems when I tried to display Mozilla instances running on different machines in the same X session. IIRC there was even a problem running an MS Windows native Mozilla together with a Unix-mozilla via Cygwin's X server. -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-remote
Sven Neumann wrote: Hi, Roel Schroeven [EMAIL PROTECTED] writes: Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine. I don't know about problems on multi-user machines, but I've had problems when I tried to display Mozilla instances running on different machines in the same X session. Of course you can't load a local file into a gimp instance running on a different machine but on the same X server. That's not any different to the current situation though. And it would probably be possible to design the remote protocol in a way that avoids this problem. So we can only improve things. I think we're not talking about the exact same thing. What I mean is this: suppose you have a remote instance of the Gimp running, and then you want to open a local file in the Gimp. I think a new, local instance should start to open that file, since the remote one can't load that file. But if the remote protocol just looks for a gimp window, it will try to use the existing gimp instance to open the file. Unsuccessfully. -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Alternative zoom algorithm
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: For example, in C, the compiler is legally allowed to transform: r = (1 - a) * b; into: r = a - a * b; Which might not be the same value. If that is a problem, you either have to use more sequence points (i.e. multiple statements), or you need to use fortran, where these kinds of transformations are not allowed :) I assume you mean r = b - a * b, but even then that's the first I see something like this. AFAIK that is not what sequence points do. In (1 - a()) * b() a() might be evaluated before b() or the other way around, you never know. Sequence points ensure that everything before them is executed first. That's what I know sequence points are for; I would be very much surprised if the compiler is allowed to do symbolic algebra. I could be wrong of course (it wouldn't be the first time). Do you have any pointers to relevant online resources? -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet wrote: On Tue, 16 Dec 2003 10:31:29 -0200, Joao S. O. Bueno [EMAIL PROTECTED] wrote: You could maybe just add (or ask someone to add) a zero-out transparent pixels on the layers menu. [...] I do not care (yet) about clearing the transparent pixels, destroying color data, using pre-multiplied alpha or all the (un)related things that were mentioned in recent messages. I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary. Above you said I do not care about [...] destroying color data, now you say that the GIMP should be free to destroy RGB data. No offense, but that does make it easier to misunderstand you. After reading many posts about this topic, I'm still not sure I understand what you are saying. As far as I understand it, I disagree. [...] Basically, the model that we should promote is: - layer mask= hiding mechanism, reversible - alpha channel = pixels that are cleared have undefined RGB data, not reversible (except for undo) Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers). I *really* don't see why. The way I see it is that in general things should be kept orthogonal as much as possible, unless there are good reasons to do otherwise. In RGBA we have four values named R, G, B and A, and it is perfectly possible to change any single one of them without affecting the others. That's orthogonality, and it is a nice feature to have. What is the advantage of RGB data suddenly being undefined? -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Status of gegl, gimp 3.0?
Sven Neumann wrote: Nathan Carl Summers [EMAIL PROTECTED] writes: Which brings up an interesting question -- how can an open source project accurately represent what is going on in developmentland on its web site? One thing I could imagine would be some sort of regular news update on GIMP development. Similar to kernel-cousin (you mentioned that already) or the Abiword Weekly News (http://www.abisource.com/information/news/). Something like that once existed, but sadly it's asleep now: http://kt.zork.net/asleep.html -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Ermapper / ECW Support
Also, they compare ECW to Photoshop -- ??? Not really; I think they ment to compare their 'ER Mapper' product to Photoshop, and ER Mapper seems to be some kind of GIS-tool, allowing to handle very large bitmaps and doing orthorectification and stuff. It's still a silly comparison though, since ER Mapper and Photoshop are aimed at very different target audiences. Could be worth a look, though, especially if it's as open as they say They certainly claim that it's an open standard, but they also talk about a 'patent-pending Enhanced Compressed Wavelet (ECW) technology'. We need to be careful to avoid another LZW fiasco, as another poster said. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
