Legacy ImageMagick Discussions Archive

@Fred: The programming will be horrid because among other things we need to elegantly handle cases in which the local min is exactly equal to the local max.
I read between the lines that you want to locally change the contrast value. This is not what I have I mind: I want to define the values that define the "gamut" (0-255 in sRGB) based on local mins and max on 7x7 squares centered at the input locations, and interpolate these values with bilinear to get "gamuts" at each and every output pixel location.
Too many things require careful thinking and fine tuning for me to be willing to send you on this nontrivial programming mission.
No time for this now.

@Fred: Maybe locally changing the contrast value is better than locally changing the "gamut"?

fmw42 wrote:...
What I was really hoping that there would be some way to get more sharpness without the jaggies and the other artifacts. I was hoping that one could use the same sigmoidal trick but use something further along the B+2C=1 line of cubics in the Mitchell diagram. It seems that the catrom is very sharp but I am sure for you has too much artifacts. But perhaps something past the Robidoux-Sharp would achieve a better compromise.
...

@Fred: Again, I've not tried it because I put all my energy into windowed methods with 3 or more lobes. But I've felt that actually sigmoidization could be used to take some of the jaggies and blur out of bilinear (a.k.a. IM's Triangle). Which, incidentally, is not a method with a negative lobe.
So, we are thinking similarly.
Am I right? No clue. I'd have to try it, and no time now.
Same with BC-splines: It could, maybe, sharpen Mitchell (a truly excellent method) without adding jaggies, or take the worst halos out of Catmull-Rom. If you believe in Santa. But this elf has not tried it: too busy making toys.

I tried using sigmoidal-contrast a while back with Catrom and Lagrange, but did not see much help as I recall. But it has been a while. I would have to try again. I had thought of setting up a script to process along the Keys B+2C=1 line to see what happens. But, like you, I have not had time to get back to it.

NicolasRobidoux wrote:@Anthony: I'd add Quadratic to the list of recommended windowing functions (in the plot, for example). Not sure if it's commonly used/recommended, but back of the envelope says that with lots of lobes (4+) it may work well, and that it may work OK with really sharp images with 3 lobes. (I've not tried it.) And it kind of fits nicely into the collection: Halfway between Bartlett (linear spline) and Parzen (cubic spline).

Quadratic is not a windowing function but a Guassian-like function.

I do not know of a name for a quadratic windowing filter, and as such can not add it as a 'named' filter until I do. But you can of course easily use it as a windowing filter directly, (4 lobe) with just one setting... After all I designed the settings to make this to be as easy as possible! Adding -define filter:verbose=1 shows the filter used is...

# filter = SincFast
# window = Quadratic
# support = 4
# window-support = 4
# scale-blur = 1
# practical-support = 4

anthony wrote:... After all I designed the settings to make this to be as easy as possible! ...

Indeed, it's unbelievably easy to mix and match pieces. Truly wonderful.

NicolasRobidoux wrote:I'll give a try to f(x) = x/sqrt(1+x^2) and it's inverse g(x) = x/sqrt(1-x^2), for no other reason that these functions are cheap to compute. (Yes, I know IM uses LUTs to apply sigmoidal-contrast, at least now, even in HDRI mode. I don't only program for IM.)

Strange, I didn't think it did! I hated using a LUT when a function was available, and it was only one call per pixel. But then changes have been made since that function was added.

As for other functions, I was looking at the err() function for more correct calculation of discrete gaussian kernels (1D and 2D forms).


Side track... (start a new topic if you want to explore this further.)

The reason I was looking at the err() function is that, like image pixels, convolution kernel elements represent an area, effect, and not simply a point, and as such you really need the difference of the err() function (the intergral of gaussian) rather than simply a single point on the gaussian curve.

Single point Gaussians are close but not exactly correct. It can actually produce very WRONG kernels at very small values of sigma (less than 0.5), and especially close to the origin or 0 point. The 1D blur convolutions currently (and previously) solved this by use an average of 3 Gaussian samples for each kernel element. A comment in the code said that that technique came from photoshop!

However I eventually decided NOT to use the more accurate err() function as I could NOT ensure that it was available on all computer systems IM is compiled on (mobile phones for example). Besides I had other fish to fry!

The same problems is probably also true for resampling filters (and also other functions too). A resampling filter is after all very similar to a convolution kernel, which is NOT aligned strictly on perfect element to pixel alignment. That is, the origin is not at an integer image coordinate, and spacing of elements is also variable.

However for accurate Gaussian weighting values in a filter will not only need the weight 'point' but the 'area' (or scaling factor) that the weight will be applied to. That gets even harder for That is a major API change, though it is internal API changes.

Going back to the "chip" test image, here is an 8x enlargement with the "safer" sigmoidized Ginseng. Download or view the image on its own: It's rather big, so your browser is probably cropping it.

Sure, it's not artifact free. But it's an enlargement of this:

If you are so enclined, compare with the 4x enlargements of the same test image shown at http://www.wisdom.weizmann.ac.il/~visio ... ageSR.html. (Push on the orange, green and blue buttons to display other methods than nearest neighbour, which of course is horribly aliased.)
In my book, it's no contest.

NicolasRobidoux wrote:@Fred: Maybe locally changing the contrast value is better than locally changing the "gamut"?

If you ever decide to get back to adaptive processing and need help, let me know.

Lots and lots of sample enlargements with Ginseng here: viewtopic.php?f=22&t=21804.

I tried using the inverse of x+x^3 with x=a*(x-b) instead of the logistic sigmoidal and this is a bad idea.
Maybe I should have used x+a*x^3 with x = x-b instead?
P.S. I programmed them backward.

Here is the key enhance.c code for my x+x^3 S-curve attempt, which does not seem to be something worth exploring more:

With the new IM7 LUT-free (direct) sigmoidal-contrast, the contrast values necessary to keep the halos within the limits that define the "less safe" and "safer" contrast values go down a minuscule amount: 11.6931 (down from 11.6933) and 9.52019 (down from 9.520945).

Compaisons with nearest neighbour (via the -scale IM command): http://stackoverflow.com/questions/7168 ... ion-images, courtesy of Kurt Pfeifle (CUPS).

Hi,

I'd like to post some screenshots I made after implementing jinc 2-lobe for my needs. The first thing I did was to find an approximation to Bessel function J1 for at least x<2.5. This is the function I use:
It's a sinc windowed-sinc resampler. When WA=1.0 and WB=0.5, I have a lanczos resampler. But, if I have WA~=0.825 and WB~=0.4, it approximates the Bessel function I was looking for. I made some tests and found these values better for me in subjective quality: WA=0.819893979, WB=0.39.

This screenshots were made using these last values:







I'd like to know what you think about the quality of these images (they're 4x scaled). And if the parameters WA and WB I've used for the sinc windowed-sinc resampler is degrading the images someway (as I don't see it).