Re: [Oiio-dev] Review: filters updated: sinc, blackman-harris, gaussian
On Wed, Aug 31, 2011 at 6:08 PM, Larry Gritz l...@larrygritz.com wrote: There is no specific goal to match any other application, but the filtering is tricky and easy to get wrong (as I have clearly botched it in this case, despite having written it many times over 25 years!). So when we match the results of another application that is written by smart people (including, sometimes us, in other products or companies), it raises our confidence that we've done it correctly this time. When several allegedly-smart products each gets a completely different answer, it makes me very nervous about assuming that we are somehow the one group to get it right. Oh I know that one... I notice the definition for Lanczos3 for instance is not my expected windowing function which is something more like: sinc(position) * sinc(position / size) where size = 3 for a 3 lobed window. Um... I think we're correct, and Jeremy says we match several other smart apps now... Glancing at the code myself, I clearly see our lanczos3 implementation returning a/(pi*x)^2 * sin(pi*x)*sin(pi*x/a) = sinc(x) * sinc(x/3) (for normalized sinc, a=3) having looked at this, I guess I should have looked at expanding the formula... I agree it is the same... I've just never had to expand the sync() functions for either accuracy or speed, when re-sampling an image I just cache the filter results, although that won't work for arbitrary transforms, it works well for typical resizing usage. Also i wondered what the 'phase' of the filters does the implementation sample at - does it always results in all pixels being filtered when exactly halving/doubling, or does the filter only effectively sample at 0.0 and thus return a single sample for half the outputs? (Once I have it compiled, I can obviously run it to find out, there appears to be a lot of +/- 0.5s in the code and I'm not as good as the compiler :-). Sorry, I'm not exactly sure I understand the question. Jeremy's answer suggests that the implementation samples the filters in the same way, Shake or Nuke would do. I ask because recently we came across a production that was handing us both '4K' EXR and '2K' DPX files, unfortunately they used a tool that did not use the pi/4 offset to reproduce the 2K and so to reproduce the 2K DPX files from the EXRs we had to factor that into our system. Visually, sampling on the pi/4 offset looks much nicer, especially if the original was not band limited correctly in the first place (in this exact halving situation you can end up with alternate pixels being 'impulse' filtered). Anyway, I finally beat cmake into submission and built the code pointing to our preferred libraries, I'll move onto testing it and then OpenColorIO Thanks Kevin ___ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Re: [Oiio-dev] Review: filters updated: sinc, blackman-harris, gaussian
Hi, being new to the list, please forgive me if I've missed something, is the goal to match existing apps in general or just to match specific applications as a reference? I notice the definition for Lanczos3 for instance is not my expected windowing function which is something more like: sinc(position) * sinc(position / size) where size = 3 for a 3 lobed window. Also i wondered what the 'phase' of the filters does the implementation sample at - does it always results in all pixels being filtered when exactly halving/doubling, or does the filter only effectively sample at 0.0 and thus return a single sample for half the outputs? (Once I have it compiled, I can obviously run it to find out, there appears to be a lot of +/- 0.5s in the code and I'm not as good as the compiler :-). Thanks Kevin On Wed, Aug 31, 2011 at 2:12 AM, Jeremy Selan jeremy.se...@gmail.com wrote: https://github.com/OpenImageIO/oiio/pull/157 The math and filter radii have been updated for a bunch of filters to better match existing performance in other common applications. (The biggest change being sinc, which is now much sharper.) Filter results comparison: pow2 downres (4K - 128 tested) - katana 2.7.12 - ImageMagick 6.3.6 - prman 16.0 txmake box: oiio, prman, katana, imagemagick match lanczos3: oiio, katana, imagemagick match. prman is far sharper (perhaps lanczos2?) sinc: oiio, prman match. Katana is slighly softer. imagemagick is much softer blackman harris: all differ. In order of decreasing sharpness... imagemagick, oiio, prman catrom: oiio, imagemagick, prman match gaussian: oiio, prman, katana roughly match. imgmagick is sharper -- Jeremy ___ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org ___ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
Re: [Oiio-dev] Review: filters updated: sinc, blackman-harris, gaussian
being new to the list, please forgive me if I've missed something, is
the goal to match existing apps in general or just to match specific
applications as a reference?
Hello!
In my opinion, the goal is firstmost to be 'right'. So thanks for
your extra set of eyes. :)
Of course, sometimes it's hard to verify what 'right' is, so next best
is to settle for 'matches everything else out there'. :)
Even if we've gotten the filter kernel math correct, there's other
parts in the codepath that can lead to differing results. Thus, it's
a really good sanity check to see how our results compare against
other implementations people may be using alongside OIIO. In the case
of OIIO's maketx, the typical alternative would be txmake that ships
with prman. So it made sense to see how our filtering results
compare. Also, internally we have an image processing tool, Katana,
which we've trusted for a long time. So it also makes sense to compare
against that.
Are there any other applications, or known reference filtering
results, that you'd trust? (I threw in imagemagick as well into the
comparison mix, as they have nice support for kernels and I was
curious how their tool performed.) Maybe something more scientific,
such as matlab?
I notice the definition for Lanczos3 for instance is not my expected
windowing function which is something more like:
sinc(position) * sinc(position / size)
where size = 3 for a 3 lobed window.
I believe we are using your definition of lanczos3. We've just
expanded it to the underlying implementation that calls 'sin', not
'sinc'. See http://en.wikipedia.org/wiki/Lanczos_resampling, where
they list the expansion:
http://upload.wikimedia.org/math/0/9/e/09ec679a25f4b98dc7d2b8e5dd07a488.png
The math we're using is: src/libutil/filter.cpp
static float lanczos3 (float x) {
const float a = 3.0f; // Lanczos 3 lobe
x = fabsf(x);
if (x a)
return 0.0f;
if (x 0.0001f)
return 1.0f;
const float m_pi = float (M_PI);
const float m_piinv = 1.0f / m_pi;
const float ainv = 1.0f/a;
float pix = m_pi * x;
return (a*m_piinv*m_piinv)/(x*x) * sinf(pix)*sinf(pix*ainv);
}
Please let me know if you think we're in error.
Also i wondered what the 'phase' of the filters does the
implementation sample at - does it always results in all pixels being
filtered when exactly halving/doubling, or does the filter only
effectively sample at 0.0 and thus return a single sample for half the
outputs? (Once I have it compiled, I can obviously run it to find out,
there appears to be a lot of +/- 0.5s in the code and I'm not as good
as the compiler :-).
These are where the lanczos3 function (as implemented above) is being
queried. Note that we scale x by pi, so you can really think of this
as pi/4, 3pi/4, etc.
x 0.25 y 0.890067
x 0.75 y 0.27019
x 1.25 y -0.132871
x 1.75 y -0.0677913
x 2.25 y 0.0300211
x 2.75 y 0.00735591
-- Jeremy
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
