同一个缩放算法应用在luma平面和RGB平面的区别

[yemijun]

比如
AMD_FSR_EASU_luma
AMD_FSR_EASU_rgb
这两个放大算法，按照MPV的处理顺序的话

是否意味着AMD_FSR_EASU_rgb的放大实际上对chroma进行了“两次放大”呢？第一次由cscale拉伸到与luma平面相同，第二次由YUV转为RGB后，由AMD_FSR_EASU_rgb放大到屏幕目标分辨率。

如果以上成立的话，是否意味着luma平面的放大性能开销更小，效果更好呢？

而且YUV中UV平面也并非完全不包含Y平面的信息，亮度信息并非全部被剔除到Y平面，使用AMD_FSR_EASU_rgb似乎可以解决这个问题。

这个讨论并非对视频画质的锱铢必较，仅仅是对视频缩放原理的疑问，并不具有多大的实际意义，这两个滤镜在实际使用中的差别几乎不大。

[verygoodlee]

视频以 yuv420 像素格式居多，色度平面的分辨率只有亮度平面的一半，以 1080p yuv420 放大到 2160p 为例：

• 使用亮度平面放大的着色器

1. 亮度平面 1080p -> 2160p
2. 色度平面 540p -> 2160p
3. 合并亮度/色度平面为 2160p 的 RGB 平面

• 使用RGB平面放大的着色器

1. 色度平面 540p -> 1080p
2. 合并亮度/色度平面为 1080p 的 RGB 平面
3. RGB平面 1080p -> 2180p

luma平面的放大性能开销更小，效果更好

通常对于视频播放来说是的，应该优先使用亮度平面放大的着色器，
RGB平面放大的着色器更多用于图片放大，图片有很大部分是RGB像素格式的，亮度平面放大的着色器派不上用场。

另外RGB平面放大的着色器搭配更灵活一点，比如使用Anime4K_Restore重构线条之后，不想用Anime4K_Upscale放大（油画感太重），可使用其他RGB平面放大的着色器，没法用亮度平面放大，因为Anime4K_Restore工作在RGB平面，使用亮度平面放大就变成了先放大后重构线条，这会带来更多伪影。

[hooke007]

是否意味着AMD_FSR_EASU_rgb的放大实际上对chroma进行了“两次放大”呢

AMD_FSR_EASU_rgb_RT hook 的是main，这时候已经没有chroma了怎么会两次放大chroma呢

---

同一个缩放算法应用在luma平面和RGB平面有什么区别呢

这个问题是有点广的，单举例一个fsr不全面。EASU其中一部分是lanczos2改进而来，而lanczos2本身不太依赖颜色信息，作为luma scaler是不太影响整体变化的，其他依赖颜色信息的算法如果做成两种变体就容易会有精度差异，至于看不看的出来又是另一回事。

[yemijun]

另外还有个小问题，在MPV-lazy的默认配置中您采用了
correct-downscaling = no
sigmoid-upscaling = no
这样的参数是出于什么考量呢

MPV官方文档的解释我没法很好的理解
--correct-downscaling
When using convolution based filters, extend the filter size when downscaling. Increases quality, but reduces performance while downscaling. Enabled by default.
--sigmoid-upscaling
When upscaling, use a sigmoidal color transform to avoid emphasizing ringing artifacts. Enabled by default. This is incompatible with and replaces --linear-upscaling. (Note that sigmoidization also requires linearization, so the LINEAR rendering step fires in both cases)

[hooke007]

只是因为性能而已。。。

correct-downscaling 对大尺寸图片缩放到小尺寸时降采样的抗锯齿十分明显。我关掉后4k源在1080p显示设备上播的锯齿感很明显，作为补偿我选择了弱锯齿的dscale作为默认值

sigmoid-upscaling 作为放大时的部分伪影瑕疵优化吧，感知不强，而且我已经采用第三方shader了，而且考虑大部分用户可能也会选外部算法而不是内置的

