madVR - high quality video renderer (GPU assisted)

[Blight]

madshi:
I'm investigating the option to port some of ZP's MadVR OSD rendering to add side-by-side 3D support.
So far, other than a negligible CPU overhead, it seems to quite easy to implement.
The question is, wouldn't it be better to do it on the renderer rather than the player?

Here's what I'm experimenting with (not sure it's the best approach, as I lack the 3D hardware for testing):
I took the OSD image, made sure its width is mod 2 (to simplify things) and then what I do is this:
I split the source image into two by taking every alternating vertical column of pixels, one column for the left eye and the next for the right-eye and splitting the source images into a left/right eye images.
Then I half the X-Offset to compensate for the left/right scaling being performed on the target device and place the left image.
For the right-eye image, I add half the video's width and half of the x-offset.

Here's how it looks like:
http://zoomplayer.com/pix/3d_test.png

What do you think?

P.S.
I noticed in the OSD API's code there is an option to define a 'left' and 'right' bitmap for 3D.
Does this code do anything or is it just a place holder for now?

[6233638]

I did take your advice and try bicubic 75 and Mitchell-Netravali. I liked them and used bicubic 75 until recently, trying 3 tap Jinc + anti-ring for chroma now. I am just not convinced there is really a correct method. :)I can find several examples where Jinc is a bad choice for Chroma. I don't recommend it.

Now that we have the anti-ringing filter for Chroma, I don't think Mitchell-Netravali is the best choice, as its main benefit was a lack of ringing, at the expense of other areas of image quality. As I said, the anti-ringing filter changes things.

[NicolasRobidoux]

This is in a different thread than what has been talked about, but if you wanted something a) cheap b) without ringing c) reasonably smooth, even when upsampling, then I would recommend tensor quadratic B-spline smoothing.
The footprint of the filter is really really tight: It's a square with width = 3 (compare to 4 with all the bicubics).
What this scheme is: The (archetypal, meaning lost) "middle child" in the B-spline family, which goes like this: box filtering (width=1), bilinear (width=2), quadratic B-spline smoothing (width=3), cubic B-spline smoothing (width=4).
It's basically for someone who likes the standard cubic B-spline smoothing but can't stand the blurriness. The quadratic version is sharper a nudge, without introducing the "ridges" that bilinear brings to the table..
-----
But then I don't really know what video people are after, in luma or chroma.

[Blight]

One other thing I forgot,
It seems that the latest builds are slower at existing FSE compared to v0.82.5
This is most evident when opening ZP's fullscreen navigation interfaces, it takes probably 200-300ms longer for the navigation GUI to appear.

[NicolasRobidoux]

I can find several examples where Jinc is a bad choice for Chroma. I don't recommend it.Interesting. I'd love to understand why.

[madshi]

The curve is still a perfectly symmetrical S curve over the interval [A,B], not over [0,1], unless -A=B-1. So, I believe the answer to the first question is "no", the answer to the second is "yes, but maybe not the way you understand it", and to the third, "no, in a sense, but also yes, in a sense".
Although this is different than the sigmoidization I've used, I think that actually this may work better than any other fix because of the fact that conversion from Y'CbCr over and undershoots when converted to linear RGB.
I really do. I don't want to go into a big lecture as to why, because the proof (or disproof) will be in the pudding.
However, I'll also do the math for the fix that extends the S in a straight line past [0,1], in case you want to try that too. That would be my "second best fix".
I really really don't like the mirroring solution.
Thank you. I've now implemented your sigmoid function "stretching" and it seems to work well, from what I can see.

However, after testing the new sigmoidized jinc on a few sample clips I found that I had to dial the contrast down from 11.5 to 7.5 to avoid problems and even then I'm finding that there's an improvement in some situations and things get worse in other situations. So I'm not really sure right now if sigmoidization is a good idea for video playback.

For photo editing the situation is a bit different: There having a slider to play with is a great thing. For some images it improves the quality, and if it doesn't, you simply dial it down. However, a movie has tons of different scenes, some of which may benefit from sigmoidization and other scenes may get worse instead. I'm not really sure if that's an option I should offer. I'd like to offer options which in 99% of all cases at least don't make things worse. So right now I'm not sure if I'm going to offer sigmoidization as an option in future madVR builds. But I haven't fully decoded yet. Any thoughts on this?

FWIW, it seems to be a good contrast algorithm, so it will come in handy when at some point in the future I'll add contrast/brightness/color controls to madVR. So even if I don't use it for resampling, the work we've done on it wasn't in vain in any case.

I know that the focus right now is on greater things, but can anybody else check and confirm? MadVR does not work when the player is on a monitor in portrait mode for me
Portrait mode is currently not supported. It's on my (very long) to do list.

LOL, hey now.. He's Madshi to us. Maybe when you reach NicolasRobidoux's level you can get away with being on a first name basis :D
I don't care if you guys call me madshi or Mathias or Karl-Heinz-Otto, as long as I know who you mean.

I noticed in the OSD API's code there is an option to define a 'left' and 'right' bitmap for 3D.
Does this code does anything or is it just a place holder for now?
Currently it doesn't do anything. The "right" bitmap is simply ignored. It's a placeholder for the future.

[NicolasRobidoux]

