[Gimp-developer] None
__ 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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] None
Hi, Sven Neumann wrote: > "William Skaggs" <[EMAIL PROTECTED]> 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. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] None
Hi, "William Skaggs" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] None
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] None
Jo, "William Skaggs" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
