nnedi3_rpow2 causing slight chroma shifting?

[killerteengohan]

I never noticed this before, but for some reason when using nnedi3_rpow2, I am seeing strong colors like red and blue appear to shift slightly to the left and looks kind of like its out of place. This is quite noticeable in a lot of places.

nnedi3_rpow2(2, cshift="LanczosResize", fwidth=1920, fheight=1080, nns=4)

I tried spline, bilinear, bicubic, and lanczos. They all appear to have the colors stay in place, but vary in sharpness.
I tried various cshift types and it didn't really fix it. Some made it even worse.
I tried shifting the chroma to the right by 0.25 with chromashiftsp to try and get it closer to the other resizers. It looks like it kept most things in place, and at the same time pushed others slightly out of place.
nnedi3 is supposed to be sharper and better at upscaling, yet it looks softer or as if distorting details.
Is nnedi3 doing something wrong here?

NOTE: The original resolution is 1280x720 if that helps with figuring anything out. nnedi3 is the only one that doesn't look like the colors stay as the 720p looks.

[jagabo]

I never noticed the slight chroma shift relative to the other scalers. This might be difference in chroma placement assumptions. ChromaShiftSP(x=-0.25) appears to fix it.

nnedi3_rpow2() is designed to upscale sharp video without creating aliasing artifacts and oversharpening halos. It will not sharpen video that's already blurry. Lanczos (and the other sharpening scalers) will create oversharpening halos and aliasing artifacts with video that's already sharp. They will sharpen slightly fuzzy videos.

[killerteengohan]

I never noticed the slight chroma shift relative to the other scalers. This might be difference in chroma placement assumptions. ChromaShiftSP(x=-0.25) appears to fix it.

nnedi3_rpow2() is designed to upscale sharp video without creating aliasing artifacts and oversharpening halos. It will not sharpen video that's already blurry. Lanczos (and the other sharpening scalers) will create oversharpening halos and aliasing artifacts with video that's already sharp. They will sharpen slightly fuzzy videos.

Yeah it appeared to fix it when I tried it too, but it is also pushing other things chroma out of place.
I also tried doing this, and it did give me the same chroma as if I used lanczos, but it made the chroma have halo's.

source = last.lanczosresize(1920,1080)
nnedi3_rpow2(2, cshift="LanczosResize", fwidth=1920, fheight=1080, nns=4)
MergeChroma(last, source)

I opened the original 720p in photoshop and mspaint, and resized it to 1920x1080 in both. Then I opened both nnedi3 with, and without chroma shifting in photoshop and mspaint. When looked at like this, not using the chroma shift looks more like the original 720p does. They don't match up 100%, but they are certainly closer to being the same than the one with the chroma shifting.

I guess it just looks like it's moving out of place when lanczos vs nnedi3 is being used in avisynth and compared at 1080p. However, when I do what I did in photo editor, there was no need to chroma shift. I guess it's just looks slightly different in avisynth preview or something.

[jagabo]

Note that photoshop and paint work in RGB. So you wouldn't expect chroma shifting there -- the colors aren't separate from the luma, and they're not subsampled. Also, there's no (or at least a much smaller) chroma shift with YV24.

[killerteengohan]

Are you saying the photoshop and paint are inaccurate at scaling, and I should do the shifting?

[poisondeathray]

I wonder if you're using an old nnedi3 ?

There are 2 known common shifts, one is from old nnedi3 versions (corrected in recent jpdsr versions, with csresize=true, mpeg2=true ; both these are true by default)

The other is all avisynth internal resizers use "center" placement for the 4:2:0 chroma interpretation , which is "mpeg1" placement. Industry standard for 4:2:0 is "mpeg2" or " left" for 99% of most formats (exceptions are DV, MPEG1, and UHD) . Depending on how you're taking screenshots, how you're converting to RGB - how you're upsampling the chroma when converting to RGB for display - you can get variations in shifts

[jagabo]

I was using a two year old version. So I just updated to v0.9.4.58 built recently: https://github.com/jpsdr/NNEDI3/releases

The chroma shift is the same without specifying csresize or mpeg2. Specifiying csresize=true, mpeg2=true still shows the chroma shift. But if I set them to false the horizontal shift is gone. But now there may be a slight vertical shift. It's hard to tell because I'm using an image that isn't very sharp to begin with. I'll test with a sharper image tomorrow.