Mathias:
If I have time (probably not), I'll have to think about the consequences of 4:2:0 w.r.t. to filter choice.
-----
What I'm focusing on now is Y'CbCr, which in my understanding is the origin of the BTB and WTW in R'G'B' and linear RGB. (Almost always Y'CbCr is the "anchor" space, yes?)
While I put together the "straight line extensions" pseudocode, could you please try the following if you have a minute, and tell me how it looks:
Use sigmoidization on Y'CbCr values unmodified. No conversion to R'G'B' or RGB. Straight up.
Maybe I'm off my rocker, but in practice this may actually work well. I don't want to go into a discussion of why I think so: If it sucks, my dirty heuristics don't matter. Part of it is that I'd really like to apply sigmoidization to a luminance or luma channel, and at this point I'm willing to pay the price of not sigmoidizing in linear light, which may or may not be the best for human viewers anyway.
P.S. I'll try to wrap this up quickly. I realize that most likely you need to move on.

[NicolasRobidoux]

...
However, after testing the new sigmoidized jinc on a few sample clips I found that I had to dial the contrast down from 11.5 to 7.5 to avoid problems and even then I'm finding that there's an improvement in some situations and things get worse in other situations. So I'm not really sure right now if sigmoidization is a good idea for video playback...
I had not read yours before writing my latest.
-----
So, you discovered "the safe contrast value business".
Honestly, even 7.5 is a bit on the "showy" side.
It it was not that I want things to look noticealy better than enlarging straight through sRGB most of the time, I'd have set the recommended value lower than 7.5. At 7, or 6.5, or even 5, 4, or 3. But then you can ask: Worth it?
-----
So: No offense taken, truly.
However, please quickly document what you try or tried and what "bugged you".
-----
Should I put together the "straight line hair extensions" pseudo code, or just let it go?

[NicolasRobidoux]

Karl-Heinz-Otto:
My thought:
Put sigmoidization out there with a request for comments, after having settled yourself on a value that seems to almost never do harm. (6.5?)
Bad comments -> Bye.

[NicolasRobidoux]

KHO:

Another thing:

If you are willing to use low constrast, there comes a point where the
WTW values are fine without modifying the sigmoidal function. (The
BTB, really, are not an issue.)

That is, you can use the formulation with A=0 and B=1 (which
simplifies things a bit) and the atanh will not over or underflow ever
without any ifs or buts.

If I use that the largest WTW is 1.2143440435408780674380747705496
(this is the value you posted), you can use the "[0,1]" sigmoidal
(which is perfectly symmetrical w.r.t. black and white interchange) in
linear RGB safely as long as the contrast value a is STRICTLY LESS
than 2.4173259816672438931 (you may want to push this down a fudge).

Of course, the question arises as to whether this noticeably improves
things.

Interestingly, when sigmoidal-contrast (in ImageMagick) is actually used
to increase the contrast by modifying the color histogram (which
sigmoidization does not do ... much), contrast = 3 is considered to be
about as far as one should push things. But this is a different context.

P.S. I suck. Algebra mistake. Fixing.

[madshi]

What I'm focusing on now is Y'CbCr, which in my understanding is the origin of the BTB and WTW in R'G'B' and linear RGB. (Almost always Y'CbCr is the "anchor" space, yes?)
Yes, Y'CbCr is the usual source space. madVR can handle straight RGB sources, too, though.

could you please try the following if you have a minute, and tell me how it looks:
Use sigmoidization on Y'CbCr values unmodified. No conversion to R'G'B' or RGB. Straight up.
Have tried it now. It looks different again, some parts are less improved than with the original sigmoidization, other parts are more improved. Negative side effects are different, too. I'm not sure if this is overall better or worse.

My impression is that sigmoidization makes some lines more "focused" (which is good) but other lines less focused. It also makes some lines less aliased, but other lines get more aliased. I haven't been able to figure out whether the positive or negative changes are more prominent. It all depends on the source material, I guess.

So, you discovered "the safe contrast value business".
Honestly, even 7.5 is a bit on the "showy" side.
It it was not that I want things to look noticealy better than enlarging straight through sRGB most of the time, I'd have set the recommended value lower than 7.5. At 7, or 6.5, or even 5, 4, or 3. But then you can ask: Worth it?
The problem is that when doing sigmoidization in linear light, I only can choose a compromise somewhere between totally linear light on the one end of the scale and dramatically sigmoidized light on the other end of the scale. No matter what value I set the contrast to, I'll never end up with scaling in gamma corrected light. So I'm rather sure that whatever value I set the contrast to, compared to scaling in gamma correct light, some things will get better and others will get worse. Maybe it would be cleverer to make a slider which gradually switches betwen linear sigmoidized light on the one end of the scale, and gamma correct non-sigmoidized light on the other end of the scale. But then which contrast value to use for sigmoidization? Maybe two sliders would be necessary. But this is all getting complicated to use again...

However, please quickly document what you try or tried and what "bugged you".
E.g. try upscaling this with sigmoidized jinc:

http://madshi.net/housetop.png

The roof line gets more aliased.

