None
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| None | William Skaggs | 20 May 19:55 |
| None | Nathan Carl Summers | 21 May 19:19 |
| None | Sven Neumann | 21 May 19:31 |
| None | Nathan Carl Summers | 21 May 20:13 |
| None | Sven Neumann | 21 May 20:28 |
| None | David Neary | 23 May 21:35 |
| None | William Skaggs | 21 May 20:25 |
| None | Sven Neumann | 21 May 20:33 |
None
Hi,
I have added a plug-in to the registry (http://registry.gimp.org/plugin?id=4177) that some may find useful: it does edge detection using the "difference of Gaussians" method, which is widely used in computational vision. Basically it works by calculating two Gaussian blurs with different radius, and then subtracting them. The implementation is pretty fast because it uses the method from gauss_rle for blurring.
The motivation for doing this is that it seems to me that the existing edge detection plug-ins distributed with Gimp are rather weak in terms of output quality (their advantage is that, because they are all just 3x3 convolutions with different kernels, they are simple and very fast). I think that this DoG plug-in, and also the Thin Line plug-in from the registry (http://registry.gimp.org/plugin?id=2128) produce results that most users would be happier with.
Any feedback is welcome.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
None
On Thu, 20 May 2004, William Skaggs wrote:
The motivation for doing this is that it seems to me that the existing edge detection plug-ins distributed with Gimp are rather weak in terms of output quality
Yeah, I've never been very happy with them.
(their advantage is that, because they are all just 3x3 convolutions with different kernels, they are simple and very fast).
Since they are so similar, it might make sense to put them all in one binary. If nothing else, that way we could consolidate some menu items. We would want to continue to export a compatibible PDB API, of course.
Rockwalrus
None
Jo,
"William Skaggs" writes:
The motivation for doing this is that it seems to me that the existing edge detection plug-ins distributed with Gimp are rather weak in terms of output quality (their advantage is that, because they are all just 3x3 convolutions with different kernels, they are simple and very fast). I think that this DoG plug-in, and also the Thin Line plug-in from the registry
(http://registry.gimp.org/plugin?id=2128) produce results that most users would be happier with.
IIRC Dave did a change to the edge plug-in somewhen in the 1.3.x development cycle that incorporated code from the thinline plug-in. Doesn't that mean that it can produce similar results?
Also I remember that the plan was to move all edge algorithms into edge.c in order to obsolete the other plug-ins in the distribution. That tasks has probably not been finished before 2.0. Might be a good time to do that now.
Sven
None
On 21 May 2004, Sven Neumann wrote:
Also I remember that the plan was to move all edge algorithms into edge.c in order to obsolete the other plug-ins in the distribution. That tasks has probably not been finished before 2.0. Might be a good time to do that now.
Come to think of it, it might be benificial to put some generic convolution code in libgimp or an allied library. Just a thought.
Rockwalrus
None
Sven Neumann wrote:
IIRC Dave did a change to the edge plug-in somewhen in the 1.3.x development cycle that incorporated code from the thinline plug-in. Doesn't that mean that it can produce similar results?
Also I remember that the plan was to move all edge algorithms into edge.c in order to obsolete the other plug-ins in the distribution. That tasks has probably not been finished before 2.0. Might be a good time to do that now.
Dave did in fact move all of the edge plug-ins into edge.c, which now allows you to select among six algorithms. From the user's point of view this is merely confusing, because most of the methods give similar results and there is not even a preview to distinguish between them. In fact, some of them really have no reason to exist in the distro. The Roberts and Differential algorithms, for example, yield quite low-quality results, and have only the advantage of being 2x2 convolutions (hence very fast); but since edge.c does everything as 3x3 even this advantage is mostly lost.
The other edge-detection plug-ins in the 2.0.1 distro are Sobel and Laplace. The Sobel plug-in uses the same algorithm as the Sobel in edge.c, but allows a few extra options. The Laplace plug-in does nothing that is not included in the edge.c version.
None of them produce anything resembling the results of thinline.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
None
Hi,
Nathan Carl Summers writes:
Also I remember that the plan was to move all edge algorithms into edge.c in order to obsolete the other plug-ins in the distribution. That tasks has probably not been finished before 2.0. Might be a good time to do that now.
Come to think of it, it might be benificial to put some generic convolution code in libgimp or an allied library. Just a thought.
libgimpmath would perhaps be a good place. If you can extract some common code and give it a nice API than that would certainly be a very good idea.
Sven
None
Hi,
"William Skaggs" writes:
The other edge-detection plug-ins in the 2.0.1 distro are Sobel and Laplace. The Sobel plug-in uses the same algorithm as the Sobel in edge.c, but allows a few extra options. The Laplace plug-in does nothing that is not included in the edge.c version.
Would it be a good idea to remove Laplace and Sobel then? Perhaps after adding the extra Sobel options to edge.c?
Of course it would also be a good idea to help the user to choose a reasonable edge detection algorithm. I guess we will need a preview for this.
Sven
None
Hi,
Sven Neumann wrote:
"William Skaggs" writes:
I think that this DoG plug-in, and also the Thin Line plug-in from the registry
(http://registry.gimp.org/plugin?id=2128) produce results that most users would be happier with.IIRC Dave did a change to the edge plug-in somewhen in the 1.3.x development cycle that incorporated code from the thinline plug-in. Doesn't that mean that it can produce similar results?
Yup. thinline used 3x3 convolution kernels - a LoG is obviously a larger (although decomposable) covolution; it could be done as a script-fu, since we have both a L plug-in and a G plug-in already :)
Also I remember that the plan was to move all edge algorithms into edge.c in order to obsolete the other plug-ins in the distribution. That tasks has probably not been finished before 2.0. Might be a good time to do that now.
edge.c and sobel.c already redundancise each other. the default edge algorithm in edge.c is Sobel, and the only additions are the ability to use only vertical or horizontal components, and the fact that it affects the alpha channel.
Cheers, Dave.
