Re: gaussian reduce operator, and GIMPGEGL operator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



---- "Øyvind Kolås" <pippin@xxxxxxxx> wrote: 
> On Thu, Mar 29, 2012 at 4:12 PM,  <bootch@xxxxxxxxx> wrote:
> > This message has two subjects.
> > 1. Is there a gaussian reduce operation in GEGL?  Refer to the paper by Burt and Adelson, 1983, where it is called REDUCE and apparently claims that it is faster than operation gaussian blur followed by down-sample (scale by 1/2).  Used in the production of a gaussian pyramid.  It seems to me to be a fundamental operation and should be in GEGL.  A search shows that the operation mantiuk06 for GSOC might have generated gaussian pyramids but AFAIK did not expose reduce() as a operation.  There is also a corresponding inverse operation EXPAND, which is useful in generating a Laplacian pyramid.  I have a use for a gaussian pyramid and might consider implementing gaussian reduce for GEGL (instead of the naive approach of using gaussian blur followed by scale.)  The gaussian and laplacian pyramids are used in texture synthesis and image compression.
> 
> There is no such op at the moment, but it does sound like something
> that would be a useful building block for other things.
> 

!? Nevermind: I think the gegl:scale with filter=cubic might be the same as reduce.   I will study more.

> > 2. A few weeks ago I posted to GIMP-dev list about https://github.com/bootchk/pluginGEGLpluginGIMP a GEGL operation that lets you used GEGL in GIMP plugins written in Python and using Pygegl binding.  Its not in the form of a proper patch to GEGL but I would make a patch if I thought it would help anyone to evaluate whether it should be part of GEGL.
> 
> The proper migration of GIMP to GEGL has ramped up significantly the
> last month, in GIMP-2.10 the tile based drawable API will be marked as
> deprecated and the official way for plug-ins to interact with the GIMP
> core will be through GeglBuffers, for a very simple example see this
> file:
> 
> http://git.gnome.org/browse/gimp/tree/plug-ins/common/goat-exercise.c?h=goat-invasion
>

OK.  It is not clear to me that the new API using GeglBuffers will let Python plugins use GEGL, 
only C-language plugins, unless there are more changes to, for example, the GIMP PDB or to Pygimp.
But I understand it is not high priority, since few GIMP plugin developers, using Python and Scheme, need direct access to GEGL?  
I suppose the guiding principle is that fundamental filter operations should be GEGL plugins written in C.  
But why should non-fundamental Python GIMP plugins need to go through the PDB to get to GEGL?  
I suppose the architecture of GIMP plugins is of no concern to GEGL, and I am not an expert.

Anyway, I will defer until after 2.10.

> /Øyvind K.
> -- 
> «The future is already here. It's just not very evenly distributed»
>                                                  -- William Gibson

_______________________________________________
gegl-developer-list mailing list
gegl-developer-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gegl-developer-list



[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux