Re: [Gimp-developer] still the same bug
GSR - FR wrote: Hi, [EMAIL PROTECTED] (2007-04-30 at 2137.21 -0300): could you provide more instructions to reproduce the error, Well, cannot tell you more... Adaptative, nonrecursive, 1 pixel radius, black=7, white=248. A 5 pixel cross in the middle of a white image, and I got a NONSYMMETRIC 6 pixel output like this: x xxx xx I see what you describe, with the 5 pixels being grey #8 and the bg #ff. A longer cross (3 pixels each arm plus the center pixel) also returns something interesting: x x x xx x xx xxx - xxx xxx x xx x xx Repeating the filter makes it grow to the bottom right a bit each time. GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer IMHO this comes from the histogram correction, try the same with a black (00) cross and white (FF) background. see : 2004-10-30 Sven Neumann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * plug-ins/common/despeckle.c: applied a patch from Geert Jordaens that improves the Despeckle algorithm. See bug #72862 http://bugzilla.gnome.org/show_bug.cgi?id=72862. The problem is that due to histogram correction some pixels are thrown out in this case the white pixels are thrown out. In the patch of 30-10-2004 I allowed the value of black to be -1 and white to be 256 to disable the histogram correction. Geert Jordaens ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
I once wrote a path for it, this included the possibility of disabling
the histogram correction (by setting the values out of range).
It seems that a more recent patch reversed this option.
Probably the out of range option was not the best way of implementing
it, however the function does make sense
for line-art and BW photo's see bug #72862.
Revision *16861*
http://svn.gnome.org/viewcvs/gimp?view=revisionrevision=16861 - (view
http://svn.gnome.org/viewcvs/gimp/trunk/plug-ins/common/despeckle.c?revision=16861view=markup)
(annotate
http://svn.gnome.org/viewcvs/gimp/trunk/plug-ins/common/despeckle.c?annotate=16861)
- [select for diffs]
http://svn.gnome.org/viewcvs/gimp/trunk/plug-ins/common/despeckle.c?r1=16861view=log
2005-03-11 Sven Neumann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
* plug-ins/common/despeckle.c: test intensity against white and
black level, not only the red channel. Improved border behavior.
Iterate over the pixels row-by-row, instead of jumping through the
data column-wise.
...
Revision *15374*
http://svn.gnome.org/viewcvs/gimp?view=revisionrevision=15374 -
2004-10-30 Sven Neumann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
* plug-ins/common/despeckle.c: applied a patch from Geert Jordaens
that improves the Despeckle algorithm. See bug #72862
http://bugzilla.gnome.org/show_bug.cgi?id=72862.
Right now I don't have the tme to followup a bug report or create a complete
patch.
for (v = ymin; v ymax; v++)
{
gint off2 = v * width * bpp;
for (u = xmin, off2 += xmin * bpp; u xmax; u++, off2 += bpp)
{
guchar value = pixel_luminance (src + off2, bpp);
/*if (value black_level) Allow no histogram correction on line
art or bw*/
if (value black_level filter_type FILTER_ADAPTIVE)
{
hist0++;
}
/*else if (value white_level) Allow no histogram correction on
line art or bw*/
else if (value white_level filter_type FILTER_ADAPTIVE)
{
hist255++;
}
else
{
buf[count] = src + off2;
ibuf[count] = value;
count++;
}
}
}
Geert Jordaens
Luis A. Florit wrote:
Pals,
I reported this bug in this list some time ago, and got no
answer (I think), and the 2.3.16 version still has the same bug:
The despeckle plugin shifts the image one pixel to the right,
and one to the bottom. Consequently, it is essentially useless.
If you draw in the middle of a white background a black cross
like this:
x
xxx
x
and run the despeckle plugin with radius 1, you get this asymmetric
output:
x
xxx
xx
Thanks,
Luis.
___
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] Pixel coordinates input type for script-fu?
On Tuesday 01 May 2007 00:15, Mark Lowry wrote: I'm working on a script in which it would be advantageous to use the mouse to click on an image and have the pixel coordinates captured as an input. Right now I have to manually enter the coordinates for four points, which is a tedious process. Is there a way to capture these coordinates as inputs to a script? If not, where is the appropriate place to suggest a feature request for this? Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -- Thanks . Mark __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] still the same bug
From: Luis A. Florit [EMAIL PROTECTED] For Bill: [...] Well, I am really tired about reporting bugs at Bugzilla and not even getting an answer, specially for Fedora bugs. [...] Fedora maintainance sucks. Please don't judge GIMP's bug handling by Fedora. For gg: I suspect it got ignored since one pixel offset errors are pretty much to be expected. ???!!! Well, now this answer was indeed unexpected! For me this kind of bugs is enough reason to never use a program!!! You cannot apply a filter with masks if it has shifts! As I wrote before, you are quite correct, and gg is wrong here. Rounding errors are to be expected every so often, although they should be fixed when they are found if possible, but a systematic 1-pixel offset in a filter is a serious bug that must be fixed. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Help - gimp-plugin-template development on olderLinux.
From: G Bulmer [EMAIL PROTECTED] I am attempting to write a gimp plugin to 'bridge' between the gimp and a 3rd party piece of technology, under Linux. [...] My users need to stay with their currently deployed versions of software including the gimp (2.0.5) [...] If the code for your plugin will fit into a single C file, it is a lot simpler to build and install it using the gimptool-2.0 --install command. As a framework for such a plug-in, you could start with pretty much anything in plug-ins/common in the GIMP source code -- you have to remove a few lines involving internationalization to get a plug-in to compile using gimptool --install, but it isn't very difficult. Also, you can find quite a number of plug-ins in the registry (registry.gimp.org) that are specifically written for GIMP 2.0, if you want a better starting point. Many are single-file plug-ins that you install using gimptool, but a few are more complex. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
From: Mark Lowry [EMAIL PROTECTED] I'm working on a script in which it would be advantageous to use the mouse to click on an image and have the pixel coordinates captured as an input. Right now I have to manually enter the coordinates for four points, which is a tedious process. Is there a way to capture these coordinates as inputs to a script? If not, where is the appropriate place to suggest a feature request for this? GIMP Bugzilla is the place to request features, but it is often helpful to discuss them on this list first, as you are doing. As Joao said, the functionality doesn't exist right now. I wonder if the best way to get it would be to use sample points, which you can create by Ctrl-clicking on a ruler and dragging into the image, and can even move around after they have been created, by activating the Color Picker tool and click-dragging a sample point. Sample points are a new feature, and code hasn't yet been written to allow a plug-in to request the list of sample points belonging to an image, but it would be pretty straightforward to do so. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
On Tue, 01 May 2007 18:08:35 +0200, William Skaggs [EMAIL PROTECTED] wrote: From: Luis A. Florit [EMAIL PROTECTED] For Bill: [...] Well, I am really tired about reporting bugs at Bugzilla and not even getting an answer, specially for Fedora bugs. [...] Fedora maintainance sucks. Please don't judge GIMP's bug handling by Fedora. For gg: I suspect it got ignored since one pixel offset errors are pretty much to be expected. ???!!! Well, now this answer was indeed unexpected! For me this kind of bugs is enough reason to never use a program!!! You cannot apply a filter with masks if it has shifts! As I wrote before, you are quite correct, and gg is wrong here. Rounding errors are to be expected every so often, although they should be fixed when they are found if possible, but a systematic 1-pixel offset in a filter is a serious bug that must be fixed. -- Bill Since everyone seems to quoting what I wrote but only reading half of the sentence I probably should explain what I meant. Please note the I suspect it got ignored since. As Bill says here systematic offsets are a bug that should be fixed but random rounding errors are unavoidable in many cases. That means they should be random ie in both directions and not trucations errors always in one direction or a definite pixel offset. There is an underlying issue where both origin and offset of a region are stored as gint before any processing is done. This means two rounding and/or trucation errors can easily end up producing a one or two pixel error. I'm rather surprised that anyone following this list should mistake my position since I have been quite critical of just this kind of point, even in the last 7 days. Now Luis has given a specific case and replied to my request for the filter settings needed to reproduce it, it seems to be getting the attention he felt it missed last time. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
As mentioned previously on this list, I would also like to develop a plug-in with similar pixel coordinate requirements. For my purposes, using the color picker would be an extremely ugly and practically unusable hack. I really need to get the coordinates directly and on the fly from the plug-in, as in click on button on plug-in's user interface to initiate pixel selection, then click in image (or preview?) to return coordinates to plug-in. Kevin M. - Original Message - From: William Skaggs [EMAIL PROTECTED] To: gimp-developer gimp-developer@lists.XCF.Berkeley.EDU Sent: Tuesday, May 01, 2007 11:52 Subject: Re: [Gimp-developer] Pixel coordinates input type for script-fu? From: Mark Lowry [EMAIL PROTECTED] I'm working on a script in which it would be advantageous to use the mouse to click on an image and have the pixel coordinates captured as an input. Right now I have to manually enter the coordinates for four points, which is a tedious process. Is there a way to capture these coordinates as inputs to a script? If not, where is the appropriate place to suggest a feature request for this? GIMP Bugzilla is the place to request features, but it is often helpful to discuss them on this list first, as you are doing. As Joao said, the functionality doesn't exist right now. I wonder if the best way to get it would be to use sample points, which you can create by Ctrl-clicking on a ruler and dragging into the image, and can even move around after they have been created, by activating the Color Picker tool and click-dragging a sample point. Sample points are a new feature, and code hasn't yet been written to allow a plug-in to request the list of sample points belonging to an image, but it would be pretty straightforward to do so. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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] still the same bug
From: [EMAIL PROTECTED] There is an underlying issue where both origin and offset of a region are stored as gint before any processing is done. This means two rounding and/or trucation errors can easily end up producing a one or two pixel error. Yes, but there are other basic coding errors that can easily cause a filter to shift its result by one pixel, too. I'm rather surprised that anyone following this list should mistake my position since I have been quite critical of just this kind of point, even in the last 7 days. I actually understood what you *meant*, but what you *said* to Luis was misleading and needed to be corrected. Now Luis has given a specific case and replied to my request for the filter settings needed to reproduce it, it seems to be getting the attention he felt it missed last time. Well, it's getting attention, but it probably won't get fixed unless there is a bug report. By the time people get back from LGM, all this discussion will have disappeared in Dev-list limbo, and probably nobody is going to go back and re-read it. (Unless you fix it yourself, gg :-)). -- Bill gg __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
--- Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -- I have thought about doing that and I think that is the way I will have to go. I'm confused with how to extract elements from the vector returned by gimp-path-get-points. I thought I understood that (vector-ref vector k) was the way to pull the k-1 element from the vector, but when I input (vector-ref '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on vector-ref. What do I need to do to be able to extract a value from the result of (gimp-path-get-points image path)? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
Glad you all confirmed the bug, and sorry gg if I misunderstood you. However, I am not sure what histogram correction means here. I saw the same shift in the despeckle plugin for photographies, like a human face. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Help - gimp-plugin-template development on olderLinux.
I am attempting to write a gimp plugin to 'bridge' between the gimp and a 3rd party piece of technology, under Linux. [...] My users need to stay with their currently deployed versions of software including the gimp (2.0.5) [...] If the code for your plugin will fit into a single C file, it is a lot simpler to build and install it using the gimptool-2.0 -- install command. I'll work through some examples using the gimptool-2.0, but I don't think it is enough for the proof of concept. Unfortunately, the technology I'm bridging too isn't quite C/C++, though it does implement an 'extern C' calling interface, and does follow gcc ABI. But, I don't see a sure-fire way to build a plugin bridge within a single file, and even if I can do it somehow, it may be more clunky that having a multi-file build. This is only part of the complexity I need to sort out; there may be lots of other fun ways for it to break, it might have alternative, incompatible, implementation of library functions !-) That's what I'll find out. As a framework for such a plug-in, you could start with pretty much anything in plug-ins/common in the GIMP source code -- you have to remove a few lines involving internationalization to get a plug-in to compile using gimptool --install, but it isn't very difficult. Okay, I'm usually good at removing stuff. Also, you can find quite a number of plug-ins in the registry (registry.gimp.org) that are specifically written for GIMP 2.0, if you want a better starting point. Many are single-file plug-ins that you install using gimptool, but a few are more complex. Ah! That feels like a great starting point. I've just had a quick dig through registry.gimp.org, and refocus-it looks like a 2.0 compatible multi-file build plugin, so I'll look at that. Thank you for the help. GB ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
On Tuesday 01 May 2007 17:05, Mark Lowry wrote: --- Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -- I have thought about doing that and I think that is the way I will have to go. I'm confused with how to extract elements from the vector returned by gimp-path-get-points. I thought I understood that (vector-ref vector k) was the way to pull the k-1 element from the vector, but when I input (vector-ref '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on vector-ref. What do I need to do to be able to extract a value from the result of (gimp-path-get-points image path)? oh man.,.. 2 things: 1) I do python-fu, not Scheme (script-fu) - so I have erased from my mind the esoteric ways of getting elements out of a vector or array in Scheme. btw, if your plug-in is of any complexity, unless you think your time is being well spent as you exercise your mind around how to get and use data with scheme expressions as an extra exercise, I'd suggest writting it in python. If you are on windows, that will only work witht he developemtn version of GIJMP, though. But it has the advantadge of letting you worry with your problem instead of the language _and_ your problem. 2) this very API is being obsoleted in GIMP 2.3.x - there are all new vector manipulation calls in place, that can finally deal correctly with multiple stroke vectors (not needed to fecth just one or two coordinates anyway) In python, an interactiuve session exploring the return values might just display: img = gimp.image_list()[0] pdb.gimp_path_get_points (img, a) (1, 0, 15, (103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 529.480002, 102.039996, 1.0, 529.27428571428572, 101.679995, 2.0)) v = pdb.gimp_path_get_points (img, a) points = v[3] points (103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 529.480002, 102.039996, 1.0, 529.27428571428572, 101.679995, 2.0) points[0], points[1] (103.03428571428572, 101.01142857142861) (the are the prompt, not part of the language) -- Bill...could you see if it iyou can add a simple api for retrieving the sample points? I think this will bother no one at this point, it is starightforward as you said, and...we want to get 2.4 out, so it has to be done real soon. js -- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