Should I put together the "straight line hair extensions" pseudo code, or just let it go?
I think the current solution with the S-curve stretching is good enough for resampling. What I'm wondering, though, is how to handle true contrast changes. Maybe for that the straight line hair :) extensions would be better suited? Because a contrast change should leave white as white and black as black. So probably the outer ends of the S-curve should stay fixed at black and white, I guess. Thoughts?

Karl-Heinz-Otto
That's me!!

My thought:
Put sigmoidization out there with a request for comments, after having settled yourself on a value that seems to almost never do harm. (6.5?)
Bad comments -> Bye.
I'm not sure I can find a value which almost never does harm, when using sigmoidized linear light, because with lower contrast values I'm getting nearer to true linear light upscaling, which we both know is not very pretty.

[NicolasRobidoux]

Theorem
In order for the "[0,1]" sigmoidal to be safely used with values in the interval [A,B] (where A<=0 and B>=1), the contrast should be strictly less than

4*atanh(1/(1+2*EPSILON))

where EPSILON=min(B-1,-A)

With the values for limits on BTB and WTW when in linear RGB that Mathias provided, this means that the contrast a should be strictly less than 3.46875384788283582098.

Which turns out to be a very useable contrast value. (Although it's really "light".)

P.S. What the above does is state when there is no need stretch the S curve or add extensions. If the contrast a is 3.468753, say, no prob.

[NicolasRobidoux]

What I'm wondering, though, is how to handle true contrast changes. Maybe for that the straight line hair :) extensions would be better suited? Because a contrast change should leave white as white and black as black. So probably the outer ends of the S-curve should stay fixed at black and white, I guess. Thoughts?
Part 1: The theorem above states what values of the contrast ensure that sigmoidizing can be done safely without stretching or extensions.
Part 2: I am almost certainly going to add "hair extensions" to the ImageMagick sigmoidal-contrast tool in the future, exactly so it handles robustly out of nominal gamut values (which may occur in HDRI mode). Right now they are clamped to the equivalent of [0,1]. (Which is fine when not in HDRI mode, and does not matter in ImageMagick 6 because a LUT is used anyway. But it matters in ImageMagick 7, which is the "drastic change" alpha development version.)
The "[0,1]" version keeps things anchored at 0 and 1. Hair extensions will safely take care of out of gamut values.
When you are ready to add this tool, fire me an email. It's a quick job. I'm just juggling priorities, and nobody's breathing down my neck on this at ImageMagick, so...

[madshi]

Cool, thanks for the offer, I'll keep this in mind.

[NicolasRobidoux]

...
I'm not sure I can find a value which almost never does harm, when using sigmoidized linear light, because with lower contrast values I'm getting nearer to true linear light upscaling, which we both know is not very pretty.I cannot argue with this.
-----
As explained somewhere in the ImageMagick documentation or Forums or both:
linear light -> dark halos from hell
perceptual light -> light halos from heaven (still bad)
When using sRGB -> linear RGB sigmoidization, contrast = 7.5 is roughly (depends on the filter) where the dark halos are about as good with sigmoidization as with straight sRGB processing. But the sigmoidized light halos are then better.
Now: What this all has to do with is this: Most filters' negative lobes give horrid halos/ripples in linear light. The perceptual colorspaces, as well as the "sigmoidal" ones, produce ripples that depend nonlinearly on the pixel values (understood as belonging to linear light). sRGB does not ripple the same going into midtones from darks than it does going into midtones from light. Sigmoidal color space does not ripple the same coming from midtones as coming from the extreme values.
Now, the "sharpening" effect of negative lobe filters is somewhat proportional to the size of the ripples. So, what I just said, is that midtone features will be sharpened differently than features near the extremes of the gamut. And vice versa.
-----
This is a bit brutal. I hope it gives an idea of my fuzzy understanding of what's going.

[NicolasRobidoux]

...E.g. try upscaling this with sigmoidized jinc:

http://madshi.net/housetop.png

The roof line gets more aliased...
I've not checked yet, but I know this test image.
It is remarkable in that there already is a large amount of halo around sharp features ... which I imagine is common in video images. (Having halo already, I mean.)
OK: Apparently sigmoidization does not work so well re-enlarging images that have heavy handed sharpening or where downsampled with a heavily sharpening filter.
Good to know. (And it makes sense.)
P.S. Remember my comment about 11.5 being OK with somewhat blurry images?

[NicolasRobidoux]

Mathias:
This is a general fact about methods that aim at minimizing the introduction of halo or ripples: Many of them are "straightjacketed" when the original already has halo or ripples.
This is the case of my "Nohalo" method which is implemented in VIPS, NIP2 and GEGL.

[madshi]

As explained somewhere in the ImageMagick documentation or Forums or both:
linear light -> dark halos from hell
perceptual light -> light halos from heaven (still bad)
When using sRGB -> linear RGB sigmoidization, contrast = 7.5 is roughly (depends on the filter) where the dark halos are about as good with sigmoidization as with straight sRGB processing. But the sigmoidized light halos are then better.
Now: What this all has to do with is this: Most filters' negative lobes give horrid halos/ripples in linear light. The perceptual colorspaces, as well as the "sigmoidal" ones, produce ripples that depend nonlinearly on the pixel values (understood as belonging to linear light). sRGB does not ripple the same going into midtones from darks than it does going into midtones from light. Sigmoidal color space does not ripple the same coming from midtones as coming from the extreme values.
Now, the "sharpening" effect of negative lobe filters is somewhat proportional to the size of the ripples. So, what I just said, is that midtone features will be sharpened differently than features near the extremes of the gamut. And vice versa.
-----
This is a bit brutal. I hope it gives an idea of my fuzzy understanding of what's going.
Makes sense, but you're mostly writing about halos. Personally, that's the least important aspect of sigmoidization to me because my anti-ringing filter takes care of the halos already. I don't need sigmoidization for that. So for me the advantages of sigmoidization is that some lines are becoming more "focused" and some lines have less aliasing. Unfortunately, for some other lines the exact opposite is true.

I've not checked yet, but I know this test image.
It is remarkable in that there already is a large amount of halo around sharp features ... which I imagine is common in video images.
OK: Apparently sigmoidization does not work so well re-enlarging images that have heavy handed sharpening or where downsampled with a heavily sharpening filter.
Many DVDs are like this, with heavy halos in the source. And unfortunately even some Blu-Ray are like this. Fortunately only some.

[6233638]

Madshi, we can now open images with madVR, which seemed like it would be useful for creating quick test patterns rather that relying on compressed video, but chroma scaling options don't seem to apply to 4:2:0 JPGs. (100% quality, but 4:2:0 chroma res)

P.S. in testing this, I found some images which show Jinc to be significantly better than most Luma options, that also reinforced why I like SoftCubic as well.

Interesting. I'd love to understand why.It is often too soft, or perhaps too accurate?

Not the best example, but one where Jinc is too soft. (Lanczos is possibly too sharp though) Keep in mind that all X's should look the same.

At 400%, Nearest Neighbour:
http://www.abload.de/thumb/nnv5ly6.png (http://www.abload.de/img/nnv5ly6.png)

Jinc 3 AR:
http://www.abload.de/thumb/jf4zlo.png (http://www.abload.de/img/jf4zlo.png)

Lanczos:
http://www.abload.de/thumb/l6jx4l.png (http://www.abload.de/img/l6jx4l.png)


I would be much happier if I could use my own pattern rather than someone else's compressed video though.

[NicolasRobidoux]

Mathias:
Your response is clear.
-----
In your context, one way to describe sigmoidization is that it is a sharpening method that does NOT add more haloing.
Then, like most sharpening methods, the payback for sharpened features is occasional jaggies.
Given that you have effective halo suppression, it becomes a good question whether this is worth putting in the "general toolchain".
Or should you simply add sigmoidization as a sharpening option, or drop it and add some other sharpening method?
-----
We see eye to eye on this?

[madshi]

Madshi, we can now open images with madVR, which seemed like it would be useful for creating quick test patterns rather that relying on compressed video, but chroma scaling options don't seem to apply to 4:2:0 JPGs. (100% quality, but 4:2:0 chroma res)
Not sure, must be caused by whatever source filter is used on your PC. It probably upscales chroma internally? Don't know...

It is often too soft, or perhaps too accurate?

Not the best example, but one where Jinc is too soft. (Lanczos is possibly too sharp though) Keep in mind that all X's should look the same.
This is gaming content, though, which benefits from extremely sharp chroma upsampling. We can see with Luma resampling that Jinc often produces noticeably less aliasing than Lanczos (and before I implemented Jinc, I thought Lanczos had very low aliasing levels!). So once again the question is: Is sharpness more important or aliasing? I still believe it's a matter of taste...

In your context, one way to describe sigmoidization is that it is a sharpening method that does NOT add more haloing.
Then, like most sharpening methods, the payback for sharpened features is occasional jaggies.
Given that you have effective halo suppression, it becomes a good question whether this is worth putting in the "general toolchain".
Or should you simply add sigmoidization as a sharpening option, or drop it and add some other sharpening method?
The funny thing is that there's no direct correlation between sharpening and aliasing with sigmoidization. Some edges get sharper *and* less aliased. Some edges get softer *and* more aliased. So sigmoidization is not a sharpener, instead it's a funky swirl around edge quality algorithm. Some edges get better some get worse and there's no knowing what will happen with the next test image... :D At least that's my current impression.

[NicolasRobidoux]

Mathias:

I enlarged the lighthouse roof image 800% with "[0,1]" sigmoidization, the "slightly softer" EWA LanczosSharp with blur=.9891..., and contrast = 3.468753 (the value safe with RGB values that come from Y'CbCr). (But no ripple limiter, since I'm doing this with ImageMagick.)

Before giving my results, I repeat that this is not a "normal" image: there is some unusual processing done to this one, above and beyond, I believe, downsampling with a sharpening filter.

With this caveat out of the way:

No question straight sRGB enlargement is better. Less jaggies, and contrast=3.468753 is close enough to linear light that the ugly dark halos are starting to show up.

-----

If such images are sufficiently representative of an important fraction of what's in videos, this is what I recommend:

Unless we (or users) find better sigmoidization settings through R&D, reasoning or experimenting, I think you should ditch sigmoidization (or relegate it to a future "sharpening" tool) and instead experiment with deblurs slightly smaller than .98, since many people find "Jinc" slightly on the soft side, and sigmoidization is not there to tighten things (and does not need the slight additional jaggy reduction that a deblur closer to 1 brings).

P.S. Our posts crossed, but it looks like we inching (running?) toward the same conclusion.

[madshi]

Yeah, that probably makes sense. I think I'll lower the deblur value to .96 and be done with it for now. A true sharpener may come some time in the future then.

Let me say "thanks" again. I appreciate the effort you put into this.

[NicolasRobidoux]

Did I get lucky in my selection of test images?
I'm going to have to take the time to test sigmoidization some more.
-----
MadVR file closed.
If at some point you want some assistance making the GPU code for bicubics or Jinc or Lanczos faster, remember that I'm a consultant. (And I charge less for fun work.)
Good luck!

[6233638]

Not sure, must be caused by whatever source filter is used on your PC. It probably upscales chroma internally? Don't know...Do you know a suitable filter?

This is gaming content, though, which benefits from extremely sharp chroma upsampling. We can see with Luma resampling that Jinc often produces noticeably less aliasing than Lanczos (and before I implemented Jinc, I thought Lanczos had very low aliasing levels!). So once again the question is: Is sharpness more important or aliasing? I still believe it's a matter of taste...Most of my testing is video content though, that's just one example. Do you have any samples where soft chroma is better though? I find that to be very rare.


P.S. another test with SoftCubic 80, Jinc 3 anti-ring, Lanczos 3 anti-ring Luma scaling (4:4:4 JPG, no chroma scaling)
http://www.abload.de/img/scaleg8sj8.jpg

No wonder it is low aliasing!

I also confirmed that anti-ring increases aliasing with all bicubic scalers.

[madshi]

Did I get lucky in my selection of test images?
I'm not sure. Maybe yes, maybe I got unlucky, maybe it's just the difference between photos and videos, I don't really know...

If at some point you want some assistance making the GPU code for bicubics or Jinc or Lanczos faster, remember that I'm a consultant. (And I charge less for fun work.)
Good luck!
I'll keep that in mind. I actually do have some ideas which are way over my math skills. But it'll probably be some months before I can even start looking into that direction. Too many other things need work first...

Do you know a suitable filter?
Maybe avisynth? I've no idea...

Most of my testing is video content though, that's just one example. Do you have any samples where soft chroma is better though? I find that to be very rare.
I don't have any at hand right now, and I'm not really feeling like searching for samples now. Maybe later...

P.S. another test with SoftCubic 80, Jinc 3 anti-ring, Lanczos 3 anti-ring Luma scaling (4:4:4 JPG, no chroma scaling)
http://www.abload.de/img/scaleg8sj8.jpg

No wonder it is low aliasing!
:)

