Legacy ImageMagick Discussions Archive

I put a version NOT DOUBLE CHECKED of resize.c at the usual http://web.cs.laurentian.ca/nrobidoux/misc/IM/ with the following features: 1) I have eliminated SincPolynomial, basically by replacing Sinc with a version of it with tolerances tighter than they were before. I have not triple checked the t...

Suggestion: It appears to me that there is no benefit to computing filter coefficients at long double accuracy, ever. For one thing, most of them have been computed using double precision math.c routines, not their long (C99) versions, and nobody, apparently, has complained (unless there is some ove...

I double checked with Dr Ralf Meyer (who knows better about the standards and how modern compilers/chips behave under the hood than me) and my insistent explicit casting of MagickRealTypes to doubles prior to plugging into sin, cos etc was redundant: Basically, math.h REQUIRES the input to be cast t...

May I suggest calling the polynomial approximations "Sinc" and their more accurate versions "SincTrigonometric"? (!) My thoughts exactly. Though explaining this complication in IM examples will be tricky, especially now you can lookup exactly what functions were selected using t...

NicolasRobidoux wrote: (Forgive me if I'm preaching to the converted.)

Apologies: I now realize that I was preaching to the Pope

-----

This is interesting: What it says is that when resampling RGBA (say) must be treated kind of like CMYK.

ASIDE: currently it switches automatically between EWA and Interpolation depending on if the pixel area is becoming enlarged or not. I would guess you know this already (I suppose I could figure it out by looking at the code): Filters generally have a "normalized scaling most appropriate for t...

Just to make sure there is no confusion: All my suggestions so far where "using a kernel function as a weighing function" (Michell-Netravali is normally used "the other way"): Over the support, give weights to input pixels p(x_i,y_j) based on their relative position (x_i,y_j) w.r...

In cylindrical filters the Bessel (Jinc()) function is generally used instead of Sinc. Basically it is a single pass filter using a circular (or elliptical) weighted sampling of the pixel neighbourhood, instead of a 2 pass linear sampling. It is used for image distortions where rotations can be inv...

Of course I'd be delighted if the Poor Man's Sincs became the Sinc defaults, and "standard trig sincs" became SincTrigonometric.

May I suggest calling the polynomial approximations "Sinc" and their more accurate versions "SincTrigonometric"? (!) My thoughts exactly. Though explaining this complication in IM examples will be tricky, especially now you can lookup exactly what functions were selected using t...

As such for 'typical' resizing and distorts, the caching vastly reduces the cost of trig functions. Only in the extreme case where 'caching' provides little benefit, does the polynomial form show a major improvement. However that does not mean we would not want to make use of the improvements. Espe...

A "less bad" idea: Try lanczos2(r^2) with support up to r^2=2. (Again, my understanding of cylindrical is a bit primitive, which is why I'd need a new grad student to explain things to me, but if it's easy to try things...) And, of course, Chantal and I can provide ridiculously cheap accu...

P.S. My suggestion below is a BAD IDEA. Ignore it! However while lots of information is available for 2-pass orthogonal filters and the many alternatives, very little is available on 2D cylindrical variants. For example a 2D Lanczos equivalent (Bessel windowed Bessel???) could generate much better ...

Just a suggestion:

Maybe it's time to give me commit privileges.

anthony wrote:Take a look at the new 'Gaussian' filter change report.

I don't understand: I checked svn carefully, and I don't see any change.