On 11-07-09 03:47, Nicolas Robidoux wrote:
> Let me try to explain the motivation for having different methods for
> transformations which are tuned for upsampling on the one hand, and
> downsampling on the other, and why a "one size fits all stylishly"
> scheme is neither easy to put together nor
Let me try to explain the motivation for having different methods for
transformations which are tuned for upsampling on the one hand, and
downsampling on the other, and why a "one size fits all stylishly"
scheme is neither easy to put together nor likely to be fast.
Practical explanation:
If one
Geert Jordaens writes:
> I do not see any reason why one would have to specify up or downsize in
> the parameter since this can be determined from the in and output size,
> what about translations?
All the "to be named" samplers can be used for arbitrary warps, and
all can be used for upsamp
On 10-07-09 16:39, Nicolas Robidoux wrote:
> Most likely names of the resamplers at this point are either:
>
> upsharp and upsmooth
>
> or
>
> sharpupsize and smoothupsize
>
> for the samplers tuned for warps in which upsampling is more typical
> than downsampling (e.g., for image enlargement), and
Most likely names of the resamplers at this point are either:
upsharp and upsmooth
or
sharpupsize and smoothupsize
for the samplers tuned for warps in which upsampling is more typical
than downsampling (e.g., for image enlargement), and either
downsharp and downsmooth
or
sharpdownsize and
On Wed, Jul 8, 2009 at 1:08 PM, Nicolas
Robidoux wrote:
> PS
>
> Let me know if you'd rather I think about all this off list.
I dislike writing email, and you are almost using email like IRC, feel
free to continue but do not expect much response from me in particular
:d
/pippin
--
«The future
sharpsmall and smoothsmall
and
sharpbig and smoothbig
?
In a "scale image" menu, the most likely appropriate method could be
chosen automatically (depending on the requested resizing), with an
"extra smoothing" toggle set by default to off.
Nicolas Robidoux
Universite Laurentienne
___
sharpEnlarge and smoothEnlarge
and
sharpShrink and smoothShrink (or sharpReduce and smoothReduce)
?
PS
Let me know if you'd rather I think about all this off list.
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.X
yahvuu writes:
>
> uh, what, me?
>
> i wouldn't want to be bothered with choosing different samplers
> for up/down-scaling.
(I'm surprised. You are always happy with the thumbnails you get?
Result after rotating an image? Maybe I'm too invested in this field
to know what matters and what m
Is it "decided" that there will be only two versions of the "good for
upsampling" sampler, and only two versions of the "good for
downsampling" sampler as well?
Because if it is, Eric's nohalo1 and snohalo1 patches could be made
"ready to push" in very little time, and the preliminary version of
hi,
Nicolas Robidoux schrieb:
> Can you (yes, I mean you) think of better names?
uh, what, me?
i wouldn't want to be bothered with choosing different samplers
for up/down-scaling.
So just let me choose from matching pairs of samplers.
You know them better than i do...
greetings,
peter
_
Øyvind Kolås writes:
>
> The names for samplers would need some serious thought, linear, cubic
> and lanczos in current GIMP is already too techical for many users,
> most people would have no clue what "box" refers to in the suggested
> names. When exposes as for instance a drop down in the
On Wed, Jul 8, 2009 at 8:43 AM, Nicolas
Robidoux wrote:
> Suggestion implementing the s/nohalo family and the nohalobox family
> without an explicit, visible, parameter:
>
> Would it be possible/desirable to use the current code (which has a
> parameter) as some sort of template?
Sure, for most us
Suggestion implementing the s/nohalo family and the nohalobox family
without an explicit, visible, parameter:
Would it be possible/desirable to use the current code (which has a
parameter) as some sort of template?
Then, the nohalobox code would produce four independent samplers:
sharperbox ->
On Tue, Jul 7, 2009 at 11:31 AM, Øyvind Kolås wrote:
> I would feel more comfortable if this parameter was not exposed, but
> rather that sane presets were added and given names. In most cases the
> additional properties of for instance a displacement map operation
> might be visual and conceptual
Nicolas Robidoux writes:
>
> For example, nohalo1 (same result as snohalo1 with smoothing = 0, but
> runs faster) would be "sharper", snohalo1 with smoothing = 1 would be
> "smoother", and snohalo1 with smoothing = .5 would be "halfandhalf,"
> or something kind of like that?
If there were o
Øyvind Kolås writes:
>
> I would feel more comfortable if this parameter was not exposed, but
> rather that sane presets were added and given names. In most cases the
> additional properties of for instance a displacement map operation
> might be visual and conceptual clutter getting in the
On Tue, Jul 7, 2009 at 10:25 AM, Nicolas
Robidoux wrote:
>
> Adam Turcotte and Eric Daoust are implementing samplers (alternatives
> to nearest neighbour, bilinear, bicubic, lanczos... interpolation),
> names snohalo1 (tuned for upsampling) and nohalobox (tuned for
> downsampling), which both have
Adam Turcotte and Eric Daoust are implementing samplers (alternatives
to nearest neighbour, bilinear, bicubic, lanczos... interpolation),
names snohalo1 (tuned for upsampling) and nohalobox (tuned for
downsampling), which both have a natural parameter. This parameter is
basically the amount of ex
I have added a parameter (called blur) to a new sampler, and I want to
pass a value to this parameter when rotating with an XML file.
I know how I would pass a value to the rotation parameters, but how do
I pass a value for a GeglSamplerNohalobox parameter?
Here is an example of a rotation test:
20 matches
Mail list logo