[poisondeathray]

The left shift is meant to compensate for avisynth internal resizers. If you set cresize=false, it will be effectively shifted to the right on some colors and lines . Neither are perfect, both have different flaws . That quarter pixel chromashift is intermediate, but you could argue it's a tradeoff as well, because other lines will be worse. There is only so much you can do with 4:2:0

[killerteengohan]

I wonder if you're using an old nnedi3 ?

I tried 3 different versions of it before asking about it in here. The older ones did the same thing, but shifted slightly more, or looked slightly worse. It was minimally more of a shift, and without comparing you probably wouldn't notice, but it was even more in the older ones.

I tried
NNEDI3 v0.9.4
NNEDI3 v0.9.4.51
I forget what the third was.

I was unaware of anything newer than 0.9.4.51. Apparently the next update took a year to come. I will give the newest a try. I don't see much info in the changelog that would indicate anything is going to change, but I will still try it.

[killerteengohan]

Here is the original 720p if you wish to give it a try yourself.
https://forum.videohelp.com/images/imgfiles/5vwVmcq.png

nnedi3_rpow2(2, cshift="LanczosResize", fwidth=1920, fheight=1080, nns=4)

[poisondeathray]

Here is the original 720p if you wish to give it a try yourself.
https://forum.videohelp.com/images/imgfiles/5vwVmcq.png

nnedi3_rpow2(2, cshift="LanczosResize", fwidth=1920, fheight=1080, nns=4)

An RGB image such has PNG has already been upsampled. Whatever chroma interpretation you used for the RGB conversion has already been applied.

The shift only affects subsampled formats such as 4:2:0

When you convert to RGB, you are upscaling the chroma planes. The chroma location interpretation matters (how you convert to RGB)

eg.
#YV12 source
#converttorgb24(matrix="rec709", chromaresample="bicubic", chromainplacement="mpeg2")
converttorgb24(matrix="rec709", chromaresample="bicubic", chromainplacement="mpeg1")

Take original source (not PNG) , and try those avisynth internal RGB conversion lines, notice the relative shifting left and right . That is the effect of left vs. middle chroma interpretation. The method you use to convert to RGB matters.

nnedi3 introduced csresize a few years back, because avisynth internal resizers are non standard in terms of the chroma interpretation. The results don't match 99% of other programs. If you set csresize=false, that's the old nnedi3 behaviour. cresize=true (default for newer versions), includes the avisynth correction to match other programs

   csresize
     
      Chroma Shift Resize. This parameter enable (true) or disable (false) the chroma shift
      adjustment according the resize. If disabled, no shift is made on chroma according the
      resize and/or the colorspace, and the [mpeg2] parameter has not effect. If true, adjustment
      on chroma shift is made according the color space and the resize. YV16 is always shifted
      because it's always MPEG-2 subsampling, YV411 is never shifted, and YV12 is ruled by the
      [mpeg2] parameter.
      
      Default: True

   mpeg2
     
      Specify chroma alignment for YV12. If true, chroma subsampling follow MPEG-2
      alignment, and a shift correction is made on the chroma according the resize.
      If false, chroma subsampling for YV12 is MPEG-1, and so no shift is made.
      
      Default: True

Bottom line - you're not going to get perfect results - the color is subsampled; if you shift it one way, other parts will look worse.


PointResize is just "nearest neighbor" algorithm, but since avisynth internal resizer chroma interpretation is non standard, so you get vertical shifting
https://forum.doom9.org/showthread.php?p=1884351#post1884351
So you need to correct for it
https://forum.doom9.org/showthread.php?p=1571315#post1571315

It's the same idea with csresize and nnedi3 . This corrects the internal avisynth scaling. If you csresize=false with a cshfit scaler that uses standard chroma interpretation such as resize8 or avsresize, you get the same results.

[killerteengohan]

Oh well. It's close enough to the original that I never noticed before in the many other things I have used it on. I'll let my OCD go about this one, and accept the slight difference that I otherwise would never have known about without comparing and actually looking for it. It's not exactly ruining anything or changing so much that it cant be missed.

Thanks!

[killerteengohan]

I'm curious though. Would it be better to upscale the chroma separately, then overlay it on top of what nnedi3 results in with mergechroma or something?

[jagabo]

I usually don't worry about it and just do a chromashiftsp() at the end if the chroma is off by too much.