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.
I tried spline, bilinear, bicubic, and lanczos. They all appear to have the colors stay in place, but vary in sharpness.Code:nnedi3_rpow2(2, cshift="LanczosResize", fwidth=1920, fheight=1080, nns=4)
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.
+ Reply to Thread
Results 1 to 14 of 14
Last edited by killerteengohan; 12th May 2021 at 21:21.
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.
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 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.
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
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.
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
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.
Last edited by killerteengohan; 13th May 2021 at 07:55.
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)
#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
PointResize is just "nearest neighbor" algorithm, but since avisynth internal resizer chroma interpretation is non standard, so you get vertical shifting
So you need to correct for it
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.
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.
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?
I usually don't worry about it and just do a chromashiftsp() at the end if the chroma is off by too much.