I also confirmed that anti-ring increases aliasing with all bicubic scalers.
But not so much with Jinc, right?

[6233638]

But not so much with Jinc, right?Correct. Anti-ring is good with Jinc & Lanczos, probably spline. (I don't bother to test that much, as I don't like it) I don't think I like it with any bicubic scalers, and it is especially bad with softcubic.

EDIT: Jinc 3, Jinc 3 AR at 300%
http://www.abload.de/thumb/jincgtk2s.jpg (http://www.abload.de/img/jincgtk2s.jpg)

But anti-ring enabled is better overall.

[NicolasRobidoux]

...
But anti-ring enabled is better overall.
You mean that it is generally better with Jinc even though on your last test AR shows ugly "notches" on the sides of the X?

[6233638]

You mean that it is generally better with Jinc even though on your last test AR shows ugly "notches" on the sides of the X?Yes, the overall image is better with it enabled. That is a highly magnified area, and an example like that is probably not too likely to occur with real-world imagery, compared to the ringing that is removed, which is obvious even with moving video content.

[NicolasRobidoux]

Maybe it would be cleverer to make a slider which gradually switches betwen linear sigmoidized light on the one end of the scale, and gamma correct non-sigmoidized light on the other end of the scale. But then which contrast value to use for sigmoidization? Maybe two sliders would be necessary. But this is all getting complicated to use again...(Mopping up.)
If you skip the conversion to linear light, and apply sigmoidization directly to Y'CbCr or R'G'B', you only need one knob: contrast.
It you decide to try that at some point, let me know and I'll immediately do the hair extension math.
P.S. ... because with R'G'B', you want to have most of the effect at the light end, so you want the curve to be "tighter" there than at the dark end, and stretching does the opposite.
P.S.2 Of course the knob could be called "sharpening" even though it is a bit of a misnomer.

