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.)
--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
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.
(Wearing a blue hawaiian shirt today)
Gimp-developer mailing list