sigmoid-upscaling 在madvr那边好像叫 scale in sigmoidal light ，万年冷冻库的解释也是和放大锯齿相关的

[yemijun]

imagemagick中对sigmoid-upscaling的详细解释如下
https://usage.imagemagick.org/resize/#resize_sigmoidal

我的理解是针对作用在RGB平面的scale可以减少可能出现的锯齿或振铃伪影。也就是对hook在main上的第三方着色器也有效果。

[hooke007]

sigmoid 在 main 之后那肯定是有效果的，但是shader本身是可以在整个着色器脚本内就处理自身的dering这些东西，所以要不再加一次后处理看你怎么想了

[yemijun]

是的，具体还是跟shader本身的处理方式相关

[dyphire]

你的问题涉及的比较多啊，上面两位也已经进行了比较充足的解释，我仅在个人知识层面进行一些补充（存在片面和错误的地方

同一个缩放算法应用在luma平面和RGB平面的区

这个比较好理解，一个是 luma 平面上进行放大，一个是 RGB 平面上进行放大，luma 放大只涉及亮度通道，所以计算消耗更低，同时它可以避免 RGB 混合后可能的色度信息上的溢出或失真甚至噪点瑕疵产生的干扰，通常情况下会优先选择在 luma 平面上进行放大锐化和瑕疵处理等操作，再对色度平面进行单独处理。但是对于以 rgb 形式存储的文件则只能在 RGB 平面上进行放大

比如 AMD_FSR_EASU_luma AMD_FSR_EASU_rgb 这两个放大算法，按照MPV的处理顺序的话
是否意味着AMD_FSR_EASU_rgb的放大实际上对chroma进行了“两次放大”呢？第一次由cscale拉伸到与luma平面相同，第二次由YUV转为RGB后，由AMD_FSR_EASU_rgb放大到屏幕目标分辨率。

上面已经有人解释过了，rgb 类缩放器只在合成后的 RGB 平面执行放大操作，即此类着色器和算法会在最后执行

如果以上成立的话，是否意味着luma平面的放大性能开销更小，效果更好呢？

对于同一种算法的不同实现的话是的，不同算法之间则不能如此类比

而且YUV中UV平面也并非完全不包含Y平面的信息，亮度信息并非全部被剔除到Y平面，使用AMD_FSR_EASU_rgb似乎可以解决这个问题。

这是不正确的，YUV 中 Y 平面为亮度信息，UV 平面是与亮度相对应的色度的色差信息，两者存在变换关系，但 UV 平面并不会包含亮度信息。而当亮度信息和色度信息的相关性不够强时基于亮度尝试还原色度的着色器会产生糟糕的效果

这个讨论并非对视频画质的锱铢必较，仅仅是对视频缩放原理的疑问，并不具有多大的实际意义，这两个滤镜在实际使用中的差别几乎不大。

题外话，FSR 着色器在一些场景中会对线条产生明显的劣化效果。本身就不是一个优秀的算法

区别是有的，但是具体有无精度差异还是要看实际所使用的放大算法。 希望能具体举例一下有哪些scaler算法比较依赖颜色信息，或者能给我一些相关资料，我去进行查询，万分感谢。

可以说大多数常规放大算法无论双线性、双三次、Lanczos 和 EWA 类，以及 nnedi3 和 ravu 等等，都是在分析和处理像素的插值方式，是不涉及亮度和色度信息的针对性处理的，所以它们都通用于亮度和色度，但更适合亮度平面的处理

而考虑到色度信息进行针对性处理的大多都是 AI 类放大算法，它们往往在非线性色彩空间中进行训练和处理

例如nnedi3这种deinterlacing滤镜分别在x，y方向做倍高，具有一定“连接线条能力”的算法是不是就可以理解为几乎不依赖颜色信息，用在luma scaler是合理的？ 我在学习vcb-s公开教程中，将eedi这类算法用作AA算法时也几乎只对Y平面处理，几乎不对色度平面做AA