[NicolasRobidoux]

...
If the curve only is defined in [0,1], then I don't see the problem with clipping. Introducing a new curve for out-of-range values seems kind of arbitrary, and there's the convex/concave problem.For reasons that mostly have to do with "elegant" transition toward contrast = 0 (which should be a straight line), the curve actually extends past [0,1], even when it is not "stretched".

[NicolasRobidoux]

Yeah, there's a change from concave to convex, but what else could we do? At 0.0 the curve is almost a horizontal line. If we try to add a straight line to cover values < 0.0 then there actually *will* be a corner. The only proper way to continue the curve < 0.0 without changing from concave to convex and without adding a corner would be to make the line totally horizontal. But that would be identical to simple clipping, which is not what I want to do.
I hope that it is now clear that even the "[0,1]" version of sigmoidal-contrast gives a curve that extends past [0,1]. The key word is "almost horizontal". This formulation of sigmoidal-contrast took a lot of work to get right, work mostly done by a number of people associated with ImageMagick. Basically, as the contrast goes to zero, the "extent" of the curve increases, and in the limit the curve becomes y=x from (-infinity,infinity), which means that sigmoidal-contrast has no effect, irregardless of whether or not there are overshoots and undershoots. This is what one wants, and the "[0,1]" version elegantly does this.
This is why I can add "hair extensions": I have whiskers (more like a stubble, but still there, if the contrast is high) to which I can "attach" sloping locks of straight hair, without there being any "break".
Warning: There are generations of slightly broken implementations in ImageMagick. Use a recent release. But even recent releases have short hair. (Will fix later, although this does not matter with versions that use LUTs.)

