Hello all:

I mentor two GEGL-related GSoC projects this Summer, and would like to
discuss some of my ideas about implementing the two projects with more
senior developers who happen to be at LGM 2009 Montreal. I'll be in
town until Sunday, and this is my priority. You may also give feedback
to this list if you have some to give, and I will read it carefully.

In all cases, pointers toward "best" implementation approach would
also be appreciated. (In most cases, we can probably figure it out
from the source code, but this only implies preferences and intent on
the part of core developers.)

Main issues:

--Desired image size convention for transformations (e.g. resize) for
  which this matters. 

  Option A: Corner

  Option B: Center
  Option C: User chooses between them

--Abyss policies for resamplers. I am not convinced that "more" is
  necessarily better.

  Option A: Minimal fast and robust: Only clamp a.k.a. nearest
  neighbour abyss (like GPUs or VIPS)

  Option B: User can toggle between clamp and constant and periodic
  (good for textures) one source at a time.

--In order for a sampler to be adaptive with respect to transformation
  features (its jacobian matrix, say), such information must be
  communicated to the sampler. Any suggestion RE: how to communicate
  such information to samplers? (We could start with affine
  transformations, in which case a constant matrix gives all the key

--Higher level nohalo/snohalo (3 and above) would be simpler to
  program if one could store one level of subdivision into a
  buffer/tile which would behave like a normal input image tile as far
  as the "final" subdivision levels go. I know this is possible to do
  in VIPS, which is quite similar internally to GEGL (John Cupitt has
  tried in the past this on other operations than resamplers). I'd
  like some guidance as to how to do this cleanly in GEGL.

  (Basically, this emulates producing a double density version of the
  input image, fixing the sampling coordinates so that they use a
  coordinate system relative to the double density image (easy), and
  then using "standard" higher level nohalo as if the double density
  image tile was a normal input tile. Of course, this requires abyss
  policies to be applied to the double density image too.)

  We can program things directly without such intermediate result
  tiles, but this quicly leads to increases in code complexity.


I don't necessarily need to fully understand the details: this will be
the job of the GSoC students. I just would like to know at least
enough to properly steer them.


Nicolas Robidoux
Universite Laurentienne
(Wearing a blue hawaiian shirt today)

Gimp-developer mailing list

Reply via email to