如上所述，是的

另外还有个小问题，在MPV-lazy的默认配置中您采用了
correct-downscaling = no
sigmoid-upscaling = no
这样的参数是出于什么考量呢
我的理解是针对作用在RGB平面的scale可以减少可能出现的锯齿或振铃伪影。也就是对hook在main上的第三方着色器也有效果。

除非性能真的不够，否则 --correct-downscaling 选项不建议禁用，它就是降采样的 AA 处理，mpv 目前默认启用

sigmoid-upscaling 作用于缩放前（LUMA 平面及 RGB 平面前），它是对色彩空间进行了非线性转换。也就是先对像素值做 sigmoid 曲线映射 → 再执行图像操作 → 最后做反向映射还原
这样做是为了避免过亮和过暗区域在线性色彩空间转换下容易产生的溢出和伪影瑕疵，因为线性转换的插值不平滑，同样 mpv 目前默认启用
顺便即使禁用它 mpv 默认的缩放操作也是在伽马光下进行非线性转换而不是线性光下的线性转换

但这样做也可能导致反向映射后色彩的动态范围和准确度出问题
上面提到 AI 类放大算法往往在非线性色彩空间中进行训练和处理，如果你仔细观察对比 AI 放大算法处理后的画面，就会发现它们和常规放大算法在色彩表现上存在明显的差异，就是在非线性色彩空间映射 → 图像处理 → 反向映射的处理过程中对色度进行了补偿操作

[dyphire]

这是可以预期的，像素偏移必然会导致色度还原算法的不良效果

至于 cfl 和 krig 置于 nnedi3 和 ravu 之前的做法不是很推荐，在 vulkan 或 opengl 后端下有可能导致画面异常（已知问题

顺便就如我在 #78 中提到的我个人对色度升频算法不感兴趣，之所以仓库配置还保留着 krig 只是因为在我的机器上没有啥性能消耗，下次一定

[verygoodlee]

工作顺序按理应该不会变的（仍然是先nnedi3后krig的bind），可以看看stat验证一下。区别应该是krig脚本在前会先hook没加工过的luma尺寸，导致chroma放大的尺寸不够才会上内置scaler接力

你说的是对的，工作顺序没变

[dyphire]

工作顺序按理应该不会变的（仍然是先nnedi3后krig的bind），可以看看stat验证一下。区别应该是krig脚本在前会先hook没加工过的luma尺寸，导致chroma放大的尺寸不够才会上内置scaler接力

不正确，krig 和 cfl 这类色度还原算法在 hook 色度平面时还会绑定亮度平面的纹理，它们需要亮度信息来还原色度信息，只有它们工作完成后解绑亮度纹理 nnedi3 之类 hook 亮度平面的着色器才会触发，所以它们的着色器顺序是会影响生效顺序的

咦，看来是我的理解有问题

[hooke007]

在原始的整个链路流程里先luma hook再chroma hook，如果后跑nnedi3这个脚本，虽然不会bind上去，但是传递了“错误”的luma尺寸信息
https://github.com/hooke007/MPV_lazy/blob/45988d7df5346f906efa7b795488ed828299db43/portable_config/shaders/nnedi3_nns128_win8x4.glsl#L18
导致先跑krig脚本话hook到了被前一个脚本改变过的luma尺寸。(这段逻辑有问题把我自己绕晕了，总之就是先做luma bind再chroma bind)我记得之前验证过一次。

如果mpv内部确实是这么执行的话，两个着色器脚本里硬编码的尺寸block越多，哪怕脚本顺序放的正确可能结果也是错的，因为你不知道每个block是不是hook到的正确的位置。。。。有些离奇的拉伸应该就是这么产生的

[yemijun]

可以说进一步降低了在色度平面使用第三方着色器的必要性，在进行测试后CfL如果放置在nnedi3前也会产生类似的结果。目前来看色度平面bilinear/catmull_rom这类内置算法足以实现较好的观看体验。