[NicolasRobidoux]

Hopefully my final comment:
Stretching the curve, which was based on my very basic understanind of Y'CbCr, was probably the wrong choice. Hair extensions, most likely are better.
Sufficiently better?
Don't know.
-----
Also, I'm going to have to try sigmoidization, with smaller contrast, based on sRGB values directly.
Rationale: Why start from a color space that "we all know" is terrible when upsampling, namely linear RGB? Start from something that's already pretty good, namely sRGB, which roughly corresponds to R'G'B'.
These are images meant for human consumption, so pay respect to perceptual spaces.
(Warning: Not when downsampling, where linear light is king.)

[aufkrawall]

I had the same problem today, until I noticed that the filename contained "60p". This overwrites the 59.94Hz and Madvr will switch to 60Hz instead of 59.94.
After renaming (delete "60p"), I got 59.94, just like it should :)
That did the trick, thank you very much. :)

[madshi]

You mean that it is generally better with Jinc even though on your last test AR shows ugly "notches" on the sides of the X?
Those "notches" only occur with the Jinc anti-ringing filter. They don't occur with the conventional tensor-based anti-ringing. I'm planning to improve the Jinc anti-ringing filter to avoid those notches. Already have some ideas...

Also, I'm going to have to try sigmoidization, with smaller contrast, based on sRGB values directly.
Rationale: Why start from a color space that "we all know" is terrible when upsampling, namely linear RGB? Start from something that's already pretty good, namely sRGB, which roughly corresponds to R'G'B'.
The problem I see is that the gamma correction from gamma corrected R'G'B' has a somewhat similar curve to the sigmoidization S-curve for a certain range. So applying an S curve *on top* of the gamma power function might put that range over the top, if you know what I mean? I'm not really sure, though, so maybe it would be worth a try. But to be honest, I've spent *a lot* of time on implementing and experimenting with sigmoidization already and I'd really like to move on now and work on something else for a change. E.g. I'd like to get that anti-ringing notches fixed. Anyway, maybe I'll give low contrast sigmoidization with R'G'B' a quick look tomorrow. It won't be much more than a quick look, though, unless the results positively surprise me...

[NicolasRobidoux]

...
The problem I see is that the gamma correction from gamma corrected R'G'B' has a somewhat similar curve to the sigmoidization S-curve for a certain range. So applying an S curve *on top* of the gamma power function might put that range over the top, if you know what I mean? I'm not really sure, though, so maybe it would be worth a try.
I immediately saw the same exact potential problem.
But if you don't try stuff, you don't learn.
And of course this was the "try this first".
-----
How about this:
Let me try it in the context of ImageMagick when I have a minute.
It does not cover the "these values come from Y'CbCr and go back there" issue, but it's a start.
>>I<<'ll get back to you.
And I'll take my time.
Deal?
P.S.
I myself am working on higher priority things.
P.S.2
It's always a pleasure to work with someone who "sees" things.
But I'll try not to abuse a good thing.

[NicolasRobidoux]

Mathias:

I'll have to double check tomorrow morning (and tomorrow is D-Day
for my last grad student as main supervisor).

This being said, I would guess that having a slightly smaller radius
would help you fix the "ringing suppressor".

So, as a preliminary result, I offer to you that the deblur =
.94872134570137621495, which probably you should truncate at the 0
decimal, is special. (Assuming I did not make an algebra or geometry
mistake.)

Does it antialias enough? Don't know yet. But it seems to be pretty
much where I would expect the visual sweet spot to be with EWA Lanczos
3.

In any case, you should feel free to use deblurs between about .94 and
1 and use whichever works best with your anti ringing gadget.

[madshi]

I immediately saw the same exact potential problem.
But if you don't try stuff, you don't learn.
And of course this was the "try this first".
I've just given it a try. It's the same thing again: Some lines get more aliased, other less aliased. Some lines get more focused, others less focused.

I'll have to double check tomorrow morning (and tomorrow is D-Day for my last grad student as main supervisor).

This being said, I would guess that having a slightly smaller radius would help you fix the "ringing suppressor".

So, as a preliminary result, I offer to you that the deblur = .94872134570137621495, which probably you should truncate at the 0 decimal, is special. (Assuming I did not make an algebra or geometry mistake.)
Thanks! :)

[madshi]

I also confirmed that anti-ring increases aliasing with all bicubic scalers.
Do you have a sample (or 2) which shows this increased aliasing with bicubic scalers? Maybe I can find a way to improve it...

[NicolasRobidoux]

