Default interpolation?
Erik Krause
does someone know what the "Default" (internal) interpolator is?
best regards
--
Erik Krause
Offenburger Str. 33
79108 Freiburg
Hans
Yes please I have also wondered about this.
Hans
PTGui Support
intention to use a different interpolator for HDR, but lanczos turned
out to work fine after all.
Joost
Hans
On Nov 12, 1:18 am, PTGui Support <supp...@ptgui.com> wrote:
> Currently this is just Lanczos. It was added in for PTGui Pro, with the
> intention to use a different interpolator for HDR, but lanczos turned
> out to work fine after all.
>
things it is not supposed to do.
I have seen too many oversharpend panoramas.
Hans
Eric O'Brien
If Hans is correct, it looks like we could use the addition of a "non
sharpening" interpolation algorithm. Umm... which one(s) of the
zillions would it be??
And, would some algorithms be preferred for "larger" source images?
A full frame digital SLR has a whole heck of alot of pixels in it.
I also understand that some algorithms are preferred when reducing
images. I would bet that many folks are not stitching at the
"Optimum" (maximum best) size, so PTGui would be down-sampling the
source image as part of the process.
eo
John Houghton
pano12.dll. I rotated an image eight times by 45 degrees and compared
the (same size) result to the original image, with a view to seeing
which did the least damage. After seeing the results, I must say I am
at a loss to understand why there are so many options provided. Many
are clearly non starters, unless you are after unusual effects. As
Hans suggested, the PTGui default interpolator (Lanczos) is certainly
not one of the best, unless you are after a modicum of sharpening in
your result.
In my particular test, these did best (fastest to slowest):
poly3
spline36
spline64
sinc256
sinc1024
Lanczos3
Blackman/sinc
More searching tests would no doubt find more differences between
them, but I standardised on spline36 long ago and for the moment I see
no reason to change. The last three are very slow.
John
>
> - Show quoted text -
Erik Krause
> In my particular test, these did best (fastest to slowest):
>
> poly3
> spline36
> spline64
> sinc256
> sinc1024
Theses are non-antialiasing interpolators with a fixed kernel size.
> Lanczos3
> Blackman/sinc
These are anti-aliasing interpolators where the kernel size changes.
A speed test between those two groups is not possible. The outcome of
the second group depends on the used kernel size, which is calculated
dynamically by the algorithm. Two years ago I did a quick test which
used a less artificial setup:
--snip
Ok, I've done a quick test on my machine. The results are quite
surprising. Here the list for a remap from 4000x2000 equirect to 6
cubefaces with 1200x1200 each. I've used a modified version of my
cubefaces batch file with fast transform turned off.
filter number and execution time (mm:ss,0)
0 00:41,9
1 00:40,1
2 00:43,6
3 02:28,9
4 00:46,7
5 00:37,8
6 00:37,2
7 05:32,6
8 00:41,8
9 00:41,8
10 00:41,9
11 00:41,6
12 00:42,0
13 00:41,6
14 00:41,6
15 00:41,6
16 00:41,6
17 00:41,7
18 00:42,1
19 00:44,9
20 00:43,8
21 00:42,9
Filter 8 to 21 are the new anti-aliasing filters. Interesting that
only the older low quality interpolators poly3, bilinear and nearest
neighbor are slightly faster. The sinc filters are significantly
slower...
--snap
You can read the thread in context on
http://www.panotools.org/mailarchive/msg/41713
since there are some interesting replies (for example on the
uncomparability ;-)
More information on the anti-aliasing filters on
http://wiki.panotools.org/PanoTools_Anti_Aliasing_Filters
best regards
best regards
--
http://www.erik-krause.de
PTGui Support
is indeed the most neutral.
When downsampling, a slightly sharpening interpolator usually gives
nicer results (CS3 also recommends to use Bicubic Sharper for
downsizing). This is one of the reasons for making it the default in
PTGui. But the default can be changed easily.
Joost