Re: [Gimp-developer] Re: Blur filter
On Sun, 22 Jun 2003 13:17:49 -0700 Joel Rodriguez [EMAIL PROTECTED] wrote: In practice this means, that I can have two completely different images, one that shows a normal image and another one that completely looks like random noise. But when I use a convolution on both images the result can be almost identical. The problem with least squares optimization is that this procedure cannot distinguish between these two images. I almost agree with you, in the sense that the forward modeling Fourier analysis based technique might not be sufficient, although the least squares method (as a hole) might be. Might be if there is a way to incorporate such image information that characterizes it, in some other way or aside Fourier analysis, such information (invariant measures) could be incorporated into a least squares reconstruction task as regularization scheme technique. although the above sentence it is not a fact to my knowledge. To my knowledge it is a fact. Perhaps the following explanation might help. Given a convolution C and a blurred image B, the least squares technique tries to find an image I such that the least squares distance between C(I) and B is minimal. In my previous post I describe how you could construct an inverse of C, let's call it D. Now for all images X it is true that C(D(X)) = X, therefore I=D(B) is the least square solution because C(I)=C(D(B))=B. When the Fourier transform of C contains any zero coeficients, the inverse D is not uniquely determined. In fact, I can choose arbitrary values for the coefficients in the Fourier transform of D that correspond with the zero coeficients in C. This is true because you can describe convolution in the Fourier domain by multiplication of the coeficients. When I multiply a value by zero the end result is always zero. So when the Fourier transform of C contains zero coeficients there are an infinite number of least square solutions, and the least square criterium alone cannot select one of them. Even when the Fourier transform does not contain zero coeficients the least squares solution is generally not a visually good solution because it is extremely sensitive to errors. The problem is that C frequently contains some small coeficients, the corresponding coefficients in D are therefore very large. But this means that D will greatly magnify any errors in the corresponding Fourier coeficients of the blurred image B. So even very small changes in B will have a great impact on the least square solution I=D(B). In practice this means that in general you don't want to use the true least square solution because it is highly unstable. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [long] Suggestions + Patch, Redo (please dont flame), Part 1
on IRC Sven said i really should put these changes to the list for discussion I will try and make keep this simple but I have a few loosely related changes all of which are against gimp/app/gui/image-menu.c The patch is here http://bugzilla.gnome.org/showattachment.cgi?attach_id=17739 Attached to this bug report http://bugzilla.gnome.org/show_bug.cgi?id=92468 The patch itself is simple, but I expect it will be controversial. Firstly (and most likely to be incredibly unpopular) I want to change Redo Control+R to Redo Control+Shift+Z Reasons: Ctrl+R is not unreasonable, as R is the first letter of Redo (in English at least) and it probably comes from something older than me that I am unaware of but very few other applictions use it, which makes it inconsistant and harder for most people to learn. I will qualify what I mean when I say very few: Microsoft Windows doesnt use Ctrl+R, usually it uses Ctrl+Y the twisted logic being that Y comes before Z and Z is used for Undo. (Mozilla uses Ctrl+Y for Redo as well). Apple OS X uses AppleKey/CommandKey + Shift + Z, older versions may have used CommandKey + Y but I cannot remember clearly. The logic is to use a Shifted version of a keybinding for closely related actions across the whole desktop which makes it slightly easier to guess unknown keybindings (and means you can use Ctrl+Y for something else). Gnome uses* Ctrl+Shift+Z for Redo. [* most Gnome apps do already or will follow the Gnome Human Interface Guidelines. This guideline does makes sense, they are just following Apples logic] KDE also uses Ctrl+Shift+Z http://developer.kde.org/documentation/standards/kde/style/menus/edit.html (These are based on a google search:) Abode Photoshop also seems to use Ctrl+Shift+Z for Redo Jasc Paint Shop Pro is a bit strange and uses Ctrl+Alt+Z, because Ctrl+Shift+Z is already taken by Undo History (using Ctrl+Alt+Z for Undo in Gimp wouldn't be a terrible idea, but i know using Alt cause some minor problems in places). So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually. There also already exists a Menu Configuration File for Photoshop users, I propose a Menu Configuration for users who like the current menu configuration and dont want things changed (there was a bug report about being allowed to change and reset the menurc from the preferences dialog but i am not sure of its current state). I also want Ctrl+R for a different keybinding. This message is getting really long so I will explain the rest of the patch in other emails, please hold off critiquing the rest of the patch for a while so that I have a chance to _fully_ explain my reasoning. I have put a lot of time and thought into this, but I am not an expert I just know what I like and have a reasonably good understanding of why so please consider your criticism carefully. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ PS Please leave my address in the CC line, I am subscribed to the list digest and it will take me a while to give carefully considered responses to any questions. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [long] Suggestions + Patch, Redo (please dontflame), Part 1
Hi, Alan Horkan [EMAIL PROTECTED] writes: So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually. There also already exists a Menu Configuration File for Photoshop users, I propose a Menu Configuration for users who like the current menu configuration and dont want things changed (there was a bug report about being allowed to change and reset the menurc from the preferences dialog but i am not sure of its current state). I think we shouldn't do this change since I can not follow your arguments. Everyone seems to be using a different keybinding for Redo and we use Ctrl-R for quite some time now. Why should we change the default? Perhaps we need a hig-menurc... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [long] Suggestions + Patch, Redo (please dontflame), Part 1
Sven Neumann wrote: Alan Horkan [EMAIL PROTECTED] writes: So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually. I think we shouldn't do this change since I can not follow your arguments. Everyone seems to be using a different keybinding for Redo and we use Ctrl-R for quite some time now. Why should we change the default? Perhaps we need a hig-menurc... Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut. I think following the HIG by default is a good thing. People will get used to the new defaults. I'd have more of a problem with having those kinds of things as options, to be quite honest. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