I'm thinking of buying TV ads in which a grey haired soap opera star looks the viewer in the eye and says:
"Why waste your money on investment advice?
Unlike stock market tips, sigmoidization MAY NOT MAKE YOUR IMAGES WORSE!
And you get amazing value if you call in the next 15 minutes:
Buy the ImageMagick -sigmoidal-contrast command for $19.99 and get the +sigmoidal-contrast command ABSOLUTELY FREE!
(Shipping and handling extra. Hair extensions may not improve your Facebook popularity.)"

[6233638]

Do you have a sample (or 2) which shows this increased aliasing with bicubic scalers? Maybe I can find a way to improve it...I don't know that I have any good video content samples that make it clear, and I think what I've been seeing was not actually aliasing, but the anti-ring filter being too aggressive and "cutting into" the image, rather than just the ringing, similar to what was seen with Jinc.

Here is a very artificial, high magnification example of this. (softcubic is worst affected, and this is probably not a useful test for you)

http://www.abload.de/thumb/normal4bp0h.jpg (http://www.abload.de/img/normal4bp0h.jpg) http://www.abload.de/thumb/ar2eoq2.jpg (http://www.abload.de/img/ar2eoq2.jpg)

Source (http://www.abload.de/img/untitled-2l3ol6.jpg)


I really need to spend some time to create some proper test patterns for evaluating scaling (I'm just experimenting right now) and decide upon a good set of real-world scenes from films and other sources rather than just going through a large portion of my film library and comparing algorithms.
I do of course use commercial test discs as well such as DVE and Spears & Munsil.

I also need to figure out how to the 4:2:0 JPGs to have Chroma scaled by madVR, as I have some tests I want to do that are difficult to check properly with compressed video. (when I create the patterns myself, I know exactly what the input and output values should be etc.)

[madshi]

madVR v0.84.3 released

http://madshi.net/madVR.zip

* improved Jinc anti-ringing filter
* fixed: after a few seeks playback sometimes started to stutter
* maybe fixed: black screen after switching display mode
* fixed: changing window size when using Jinc was slower than necessary
* linear light scaling works slightly different now, might be a bit faster
Please everybody who's interested recheck whether the Jinc anti-ringing filter works well for you or not. It seems to be better in the images I tested with, but the proof is in the pudding, so they say. So if there's anything that got worse, please let me know (in that case a sample would be great).

A little teaser:

small original image (http://madshi.net/small.png) || Lanczos4 (http://madshi.net/small-lanczos4.png) || Lanczos4 AR (http://madshi.net/small-lanczos4ar.png) || Jinc4 (http://madshi.net/small-jinc4.png) || Jinc4 AR v0.84.2 (http://madshi.net/small-jinc4arOld.png) || Jinc4 AR v0.84.3 (http://madshi.net/small-jinc4arNew.png)

Please note that this test image is a very artificial test pattern, made to show ringing and aliasing artifacts. In real world the differences between Lanczos and Jinc, and between with/without anti-ringing are of course *MUCH* smaller.

[BetA13]

Thanks a lot for the UPDATE madshi... :)
Gonna test it right away...

And btw, the Anti ringing feature really getting better and better..The teaser pics look great.

[NicolasRobidoux]

Warning:

Jinc 4 with "shrunk" radius (a lot) does artificially well on this particular test image. How well it does on it is not representative of how well it does in general.

Don't know if this is applicable to your AR version.

[Pat357]

for evaluating scaling (I'm just experimenting right now) and decide upon a good set of real-world scenes from films and other sources rather than just going through a large portion of my film library and comparing algorithms.
Does this mean that your film collection is not a good representation of "real-world and other sources" ?? ;)

What's in there than ? :rolleyes:
Is it mostly BD/HDVD ripped full HD material ? 50% full HD or more ?
Does it contain much of SD ?
DVD-ripped material ? 25% or more ?
Consumer/own HD/SD CAM material ?
Any older B&W/silent stuff ?

[6233638]

* improved Jinc anti-ringing filterWow, those tweaks to the anti-ringing filter look great! Of course they are artificial tests, and probably less impactful in real-world testing, but tests like that do seem like they're useful for fine-tuning the AR filter.

Does this mean that your film collection is not a good representation of "real-world and other sources" ?? ;)

What's in there than ? :rolleyes:
Is it mostly BD/HDVD ripped full HD material ? 50% full HD or more ?
Does it contain much of SD ?
DVD-ripped material ? 25% or more ?
Consumer/own HD/SD CAM material ?
Any older B&W/silent stuff ?What I meant is that I don't have a specific set of scenes from films that I look at. I want to have something more structured, so that I only have to check maybe 10-15 scenes rather than simply browsing through my film library. (and often ending up just watching a film all the way through) There are some specific things I check every time, and obviously the more content that can be compared the better, but this is why it probably takes me weeks to go through all my tests. (especially when I'm busy, like I am just now)

I have a selection of very bad quality DVDs, high quality DVDs, film, TV content, animation, Blu-rays, low resolution (360p) YouTube quality content, less compressed 360p game footage, 720p game footage at varying compression levels, live 720p footage etc. I also run through some test discs, and now that we have support for images in madVR, I will be able to create my own patterns to look for specific artefacts. (though I need to figure out how to use that for chroma testing)

