[Gimp-developer] gimp-unstable-2.3.11
Hi,
I'm solving bug (https://bugzilla.novell.com/show_bug.cgi?id=231161 ) in
package gimp-unstable-2.3.11. There are modified elements 2 and 3 of
'values' array on lines 223 - 226 of file
plug-ins/winicon/main.c
But this doesn't agree with definition of 'values' parameter of function
run(), line 154.
Is it OK to replace 2 by 4 in the definition of 'values' variable?
Thanks.
Petr
--- plug-ins/winicon/main.c
+++ plug-ins/winicon/main.c
@@ -151,7 +151,7 @@
gint *nreturn_vals,
GimpParam **return_vals)
{
- static GimpParam values[2];
+ static GimpParam values[4];
gint32 image_ID;
gint32 drawable_ID;
GimpRunModerun_mode;
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-unstable-2.3.11
On Thu, 08 Mar 2007 10:15:53 +0100, Petr Gajdos [EMAIL PROTECTED] wrote: Hi, I'm solving bug (https://bugzilla.novell.com/show_bug.cgi?id=231161 ) in package gimp-unstable-2.3.11. [...] Is it OK to replace 2 by 4 in the definition of 'values' variable? Yes, of course this is OK. Thanks a lot for reporting this bug and for providing a patch. This is now fixed in SVN, revision 22070. I am surprised that such a bug was able to hide in our code for several months without being noticed. Boo! for the developer who introduced it in the code! :-) No, I will not give any names - the culprit has already been identified and he pleaded guilty. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-unstable-2.3.11
:-) Raphaël Quinet píše v Čt 08. 03. 2007 v 11:16 +0100: On Thu, 08 Mar 2007 10:15:53 +0100, Petr Gajdos [EMAIL PROTECTED] wrote: Hi, I'm solving bug (https://bugzilla.novell.com/show_bug.cgi?id=231161 ) in package gimp-unstable-2.3.11. [...] Is it OK to replace 2 by 4 in the definition of 'values' variable? Yes, of course this is OK. Thanks a lot for reporting this bug and for providing a patch. This is now fixed in SVN, revision 22070. I am surprised that such a bug was able to hide in our code for several months without being noticed. Boo! for the developer who introduced it in the code! :-) No, I will not give any names - the culprit has already been identified and he pleaded guilty. -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] 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
[Gimp-developer] Rewritten save-for-web
Hi, Save-for-web plug-in has been rewritten in order to make code maintainable and to introduce some features previously discussed on the mailing list. If someone tests it (last version 0.8), please tell if it is useful and comment whether it should be added as standard gimp plugin. (There is an enhancement request for save-for-web plug-in in Bugzilla, but it is possible that something diferrent is expected). link: http://registry.gimp.org/plugin?id=8799 Thanks. ___ 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 Thu, 08 Mar 2007 11:54:25 +0100, David Gowers [EMAIL PROTECTED] wrote: 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.) I think you can achieve the same results without floating. Just try a rotate. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
My plugin is working fine, after I found my bug and the one in the blur example. It's just annoying. Then please explain the bug in the example code and send us a patch (preferably against SVN) that we can apply so that others won't run into the problem again. http://svn.gnome.org/viewcvs/gimp-web-devel/trunk/writing-a-plug-in/ Unfortunately, the code has more that one bug, or the correction I made didn't solve the issue completely. Using your last code in http://svn.gnome.org/viewcvs/gimp-web-devel/trunk/writing-a-plug-in/3/myblur5.c?revision=207 (that still shows the shift), I did an experiment. First, I made a symmetric image with a set of lines: http://w3.impa.br/~luis/fotos/lixo/grid.jpg and then blurred it with the code and radius=20. I got this: http://w3.impa.br/~luis/fotos/lixo/grid_blurred.jpg You can see three problems: 1) The old 1-pixel-down shift. 2) The two dark bands (20 lines each) at top and bottom of the image. 3) Even much intriguing is the grey band right below the top one, also of 20 lines! And it is homogeneous (no likes inside)... My 'solution' (change 'x1, y1,' in line 241 by 'x1, y1+1,') took care of the shift, but not of the banding. The homogeneous grey band just moved to the bottom... (you cannot imagine the mess this does in my code!) I think that the problem is that this shuffle function is implemented without taking into account the drawable height. Now: Could anyone please show me a SIMPLE code where the tile handling is properly implemented, without bugs? I mean, the same blurring plugin would be just perfect, but without bugs... From this buggy example, I just don't understand how they work, so I am not able to find the bug. You should realize that this is all just volunteers effort. Someone wrote this tutorial years ago and another volunteer added it to the gimp-developer web site. It will take another volunteer to improve it and to fix the example code. And yet even more volunteers will have to show up in the future to keep the tutorial uptodate. Of course I understand this. We are all volunteers. This was not the point. Anyway, thank you for your time, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google SoC: Help with proposal
Matthew Wood wrote: Hi Matthew, I'd really like to participate in Google SoC and specifically with the GIMP project. I am only a second year CS major though and so am still in the early stages of my education. I'm interested in the search-based menu browser idea, but was unsure how to form a proposal. thanks for your interest in participating. We are currently discussing the SoC project ideas at http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-March/thread.html#17379 There are different views on this project - see Peter's and Akkana's mails. Maybe you want to participate in this discussion as well - you could tell us why you did choose this idea, for example. The GIMP Soc wiki says that an application should include a time line for implementing the certain parts of the proposed project. I have experience with C , but not with anything on the scale of gimp, and so although I can imagine how I'd practically break this problem down piece by piece, I'd need a little help getting started with the code. If you can break up the project in smaller pieces, then you've got a time line. It will list milestones instead of dates. Does anyone have any advice for how I should get started writing my proposal? You can summarize how you do expect the menu browser to work, from a user's point of view - where it will be shown in the ui, how the user can interact with it, and so on. This will decide about the steps that have to be done from a developer's point of view, and this is when you can being to assign milestones. HTH, Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote: It is pretty easy to crash many (most?) of the plug-ins when passed bad data from some script. Checks in libgimp can stop GIMP from crashing but will only go so far to stop the plug-in from crashing. I think it would be a worthwhile project to get done at some point. In terms of SoC, it would be a low priority project. This also raises the question as to whether the plug-in-template can handle being passed bad data or not. If not, it should be updated to show new plug-in authors how to properly write a plug-in to deal with the possibility of receiving bad data. On Thursday 08 March 2007 04:12, Sven Neumann wrote: The question is, is this a serious problem at all? If a script is broken and the result is a plug-in that crashes, is that really a problem? A crashing plug-in shouldn't cause further harm and there's a warning that informs the script author that there's a problem. The script can then be fixed. I fully agree with Sven here. Besides, I can't imagine how this could be something cool, which, IMHO, GSoC stuff should be. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
Quoting Luis A. Florit [EMAIL PROTECTED]: http://w3.impa.br/~luis/fotos/lixo/grid_blurred.jpg You can see three problems: 1) The old 1-pixel-down shift. 2) The two dark bands (20 lines each) at top and bottom of the image. 3) Even much intriguing is the grey band right below the top one, also of 20 lines! And it is homogeneous (no likes inside)... My 'solution' (change 'x1, y1,' in line 241 by 'x1, y1+1,') took care of the shift, but not of the banding. The dark bands can be attributed to the fact that the averaged region near the borders is filled out by effectively duplicating the row or column at the edges. The algorithm may not be optimal, but it works as one should expect. The average is currently produced by a formula similar to: sum (v-2, v-1, v, v+1, v+2) / 5 Near the borders, when there is no value v+2 available, for example, you end up with: sum (v-2, v-1, v, v+1, v+1) / 5 And the next pixel will be: sum (v-2, v-1, v, v, v) / 5 If you wish to improve the algorithm, I would suggest that you need to discard terms and adjust the denominator accordingly -- the last example shown should produce sum (v-2, v-1, v) / 3. At least, that is my recommendation. I am not a mathematician. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
On Tuesday 06 March 2007 05:03, Sven Neumann wrote: Hi, I have read through the list at http://wiki.gimp.org/gimp/SummerOfCode and I think we need to triage the list and try to come up with fewer but more detailed proposals. Here are some comments to get us started: I added some more ideas to the list on the wiki I think could be feasible as GSoC projects: * Enhancing Painting with parameter curves Currently there are quite a few options to use with the paint tools, however, mapping how these options could vary with pressure, tilt, speed, angle of painting is somewhat limited. A complete tabbed dock, where new curves could be added that would map one input variable to paint option could increase several fold the options available to artists. A request for this is drafted in [http://bugzilla.gnome.org/show_bug.cgi?id=119240|bug #119240]. * Categories for brushes, fonts, gradients and palettes If one adds too many fonts or brushes to GIMP, they quickly become un-manageable through the existing UI. Implementing a way of organizing these resources in sub-categories, in a way that one resource could be present in more than one category (like thrugh the use of tags) in a nice UI could overcome these limitations; * Font Selector Widget We need something better. Something that is reusable. Something to turn choosing fonts into a pleasure, rather than a pain. Something to leave the competition on the dust. And I also came up with this idea, but did not add it to the wiki, because it certainl should have further consideration from the developers, more than the others, to get toeven a rughidea of what will be needed: * Layer Folders UI With the upcoming integration of GEGL, there finally will be internal support for layer grouping, even more than one level of it. Aide form the work on the core, we will need a good UI to be the evolution of the current layers dialog. If the GIMP will only allow nested layers, then this should be mroe or less trivial. If GIMP will allow full usage of GEGL, and allow the same layer to be used as source for multiple operations then we will need a brilliant UI. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
On Fri, 09 Mar 2007 05:31:26 +0100, [EMAIL PROTECTED] wrote: Quoting Luis A. Florit [EMAIL PROTECTED]: http://w3.impa.br/~luis/fotos/lixo/grid_blurred.jpg You can see three problems: 1) The old 1-pixel-down shift. 2) The two dark bands (20 lines each) at top and bottom of the image. 3) Even much intriguing is the grey band right below the top one, also of 20 lines! And it is homogeneous (no likes inside)... My 'solution' (change 'x1, y1,' in line 241 by 'x1, y1+1,') took care of the shift, but not of the banding. The dark bands can be attributed to the fact that the averaged region near the borders is filled out by effectively duplicating the row or column at the edges. The algorithm may not be optimal, but it works as one should expect. The average is currently produced by a formula similar to: sum (v-2, v-1, v, v+1, v+2) / 5 Near the borders, when there is no value v+2 available, for example, you end up with: sum (v-2, v-1, v, v+1, v+1) / 5 And the next pixel will be: sum (v-2, v-1, v, v, v) / 5 If you wish to improve the algorithm, I would suggest that you need to discard terms and adjust the denominator accordingly -- the last example shown should produce sum (v-2, v-1, v) / 3. At least, that is my recommendation. I am not a mathematician. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer yes the border handling is pretty basic. YOu could look at the convolution filter (one of the plugins built with gimp) for different methods of dealing with borders. The basic problem is that this will always be extrapolation outside the real data so its a guess. With a pattern like your grid this can easily be badly wrong. The best simple method would be a linear extrapolation over a few points. This would at least prevent a black line becoming a black band as you are seeing here. Another approach would be to not process areas with unknown data, ie leave a band unblurred and then replace this with an extrapolation of the edges of the reduces area containing correct data. This will provide more visually acceptable results in your test case although this can never be mathematically rigourous since you are arbitarily extrapolation outside known data. This may well be an approach worth investigating throughout gimp since current methods seem to be somewhat rudementary. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
On Thu, 08 Mar 2007 23:13:08 +0100, Luis A. Florit [EMAIL PROTECTED] wrote: My 'solution' (change 'x1, y1,' in line 241 by 'x1, y1+1,') took care of the shift, but not of the banding. The homogeneous grey band just moved to the bottom... (you cannot imagine the mess this does in my code!) This is what's known in the trade as a frig factor! You are arbitarily making an adjustment to correct one subjective error. You will likely find that on a different image it bahaves differently unless you understand why this adjustment is necessary and that +1 is a generally valid fix. I cant comment on whether this is a bug in the tile code of the example or elsewhere. I suggest you look at some of the built in plugins. I think most of the effects on the filters menu are implemented as plugins that are part of the gimp distribution. There are some differences in integrating external plugins but it's pretty much the same thing in the plugin code so you may be able get some clues on what you are trying to do from the existing plugins. Be warned there are bugs in there two ;) I did some revectoring and tidy up work on the convolution plugin last year and got told off for not testing it and introducing bugs. It turned out the bugs have been there since 1997. My objective was to make the code more readable and maintainable and to generalise the matrix routines to handle larger dimensions. I did not attempt to fix these anomolies. My initial idea was to write a new plugin but I gave up since the documentation was totally inadequate, out of date and sometimes inaccurate. I decided it would take more time than I had available. I hope you have more luck. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
Hi, On Fri, 2007-03-09 at 08:08 +0100, [EMAIL PROTECTED] wrote: I did some revectoring and tidy up work on the convolution plugin last year and got told off for not testing it and introducing bugs. It turned out the bugs have been there since 1997. My objective was to make the code more readable and maintainable and to generalise the matrix routines to handle larger dimensions. I did not attempt to fix these anomolies. Huh? Your changes got committed, if I remember correctly. GG, can you perhaps consider to take your bashing off-list? We all know very well that the GIMP code is far from perfect. A lot of plug-ins and also some code in the core is old and the people who wrote it weren't experts in computer graphics. The algorithms being used are sometimes badly chosen and sometimes even incorrectly implemented. There is a lot to do in this respect and we hope that the switch to GEGL will force us to review all this code. The concepts of GEGL and babl should also allow us to get to cleaner and more readable code. Please do not discourage us and potential contributors by continously pointing out that some of the code is crap. We all know that. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
Hi, On Thu, 2007-03-08 at 19:13 -0300, Luis A. Florit wrote: Unfortunately, the code has more that one bug, or the correction I made didn't solve the issue completely. I think we should then replace the example by something simpler. The point of this tutorial is not to show how to implement a blur. It is supposed to show some basic concepts of plug-in development. The code that is used as an example should be simple and bug-free. The current blur code doesn't seem to fulfill these requirements. So perhaps it should be replaced by a more local operation. Another option would be to add a comment to the tutorial that points out that, for the sake of simplicity, the blur code is simpler than it would have to be and that it introduces a shift for that reason. Now: Could anyone please show me a SIMPLE code where the tile handling is properly implemented, without bugs? I mean, the same blurring plugin would be just perfect, but without bugs... From this buggy example, I just don't understand how they work, so I am not able to find the bug. The GIMP source code includes more than hundred plug-ins. I am sure you will find one or two that can serve as examples. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
