Re: [Gimp-user] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, On Mon, 2008-10-27 at 04:01 -0700, Claus Berghammer wrote: Since there is no explanation WHY the algorithm was rewritten, I guess 2 possible reasons: 1.)The old code did something wrong in some cases 2.)The new code was necessary due to GEGL integration For the first point, I compared scaling results from 2.4 and 2.6, and they are (ignoring some harmless alignment issues) 100% identical (using difference blend mode). I also cannot remember, that in the past years, the scaling routine in Gimp produced noticeable wrong results. (Beside the lanczos interpolation, that didn't work right, when it was introduced) Your analysis is wrong. There's a discussion about the problems and the solution in bug #464466 (and several other bug reports linked from there). This has also been extensively discussed on the gimp-developer mailing-list. Fact is also that scaling is not much slower in general. There are some cases where it became faster. Other cases became slower, but the results are of much better quality. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Identify old GIMP font
Hi, On Mon, 2008-10-27 at 17:19 +, Per Gregers Bilse wrote: I have now forgotten the name of the font I used (...) and I'm wondering if anybody here might be able to identify it. Have you tried What the Font (http://www.myfonts.com/WhatTheFont/) already? Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] stroke selection not antialiased
On Tue, Oct 28, 2008 at 2:19 PM, Ernie Wright [EMAIL PROTECTED] wrote: Simon Budig wrote: Nathan Lane ([EMAIL PROTECTED]) wrote: So why not convert your selection to a path then stroke the path? This is a good work around, and even in my mind now, this makes sense. The stroked path is antialiased. This is a good workaround if you know what you're doing and what effect you're after. We just cannot make this descision on behalf of the user from within Gimp code. I can't believe any user actually wants this behavior. But assuming some do, they could still get it by untoggling the Antialiased checkbox in Choose Stroke Style-- and in fact, I would expect users who want aliased strokes are already doing that, unaware that the Antialiased setting makes no difference at all (that I can see, anyway). I can confirm this bug. If you stroke using a tool (eg paintbrush), the result is antialiased, so I don't understand why the vector stroking isn't Actually, it is antialiased. It's just that the antialiasing quality reduces as the stroke width increases. David ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] stroke selection not antialiased
Hi, On Tue, 2008-10-28 at 17:54 +1030, David Gowers wrote: I can confirm this bug. If you stroke using a tool (eg paintbrush), the result is antialiased, so I don't understand why the vector stroking isn't Simon has actually explained this quite well already. The outline you are stroking is the selection border. Since the selection is a mask it consists of pixels. So the selection border runs along pixel edges and thus consists of only horizontal and vertical segments. Zoom in and look at the marching ants. Now if you stroke this, you get the expected result. Stroking with the paint tool is implemented by stamping the brush in regular intervals along the path you are stroking. This eliminates the problem somewhat as the stroking does not closely follow the selection border on its way along the pixel edges. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hello... @Eric P: Upscaling image: 500px - 5000px (bicubic): Gimp 2.6.1: 35,21 sec Gimp 2.4.7: 6,9 sec Downscaling layer: Image is 5000x5000 px, 2 white layers Scaling top layer to 2500x2500px (bicubic): Gimp 2.6.1: 7,85 sec Gimp 2.4.7: 4,78 sec @Sven Neumann: Thanks for your hint on the related bugthread. I will read it carefully to better understand the whole thing. Claus Eric P wrote: Claus Berghammer wrote: Hello Gimp Users and Developers, This is a follow up of Bug 557950 (which in fact isn't a bug, according to Sven Neumann ;-) http://bugzilla.gnome.org/show_bug.cgi?id=557950 As described in the “Bug”, scaling in Gimp 2.6 series is far slower, than it was in 2.4. Sven Neumann commented: “We have completely changed the scaling implementation. The new algorithm is slower for some cases, but that is not a bug.” Since there is no explanation WHY the algorithm was rewritten, I guess 2 possible reasons: 1.)The old code did something wrong in some cases 2.)The new code was necessary due to GEGL integration For the first point, I compared scaling results from 2.4 and 2.6, and they are (ignoring some harmless alignment issues) 100% identical (using difference blend mode). I also cannot remember, that in the past years, the scaling routine in Gimp produced noticeable wrong results. (Beside the lanczos interpolation, that didn't work right, when it was introduced) So my question is, isn't it possible, to have both algorithms in Gimp, and let the user decide which one he wants to use? (Option in Scale Dialog) If it was due to point 2, the GEGL integration, than can we expect a faster version of the new scaling routine? Or will it be automatically faster, when GEGL is integrated more/better? The current situation draws some users (not myself) to not use Gimp 2.6, and stick with 2.4 instead, because the difference in speed is so dramatically. Sincerely, Claus Berghammer I'd be curious to see some benchmarks comparing 2.4 and 2.6 in this regard so that we know just how dramatically different the speed is. Eric P. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user -- View this message in context: http://www.nabble.com/Scaling-in-Gimp-2.6-is-much-slower-than-in-Gimp-2.4-tp20185528p20202924.html Sent from the Gimp User mailing list archive at Nabble.com. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, On Mon, 2008-10-27 at 04:01 -0700, Claus Berghammer wrote: http://bugzilla.gnome.org/show_bug.cgi?id=557950 I have done some more tests and I tend to agree that the multi-pass scaling doesn't improve the quality when upscaling. It's a very simple change to get upscaling perform more similar to what GIMP 2.4 has done. Could we perhaps move this discussion to the gimp-developer list? There your mail would have a chance to reach the developer who wrote the new scaling code. Thanks. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Moving Selections
Hello All, I've been using the GIMP off and on since 2.2 and find it to be a very good piece of software. I'm a web programmer and don't tend to do much graphic design work, but occasionally I need a button / background in a hurry and I enjoy having a play around to see what I can come up with. A task that I find myself frequently performing is cropping images. In the old GIMP I used to drag out a selection box, and then use one of the control keys (CTRL/ SHIFT/ ALT, can't remember which sadly) to move it around until it looked right. So for example, if I wanted the left border to expand out a bit further I would hold the key, move my selection left a bit, release the key, and the continue to line up the right border. It is such a simple, fluid process that it wasn't something I ever thought consciously about. The problem I have is that in the newer GIMPs I cannot seem to find the key which does this. I've read online that it should be the ALT key but when I searched on Google I just got back a lot posts that seemed to end in an argument about the right / wrong way to use the software. This doesn't concern me really, I'd just like to know how to get this functionality back as it was something that I found very useful. Would it be possible for someone to show me where I'm going wrong? Thanks very much, Olly Lennox IT Developer __ Clarke Willmott* http://www.clarkewillmott.com international tel: +44 117 916 9381 international fax: +44 117 917 5595 __ __ Information contained in this e-mail is intended for the use of the addressee only, is confidential and may also be privileged. If you receive this message in error, please advise us immediately. If you are not the intended recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses which may damage your systems. Clarke Willmott have taken reasonable precautions to minimise this risk, but we advise that any attachments are virus checked before they are opened. Any offer contained in this communication is subject to Clarke Willmott's standard terms conditions. Regulated by the Solicitors Regulation Authority. Authorised and regulated by the Financial Services Authority. A list of Partners is available for inspection at our offices. _ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Moving Selections
A task that I find myself frequently performing is cropping images. In the old GIMP I used to drag out a selection box, and then use one of the control keys (CTRL/ SHIFT/ ALT, can't remember which sadly) to move it around until it looked right. One link to rule them all http://docs.gimp.org/en/gimp-using-selections.html But why don't you use the crop tool if you want to crop an image or a layer? Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Strange zoomout behavior
Claus Berghammer wrote: When I zoomed in with 2.6.0, put the cursor on the pixels of interest, and type 1, the pixels of interest WAS at (or close to) the cursor (as expected). Now, with 2.6.1, the pixels of interest are somewhere, but not by far close to the cursor. Instead I always see the corner which is closest to the pixels of interest centered in the window. Hi Isn't what you are seeing here simply bug #555493 [1] ? If yes, then yeah that is certainly a bug. I open a larger picture (1944x2592px), where red eyes has to be removed. That for, I zoom into the eyes with the zoom tool. Then I draw a freehand selection on every eye that needs to be changed. To see the effect of the following step at 100%, I type 1 while the cursor is between the two eyes. With 2.6 the eyes were centered in the image window now, and was able to proceed without any extra panning. Since other use cases rely on that typing 1 does *not* use the cursor as the zoom focus point (which was what bug #553534 [2] was all about), I suggest you instead zoom out with the - key which *does* use the mouse cursor as the zoom focus point, or make use of the Zoom Revert functionality (View - Zoom - Revert Zoom, default shortcut key is `). The zoom button instead always centers the image in the image window, which is slightly more compelling to me than centering a image corner in the window, but still not the perfect way. I would like to have the following behavior: - Zooming out with cursor IN the image window - center the pixels under the cursor in the image window, image borders should be ignored. - Zooming out with mouse outside image window - pixels in the center of the image window should remain the pixels in the center of the image window, image borders should be ?. If you by zoom button mean the - or + key, then this is how it currently behaves. And actually it is an open question if it *should* behave that way or if the image coordinate under the cursor should *always* be the zoom focus point, independent of if the cursor is within the image window canvas or not. That is how GIMP 2.4 behaves. The way it currently works in GIMP 2.6 was introduced before the image was made (in the middle of GIMP 2.5 development) to center itself in the viewport if it becomes small enough to fit there when zooming out . In other words, there is no real reason to keep the new behaviour here. For the thing with image borders, how about introducing a operator key for zooming? Currently ALT and SHIFT doesn't seem to have a function while zooming, so one of these keys could be used to set the wanted border behavior. I'm sceptical about this, to me it doesn't make much sense and feels like a workaround to an issue that I'm not even sure exists in the first place. Sorry for the late reply BR, Martin [1] Bug 555493 – Zoom 1:1 scrolls partly off image http://bugzilla.gnome.org/show_bug.cgi?id=555493 [2] Bug 553534 – centering issues after image scaling and setting zoom to 100% http://bugzilla.gnome.org/show_bug.cgi?id=553534 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Identify old GIMP font
[EMAIL PROTECTED] (2008-10-27 at 1842.17 +0100): That looks like one of the Fixed fonts shipped with the X-Server. Since Gimp no longer uses the X11-mechanisms for font selection it no longer shows up in the font dialog. You need to somehow convince fontconfig to provide that font as well. GSR - FR writes: Modern fontconfig has /etc/fonts/ dir with config options and where (and pointing to the README there) On Debian and Ubuntu, you can probably get the bitmapped X fonts back by going to /etc/fonts/conf.d, removing the symlink to ../conf.avail/70-no-bitmaps.conf and replacing it with a symlink to ../conf.avail/70-yes-bitmaps.conf. Depending on the distro, you might also need to uncomment or comment a section in /etc/fonts/fonts.conf (I don't see anything relevant in Hardy, but I remember needing to make a change there in some past versions). ...Akkana ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
