Legacy ImageMagick Discussions Archive

Your set up definitely has a very particular "look".
Are you sure that all you do is use linear filtering with your modified weights?

NicolasRobidoux wrote:Your set up definitely has a very particular "look".
Are you sure that all you do is use linear filtering with your modified weights?

Sorry, I forgot to mention I use some anti-ringing code internally.

I find the "texturelessness" unnatural. I personally would tone down the anti-ringing (not eliminate it: just turn it down).
Otherwise, it's an interesting approach. Good job!
(My apologies for a very cursory evaluation. No time for more.)

The anti-ringing works more or less like this:

It gets the four nearest neighbors from the point I'm sampling and choose the max and the min, per color channel. Then, the jinc2 output is clamped to that range (min,max).

By toning down, do you mean enlarging that range? Something like a new range (min - d, max + d)?

This approach is reasonable and a bit reminiscent of what is done in the LBB component of the nohalo sampler (in the GEGL and VIPS FLOSS libraries; just google nohalo image sampler).
-----
Instead of (min-d,max+d), what I would do is blend (lerp) the unclamped result with the clamped result.
I would also apply it to a different color space than (I imagine) sRGB and blend the result of clamping in this space with the one you have already. I'd start with L*a*b*.
So, you'd be blending three results to get the final result.
The reason for using a second color space is that this way you are more likely to clamp "approximately isotropically": Nothing says that the clamping is better done with the primaries: you may be dealing with blended colors. L*a*b* is sufficiently different to mix things up a little.

One thing I am curious about but have had no time to experiment with is whether such "clamping" is better done in linear light or in perceptual spaces.
Generally, upsampling (enlarging) through a perceptual space is better than linear light, at least when the filter has negative lobes. When the filter does not produce over or undershoots, however, it has been my hunch that the advantage of perceptual vs linear light when upsampling vanishes.
With an AR filter of some sort we are kind of in the latter situation. So, it could be that using, say, RGB and XYZ as color spaces in which the resampling and clamping is done would be better than using sRGB and L*a*b* with your filter.
Am I being too terse?

Thanks, Nicolas, for the suggestions.

I've implemented the blend suggestion and it indeed worked better for natural images. Though for Pixel Art (my primary need) it isn't so good, because it let escape some ringing.

Here's the images using the blend AR:







Sorry if I can't respond fast some messages. I access the forum from time to time as I constantly have to go out and can't keep a regular conversation.

Art-like images have not been studied/discussed too much on this forum. Here is the last topic of discussion. Perhaps you would like to make the study and report back.

see viewtopic.php?f=1&t=25629

Ok, I was just making an observation about pixel art. I've already developed an algorithm for that kind of image.

In this thread I'm more interested in extract the most of a Jinc2 algorithm, because for realtime applications as games, Jinc3 is a bit prohibitive yet. Actually, this Jinc2 implementation I made already works in shader format and is used in some emulators.

With the new AR (blend based thanks to Nicolas) I've found a sharp config (WA=0.9 and WB=0.4). Using the old AR, this config flattened to much the textures. Now they seem almost accetable to me:

If it is truly pixel art (as opposed to line art) see https://plus.google.com/+SevensheavenNL ... nXFi6BHJ1N.
If you really want to develop your own method from what you have already, I suggest the following:
Instead of blending with your scheme untouched by your AR method, blend with the result of a different scheme that has no, or little, halo.
Something like VSQBS = Vertex Split Quadratic B-Spline interpolation (FLOSS code in the libvips library) or, if you want to stick to something available in IM, EWA Quadratic or EWA QuadraticJinc, discussed in http://www.imagemagick.org/Usage/filter/nicolas/.
Also, my guess is that EWA LanczosSharpest 4-lobe (google: it's not a built-in method, at least not yet) would be a good candidate to use with your AR and may work well with pixel art.

Our posts crossed.
-----
Now that I understand more what you want to do, I really suggest that you try EWA with Keys cubics. This is a one parameter family of schemes which only grab data from a disc of diameter 4, the weights are cheap to compute (there is code that computes some of them efficiently in libvips and GEGL; I don't remember if or where I've put the most general/efficient code; IM can compute all BC-splines, so the code is not as optimal for Keys).
At one end you have EWA B-spline smoothing, at the other you have EWA Catmull-Rom, which is very very sharp.
Blend one used with your AR together with one, closer to B-spline smoothing (or maybe EWA Quadratic) without AR.
The special thing about EWA done with Keys cubic weights is that they almost interpolate "perfect" linear gradients exactly.

Thanks for the tips, Nicolas. I'll look into it later.

If I have news, I'll post here.

Hyllian: Apologies for telling you, of all people, about the existence of specialized pixel art shaders. (Foot in mouth disease strikes again.)

And indeed your latest scheme looks very good.

I do not know if this is relevant or beneficial, but IM -fx has j0, j1 and jinc (bessel functions). See http://www.imagemagick.org/script/fx.php

My understanding is that Catrom is the same as keys cubic convolution. I generally like its sharpness over other artifacts, but I do not have such a critical "eye" as others, especially Nicholas. But it is even obvious to me that your second set of images is clearly sharper/better than the first set of images.