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 parameters.) --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. Thanks, Nicolas Robidoux Universite Laurentienne (Wearing a blue hawaiian shirt today) _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
