Maybe credit the original algorithm creator?

NicolasRobidoux · Postby **NicolasRobidoux** » 07 Oct 2024 08:02

I understand that FLOSS (or any) devs have something else to do that properly give credit, esp. when what they did was inspired by something else than the code in which an algorithm was originally presented (when the algorithms are "third hand hand-me-downs"; maybe I should complain upstream), but for example I would have appreciated a comment to the effect that
https://code.videolan.org/videolan/libp ... quests/569
is basically my
https://www.imagemagick.org/discourse-s ... 068#p89068
and
https://code.videolan.org/videolan/libp ... quests/567
as well as
https://code.videolan.org/videolan/libp ... quests/560
are basically my
https://www.imagemagick.org/discourse-s ... 87#p128587
and
https://www.imagemagick.org/discourse-s ... 393#p78393
[CONTINUED IN A REPLY SINCE THERE'S A LIMIT ON LINKS]

NicolasRobidoux · Postby **NicolasRobidoux** » 07 Oct 2024 08:02

... More generally, quite a lot of what's in
https://code.videolan.org/videolan/libp ... type=heads
can be traced to
https://github.com/ImageMagick/ImageMag ... e/resize.c
without, sadly, some of the kernel simplifications,
https://legacy.imagemagick.org/Usage/filter/nicolas/
down to my dumb "Ginseng" pun, and
https://legacy.imagemagick.org/Usage/fi ... czos_sharp
The same goes with sigmoidization,
https://code.videolan.org/videolan/libp ... lorspace.c
which is even implemented with Anthony Thyssen's favorite slope (6.5) by default (of course this could be a coincidence: great minds yaddi yaddi yadda):
https://imagemagick.org/Usage/resize/#resize_sigmoidal
-----
Not totally sure I'm knocking at the right door here. Kindly redirect me if not. https://github.com/mpv-player/mpv?

NicolasRobidoux · Postby **NicolasRobidoux** » 08 Oct 2024 02:14

Also, I believe that I did not make the very best choice for the (de)blur that defines EWA LanczosSharp very many years ago given that the intent was

% 'No-Op' Vertical and Horizontal Line Preservation Condition: Images with
% only vertical or horizontal features are preserved when performing 'no-op'
% with EWA distortion.

https://github.com/ImageMagick/ImageMag ... e/resize.c
For EWA LanczosSharp, I suggest you find the root of

Code: Select all

def rite(r):
    return (
    (
        l(f(r)[0]) +
        l(f(r)[2]) +
        l(f(r)[5]) +
        l(f(r)[8]) +
        l(f(r)[12]) +
        2 * (
            l(f(r)[1]) +
            l(f(r)[4]) + 
            l(f(r)[10]) +
            2 * (
                l(f(r)[3]) +
                l(f(r)[6]) +
                l(f(r)[7]) +
                l(f(r)[9]) +
                l(f(r)[11])
            )
        )
    ) / (z + 4 * (
        l(f(r)[0]) +
        l(f(r)[2]) +
        l(f(r)[5]) +
        l(f(r)[8]) +
        l(f(r)[12]) +        
        l(f(r)[1]) +
        l(f(r)[4]) +
        l(f(r)[10]) +
        2 * (
            l(f(r)[3]) +
            l(f(r)[6]) +
            l(f(r)[7]) +
            l(f(r)[9]) +
            l(f(r)[11])
        )
    )))

instead of the one that's in
https://code.videolan.org/videolan/libp ... quests/569
I expect it to barely change the value, actually pushing it closer to 1. I very much doubt anybody will see a difference, but then the blur (scaling of Jinc-windowed Jinc) gives a filter that has a cleaner defining property: When used with images that are constant along columns (or rows), the blur makes the convolution, under no-op, the closest to the identity in infinity linear operator norm. So it better parallels Lanczos4Sharpest which uses the 2D version of the same principle:

-- Computation of the deblur of the EWA Lanczos (Jinc-windowed
-- Jinckernel that makes the convolution, under no-op, the closest to
-- the identity in infinity linear operator norm. Equivalently, deblur
-- that makes the weight of the center pixel equal to 1. Equivalently,
-- deblur that makes the sum of the weights of the other pixels equal
-- to zero. One may argue that this gives a good approximation of the
-- sharpest resampling Jinc-windowed Jinc kernel.

https://www.imagemagick.org/discourse-s ... 6b#p128587
Back to EWA Lanczos 3, there are various criteria that one can use to determine how to scale (blur) the EWA Lanczos kernels, and they all give, for EWA Lanczos 3, roughly the same answers (between 0.97 and 1). The defining criterion that is currently used by libplacebo and ImageMagick (to my regret) is "if an image only contains vertical (or horizontal) lines then the value along a line does not affect the two closest ones". The two above principles are equivalent if the support of the filter is contained in a (centered) square of "radius" 2 (edge length 4); the Robidoux kernel satisfies both.
(I'm totally happy with the principle I used with Lanczos4Sharpest 10+ years ago. Don't change it and thanks for the extra precision.)

Postby **Rémi Denis-Courmont** » 08 Oct 2024 03:19

It should be obvious but you're unlikely to reach libPlacebo devs on a VLC forum.

Also this is really off-topic.

The VideoLAN Forums

Maybe credit the original algorithm creator?

Maybe credit the original algorithm creator?

Re: Maybe credit the original algorithm creator?

Re: Maybe credit the original algorithm creator?

Re: Maybe credit the original algorithm creator?

Who is online