What I don't have, is any pirated content such as re-compressed 1080p/720p Blu-ray/TV rips etc.


Really though, I think I am liking Jinc a lot - I am unsure about whether I prefer Jinc 3 or 4. Generally I don't like anything above 3 tap, but Jinc 3 is definitely softer than Jinc 4. Right now it's mostly between Jinc 3 anti-ring when a sharper option is more suitable, and SoftCubic 80 (no AR) when I want something softer for highly compressed/artefacted content.

Chroma I am still undecided on. As I suspected, I've come across some examples where Lanczos is too sharp, and Spline is looking better now. It may still be too sharp though, testing is more complicated with the anti-ringing filter, as ringing was an easy way to tell if a resampler was too sharp or not.

[blackjack12]

madVR v0.84.3 released

http://madshi.net/madVR.zip

* improved Jinc anti-ringing filter
* fixed: after a few seeks playback sometimes started to stutter
* maybe fixed: black screen after switching display mode
* fixed: changing window size when using Jinc was slower than necessary
* linear light scaling works slightly different now, might be a bit faster
Please everybody who's interested recheck whether the Jinc anti-ringing filter works well for you or not. It seems to be better in the images I tested with, but the proof is in the pudding, so they say. So if there's anything that got worse, please let me know (in that case a sample would be great).

A little teaser:

small original image (http://madshi.net/small.png) || Lanczos4 (http://madshi.net/small-lanczos4.png) || Lanczos4 AR (http://madshi.net/small-lanczos4ar.png) || Jinc4 (http://madshi.net/small-jinc4.png) || Jinc4 AR v0.84.2 (http://madshi.net/small-jinc4arOld.png) || Jinc4 AR v0.84.3 (http://madshi.net/small-jinc4arNew.png)

Please note that this test image is a very artificial test pattern, made to show ringing and aliasing artifacts. In real world the differences between Lanczos and Jinc, and between with/without anti-ringing are of course *MUCH* smaller.

Madshi

Wanted to confirm that the seek/jump around, stuttering issue is fixed on all the systems that I have tested as well.

Thanks ... :)

[Ver Greeneyes]

madshi,

I made those CAM02-UCS shaders I was talking about and did some quick before/after tests with MPC's EVR renderer (forward transform as a pre-resize shader, inverse transform as a post-resize shader). There are some differences, but they're miniscule - and annoyingly, I'm getting some artifacts on dark shades that I've yet to track down. If I manage to fix those I might still send you the shaders, but yeah, the calculations are pretty complex and I don't think it adds much.

[cyberbeing]

Similar to your sample image, Jinc3 anti-ringing shows those sharp bright/dark residual ringing specks, and soft dark residual ringing around edges of fonts rendered by xy-VSFilter on 720p video. This isn't surprising, since not unlike your test image, fonts are extremely sharp high-contrast vector shapes. The overall Jinc3 anti-ringing result on 720p is softer with more ringing than Spline36 anti-ringing. When upscaling 360p, Jinc3 anti-ringing more clearly shows it's major advantage of lacking aliasing, but it's still softer than Spline36 anti-ringing, and seems to have around 10x more residual ringing around the edges of fonts and other hard edges.

To get subtitles out of the picture, I may need to wait until madVR implements the new subtitle interface to do a proper evaluation of Jinc. Overall though, I still personally don't see Jinc's increased ringing and softness compared to Spline as a great compromise, just to eliminate aliasing. On the other hand, if you were able to bring residual ringing down to Spline36 anti-ringing levels without increasing softness further, it would suddenly become a compelling option for upscaling low-res and DVD content IMHO.

In other news:

Linear light scaling seems to average ~10% faster rendering times on my GT440 DDR5 with this build. Would anything you changed reduce the serious aliasing + ringing which linear light scaling caused when upscaling, or should that be pretty much unchanged in this build (i.e. should I spend time re-testing)?

Jinc4 anti-ringing is still too slow to use on my GT440 DDR5, so I can't test it well.

[madshi]

Warning:

Jinc 4 with "shrunk" radius (a lot) does artificially well on this particular test image. How well it does on it is not representative of how well it does in general.

Don't know if this is applicable to your AR version.
FWIW, I've not implemented the shrunk radius yet (didn't have time to look at it yet). The screenshots I made from the new anti-ringing filter are with 4-tap Jinc with 0.9891028367558475.

Wanted to confirm that the seek/jump around, stuttering issue is fixed on all the systems that I have tested as well.
I'm glad to hear that! :)

I made those CAM02-UCS shaders I was talking about and did some quick before/after tests with MPC's EVR renderer (forward transform as a pre-resize shader, inverse transform as a post-resize shader). There are some differences, but they're miniscule - and annoyingly, I'm getting some artifacts on dark shades that I've yet to track down. If I manage to fix those I might still send you the shaders, but yeah, the calculations are pretty complex and I don't think it adds much.
Yeah, after the experiments with Sigmoidization my expectations are that your shaders will also improve some test images and make things worse in other test images. It seems to me that all color space manipulations have this effect. But we can try. Maybe if you've got in running in MPC-HC we could test it there before trying it in madVR. Because if it isn't convincing in MPC-HC then I could save the time to try it in madVR.