網誌文章分布

網誌文章分布
入門教程系列:2017年三月,主要是提些播放軟體的安裝。
基本教程系列:2017年四月,會提到一些播放流程丶驅動程式丶播放器設定。
進階教程系列:2017年五月,大多談些濾鏡的事項。
SmoothVideo Project 系列:2017年六月,部分關於SVP的文章
測試筆記:2017年七月~,就是一些相關測試的筆記,錯誤可能較多。
SmoothVideo Project(SVP)日系手繪動漫(Anime)適用參數:永久置頂

由於個人因素,Blog文章停止更新中,留言一樣會回覆,不過可能會延遲數天,預計恢復正常更新時間2018年10月

2017年7月2日 星期日

測試筆記:SVP紀錄(更新進度:2018.03.20)

以下內容大多為我和kevingwn大討論SVP的信件內容,(以下採用A和K代稱我與kevingwn大),
由於之前數次整理信箱,已有部分信件被刪除,故以下對話內容可能有些遺漏。
底色為淡黃色的為編寫此文時新增的結果,而非當時信件內容,
K大之後補充的部分,底色則為淡紫色的,
部分結果為當時的結果,而非最新研究的結果。

此外對話時間可能並非正確時間,會有誤差前後幾天,由於一封信件中可能有多個討論,
討論可能討論數天,因此以下對話將會稍作先後次序的調整,讓閱讀較為流暢。



----------------------------------------------------------------------------------------
2016.11.22

K:
你好,
可以請你幫忙試試一組SVP3的參數嗎?
請回信告訴我用在動畫上的感想,謝謝~

A:
補充日期:2017.07.20
補充內容:
就是此封信件開始了與K大討論SVP參數,也是這一切的開端,沒有什麼意義,但很有紀念價值😆
很感謝過程中K大所提供任何訊息與知識,扮演說明的角色,而我則是簡單的測試參數,觀察不同參數的差異。

----------------------------------------------------------------------------------------
2016.11.23

K:
對應SVP4記得在generate.js裡
avs.WriteLine('SetFilterMTMode("DEFAULT_MT_MODE",2)');
avs.WriteLine('SetFilterMTMode("ffdShow_source",3)');
這邊新增兩行變成
avs.WriteLine('SetFilterMTMode("DEFAULT_MT_MODE",2)');
avs.WriteLine('SetFilterMTMode("SVSuper",1)');
avs.WriteLine('SetFilterMTMode("SVAnalyse",1)');
avs.WriteLine('SetFilterMTMode("ffdShow_source",3)');
效能會好一點點

A:
測試日期:2017.07.12
測試結果:雖然差異很小(左方有新增那兩行,右方則無),不過不開白不開。

K:
這個override.js是用來改變Profile的設定,例如:

levels.pel              = 1;
levels.full             = false;

analyse.block           = {w:32,h:32};

smooth.algo             = 23;
smooth.mask             = {cover:80};
smooth.scene            = {mode:0};

這幾行相當於
Frames interpolation mode: Uniform (max smoothness)
SVP shader: 23. Complicated
Motion vectors grid: 24 px. Large 2
Motion vectors precision: One pixel
Artifacts masking: Disabled (default)
Processing of scene changes: Repeat frame (default)

以及一些Profile沒辦法做到的設定,例如:(舊參數)

analyse.main.levels         = 3;

這行是指只做3階層的搜尋
(我的感覺是可以減少偽影但移動太快的場景就會變成不補幀

analyse.main.search         = {coarse:{distance:-12,bad:{sad:2000}},type:3...

這行近似Search radius: Large和Wide search: Strongest
但將finest level的搜尋改成UMH並將半徑從-2加大變-8

analyse.refine[0]           = {search:{type:2,distance:-4}};
analyse.refine[1]           = {search:{distance:2}};

這邊相當於用To small step 6-8 px.把閾值改成預設的200(比全局更低
並將12px的搜尋改成HEX半徑從1加大變-4
8px的搜尋半徑也加大變2

原本的override.js就是不改變Profile設什麼就是什麼

這份參數我是以滑順為優先
我對偽影的容忍度也比較高
所以只要能提昇滑順但不會增加太對偽影的參數就用上去
因為相較DR來說SVP還是不夠順

A:
如果override.js和Profile如果衝突的話,
這樣SVP會依何者運作呢?
SVP的Profile分成1080P、720P等…
override.js是一視同仁嗎?

K:
會依override.js所設(override=覆寫,覆載)
SVP會先選好Profile
先執行generate.js
再執行override.js
產生C:\ProgramData\SVP 3.1\AVS\ffdshow.avs讓播放器去執行
所以override.js是不分Profile的
除非該Profile是關閉補幀
那override.js也不會作用

K:
SVP分三個步驟

1. SVSuper - 產生倒金字塔狀的多階層影像

以1920x1080為例,SVSuper會做出
3840x2160
1920x1080
960x540
480x270
240x134
120x66
60x32
30x16
...
這樣的一張影像
1920x1080是原圖,其他階層是經由原圖縮放而來
其中3840x2160只有選Half pixel才有,如果選One pixel或Two pixels就沒有
這些階層中解析度最大的稱為finest level
其他的是coarse levels

2. SVAnalyse - 搜尋影像與前後張影像的MV

以SVSuper產生的圖,從coarse levels往finest level一層層搜尋
因為搜尋的區塊只有32,16,8,4這些大小
所以靠縮小原圖來達成近似搜尋64,128,256,...這些大小區塊的結果
因為我認為有些artifacts是因為結果產生的
所以限制只搜尋3層
Level     區塊  相當於原解析度的大小
480x270   32x32 128x128
960x540   32x32 64x64
1920x1080 32x32 32x32
(因為設成One pixel,所以這邊finest level是1920x1080)

搜尋完後會在finest level進行Decrease grid step
Level     區塊
1920x1080 16x16
1920x1080 8x8
然後會得到目前影像的前後MV

3. SVSmoothFps - 以前面得到的MV來產生補幀

這步相關的參數就是
Frame interpolation mode,SVP shader,Artifacts masking這些
這邊是唯一能用到GPU的部份
前兩步其實都是CPU在處理

A:
另外有發現,
如果Motion Vectors grid加大時
可以降低偽影程度,
不過加大的缺點是Blend會多一些
之前在24、28、32px選擇時,
選了中間的28px

K:
是的,之前也是有同樣的感覺
但在內嵌字幕的影片中,32px會發生背景一動字幕會跟著抖動的artifact
所以後來改用24px
理論上網格重疊的部份越多搜尋出的MV越好

A:
補充日期:2017.07.20
補充內容:網格重疊越多會使資源較大,而且搜索的向量會更多,但有時也會因此有較多波浪狀偽影,然而大網格雖然波浪狀偽影會明顯減少,不過卻會增加些畫面黏滯感,因此不建議使用過大或過小的網格大小,目前比較常用的為24~28px

A:
搜索半徑加大
感覺在平移時的滑順程度會增加,
但是如果物體非平移時,
像是頭髮漂蕩的部分,
反而會加大偽影的產生機率

K:
這邊加大搜索半徑是因為
SVP4預設下半徑和網格比例是-8:12px=66%
改成-12:24px後是50%
我想維持和SVP4預設一樣的滑順
然後靠大網格和減少階層來降低artifacts
不過頭髮的部份的確是蠻容易有泡泡狀的artifacts
但減少半徑滑順會降不少

A:
補充日期:2017.07.17
補充內容泡泡狀的artifacts,似乎可以透過增加analyse.main.search.distance來改善,
網格大小則因不同參數而有所有差異,不過目前還是建議24~32px。

K:
其實1,2以外的shader產生的補幀大都有殘影(blend)
(FM也是拿這些blend當中間幀)

21,23雖說會減少halo增加清晰度但我覺得對這些泡泡好像沒用
反而13. Standard因為有抹平,模糊的效果我覺得能減少頭髮的泡泡
但23感覺上還是比較順(可能是心理作用

DR
非常smooth,但偶爾會糊成一片,artifacts還好

SVP
smoothness應該可以調到接近DR,但此時artifacts應該比DR多
如果能找出平衡smoothness/artifacts的參數的話就比DR好

FM
覺得大多是用blend frame來補幀
所以artifacts少,但相對的看起來不smooth
SVP把Artifacts masking開高應該也能接近FM這樣的效果

----------------------------------------------------------------------------------------
2016.11.24

A:
增加搜索階層的效果會增加很少,
這可以理解,
畢竟解析度降低後分析到的資訊量會降低
但應該不會造成artifacts吧?
因為還有後續高解析的MV分析不是嗎?
還是說在低解析時所分析到的MV會對後續高解析無法分析的部分當成基底MV?

K:
你說對了
只要低解析時所分析到的MV的SAD值
比後續高解析的還低
就會維持低解析的結果
Decrease grid step也是依照這個原則

A:
舉例來說,
一個機器人向右移動,
低解析分析出其MV朝右
但機器人在移動時,手臂朝後方移動
高解析分析出其MV朝左
但有部分無法分析,
無法判定區塊則以基底MV為參考
造成部分手臂MV朝右,部分朝左
形成破碎的畫面?

K:
沒錯
我也是想說有些artifacts說不定就是這樣造成的
另外就是我希望只針對小移動做補幀
因為比較容易補得順又不容易補錯
大移動與其補錯不如放棄

A:
網格重疊和單純的小網格差在哪邊呢

K:
就我的理解
網格重疊比單純小網格的計算量高很多
而且較不容易找到錯的MV
因為比對的範圍大

A:
重疊的區域又會怎麼判定呢?

K:
一樣是將原圖以網格大小下去劃分
每一個網格對應一組MV

A:
此外,此處的網格大小
就是SVSuper的最大分析大小對嗎?

K:
是Motion vectors grid這項參數
例如28 px. Large 1
代表用32x32的區塊
每個區塊間重疊4像素
從左上到右下對目前幀和參考幀
做區塊比對(HEX,UMH,EXH這些)
以1920x1080為例
最後會得到(1920/(32-4))x(1080/(32-4))=68x38組MV

A:
有些參數有正有負,好像有些差異

K:
搜尋半徑是負數代表依區塊的對比調整半徑
對比低就用短一點
這樣的優點是可以減少不少的計算量
缺點是複雜的場景可能會掉幀
還有亮度低的場景會變頓(因為半徑都變短了

A:
這是我昨天唯一有心得的一項QQ
UMH會造成明顯的artifacts
EXH在這方面還是比較好
而且UMH並無明顯降低處理器的使用率
至於流暢程度,覺得好像差不多?

K:
可以的話還是用EXH比較好

A:
DR模糊的特性使得眼睛無法精準判定其位置,但大腦依照前後幀來臆測中間幀的位置
所以感覺上會較為流暢?

K:
要滑順覺得還是中間幀要能銜接前後幀的移動讓大腦覺得流暢
即使它有點模糊不清也沒關係
例如一顆球從左橫移到右
補出來的幀只要在中間有個像球的東西
就能串聯起左到右這個移動讓人感到滑順
但只要不是在中間或者不是球形就會感到不順

A:
SVP和FM都太清晰了,所以相對較好可以判定其位置,但因手繪動畫特性,使得感覺不流暢?

K:
以上面的例子來說
SVP是補出來球扭曲到不像球所以會察覺artifacts
FM則是只有blend看起來球是在左邊消失然後出現在右邊XD

A:
不知道SVP會用中間幀去算下一幀嗎?
還是只會用原始幀來運算呢?

K:
我想補幀只是線性內插
例如1 A B C 5
不需要先算出B=3再用
1 A 3和3 C 5才能算出A和C

----------------------------------------------------------------------------------------
2016.11.25

A:
說明網頁中有看到滿多地方提到SAD值
但是不是很理解這SAD值是如何計算的
只知道如果畫面一樣的話,SAD=0
有差異的話,SAD就會增加

K:
SAD就是Sum of Absolute Differences
兩個NxM區塊相減後會得到NxM個差異值
將這些差異值取絕對值再加總起來就是SAD值

可以參考下面這個簡體網頁
https://goo.gl/YE6EdQ
它是用MAE值(差異值取絕對值後加總平均)來預估
跟SAD的差別就是MAE多一個除以NxM而已

A:
搜索半徑降低,
如此一來,大移動因為偵測不到而不補幀
小移動則在偵測範圍內
但要拿捏好這尺度
搜索半徑降低會使得補幀強度下降
但搜索半徑過大又會產生明顯artifacts
這樣理解對吧?

K:
對的
減少階層也能不偵測大移動
這樣就能維持大搜索半徑讓補幀滑順了

A:
我的意思是有兩個相臨且有部分重疊的網格,
一個向右,另一個向左
那重疊部分的MV怎麼處理呢?
直接平均計算?

K:
你想成影像還是分割成一格格28x28大小
但這每個28x28在搜尋時是用32x32去找就好了

A:
Halo的來源?
如果設定網格不重疊,
理論上就不會有Halo的產生?
如果網格有重疊,
那Decrease grid step也可以壓低Halo的產生?

K:
Halo是指網格太大所以移動物邊緣會像黏著背景一樣嗎?
是的話我覺得跟不是重疊而跟網格大小比較有關
同個網格內的像素都是同樣的一組MV(運動向量)
用Decrease grid step減小網格理論上應該可以減低這種artifacts

A:
對比比較是…?
網格內的顏色平均比較鄰近網格的顏色變化?

K:
對比是指該區塊明暗變化的程度

A:
補充日期:2017.07.17
補充內容
由於自適應搜索半徑,其搜索半徑的依據為區塊內的對比差異,而對比差異包含明暗及色彩差異,
大致上算法為:
(原始區塊 - 區塊平均)/區塊大小

A:
那如果搜索半徑是正數呢?
直接比較網格與鄰近網格的內容變化?

K:
搜索半徑是正數的話就不以對比來減少搜索範圍
半徑設多少範圍就多大
計算量會高很多,不建議使用

A:
FM我看起來則是移動時,
邊緣處會閃爍,
應該是Blend造成的

K:
應該是Blend沒錯

A:
如果精度調整到半像素
那finest level也會是3840P囉?(原始1920P)

K:
對。

----------------------------------------------------------------------------------------
2016.11.26

A:
analyse.refine[0].thsad         = 200;
官方說明是區域內SAD值大於此值時(轉換成8x8大小)
就會縮小區塊再次進行計算
不過我用內建的設定改成如下(SVP3)
Motion vectors grid:28px,Large 1
Decrease grid step:To smallest step 3-4px
參數竟然變成
analyse_params="{block:{w:32,h:32,overlap:1},
main:{search:{coarse:{distance:-10}}},refine:[{thsad:65000},{thsad:65000}]}"
thsad 65000,那不就是不進行縮小區塊計算了嗎?

K:
thsad設65000還是有機會進行refine
只是機率會變很低
我也不懂SVP為何是把To small...設成65000

A:
補充日期:2017.07.18
補充內容:至今不知為何SVP3內要設定thsad這麼高,不過SVP4已經拿掉這兩項了。

A:(此為先前levels = 3參數的建議,而且無經過逐幀檢查,現在已不採用)
附上目前經肉眼確認有助於減緩artifacts的幾個參數
levels.pel                              = 2;
        //levels.pel 設2時表現最佳,設1小輸2的表現,設4會產生許多artifacts
analyse.block.w                         = 32;
analyse.block.h                         = 32;
analyse.block.overlap                   = 2;
        //14px中偏少artifacts,16px輕度artifacts,24px極少量artifacts
analyse.main.levels                     = 3;
        //三階層分析,經測試設2或4皆有負面影響
analyse.main.search.type                = 4;
        //2HEX搜索,3UMH搜索,4無窮搜索
analyse.main.search.coarse.type         = 4;
        //2HEX搜索,3UMH搜索,4無窮搜索

K:
對比不是看鄰近而是看區塊本身

如圖藍色8x8區塊的對比(有紅有白)較高所以半徑較大(4px)
綠色區塊對比低(只有紅色)所以半徑小(2px)
(這只是舉例,實際上動態調整的幅度要看原始碼)

analyse.main.search.distance = 0;代表不搜索finest level
One pixel的設定是
levels.pel              = 1;
levels.full             = false;
再加上analyse.main.search.distance = 0;就是Two pixels
analyse.main.search.coarse.distance比較特別,0其實是代表-10

A:
此外如果pel設2(半像素精度)時,
analyse.main.search.distance設10px,等於實際原圖的5px?

K:
對,可以這麼想

----------------------------------------------------------------------------------------
2016.11.28

A:(此為先前levels = 3參數的建議,而且無經過逐幀檢查,現已不適用)
找到一個關鍵參數,可以解決大部分的artifacts
analyse.main.penalty.lambda             = 0.5;
        //消除果凍感(黏滯感),降低大量artifacts,缺點是會稍微降低流暢度

目前測試出最理想的參數,麻煩您測試一下
低artifacts丶低Blend丶缺點是似乎還不夠流暢
(此為先前levels = 3參數的建議,而且無經過逐幀檢查,現已不適用)
levels.pel                              = 2;
analyse.block.w                         = 32;
analyse.block.h                         = 32;
analyse.block.overlap                   = 2;
analyse.main.levels                     = 3;
analyse.main.search.distance            = -3;
analyse.main.search.coarse.distance     = -6;
analyse.main.search.coarse.bad.sad      = 2000;
analyse.main.search.coarse.bad.range    = -12;
analyse.main.penalty.lambda             = 0.5;
analyse.refine[0]                       = {thsad:1000,search:{distance:4}};
smooth.algo                             = 2;
        //建議2和23都可以試試看,我是比較喜歡2,Blend少,23則是較流暢
smooth.mask.cover                       = 50;
smooth.mask.area                        = 25;
smooth.mask.area_sharp                  = 0.5;
        //輕微消除一些artifacts,不過好像設太低,沒什麼差異的樣子XD
smooth.scene.mode                       = 3;
                //0 Uniform,3 Adaptive
smooth.scene.limits.m1                  = 2400;
smooth.scene.limits.m2                  = 4101;
smooth.scene.limits.scene               = 5600;
        //藉由拉高m1 m2及轉場設定,來提高Adaptive的流暢程度,避免artifacts
smooth.scene.limits.blocks              = 40;
        //加大閥值,增加變化大時的流暢度

----------------------------------------------------------------------------------------
2016.11.29

K:
移除area_sharp後有變好了
不過比較難的artifacts我覺得還是差不多
(尤其是K-ON!!的NCED2,1:06澪的頭髮那邊XD)

我平常都是用DxD一期的ED測試
主要看鋼管舞那邊夠不夠滑順>///<
十字架與吸血鬼二期ED之前也是有不少artifacts
好像是levels設3後才好一些

----------------------------------------------------------------------------------------
2016.11.30

K:
看了一下原始碼
當設成Half pixel(level.pel=2)時,階層應該如下

Level       Resolution
0(finest)   3840x2160
1               960x540
2               480x270
3               240x134
4               120x66
5               60x32
(24px只算到6階層)

所以analyse.main.levels=3其實是算3840x2160,960x540,480x270這3階
終於理解為何analyse.main.search.distance和refine[0].search.distance
的預設值都是level.pel的倍數了
因為finest level變大所以SVP把搜索半徑也跟著放大

----------------------------------------------------------------------------------------
2016.12.03

A:(舊參數及使用i5-6600K@4.7Ghz)
我用MPC-BE 然後掛LAV
BFRC和DR有改成攔阻
SVP關閉時,軟解10bit h.265影片CPU使用率大概是35%

K:
我關閉SVP播
Kantai Collection OP01 [Ma10p_1080p][x265_flac].mkv
CPU使用率不超過15%
加上SVP後在開頭和結尾較複雜的段落會衝到6,70%
這樣看來i5真的跑不動orz

複雜的場景可能是因為很多區塊找到的SAD都高於thsad
所以全都24px→12px→6px這樣算下去
要減少計算看來只能提高thsad或乾脆只refine到12px就好

之前也有試過設Two pixels來放棄finest level(analyse.main.search.distance=0)
然後refine[0].thsad=0強制算12px
但結果變得不滑順

A:
補充日期:2017.07.18
補充內容
由於此為使用舊參數測試,為了增加流暢度而狂加搜索半徑或縮小網格等,導致消耗資源大增,
主要是levels:3有其流暢度的極限,因此目前改用levels:4,新研究出來的參數比過去使用更少的資源。

K:
lambda大,離比較遠的位置就可能會被忽略
如果因此忽略較好的移動就會造成artifacts

cost = 該level的lambda * (dx*dx+dy*dy) / 256

----------------------------------------------------------------------------------------
2017.01.07

A:(舊參數)
不,可能我敘述不佳,使得您可能誤會了。
那是為了用眼睛判斷所以故意讓Blend明顯顯示出來的,
這樣才有辦法快速找出是否超過smooth.scene.limits.blocks值
找到之後,當然就要把Processing of scence change改回Repeat
增加這值可以增加流暢度,(原先不補的部分,因為低於此值,所以從不補變成有補)
如果說拉高這項會造成Blend變多,
那主要是Complicated模式造成的,
因為這模式只要有補,都會造成輕微Blend(這也是我棄Complicated改Sharp的最大理由)
簡單來說就是只要將smooth.scene.limits.blocks設定70,
就能提高流暢度。

K:(舊參數)
拉高blocks變得非常滑順
跟DmitriRender有的比!

但就跟DR一樣,blend變多了
所以我改成將zero降低為100
這樣會增加好的block數量進而使整體百分比下降
所以不會影響原本變動很大的場景變成blend
不過效果比起blocks輕微很多

----------------------------------------------------------------------------------------
2017.01.08

A:
請問Zero這項的意思是甚麼呢?
根據測試,Zero此值降低會較為流暢,但是偽影將增加
此值增高時,將較不流暢,但是偽影會降低。
您的意思是blocks不動,然後降低Zero?

K:
當adjusted SAD大於limits.scene的區塊數量(1)
佔adjusted SAD大於limits.zero的所有區塊數量(2)
的百分比超過limits.blocks
就判斷成場景變換

所以要增加滑順度
(讓原本被判斷成場景變換而不補幀的地方變成要補幀)
可以
提高scene來減少(1)的數量
或降低zero來增加(2)的數量
或直接提高blocks這項門檻

簡單圖示:
零-----limits.zero---------limits.scene---------無限大
|                 |                            |<            (1)            >|
|                 |<                         (2)                            >|


我現在只降低zero其他不動(舊參數)
在SVP的論壇上也有看到
smooth.scene.limits.scene        = 4400;
smooth.scene.limits.zero        = 0;
smooth.scene.limits.blocks        = 23;
設成這樣的
所以看個人喜好和容忍程度吧

----------------------------------------------------------------------------------------
2017.01.16

A:(舊參數)
這幾天稍微測試了一下,還是覺得
analyse.block.w                         = 32;
analyse.block.h                         = 32;
analyse.block.overlap                   = 2;
這樣比較好,或overlap = 1

K:
同意

A:(舊參數)
search.type 還是4的表現比較好,
目前設定是
analyse.main.search.type = 4;
analyse.refine[0]        = {thsad:75,search:{distance:-6,type:3}};
analyse.refine[1]        = {thsad:300,search:{distance:-2,type:2}};

而analyse.main.penalty.plevel太低反而有些場景降低流暢度
所以目前我是上調到1.2

K:
後來改來改去我也把type改回4了
main:{
        search:{
                coarse:{
                        distance:-8
                },
                distance:-4
        },
        penalty:{
                lambda:0.1,
                plevel:1
        },
        levels:3
}
artifacts有少一點點
但搜尋量看來會增加不少
artifacts好像很難再減少了

refine則維持
[{search:{type:2,distance:2}},{search:{type:2,distance:2}}]
比distance:1滑順些
搜尋量也會比distance:2少一些

plevel小於1反而會使lambda值隨level提高

A:
補充日期:2017.07.20
補充內容後來測試plevel過低的確會使流暢度下降,不建議設太低。

A:
//analyse.main.penalty.lsad             = 8000;
//analyse.main.penalty.pnew             = 50;
//analyse.main.penalty.pglobal          = 50;
//analyse.main.penalty.pzero            = 100;
//analyse.main.penalty.pnbour           = 50;
//analyse.main.penalty.prev             = 0;
這幾個參數搞不太懂用意

----------------------------------------------------------------------------------------
2017.01.18

K:
lsad
SAD超過此值會試著降低lambda值(不過感覺8000很難被超過

pnew
是每個位置的搜尋時都會加上這個值跟之前的結果比較
另外這個值是以比例的方式加上SAD
SAD + SAD * pnew / 256
和其他penalty值是直接加上SAD不同

pglobal
統計出來的全域MV的SAD會加上這個值去和其他比較

pzero
零位移的MV的SAD會加上這個值去和其他比較

pnbour
週圍8個MV的SAD會加上這個值去和其他比較

prev
是指參考反方向的MV算出SAD
SAD值再加上prev和其他做比較

----------------------------------------------------------------------------------------
2017.01.19

A:(舊參數)
lsad
由於lambda原先設定就都很小了,這參數效果看不太出來

pnew
經測試發現此項較低時,可以提高流暢度
雖然效果不大,但還是看的出來

pglobal
此項也是看不太出效果的參數...

pzero
這參數效果非常明顯,越高越滑順

pnbour
這參數也非常明顯,越低越滑順

prev
這參數越大越不順...

當然,更流暢的同時
偽影也多了一點...

----------------------------------------------------------------------------------------
2017.01.21

K:
用起來感覺是pnbour:35這項幫助不少

A:
補充日期:2017.07.20
補充內容:這幾個參數,到現在還是有幾項尚未測試出其明確的效果,目前常改動參數為pzero丶pnbour。

----------------------------------------------------------------------------------------
2017.02.16

A:
今天用了7700K測試HT對於SVP的效果
4.7Ghz 4C4T
CPU分數4194

4.7Ghz 4C8T
CPU分數4423

如果只從分數來看的話,差異大約是5.5%左右
如果是實際播放影片
4C4T 使用率80%左右
4C8T 使用率60%左右
另外,在不運行SVP時
4C4T 的使用率約35%
4C8T 的使用率約15%
所以,HT對於SVP的效果的確有限,約5%
但是HT對於其他(MPC-BE丶LAV丶madvr丶XySub)有著不錯的效果

K:
扣掉不運行SVP的使用率
4C4T 80%-35%=45%
4C8T 60%-15%=45%
等於SVP的使用率根本沒有降低XD

btw,參考你的設定後我改成下面這樣(舊參數)

global super_params="{scale:{up:0},gpu:1,pel:1,full:false,rc:true}"
global analyse_params="""{block:{w:32,h:32},
        main:{
                search:{
                        coarse:{distance:-6},
                        type:2,distance:-6
                },
                penalty:{pnbour:35},
                levels:3
        },
        refine:[{search:{type:3,distance:-3}},
                {search:{type:2,distance:-4}}]
}"""
global smoothfps_params="""{rate:{num:5,den:2},
        algo:23,
        mask:{cover:80},
        scene:{mode:0,limits:{scene:1600,blocks:43}}
}"""

預期CPU使用率會比全部用type:4,distance:-6低
但結果是差不多
不過artifacts和滑順我覺得還算滿意

----------------------------------------------------------------------------------------
2017.03.07

A:(舊參數)
前幾天稍微測試了一下,
發現在analyse.main.levels=2的時候,
可以降低非常多artifact,
但是代價是會變得稍微不流暢一點。

K:
levels=2我覺得太極端了(2是最低值
這樣coarse level就只剩1層
在比較大的移動可能效果不好
levels=3我就覺得常卡卡的
所以又把coarse.distance提高及降低penalty.pnbour

A:
不知道有無辦法讓前一層的MV的SAD加上某值再進行比較呢?

K:
在原始碼中前一層的penalty寫死為0
但想想pnew,pglobal,pzero,pnbour,prev也是可以設為負值的!
不過我沒這樣試過就是XD

A:
近來發現analyse.main.penalty.prev拉高也有助於壓低artifacts

K:
我簡單試起來感覺效果不是很明顯
改天再多試試

A:
對於SVP充滿期待有很大一部分就是10bit,終於推出了 (感動
花了大概10小時左右在研究如何以10bit輸出,
內建的mpv可以順利撥放59.94fps 10bit沒問題,
Potplayer內建的VapourSynth也可以開啟使用,
開啟的地方藏的好隱密...

但是...
Potplayer內建的VapourSynth不支援P010格式
所以即使用VapourSynth輸出也還是8bit...

K:
抱歉,沒注意到還有這個限制<(_ _)>
難怪官網也只提到mpv和vlc而已

A:
其次,
Potplayer只要用VapourSynth開啟SVP,
保證不流暢,因為CPU使用率卡在30%升不上去
感覺像只有使用單執行續。
尋找支援VapourSynth的DirectShow Filter中...

K:
其實AviSynth+也支援10bit
但卡在ffdshow不支援
MPC-HC和MPC-BE看來也不想弄這塊
我想可能還是只能期待potplayer了

----------------------------------------------------------------------------------------
2017.03.10

K:
之前是試起來降低pnbour就改善了很多
但有些場景還是沒轍
例如戰車少女劇場版開戰車去便利商店
路上前景是華背景是破爛熊看板那段
好像只能增加level和distance

A:
是這幕對吧
這幕要流暢的最好的方法就是
levels設到4或5
或者加大analyse.main.search.coarse.bad.range
但是這兩種都會增加非常多artifacts,
測試過程中也發現bad.range是很多偽影的來源
這幕開FM的效果最好 XD

現在我測試參數是否會太高都用
The Asterisk War OP01
這是我目前實測開SVP後,CPU使用量最高的1080p動畫類影片

K:
對10bit也還沒迫切的需求
我後來放棄lambda=0.1了
因為artifacts增加
也在想refine是否需要兩次

A:
refine我是覺得在偽影多的影片才需要開到2次,
一般開1次就算足夠了。

下面這是目前採用的參數,(舊參數)
在URA-ON!!表現尚可,但是在少女與戰車的片段還是不太行
少女與戰車那段要流暢造成的偽影太多。

下面這份參數已經需要用mask來壓制偽影,
但是使用mask會有新的artifacts產生。

主要是analyse.main.search.coarse.distance參數
如果半徑設的大,偽影就多很多
但如果設太小,就不流暢

/***** SVAnalyse options *****/

analyse.block.w                         = 32;
analyse.block.h                         = 32;
analyse.block.overlap                   = 1;

analyse.main.levels                     = 4;
analyse.main.search.type                = 4;
analyse.main.search.distance            = 4;
analyse.main.search.coarse.type         = 4;
analyse.main.search.coarse.distance     = 3;
analyse.main.search.coarse.bad.range    = 0;

analyse.main.penalty.lambda             = 10.0;
analyse.main.penalty.plevel             = 1.4;
analyse.main.penalty.pnew               = 75;
analyse.main.penalty.pglobal            = 75;
analyse.main.penalty.pzero              = 25;
analyse.main.penalty.pnbour             = 75;
analyse.main.penalty.prev               = 20;

analyse.refine[0]                       = {thsad:9,search:{distance:4,type:4}};
analyse.refine[1]                       = {thsad:33,search:{distance:2,type:4}};

/***** SVSmoothFps options *****/

smooth.mask.cover                       = 54;
smooth.mask.area                        = 30;

----------------------------------------------------------------------------------------
2017.03.12

A:
這兩天花了一些時間研究,
為了調整參數,又跑回去開啟FM來看FM是怎麼處理畫面的,
結果驚覺...
FM的artifacts也不少阿,而且部分畫面好卡
以前看不是artifacts很少以及夠流暢的嗎?眼睛進化了? XD

K:
用過更順的就回不去了XD

A:
因為上一封的參數偽影實在是太多,
花了不少時間慢慢調整參數。
以下參數調整全部是基於螢幕更新率71.928hz為基準

/***** SVAnalyse options *****/

analyse.block.w                         = 32;
analyse.block.h                         = 32;
analyse.block.overlap                   = 2;

analyse.main.levels                     = 4;
analyse.main.search.type                = 4;
analyse.main.search.distance            = 4;
        //此項無仔細比較,效果好像不是很明顯。參數是隨意設定的。

analyse.main.search.coarse.type         = 4;
analyse.main.search.coarse.distance     = 3;
        //設2的半徑太小,很多地方不夠流暢,設3以上偽影會多很多,可以加強smooth.mask參數來提高此項容許值。

analyse.main.search.coarse.bad.range    = 0;
        //增加此項可以提高流暢度,但是設-2以上偽影就會增加很多,最終決定放棄開啟。

analyse.main.penalty.lambda             = 3.5;

        //效果有限。根據plevels說明,此項應該越小越流暢。

analyse.main.penalty.plevel             = 1.3;
        //此項越小越不流暢,但太大也會增加偽影的機率。

analyse.main.penalty.pnew               = 135;
        //此項效果也不甚明顯

analyse.main.penalty.pzero              = 0;
analyse.main.penalty.pnbour             = 75;


analyse.refine[0]                       = {thsad:50,search:{distance:3,type:4}};


/***** SVSmoothFps options *****/

smooth.mask.cover                       = 50;
smooth.mask.area                        = 13;
smooth.mask.area_sharp                  = 0.6;
        //此項稍微設小,可以讓mask造成的偽影不明顯
smooth.scene.limits.blocks              = 45;
        //60hz螢幕建議此項調整成52。72hz建議調整成45。

目前這套參數是最為滿意的,
絕對是目前最好的動畫類補幀參數無誤。
昨晚有用這套參數看電影,半徑不夠,不適用XD

A:
補充日期:2017.07.20
補充內容
當時會設為71.928hz主要因素是我認為流暢的畫面幾乎都是uniform模式,
而uniform模式根據SVP官方描述,每10幀只有2幀為原始幀,
若改為71.928hz(影片整數倍更新率)則可以提高到9幀中有3幀為原始幀。
Frames interpolation mode:
0 -     uniform interpolation for maximum smoothness.
        For example for 24->60
        conversion output will be: "1mmmm1mmmm...",
        where "1" stands for original frame and "m" for interpolated one.

----------------------------------------------------------------------------------------
2017.03.13

K:
稍微試了一下

我覺得關鍵在於levels=3真的太少了
設成4真的好不少
GuPdF那邊的破裂也減輕很多
而且在提高了blocks使補幀力道提高後
refine看來1次也就夠了
artifacts變少也更省CPU
原本做2次也只是要提高補幀力道

bad之前怎麼調都無感
提高levels後就有差了
關掉後artifacts的確少了
看來關鍵還是不要搜尋太遠的位置
penalty都用預設看起來也還ok
這禮拜再慢慢調使artifacts更低

感謝你的分享~

現在的設定
super_params="{scale:{up:0},gpu:1,pel:1,full:false}"
analyse_params="""{
        block:{w:32,h:32},
        main:{
                search:{
                        coarse:{
                                distance:-5,
                                bad:{range:0}
                        },
                        type:2,
                        distance:-5
                },
                levels:4
        },
        refine:[{
                search:{
                        type:3,
                        distance:-3
                }
        }]
}"""
smoothfps_params="""{
        rate:{num:5,den:2},
        algo:23,
        mask:{cover:80},
        scene:{
                mode:0,
                limits:{
                        scene:1600,
                        blocks:42
                }
        }
}"""

----------------------------------------------------------------------------------------
2017.03.16

A:
有個參數,
個人強烈建議稍作變更
analyse.main.search.coarse.distance
此項設-5的效果有限,
而且有時反倒會造成反效果,
建議設定+3~+4,
效果真的會好很多,尤其是破爛熊看板的部分

K:
看板那邊我用trymany才有改善
但-5的確artifacts比較明顯
後來又微調了幾個參數
super_params="{scale:{up:0},gpu:1,pel:1,full:false}"
analyse_params="""{
        block:{w:32,h:32},
        main:{
                search:{
                        coarse:{
                                // -5的artifacts明顯,-4好些
                                distance:-4,
                                bad:{range:0},
                                // trymany減輕撕裂,可以不用調pnbour
                                trymany:true
                        },
                        type:2,
                        distance:-5
                },
                // 感覺有增加滑順,但可能是安慰劑效果
                penalty:{lambda:11.5,plevel:1.6},
                levels:4
        },
        refine:[{
                search:{type:3,distance:-3}
        }]
}"""
smoothfps_params="""{
        rate:{num:5,den:2},
        algo:23,
        mask:{cover:80},
        scene:{
                mode:0,
                limits:{scene:1800,blocks:39}
        }
}"""

目前用起來很滿意

----------------------------------------------------------------------------------------
2017.03.17

A:
coarse distance用+3~+4的效果真的不錯,
比較不會因為區塊對比高低而影響半徑,
負數平均搜索半徑只有其絕對值一半不到,

K:
官方是說大約是1/3
我比較偏好用負值
artifacts比較少
也蠻滑順的
而且很省CPU

A:
trymany這項碰的比較少,
因為總覺得好像沒什麼效果。

K:
之前試起來的確沒啥效果
是剛好在GuPdF有效才打開

A:
lambda在distance小的時候效果不明顯,
但plevel加大的效果算明顯變順,
不過超過1.8之後的效果好像就都差不多,
所以不是安慰劑啦~

K:
因為plevel越高lambda隨level遞減越快
太高還是會有些artifacts
所以不加太大並增加lambda以減少artifacts
下表是1080p(約6階)時lambda=10.0的情況(圖表錯誤,下方有修正版本)

A:
補充日期:2017.08.13
補充內容
雖然上方圖表lambda不完全正確,但依然可以觀察plevels改變的影響,故未刪除。
若將main.levels設為X時,那第X層的lambda會被強制設為0,
下圖為main.levels:4時,第4層(level 3)的lambda被調整成0
更正:level 3 - 135p 應改為 level 3 - 134p 才正確

----------------------------------------------------------------------------------------
2017.03.19

A:
目前coarse distance這項我是決定設定+3,
+4雖然更順,但是artifacts明顯多不少。
一般最大使用率約80%
平均CPU使用率大約落在50%左右

 scene降低這麼多,會變不順吧?

K:
因為我偏好不要有殘影
這邊隨個人喜好調整就好

A:
scene 1800,limits.blocks 39
還滿容易頓一下的,不說DxD OP部分,
Kantai Collection 的OP也會,
scene此項SVP預設是4000,是不是打錯了?

K:
blocks 39是有點低,後來提高到40
scene我是參考自適應模式預設的m1:1600
超過就當成場景改變以降低artifacts
1600有點低所以提高到1800

看了一下原來SVP對10bit的支援是將影片轉成8bit去找MV
再拿MV回10bit去補幀XD

limits就是讓SVP決定這個畫面要不要補幀
喜歡盡量補幀的就提高m1,m2或設成Uniform提高scene和blocks
喜歡盡量保留原畫面的就降低scene和blocks
隨個人口味調整就好

----------------------------------------------------------------------------------------
2017.03.25

A:
感謝您的解說,想請教一下
plevel是否不論level設定如何,lambda值皆固定?
意即假設lambda設定為10,plevel設為1.5
那即便level設為0,
在level 0(1080p)的lambda便是1.316,
不會隨著level設定而有說變化對吧?

K:
沒錯~

A:
這幾天有發現一個參數會影響到偽影
smooth.scene.luma,預設為1.5

再看一些對比較高的部分,
像是黑夜中的仙女棒這種背景為深色,主體為亮色系的在移動的畫面,
此項偏高時會造成嚴重artifacts,
還在測試,
從4.0開始測試,目前試到1.3,
覺得1.3的效果最佳,晚些會在往更低繼續測試。

K:
看了一下官網的說明
luma為SAD的除數
所以越高SAD越低所以越容易補幀=>artifacts變多
越低越不容易補幀

A:
抱歉這麼久才回復,
因為最近不論調整甚麼參數都沒有帶大的改善
大多是改好了這裡,另一處又變差...orz

K:
的確
我已經滿足於現在的設定
暫時也沒動力去試了orz

btw今天去看了聲之形
這部有不少比手語的畫面
這樣的畫面常有artifacts
我猜是手指跟手指距離很近容易找到錯的MV(像窗戶欄杆也是
希望之後BD補起來不會太糟XD

A:
補充日期:2017.07.20
補充內容
smooth.scene.luma效果還不確定,因為3月的測試與6月的測試結果有差異。

----------------------------------------------------------------------------------------
2017.04.06

A:
抱歉,這麼晚才回復您,
原因還是和之前一樣,參數調整上沒有什麼重大發現...
能調的就那些,效果也沒有甚麼重大改變
luma這項後來試的結果是1.0~1.2較佳,
動畫類因為亮暗區邊界比較明顯,
luma這項偏高的話比較容易在亮暗邊界有artifacts。

此項我自己是常駐1.0。
因為流暢度也沒明顯降低,1.0~1.2的偽影倒差不多,
可能心理因素,感覺1.0的偽影應該丶也許丶可能會好一點?

A:
補充日期:2017.07.20
補充內容
smooth.scene.luma效果還不確定,因為3月的測試與6月的測試結果有些差異。

K:
SVP的演算法差不多能調的就是這樣了

1. 準備金字塔狀圖層
2. 分成區塊找MV,參數影響找的速度但似乎不太影響正確性
3. 根據整體SAD決定要不要補,參數為閾值但很難完美區分出差別
4. 用找到的MV補幀,可以用mask降低artifacts但效果有限

除非改演算法不然效果應該差不多了

A:
髮尾丶手指丶欄杆丶小草都很容易找到錯的MV,
近來有想要嘗試開啟analyse.main.search.coarse.satd參數

有稍微上網找一下演算法的文章,
不過看到的都是一堆公式orz,實在看不懂,
有看到satd比較適合運用在大塊的預測上(coarse levels),
而sad較適合運用在較精細的部分,
原因好像是satd經過轉換後比較容易陷入區域最佳值,
sad則是範圍內最佳值,所以實際半徑satd會比sad小一點。
(以上是找H.264演算法得來的資訊,非SVP)

K:
這應該跟UMH,HEX這些搜尋演算法有關
只要不是EXH找出來的都算是區域最佳值
區域最佳值對視訊壓縮來說還好
只是不能壓得更低而已
要不要拿速度去換壓縮率見人見智
但補幀的話區域最佳值就可能造成artifacts

A:
但在先前測試中所調整的動畫類參數大多是縮小搜索範圍以達到較低artifacts,
加上在類似髮尾丶手指這類很容易找到錯的MV大多是搜索半徑太大造成的,

K:
對,因此才會加上lambda來讓遠一點的位置不要影響判斷

A:
想說是否利用satd特性來壓低手指這種artifacts,
satd開啟後的缺點是,CPU使用率暴增...
要降 refine的次數 或 降搜索半徑 才能流暢播放。

K:
從理論來看
假設要搜尋髮尾
頻率域(SATD)的差異應該會比空間域(SAD)低
要看這特性對搜尋是否有助益

----------------------------------------------------------------------------------------
2017.04.20

K:
doom9上SVP的資料不多
SVP自己的論壇上比較多一點
https://www.svp-team.com/forum/viewforum.php?id=7

A:
這幾日所得訊息:
1. HD630 不支援BlueskyFRC,
    DXVAChecker檢查過了,這功能被Intel拿掉了。

K:
看了一下手邊的Iris P580也是寫不支援
看來Intel放棄這塊了
反正效果也不怎麼樣XD

A:
2. SAD和SATD表現有好有壞,還看不太出來哪項更好一些。(逐幀比對)

K:
看了一下比對影片
在finest level上SAD和SATD差別的確不大
偶爾SATD的畫面線條比較清楚而已
我是認為維持用SAD就好

A:
3. SVP著色器,13.有時表現更勝於23.,尤其是在畫面快速移動時。
   (GPU渲染時,關閉GPU渲染時尚未確認)

K:
我原本也是覺得13th比較順
23th差別不大而且比較吃GPU(印象中還可能會跑不動
是在調整參數後才覺得23th比較滑順
之前有逐幀比較覺得
對動畫來說11th,13th,21th,23th
通常差別倒是沒有很明顯
不過那時沒有大量比較就是(太麻煩了

A:
4. SVP著色器2.和23.在快速移動時邊界會有偽影,13.不會。(GPU渲染時)

(圖片上方黑影)

K:
這點真的是很明顯有差
雖然透過調整參數後可以減緩這現象
但背景快速移動時字幕類的小物體還是會常常變形
這邊很在意的話只能換成13th來解決

另外對於23th感覺比13th順
我有個猜測是13th比較類似DR的動態模糊
而23th線條比較清楚
在慢速移動上23th會看起比較滑順

A:
5. 關閉GPU渲染,第4點問題即可解決。

另外,
有壓一些比對影片上youtube,結果被youtube壓得慘不忍睹,壓成4K丶CRF 0上傳都一樣爛XD

K:
我也很想知道怎麼才能讓youtube不要重壓
但好像沒辦法

A:
補充日期:2017.07.20
補充內容:徵求影片上傳Youtube不會被壓得太爛的方法。

A:
想請問您找svp的文檔是從哪裡找呢?翻了討論區沒找到
有個參數一直很好奇,
smooth.scene.force13,但找不到資料。

K:
文檔是說原始碼嗎?
http://www.svp-team.com/files/gpl/svpflow1-src.zip
開發者只有公佈在doom9
而且這只包含了SVSuper()和SVAnalyse()
(因為是從MVTools改來的,必須公開原始碼)
沒有SVSmoothFps()
(因為這邊用到了GPU加速,是SVP自己開發的)

force13我也只查到在俄文的更新日誌有提到XD
https://www.svp-team.com/wiki/Changelog/ru
在3.1.5版提到的(用google翻成英文)
A slight improvement in quality - SVP moves to the 13th shader on "bad"
frames, depending on the quality of the scene change.
See generate.js: smooth.scene.force13 and smooth.scene.limits.m1;
但比對英文的更新日誌卻沒有See generate.js...這行

而且安裝3.1.5也看不出來generate.js有寫什麼orz

這參數是SVP自己加的,所以也沒辦法參考MVTools
只能自己比對效果或乾脆問開發者了

以下是閒聊,

最近doom9上有個SVP相關的話題
https://forum.doom9.org/showthread.php?t=174410
有份叫作jm_fps()的MVTools參數據說效果不錯
可惜我用學戰OP試了一下偽影還蠻多的XD

後來我也覺得limits.scene用1800太低了
所以照你之前的參數調整了一下
不過還是調的比較保守

----------------------------------------------------------------------------------------
2017.04.24

A:
algo23 13 Fate Stay Night 2006 [09].mp4
01:08處,Saber穿越樹林片段
逐幀來說看起來是23th表現比較好,
但是撥放時,我反而比較喜歡13th的表現。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
23th播放起來扭曲的比較明顯
但逐幀看時線條比較清楚
00:25處的pan up也是如此

A:
GPU CPU ニセコイ (Creditless ED2).mp4
00:32處上方,
GPU渲染有明顯黑影,估計最嚴重的有20px以上
CPU渲染也有一點點,不過大概2~5px而已

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
這邊看要不要改成adaptive range
或是只做1次refinement就好

A:
請問Vapoursynth有辦法排版嗎?
像這樣,

不然好難閱讀 orz


K:
可以用SVP官網提到的三個雙引號寫法
https://www.svp-team.com/wiki/Plugins:_SVPflow#More_JSON_magic

或是可以用反斜線,例如

A:
前陣子有看過doom9上的InterFrame 2.8.2,
這是採用svp核心的腳本,但它針對手繪動畫的表現也不是很好,
看了一下,半徑好像設的有點大。

K:
jm_fps()後來看了一下它預設的block大小是16
改成32應該會有改善
不過我後來就沒試了
InterFrame()應該也是如此
但它一段時間沒更新了

可惜MPC-HC還不支援Vapoursynth就是

----------------------------------------------------------------------------------------
2017.04.28

A:
GPU Linear Accel World Creditless ED2

        GPU Linear關閉後的畫面會稍微糊一點點(00:01.885)
        不過SVP作者推薦開啟
        https://forum.doom9.org/showthread.php?t=164554&page=11

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
找不到什麼是linear light的說明
姑且假設跟photoshop圖層混合模式的線性光源意思一樣

https://helpx.adobe.com/tw/photoshop/using/blending-modes.html
依照混合色彩,用增加或減少亮度的方式,將顏色加深或加亮。
如果混合色彩 (光源) 比 50% 灰階亮,增加亮度會使影像變亮;
如果混合色彩比 50% 灰階暗,減少亮度會使影像變暗。

簡單來說線性光源混合的對比會比單純的混合來得提高
所以偽影也變明顯了XD
的確可以考慮關掉來減輕偽影
而且還能降低GPU使用率的樣子
http://www.svp-team.com/forum/viewtopic.php?pid=60462#p60462

----------------------------------------------------------------------------------------
2017.04.30

K:
doom9那個jm_fps討論串po了一個韓國團體的MV

其中百葉窗的片段被拿來比較效果
果不其然SVP這邊表現蠻慘的XD

但jm_fps用blksize=32就沒啥偽影
我很好奇所以試了一整天
結果是SVP就算盡可能和jm_fps用的參數一樣
但補出來的偽影就是很多orz
令我懷疑SVP是不是從MVTools改過來後被改壞了

參數大概如下,

MSuper(hpad=16, vpad=16) ~= SVSuper("{
        pel:2 // pel=2
        gpu:0,
        scale:{
                up:2, // sharp=2
                down:2 // rfilter=2
        }
}")

MAnalyse(blksize=32, overlap=4, search=3, dct=0)
MRecalculate(blksize=16, overlap=2, thSAD=100) ~= SVAnalyse("{
        block:{
                w:32, // blksize=32
                overlap:1 // overlap=4
        },
        main:{
                search:{
                        type:4, // search=3
                        distance:2, // pelsearch=pel
                        coarse:{
                                distance:2, // searchparam=2
                                satd:false, // dct=0
                                bad:{
                                        sad:10000, // badSAD=10000
                                        range:24 // badrange=24
                                }
                        }
                },
                penalty:{
                        lambda:16, // lambda=1000*blksize*blksizeV/64
                        plevel:2, // plevel=linear
                        lsad:1200, // lsad=1200
                        pnew:50, // pnew=50
                        pglobal:0, // pglobal=0
                        pzero:50 // pzero=pnew
                }
        },
        refine:[{
                thsad:100, // thSAD=100
                search:{
                        type:2, // search=4
                        distance:2 // searchparam=2
                }
        }]
}")

MFlowFps(blend=false, ml=200, mask=2) ~= SVSmoothFps("{
        algo:23, // mask=2
        mask:{
                cover:200 // ml=200
        },
        scene:{
                blend:false // blend=false
        }
}")

結果那個百葉窗用我自己的參數偽影也還是沒有jm_fps那麼少
但jm_fps用在動畫上還需要更多調整
而且速度差太多了
所以還是在SVP上繼續努力吧...

----------------------------------------------------------------------------------------
2017.05.01

A:
針對黑影/黑邊偽影,進行測試,不過測試樣本很少,待以後多次測試後確認
refine 1 2  ニセコイ(Creditless ED2)
refine 1 2 [linear off] ニセコイ(Creditless ED2)
        refine次數對於邊界黑影出現次數無關連,僅有濃淡差異,
        refine 2次的黑影濃淡變化較大,確認與linear無關。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
關於refine 1 2的比較
是否將thsad都設為0差異才比較明顯?
不過我想refine 2次的CPU使用率高了快一倍
還是盡量用1次比較好

A:
MAnalyse
Can be faster than original version (with chroma=true) by 20-40%

K:
這邊是指SVP自己魔改的MVTools比原版的快,不是指SVPflow本身
(不過這邊的改法也沿用到了SVPflow)
我比較了下兩邊的原始碼
原版的作法是計算完明度SAD,彩度SAD和lambda的cost加總後比較
SVP改成不全部算完加總才比較
而是每算完一個值就做比較,比較大就不用往下記算其他值了
就結果來看會是一樣
但速度上有可能比較快沒錯

A:
jm_fps的參數是以下這樣嗎?(原信件內容遺失)
如果是的話,百頁窗那邊的偽影還是不少呀?或是我漏了哪個步驟?

K:
把blksize設成32偽影應該會少些
我是拿720p的影片(跟doom9上的截圖一樣)中的3545~3558這幾幀比較
前幾幀MVTools表現比較好
後面SVP表現比較好
但我覺得相同參數應該要一樣才是

A:
以前都沒用過SVP補真人影片,一直無法接受插補的真人畫面orz
調了一下參數,不知道適不適用在其他影片上,
這是針對[MV] GIRL'S DAY_FEMALE PRESIDENT的特調參數
主要參數設定是大幅度降低插補強度
https://goo.gl/iFb1VR

K:
之前的經驗是動畫偽影比較嚴重
所以搞定動畫真人影片就不是問題
不然不同類型還要設不同參數也是麻煩
FM和DR也是一套設定而已

A:
這幾天其餘測試結果
CPU Block 23 The Asterisk War NCOP1
CPU Block 23 Charlotte 2015 - NCOP01
CPU Block 23 Accel World Creditless ED2
        在algo23 CPU渲染下無法分辨Block開啟/關閉差異。
CPU Block 13 The Asterisk War NCOP1
        在algo13 CPU渲染下Block開啟/關閉造成的差異有限,
        關閉似乎會多一些偽影(00:35.602),看起來比較像是轉場設定較低造成的。
CPU Block 2 Charlotte 2015 - NCOP01
        在algo2 CPU渲染下無法分辨Block開啟/關閉差異。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
嗯,看不出差別

A:
Cubic Charlotte 2015 - NCOP01.py - 144.png

        意外發現cubic開啟,偽影會比較模糊

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
不過這邊差異算可忽略吧

A:
CPU Linear ニセコイ (Creditless ED2)
        似乎在使用CPU渲染時,linear參數是無效的。
CPU Linear Accel World Creditless ED2
CPU GPU Linear Accel World Creditless ED2
GPU Linear Accel World Creditless ED2.mp4_snapshot_00.01_[2017.04.27_23.36.01]
        透過這兩片與之前的截圖比較(時間00:01.885),
        推測啟用CPU渲染時,linear參數是無效的。

K:
是的,"Only works with GPU rendering enabled."

A:
Light ニセコイ(Creditless ED2)
        開啟背景燈無助於改善GPU渲染造成的邊界黑影問題。

K:
可能是先補幀再做背景燈效果吧

A:
refine 1 2  ニセコイ(Creditless ED2)
refine 1 2 [linear off] ニセコイ(Creditless ED2)
        refine次數對於邊界黑影出現次數無關連,僅有濃淡差異,
        refine 2次的黑影濃淡變化較大,確認與linear無關。
pel 2 1 ニセコイ(Creditless ED2)
        pel 1的邊界黑影情況有比pel 2來的改善一些,
        其餘偽影則有勝有負,pel 2大概贏60%,pel 1贏40%。
pel 2 1 The Asterisk War[NCOP1]
        偽影有勝有負,但pel 1贏60%,pel 2贏40%。
        看來需要多加測試。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
不逐幀看不出差別

A:
GIRL'S DAY
        開啟linear會把閃光燈效果強化或抑制。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
我偏好開啟
不過一般看片時感覺不太出來就是

A:
想請問avs有什麼方法可以擴張四周邊界,並且擴張區域是模糊的嗎?
類似SVP開啟背景燈,
想透過影片先透過此種方式處理後再交由SVP處理,
輸出時再裁切畫面。
測試是否可以抑制邊界黑影的問題。

K:
這是個好想法!
MSuper的參數(hpad=16, vpad=16)正是將四周各填充16像素
(可以只寫MSuper()然而用staxrip觀察出來的圖長怎樣)
SVP可以試試下面的效果

#填充的像素應該要和overlap一樣才能使區塊落在原本的位置
PointSize(寬+48, 高+48, -24, -24, 寬+48, 高+48)
super=SVSuper("")
vectors=SVAnalyse("{block:{w:32,h:32,overlap:2}}")
SVSmoothFps(super, vectors, "")
Crop(24, 24, -24, -24)

不過經過SVSuper()的階層化後
coarse的區塊位置就不一樣了,refine也是
效果跟MVTools可能還是有差

A:
至於MVTools移植到SVP失敗,應該是不是至於吧?
看過pel 1和2的差異,畫面差異不小(逐幀情況下),說好的只差半精度呢?
原本還以為兩者應該差不多...

K:
我覺得pel 1和2差不多耶
另外半精度只在finest層才做喔
半精度其實只是把finest放大1倍
再將搜尋出來的MV長度除以2

----------------------------------------------------------------------------------------
2017.05.04

A:
這幾天新的測試結果,
PointResize 28 24px[overlap2] ニセコイ(Creditless ED2)


        採用土炮方式填充邊緣所增加的較明顯的偽影,有上圖兩種,
        雖然可以抑制黑邊偽影,但卻多了這類型的偽影,
        黑邊偽影是出現機率低但很明顯,
        而新的偽影而是出現機率高但相對來說較為不明顯。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
看起來像原本的黑邊偽影換成了邊緣填充
終究還是偽影
看來這方法並不能解決問題
正確應該是參考後面影格補出缺少的部份

A:
PointResize 28 32px[overlap2] ニセコイ(Creditless ED2)
        block:{w:32,h:32,overlap:2} 24px
        其實看起來差不多,估計黑邊偽影的尺寸大概40px(?),
        不過這其實非常不精確,黑邊偽影可能與畫面移動速度丶SVP參數相關,
        設為當bolck為24px時,填充24px的確是不夠的,
        畢竟經過Super縮放後就變12px 6px 3px,
        除非能夠算出來最大移動距離,然後依此距離來設計填充大小,
        不過這該怎麼計算? main range + 階層數*coarse range嗎?
        以這部測試影片及參數來說,我個人認為設24px是不太夠的,
        而32px效果大於28px,以改善程度來說
        24px 改善50%黑邊偽影問題,28px改善75%,32px改善85%,
        (未經科學測試,個人觀感評分)
        但填充過多是否會會有更嚴重負面影響?
        不確定,未測試,但我想應該多少是有的吧。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
MV最大值應該是

finest只會有一層
例如1920x1080半精度會是
0 3840x2160(拆成四個1920x1080)
1 960x540
2 480x270
3 240x134
...

distance代表是半徑,除以pel就好了
但應該不會找到那麼遠去

A:
補充日期:2017.07.28
補充內容
上述式子中的levels代表的是第levels層,而override.js內的analyse.main.levels則是代表分析levels層。
analyse.main.levels=3時,會分析levels 0丶1丶2,而不會分析levels 3,兩者意思不同。

另外,
式子中的pel代表的是實際精度,而override.js內的levels.pel則是選項,而非實際精度。
levels.pel = 1,實際精度為 1px。
levels.pel = 2,實際精度為 0.5px。
levels.pel = 4,實際精度為 0.25px。須多加注意。

A:
PointResize 32 36px[overlap1] ニセコイ(Creditless ED2)
PointResize 36 40px[overlap1] ニセコイ (Creditless ED2)
        block:{w:32,h:32,overlap:1} 28px
        32px和36px相比,約進步10~20%,
        36px和40px相比,進步大概5~10%,
        這部分覺得沒必要填充到40px,32px~36px會是一個較佳的甜蜜點。
PointResize 32 36px[overlap0] ニセコイ(Creditless ED2)
PointResize 36 40px[overlap0] ニセコイ(Creditless ED2)

        block:{w:32,h:32,overlap:0} 32px
        32px和36px相比,約進步15%,
        36px和40px相比,進步大概10%,
        甜蜜點大約是36px~40px,
        另外發現,似乎填充的像素越多,與運動方向垂直的線條偽影會改善一些,
        看起來有拉直的效果,曲線則不確定,未測試。
        或許這是MVTools部分偽影比SVP好的原因?

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
兩邊行為不一樣很難比較
不過我想還是比較兩邊的原始碼詳細看看邊緣是怎麼處理的好了
有可能SVP和我預想的不一樣
MSuper好像一開始就會做填充
SVP改過來可能只是換了一個做法而不是拿掉

A:
Resize28px[VS]  (Creditless ED2)


        VapourSynth Resize設為負值不是重複邊界,而是鏡像,
        由於此種特性,與影像運動方向平行的線條偽影將會比較少,
        但垂直偽影卻會增加不少,而且從黑邊偽影變成黑線偽影,
        感覺有劣化的情況。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
的確看起來沒好多少

A:
VapourSynth的部分有想到一種辦法,
借MVTools裡的MSuper來使用,


K:
mv.Super的pel應該也要設成1

A:
這幾天想測試處理器核心/執行續與SVP腳本內的threads關聯,
透過關核心丶改變頻率測試,
預計測試
4C8T 5Ghz    當前最高頻率
4C8T 4Ghz    桌上型I7
4C4T 3.5Ghz  桌上型I5
2C4T 3.8Ghz  桌上型I3
4C8T 2.8Ghz  筆記型I7-HQ(不過筆電跑這不會過熱降頻嗎?)
4C4T 2.8Ghz  筆記型I5-HQ
2C4T 2.6Ghz  筆記型I7-U丶I5-U丶I3-U/H
測試腳本用這組可以嗎?


K:
在我的筆電(i7-3630QM+GTX660M)上只能跑最低的設定
而且風扇狂轉orz
不過雖然不如桌機的滑順
至少最低的設定沒什麼偽影就是XD

A:
補充日期:2017.07.25
補充內容
目前研究所得參數大多為降低搜索半徑,剛好SVP較低的設定也是降搜索半徑,
因此在SVP 4 Free文章中有提到設定拉桿拉至左方的效果可能更佳。

K:
btw,
gpu:1的話,scale.up會變成0
"Note that with "gpu:1" scaling up mode is always set to 0
cause subpixel planes are not actually used for frame rendering."

發現我現在用的參數在快速橫移還是不行orz
冰菓11話最後聊天室那邊完全補不起來
雖然之前搭配trymany用-4在GuP劇場版就ok了
這邊要把coarse distance提高到-6才行
但-6在DxD一期OP最後的棋盤就會有明顯偽影(可能是搭配finest用UMH的關係

還在想怎麼解決...

----------------------------------------------------------------------------------------
2017.05.06

A:
另外pel設成2丶4,並沒有將圖片放大,(錯誤觀念)
而是變成1976*4544 = (1920+28+28)*[(1080+28+28)*4]

pel設成4則是變成 (1920+28+28)*[(1080+28+28)*16]
並沒有長寬乘2丶4倍

K:
有放大喔

原圖
o o ...
o o ...
... ...

放大兩倍(o是原來的像素,h,v,d是內插出來的)
o h o h ...
v d v d ...
o h o h ...
v d v d ...
... ... ...

SVSuper()會將它排列成
o o ...
o o ...
... ...
h h ...
h h ...
... ...
v v ...
v v ...
... ...
d d ...
d d ...
... ...
(推測順序)

而如果pel=1且full=false
SVSuper()只會有coarse層
finest直接拿原圖
所以SVAnalyse必須設src=input

A:
方便請問一下現在用的參數是?

K:(2017.07.25擷取),非最新版。
override = function()
{
// It's recommended to add needed options via Application settings -> 
// Additional options -> All settings -> User defines options
 
/***** SVSuper options *****/

//levels.pel    = 2;
//levels.gpu    = 0;

levels.pel    = 1;

//levels.scale.up   = 2;
//levels.scale.down   = 4;
//levels.full    = true;

levels.full    = false;

/***** SVAnalyse options *****/

//analyse.vectors   = 3;
//analyse.block.w   = 16;
//analyse.block.h   = 16;
//analyse.block.overlap   = 2;

analyse.block    = {w:32,h:32};

//analyse.main.levels   = 0;
//analyse.main.search.type  = 4;
//analyse.main.search.distance  = -4;
//analyse.main.search.sort  = true;
//analyse.main.search.satd  = false;
//analyse.main.search.coarse.type = 4;
//analyse.main.search.coarse.distance = 0;
//analyse.main.search.coarse.satd = true;
//analyse.main.search.coarse.trymany = false;
//analyse.main.search.coarse.width = 1050;
//analyse.main.search.coarse.bad.sad = 1000;
//analyse.main.search.coarse.bad.range = -24;

var levelsmax=Math.floor(Math.log((Math.floor(((mediaInfo.main.reswidth<mediaInfo.main.resheight?mediaInfo.main.reswidth:mediaInfo.main.resheight)-8)/24)*24+8)/32)/Math.LN2)+1;
if(levelsmax>=3)
 analyse.main.levels  = levelsmax*3>>2;
analyse.main.search.type  = 3;
analyse.main.search.distance  = -5;
analyse.main.search.coarse  = {distance:-4,bad:{range:0},trymany:true};

//analyse.main.penalty.lambda  = 10.0;
//analyse.main.penalty.plevel  = 1.5;
//analyse.main.penalty.lsad  = 8000;
//analyse.main.penalty.pnew  = 50;
//analyse.main.penalty.pglobal  = 50;
//analyse.main.penalty.pzero  = 100;
//analyse.main.penalty.pnbour  = 50;
//analyse.main.penalty.prev  = 0;

analyse.main.penalty.lambda  = 11.5;
analyse.main.penalty.plevel  = 1.6;
analyse.main.penalty.pnbour  = 65;

//analyse.refine[0].thsad  = 200;
//analyse.refine[0].search.type  = 4;
//analyse.refine[0].search.distance = 2;
//analyse.refine[0].search.satd  = false;
//analyse.refine[0].penalty.lambda = 10.0;
//analyse.refine[0].penalty.lsad = 8000;
//analyse.refine[0].penalty.pnew = 50;

analyse.refine    = [{search:{distance:4}}];

/***** SVSmoothFps options *****/

//smooth.rate.num   = 2;
//smooth.rate.den   = 1;
//smooth.algo    = 13;
//smooth.block    = false;
//smooth.cubic    = 0;
//smooth.linear    = true;

smooth.algo    = 23;

//smooth.mask.cover   = 100;
//smooth.mask.area   = 0;
//smooth.mask.area_sharp  = 1.0;

smooth.mask    = {cover:80};

//smooth.scene.mode   = 3;
//smooth.scene.force13   = true;
//smooth.scene.luma   = 1.5;
//smooth.scene.blend   = false;
//smooth.scene.limits.m1  = 1600;
//smooth.scene.limits.m2  = 2800;
//smooth.scene.limits.scene  = 4000;
//smooth.scene.limits.zero  = 200;
//smooth.scene.limits.blocks  = 20;

smooth.scene    = {mode:0,limits:{scene:3000,blocks:40}};

//smooth.light.aspect   = 0.0;
//smooth.light.sar   = 1.0;
//smooth.light.border   = 12;
//smooth.light.lights   = 16;
//smooth.light.length   = 100;
//smooth.light.cell   = 1.0;

//smooth.gpuid    = 0;
}

K:
levelsmax那串的意思是,在是不同尺寸的影片會有不同levels設定
例如DVD只有480P
在block=24x24下,SVAnalyse()只能分析總共4層

先算出來避免levels=4不能播320x240的影片
另外在小解析度用小一點的levels(720P就設3)來減少偽影

A:
補充日期:2017.07.28
補充內容
由於目前只有測試1080P影片為主,低於此解析度的參數不是很確定效果,但依照經驗推論,低解度影片應該依等比例縮小網格大小才會與高解析度影片有相同效果,只減小搜索階層數而無縮小網格大小可能會影響其效果?

K:
補充日期:2017.07.28
補充內容
依比例縮小網格大小也可能是個方法
只是因為階層數會受解析度影響而網格大小不會
且32效果一直都很好所以我只調整階層數
其實減少階層數的效果反而會快速pan時抖動嚴重
我也開始在想是不是>=480p都設levels=4就好

K:
在對比60%~100%就變成4→因為UMH的5跟4效果一樣
比distance=-4的75%~100%來得大
提高一些些滑順的可能(或是偽影)
不過我沒詳細比對,只是從演算法去推測應該有這樣的效果

A:
這段到現在還是看不懂...

K:
補充日期:2017.07.28
補充內容
因為不像EXH的distance設+5和+4會不一樣
UMH和HEX的特性是有些奇數和偶數是一樣的效果
然後SVP是先根據對比決定distance是多少再去搜尋
因此可以想像UMH實際上是

同樣是將範圍限制在4以下
但對比60%時一個用+2搜尋另一個會用+4搜尋

不過想到之前實驗結果對比通常都很低
說不定可以設高點,反正實際上不會跑到XD


A:
這幾天的測試




         經過測試後發現SVPflow無法發揮處理器全部效能,極限大概是85~90%,
         而且會有特定核心使用率特別高,
         超執行續效率約為 +19~27%,
         5Ghz與2.6Ghz的每單位性能相比約有7%損失。

 K:
SVP3的threads預設是
gpu=1時
%NUMBER_OF_PROCESSORS%*1.823再四捨五入

gpu=0時
%NUMBER_OF_PROCESSORS%+1

 A:
測試軟體採用的腳本
High-profile

Main-profile

K:
我覺得search.type=3的話
distance不宜設太高
因為UMH找完十字和六邊形後的位置
會再用同樣的distance做HEX
這樣可能容易有偽影
我是設成-5 distance跟設-4一樣
但提高adaptive range判斷高對比的範圍

 A:
測試影片是直接提取 PSYCHO-PASS II 藍光內的OP,
無壓縮,所以檔案會有點大,抱歉。
這片是我目前看過SVP平均消耗最高的1080p手繪動畫(非瞬間最高)
第二是學戰OP,瞬間最高則沒仔細比過。

K:
這片補幀效果不是很明顯XD
另外LWLibavVideoSource可以開硬解的樣子 可以省一些CPU

A:
補充日期:2017.07.25
補充內容
當時使用這片段測試是因為這段是當時測得消耗平均效能最大的影片,
如果參數在這片段中可以穩定使用,那在大多1080P動畫片段應該都沒問題,也因此故意不開啟硬解,
補幀效果不明顯...這片段本來就不是用來測流暢度的,是比較不同處理器運行SVP時的效能差異

----------------------------------------------------------------------------------------
2017.05.07

A:
Potplayer內建的Avisynth與Vapoursynth均有CPU使用率過低的問題,
若SVP透過內建Avisynth輸出,Potplayer會謊報實際FPS,
影片明顯不流暢,但FPS卻維持59.6fps。

透過AVSMeter2.5.4測試,
利用https://forum.doom9.org/showthread.php?t=168339,
讓Avisynth能夠執行Vapoursynth腳本(HighProfile),
結果這種轉換的效率比原生Avisynth腳本效率還高 4.5%左右。

K:
這麼神奇!?
不曉得是VapourSynth本身還是SVPflow的vs版
哪一個效能比較好的關係XD

A:
不過我不會將這種轉換移植到SVP裡XD

K:
要從SVP 4\script\generate.js下手

A:
補充日期:2017.07.28
補充內容
看了一下,似乎不是不行,但ffdshow_source()怎麼透過.avs交給.vpy執行...?

----------------------------------------------------------------------------------------
2017.05.09

K:
但MPC-BE的EVR-CP效能比MPC-HC的來得好
而且還能用DXVA縮放
加上內建的HEVC軟解效能比LAV高一些
有些4K HEVC10bit 60fps的影片跑得動了
(其實EVR效能最好,但沒字幕)
暫時換用MPC-BE

A:
我這邊EVR依然可以正確顯示字幕
外掛字幕渲染器 -正常工作

內建字幕也可以

.ass和.srt都確認可以,可能還要檢查看看喔。

K:
EVR-CP可以顯示字幕
不能的是EVR
但EVR效能好很多

A:
試試xy-VSFilter

https://forum.doom9.org/showthread.php?t=168282
不過,用這個之後,
MPC內建硬解也失效就是了。

K:
感謝~
習慣內建的後都忘了有字幕濾鏡可以用了
只要LAV的DXVA-CB能用就沒問題

K:
另外用Process Explorer看了下GPU使用率
HD4600用
algo=21比23節省約10%
cubic=0也能節省約10%
linear=false省比較少
如果之後GPU跑不動4K補幀大概要犧牲這邊

K:
我用MPC-BE掛SVP好像都不會啟用硬解

A:
我這邊也是,有掛ffdshow或BFRC就不會啟用。
ffdshow 開啟 或 BFRC開啟
LAV 可以硬解 HEVC Main10 23.976fps
         無法硬解 HEVC Main10 59.94fps
MPC 無法硬解 HEVC Main10 23.976fps
         無法硬解 HEVC Main10 59.94fps

ffdshow 關閉
LAV 可以硬解 HEVC Main10 23.976fps
         無法硬解 HEVC Main10 59.94fps
MPC 可以硬解 HEVC Main10 23.976fps
          可以硬解 HEVC Main10 59.94fps

A:
補充日期:2017.07.28
補充內容
根據當時測試結果,發現LAV無法硬解hevc 10bit 59.94fps的影片,
隔幾天後的LAV Filters Nightly Builds更新才有支援,目前新版LAV均已支援。
LAV Filters 0.69.0.71版本後
已經支援HEVC 10bit 59.60fps影片硬解

NVIDIA CUVID 和 DXVA2(copy-back)模式下,
可以同時開啟硬解及SVP。

----------------------------------------------------------------------------------------
2017.05.10

A:
另外這幾天看了SAO第一季,
OP01片段中
coarse.distance -5不太夠,
-5 + trymany 也不太夠,
-6丶-6 + trymany也都不甚滿意,
最後加到+3才好些。

K:
這部剛好沒看

A:
在前幾封信中,
您有提到對比百分比與搜索半徑的關係,
想再詢問,
對比百分比是怎麼計算呢?
只參考luma?還是也會考慮chroma呢?

K:
剛剛看原始碼想確認一下計算方法
結果發現refine.search.distance可能不支援adaptive range!!
我一直以來都搞錯了(爆
refine的distance是和1比較取最大值
所以之前設的-6,-4,-2其實都等於1
一直以來覺得有效果都是我的心理作用orz
原本還想說和finest一樣設0來跳過直接做最小區塊
難怪都沒效果...

A:
那...refine最小的distance就是1?
即使設0也一樣?

K:


A:
另一個問題是,
如果上述成立,那會refine幾次呢? 32px > 16px > 8px > 4px > 2px > 1px ?

K:
原本是想說在32px下
analyse.main.search.distance = 0; // 32px不搜尋
analyse.refine[0] = {thsad:0,search:{distance:0}}; // 16px不搜尋
analyse.refine[1] = {thsad:0,search:{distance:1}}; // 8px

這樣跳過32px,16px直接搜尋8px甚至4px
但看來refine做不到跳過16px

A:
不,
我的意思是,
如果我不設定refine的情況下,
會做幾次refine呢?

做到無法被2整除?

K:
analyse.refine = [];
等於
Decrease grid step: Disable

這樣就是不做任何refine

K:
亮度對比基本上是
先計算整個區塊的平均亮度
再計算與平均亮度的絕對誤差和(SAD)
除以區塊大小
彩度對比也是同樣算法然後與亮度對比加總
超過255視為255
再對distance做調整


----------------------------------------------------------------------------------------
2017.05.12

A:
感謝您的說明,
不過有個地方不甚了解,如果方便的話,可以麻煩加以說明嗎?感謝

if(contrast<2) distance=0;
如果對比小於2,則距離為0;
else distance = 1 + |distance|*min(255, contrast * 255 / 150) / 256;
否則 距離等於1 + (-1)*(距離)*(255 或 對比*255/150 取較小值)/256;

這樣應該沒錯吧!
有疑問的地方是為何對比要*255/150呢?

K:
我也不理解將對比乘以1.7的用意
原本以為會是

1 + |距離| * 對比 / 256

這樣

可能是SVP實驗發現這樣效果比較好吧?

在翻看原始碼時注意到
雖然只有對比<2時距離才會變為0
但不同search.type
在距離為0會有些不一樣的行為

EXH不會做搜尋,和距離為1不同
HEX和UMH還是會搜尋,跟距離為1結果一樣

不過對比<2機會應該很低

這差異應該可以忽略...吧


A:
補充日期:2017.07.30
補充內容
此處與本Blog當前設置有些許差異,因為在很久之前的測試結果為EXH優於其他,所以推薦EXH,
最近在低對比區域的流暢度有瓶頸,也許可以藉由UMH的特性改善? 待測試。

A:
如下的圖片,(請見2017.05.14的圖片)
我覺得對比<2在手繪動畫上應該不難見到...

真人影集應該就很難遇到(導演應該不會拍出一堆過曝丶欠曝的畫面吧...)

K:
應該是在finest level
或是refine時
區塊比較小所以比較有機會對比<2

在coarse level應該比較不會

A:
如此一來搜索半徑就與Gamma無關了對吧?
搜索半徑與對比成正比,若不添加Gamma校正,
那暗部搜索半徑會偏小,亮部搜索半徑會偏大,
不過這好像和偽影無直接關聯,好像多想了XD

K:
應該無關吧
我猜是以
高對比->比較可能是前景物體->會動比較快
低對比->背景->比較不會動
這種想法設計出這演算法

不過在鏡頭平移或是背景複雜前景反而單調的情況下就不成立了

A:
根據前幾天您對pel與distance做了個小測試,
pel1 2 [refine 0]Accel World Creditless ED2
        (pel 2 distance 8 / pel 1 distance 4)

        根據本次測試,main distance的確與pel相關,
        且關係式為 搜索半徑 = main search distance / pel(半精度為2)
        加上前幾次的測試 " main search distance在-8時,pel 1的表現略比pel 2佳 ",
        推測 搜索半徑 = -4 (-8/2)是不太夠的,應適度加大,但須加到多大則有待測試,

        而在搜索半徑相同時,pel 2表現的確是比pel 1略佳。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
我main.search設成type:3,distance:-5
感覺有比type:4,distance:-4來得滑順

(在pel 1的情況下)

----------------------------------------------------------------------------------------
2017.05.14

A:
所以contrast超過150時,搜索半徑就會是最大值了對吧。
當contrast ≧2時,
搜索半徑最小值為 1 + |distance|*(2*1.7)/256
最大值則為 1 + |distance|*(255)/256
這樣的話,distance為負值時,搜索半徑為 1 ~ |distance|+1,應該沒錯吧?

K:
抱歉之前沒說清楚
因為是除以256而不是255
一般程式語言的整數除法都是無條件捨去
|distance|*(255)/256為|distance|-1
再加上1後最大值即|distance|

所以distance = -5時,搜索半徑為+1 ~ +5
平均半徑為3.8046875

A:
也就是說,distance = -5時,搜索半徑為 +1 ~ +6,平均半徑約為 +1.93
-5時約為38.6%,-7約為35.6%,-9約為34.1%,-10約為33.3%,-15約為31.7%

(透過官方說明自適應搜索半徑約為其1/3及Average distance = -10求出)

K:
這邊看不太懂

A:
平均半徑3.8046875這應該是錯誤的,
因為 對比0~255 不是均勻分布的,
對比255要在block內一半完全白一半完全黑才會達到,(不過動畫好像也滿常看到的?)
而且依照SVP官網說明,半徑為負值時,其平均半徑為1/3,因此均勻分布不合理。

上圖中每個小框框的寬高均為32px,(人工用小畫家畫的,若有沒畫好的地方還請見諒)
除了最下面一排高度不足32px,

可以發現不少框框內的對比極低,幾乎為純色

因此我用常態分布來推估分布,
1/(σ√2π) * e^{[-(x-μ)^2] / 2σ^2}
令分布中心為0,μ=0    --->應該要考慮影片Dither強度,但這裡沒考慮
而σ則透過SVP官網說明,半徑為負值時,其平均半徑為1/3,半徑採用預設值-10計算,
算出來的σ為54.811
試算表如下
https://goo.gl/YLQNDC

因此才會說
-5時自適應半徑約為38.5%
-7時自適應半徑約為35.6%
-9時自適應半徑約為34.1%
-10時自適應半徑約為33.3%
-15時自適應半徑約為31.7%

我知道這種推算方式有很大瑕疵,
分布應該要用更嚴謹的方式來計算,
不過這要怎麼寫腳本計算,我不會...冏

而且真人影片和手繪動畫的分布應該也有差異。

A:
補充日期:2017.07.30
補充內容
此處僅為當時胡亂計算的結果,與後續實際測試差異很大。

K:
原來如此

用均勻分佈的確不合一般情況

可是μ=0的話
鐘形中心會落在對比0的位置

會這麼高機率對比趨於0嗎?

A:
這樣一來,
若平均半徑達到+3,distance要設到-9才夠,
依照我以前的測試,
日本手繪動畫distance最佳選擇應該是+4丶+3丶-5丶-6這幾個
+4在低對比背景區域效果最佳,-5偽影最少,
最佳搜索半徑應該是 0 ~ +6,平均半徑 3.0 ~ 3.5

K:
+4是因為不受對比影響所以能找到
-5是因為適時減短半徑所以偽影少
我猜是這樣

A:
所以,我希望在分析前手動加大對比,
使平均搜索半徑能夠增加一些,
增加一些低對比區域的搜索半徑。

A:
如果在分析階段前加大對比,
提高低對比時的搜索半徑,效果不知道會不會比較好?
distance:-5,對比*1.3,平均半徑 +2.31

K:
藍線是原本的
橘線是先把對比*1.3嗎?

A:
恩,沒錯
不過對比越高的區域,增加量小一點可能會好一些,
直接*1.3,似乎也不太妥當,
反而高對比區域提升多不少,
目標還是在於提高低對比區域對比。

K:
可能可以類似jm_fps用RemoveGrain那樣

先用其他濾鏡加大對比再給SVSuper和SVAnalyse

A:
這幾天測試很少,抱歉
GTX960 R7-260 Accel World Creditless ED2
        使用不同顯示卡渲染(GTX960 / R7-260)
        雖然分別壓出來的大小略有不同,(85.4MB/85.1MB)
        但如同預期,肉眼上無法辨識差異。

A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
感謝測試
這樣至少不同顯卡上
SVP效果不會打折扣

----------------------------------------------------------------------------------------
2017.05.17

K:(舊版腳本)
先用avs來個模擬好了
(不過這只能模擬block.overlap=0)
#裁切成32x32的倍數
Crop(0, 0, -(width % 32), -(height % 32))
source = last
#只計算亮度對比
ConvertToY8()
luma = last
#用BilinearResize模擬各區塊的平均亮度
BilinearResize(width / 32, height / 32).PointResize(width, height)
#相減得到差值(差值範圍-255~255會被調整成0~255)
Subtract(luma)
#計算絕對值(0~127,128~255 -> 255~0,0~255)
Overlay(Levels(0, 1, 127, 255, 0), Levels(128, 1, 255, 0, 255), mode = "add")
#用BilinearResize模擬平均絕對值得到各區塊的對比
BilinearResize(width / 32, height / 32)
#顯示直方圖
StackVertical( \
source.BilinearResize(480, 256).Histogram("levels"), \
PointResize(480, 256).ConvertToYV12().Histogram("levels"))
如果這模擬符合真實情況的話
對比似乎比較驅向0

A:
結果分布不是鐘形的,比想像的還嚴峻,
亮度對比大多分布在 0~50左右(手繪動畫),
幾乎看不到對比超過128的。

K:
應該是有

只是太少了直方圖看不出來XD
用BilinearResize模擬其實不好,但我用masktools一直當掉orz

A:
可以請教請問Resize模擬哪裡不好嗎?

K:
BilinearResize的取樣應該只有4個點
這跟取區塊每個點平均差很大
我還有試過做5次BilinearResize(width / 2, height / 2)
但效果也不對

研究了下masktools終於有比較好的做法,請看下面

A:
另外,
如果原始影片1920*1080,
設定區塊大小32px,那只會計算1920*1056對吧。
那色度平面是會先拉到1920*1056嗎?
還是直接在960*528開始計算呢?
還有,先前您說過總對比 = 亮度對比 + 色度對比
請問是
1. Y平面對比 + U平面對比 + V平面對比
2. Y平面對比 + (U丶V平面對比平均)

哪一種呢?

K:舊版腳本
是1.

Subtact()和Levels()好像會考慮到tv/pc的問題
所以之前的腳本不是很正確

請參考下面新的做法

#需要masktools2
LoadPlugin("%app:masktools2%")

#利用卷積計算2x2的平均
#0 0 0
#0 1 1
#0 1 1
#再用縮小1/4留下偶數位置的值
function AverageBy2(clip c)
{
uv = c.IsY8 ? 1 : 3
c.mt_convolution( "0 1 1", "0 1 1", \
u = uv, v = uv ).PointResize( c.width / 2, c.height / 2 )
}

#一樣先裁切

Crop(0, 0, -(width % 32), -(height % 32))

#彩度平面的作法跟亮度一樣
#但SVP是用1/4區塊去算
#這邊只能用一樣大區塊
#所以轉成YUV4:4:4
ConvertToYV24()
src = last

#縮小1/2 5次=32x32的平均
AverageBy2()
AverageBy2()
AverageBy2()
AverageBy2()
AverageBy2()
PointResize(width * 32, height * 32)

#計算絕對差值,這邊應該不會像Subtract()有tv/pc的問題
mt_lutxy(src, expr = "x y - abs", u = 3, v = 3)

#取32x32的平均
#這邊可以用32x32的卷積
#然後PointResize(width / 24, height / 24)
#來模擬overlap

#但好像會很慢而且差距不明顯
#所以先不考慮overlap
AverageBy2()
AverageBy2()
AverageBy2()
AverageBy2()
AverageBy2()

#還想不到方法把各平面的對比相加,待改善
StackVertical( \
src.BilinearResize(480, 256).ConvertToYV12().Histogram("levels"), \
PointResize(480, 256).ConvertToYV12().Histogram("levels"))


不過看起來對比還是比較驅向0就是
另外在coarse level
SVP會對亮度的每個區塊做調整

以8x8為例

將原本和位移後的區塊相加/2
得到的區塊才去算對比
這個我還不太清楚SVP的用意
而且avs不好模擬

可能要寫程式才能比較了

----------------------------------------------------------------------------------------
2017.05.18

K:
想到方法將各平面對比相加了
很簡單

mt_lutxyz(ConvertToY8(), UtoY8(), VtoY8(), "x y + z +")

之後也可以再乘以1.7

mt_lut("x 255 * 150 /")


下面是我現在的腳本舊版腳本

LoadPlugin("%app:masktools2%")

function AverageBy2(clip c)
{
c.mt_convolution("0 1 1", "0 1 1", u = 3, v = 3)
PointResize(width / 2, height / 2)
}

function AverageBy32(clip c)
{
c.AverageBy2()
AverageBy2()
AverageBy2()
AverageBy2()
AverageBy2()
}

function ShowContrast(clip c)
{
c.Crop(0, 0, -(c.width % 32), -(c.height % 32))
ConvertToYV24(chromaresample = "point")
src = last

AverageBy32()
PointResize(width * 32, height * 32)
mt_lutxy(src, "x y - abs", u = 3, v = 3)

AverageBy32()

mt_lutxyz(ConvertToY8(), UtoY8(), VtoY8(), "x y + z +")

mt_lut("x 255 * 150 /")



#增加用ColorYUV()來顯示最大/最小值

PointResize(480, 264)

ConvertToYV12()

StackHorizontal( \

src.ConvertToYV12().BicubicResize(width, height, 0, 0.5).Histogram("levels"), \

Histogram("levels"), ColorYUV(analyze=true))

}



#跟super.scale.down=4一樣用BicubicResize(1,0)縮小
stack = ShowContrast()
BicubicResize((width / 4) * 2, (height / 4) * 2, 1, 0)
stack = StackVertical(stack, ShowContrast())
BicubicResize((width / 4) * 2, (height / 4) * 2, 1, 0)
stack = StackVertical(stack, ShowContrast())
BicubicResize((width / 4) * 2, (height / 4) * 2, 1, 0)
StackVertical(stack, ShowContrast())

意外的是即使加上彩度乘以1.7後依然很少超過128
而且coarse level對比最大值並沒有比較高
我想模擬應該是有不足的地方

另外有字幕的地方明顯對比較高
這也許是這裡容易出現偽影的原因



----------------------------------------------------------------------------------------
2017.05.19

K:
因為SVP用的是YV12
所以UV是用1/4區塊大小去計算的
 (也就是AverageBy16就好)
而且是直接與Y相加不用先把UV平均

A:
不對吧?
UV依然是要AverageBy32吧
前一封說的YV12做AverageBy2有問題,
原因應該是尺寸要2的倍數(與UV層有關),
Y8 YV24就沒此限制。
把YV12拉到YV24,
UV層被放大2*2倍,
最後對比相加時,
要把UV層的值/4才會是正確的吧?

K:
YV24的話是通通AverageBy32()
雖然UV被放大2*2但也和Y一樣是算32x32的平均
不需要再/4

YV12的話就分別
ConvertToY8().AverageBy32()
UToY8().AverageBy16()
VToY8().AverageBy16()
再加總起來

我改成了遞迴,這樣就可以指定區塊大小了

function AverageBy2(clip c, int blkSize)
{
blkSize > 1 ? \
c.mt_convolution("0 1 1", "0 1 1").PointResize(c.width / 2, \
c.height / 2).AverageBy2(blkSize / 2) : c
}

function GetContrast(clip c, int blkSize)
{
c.Crop(0, 0, -(c.width % blkSize), -(c.height % blkSize))
mt_lutxy(AverageBy2(blkSize).PointResize(width, height), "x y - abs")
AverageBy2(blkSize)
}

function ShowContrast(clip c, int blkSize)
{
mt_lutxyz( \
c.ConvertToY8().GetContrast(blkSize), \
c.UToY8().GetContrast(blkSize / 2), \
c.VToY8().GetContrast(blkSize / 2), "x y + z +")
mt_lut("x 255 * 150 /")
PointResize(width * 2, height * 2) #避免寬高是奇數轉回YV12會補黑邊
ConvertToYV12()
c.BilinearResize(426, 240).StackHorizontal( \
PointResize(426, 240).ColorYUV(analyze=true), \
Histogram("levels").Crop(width, 0, 0, 240)) #Historam不先放大,尺度比較好看
}

stack = ShowContrast(32)
BicubicResize((width / 4) * 2, (height / 4) * 2, 1, 0)
stack = StackVertical(stack, ShowContrast(32))
BicubicResize((width / 4) * 2, (height / 4) * 2, 1, 0)
stack = StackVertical(stack, ShowContrast(32))
BicubicResize((width / 4) * 2, (height / 4) * 2, 1, 0)
StackVertical(stack, ShowContrast(32))


這樣和轉YV24計算的數值有點差異
應該是這樣直接用YV12比較準
另外overlap我想到利用PointResize()的特性

假設24px寬的資料
0         1         2
012345678901234567890123
目標是block:{w:8,overlap:2}
讓它每8個點重複2個點變成
0           1             2
012345676789012323456789890123
      ︿︿      ︿︿      ︿︿

首先
PointResize(24 + 4, 1)
應該如下增加24/6=4個點
 0          1           2
0012345667890122345678890123
︿      ︿      ︿      ︿
然後再PointResize(28 + 4, 1)變成
  0           1             2
00012345666789012223456788890123
︿       ︿       ︿       ︿

再將原本的資料反過來重覆上面的動作
   2         1         0
321098765432109876543210
變成
     2             1           0
33321098777654321110987655543210
︿︿      ︿︿      ︿︿      ︿︿
再反轉回來
0           1             2
0123455567890111234567778901233

用mt_lutspa()產生
11000000110000001100000011000000
這樣的遮罩(0代表取第一個結果,1代表取第二個)

將兩個結果用mt_merge()透過遮罩合成
0 0           1             2
01012345676789012323456789890123
︿︿      ︿︿      ︿︿      ︿︿
再砍掉最左邊兩個px
就是overlap的樣子了

但這看起來就非常慢XD
還要再想想有無更簡單的方法(python還沒開始看orz

----------------------------------------------------------------------------------------
2017.05.21

A:
感謝您上一封的解說,
一時轉不過來,真是抱歉

在您的腳本上,
我添加了幾行(GetContrast丶AverageBy2沒變更,就省略了)

global search_distance = -10

function ShowContrast(clip c, int blkSize)
{
mt_lutxyz( \
c.ConvertToY8().GetContrast(blkSize), \
c.UToY8().GetContrast(blkSize / 2), \
c.VToY8().GetContrast(blkSize / 2), "x y + z +")
mt_lut("x 255 * 150 /")
PointResize(width * 2, height * 2)
ContrastTotal = last

#設定Adaptive distance
mt_lut(y = search_distance , u = 1 ,v = 1)
distance = last

# if(contrast<2) distance=0;
# else distance = 1 + |distance|*min(255, contrast * 255 / 150) / 256;
# x < 2 ? 0 : 1 + x / 256 * y
mt_lutxy(ContrastTotal, distance,"x 2 < 0 1 x + 256 / y * ?", u=1, v=1)

ConvertToYV12()

c.BilinearResize(426, 240).StackHorizontal(\
StackVertical(\
PointResize(512, 240).ColorYUV(analyze=true).Crop(0, 0, 0, 120), \
Tweak(bright = 16.0,cont = 10.0,coring = false).\
Histogram("levels").Crop(width, 0, 0, -184).PointResize(512, 120)))
}

這樣可以直接看平均搜索半徑,
大概長這樣



目前有幾種改變搜索半徑的想法
1. 將TVrange伸張至PCrange,加大對比,
   提高高對比區域搜索半徑,低對比區域則不變。

2. 添加噪點,加大區域差異,
   提高全部搜索半徑,低對比區域效果較明顯。

3. 模糊影像,降低區域對比差異,
   降低全部搜索半徑,尤其是高頻區域。

以上都可以同時採用,
甚至可以針對某一特定level處理,

像是在
level > 2,套用Blur 降低搜索半徑過大產生的偽影,
然後在全部階層都加上一層噪點,提高低對比區域的搜索半徑,
等等...

K:
試了一下Local Contrast Enhancement
http://www.cambridgeincolour.com/tutorials/local-contrast-enhancement.htm
它是透過遮罩加強亮/暗部的細節,效果類似HDR

用這個腳本(需要masktools2)
https://forum.doom9.org/showpost.php?p=1555234&postcount=46

coarse level的對比有提高
但對finest level效果沒有很明顯

----------------------------------------------------------------------------------------
2017.05.29

A:
這幾天測試些參數
AddGrain(a) Girls und Panzer
        此測試為先Super後,除噪再添加重噪點
        super=SVSuper(input, super_params).RemoveGrain(2).AddGrain(var=10.0, uvar=10.0)
        有變化,但是並不全然是正向改變,
        個人感覺並沒有比較好,有略差的感覺。

AddGrain(b) Girls und Panzer
        此測試為先添加重噪點後,再丟給Super處理
        input_m8T  = core.grain.Add(input_m8, var=15.0, uvar=15.0)
        super   = core.svp1.Super(input_m8T,super_params)
        與先Super再添加噪點相比(AddGrain(a) Girls und Panzer),
        感覺表現比較好,但與原始相比依然沒有特別明顯優勢,
        推測高level時,並不需要添加噪點來增加搜索半徑。

YC Girls und Panzer
        此測試是將TV range拉伸到PC range
        super=SVSuper(input, super_params).ColorYUV(levels ="TV->PC")
        表現似乎有比原先略佳,但效果不算很大,
        可能還要搭配其餘參數調整。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

----------------------------------------------------------------------------------------
2017.05.30

K:
測試辛苦了
有先比較過對比的變化嗎?

----------------------------------------------------------------------------------------
2017.06.01

A:
有比較過對比變化。
拉高對比,level越高的階層影響越大,低level的影響較小,
試了一下,
如果只拉高level 0~2的對比,
表現反而比把全部拉高還要好一些,
測試畫面是少戰劇場板,路上經過破爛熊看板片段,
測了幾種提高對比的方式(-5),
與搜索半徑設為+3相比,
效果都不盡理想…
即使拉高對比,低對比背景還是很容易產生blend,
大概是自適應半徑不足吧,+3就不太會發生,
可能還要多嘗試測試一些新組合。

K:
看來低對比背景很難提高adaptive range
可能要同時做adaptive(-5)和fixed range(+3)
然後根據低對比背景佔畫面的多寡決定要用哪一個補幀結果

A:
SVP可以這樣設定嗎?
或是可以設定成range = (range:+2)+(range:-4)這類嗎?

K:
應該不行,只能像下面這樣
smooth_adaptive = ...
smooth_fixed = ...
frame_contrast > threshold ? smooth_adaptive : smooth_fixed

K:
或是試試降低main.search.coarse.width
原本1080p以下只有level 0會是finest level其他是coarse
將這參數設低應該可以讓level 1和其他也是finest
然後coarse用+3看看效果會不會好些

A:
這部分過幾天再測試,感謝

這幾天測試結果如下,廢話有點多,可以直接跳小結

YC2 YC1 L Girls und Panzer
        對Level 0~2及0~1做YC伸張,
        差異不明顯。與distance:+3相比,還是差很多。
        *影片註釋錯誤,寫成Level 0~3 / Level 0~2

YC2 Grain L Girls und Panzer

        superA2=SVSuper(input, super_params2).crop(0,0,0,Int(input.height+ input.height/2+ input.height/4)).ColorYUV(levels ="TV->PC")
        superB2=SVSuper(input, super_params2).crop(0,Int(input.height+ input.height/2+ input.height/4),0,0)
        super2=StackVertical(superA2,superB2).AddGrain(var=10.0, uvar=10.0)
        AddGrain(var=10.0, uvar=10.0)會吃細節,
        細節表現表現比較好,但看板處表現卻下降。
        *影片註釋錯誤,寫成Level 0~3

YC3 Grain(G) L Girls und Panzer
        super2=StackVertical(superA2,superB2).AddGrain(var=10.0, uvar=0.0)
        AddGrain(var=10.0, uvar=0.0)不會吃細節,
        表現有好有壞,但個人感覺並沒好到哪去。
        *影片註釋錯誤,寫成Level 0~3

YC2 Grain(GH) L Girls und Panzer
        super2=StackVertical(superA2,superB2).AddGrain(var=15.0, uvar=0.0)
        加重亮度噪點似乎沒有明顯改善。

YC2 Grain(C) L Girls und Panzer
        super2=StackVertical(superA2,superB2).AddGrain(var=0.0, uvar=10.0)
        AddGrain(var=0.0, uvar=10.0)會吃細節,
        細節表現表現比較好,但看板處表現卻下降。

YC2 Grain(CH) L Girls und Panzer
        super2=StackVertical(superA2,superB2).AddGrain(var=0.0, uvar=15.0)
        AddGrain(var=0.0, uvar=15.0)會吃細節,
        加重色度噪點似乎沒有明顯改善。

Levels3 YC2 L Girls und Panzer
        levels:3 + YC伸張,
        流暢度還是輸levels:4不少。

Distance+3 YC L Girls und Panzer
        distance:+3 + ColorYUV(levels = "TV->PC")
        無明顯差異。

Distance+3 Anti-YC L Girls und Panzer
        distance:+3 + ColorYUV(levels = "PC->TV")
        無明顯差異。

Distance+3 +2-5 Girls und Panzer
        distance:+2 + bad:{sad:200,range:-5}
        bad.range:Use positive value for UMH search and negative for Exhaustive search.
        細節處 +3優於+2-5
        看板處 +3效果與 +2-5差異並不明顯。

Distance+1 +2 Girls und Panzer
        看板處,
        搜索半徑+1非常不足(超過半數),
        搜索半徑+2也不足(20%比例),
        根據過去測試,大概要半徑2.5~3.5才會有最佳表現。

Distance+3 -1-3 Girls und Panzer
        distance:-1 + bad:{sad:1,range:-3}
        與distance:+3表現類似,發現缺點為理應為轉場時卻有Blend。

Distance+3 -4-2 Girls und Panzer
        distance:-4 + bad:{sad:15,range:-2}
        看板處流暢度幾乎一樣,細節處各有優劣,不易區分。

Distance+3 -5-1 Girls und Panzer
        distance:-5 + bad:{sad:1,range:-1}
        看板處流暢度幾乎一樣,細節處各有優劣,私心認為+3比-5-1優異一點。

Distance+3 -1-1 Girls und Panzer
        distance:-1 + bad:{sad:1,range:-1}
        看板處流暢度幾乎一樣,看來bad.range和coarse.distance計算方式不近相同。

Distance+3 -1-1(levels3) Girls und Panzer
        distance:-1 + bad:{sad:1,range:-1} + levels:3
        Blend多,看來之前說要把bad.range設0,是陷入區域最佳了。

小結:
1. 增加亮度噪點幾乎沒有差異。
2. 增加色度噪點可以提高一些細節表現,但低對比區域表現下降。
3. 1080p影片來說,levels:3的確不夠,目前各項測試皆顯示levels:4流暢度更佳。
4. 增加噪點或拉高對比,能提供的改善非常小。
5. bad.range沒有自適應半徑設計,Use positive value for UMH search and negative for Exhaustive search.
6. coarse.distance:-1 + bad:{sad:1,range:-1}在低對比表現與coarse.distance:+3相當,而且bad.range即使拉到-5也無明顯大幅增加偽影。
7. bad.range和coarse.distance計算方式不近相同。
8. 之前說要把bad.range設0,可能是陷入區域最佳了。
9. bad.range目前發現缺點應為轉場重複幀時卻產生Blend。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
(增加噪點或拉高對比,能提供的改善非常小。)
看來這條路不通...真可惜

bad.range<0是在搜尋出的MV再做一次EXH
而且是擴張式的先搜尋1的位置
3333333
3222223
3211123
3210123
3211123
3222223
3333333

然後比較SAD如果小於一開始的1/4則結束
否則再搜尋2->比較SAD->再搜尋3->...直到設定的range為止

A:
想請問一下,
bad.range是否與penalty系列參數無關?
因為沒想到bad.range只要-1的效果就能與coarse.distance:+3比肩,
原先以為要coarse.distance:-4 + bad:{sad:1,range:-2}才有辦法,
結果測試結果出乎意料...

K:
penalty的lambda和pnew一樣會影響bad.range用的UMH或EXH

記得之前有試過coarse.distance調小加上bad.range輔助
但效果似乎不怎麼好就放棄了
可能要再詳細試試

----------------------------------------------------------------------------------------
2017.06.06

A:
但這很奇怪,
distance設+1 +2 +3都有明顯差異,
結果bad.range設-1就至少有distance:+3的流暢度

K:
我猜因為+3是搜尋-3~+3的範圍
而-1-1是先搜尋-1~+1

如果結果是+1的話再以-1搜尋0~+2
如果結果是-1的話再以-1搜尋-2~0

所以-1-1的範圍相當於-2~+2
有接近+3的效果

A:
嗯,感謝您的說明,
-1-1的效果在低對比區域比+2還好,
有+3左右水準

原先是猜不受到penalty系列參數束縛,
所以效果很明顯,好像想錯了

K:
我也只是從程式碼去推斷
可能有誤也說不定

A:
請問一下,
penalty參數會去影響搜索半徑,
但最小半徑還是1對吧?

像是lambda設1000
半徑依然會有1,而不會變0。

K:
程式碼看不出有半徑至少會有1的處理

btw,最coarse層(搜尋開始的那層)
的lambda值會調成0
所以可以說最coarse層是fixed range的話
半徑至今會有1

A:
最近又試了幾種參數,

bad1 1000 Girls und Panzer
        distance:-1 + bad:{sad:1000,range:-3}
        distance:-1 + bad:{sad:1,range:-3}
        bad:{sad:1000}在看板處流暢度還不錯,
        但在看板處的背景(樹&草)就有明顯的blend出現,
        細節部分則好像有比bad:{sad:1}稍微好一點點(不明顯)。

MShow Distance +3 -5 Girls und Panzer
MShow Distance +3 -1-1 Girls und Panzer
http://screenshotcomparison.com/comparison/211649
        利用MShow查看MV,
        bad:{range:-1}與distance:+3,在低對比區域近似,
        而細節則是bad:{range:-1}搜索較積極(偽影可能也因此較多),
        看來,bad還是不能開。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
或許bad.range還是能幫助低對比區域
只是bad.sad要再試試設多少能不造成偽影變多增加流暢

設1000可能只有最coarse層bad才有作用
往finest上SAD已經很小了所以不會作用增加偽影
設1可能每層都會作用變成偽影增加也說不定

A:
當時設1是想把bad.range當成coarse.range用。

bad.sad調高後,
低對比區域可能因為SAD較低,
反而不會搜尋低對比區域,
只搜尋較高對比處,

K:
這樣低對比區就只能用fixed range來提高半徑了

A:
這幾天有透過width參數,
限制coarse層來減少bad參數作用的層數,
不過效果不彰。

K:
真的沒招了XD


A:
Distance -5 coarse width 250 Girls und Panzer
        finest:{distance:-8, satd:true}
        coarse:{distance:-5, width:250}
Distance +2 coarse width 250 Girls und Panzer
        finest:{distance:-8, satd:true}
        coarse:{distance:+2, width:250}
Distance +2 coarse -5 width 500 Girls und Panzer
        finest:{distance:+2, satd:true}
        coarse:{distance:-5, width:500}
Distance +3 coarse -5 width 500 Girls und Panzer
        finest:{distance:+3, satd:true}
        coarse:{distance:-5, width:500}
Distance +2 coarse +2 width 250 Girls und Panzer
        finest:{distance:+2, satd:true}
        coarse:{distance:+2, width:250}
        以上效果皆不佳

Distance +5 coarse +2 width 250 Girls und Panzer
        finest:{distance:+5, satd:true}
        coarse:{distance:+2, width:250}
        看板處僅有一處不流暢,是本批測試裡面唯一效果較佳的,
        但很消耗處理器性能,所以也不實用...


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
finest還是關掉satd吧
我猜在coarse開就足夠了

另外distance也會受到lambda影響
把lambda設低或plevel設1再試說不定能比較看得出
corase和finest的distance怎麼分布比較好

A:
Levels +4 -4 Girls und Panzer
        levels:-4,偽影少很多,
        但Blend更多,且也更不流暢。

Levels +4 -3 Girls und Panzer
        levels:-3,偽影較少,
        但Blend更多,且也更不流暢。

Levels +4 -2 Girls und Panzer
        levels:-2 和 levels:+4看起來一樣啊!


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
因為1080p的levelmax為6
所以
6-4 = 2
6-3 = 3
6-2 = 4

A:
這幾天再試試看降低width搭配bad.range,快沒招了XD

K:
辛苦了
用人工最佳化參數實在是很吃力
如果能像深度學習用機器去自己找參數就好了

A:
啊~
實在不想一次動超過3個參數,
要測試的量會變爆多,
penalty參數特別麻煩XD
不過好像也沒辦法了…

最近再試看看lambda、plevel好了。


----------------------------------------------------------------------------------------
2017.06.08

K:
真的很麻煩~
doom9上好像沒什麼調整搜尋參數的討論
比較偏向用artifact masking來補救偽影

A:
畢竟artifact masking改善偽影比較方便 XD

參數可能要往MVTools的討論去找吧,
畢竟svpflow也是從MVTools改來的。

K:
MVTools也找不太到參數的討論
比較多是拿找出來的MV做其他影像處理
這應該才是開發MVTools的原因吧
補幀只是其中一項功能

A:
這幾天因為Blog寫了些BlueskyFRC的東西,
有去查些資料,
其中,關於不同AMD顯示卡開啟AFM後效果是否相同?
眾說紛紜,有人說沒差,有人說換成RX460後比以前感覺更好,

於是用HD7770做了個測試,
利用.grf將經BFRC處理後的影片壓制出來(影片1),
然後再用.grf壓制出來一次(影片2),
理論上影片1與影片2應該要一樣,或無法分辨差異,
結果很神奇的...有差,而且差不小。
BFRC TEST Accel World.mp4

用類似的方式,(trim是因為兩次SVP啟動時間不同,校正用)

透過.grf經過ffdshow raw filter外掛SVP,兩次壓制
SVP Accel World Creditless ED2.mp4

SVP跑出來的影片很接近,
而BFRC很神奇的有些差異,還不小(以逐幀觀點),
不過用的是沒原生支援AFM的HD7770,
不確定是否有差異。

幾天後再R7-260試試。

K:
這就麻煩了
不曉得是DirectShow本身的機制還是AFM會根據情況微調
或是DirectShowSource其實只是一張張截圖下來?

先排除變因的話
試試把BFRC的output接上Video Renderer
用GraphEdit的播放看看有沒有差異

如果不會的話就要把BFRC的output接上
其他encoder和muxer看這樣能不能輸出正確的檔案了

----------------------------------------------------------------------------------------
2017.06.14

A:
直接使用GraphEdit撥放就不同了...


原本以為是7770有問題,(7770是朋友那邊借來的,偶有黑屏問題)
前幾天換R7-260測試,一樣有類似情況,除非R7-260也壞了。

同張卡每次開啟AFM撥放都類似,但就是不會一樣,
至於7770和R7-260的效果有差嗎?
我可以很確定,絕對有差 (如果卡沒壞的話...)

K:
差異很細微
會不會是因為時間差了0.001秒
所以其實是不同張frame?

不知道直接寫信問BFRC作者會不會最快XD

A:
這個我有想到,但是怎麼會只差1ms?
前一張或後一張,應該都要差超過10ms吧。
差0.001秒不知道是怎麼回事XD

我挑的那張比較不明顯,隨手亂挑的...





這幾個就比較明顯,
youtube影片隨便一個時間點,
都有機會看到一邊有Blend一邊沒有的情況發生。

A:
測試環境均相同(同版本驅動丶同版本LAV丶同版本BFRC丶均為Mode 2)
唯二不同
1. 顯示卡 HD7770 / R7-260
2. x265壓制參數(不過這應該沒差太多)

看起來兩者效果並不算非常巨大,但R7-260的表現的確比較佳,
測試中最明顯的部分在SAO OP片段,亞絲娜在人行道上走動的部分最明顯(00:21~00:25處),
可以看地磚運動狀況,(因為版權因素,放上Youtube被強制下架,因此不便公開影片)
嘗試將R7-260切換到Mode 1測試,結果與上面又不太一樣,所以不是7770被切換成Mode 1。

偽影部分兩張卡差不多,差異主要在轉場Blend臨界點設定不同?

但以上測試有個瑕疵...
HD7770這張卡是有點小毛病的,不確定是否會有影響。

不過GCN1.0官方就沒有開放AFM功能,
所以無法推測不同卡是否有所不同。

K:
嗯...
這樣說不定能期待比較新世代的卡還會比較好
可惜AMD顯卡這方面資料都很少
像我想查硬解能力到哪都查不太到
nv就有wiki整理得很完整

A:
真的好少,這是看到寫的比較完整的,但還是很"精簡"
https://www.x.org/wiki/RadeonFeature/#index8h2

哪天有機會的話會測試AMD新出的顯卡,

剛查了一下,WIKI中Unified Video Decoder的資料,

UVD 4
UVD 4 includes improved frame interpolation with H.264 decoder.
看起來就很像AFM的說明。

從Wiki的來源連結中看到下面這串
A new feature is the improved frame interpolation where the GPU calculates
intermediate frames when you watch 24 Hz material on a 50 Hz or 60 Hz screen.
有個新功能,改善在50/60Hz螢幕上觀看24Hz素材時,顯示卡計算中間幀的插幀效果。

HD7770     代號Cape Verde     UVD 4.0
R7-260     代號Bonaire        UVD 4.2
A10-7850K  代號Kaveri         UVD 4.2

說有強化補插的文章連結
https://uk.hardware.info/reviews/5156/6/amd-a10-7850k-kaveri-review-amds-new-apu-extras-trueaudio-and-new-uvd

文章內文是用A10-7850K說明,不確定指UVD4.0或是UVD4.2,

另外有新找到一篇文章說明各UVD版本的硬解能力
http://tieba.baidu.com/p/4794478528

不知道是不是這造成HD7770和R7-260的差異,
看下來好像與GCN版本無關XD


----------------------------------------------------------------------------------------
2017.06.15

K:
但UVD4之前的又沒看到有這功能
而且UVD不就是AMD版的DXVA2(硬解和去交錯)嗎?
居然還有補幀的功能

wiki是引該文說是UVD4.0
但Kaveri的卻是UVD4.2
有點矛盾...

今天看到有人用深度學習去做補幀了!
裡面有論文的連結(日文的
稍微看了一下是用三張連續frame
頭尾兩張當訓練資料
中間那張當訓練目標
論文還在研究
但看youtube好像效果一般般XD

A:
我也很納悶...
剛剛查了一下,確定可以開AFM的最老顯示卡是 HD7970
解碼模組為UVD3.2,顯示卡架構為GCN 1.0
但我找不到模組是UVD3.2而架構不是GCN1.0的顯卡。

GCN 1st Gen : UVD3.2 ~ 4.0
GCN 2nd Gen : UVD4.2
GCN 3rd Gen : UVD5.0 ~ 6.0
GCN 4th Gen : UVD6.3

剛好UVD隨著GCN架構更新,所以也沒辦法分辨是UVD還是GCN負責的,
另外,查到的資料中表示,Kaveri無法開啟BFRC AFM Mode2。

youtube那是4x處理的,學習時間不短,動輒上百小時

發這篇論文的是角川多玩國集團的員工,
目標是想把動畫升到60fps,還是想把原生fps壓到8fps?XD


----------------------------------------------------------------------------------------
2017.06.15

K:
看起來應該是想讓1拍2(12fps)或1拍3(8fps)的作畫(不含攝影等後期)
提升到全動畫(24fps)
或是人工原畫而用AI產生中割來節省人力
但我覺得還有很長的路要走

----------------------------------------------------------------------------------------
2017.08.04

A:
之前有篇信件中您有提到
"在翻看原始碼時注意到
雖然只有對比<2時距離才會變為0
但不同search.type
在距離為0會有些不一樣的行為
EXH不會做搜尋,和距離為1不同
HEX和UMH還是會搜尋,跟距離為1結果一樣"

這幾天想說是否可以用這方式來改善低對比下的流暢度,
所以做了些測試

coarse type 3 Girls und Panzer
coarse type 3 URA-ON
        finest:{type:3}
        coarse:{distance:-5, type:3}
        流暢度無明顯變化,畫面差異極小

coarse type 3 Sword Art Online[OP01]




        finest:{type:3}
        coarse:{distance:-5, type:3}
        從部分截圖發現type:3會有顏色斷層的情況,
        而且部分Blend區塊色彩不均勻,
        另外搜索半徑略小於type:4(不明顯)
        p.s. imgur把圖壓成jpg,變得比較不明顯一些,Google Drive的原圖比較明顯

coarse type 3 Charlotte  OP01



        finest:{type:3}
        coarse:{distance:-5, type:3}
        部分較為複雜的畫面type:3所呈現的畫面會較為破碎些,
        但在快速不規則小物件移動下(Ex:手指),偽影抑制效果較佳,
        另外,部分畫面色彩過度較為不平滑些。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
抱歉忘了說
在coarse層用UMH會有奇怪的抖動
所以我都只用在finest層而已
coarse層只用EXH或HEX
(令我懷疑SVP的UMH是不是實作有問題

A:
最後想說type 3和4的差異不算很大,
如果資源消耗大很多的話,應該就會改使用type3
結果...

type 4消耗得比type 3還要小啊!!
後來想說可能是refine造成的影響,關閉refine後重測

還是一樣...

K:
這真令我意外!
難怪SVP預設上都沒用到UMH
以壓檔的經驗來說UMH都是比EXH快的

題外話
最近看你的名字的OP
有一幕天空pan過去抖得頗明顯
用trymany好像還是幫助有限
還是要提高coarse.distance或是levels
可是這兩種都會增加些偽影
真是頭痛orz

A:
聽起來像低對比造成搜索半徑不足的問題...
目前有在\SVP 4\script\base.avs修改這一行當安慰劑用
super=SVSuper(input, super_params).ColorYUV(levels ="TV->PC")
在這方面也沒有想到甚麼辦法...

K:
是類似GuPdF的破爛熊看板那種抖
改成先ColorYUV()再SVSuper()應該會比較快

試來試去好像都會導致其他場景出現偽影
btw之前有感覺
一個經過銳化濾鏡的rip比沒有經過濾鏡的
偽影要來得少些
但沒有詳細比較也許只是錯覺

A:
這種似乎除了加大搜索半徑似乎沒有甚麼好辦法?
super = ColorYUV(input, levels ="TV->PC").SVSuper(super_params)

K:
還有就是增加level數orz
嗯,這樣改的效果應該和SVSuper().ColorYUV()一樣但會快一些些

A:
自從levels:3改成4後,偽影就不好壓了,
再增加levels該怎麼辦XD


----------------------------------------------------------------------------------------
2017.08.06

A:
重做了些測試
finest type 4 3 no refine

        比較了一下,finest.type:2 3 4所消耗的資源差異,皆不做refine
        效能 type 2(102%) > type 4(100%) > type 3(92%)
        如果做refine的話,差異會小一些。
        好像UMH有點問題...?

K:
沒想到HEX也沒快多少
還是說adaptive radius和lambda
使得EXH速度上跟HEX一樣了

A:
應該是這樣,
測試用的參數是finest.distance:-8,lambda:10.0


A:
補充日期:2017.08.13
補充內容
後來發現快很少的原因可能是因為其他地方有瓶頸,但目前尚未找出,因為發現不使用svpflow,fps才255而已,甚至比開啟還低。


A:
補充日期:2017.08.23
補充內容
24fps的影片跑240fps和60fps的影片跑600fps的速度才會一樣,之前(2017.08.13)搞錯了。

A:
finest type 3 Girls und Panzer
finest type 3 URA-ON
finest type 3 Charlotte  OP01
finest type 3 Sword Art Online[OP01]

        finest:{type:3, distance:-8}
        coarse:{type:4, distance:-5}
        差異極小,連逐幀觀看都很難看出差異,
        硬要說的話,似乎type:3波紋狀的偽影表現好一點點。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

K:
同distance下UMH實際上會比EXH範圍要廣
不過理想上UMH的效果應該要接近EXH而速度要比EXH快
所以比較慢就沒有使用的價值了

A:
UMH真的慢得很明顯。


----------------------------------------------------------------------------------------
2017.08.07

A:
您之前有提過lambda的分佈是如此(下圖錯誤)

後來又說最coarse層的lambda會被設為0
這項有衝突,故有此一問。

K:
我也是後來看程式碼才發現

A:
所以計算方式應該是和官網一致囉?
Let the finest level number is 0 and we've got N levels total => the smallest level number is N-1.
<local lambda value at level K> = lambda * 1000 / (plevel^(N-1-K))
另外指定最coarse層為0

還有個問題是,
這裡提到的最coarse層是指我們指定分析的最coarse層,
還是該解析度對應的最coarse層呢?
舉例來說:1080P
總共有 level 0 1 2 3 4 5
設定levels:4
等於分析level 0 1 2 3
那lamdba為0的是level 3還是5呢?

K:
從原始碼來看
lambda必為0的是level 3


----------------------------------------------------------------------------------------
2017.08.09

A:
自從改了levels:4後,
調整lambda對於偽影改善很小,
偽影主要因素應該是level 3這層來的?

K:
應該是
因為每一層的搜尋都是基於上一層的結果
所以開始搜尋的那層(smallest層)影響最大
btw,除了lambda外pnew也會是0

A:
不知道設定levels:5,
但是將Super的輸出只保留4層,
可不可達到限制第4層的lambda的效果,

K:
大概只能自己改程式碼來達到了

A:
不然依說明
<local lambda value at level K> = lambda * 1000 / (plevel^(N-1-K))
(此圖與前面某圖一樣,近期才發現過去理解錯誤的)

不是很奇怪嗎...
本應lambda最高的值卻變成0

K:
真的很奇怪(-"-)
我想應該是認為smallest層不用限制
盡量找出來然後靠後面層去調整

----------------------------------------------------------------------------------------
2017.08.10

K:
原本打算放棄了
因為之前的參數增加distance效果有限
這兩天試來試去後
決定再增加levels然後靠更小的distance來減少偽影(越改越回頭啦orz

對照2017.07.25那份參數修改了下面幾處(已整合在一起,免向前翻閱)

K:

補充日期:2017.08.17
補充內容:下列參數還在測試,因為感覺偽影有增加,還需要再調整)

override = function()
{
// It's recommended to add needed options via Application settings ->
// Additional options -> All settings -> User defines options

/***** SVSuper options *****/

//levels.pel    = 2;
//levels.gpu    = 0;

levels.pel    = 1;

//levels.scale.up   = 2;
//levels.scale.down   = 4;
//levels.full    = true;

levels.full    = false;

/***** SVAnalyse options *****/

//analyse.vectors   = 3;
//analyse.block.w   = 16;
//analyse.block.h   = 16;
//analyse.block.overlap   = 2;

analyse.block    = {w:32,h:32};

//analyse.main.levels   = 0;
//analyse.main.search.type  = 4;
//analyse.main.search.distance  = -4;
//analyse.main.search.sort  = true;
//analyse.main.search.satd  = false;
//analyse.main.search.coarse.type = 4;
//analyse.main.search.coarse.distance = 0;
//analyse.main.search.coarse.satd = true;
//analyse.main.search.coarse.trymany = false;
//analyse.main.search.coarse.width = 1050;
//analyse.main.search.coarse.bad.sad = 1000;
//analyse.main.search.coarse.bad.range = -24;

//直接層數-1,不用再計算levelsmax了
analyse.main.levels = -1;

//感覺finest還是用UMH比較滑順,我猜是因為一定會搜尋距離4的點的關係
analyse.main.search.type  = 3;
//但distance改成-3
analyse.main.search.distance  = -3;

//coarse改成type:2,distance:-2,因為HEX試起來偽影比EXH少些
//trymany因為levels增加所以不需要了
analyse.main.search.coarse = {type:2,distance:-2,bad:{range:0}};

//analyse.main.penalty.lambda  = 10.0;
//analyse.main.penalty.plevel  = 1.5;
//analyse.main.penalty.lsad  = 8000;
//analyse.main.penalty.pnew  = 50;
//analyse.main.penalty.pglobal  = 50;
//analyse.main.penalty.pzero  = 100;
//analyse.main.penalty.pnbour  = 50;
//analyse.main.penalty.prev  = 0;

//distance變很小lambda的影響也變低
//改回預設感覺也差不多(還需要更多測試
analyse.main.penalty.lambda = 12.0;
analyse.main.penalty.plevel  = 1.6;
analyse.main.penalty.pnbour  = 65;

//analyse.refine[0].thsad  = 200;
//analyse.refine[0].search.type  = 4;
//analyse.refine[0].search.distance = 2;
//analyse.refine[0].search.satd  = false;
//analyse.refine[0].penalty.lambda = 10.0;
//analyse.refine[0].penalty.lsad = 8000;
//analyse.refine[0].penalty.pnew = 50;

//改成1感覺也差不多,暫定2
analyse.refine = [{search:{distance:2}}];

/***** SVSmoothFps options *****/

//smooth.rate.num   = 2;
//smooth.rate.den   = 1;
//smooth.algo    = 13;
//smooth.block    = false;
//smooth.cubic    = 0;
//smooth.linear    = true;

smooth.algo    = 23;

//smooth.mask.cover   = 100;
//smooth.mask.area   = 0;
//smooth.mask.area_sharp  = 1.0;

smooth.mask    = {cover:80};

//smooth.scene.mode   = 3;
//smooth.scene.force13   = true;
//smooth.scene.luma   = 1.5;
//smooth.scene.blend   = false;
//smooth.scene.limits.m1  = 1600;
//smooth.scene.limits.m2  = 2800;
//smooth.scene.limits.scene  = 4000;
//smooth.scene.limits.zero  = 200;
//smooth.scene.limits.blocks  = 20;

smooth.scene    = {mode:0,limits:{scene:3000,blocks:40}};

//smooth.light.aspect   = 0.0;
//smooth.light.sar   = 1.0;
//smooth.light.border   = 12;
//smooth.light.lights   = 16;
//smooth.light.length   = 100;
//smooth.light.cell   = 1.0;

//smooth.gpuid    = 0;
}

這樣快速pan已經不會抖了
目視上偽影有增有減
還需要更長的時間驗證
請參考參考

A:
信件整理一部分了,看您無需要針對哪邊修正之類的?
修正處還麻煩以紅底標示,不然在這麼多頁中找差異有點困難...
或者來信註明欲修正段落的日期也可以

K:
整理得很完整,感謝
一路看下來
從最早的levels:3到現在levels:-1
好像漸漸走回去用預設值了XD
不過這應該是我們的要求變嚴格了
偽影,滑順,效能都要兼顧
感謝A大你一路來嘗試那麼多的參數
做了那麼多的比對和測試<(_ _)>
沒有這些我也不會有機會釐清自己錯誤的認知
能遇到同好實在很幸運~
一起在補幀技術上(ex.4K)繼續切磋吧!

A:
前陣子試了 你的名子4K SVP果不其然的...跑不動XD

K:
i7-7770k也是不行嗎?
我本來想說加一張有HEVC Main 10硬解的卡
用i7-4790就應該跑得動...
看來要換Ryzen了

A:
忘了說這部是4:4:4的XD
不過試了一下4K 100Mbps的花海 + 硬解
也還是跑不動,而且還是全程都卡,
Ryzen可能也沒辦法,畢竟R7@3.7G效能也就比7700K@5G好35%而已
4K大概只能降參數了吧(?
或者買張FM卡專門對付4K影片XD

K:
444的好像不在硬解支援內
我覺得有硬解的話至少i7要可以補4K
先把所有吃CPU的參數全關
然後再慢慢調整


----------------------------------------------------------------------------------------
2017.08.11

A:
之前測試的時候有分別針對Coarse和finest用UMH和EXH做比較,
在finest層
大概50幀裡面大概有45幀看不出差異,2幀EXH較佳,3幀UMH略好一點點,
不過也有可能是我做2次EXH的refine,使得差異變小

Coarse層看起來EXH的表現比UMH好不少,不過沒特別試HEX。


A:
補充日期:2017.08.17
補充內容:於2017.08發現過去測試腳本設置錯誤,導致比對參數會互相干擾,過去對比測試全部作廢。

A:
不知道這樣有沒有效果?
把Super產生的階層畫面從第level層之後的畫面替換成純色,
由於純色,使得該畫面的對比度為0,讓其搜索半徑降至0。

(以下限定在pel=1時使用)
#計算pel = 1時的Super畫面的高度
#InHeight:input畫面的高度
#Count:做幾次縮小
#SumHeight:各階層高度總和
Function SuperHeight(int InHeight, int "Count", int "SumHeight")
{
Count = Default(Count, 15)
SumHeight = Default(SumHeight, InHeight)

halfHeight = InHeight > 4 ? (InHeight/4)*2 : 0

Count > 1 ? SuperHeight(halfHeight, Count-1, SumHeight+halfHeight) : SumHeight
}

#設定欲保留之階層數
levels = 4

#SuperC用來取代原先的Super
SuperC = StackVertical(\
Crop(super, 0, 0, 0, -(Super.height-SuperHeight(input.height, levels))),\
super.BlankClip(height=2)).\
PointResize(Super.width, Super.height, 0, 0, Super.width, Super.height)

然後再將main.levels設成5,
由於level 4(第5層)的畫面在Super內是全黑的,對比為0,
應該就可以避開最coarse層lamdba為0的情況(不算純色的第5層)

K:
這想法感覺不錯
只是不曉得這樣super會不會不被SVP認得

A:
應該是可以的吧

K:
因為記得MVSuper()的輸出SVAnalyze()是不認得的
所以擔心StackVertical()會不會也是

A:
不認得的原因應該是MVSuper有在每層level邊緣填充像素,

而SVSuper並沒有做這動作,導致輸出的圖像尺寸不同。

A:
另外發現一件事,
使用AVSMeter測試效能時,
發現輸出Super和smooth的fps幾乎一樣...(210fps)
Prefetch丶MTMode的效果也很差,沒設好甚至會只剩20%的速度
全開和全關沒什麼效能差異...

K:
SVSuper()只有做縮放
應該會很快才是
有可能效能瓶頸不在運算
而是在記憶體間的資料搬移嗎?

A:
我耍蠢了...
一個是24fps影片輸出210fps
另一個是60fps影片輸出210fps,是差很多才對...
另外,的確有發現效能莫名差很多的問題
SetFilterMTMode("DEFAULT_MT_MODE",2)
video = "Anime_BD.dat"
video = LWLibavVideoSource(video,format="YUV420P8")
input = AssumeFPS(video,24000,1001)
global threads=8*1.823
input.Prefetch(Round(threads))

FPS 24.66


SetFilterMTMode("DEFAULT_MT_MODE",2)
video = "Anime_BD.dat"
video = LWLibavVideoSource(video,format="YUV420P8")
input = AssumeFPS(video,24000,1001)
global threads=8*1.823
input

FPS 253.6
不過在使用SVP時,使用Prefetch()可以讓速度從45fps -> 210fps


K:
光用Prefetch()應該是不會變快啦
還要搭配能平行處理的plugin
但會變慢我就不曉得原因了

我猜這時CPU沒滿?

A:
要搭配使用MTMode才會有作用,但是會變慢的確是件很奇怪的事

CPU那時的確沒有滿


----------------------------------------------------------------------------------------
2017.08.17

A:
測試過程中發現一個很嚴重的問題,之前的所有測試可能全部要重測,抱歉Orz
因為svpflow應該會用到之前幾的訊息,之前寫的腳本全部錯誤
下列為之前比較用的腳本
LoadPlugin("svpflow1.dll")
LoadPlugin("svpflow2.dll")
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("SVSuper",1)
SetFilterMTMode("SVAnalyse",1)

a = "Girls und Panzer.mp4"
#對比檔案

input = LWLibavVideoSource(a,format="YUV420P8").AssumeFPS(24000,1001)
#視訊讀取並指定fps

global super_params     = "{}"
global analyse_params   = "{}"
global smoothfps_params = "{}"
#SVP左方參數

global super_params2     = "{}"
global analyse_params2   = "{}"
global smoothfps_params2 = "{}"
#SVP右方參數

super=ColorYUV(input, levels ="TV->PC").SVSuper(super_params)
vectors=SVAnalyse(super, analyse_params)
smooth=SVSmoothFps(input, super, vectors, smoothfps_params, mt=threads)
#左方影片

super2=ColorYUV(input, levels ="TV->PC").SVSuper(super_params2)

Function SuperHeight(int InHeight, int "Count", int "SumHeight")
{
Count = Default(Count, 15)
SumHeight = Default(SumHeight, InHeight)
halfHeight = InHeight > 4  ? (InHeight/4)*2 : 0
Count > 1 ? SuperHeight(halfHeight, Count-1, SumHeight + halfHeight) :
SumHeight
}

levels = 4

superC = StackVertical(\
Crop(super2, 0, 0, 0, -(super2.height-SuperHeight(input.height, levels))), super2.BlankClip(height=2)).\PointResize(super2.width, super2.height, 0, 0, super2.width, super2.height)

vectors2=SVAnalyse(superC, analyse_params2)
smooth2=SVSmoothFps(input, superC, vectors2, smoothfps_params2, mt=threads)
#右方影片

StackHorizontal( smooth, smooth2)
結果只變動analyse_params,沒改變analyse_params2時,卻很明顯有影響到smooth2的畫面
原本以為是algo23影響的,不過algo2也依然有此現象。
之前所做的比較全部要重來了...
不過值得欣慰的是,既然可以影響到,那也表示應該可以混和兩種不同參數的效果。

K:
可能沒有考慮到混用的情況
所以同一份腳本只有一個SVP在運作
導致互相影響吧

A:
Avisynth可以像VS一樣分開調用不同路徑的plugin嗎?
想避免互相干擾,不然以後測試全部要分成3步驟
1. 參數A影片
2. 參數B影片
3. 合併參數A&B影片
覺得有點麻煩XD

K:
有提到可以前綴dll的檔名來區別
http://avisynth.nl/index.php/Plugins
- Plugin Autoload and Conflicting Function Names
看能不能將svpflow*.dll複製一份改名
變成兩個不同的SVP


----------------------------------------------------------------------------------------
2017.08.20

A:
同一腳本中使用不同路徑之svpflow.dll依然有相互影響的現象,

K:
有改dll檔名嗎?例如
將svpflow1改svpflow3,svpflow2改svpflow4
然後加在呼叫函式前
LoadPlugin("svpflow3.dll")
LoadPlugin("svpflow4.dll")
super1=svpflow1_SVSuper(...)
super2=svpflow3_SVSuper(...)

A:
未來測試將會全部隔離處理,一腳本中只會有一組svpflow執行。

K:
這樣做比較好
能確保結果最正確
但麻煩了點

A:
抱歉,
剛重看了一下,原來是我腳本寫錯了orz
調用到同一個svpflow2.dll,

修正腳本後,調用不同dll檔案可以避免相互干擾的問題。

A:(誤開main.satd)
這兩天重做一些測試
以下實驗均使用MeGUI壓制出來後比較,未來可以回顧,方便逐幀比較,避免直接播放比較時的誤判。

對照組參數
super_params     = "{scale:{up:0,down:4},gpu:1,pel:1,full:true,rc:false}"
analyse_params   = "{
vectors:3,
block:{w:32,h:32,overlap:2},
main:{
levels:4,
search:{
type:4,
distance:-8,
sort:true,
satd:true,
coarse:{
distance:3或-5,
type:4,
satd:true,
trymany:false
bad:{sad:1000,range:0}}
},
penalty:{
lambda:10.0,
plevel:1.5,
lsad:8000,
pnew:50,
pglobal:50,
pzero:100,
pnbour:50,
prev:0}
},
refine:[
{search:{type:4, distance:2},thsad:250}]
}"
smoothfps_params = "{
rate:{num:5,den:2},
algo:23,
mask:{cover:100},
cubic:true,
linear:true
scene:{
blend:false,
limits:{m1:2000,m2:3600,scene:5400,zero:120,blocks:52},
force13:true,
luma:1.5
},
}"

*下列參數結尾之[fps / %],為使用AVSMeter 2.5.4 64bit測得,
 測試影片採用PSYCHO-PASS II OP01 [BD-Remux_1080p],
 是為了測試參數在高複雜影片的效能,與畫面比較採用的影片不同。

-----20170819-----

\superC\Compare with Coarse distance+3\Lv5 superC D+3 Girls und Panzer.mp4
\superC\Compare with Coarse distance+3\Lv5 superC D+5 Girls und Panzer.mp4
\superC\Compare with Coarse distance+3\Lv5 superC D-12 Girls und Panzer.mp4
左側對照組
levels:4 coarse:{type:4, distance:+3} [100.3fps / 100.0%]
右側實驗組
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:+3} [99.29fps / 98.40%]
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:+6} [79.15fps / 78.91%]
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:-12} [103.2fps / 102.9%]
實驗目的
測試遮蔽最Coarse層後效果,測試其流暢度。

實驗結果
三個實驗組的"波紋類偽影"皆明顯少於對照組,
但實驗組之"Blend"皆相對於對照組有所增加,
其中Blend量由多至少為:distance: +3 > -12 > +6 > 實驗組。

個人評分
實驗二 >= 對照組 >> 實驗三 >>> 實驗一,
其中實驗一的表現太差,淘汰。
對照組的評分略輸於實驗二的原因是波紋類偽影較多,
實驗二的Blend還是略有一些,可能需要稍微調整其餘參數。

K:
看來lambda還是會影響流暢
即使在distance只有3時

A:
所以很明顯,流暢最主要就是最coarse層的lambda被設為0這件事上,
而且偽影來源也是最coarse層,
藉由遮蔽最Coarse應該可以降低不少偽影,

至於流暢度部分也許用提高levels或調整lambda丶plevel來改善。

A:(誤開main.satd)
\superC\Compare with Coarse distance+3\Lv5 superC D+3 URA-ON!!.mp4
\superC\Compare with Coarse distance+3\Lv5 superC D+5 URA-ON!!.mp4
\superC\Compare with Coarse distance+3\Lv5 superC D-12 URA-ON!!.mp4
左側對照組
levels:4 coarse:{type:4, distance:+3} [100.3fps / 100.0%]
右側實驗組
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:+3} [99.29fps / 98.40%]
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:+6} [79.15fps / 78.91%]
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:-12} [103.2fps / 102.9%]
實驗目的
測試遮蔽最Coarse層後效果,測試其流暢度。

實驗結果
四者表現很接近,唯有實驗三略差一點點
硬要區分流暢度差異的話:實驗組 >= +6 >= +3 > -12。

個人評分
實驗一 >= 實驗二 = 對照組 > 實驗三,
實驗一和二的排序比對照組前面的原因是三者流暢度十分接近,
但實驗一波紋狀偽影比較輕微,實驗二其次。



\superC\Compare with Coarse distance-5\Lv5 superC D+3 D×D 映像特典.mp4
\superC\Compare with Coarse distance-5\Lv5 superC D+5 D×D 映像特典.mp4
\superC\Compare with Coarse distance-5\Lv5 superC D-12 D×D 映像特典.mp4
左側對照組
levels:4 coarse:{type:4, distance:-5} [111.3fps / 100.0%]
右側實驗組
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:+3} [99.29fps / 89.21%]
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:+6} [79.15fps / 71.11%]
levels:5 -> 4 (遮蔽level 4) coarse:{type:4, distance:-12} [103.2fps / 92.72%]
實驗目的
測試遮蔽最Coarse層後效果,測試其波紋狀偽影抑制程度。

實驗結果
線條保留:實驗三 > 實驗一 > 對照組 = 實驗二
波紋狀偽影少至多:實驗三 > 其他
流暢度: 實驗二 = 對照組 >= 實驗三 >> 實驗一。

個人評分
全部不及格,硬要挑出哪個比較爛的,應該就是實驗一,
實驗一明顯流暢度不足,而其他各自有缺點,且流暢度也全都還不太夠,
這片段果然是大魔王等級,以後再來搞好了...

K:
這邊是否distance也設-5比較好比較效果?

A:
應該不會,
因為連distance:-12的表現都非常差,
感覺是搜索距離太小導致Blend很嚴重。

真要說,+6的表現還好一些。
不過連對照組都不怎麼流暢,看來對照組的參數可能還要再改改,
原本想說對照組盡可能以SVP預設值下去測試,
所以不是我們常用的那幾組參數設定,
看來預設值真的無法滿足我們了XD

突然覺得自己很蠢,

用一個不夠理想的參數來對比另一組新參數,我到底在幹嘛XD

K:
上封沒說清楚
我是說對照組的參數是-5
實驗組是不是也弄一組-5的來對比

比較容易看出遮蔽帶來的效果^^

A:
恩,也對!

後來發現DXD覺得會不流暢的原因是scene參數設定造成的,

不過DXD的情況比較極端,打算晚些再來調整。

A:
從這幾個測試中發現遮蔽最coarse的確有其效果,
在少戰及URA-ON!!這兩部的表現都還算不錯,
流暢度不會輸太多,波紋偽影也有些許下降,
但需要達到同樣流暢度需要添加更高的搜索半徑,
猜測SVP官方把最coarse層的lambda改成0可能是想要減少一些資源消耗吧

K:
這樣似乎還是用多level加上小distance比較好

A:
恩,目前想法也是加大levels及調整lambda丶plevel
畢竟遮蔽最coarse層等於把搜索半徑最大的一層抽掉了。

A:
另外在高複雜度上的影片(DXD)表現就不如預期。
之後可能會測試自適應搜索半徑搭配bad.range的效果,
看看是否能夠達到降低資源消耗卻有更高流暢度的表現。

----------------------------------------------------------------------------------------
2017.08.21

K:
昨天又試了一下
還是levels:4感覺偽影較少
pan會抖動就只能放棄
反正補不好的也不是只有這類場景而已orz
但還是以提高coarse.distance來改善一點點
下面是結果(紅字是修改處)

/********************************************************
override.js - version 4.0

This file is a part of SmoothVideo Project (SVP) package.
See License_eng.txt for licensing.

Description: add some custom script options processing here

********************************************************/

override = function()
{
// It's recommended to add needed options via Application settings ->
//      Additional options -> All settings -> User defines options

/***** SVSuper options *****/

//levels.pel                            = 2;
//levels.gpu                            = 0;

levels.pel                              = 1;

//levels.scale.up                       = 2;
//levels.scale.down                     = 4;
//levels.full                           = true;

levels.full                             = false;

/***** SVAnalyse options *****/

//analyse.vectors                       = 3;
//analyse.block.w                       = 16;
//analyse.block.h                       = 16;
//analyse.block.overlap                 = 2;

analyse.block                           = {w:32,h:32};

//analyse.main.levels                   = 0;
//analyse.main.search.type              = 4;
//analyse.main.search.distance          = -4;
//analyse.main.search.sort              = true;
//analyse.main.search.satd              = false;
//analyse.main.search.coarse.type       = 4;
//analyse.main.search.coarse.distance   = 0;
//analyse.main.search.coarse.satd       = true;
//analyse.main.search.coarse.trymany    = false;
//analyse.main.search.coarse.width      = 1050;
//analyse.main.search.coarse.bad.sad    = 1000;
//analyse.main.search.coarse.bad.range  = -24;

var levelsmax=Math.floor(Math.log((Math.floor(((mediaInfo.main.reswidth<mediaInfo.main.resheight?mediaInfo.main.reswidth:mediaInfo.main.resheight)-8)/24)*24+8)/32)/Math.LN2)+1;
if(levelsmax>=3)
        analyse.main.levels             = levelsmax*3>>2;
analyse.main.search.type                = 3;
analyse.main.search.distance            = -3;
analyse.main.search.coarse              = {distance:-5,bad:{range:0}};

//analyse.main.penalty.lambda           = 10.0;
//analyse.main.penalty.plevel           = 1.5;
//analyse.main.penalty.lsad             = 8000;
//analyse.main.penalty.pnew             = 50;
//analyse.main.penalty.pglobal          = 50;
//analyse.main.penalty.pzero            = 100;
//analyse.main.penalty.pnbour           = 50;
//analyse.main.penalty.prev             = 0;

analyse.main.penalty.lambda             = 11.5;
analyse.main.penalty.plevel             = 1.6;
analyse.main.penalty.pnbour             = 55;

//analyse.refine[0].thsad               = 200;
//analyse.refine[0].search.type         = 4;
//analyse.refine[0].search.distance     = 2;
//analyse.refine[0].search.satd         = false;
//analyse.refine[0].penalty.lambda      = 10.0;
//analyse.refine[0].penalty.lsad        = 8000;
//analyse.refine[0].penalty.pnew        = 50;

analyse.refine                          = [{search:{distance:1}}];

/***** SVSmoothFps options *****/

//smooth.rate.num                       = 2;
//smooth.rate.den                       = 1;
//smooth.algo                           = 13;
//smooth.block                          = false;
//smooth.cubic                          = 0;
//smooth.linear                         = true;

smooth.algo                             = 23;

//smooth.mask.cover                     = 100;
//smooth.mask.area                      = 0;
//smooth.mask.area_sharp                = 1.0;

smooth.mask                             = {cover:80};

//smooth.scene.mode                     = 3;
//smooth.scene.force13                  = true;
//smooth.scene.luma                     = 1.5;
//smooth.scene.blend                    = false;
//smooth.scene.limits.m1                = 1600;
//smooth.scene.limits.m2                = 2800;
//smooth.scene.limits.scene             = 4000;
//smooth.scene.limits.zero              = 200;
//smooth.scene.limits.blocks            = 20;

smooth.scene                            = {mode:0,limits:{scene:3000,blocks:40}};

//smooth.light.aspect                   = 0.0;
//smooth.light.sar                      = 1.0;
//smooth.light.border                   = 12;
//smooth.light.lights                   = 16;
//smooth.light.length                   = 100;
//smooth.light.cell                     = 1.0;

//smooth.gpuid                          = 0;
}

pnbour調低抖動也感覺有改善,但用預設值會有偽影
main和refine.search的distance都調低,看來不會影響滑順
trymany在coarse.distance=-5下沒什麼幫助也拿掉
這參數也是要再看個幾天

A:
感謝您的參數~

----------------------------------------------------------------------------------------
2017.08.23

K:
coarsest的搜尋範圍不夠或用lambda限制
之後的coarse,finest,refine也救不回流暢
但範圍太大又會有偽影
應該還是要設適當的值

再加上後面一層層修正才比較好

唉~可是加大levels感覺偽影都會變多

還是比較習慣只用3或4層

A:
剛剛試出幾組參數,雖然僅有比過一部影片,但很明顯比之前的任何一組都還要更加優秀XD

正好就是加大levels
偽影和流暢度都比之前設定的levels:4 distance:-5更好,

缺點就是稍微會增加一些資源消耗(約5~10%)

K:
抱歉又改了一下orz
analyse.main.search.coarse = {type:2,distance:-5,bad:{range:0}};

coarse搜尋改用HEX看起來fast panning能再改善一些些

而且有部份的偽影比EXH好些
我猜是這兩個範圍雖然一樣是-5
但HEX在adaptive distance為2或4時能搜尋到3或5較EXH大
而在4或5時,如果2,3的搜尋結果不好就不再搜尋4,5
所以避免了一些偽影
(這邊都是空想,沒有做任何驗證XD

trymany應該是碰巧在GuPdF看板那邊效果不錯
在其他地方都是反效果orz

也許可以來研究下原因...

A:(誤開main.satd)
\superC\Compare with Coarse distance-5\Lv6 superC D+3 Kantai Collection OP01.mp4
\superC\Compare with Coarse distance-5\Lv6 superC D+6 Kantai Collection OP01.mp4
\superC\Compare with Coarse distance-5\Lv6 superC D-6 Kantai Collection OP01.mp4
\superC\Compare with Coarse distance-5\Lv6 superC D-6 Kantai Collection OP01 - R.mp4
\superC\Compare with Coarse distance-5\Lv6 superC D-12 Kantai Collection OP01.mp4
左側對照組
levels:4 coarse:{type:4, distance:-5} [111.3fps / 100.0%]
右側實驗組
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:+3} [99.10fps / 89.04%]
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:+6} [78.85fps / 70.84%]
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:-6} [107.8fps / 96.86%]
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:-6} [107.8fps / 96.86%]
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:-12} [102.9fps / 92.45%]
實驗目的
測試遮蔽最Coarse層後效果,測試其波紋狀偽影抑制程度。

實驗結果
線條保留:實驗三 > 實驗五 > 對照組 = 實驗二 > 實驗一
波紋狀偽影少至多:實驗三 >= 實驗一 > 實驗五 > 實驗二 = 對照組
流暢度:實驗二 = 實驗五 = 實驗一 > 實驗三 > 對照組

個人評分
實驗一 > 實驗五 > 實驗三 > 對照組,(實驗二太消耗資源,故不排入)
實驗組的表現非常好,除了線條保留互有勝負,不過在非逐幀比較下,
線條保留不容易看出差異,其餘幾乎全面勝過對照組,而且效能損失不大。

*不過distance:-6在少戰看板處流暢度不足,大概要拉到-7 / +2才足夠(尚未詳細比較)

幾個截圖(實驗一,遮蔽level5 / distance: +3)
前面提到線條保留(右側有些線條不見了)

波紋狀偽影



\superC\Lv6 superC D-6  +3 Kantai Collection OP01 - R.mp4
\superC\Lv6 superC D-12  +3 Kantai Collection OP01 - R.mp4
左側實驗組
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:-6} [107.8fps / 108.8%]
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:-12} [102.9fps / 103.8%]
右側對照組
levels:6 -> 5 (遮蔽level 5) coarse:{type:4, distance:+3} [99.10fps / 100.0%]
*實驗組和對照組與之前比較時放置位置不同。
實驗目的
詳細比較不同參數下的表現。

實驗結果
波紋狀偽影少至多:實驗一 > 對照組 >= 實驗二
流暢度:對照組 = 實驗二 >= 實驗一

個人評分
實驗一 > 對照組 = 實驗二
雖然在這組比較中把distance:-6排在最前面,但-6在少戰測試中流暢度是不合格的,
較理想參數可能在-8~-12 / +2~+3之間,另外,對照組線條保留稍差。

----------------------------------------------------------------------------------------
2017.08.24

K:
稍微試了一下levels:6->5但覺得偽影變多
而levels:6->4,偽影少很多,K-ON!!ED2澪的頭髮好很多
但一些fast panning變差
(君名OP的1:34~37和true tears OP的0:42~44
不過我只有簡單試試
可能哪邊參數還沒弄對

A:
這樣應該流暢度會不太夠,
因為這和levels:5->4一樣,
與levels:4相比,最coarse層的lambda會差很多,
我猜,
levels:6->4流暢度會比levels:4差,
偽影會更好是可預期的。

K:
對,後來把coarse.distance設3(原本用-6)並把lambda調低
levels:6->4就比較流暢了
(但true tears OP還是有點不順

A:
之前有試過,
Lv5 superC D+3 Girls und Panzer.mp4
遮蔽level 4 且 coarse.distance:+3
結果流暢度明顯不足,distance設為+6在流暢度上的表現皆改善很多

K:
是的,要加上降低lambda才會流暢些
例如lambda:4.3,plevel:1.2

A:
後來有測試過-12,效果是比+3好上許多,但還是比levels:4; distance:+3差一些,
所以之後才會改測試遮蔽level 5,
雖然遮蔽level 5的偽影比遮蔽level 4高了一些,但流暢度也提高很多,
至於與levels:4; distance:-5比較,的確有新增一些偽影,但也少了很多偽影,
看下來遮蔽level 5; distance:+3表現的似乎比較好一些

K:
比對avs重試了一下
覺得5層的偽影沒那麼嚴重了
可能是我之前哪邊弄錯

實驗組那邊都開啟了main.search.satd
這不是會影響到效能嗎

其實我的理想還是4層的偽影
可惜它很難兼顧流暢orz

A:
呃...
其實不只是實驗組,是全部都有開啟,包含效能測試...
是我寫第一個腳本時就寫錯了,
後面全部複製貼上,所以就全錯了Orz

在測效能的時候還覺得困惑,怎麼fps好像比以前低很多,
抱歉,會盡快全部重壓。

K:
另外改了一些小地方

#稍微簡化
Function SuperHeight(int InHeight, int "Count")
{
Count = Default(Count, 15)

InHeight + (InHeight > 7 && Count > 1 ?
SuperHeight((InHeight/4)*2, Count-1) : 0)
}

#改用SuperHeight()計算遮蔽大小因為super.height會受levels.pel和full影響
blankHeight = SuperHeight(input.height) - SuperHeight(input.height, levels)
#改用AddBorders()來遮蔽
super = super.Crop(0, 0, 0, -blankHeight).AddBorders(0, 0, 0, blankHeight)

A:
感謝,
不過AddBorder不能填入yuv(0,0,0),有點可惜
雖然結果應該是一樣的XD

----------------------------------------------------------------------------------------
2017.08.25

K:
發現levels.full=false時
super.height居然是1080而不是540+270+134+66+32+16+8+4=1070
看了一下原始碼覺得用avs算很麻煩
所以改成在generate.js裡加入下列程式碼

function blankHeight(reswidth, resheight, full)
{
        var levelsmax = Math.floor(Math.log((Math.floor((
(reswidth<resheight?reswidth:resheight)-8)/24)*24+8)/32)/Math.LN2)+1;

        if (levelsmax < 3)
                return 0;

        var anaheight = 0;

        for (var i=1; i<levelsmax*3>>2; i++)
                anaheight += resheight>>i&~1;

        var levels = 0;

        while ((reswidth>>levels&~1) >= 2*2 && (resheight>>levels&~1) >= 2*2)

                levels++;
var supheight = 0;

        for (var i=1; i<levels; i++)
                supheight += resheight>>i&~1;

        if(!full)
                supheight = Math.max(supheight,Math.ceil((reswidth*resheight/2) / (reswidth>>1&~1)) + 1 & ~1);

        return supheight - anaheight;
}
avs.WriteLine("global blank_height="+blankHeight(mediaInfo.main.reswidth, mediaInfo.main.resheight, levels.full !== undefined ? levels.full : true));

然後MSmoothFps.avs改成

super=SVSuper(input, super_params).Crop(0, 0, 0,-blank_height).AddBorders(0, 0, 0, blank_height)


這樣levels.full=false時遮蔽的高度才是正確的

A:
嗯...看不懂XD
試了一下,程式碼裡面似乎無法設定遮蔽的層數,只能固定遮蔽特定層?
另外,avs.WriteLine這行無法使用,
好像是
(mediaInfo.main.reswidth, mediaInfo.main.resheight, levels.full !== undefined ? levels.full : true)
這串有問題?


----------------------------------------------------------------------------------------
2017.08.26

K:
因為預設只用levelsmax*3/4層,其他層遮蔽
可以修改(levelsmax*3>>2)改成你要的層數
for (var i=1; i<levelsmax*3>>2; i++)

例如5層就是
for (var i=1; i<5; i++)

這樣1920x1080下
anaheight是540+270+134+66=1010(不計算finest層因為它會隨levels.pel變動
而supheight會是1070(full=true)或1080(full=false)

減去anaheight就會得到要遮蔽的高度

sorry,貼成SVP3的程式碼了
SVP4改成
AVS.push("global blank_height="+blankHeight(media.dst_w, media.dst_h, levels.full !== undefined ? levels.full : true));
試試

想說來自己編譯svpflow1.dll
這樣就只要設定levels就好效能也佳
但看了一下它是用Intel C++ Compiler XE 15.0編的
手邊只有14.0版的orz

A:
改了些地方
function blankHeight(reswidth, resheight, full, unblanklevel)
(略)
        if (unblanklevel<0)
                return 0;
        if (unblanklevel==0)
        for (var i=1; i<levelsmax*3>>2; i++)
                anaheight += resheight>>i&~1;
        if (unblanklevel>0)
        for (var i=1; i<unblanklevel; i++)
                anaheight += resheight>>i&~1;
(略)

AVS.push("global blank_height     ="+blankHeight(media.dst_w,media.dst_h, levels.full !== undefined ? levels.full : true,blankHeight.level !== undefined ? (blankHeight.level) : 0));

然後再override.js加入
//blankHeight.level = 0;

這樣就可以自行設定是否使用此功能,
設為負值時關閉,0為自動,大於0則為欲保留層數,
可以統一在override.js設定。

----------------------------------------------------------------------------------------
2017.09.02

A:
這幾天針對較快速PAN的部分做了點測試,
測試並非逐幀比較,且忽視偽影,
單純以快速PAN的部分測試流暢度為主,使用24px及lambda:0.1,
因為lambda已經設的非常低了,plevel應該就可以忽視了,
因此測試結果為不流暢的,基本上就在怎麼調整參數都不太可能使其變流暢,
而結果為稍不流暢的,要調到流暢可能有些困難,
流暢臨界,表示測試時有少許不明顯的不流暢,應該還有希望依靠penalty等參數微調,
流暢的則表示,在該畫面中,SVP的流暢度不會輸給AFM丶DR。


K:
感謝這麼多的測試數據
十分有參考價值
以這份數據為基礎再來調整其他參數
相信可以節省不少時間

levels:6->5,coarse.distance:-5關閉trymany
就我的感覺也覺得這項設定比較好
distance不用設太大
lambda和plevel用預設值壓低level5的偽影

btw,我之前那份參數把pnbour設55好像有點太低了
後來還是改回65(lambda和plevel也改回預設值

A:
看的出來trymany參數似乎在提升流暢度方面的確有其助益,
但是否會增加偽影就還沒測試了。

應該會從
levels:5, distance:+1 / -2
levels:5->4, distance:+3 / -10
levels:6->5, distance:+2 / -4
這幾個再繼續測試。

K:
我覺得開啟trymany偽影還是有多些XD
而且看起來在distance很低或固定時幫助比較小

----------------------------------------------------------------------------------------
2017.09.07

K:
修改了一下blankHeight()裡levelsmax的計算
讓它跟SVP原始碼的算法一樣
這樣analyse.block就可以用不同的值了
修改後的腳本放在(SVP 4 Pro)
https://goo.gl/2wzDF8
(base.py不確定這樣改對不對

blankHeight.level我改成analyse.main.unblank
正值代表不要遮蔽的層數
負值代表要遮蔽的層數
跟analyse.main.levels類似
例如1080p時,unblank:5跟unblank:-1效果都是levels:6->5

----------------------------------------------------------------------------------------
2017.09.14

A:
感謝您提供的腳本,
測了一下應該是沒有問題(avisynth和Vapoursynth均有測試)

抱歉,
本次測試花了比較多時間,而且還沒有完成,只是個半成品...Orz
不過漏掉的部分應該多為較極端的參數,通常不太會使用
本次測試中發現,搜索半徑無節制地降低,並不見得能夠改善偽影,
尤其在快速pan的畫面,這類畫面中會有個最佳區間,超過或低於都會使得偽影增加

以下測試非逐幀比較,且不考慮偽影,使用pel:1 , 24px , algo:23
測試在保持 流暢 效果下使用的 最高的lamdba 及 最低plevel 參數(lamda解析度為0.5,plevel解析度為0.1)

原先結果為(lambda:0.1) 流暢 / 流暢臨界 的參數,
在找尋lamdba / plevel時也會要求要有 流暢 / 流暢臨界 的觀感,
方式為先保持plevel:1.5下找出最高的lamda,然後再依此lamda值找出最低的plevel
若測試結果lambda<0.5,則不會進行plevel測試。

*由於是先找出一項才去找出另一項參數,因此測試結果為局部最佳,並非為最佳組合
*標示 > 或 < 的參數,表示該項超過 / 低於測試範圍lambda:0.5~15,plevel:1.5~1.0
*原先為 流暢 與 流暢臨界 結果的參數,所採用的要求不太相同,流暢的要求會比較高
*紅底為流暢度未達標,藍色則為無法由lambda及plevel限制流暢度


部份情況下,開啟trymany後,lambda與plevel並無法有效改變測試流暢度,
加上測試標準不一致(人眼),可能會產生一些誤差。
少數幾項流暢臨界不論怎麼調整流暢度均差一點,但還不到不流暢的程度,
故暫以 ? 標示(應為pan時間太短,不易發現blend造成的)。


True Tears中levels:6->5部分參數lambda會有兩個最佳區間,
較高值在pan中會變成blend過度,較低值則是補得較連貫,
但有參數兩個最佳區間銜接良好,導致辨識困難(除非逐幀比較),
故在上表True Tears片段皆取較低值的為主。
除此之外,True Tears觀眾席快速pan片段的時間很短暫,
不易分出是否為blend,也使得難以判斷是否流暢。


部分參數會有無值的狀況,因為這些都是後來增加測試項目,
個人認定這些參數應較少使用,因此並無多加測試。(其實就是偷懶)


你的名子在之前判定流暢度時,未注意到01:40的樹叢流暢度,導致許多應為臨界流暢的參數誤判為流暢。


下一次會將你的名字片段流暢度重新測試並重新找尋對應的lambda與plevel值
...如果有時間的話 Orz

粗略分析一下上表
levels:4, coarse.distance:+2                普遍存在流暢度稍微不足情況
levels:4, coarse.distance:+3                流暢度足夠,但lambda參數似乎無法明顯抑制搜索半徑
levels:4, coarse.distance:-8~-12          不是流暢度不足,就是lambda無法抑制搜索半徑
levels:5, coarse.distance:+1~+2          不是流暢度不足,就是lambda無法抑制搜索半徑
levels:5, coarse.distance:-2~-10          不是流暢度不足,就是lambda無法抑制搜索半徑
levels:5->4, coarse.distance:+3           流暢度稍嫌不足
levels:5->4, coarse.distance:+4~+5    看起來是個不錯選擇(偽影部分未測試)
levels:5->4, coarse.distance:-11          流暢度稍微不足
levels:5->4, coarse.distance:-12~-15   開trymany看起來是個不錯選擇(偽影部分未測試
levels:6->5, coarse.distance:+2           看起來是個不錯選擇(偽影部分未測試)
levels:6->5, coarse.distance:+3~+4     偷懶未測試
levels:6->5, coarse.distance:-4            流暢度稍微不足
levels:6->5, coarse.distance:-5~-7       看起來是個不錯選擇(偽影部分未測試)

目前使用的參數為
levels:6->5,
coarse.distance:+2

補充:
levels:4,distance:+3            流暢度足夠,但lambda參數似乎無法明顯抑制搜索半徑
levels:4,distance:-8~-12     不是流暢度不足,就是lambda無法抑制搜索半徑
levels:5,distance:+1~+2      不是流暢度不足,就是lambda無法抑制搜索半徑
levels:5,distance:-2~-10     不是流暢度不足,就是lambda無法抑制搜索半徑

這幾項在調整到適當的參數下依然可以讓流暢度達到很好的效果,
並不是說無法流暢,普遍可分為兩種情況
1. 流暢度不足
2. 流暢度足夠了,但無法使用lambda和plevel來限制搜索半徑(或效果極差)

猜想後者可能就是之前調整流暢度後,lambda幾乎沒什麼效果的原因。

----------------------------------------------------------------------------------------
2017.09.16

K:
感謝測試~

從君名OP測試結果來看lambda還是要設低吧
相對於沒有遮蔽時coarsest層的local lambda為0
lambda:0.5時的local lambda還是高一些

(紅底是levels:6->5,藍底是levels:5->4)
可能因此流暢度有差

A:
當時會選擇lambda限制在0.5~15.0的原因為:
一來當然是這樣測試的量會減少很多 (但那張表還是測了超過10小時...)
其次則是把lambda降得太低的話,那有無遮蔽基本上就沒什麼差了吧?
至於上限設15.0單純就是為了省時間😋

K:
有遮蔽的話感覺偽影還是有稍微少一些些啦

K:
我現在的想法是把lambda設極低plevel設<1.0
使coarsest層local lambda接近0提高流暢度
而finest層接近原本的程度使偽影不要增加
例如:
看起來在君名和true tears那邊有幫助
可是在GuPdF那邊沒效orz
還要把pnew設低才好一點點(還是會抖動幾下

不過用遮蔽偽影是有減少的
這方向應該是沒錯

A:
忘記還有plevel<1這招
不過私心覺得plevel<1的效果可能不會比較好,
因為照過去測試經驗,levels加大偽影就會增加許多,
千方百計地想保持流暢度且降低coarse層的影響(半徑丶拉高lambda丶壓低plevel),
所以最近您發現coarsest的local lambda會被強制設為0,
我第一個想法就是,想辦法把最coarsest層給去除,
畢竟level 5每移動1像素,等於原圖移動32像素,影響不小。

K:
是的
因為levels:5->4偽影比較少但快速pan會抖動
然後lambda要降很低才有感覺
所以讓plevel<1希望不會在finest層增加偽影
而跟levels:4比
我是覺得有些地方偽影有變少些
感覺lambda還是有作用

K:
另外我原本smooth.scene={mode:0,limits:{scene:3000,blocks:40}}
可能太低了
所以levels:6->5, coarse.distance:+2沒那麼有效
可是提高scene參數又感覺有些blend
這邊還要再調整

測試中的override.js更新到
https://goo.gl/gndqQW
僅供參考

A:
忘了說測試使用的參數了,penalty保持SVP的預設值,

smooth.scene.mode                       = 3;
smooth.scene.limits.m1                  = 2000;
smooth.scene.limits.m2                  = 3600;
smooth.scene.limits.scene               = 5400;
smooth.scene.limits.zero                = 120;
smooth.scene.limits.blocks              = 52;

螢幕更新率有調成72hz,同參數在60hz下流暢度會稍微差一點,
可能要稍微降低lambda或升高plevel才會一樣流暢,
有一部分lambda最低只測到0.5也是這因素使然。

測試時開啟trymany參數後除了流暢度增加外,偽影的確有也有增加,
也許可以利用search.coarse.width來限制trymany的層數,
coarse層藉由trymany開啟來增加流暢度,
finest層關閉trymany減少偽影。

感謝您提供的參數。

K:
trymany本來對finest層就無效
coarse.width會連coarse層都減少
也許會少些偽影
但應該也會影響流暢

除了trymany外
之前試過wide search
也是能增加低levels和低distance時的流暢
(sad要設比較低較有感
可惜也是覺得偽影增加

A:
之前試的wide search讓我心裡有陰影😅

想說使用width來限制coarse層數,然後才開啟trymany,
減少trymany造成的偽影,同時提高少許流暢度,不過還沒試(冏

----------------------------------------------------------------------------------------
2017.09.19

A:
看了一些髮尾丶手指類型的偽影後,還是想不出什麼好的解決辦法...
像是,No Game No Life OVA  02:20~02:28

K:
這種可以試看看smooth.algo設回13能不能改善
但13不夠滑順...

A:
換了algo:13測試後,發現偽影變得很特別,有點類似AFM,
而且不會像23那樣在前後景速度不一時產生非常嚴重的偽影,
雖然13的偽影強度低於23很多,但出現輕微偽影的次數似乎比23多很多...
目前暫時還是轉回23使用,畫面變化比較大的番再考慮換成13。

K:
23感覺也比較滑順

A:
但感覺23似乎也很容易被鄰近幀干擾,
在變化劇烈的場景時似乎會被鄰近幀拖累,導致不流暢或偽影較多。

K:
這樣的情況下只好選擇不流暢了

----------------------------------------------------------------------------------------
2017.09.21

A:
這幾天在看search.cpp,果不其然的看不懂XD
如有錯誤還請您指正
ExhaustiveSearch的部分完全看不懂XD,
但上網翻了一些資料,猜測搜索次序應該如下(O為最佳MV,radius=4)
...........
.111111111.
.111111111.
.111111111.
.111111111.
.1111O1111.
.111111111.
.111111111.
.111111111.
.111111111.
...........
直接搜索半徑為radius的矩形區域

K:
搜索座標總數為(2*radius+1)^2

A:
Hex2Search大概看得懂一半
...........
...........
...........
....1.1....
...........
...1.O.1...
...........
....1.1...
......333..
.......
......333..

先搜索六角形位置,
然後再依最佳位置搜索半個六角形,並持續搜索下去,
直到半徑剩餘0或1時,執行ExhaustiveSearch(1),

K:
如果搜尋半個六角形沒有找到比目前更好的MV(也就是當dir == -2時)
也會停止迭代直接進入ExhaustiveSearch(1)

A:
這應該就是您之前說,在半徑為0時,HEX依然會搜索半徑1,對吧?
而且radius設為2n或2n+1的搜索區域是一樣大的(n=1丶2丶3...)不知道有無理解錯誤?

K:
沒錯,
ExhaustiveSearch(1)還是會重複搜尋九宮格中間位置
搜索座標總數為
radius=0 --> 9
radius=1 --> 9
radius>1 --> 3 + 3*floor(radius/2) + 9

A:
但UMH似乎在半徑為0時,最小搜索半徑依然為4,最大為5?

K:
對。

A:
再說UMHSearch前,有個疑問
為甚麼CrossSearch的程式碼是
void PlaneOfBlocks::CrossSearch(int start, int x_max, int y_max, int mvx, int
mvy)
{ // part of umh  search

        for ( int i = start; i < x_max; i+=2 )
        {
                CheckMV(mvx - i, mvy);
                CheckMV(mvx + i, mvy);
        }

        for ( int j = start; j < y_max; j+=2 )
        {
                CheckMV(mvx, mvy + j);
                CheckMV(mvx, mvy + j);
        }
}
為甚麼要重複執行CheckMV(mvx, mvy + j)兩次? 寫錯了嗎?

K:
絕對是寫錯啦啦啦~
居然之前都沒注意到!!!!囧rz

早上趕緊上論壇發問了
希望還沒在4.0.0.128後的版本修正
這樣之後UMHSearch的效果可能會比現在好些XD

A:
看了一下幾個版本的mvtools似乎都這樣寫(planeofblocks.cpp)
mvtools v2.5
mvtools v2.6
mvtools pmod v2.7.22
vapoursynth-mvtools
真奇怪...(照抄的?)

K:
一路下來都沒人發現...
SVP回說最新版4.0.0.136也是如此
不過UMH本來就一般不會用到
再問問看能不能改好了

A:
我先自作聰明當他寫錯好了,UMHSearch也是看不太懂

...........
.....2.....
...2.1.2...
.2.......2.
.2...1...2.
.21.1O1.12.
.2...1...2.
.2.......2.
...2.1.2...
.....2.....
...........

先執行CrossSearch,搜索 4*floor(radius/2) 個位置
然後再搜索大六邊形,搜索 16*{MAX{floor[(radius-4)/4],0}+1}
最後再以原點為中心搜索同樣radius大小的Hex2Search?

K:
CheckMV會改變bestMV
所以應該是以O,1,2中最佳的位置為中心執行Hex2Search

A:
...........
.....2.....
...2.1.2...
.2..3.3..2.
.2...1...2.
.2131O1312.
.2...1...2.
.2..3.3.42.
...2.155..
.....545..
......555..

這樣一來不是會有重複位置被重複搜尋嗎?(深紅色處)

K:
如果1,2都沒比O好就會這樣
否則的話有可能會跑得很遠
例如
...............
.....2.........
...2.1.2.......
.2......323.4..
.2...1...2..555
.21.1O1312.3545
.2...1...2..555
.2......323.4..
...2.1.2.......
.....2.........
...............

A:
所以,使用UMH搜索時,
radius設為0,實際上水平丶垂直方向最遠可以搜索到5px這麼遠?



K:
從程式碼來看應該會是這樣沒錯

radius大於2後UMH搜索位置數應該就少於EXH了

             EXH        UMH
radius=1 --> 9           16 + 9 = 25
radius=2 --> 25         4 + 16 + 6 + 9 = 35
radius=3 --> 49         4 + 16 + 6 + 9 = 35
radius=4 --> 81         8 + 16 + 6 + 3 + 9 = 42
radius=6 --> 169       12 + 16 + 6 + 3 * 2 + 9 = 49
radius=8 --> 289       16 + 32 + 6 + 3 * 3 + 9 = 72

我在想會不會是refine的關係
同樣radius下EXH找到的MV比UMH佳
SAD剛好低於refine的閥值
不用refine所以比較快

不然能得到全域最佳值的EXH比只能得到局部最佳值的UMH還快
怎麼想都怪怪的XD

A:

剛測了一下,(關閉refine)
finest.distance:2時,EXH比UMH還快
finest.distance:3時,EXH比UMH還慢
回想一下之前測試的對比差異,
finest層的確對比分布幾乎趨向0,
那UMH比EXH慢的因素應該是這樣吧?

K:
應該就是這原因了

A:
對了,似乎可以用這特性來找出整部影片中的對比期望值,
藉由改變自適應搜索半徑找出UMH比EXH還快的最小|自適應半徑|,
此時的平均搜索半徑約為{[√(35)]-1}/2 = 2.458
再計算 2.458/|自適應半徑|,就大概可以抓出對比期望值了。

K:
這想法感覺蠻有趣的~

A:
之前測試過finest層distance:-8,UMH比EXH慢,
所以finest層自適應半徑-8的平均搜索半徑還不到2.458px。
當時測試結果HEX(102%) > EXH(100%) > UMH(92%)
推算搜索位置量比約為 98:100:109,
因此平均搜索半徑應該介於 1~2之間,
這比refine預設的dintance還小,調整refine沒什麼效果大概也是因為這樣?

K:
refine感覺還是能增加滑順
就用預設值就好

A:
而levels:4, coarse.distance:-5,UMH也比EXH慢,
因此推估coarse層自適應半徑-5,平均搜索半徑不到2.458px。

K:
所以快速pan場景增加levels或改用固定半徑,wide search等
比調高自適應半徑來得有效

A:
我目前暫時先用固定半徑來搜索,試試看效果如何。
感謝您對搜索方式的說明,受益良多。

K:
也感謝你發明了遮蔽的方法讓偽影可以再減少
以及發現了程式碼中的bug
這些都是別人沒有想到的~

----------------------------------------------------------------------------------------
2017.09.22

A:
algo 13

 algo23


地上石筍的偽影23明顯很多,而且難以去除...
另外硬字幕的部分也會明顯一點。

試了一下,
流暢度:23 > 13
偽影表現:13 > 23 (23的偽影多很多,最後是把網格改28px抑制偽影)

調整了兩組參數,
algo 13那組提高流暢度為主,
23的則是降低偽影,
不知道您方不方便試一下?
https://goo.gl/PMdY5V

這兩組均有在60hz下調整過,
所以應該會比之前72hz的參數套用在60hz上流暢一些。

P.S.
直接把72hz所調整的參數套用在60hz上,
不僅流暢度稍嫌不足,偽影也變多了。 冏...

猜測可能是72hz流暢所需的搜索半徑較低,所以比較流暢,
偽影的部分則是原影片所占時間比例較高,畢竟72是倍數播放,補的少偽影自然少。

K:
只測了幾個片段來比較

君名NCOP
5秒開始那邊algo13稍稍沒那麼滑順
46秒那邊瀧身上的偽影algo13比較不明顯
50秒開始那邊algo23感覺比較滑順一點點
1分34秒開始兩個天空都很滑順
1分39秒那邊algo23三葉的手有一些些偽影

true tears NCOP
兩個差不多
沒有什麼問題

DxD NCED
9秒開始那邊兩個都很滑順
20秒開始那邊algo23比algo13滑順些
57秒鋼管舞那邊algo13的殘影比較多比較模糊

個人比較偏好algo23的表現

----------------------------------------------------------------------------------------
2017.09.26

A:
這幾天測試出一些結果,
coarse.satd:false的流暢度比true好一些,
SAO OP 00:24 右側地磚很明顯關閉SATD流暢度會比較好

K:
可能像trymany一樣
在某些情況下改善
但還是要看會不會影響大部份

A:
對,簡單比較了一下,
SATD 偽影少一點,但流暢度稍差,SAD剛好相反,
全部都用SAD偽影有點多,
目前coarse用satd,finest用sad,再使用width微調作用層。

A:
動畫類型的片頭/片尾曲在複雜畫面時SAD值很容易破20000,
DXD 00:10時,有超過20%區塊的SAD破20000,大概是動畫描邊的因素讓SAD飆高吧?
這樣的話,penalty.lsad也許可以稍微升高,降低偽影?

K:
lsad倒是沒研究過

A:
以及,有個參數搞不懂他的意思,search.sort
看官網說明好像是會依高層次的MV結果來排序搜索順序,
但不是都會搜索嗎?排序搜索順序有甚麼意義呢?

K:
doom9上找到的說明
https://forum.doom9.org/showpost.php?p=1567553&postcount=10
應該是對pnbour有幫助

A:
感謝您的資料。
試著調了pnew,只發現調高會變不流暢,
調低或預設值附近,有變化,但沒發現何者較優,目前還是回復預設值。

It prevent replacing of quite good predictors by new vector with a little
better SAD but different length and direction.
回去看說明後,感覺與sort最相關的參數應該是pnew。
由於sort會將搜尋順序重新排列,
pnew因此後搜索的SAD必須優於排列在前面的MV (SAD + SAD*pnew/256)
在algo 13測試下,pnew調高或低都沒有明顯影響(當然過高會變不流暢),
所以才會說沒什麼效果,但這是在algo 13測試所得,
現在換測試algo 23中,
有發現略為增加pnew,可以減少可觀的偽影數量,
但不建議pnew超過70,會有流暢度下降的情況,
目前還在測試,猜測較佳值應為60~65左右(algo 23時)
且plevel也不建議大於1.5(Algo 23)偽影會稍多,
而algo 13下的plevel略加1.6~1.7倒可以增加流暢度,偽影影響也似乎不太大。

K:
pnbour是指以鄰近8個已搜尋過的區塊中SAD最小的MV
原本MVTools是逐行搜尋
所以8個鄰居中有4個是搜尋過的
例如上圖要搜尋X區塊
白底是已經搜尋過的
所以找它鄰近的ABCD中SAD最小的當做X的預測MV

而SVP的sort是指將逐行搜尋改成依照上一層的結果
先搜尋那些SAD小的區塊
所以X不再受限只能找ABCD
而是8個鄰近中較小的都搜尋過了
可以以其中最小的當預測
預測MV的SAD應該是會比沒有sort來得小

----------------------------------------------------------------------------------------
2017.09.29

A:
algo13下不建議開啟trymany,
開的層數少就不夠流暢,開的層數多偽影也跟著多,
還不如直接拉高levels...

K:
在想trymany是不是能搭配特別的penalty來減少副作用
但人工下去試實在很沒效率又不準

A:
而且不同動畫效果也會差很多,
主角群有著飄逸頭髮的動畫,表現都不怎麼樣...
這幾天看了一拳超人,表現還滿不錯的,
原本以為這類戰鬥番表現會差很多,難道是因為主角禿頭(?

人工測試真的很沒效率...
這是目前調出來algo13低偽影參數,缺點就是流暢度有少許犧牲
https://goo.gl/wRNpc6

在algo 13下比較容易發現參數對於流暢度的影響,對於偽影影響就感覺很小,
在algo 23就剛好相反,對於會對偽影有所影響的參數比較容易被觀察。

----------------------------------------------------------------------------------------
2017.10.06

A:
這幾天調整了algo23下的參數,
無意見發現SVP 4在輸出59.94fps時threads=15,
但輸出71.928fps時,threads=17。

K:
原來會跟輸出fps有關
不過覺得thread多不見得能比較快

A:
恩,之前有測試過,thread到一定值後就很少有提升了,
再高甚至會有所降低,SVP預設值就不錯了

A:
analyse.main.unblank                    = 5;
analyse.main.levels                     = 6;

#HEX丶UMH丶EXH在finest層感覺不太出來差異
#UMH似乎感覺比較差一點,但可能是因為實際搜索的範圍較大
analyse.main.search.type                = 4;

#finest層搜索半徑小一點似乎有助於抑制偽影
analyse.main.search.distance            = 2;

K:
理論上這樣finest層的SAD會高些
refine會跑比較多
不過經過前面那麼多coarse層的搜尋
半徑應該是不用那麼大就能找到夠好的MV

A:
#coarse層用EXH表現較佳
analyse.main.search.coarse.type         = 4;
analyse.main.search.coarse.distance     = 3;
analyse.main.search.coarse.bad.range    = 0;

analyse.main.penalty.lambda             = 2.8;

#pnew略為增加可以抑制偽影
analyse.main.penalty.pnew               = 65;
analyse.main.penalty.pnbour             = 70;

#重新調整smooth.sccene參數
smooth.scene.limits.m1                  = 3000;
smooth.scene.limits.m2                  = 4500;
smooth.scene.limits.scene               = 5000;
smooth.scene.limits.zero                = 150;
smooth.scene.limits.blocks              = 50;

晚些會再測試levels:5->4的參數。

K:
我之前5->4的參數在某些pan會變頓
尤其是真人電影
常常順<->頓切來切去
雖然偽影少了但這樣還蠻影響觀影興致
還需再調整

A:
這幾天改成5->4也有發現同樣情況,
部分快速PAN表現下降許多,
目前有3種解法
1. 暴力加大coarse層搜索半徑
        analyse.main.search.coarse.distance     = 5;
2. coarse層改用SAD搜索
        analyse.main.search.coarse.distance     = 4;
        analyse.main.search.coarse.satd         = false;
3. 使用trymany(可減少些搜索半徑)
        analyse.main.search.coarse.distance     = 3;
        analyse.main.search.coarse.trymany      = true;
        analyse.main.search.coarse.width        = 525;
其中似乎1.和2.的偽影比較好一點,還在測試。
或者加大影片大小,做6->5?

K:
1.怕會增加太多偽影
2.怕在fade-out場景效果變差

A:
目前是改成以下這樣測試
coarse層用SAD搜索 + trymany,
finest層用SATD搜索,
refine層的thsad略為提升至1000

A:
另外,
refine層的satd等參數是可以單獨設定的,實際上也有效果,
至少refine層開啟satd後會增加資源消耗。

K:
這幾天只有筆電能用
i7-3630QM連finest層都跑不動orz

----------------------------------------------------------------------------------------
2017.10.08

A:
針對快速PAN的部分調整參數
左方參數意思如下
// levels/ coarse.distance(-badrange)/ finest.satd(coarse.width)/coarse.satd (-Trymany)(lambda)(plevel)ExtPAN

//5->4/c.d 3/sad1050/sad-T  2.6 1.6 ExtPAN;
意思為
levels:5
unblank:4
coarse.distance:3
bad.range:0
main.search.satd:false
coarse.width:1050
coarse.satd:false
coarse.trymany:true
lambda:2.6
plevel:1.5

右方的分數(偽影部分)
        0 - 很爛
        2 - 有點差
        4 - 普通
        6 - 不錯
        8 - 非常優秀



lambda對於偽影影響滿大的,尤其是當lambda低於1.0時,普遍表現都差,

上表中表現最好的是
//5->4/c.d 3/sad1050/sad-T  2.6 1.6 ExtPAN; 這組參數,
後來發現在部分畫面中開啟trymany會有滿明顯的干擾,
以及降低些偽影(犧牲少許流暢度表現)
目前參數改為

analyse.main.unblank                    = 4;
analyse.main.levels                     = 5;
analyse.main.search.type                = 4;
analyse.main.search.distance            = -3;
analyse.main.search.sort                = true;

#finest層開啟satd後稍微好一點,但不開的話可以節省非常多資源
analyse.main.search.satd                = true;
analyse.main.search.coarse.type         = 4;
analyse.main.search.coarse.distance     = 3;
analyse.main.search.coarse.satd         = false;
analyse.main.search.coarse.trymany      = true;

#減少trymany作用層數
analyse.main.search.coarse.width        = 525;
analyse.main.search.coarse.bad.range    = 0;
analyse.main.penalty.lambda             = 2.8;
analyse.main.penalty.plevel             = 1.50;
analyse.main.penalty.pnew               = 65;
analyse.main.penalty.pnbour             = 65;

*若finest層使用sad,那以上參數甚至可以跑4K影片

K:
看來主要是coarse.width=525能減少trymany的偽影
但從上面表格來看也會增加一些偽影(還是是lambda低的關係?

A:
有可能是特定參數造成的影響,
原本也以為coarse.width=525能夠減小trymany的偽影,
結果偽影的確不減反增...

另外在測試過程中有發現在遮蔽coarsest層(levels:5->4)後,
同coarse.distance下,
流暢度的關鍵是level 3層的lambda值(剛好就是遮蔽後的最Coarse層),
因此遮蔽後在快速PAN時流暢度會大減~"~

即便是加大plevel,
讓level 2的lambda降低也無法明顯提升快速PAN下的流暢度,只有明顯增加偽影...

K:
所以要提高lambda降低plevel嗎?
其實levels:5->4的偽影我已經很滿意了
只是在真人電影快速pan不會補幀算缺憾

A:
對,換句話說,
plevel壓低可以改善偽影,
且只要最Coarse層的lambda保持一樣,
那就可以幾乎維持相同流暢度,同時壓低偽影,
但低於plevel:1.3就沒測了,不能保證。

K:
因為遮蔽所以coarset層lambda不為0使得偽影減少些
plevel降低=提高coarse,finest,refine層的lambda使偽影再減少些

btw,在原始碼看到refine層的lambda固定是finest層的1/4

A:
plevel降低的同時,lambda也要同時降低,才能保持接近的流暢度,
不過coarse~finest的local lambda是呈指數遞減的,
所以plevel降低後,finest層的半徑會擴張得較慢。

感謝告知~

K:
可以訂好coarest層和finest層的lambda要多少
讓腳本透過公式算出penalty.lambda和plevel

A:
之前測的結果和表格滿接近的

plevel大一點時,local lambda有略大一些,但差不到10%

K:
另外SVP4好像可以設定Width of top coarse level來調整coarse.width
可是從generate.js看不出來有作用
得改天安裝回4確認一下了

A:
剛測了一下,
這項不論設為多少,腳本都沒有變化,
播放4K影片下也沒有改變,不知道是哪裡弄錯了。

K:
應該是bug
上論壇反應一下吧
----------------------------------------------------------------------------------------
2017.10.12

A:
連假時測試,終於有發現refine的差異了,
是說一直一來我都沒有逐幀比較過refine的差異,
因為一直覺得2px能有甚麼差異,就懶得去逐幀比較...冏
這幾天發現refine所造成的差異似乎比refine.distance還要差的還要多,
(不排除是特定參數下造成的特定變化)

由於這幾天在測試快速PAN畫面的適用參數,找了個快速PAN很多的OP來測試,
紀錄的地平線二期OP
剛好在此片中 00:03~00:06對於當時的測試參數來說,會產生很多偽影,
在測試中發現refine.thsad越低,偽影越嚴重


其中線條扭曲的部分,看起來差異超過refine.distance的2px設定

由於該參數在finest層有開啟satd,而refine沒有開啟,
推測可能是refine.thsad過低導致較佳的區塊被取代,
不過,若refine.thsad偏高,對於流暢度也會有影響,
本次測試下,700~1200似乎是個較佳值,
低於600偽影較多一些,
大於1500會明顯降低流暢度。

K:
finest層不開啟satd且refine.distance只有1似乎也會像右邊

A:
後來測試結果是特定參數下造成的特定變化,
其餘參數下,改變thsad似乎就沒這麼明顯,
倒是實際移動量大於refine.distance這點可留意下。

K:
各參數之間會互相影響
這樣實在很難測試找到好的模型啊orz

A:
對阿~
不過覺得偽影和流暢度的平衡更難抓XD

K:
其實24fps動畫應該要看是一拍二還是一拍三轉成12fps或8fps
再下去補幀會更滑順XD
只是當前後景速度不一樣就沒轍了

A:
目前SVP只能搜尋前後幀,
要處理一拍二丶一拍三不太可能啦XD

K:
所以只能先手動處理再給補幀
像下面這張我只能補到這樣的滑順而已
https://imgur.com/LHlFTNX
網路流傳超滑順那張我猜是用twixtor做的

A:
這張也很滑順了呀,真厲害

K:
如果動畫製作公司也加入補幀技術
我們就有全動畫可以看了
(前提是沒有偽影的話XD

A:
對了,後來逐幀看,不同參數下,
拉高thsad還是可以遮掉少部分較為嚴重(移動較遠)的偽影,
不過這項太高也會影響流暢度就是了。

K:
原來如此
也許refine設高thsad+高distance可能更好

A:
此外,
SVP的使用CPU渲染似乎有點問題,
之前就有覺得SVP如果使用CPU渲染的話,感覺就會頓頓的,
一樣的PAN下,使用GPU或mvtools處理就不會有這情況
測試使用影片:艦隊收藏OP  00:17~00:25

K:
這邊就沒有原始碼能確認了
也許又是bug
不過SVP的CPU渲染速度似乎比mvtools快多了?
可能是靠犧牲品質來換取速度

A:
好吧,
不然滿可惜的,畢竟用CPU渲染可以避開黑邊偽影的問題。

----------------------------------------------------------------------------------------
2017.10.16

A:
這幾天試了些參數,
在levels:5->4下,沒半組參數可以達到滿意的程度...
之前測試結果
trymany + width:1050的偽影比trymany + width:525還少,
後來測的結果有點變化,
把plevel降低後,後者的表現反而比較好一點,
加上之前多為測試OP,有的參數在正片時的效果會不太一樣,
像trymany,
在片頭時開啟,可以增加流暢度,偽影也不算太明顯,
加上通常片頭快速PAN的機率也不低,我覺得是可以開的參數,

但到了正片階段時,開啟trymany後的偽影就變得比較明顯些,覺得不太能夠接受,
coarse層使用SAD搜索倒是可以一試,搜索半徑有大一點,偽影還在接受範圍內。

K:
在想開啟trymany就是搜尋那些predictor週圍coarse.distance距離
沒有開啟就只搜尋predictor本身
也許保持coarse.distance但限制trymany範圍+1~+2
能找到更好但又不會太遠的MV增加滑順但不會導致偽影

A:
trymany的範圍能夠限制嗎?

K:
除非改原始碼了
MVTools也不能自訂trymany的範圍

A:
考慮了一下,
本來參數就會有所取捨,
之前總是想把參數套用在所有的情況下,
但這根本不可能...

----------------------------------------------------------------------------------------
2017.10.19

K:
可是有可能一集動畫前面用紙片人風格搞笑
後面用3DCG做機人格鬥
總不能看到一半還要切換參數
我是覺得只能先找在所有情況下偽影都能接受的參數(像之前官網上的動畫參數
再將補不好的場景以維持偽影為目標慢慢改善
如果怎樣都會導致其他場景偽影增加就放棄改善該場景的滑順
不過想想光是找到基礎的參數就很難了orz

A:
會這樣說是因為這陣子遇到這部影片
Log Horizon 2 OP01 00:55~01:05

這段要調到流暢,要犧牲很多片段的偽影量
一直在考慮要不要追求這段的流暢度,還是直接就放棄這段?
所以之前才崩潰的說不可能一種參數套在所有情況下XD

K:
我想只要不像之前破爛熊看板和君名OP的pan那樣變成抖動和破裂
能直接放棄補幀維持原幀率就好
至少影片原本就是那樣嘛

類似的還有像冰菓11話聊天室那種背景空白只有字體的pan
要滑順就是增加level增加distance=>偽影變多
不補幀參數要調低=>不補幀的片段變多了,影響觀影
這種連想放棄都很難orz

A:
自從偽影可以壓低之後,就又開始追求流暢度了,
要求越來越高XD

K:
看來SVP也發現那個問題了XD
http://www.svp-team.com/forum/viewtopic.php?pid=66567
    with top of coarse level
actually, it doesn't work as it should, will be fixed in the next release

A:
希望能早點修好。

這幾天測試,
levels.scale.down    = 1;
這項好像設1的偽影比0 2 3 4還要少的感覺,

K:
會差很多嗎?

A:
逐幀看了之後發現差異還不小,
但分不太出來哪個更好,不過目前也試的不多,
提供幾張差明顯有差的截圖









不知道SVP是怎麼分析不同level的,

K:
應該只有分是coarse層還是finest層

A:
在比較不同縮小法時發現,
0 1 和 2 3 4的位置不同,不知道會不會對於搜索結果有所差異

畢竟在高層次帶來的影響可能不小,

K:
從SVP預設用4來推測
不知道是不是縮小後越模糊越好
一般影像處理是會分成低頻(coarse)到高頻(fine)
而且不一定要每層縮小1/2

A:
mvtools v2.7.23內的MSuper,
不論縮小法為何,縮小後都不會有偏移的情況,

比較了一下,
levels.scale.down = 2丶3丶4 均與MSuper位置相同,
可能是0丶1的位置偏了吧?

雖然SVP這項預設為4,但MVTools這項的預設為2,

我猜,
越模糊越容易找到,但是越銳利越容易找對

因為越模糊,區塊SAD差異會越低,加上越遠cost越高,
應該會容易找到次佳的的位置,
越清楚則因為區塊SAD差異高,會比較容易找到最佳位置,
也可能剛好最佳位置為+5,但因為搜索半徑僅有4,而錯過最佳點,
但夠模糊的情況下,+4位置的SAD也夠低,因此選擇+4位置。

K:
嗯,很合理的推論
畢竟物體不會只有單純的位移
加上旋轉放大縮小等變形
模糊一些還能濾掉一些雜訊

A:
另外down:4有些問題
在1080P影片level 5的時候右側有奇怪的綠色,

我不確定這是否會對於搜索結果會有所影響,
雖然對現在的參數levels:6->5或5->4影響應該不多,(畢竟level 5被遮掉了)
但SVP預設參數應該會有影響。

K:
應該是因為YUV420的UV是次取樣
https://en.wikipedia.org/wiki/Chroma_subsampling#How_subsampling_works
顯示時邊緣會吃到一些旁邊的顏色(UV都是0記得是綠色,都128才是白色
不過這應該不會影響
因為是YUV分別搜尋而不是先將UV做upsampling轉成RGB

A:
前幾天說CPU渲染感覺鈍鈍的,
逐幀觀看後,發現是CPU渲染有輕微Blend的情況,可能是這因素造成的吧

局部比較

K:
不知道MVTools會不會也如此?

A:
不會,
只有SVP的CPU渲染才會這樣

K:
好吧,那只能認為是SVP的渲染怪怪的了
要轉檔還是用GPU渲染或MVTools

A:
另外,
想請問一下像是之前巴哈動漫瘋那種24p->30p的影片 01233 45677
有看到您說可以使用TIVTC去除重複幀,是要如何使用呢?

有把TIVIC整合進SVP4腳本裡面,也測試過可以穩定運作(x64),
但只使用tdecimate(mode=1),發現很容易就除錯幀呀,
像是變成 0133 4577 這樣,
mode=0 1 2都是這樣,mode=7倒是好一點,不過還是有問題的。

K:
這我就不曉得了
如果週期固定也可以用SelectEvery()就好

A:
有試過,不行
跳轉後就失效,大概有1/5的機率會成功XD

K:
我猜因為串流是分成很多個小片段
每個片段分別過帶所以造成週期不一致

A:
不過巴哈動漫瘋現在不是重複幀了,變成Blend,這樣一來TIVIC就沒用了吧XD

K:
後來就直接在網頁上看看而已
沒注意到訊源反而變更糟了XD
數位電視和BD都出那麼久了
居然還在提供telecined訊源
該不會是片商故意的怕被人拿去利用吧XD

A:
之後又去看了其他幾片,
只有部分是Blend(EX:為美好的世界獻上祝福),
其餘還是重複幀的居多,抱歉

----------------------------------------------------------------------------------------
2017.10.25

K:
新版generate.js只是讀參數填到avs
所以Width of top coarse level的Large,Average分別對應多少值
還是要裝SVP4Pro來看

A:
1050丶530丶260
一更新就測了XDD

K:
看來是1050/N取四捨五入到十位數XD

A:
另外,遮蔽最coarse層後常發現以下這種情況

頭髮局部出現Blend的情況,看了很礙眼,
還在找辦法解決。

K:
blend其實還好
如果是wavy的話更醜更顯眼

A:
這種情況的畫面看起來會很奇怪,
因為人物身體是連貫的,
但頭部(或頭髮)會跟不上(或超前)身體移動速度,
看起來類似這動作


總感覺很好笑XD

K:
wavy就會這樣
也許用shader 13th有motion blur會看起來不明顯些

A:
原來這是Wavy呀,我以為是指波浪狀偽影@@

K:
是我把這稱做Wavy啦
應該是有些區塊有找到MV但有些沒有
所以原本的線條就被扭曲成波浪狀

A:
有試過把SVP著色器改成13.,但改善很小,目前還在試,
應該是把最coarse層遮起來之後造成的,應該說是代價嗎(?
雖然並不算很常見,但每次出現都超明顯,
有的番全季都不太會有,但有的卻幾乎每集都有...

K:
我覺得反而是層數多的關係
如果levels=3也許就能改善
但滑順度也會嚴重下降

A:
測試過,這類畫面以下兩種可以有效改善
algo:2
或者取消遮蔽層

K:
我以為algo:2沒有blur反而會比較明顯說
不過如果取消遮蔽有效也許是搜尋範圍不夠的關係?

A:
可能我本身對於Blend畫面比較敏感吧,
以前不用23也是因為Blend比較明顯,
algo:2不會產生Blend,而是波浪偽影,加上最近參數把偽影壓到滿低的,
所以algo2產生的偽影反而沒這麼明顯,
應該是搜索範圍不太夠的因素。

A:
這幾天發現pzero拉高對於流暢度及PAN都有改善,
而且可以拉高不少,偽影增加的量不多,目前是設140。

K:
原始碼svpflow1-src.zip也有更新(為何不放在github上啊
比較新舊版差別就是更新日誌提到的
我想影響應該不大
CPU有支援AVX512的可能會快一些
不過svpflow2.dll也有更新不知道改了啥

A:
AVX512,現在只有X299平台的處理才有吧Q_Q

花了幾天,終於把SVP自動除幀的功能弄好了~
不過只有在SVP 4測試,SVP3不知道有沒有問題。

K:
很棒的功能
可以考慮提供給SVP讓他們加進去
記得SVP3就有個選項
設了會在avs中加入SelectEvery()
另外25fps不是不用刪幀嗎?

A:
這功能主要用於不正確處理的原生23.976影片上,
如果觀看的影片均為處理適當的影片,
開啟這功能反而會有不少缺點,
畢竟很多電視節目都30fps,
會把25fps列入處理的因素是,
不知道為甚麼Youtube會有壓成25fps的24fps影片,
想說處理過程都差不多,就一併加進去了,
SelectEvery()對於這類及時刪幀沒甚麼幫助,一跳轉就會有問題,
不過如果是轉檔,且重複幀有規律,那SelectEvery()的效果就是最好的了

K:
那功能通常用不到
我之前是將generate.js裡的SelectEvery()
改成我要的功能
這樣一來就可以用SVP的介面切換不用改腳本

A:
了解,沒想過可以這樣改。

A:
雖然腳本是用Decomb,
不過其實TIVTC的效率比Decomb好一點...

K:
畢竟Decomb比TIVTC還要早
更早之前就只能手動了

A:
有去doom9找類似的腳本,
但似乎更麻煩,
找到一樣畫面後,給mvtools轉成一半fps之類的,
而且不太適合用在手繪動畫上。

----------------------------------------------------------------------------------------
2017.10.29

K:
因為特價就衝動刷了一台43吋4K螢幕
不過主板沒有DP
所以打算買張1050Ti
希望它能跑得動補幀+升頻...

A:
顯卡部分補幀應該沒問題,可能應該會卡在CPU運算上面,
不過改成algo21可以省很多資源,
升頻的話,就不確定,畢竟沒4K螢幕可以測試,
不過現在很多電視都有內建補幀(有的還關不掉),也可以試試效果

K:
後來覺得要將1080p 60fps的畫面用NGU升頻到4K
還是改買1060 3GB(俗稱1059)比較保險(貴了快2000...
這兩天實際用起來果然顯卡內建的升頻很差
用NGU Standard (med)線條就好多了
可是果然很吃GPU,約60%以上

A:
不管顯卡買多好,madVR保證都能可以負載100% XD

K:
只是想在4K上看1080p像在原生1080p螢幕看一樣而已呀orz

K:
另外顯卡有了HEVCM10硬解
4K君名用我之前非遮蔽版的參數在4790上還是跑不動orz
拿掉refine勉強可以
可是有遇到播沒多久畫面停止只能強制結束程式orz

雖說畫面變大爽度增加
可是補幀效果感覺沒小螢幕時那麼好
原本的偽影也變明顯多了orz

A:
4K要處理的資料量多不少,而且片源也少,
我也只有君名和言葉之庭,想測試也有難度~"~

K:
如果先降成1080p再處理資料量就少很多了
所以我想瓶頸應該是finest層和refine
不如放棄這兩個然後調高coarse.width讓1080p那個coarse層也能跑到

----------------------------------------------------------------------------------------
2017.11.05

A:
拉高coarse.width,讓1080p那層不做satd運算,降低運算量?

K:
是像main:{search:{coarse:{width:2100},distance:0},levels:5},refine:[]這樣
搜尋到4k的1080p那層就好,finest層(2160p)和refine都不搜尋
倒是忘了coarse層都是satd
這樣可能還是跑不動orz

後來有再跑一下君名4K
目前是一開始會狂掉幀
掉了600幀左右後就會穩定些
但4K@30fps的應該還是不行

A:
以Motion Vector precision: 2 pixel方式處理?
這和64px不是很像嗎XD

K:
跟64px應該還是有差

A:
coarse層和finest層應該只有差在搜索方式丶satd丶sort丶trymany丶badrange吧?
如果都設一樣的話,finest和coarse應該是一樣的?

K:
從程式碼來看應該是差不多
但我覺得coarse層還是用satd比較好

A:
前幾天有拿Waifu2X升頻至4K的影片來補看看,結果偽影超多XD
block拉到32也沒甚麼改善,如果不用64px的block,應該很難改善(?
不然只能增加levels層數量,
然後把finest層的搜索半徑關閉或設為極小,refine層關閉,
偽裝成64px,應該就可以降低很多運算量了,效果可能和在1080p類似?

K:
照經驗來看我想增加levels可能只對流暢有幫助而無助於偽影
64px我也想試試
等越來越多人看4K說不定就會實作了

A:
隔壁的mvtools都實作64px了Q_Q

K:
不過現在兩邊程式碼可能差很多
看svp-team要不要花時間整合回來了

A:
如果SVP可以把64px加進來的話,
4K影片用的參數應該就可以沿用1080p的部分成果了,
不然重找好麻煩XD

K:
所言甚是~
也想試試64x32px的效果

A:
我的意思是下表這樣,
用降解析度的方式將32px偽裝成64px,因此需要增加levels

K:
我的腳本原本4K就會比1080p多一層
btw,1080p是沒有level 6的

A:
對了,有幾個問題想請教您

這是SVP內關於local lambda的說明,
Let the finest level number is 0 and we've got N levels total
<local lambda value at level K> = lambda * 1000 / (plevel^(N-1-K))
根據這公式,N對於local lambda也會有所影響,
那是不是代表遮蔽1層和遮蔽2層的效果會有差異呢?
像是 6->4 和 5->4
不過就我自己的感覺,兩者在流暢度似乎沒有太多差異

K:
列表來看比較清楚
24px時1080p的N=6

unblank:4,levels:6和unblank:4,levels:5效果應該是一樣的
只是後者可以少1層搜尋(但我覺得節省不多啦

另外一提720p的話N=5

N不同只對finest層有差

A:
想問的是,
"N"是固定的,還是levels指定的,
因為如果是levels指定的,那levels:6->5和5->4就會有差了吧?

K:
是固定的
由影片解析度和block決定
可以參考levelsmax的計算方式

A:
請問一下,如果block是16px,1080p就會有level 6吧?

K:
是的
block是16px,14px,12px的話1080p都有level 6(也就是N=7

A:
以及當亮度為0時,SVP是不是就不會進行運算了呢?
前幾天測試發現似乎把最coarse層的Y去除,僅保留UV層,
補出來的效果和遮蔽最coarse層差不多,
但只要Y層只要有一點資訊,就會差很多(明顯有變化)
像下面這樣,Y層只保留0.5%就有差異了
superY = ExtractY(super).ConvertToYV12()
superO = Overlay(super, superY, opacity = 0.995, mode="Subtract")

K:
SVP不會先看是不是亮度為0才決定要不要運算("看"就是個運算了
應該是UV的變化不大所以效果差不多吧
可以用mt_lut(y=-128)看看UV的變化

A:
恩,感謝您的說明,
那應該只是單純UV變化太小吧,畢竟本來UV變化就比Y小很多。

A:
還有個Avisynth的用法想請問,
之前在寫自動除幀時有發現個插件似乎可以用上,
ApparentFPS 可以計算當前幀率
http://avisynth.nl/index.php/ApparentFPS
裡面有個功能是可以把計算出來的值導出
string  Prefix = ""
     Prefix for returned Local vars.

不過我弄不好,
ffdshow_source()
ApparentFPS(FrameRate=5.0, DupeThresh=1.5, Prefix="P_")
Subtitle(string(P_ApparentFPS), size=36, align=2)
一直返回 0.00000,不知道是哪錯了。

K:
照他的範例
http://forum.doom9.org/showthread.php?p=1698788#post1698788
改用RT_SubTitle("%6.3f", P_ApparentFPS)試試?

A:
還是讀不出來


K:
他沒有給x64的dll
然後改用S_ApparentFPS.avs還是卡在沒有x64的GScript...orz
如果不要用ffdshow呢?

A:
也是不行,我認輸Orz

K:
看了一下他的範例有加上AssumeFPS(250.0)
不知道會不會有關?

A:
也是沒作用,依舊顯示0.000

A:
另外,
昨天測試發現做去噪處理後可以提高流暢度,
大概是SAD降低,影響到scene.limits的判斷,
雖然理論上應該也要降低finest層的偽影,
不過沒有感到什麼巨大差異(可能試的還不夠多),

用的方式是 SBR降噪(對噪點層降噪)
先去噪,得到A畫面,
以 原圖-A ,得到噪點層B,
對 B 做5*5的平均,得到 降噪後噪點層C,
再把 A + C ,穩定噪點,最後再送進SVSuper處理,
SVSmoothFps則輸入原圖,保留畫質。

*如果用7*7似乎會增加找錯的機率

K:
這對乾淨的片源會有效嗎?
或者是否提高scene.limits就好?

A:
噪點多的片段效果更明顯,不過原先少噪點的片段也有效,
大概是降低為了去色帶所做的dither影響,
而且大概是sad降低,
除了scene.limits可以壓低,流暢度還不會降,
refine.thsad也可以降低,增加流暢度,

K:
我覺得雖然這樣可以使補幀變多增加流暢
但如果搜尋到的MV不好反而會導致偽影或直接用blend去補

A:
當時是看到這篇,才想說把SBR整合進來

節錄自https://goo.gl/hnuC7L,作者: mawen1250

prefilter處理過的clip是用來進行Motion Estimation的,
噪點會干擾ME的正常進行所以需要用一個預處理過的clip進行ME。
prefilter方式的選取就很重要,除非是特別強的噪點,一般只推薦純spatial的降噪,
因為用temporal降噪產生的blending會影響到ME結果的正確性。
...(略)
用於快速去除噪聲,比起MinBlur我更推薦SBR,
所以可以用GrainStabilizeMC裡5x5或是7x7的GSMC_sbr()作為prefilter。

在prefilter效果足夠好的時候,再調整thSAD、thSCD之類的參數,
就可以只生成一個足夠精確的ME結果...(略)

K:
這串看起來是在討論壓片?
可是怎麼會提到mvtools?

A:
因為SMDegrain本來就是從mvtools內取出來的功能吧
https://forum.doom9.org/showthread.php?t=152326
所以應該是可以參考的。

A:
另外,
昨天發現另一個方式來增加流暢度,大幅降低penalty.lsad,
可以提高快速pan下的流暢度,而且不會像bad.range增加這麼多偽影,
目前是降到3300(有先經過降噪處理),不過低於2500的話似乎偽影有提高的趨勢。

K:
這似乎不錯
lsad會看前一層的sad來改變目前區塊搜尋時的lambda

double k=pow((float)localSadLimit/(localSadLimit+(predictor.sad>>1)),2);
localLambda = int(_fmin(localLambda*k, INT_MAX / 100.0));

前一層的sad越大lambda就越小
而lsad大小決定影響的程度
lsad越小lambda很容易變小
lsad越大則lambda不容易變小

A:
猜測應該是高level下sad差異較大,
因此降低lsad時,主要是提高coarse層的搜索半徑,
而finest層sad較低,使得影響較小。

這是用這參數壓出來的影片及簡化後的SBR腳本
(以 mawen1250 所寫的 GrainStabilizeMC_v1.0.avsi 修改而成)
#版權因素,影片上傳至Youtube後顯示禁止在全球撥放。


K:
厲害~
很滑順也幾乎沒有偽影了

A:
另外,
使用SBR處理,在剛撥放或跳轉時,撥放器似乎比較容易崩潰,撥放器重開就好了。

K:
原版的SBR好像只處理Y而已
https://forum.doom9.org/showthread.php?p=1323257

A:
SBR效能影響不大,YUV全部處理大概多消耗2~4%左右,
只處理Y和YUV均處理,速度差不到1%。

K:
不過如果是4K的話速度可能就會有差XD

K:
想到之前jm_fps也是先用removegrain濾過
不過他的refine和smooth是用未濾過的super

A:
我忘記了,哈
難怪這幾天總覺得看起來好像Algo13,Halos變明顯的感覺,
不過refine就沒辦法了。

K:
除非用full=false連finest層也不去噪

A:
這樣似乎就沒意義了XD

K:
話說看了4K的君名再回去看1080p的
變成有點像是在1080p下看720p
習慣真是可怕啊orz
不過應該是我NGU只開到medium
建議升上4K的話可以買好一點的顯卡XD

A:
現在GTX1080把1080P的圖片以Waifu2X拉到4K的速度已經到0.25s了,
再過幾年也許就可以實時Waifu2X囉~

----------------------------------------------------------------------------------------
2017.11.27

A:
這幾天把除噪的部分暫時拿掉了,
因為經過一連串的調整後,(lsad丶pzero)
似乎不用特別降噪就能達到一定水準的流暢度,
回憶場景或本身片源就重噪點的部分則沒有特別去測試,也許降噪會有助益。

目前使用的參數

levels.pel                              = 1;

//bulk 24px;
analyse.block.w                         = 32;
analyse.block.h                         = 32;
analyse.block.overlap                   = 2;

//1080p影片;
analyse.main.unblank                    = 4;


analyse.main.levels                     = 5;
analyse.main.search.type                = 4;
analyse.main.search.distance            = 2;

//finest層開啟SATD有助於降低部分場景閃爍的情況;
analyse.main.search.satd                = true;
analyse.main.search.coarse.type         = 4;
analyse.main.search.coarse.distance     = 3;
analyse.main.search.coarse.satd         = true;
analyse.main.search.coarse.trymany      = false;
analyse.main.search.coarse.width        = 1050;
analyse.main.search.coarse.bad.range    = 0;

analyse.main.penalty.lambda             = 1.50;
analyse.main.penalty.plevel             = 1.40;
analyse.main.penalty.lsad               = 3000;

//略為提高pzero增加流暢度,過高會有類似trymany的偽影;
analyse.main.penalty.pzero              = 110;
analyse.main.penalty.pnbour             = 65;

//略為增加thsad,降低偽影;
analyse.refine[0]        = {thsad: 350,search:{type:4,distance:2,satd:false}};

//refine[1]不知道有沒有用,心理安慰用的;
analyse.refine[1]        = {thsad:1800,search:{type:4,distance:1,satd:false}};

smooth.scene.limits.m1                  = 2400;
smooth.scene.limits.m2                  = 4000;
smooth.scene.limits.scene               = 4000;
smooth.scene.limits.zero                = 180;
smooth.scene.limits.blocks              = 45;

似乎沒什麼參數好改了(?)
剩下就慢慢優化參數,
前幾天有嘗試用SSIM來量化補幀效果*,不過好像沒什麼用,
有些參數開啟後明顯觀感較差(bad.range),但SSIM分數比較高。

*
先將影片挑出偶數幀當對照組,Source.SelectEvery(2, 1)
然後用奇數幀補出偶數幀當實驗組。
Source.SelectEvery(2, 0).smooth(num:2, den:1).SelectEvery(2, 1)

K:
thsad:1800可能太高
大部份應該不會做到refine[1]

一般TV動畫作畫只有到12fps
也許要拿迪士尼以前那些24fps作畫的老作品來測試?

A:
是用平移畫面較多的OP來測試,OP應該多為24fps吧

----------------------------------------------------------------------------------------
2017.11.29

A:
提供一些參數選用原因,不過這些測試是單獨調整後的結果,
也有可能是因為其他參數不佳導致當下測出此結果。

search.type             4  Hai to Gensou no Grimgar OP 00:57
finest.satd          TRUE  Log Horizon 2 [NCOP] 00:03
penalty.pnbour        >50  High School Fleet [NCOP] 00:50
penalty.pnbour        >60  Fate/Stay Night ED
penalty.pnbour        >60  Kantai Collection OP01 00:05
penalty.lsad        >2500  The Asterisk War OP02 00:30
refine.search.type      4  Nisekoi OP03 00:55
refine.thsad[1]      1500  Kyoukai no Kanata I'll Be Here Kako Hen [SP01]
refine.thsad[1]     >1600  Girlish Number OP

refine.thsad[1]低於1600的話,在部分片段會造成波紋狀偽影,
不過不確定開啟這項有無改善,只知道開啟後thsad過低會有偽影。

下圖則以整集測試

try      = trymany
b.r 2    = bad.range:2
Algo13-Y = Algo13亮度通道之SSIM值

似乎Algo:13的分數比23.丶2.都要高些,
越新的參數,分數有逐漸增加之趨勢,
不過此試驗方式並不代表實際觀感,
12fps補至24fps與24fps補至60fps可能最佳參數大不相同,(像是搜索半徑大小)
輕微的Blend可能有助於提升觀感(流暢度),但卻會降低SSIM,
偽影即使相同,但畫面變動速度不同時,也會影響到觀感,平均計算似乎不太妥當。

K:

可以的話還是拿60fps當做比較的對象
如同升頻演算法也是拿原圖縮小套用算法再和原圖比較

A:
但原生60fps的手繪動畫,幾乎找不到...
找60fps的CG動畫來試?

K:
可以先試試原生24fps的手繪動畫轉成12fps試試2:1補幀是否能接近手繪
或者是找補得很順的60fps(例如KonoSuba那張)來當做比較對象

K:
或許也不需要整個片段做比對
因為SVP都只參考前後幀
只以一些較能看出差異的畫面來比較也是可以
排除場景變換等無法補幀的畫面

A:
另外,
這幾天測試發現即使在smooth.mask.area:0時,
smooth.mask.cover夠高時(像是1000),偽影有增加的情況,
似乎與官方說明不太相同
Cover/uncover mask strength, more means "more strong mask". Recommended
values 50-100.

也稍微試了一下mvtools2,
發現在mvtools中,bulk 16px似乎比32px來的更好,和SVP的結果有較大出入,
推測可能為lambda計算方式不同所致。

K:
真希望有人能寫外掛將MAnalyse()的結果轉成SVSmoothFps()可以吃的格式XD

A:
對呀,
而且SVConvert只能轉給MVTools 2.5使用,2.7版不能。

----------------------------------------------------------------------------------------
2017.12.06

A:
這幾天拿了些OP來測SSIM和pnsr,
結果這兩項的表現和實際觀看的效果差很多,
方式依然是以12fps升頻至24fps在與原影片比較,
結果SVP預設參數的ssim及pnsr分數都遠勝於其他參數,
實際將影片轉出來觀看,
預設參數的確比較滑順,但波紋狀偽影也十分的多,
其他參數雖然比較不流暢,不過波紋狀偽影少了非常多,
我個人是比較偏好後者的表現。

Google了一下相關 評價圖像相似度的方式,
看起來大多是在研究 壓縮丶噪點丶模糊丶色偏所造成的失真,
而且不同算法對於不同類型的效果均不相同,
較接近SVP偽影的失真類型應該是TID2008/2013的Non eccentricity pattern noise,
https://imgur.com/a/mAdb3

不過似乎常見的評價方式都沒辦法很好的評價這類失真。

資料來源:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.297.8459&rep=rep1&type=pdf
http://sse.tongji.edu.cn/yingshen/paper/VSI2014.pdf

所以,
可能就算拿的到60fps片源,也沒有好的比較方式,
大概還是要人眼去看XD

K:
如果是整張圖下去平均
大部份上看起來相似分數就比較高
可是可能錯的地方人眼卻不能接受吧
也許可以改變權重突顯出錯的地方來調整分數
如果是整部片下去平均就要突顯不補和偽影很明顯的幀

A:
因為前幾天在試SSIM,
意外發現,SVP使用不同顯示卡算出來的結果不同(SSIM != 1.000000)
測試影片
1. High School Fleet - NCOP
2. The Asterisk War Season 2 - NCOP
3. Fate/Stay Night [Unlimited Blade Works] 2014 - EP02

SSIM _1: 0.999807 (GTX960/R7-260)
SSIM _2: 0.999892 (GTX960/R7-260)
SSIM _3: 0.999967 (GTX960/R7-260)

分別對原始片源比較的話,
R7-260的SSIM均比GTX960還高一點點,
不知道是不是Nvidia家OpenCL 1.2,AMD家OpenCL 2.0的因素

K:
因為SVSmoothFps()的作法不明
很難判定是什麼造成差異(不一定會根據OpenCL支援度調整算法
直接問SVP可能比較快

A:
另外也測了Cubic和Linear的SSIM,測試影片F/SN [UBW] - EP02


K:
看起來cubic的影響比linear還小

A:
也試了幾組腳本用在動畫上的效果
FrameRateConverter v1.2
https://github.com/mysteryx93/FrameRateConverter
去除偽影開太強了,流暢度不足,
7組預設值,裡面最適合手繪動畫的是Fast,其次是Faster,其他反而效果更差。
jm_fps預設則是偽影偏多。
InterFrame流暢度稍微低了點。
YFRC則是只能倍幀,不過其中用來遮偽影的部分很有意思,以後來研究看看。

K:
FrameRateConverter我覺得比較有意思的是
針對很容易出現偽影的條紋場景弄了個StripeMask
這類場景之前也是直接放棄orz

SVP的Artifacts masking就是YFRC來的
https://www.svp-team.com/forum/viewtopic.php?pid=64496#p64496
SVP版的MVTools也有導入
https://www.svp-team.com/wiki/Plugins:_MVTools2
int sadml - area mask (based on block SAD value, the idea was taken from YFRC

A:
不知道還有沒有其他腳本可以參考?

K:
水管上不少補幀的影片
有些說是SVP或其他軟體補的有些都沒說是怎麼弄的
SVP補的大多也沒有放出參數
能參考似乎很少XD

----------------------------------------------------------------------------------------
2017.12.16

A:
因為這幾天測試發現無法重現,
發現原因似乎是MT的影響,所以全部重測,目前數據應該都可以重現,

K:
最近重看舊番時也覺得有時候偽影消失了
不知道是坐遠看所以忽略了還是真的MT會有影響
和之前用OP測試偽影很固定的體驗不太一樣

A:
測試用片段

已排除部分不適合之影片,也限定同一部動畫的片段不要太多。

其中PSNR有兩個平均值,
一個是平均每個影格的PSNR值,
另一個則是平均每個影格MSE後計算出的PSNR。
(單獨列出來是因為ffmpeg記錄檔內的MSE值精度較低)

測試結果:https://imgur.com/a/pNh3Y

A:
補充日期:2018.01.18
補充內容:
上面連結中有張圖數字打錯了,更正一下
https://i.imgur.com/JnY8QDx.png

Cubic開啟後的數值表現均有上升。

Linear關閉後的數值有高有低,但在測試樣本中,有變高傾向。

FrameRateConverter的確是Fast表現較佳,Anime模式反而較差,
而且在較低百分位的數值有明顯較高(偽影較少)。

R7-260數值幾乎都比GTX960還高,而且還滿明顯的,
不過這項在實際觀賞上還沒發現沒發現明顯差異。

K:
有個很牽強的推測是
會不會SVSmoothFPS()是先轉成RGB再處理?
而轉成RGB是用顯卡內建的功能
所以在顏色上有差異
試試先把影片轉灰階再測試?

A:
可是SVPflow只吃YV12不是嗎?
轉Y8再轉回YV12?

K:
用GreyScale()或masktools把UV填128試試

A:

這是跑出來的結果,
不過,
如果是顯示卡YUV<->RGB轉換精度的差異的話,
用灰階的作用也不大吧?

K:
灰階的話不管用什麼係數
轉成RGB應該都是同樣的值才對呀
YUV(x,0,0) <-> RGB(x,x,x)
這邊有排除上面提到的偶發錯誤嗎?

A:
偶發錯誤有排除了(至少需要2次數值一樣)

YUV(BT.709) -> RGB
R = Y + (1.2803 * (V - 128))
G = Y - (0.2148 * (U - 128) + (0.3806 * (V - 128))
B = Y + (2.1280 * (U - 128))

RGB -> YUV(BT.709)
Y = R *  0.2126 + G *  0.7152 + B *  0.0722
U = R * -0.0999 + G * -0.3361 + B *  0.4360 + 128
V = R *  0.6150 + G * -0.5586 + B * -0.0564 + 128

雖然灰階轉RGB可以避開精度差異,
但RGB轉回YUV的時候依然會有精度的問題吧?
畢竟最後輸出還是YV12。

K:
我想應該是不會
也許可以試試AviSynth的ColorBars()
經過SVP後灰階的誤差範圍

A:
是比較Colorbars()與經過SVP處理後的PSNR丶SSIM這樣嗎?
SSIM: 1.000;  PSNR: inf
完全一樣,不過這是靜態圖片,可能不太準。

K:
這至少代表SVP在YUV<->RGB的部份是沒有問題
差異應該是補幀的部份所造成的

A:
但無變化時,採用bypass的話,
就有可能無差異吧?

K:
這裡是假定SVSmoothFps()的OpenCL處理用RGB
所以原始YUV都會先轉成RGB放在VRAM上供GPU存取
然後從這裡產生補幀的RGB畫面
或是原封不動複製出新畫面
最後在轉回YUV到系統記憶體
所以我猜不是YUV<->RGB而是補幀所造成的

A:
因為過去有發現特定異常情況,開啟SVP後畫面會閃爍,
加上原始幀的輸出均相同(下面的Full測試中也有一樣情形),
所以我才會猜測會不會在沒變化時,是以bypass的方式輸出。

K:
那時好像是補出來的幀和原始幀亮度不同?
這樣就應該不是bypass的方式輸出

A:
比較了一下輸出,看起來是運算精度差異造成的
R7-260

GTX960

差異處

K:
這樣看來的確有可能是不同顯卡OpenCL運算精度差異造成的

A:
Down參數似乎還是4較佳。

Algo21和23很接近,似乎就是23.的弱化版,
Algo13於第6~20百分位數值明顯較高。

如果Cover設為0,那Algo23=Algo11 (推測Algo21也是),
Cover越低,數值有越高的傾向。

K:
原來如此
之前的感想也是覺得對動畫來說Algo11,Algo21和Algo23差異不大
昨天試著讓內顯去跑SVP減少獨顯的負擔
但結果即使是Algo11內顯(HD4600)也跑不動4K
應該要強一點的內顯才可以

A:
沒測出來Force13的差異。

將Area_Sharp改小,數值似乎有少許提升。

以下為個人猜測:
第50百分位數值與流暢度相關,
第6~13百分位數值可能與偽影相關,
低於第3百分位數值的可能是轉場相關。

K:
測試辛苦了~

這幾天因為新螢幕有支援10bit所以試了一下
感想是我分別不出和8bit+抖色的差異orz
另外是D3D11 exclusive的rendering time在直接軟解輸出NV12下會很高
但多了ffdshow再輸出NV12反而比較低...有點匪夷所思

A:
exclusive我用起來遇到過不少次問題Orz
像是全螢幕會黑掉丶當機之類的,所以不太喜歡用,
而且外掛字幕常常需要切出去改,看不順眼就改XD
最重要的還是,這模式的優勢我感覺不出來...
現在不用exclusive也能輸出10Bit,所以似乎不是那麼重要了?

K:
因為我還是用win7
要輸出10bit就只能用exclusive了XD
不過現在只是擺在Ctrl+J好看而已
10bit片源經過ffdshow都變8bit了orz

A:
只好期待哪天madVR提供Vapoursynth接口了XD

話說,
聽說官方版mpv似乎也是不能輸出10Bit?
SVP的10Bit好像只是可以用Vapoursynth輸出10Bit,沒說播放器支不支援10Bit輸出。

不過有看到有人寫出可以輸出10Bit的mpv,不知道SVP版的有沒有?

K:
沒用過mpv所以不太清楚
SVP是只有vs版的才能輸出10Bit(應該是P010
所以即使ffdshow可以接受P010輸入也要等SVP更新avs版的plugin

A:
ffdshow最新一次更新是2014年,大概沒希望了XD
而且使用ffdshow的話,HDR影片在SDR螢幕下觀看會有問題,


正常應該是這樣


不過現在SVP也還不支援HDR影片,所以好像也沒差XD

K:
記得不使用madvr轉成SDR直接看HDR的話
顏色好像就會像這樣怪怪的
跟ffdshow沒關
不過經過ffdshow就損失了很多資訊
這邊真的沒希望了XD

A:
經過ffdshow後,
BT.2020色域標記會被標成BT.709,也不認smpte2084,
而且似乎無法傳遞 HDR meta,所以顏色全偏了。

加上ffdshow沒更新這麼久了,
除非madVR添加Vapoursynth接口,
或SVP可以不用依賴ffdshow,
不然過陣子只能跳mpv player了。

K:
如果SVP做成像BFRC或DR一樣
自己就是一個ds filter
不需要依賴avs或vs也是不錯
不過應該不太可能
寫ds filter太折磨人了XD

----------------------------------------------------------------------------------------
2017.12.18

A:
目前已知同時使用StackHorizontal + Crop + SVSuper + BlankClip
然後再使用MT模式,幾乎每次結果都不一樣。

如果不用以上濾鏡,使用多執行緒還是有機率出錯,
而且很討厭的是,這種可能幾千幀才出現幾個



一開始沒發現的原因是SSIM很接近,像下圖

這是同一組腳本跑兩次的SSIM和PSNR值。

K:
看來不是每次都錯在同一個地方?
可能要深入了解AviSynth的MT模式怎麼運作了

A:
加測HD630



這幾天新測的結果
https://imgur.com/a/8hXgy

小結:
CPU渲染的分數果不其然的特別低。
做2次refine不太值得,除了觀感無明顯變化,分數也變低。(以目前參數來說)
full會影響到分數

K:
前兩點在預期中
只是full結果有點意外
這只是用來節省記憶體的
會影響到畫面可以說是bug了吧

A:
又多試了幾次,
full關閉的話,數值上真的有變化,原因不明...

A:
補充日期:2018.01.18
補充內容:
full開關會影響到數值,但不一定會變高或變低。

K:
可以先比較full會不會影響SVAnalyse()出來的MV
理論上不會才是
SVSmoothFps()造成變化的可能性比較大
同樣要先排除上述的誤差

A:
我把levels改回5測試,(之前都是用5->4測試)

依然有差異,
而且變成開啟full後的表現略佳,
不過差異非常小,
但之前5->4的差異其實也不大,
有排除誤差,連續3次測試數值均一致。

另外,
在測試時,發現levels 5->4 且 full關閉時,
使用相同腳本,
依照特定順序測試會有差異,(直接跑full關閉)
依照特定順序測試也可以幾乎每次都正確,(先跑一次full開啟,再跑一次full關閉)
而且有差異時,也可以每次都在一樣的地方有差異,數值也相同。
實在很神奇...

錯相同的地方及一樣的數值


右方: 先跑一次full開啟,再跑一次full關閉
左方: 右方結束後,再跑一次與右方同樣的參數(full關閉)

*
如果levels 5->4 且 full 開啟的話,
那幾乎每次都是相同的。

K:
完全沒有頭緒
不過既然都會錯在同張畫面
也許可以將錯的存下比較看看差異?

A:
請問要用哪個指令達成呢?
因為兩個avs腳本一模一樣,所以分開輸出應該會一樣無差異?
但同時輸出的指令不知道該怎麼寫。

目前是使用以下這指令來算SSIM及PSNR
ffmpeg.exe -i a.avs -i b.avs -lavfi ssim='SSIM.txt';[0:v][1:v]psnr='PSNR.log' -an -f null -

K:
我是想說先輸出huffyuv之類的無損格式
發現差異再去看畫面實際上是如何

A:
先Full:ture再跑Full:false (正確結果)

Full:false

差異處

的確有差異...

K:
看來只有補出來的幀有差異?
而且都集中在很右邊的位置

A:
對,原始幀都是一樣結果(n=奇數)


K:
166的差異看起來像是個...邊框?

A:
會有那個奇怪的現象似乎只發生在 遮蔽Super + Full: false 上,
可能是遮蔽部分造成的影響?

而且那個差異形狀還滿奇怪的...

有辦法可排除這個情況了,將AddBorders換成BlankClip來遮蔽,
明明兩者輸出的Super是一樣的,也不知道為什麼。

K:
這可能要去研究下AddBorders了
不過至少確認了SVP是沒問題的

A:
目前暫時換回BlankClip,過段時間再來把之前的幾項測試重跑一次檢驗。

K:
不知道BlankClip和AddBorders的速度是否有差
有的話
測試時用BlankClip求最精確的結果
平常看片再用AddBorders就好

K:
btw,看能不能也將SVAnalyse()的結果也存下比較看看
SVAnalyse輸出的應該是RGB32高度為1的幀
看能不能存成BMP檔之類的
不過如果是運算精度差異造成的
那比較的結果應該都是相同

A:
對,經過比較,GTX960與R7-260的SVAnalyse的輸出均相同(PSNR=inf)
但是關閉GPU與開啟GPU加速的結果不同,
上為使用GTX960與R7-260計算的差異(無差異),下為R7-260與CPU計算的差異(少許差異)

不知道是精度的差異,還是BUG造成的。

K:
有點意外
SVAnalyse應該只有CPU運算(原始碼都攤開在眼前了
居然GPU和CPU會有差異orz

A:
SVP官方有說過CPU用整數運算,GPU採用浮點運算
https://www.svp-team.com/forum/viewtopic.php?id=2186
More precise rendering (floating point vs. integer math), correct rendering on frame edges, rendering in "linear light", bicubic subsampling.

雖然我很懷疑GPU加速在畫面邊緣的渲染比較好這句話,
而且開啟GPU加速不是只能bilinear放大嗎?

https://www.svp-team.com/forum/viewtopic.php?id=2848
新的這篇只有提到浮點運算丶bicubic插幀與線性光。

K:
這邊說的應該都是指SVSmoothFps()
SVP只有這部份能用到GPU加速

A:
恩,可能前一篇是指老版本的SVP吧。

----------------------------------------------------------------------------------------
2017.12.29

A:
這幾天因為跑出來有多次差異,所以比較晚回覆
之前使用的時候,關掉MT可以幫助降低差異,
但這幾天試其他腳本時,出錯機率大增,
然而,只有特定參數時錯誤率會大幅增加,
舉例來說,
在Algo23時,
input = input.PointResize(input.width+(PaddingPX*2),
\                         input.height+(PaddingPX*2),
\                         -(PaddingPX),
\                         -(PaddingPX),
\                         input.width+(PaddingPX*2),
\                         input.height+(PaddingPX*2))

smooth = smooth.Crop(PaddingPX, PaddingPX, -(PaddingPX), -(PaddingPX))

當PaddingPX為8丶24丶40時,特別容易出錯。
但如果PaddingPX換成0丶16丶32就比較不會有差異。

K:
都會有差異的話感覺不是裁切造成的

A:
我不知道是哪個環節造成的,
一般情況,有差異的機率大約為20%,
上面說的特別容易出錯情況,有差異的機率應該超過70%,
容易有差異的那幾組,我至少跑了6~10次才有辦法獲得相同的數值,
一般的跑個3~4次就會有相同數值了。

K:
原來如此
這要查出來得費不少功夫了
難道會是記憶體的隨機錯誤嗎!?

A:
這就超出我的能力範圍了...
不過,我有試著降頻記憶體,但還是一樣。

K:
或是換台主機試試?
如果在好幾台上都會出錯
那就是軟體的可能比較大

A:
因為測試用影片大小不同,
所以有裁切,擷取中央部位1888x1062的部分(1920-32,1080-16)

這幾天加測的一些結果,
https://imgur.com/a/EoWTP
小結:
將TVrange轉換成PCrange算出來的結果是有變化的,
對於前75%的畫面有小幅的助益,但對於變化較大的畫面有劣化情形。

在Algo13時,
適當的填充邊緣,有些幫助,不過過大似乎也會劣化,
Algo23填充邊緣的話,似乎也有一些作用,不過沒Algo13明顯。

K:
我覺得還是得先每次都能重製相同的數據
進行後續的實驗才比較妥當

A:
大部分的數據都能重現,
只不過有些可能要多跑個幾次,或是特定順序下跑(WTF...)


左方數據標題底色為黃色的代表跑了2~3次內有重現一樣的數據,
若為橘色,則表示跑了數次,才出現同樣的數據,
若無底色,則表示僅跑1次。

----------------------------------------------------------------------------------------
2018.01.21

A:
前幾天花了些時間在測試HDR影片。
SMPTE ST 2084 (PQ)這在2016年7月6日才定義出來的,所以應該是ffdshow沒支援而已。

K:
我記得不光是新的色彩空間
只要是color matrix這類的metadata都不被ffdshow認得
自然也不會帶給下一級的filter如madVR
madVR這時只能用猜的

A:
那如果要用DS系播放器來補HDR影片,目前只能使用BlueskyFRC了,(DR我沒試,不清楚)
SVP目前應該沒辦法,
不然就是要在Avisynth腳本中先將色彩空間轉換成BT.709後輸出,
不過目前沒有現成的SMPTE ST 2084轉換可以使用,
而且還沒辦法自動判斷來源是DCI-P3還是BT.2020。

K:
DR只能吃NV12所以應該也是不行

不過都要做HDR->SDR不如直接看SDR影片就好了

A:
BlueskyFRC也只吃NV12,不完整支援HDR影片,缺少HDR meta資訊,
但madVR一樣可以處理,猜測應該是有傳遞transfer_characteristics給madVR

只是這樣顏色損失很多,使用SDR顯示器材,還是觀看SDR影片就好了。

K:
我以為HDR至少要P010
不過少了metadata應該不能算是HDR訊號了吧XD

A:
HDR 多了個背光亮度控制
少了HDR metadata還是可以顯示出HDR畫面,不過背光亮度可能會錯誤。

HDR metadata只是標註影片平均最大亮度丶最大亮度為多少,
還有調試HDR影片時使用的最大/最低亮度(後兩項似乎在觀影階段根本沒影響)

在日版UHD你的名字中,Menu部分甚至根本沒有平均最大亮度丶最大亮度這兩項。

K:
關於HDR還是處於一知半解
HDR螢幕是怎麼處理HDR影片的這部份有詳細的資料可參考嗎
只理解一點攝影的HDR(或說tone mapping)

A:
我用我那號稱有HDR螢幕的手機搭配Youtube認證的HDR影片測試的,
播放影片當下很艷麗,但按下截圖後進相簿觀看,灰濛濛的,
和觀看完全沒有HDR meta的HDR影片一樣。

https://www.lightillusion.com/uhdtv.html
https://www.itu.int/rec/R-REC-BT.2100

K:
大概看了一下有多了些了解但還沒完全消化
目前我的理解是
影片存放的是線性的資料
播放時以Gamma還原成非線性
SDR影片因為顯示器的Gamma和最大亮度是固定的
所以製作時會放棄不少(尤其是在亮部的)細節
但對比,色調和飽和是不會變的
而HDR會記錄下感光元件的亮度曲線
由顯示器根據這個調整成自己的最大亮度
所以HDR影片可以保留下較多細節
以顏色來比喻SDR就是SRGB而HDR是廣色域
不知道這樣對不對?

但我覺得關鍵還是在HDR影片有10bit而SDR只有8bit
不然即使HDR最大亮度比較高
影片的資料只有8bit轉換後的亮度也只有256階吧?

而且動畫又不像電影是拍攝真實環境不能記錄下完全真實的亮度值
我覺得HDR帶來的畫質提昇應該有限

A:
好像和我理解的不太一樣(?)
SDR和HDR影片最暗處的程度差不多,
不過SDR規範的最大亮度是100nits,而HDR規範的最大亮度是10000nits,

K:
這個最大亮度我還是不太理解跟8/10bit的訊號之間的關係

A:
最大亮度和8/10bit沒關係,最大亮度和Gamma有關,
因為Gamma的關係,所以HDR需要高色深,(後面有比較詳細的說明)
可能我哪邊說的讓您誤會了。

A:
由於人眼的看到的對比度大於SDR影片的最大差異,
為了保留高亮度區域的細節,SDR影片通常會壓縮亮度差異,
或者說,HDR影片有加大亮度差異,會這樣說的理由是,

1. 很多HDR版本的電影是從SDR後製來的,原先沒有的細節是要怎麼跑出來的?
2. 如果SDR影片的對比是正確的,那SDR影片應該會有一大堆過曝/曝光不足的區塊。

多數HDR影片看起來並不是單純增加高亮度區域的細節,
是整個畫面的對比都有大幅變化。

K:
也就是說SDR影片因為壓縮亮度差異
實際上都沒有到達訊號原本的8bit=256階動態範圍嗎?

A:
觀察你的名字SDR與HDR版本,發現在同畫面時HDR的對比較大,
如果以SDR為標準,那HDR版本的動態較大,
如果以HDR為標準,那SDR版本的動態等於有被壓縮,
看要以哪個為基準,
由於SDR影片的最大亮度為100nits(業界標準?),
使得畫面中亮度超過100nits的部分,都會以Hard Clip處理,
所以下面舉例的燭光與烈陽在SDR中均為255,這就算是動態壓縮了吧。

K:
我覺得對比高!=動態大
動態範圍是訊號可以分辨出來的階層數
對比是最大最小值的差
用軟體可以簡單把圖片對比加大
但沒辦法很容易就提高動態範圍吧

燭光與烈陽均為255應該說是tone mapping
為了在影像中同時表現窗外的烈陽和室內的燭光
將兩者調成一樣
通常HDR影像好像都是這樣做的

A:
動態範圍不是最大值和最小值的差嗎...?看來是我搞錯用辭了

K:
說是差也行
google到是說可量測(對ADC而言)或可輸出(對DAC而言)的最大值和最小值的比例
所以數位訊號會因為量化的位元數影響SNR和DR
類比就要看不失真下輸出的最大音量和最小音量的底噪

A:
恩,
規格上,HDR因為最大亮度更高,所以動態範圍更大。(0~10000nits)
SDR受限於業界標準,亮度範圍只有0~100nits。

A:
這是你的名字FHD版本截圖

這是UHD_BD轉換成BT.709,並設定最大亮度為100cd/m^2


有些高亮度區塊超過100cd/m^2,過曝了
-> 該畫面原始亮度範圍大於SDR版本的
-> 所以才會說HDR版本的動態範圍(對比)比SDR版的大

K:
UHD是有比較亮但對比看來差不多
至於動態範圍HDR有10bit肯定能比SDR的8bit大的
但截圖成jpg後就看不出來了就是

K:
FHD(圖卻是4k?)怎麼彗星被雲截斷了XD

A:
FHD那張是我用madVR截圖的,當時和UHD版比較銳利度用,所以才升至4K,
這是彗星,不是流星,被雲層遮蔽才正常吧XD (太空中被太陽加熱 vs. 在大氣層燃燒)
UHD版本HDR->SDR後,動態範圍被縮小,所以才變這樣。

K:
對耶
太久了已經沒印象 加上被HDR->SDR版誤導XD
這麼說來HDR->SDR的畫面整個亮度都被拉高
不知道是因為UHD是調過的或是HDR->SDR的緣故

A:
應該都有,不過HDR->SDR目前瑕疵還是很多,沒HDR螢幕還是少碰HDR影片好了。

A:
UHD那張的亮度有被壓縮,100nits以上的訊號全沒了,
壓縮後的對比和SDR原生的對比接近
-> 原始對比大於SDR對比。

不太理解您說的10Bit比8Bit動態範圍大這句話,
如果是SDR 10Bit與SDR 8Bit相比,動態範圍是一樣的吧,
亮度 0.05 ~ 100 cd/m^2間,分別有1024階與256階,
動態範圍都是 100/0.05 = 2000,
不過前者每階的差異為 0.1 cd/m^2,後者為 0.4 cd/m^2 (假設為線性的),
因為每階差異過大,所以產生色帶。

HDR動態範圍比SDR大的因素是最大亮度更高,和多少Bit無關連。

K:
應該是誤會了
你說的應該是設備的DR而我說的是數位訊號的

設備的DR是 20 * log10( 最亮 / 最暗 ) dB

而Q-bit的數位訊號DR單純就是 20 * log10( 2^Q / 1 ) = 6.02 * Q dB

A:
原來如此~

A:
HDR影片會需要8Bit以上是必須的,
一般SDR影片的亮度從0~100nits都有,歸一化後的數值是0.0~1.0,
不過HDR影片的最大亮度通常不會達到10000nits,會用到的最高數值落在0.6~0.8間,
如果還用8Bit的話,灰階會只剩下原先的7成。

K:
不太理解這樣的比較
8bit=256階/10bit=1024階=25%
用8bit只會剩不到10bit的3成

A:
(來源: https://www.lightillusion.com/uhdtv.html)

這是HDR影片用的ST2084(上)與SDR影片用的Rec.709(下) Gamma曲線
縱座標為線性亮度,橫坐標為Y通道數值
ST2084的最大亮度為10000nits,Rec.709最大亮度為100nits,縱座標刻度不同。

ST2084中100nits對應的Y數值約為0.508 (歸一化),1000nits則是0.752
大部分的HDR影片最大亮度不會超過1000nits,
因此以10Bit來說,最大有1024*0.752=770階,
使用8Bit來儲存的話,最大只剩下256*0.752=193階,

考慮到影片達1000nits的畫面很少見,絕大部分的亮度低於100nits,
10Bit的話,在這些情況下可以呈現1024*0.508=520階,
但8Bit HDR影片只能呈現256*0.508=130階。

因為HDR影片使用ST2084為Transfer characteristics,
所以HDR影片需要使用大於8Bit來儲存,不然就只剩下130~193階了,
這也是開啟FM後的HDR影片需要加強Dither才能避免色帶產生。(NV12 HDR)

K:
還是有點霧沙沙orz
以8Bit來說用256階中的一半130階來儲存暗部資訊不是很正常的事嗎
會出現色帶是8Bit本身就會有的問題(所以才有SBMV這類的Dither技術)
就像madvr用dither在6bit面板上減少色帶問題一樣
感覺跟HDR沒有絕對關係XD

A:
怎麼說呢...
在觀看SDR影片與HDR影片的 平均亮度 大致上是一樣的,不然會被HDR螢幕亮瞎。
(BT.2100建議觀賞的環境亮度為5 nits)

HDR功能作動時,背光亮度控制似乎是失效的狀態,
和SDR螢幕可以鎖定背光強度不太相同。

SDR 全部色階均分布於 0~100nits,
HDR 分布於0~100nits的色階只有大約一半,另一半色階是100nits~10000nits,

不是用130階來儲存暗部資訊,是絕大多數訊號儲存於130階內,
少數高亮度區塊才會大於130。(8Bit HDR)

畢竟不太會有影片是持續顯示超過100nits的。

K:
所以是說在真的HDR螢幕上看到的HDR影片
亮的部分會比看SDR版的影片來得亮這樣對吧?

A:
對。

A:
動畫的話,HDR應該也是有幫助的,
如同上面所說的,SDR影片有壓縮動態的情形,
HDR可以讓色彩更細膩(10Bit)丶更真實(BT.2020)丶動態表現更好(HDR)

K:
更真實是指?

因為我是覺得動畫不像電影要靠攝影機去拍攝真實場景
光源對拍攝影響很大(不過也難說現在都靠CG和後製了orz
動畫一開始製作時就能決定對比和飽和了

A:
BT.2020的色域比BT.709大得多,可以顯示更多色彩,
不過這也要有用超過BT.709的色域才有差異,看迪士尼或皮克斯會不會率先使用吧。

K:
只知道它們的YUV<->RGB的係數有差
感受不到為何這點能顯示更多色彩

A:
中間有彩色的範圍為CIE 1931 XYZ色彩空間,也可以理解成人類可見的範圍,
人類可見色域覆蓋率: CIE 1931 XYZ > BT.2020 > DCI-P3 > BT.709 > BT.601

圖片來源:
http://cweb.canon.jp/v-display/lineup/dp-v2410/feature-performance.html

K:
我知道這張圖
但不能理解為何圖中的BT.709沒有包含到綠色
而我看BT.709的影片卻還是能看到綠色XD

A:
因為這只是示意圖XD
超出螢幕色域範圍應該是無法分辨的。

A:
之前有看過一個說法,(詳細忘了)
在SDR影片中,燭火的亮度是255,日正當中的烈陽亮度也是255,
在HDR影片中,燭火的亮度是600,而日正當中的烈陽亮度可以達到800,
HDR影片顯示出更真實的畫面。

K:
這樣是否SDR影片的燭火調成255*600/800=191也能接近真實的畫面呢?

A:
不能,這樣燭火會太暗,(50%中性灰對應的是Y:188)
原因還是因為SDR的亮度範圍不夠大(0.05~100nits),
亮度超過100nis在SDR影片中都是100nits(255),
HDR的亮度範圍夠大(0.05~1000nis),可以顯示高亮度區塊的差異,
可以分出100nits(519)丶400nits(668)丶1000nits(769)的差別。

K:
突然好像有點理解了
所以關鍵是在於HDR的螢幕會比較亮
如果只播放8bit影片有點浪費
以音響來比喻的話
一樣都是16bit的CD
用小音量播放的時候雖然也能感受音樂的動聽
但音量大更容易聽出細節這樣?

不過感覺這還是跟影片本身有多少細節沒有相關
10bit的影片細節一定是比8bit的來得多的

A:
不太一樣,
因為聽音樂的最大音量大小是一樣的,
Hi-Res是解析度變好丶聲音變化更細緻,音量不會變大,
(當然,放大音量的話Hi-Res會有更多細節)

K:
我是指DAC後喇叭輸出的音量(不是訊號本身的
HDR螢幕就是能輸出比較大音量的喇叭

A:
HDR則是拉高亮度上限,但平均亮度並不會改變太多,
而且10Bit HDR的色帶會比10Bit SDR明顯。

K:
是因為截圖下來比較的關係嗎?

A:
我們把HDR拆分成0~100cd/m^2,以及100~10000cd/m^2來看,
因為大多畫面的亮度依然低於100cd/m^2,
所以下面只考慮0~100cd/m^2的部分,
10Bit HDR有520階,而10Bit SDR有1024階,8Bit SDR有256階。

在100cd/m^2內,10Bit HDR的色帶表現約等於9Bit SDR,
8Bit HDR約等於 7Bit SDR的色帶表現

K:
ㄜ...所以是HDR影片顯示在HDR螢幕上比10bit SDR影片顯示在同一螢幕上
HDR影片會比較banding嗎?

A:
如果以車速來形容的話,在速限100KM/hr的公路上,
16bit CD     以10KM/  1hr為單位調整速度,平均速度80KM/hr,最高可達100KM/hr,
24Bit Hi-Res 以 39M/0.5hr為單位微調速度,平均速度80KM/hr,最高也是100KM/hr,
(16Bit 44.1khz vs. 24Bit 88.2khz)

 8Bit_SDR 以 8KM/hr為單位調整,均速18KM/hr,最高100KM/hr,
10Bit_SDR 以 2KM/hr為單位調整,均速18KM/hr,最高100KM/hr,
 8Bit_HDR 以16KM/hr為單位調整,均速18KM/hr,最高600KM/hr,氮氣加速1000KM/hr,
10Bit_HDR 以 4KM/hr為單位調整,均速18KM/hr,最高600KM/hr,氮氣加速1000KM/hr。
對不起,都是龜速車XD (影片平均亮度只有10nits~30nits左右)

K:
同bit不是應該同單位調整(檔數)嗎?

A:
音頻的部分(16Bit 44.1khz vs. 24Bit 88.2khz)
相差8Bit,所以調整單位差2^8=256倍,
採樣率差1倍,所以調整單位時間只需要一半。

影片的部分在前段有說明,
因為HDR PQ(SMPTE ST 2084)與SDR Rec.709 gamma不同的因素,
大部分的情況下(低於100nits),
10Bit HDR的色帶表現約與9Bit SDR接近,
 8Bit HDR的色帶表現約與7Bit SDR相近,
所以調整單位不同。

K:
應該是一開始就誤會了
我說的是10bit影片本身的訊號
細節上一定是能比8bit的多

A:
不過10Bit HDR多出來的訊號有很大一部分是極高亮度的訊號(高頻訊號?)
所以效果會比10Bit SDR差一點。

K:
原來如此
但反過來說HDR在即高亮度的細節表現會比SDR好非常多

A:
對,
但前提是要有HDR螢幕,用SDR螢幕有可能會顯示出各種色彩怪異的畫面。

K:
所以SDR螢幕也有可能正確顯示嗎?

A:
應該可以,
不過目前似乎還沒有統一的轉換方式

A:
然後目前HDR的儀表板有做到10000KM/hr,
不過只要極速能跑到1000KM/hr,就通過HDR規範了。

但因為原有規範有些嚴苛,
所以廠商聯合推出低階認證(HDR 400/600),
導致現在有些一些極速只有400KM/hr的產品也打著HDR(400)的旗號在賣。

DisplayHDR Specs
https://displayhdr.org/performance-criteria/

P.S.
如果照規範的話,UP2718Q似乎也稱不上是完全體的HDR螢幕(HDR1000)
因為UP2718Q 典型最大亮度只有400cd/m^2,不到600cd/m^2

K:
畢竟是規範出來前的產品

A:
UP2718Q過的是UltraHD Premium認證
解析度: 3840x2160
色深: 至少10Bit
色域: 大於90% DCI-P3
亮度: 最大大於1000nits且最小低於0.05nits 或最大大於540nits且最小低於0.0005nits
HDR: 使用SMPTE ST2084 EOTF HDR系統

和新的規範不太一樣,沒規定典型最大亮度。

K:
像我習慣把螢幕調暗一點
似乎也不需要真HDR螢幕(真的看過後可能又會改觀XD
而且動畫的HDR還是後製出來的
等到作畫是用HDR去製作時我覺得動畫用上HDR才有意義
說不定那時背景都跟照片一樣比新海誠的還逼真
但這樣又好像失去了動畫的味道...

A:
HDR作動時,背光控制會失效的樣子,
調暗只對SDR影片有效的樣子。

A:
SVP在mpv player中補HDR影片目前會有閃爍及嚴重色帶的BUG。

K:
是因為mpv開始支援HDR影片嗎?
離上次release好久了才發現這bug

A:
不知道耶...
最近測試才發現有這BUG。

----------------------------------------------------------------------------------------
2018.02.03

A:
完全不遮蔽 93.21 fps
AddBorders  85.89 fps
BlankClip     84.67 fps

差異不大,而且觀看影片時SVP也不會吃滿CPU使用率
如果會吃滿的話,完全不遮蔽應該也一樣會吃滿。

K:
這樣看來比較合理

K:
HDR版本看起來跟之前的4K rip顏色差很多嗎?

A:
港版UHD和日版UHD不一樣喔,差很多

有請使用HDR螢幕的網友幫忙測試,(使用DELL UP2718Q螢幕)

使用電腦播放,UHD_JP版有偏紅的情形,隔天對方買了一台XBOX來測試,
說是要用「正規的播放器」來測試,結果UHD_JP版的畫面依然偏紅。

個人認為,
似乎 你的名字 UHD日版 的顏色有問題,
除了前面提到的偏紅以外,UHD_JP版花絮片段的最黑處也不夠黑,UHD_JP版本根本做壞了吧...
不過 UHD港版的亮度似乎也有一些問題...

K:
聽起來港版並非拿日版HDR檔案而是自己轉成UHD而已

A:
比較像是HDCAM-SR母帶是正確的,
但港版壓成UHDBD時使用錯的HDR meta,
畢竟港版不太可能自己調整HDR效果吧(日方大概也不會同意)。

日版UHD就不知道怎麼一回事...
可能第一次處理HDR影片,沒處理好吧。

K:
日版也是拿DPX檔用程式去4K/HDR化的
我覺得不會這樣好心把轉好的直接給港版去壓片

K:
看訪談日版這HDR是後製出來的
但是是經過新海誠認證
所以應該不能說做壞
黃疸少女那時也是如此XD

A:
我是比較傾向母帶沒問題,
是母帶轉成UHDBD這之間出了錯誤,
畢竟顏色真的偏很多,色指定不可能沒注意到吧(?
如果母帶正確的話,那就說的通了。

K:
那時是推測製作DVD時顯示器的色溫被調成了10000K
但後來宮崎駿出來說那才是他想要弄成的顏色(色指定:黑人問號???
到最後真相不明

A:
哈哈,
色指定大概想死吧XD

K:
也可能是為了幫製作人員背鍋啦XD
這樣一想就覺得宮崎老頭還蠻挺員工的

A:
有看到一說,
UHD的制碟问题可能是真有,毕竟东宝之前的新哥斯拉UHD不止一个人说有问题了。
这部HDR还有多些信息,因为UHD拿了原始10bit的DPX文件做的,
然而东宝那个制碟,最后效果咋样不保证了 ...
目前看了几个看过UHD的反馈,
基本都说到的是画面偏暗了(很多HDR都有的小问题,可以电视本身调整),
然后有两个说色彩偏黄了,一个说还有压缩的问题,然后还有一个说4K放大没放好。
其实都是UHD目前经常会有的问题,六大的UHD也不少这种事情发生。

來源: http://123.103.16.28/bbs/archiver/?tid-164692.html&page=4

K:
其實君名算好了
鋼彈雷霆領域的4K還是從1440x810升上來的呢
https://av.watch.impress.co.jp/docs/news/1034441.html
相比之下
CCS還能將當時35mm膠卷重新掃瞄成4K
https://www.phileweb.com/interview/article/201712/28/520.html

A:
4K小櫻的顏色和先前版本的差好多...

K:
不知道是刻意調的還是說是呈現最原始的色彩

A:
偏黃可能是6500K白點在低亮度下不夠白(?
好像也不太對,
Y:600 U:512 V:512的亮度超過100nits,也是稍微偏淡黃(螢幕校準不夠準?)
之前用UP2718Q的網友也有發現。

K:
目前最大的問題還是要看HDR就不能用SVP
兩者我還是優先考慮SVP
反正也還沒有HDR設備

A:
SVP應該快可以用於HDR影片了 (mpv播放器上)
之前只是有BUG,並不是不能撥放。

K:
真是好消息

A:
至於MPC,
有看到madVR新版多了
added file tag "hdr=on|off" or "transfer=hdr|sdr|2084|709"
也許可以強制開啟HDR,雷同於AFM的8Bit HDR(缺少部分HDR meta模式)
不過我還沒試,之前升了1709,系統不太穩,正打算重灌回1703...

K:
但關鍵還是沒有10bit
ffdshow...QQ

A:
沒辦法,ffdshow就只能吃8Bit輸入QQ

K:
但是又能輸出P010/P016這些格式orz

A:
如果ffdshow能支援Avisynth的LSB或MSB高精度輸出也好呀QQ

A:
一般10Bit有1024個灰階,但HDR影片中的Y:520對應100cd/m^2,
而SDR影片一般最高亮度就是100cd/m^2,
所以HDR->SDR的灰階數被砍半,然後又因為被轉成8Bit,
灰階數再少3/4,只剩下原先的1/8 (1024->520->130),比SDR影片的255灰階還少Orz
需要開更強的debanding來避免色帶。

K:
如果用D3D11 10bit播放是不是就能減少這邊的損失?

A:
沒用呀,卡在ffdshow那關,mpv player倒沒這問題
我應該這樣寫比較好
1024(10Bit來源) -> 256(8Bit_ffdshow) -> 130(HDR轉SDR的損失)

K:
我是指沒有經過SVP直接播放HDR->SDR啦
不曉得madVR這部份是不是也是16bit處理
http://i1222.photobucket.com/albums/dd496/asmodian3/madVR%20Chart%20v2_zpsmgiipbgh.png
這張圖還沒有提到HDR
還是說包括在calibration/3DLUT裡?

A:
這我不知道,可能要問 madshi,
不過至少會在calibration/3DLUT前或中。

K:
那應該是16bit處理了
所以應該不須擔心會有色帶
不過madvr的dither不是很強嗎
應該還不需要開deband吧?

A:
效用有限,16bit只能減少誤差,
在前段就失去的訊號(8Bit HDR),是算不回來的,
不過如果是8Bit SDR或10Bit HDR影響應該不大。

以前開弱就好,看這類HDR轉SDR影片的需要開高一階,
畫面看起來有稍微髒一點(可能dither的因素吧)

K:
所以等SVP支援10bit那時就沒問題了

----------------------------------------------------------------------------------------
2018.02.06

K:
用PC要看UHD反而麻煩
不如買台player搞定

A:
不過現在支援的撥放器不多,
而且主流規格似乎也還沒有穩定下來(?)
Dolby Vision 和 HDR-10 還沒廝殺出結果。

K:
也就是說等規格底定現在的UHD BD都可能會再出一次XD

A:
我記得以前剛出Blu-ray的時候,
一開始也是很多廠商處理的很不好,畫質沒比DVD版本好多少,
可能這次UHD BD也有一段過渡期吧(?

K:
DVD時代就是這樣了
先隨便轉檔出一個版本
反正靠DVD的規格就能打贏VHS等其他媒體
然後再remaster出一個強調真正發揮DVD價值的版本
一部作品就能賺兩次錢XD

A:
HDR和SDR的畫面差異很多,尤其是對比方面,不過誰好誰壞就不好說了。

K:

其實一些HDR示範片用madVR在SDR螢幕上播我覺得效果就很好了
但想說用madVR的演算法將HDR轉成SDR 10bit影片
是不是效果也一樣

A:
和相片一樣吧,
HDR相片看起來很新奇,但有些HDR相片看起來很奇怪,
不過也有效果很棒的。

K:
就太鮮豔飽和反而感覺不夠真實XD

A:
HDR->SDR 通常紅丶綠色會很鮮豔,不知道是不是DCI-P3 -> BT.709造成的。

K:
是說比直接輸出到HDR螢幕上看到的鮮豔嗎?

A:
比較像是廣色域縮至窄色域,顏色爆掉的情況(類似於過曝)
由於短波長(藍色)的部分,DCI-P3和BT.709極值差不多,所以藍色沒紅綠色明顯。

A:
這幾天回顧一下以前的討論發現20171218時,
目前已知同時使用StackHorizontal + Crop + SVSuper + BlankClip
然後再使用MT模式,幾乎每次結果都不一樣。
如果不用以上濾鏡,使用多執行緒還是有機率出錯,
而且很討厭的是,這種可能幾千幀才出現幾個

嗚...當時可能因為這樣我才轉成AddBorders處理,
不過現在我重現不出來當時的情況,忘記當時怎麼弄得
這段時間有更新Avisynth+ r2580
還有更新ffmpeg 3.4.1

不過幾千幀出錯一次也比幾百幀出現好幾次好多了。

K:
可能是AviSynth的MT模式真的有某潛在的記憶體存取問題了
多執行緒程式就是這點難搞
而且出現機率低影響又不明顯
所以通常開發人員不會去深究

A:
特定濾鏡鍊才會發生,
分開單獨測試都沒問題,所以之前測好幾天找不出原因
(雖然現在還是沒找出原因啦...)

----------------------------------------------------------------------------------------
2018.02.12

K:
單獨沒問題的話試試改變部分濾鏡的mt mode如何?

A:
這當時也有試過了Q_Q
當時試到崩潰,因為不是每一次測都會有一樣結果,
後面不少測試打臉前面的測試很多次Orz

可以確定的是,SVP的MT要用下面這組是最好的
NICE_FILTER - mt mode 1, MULTI_INSTANCE - mt mode 2, SERIALIZED - mt mode 3

SetFilterMTMode("SVSuper",             MT_NICE_FILTER)
SetFilterMTMode("SVAnalyse",           MT_NICE_FILTER)
SetFilterMTMode("SVSmoothFps",         MT_MULTI_INSTANCE)

然後其他什麼結果當時也沒試出來 XD

K:
真的沒招了XD

因為問題似乎只發生在"遮蔽Super + Full: false"
有試過將AddBorders的MT設為3嗎?
SVP還是讓它跑預設的mode就好

A:
有試過全域MT(3)+SVP MT預設,不過我忘記結果了Orz
加上現在無法重現,也不知道是哪個環節有問題...

A:
HDR螢幕目前似乎不能很好的校色,
因為HDR螢幕的電光轉換函數(EOTF)通常是固定的,沒得改,
所以背光亮度無法校正的樣子。

K:
gamma可能是固定的(有些螢幕也不能調
但亮度對比色溫這些也不能調嗎?
而且這樣背光會不會比較快老化啊

A:
亮度可以調整,但撥放HDR影片時似乎失效(至少我手機是這樣)
色溫可以調整,對比不能調整,

對比受限於螢幕面板,IPS 大概就是1000:1,
HDR的高對比是透過改變背光來達到的(可能是區域控光吧)。

HDR輸出除了 R G B 外,多了個 HDR meta,
透過計算 R G B 強度以及HDR meta,來決定區塊顯示亮度,
其中轉換亮度的公式取決於螢幕內的EOTF。

這樣說起來,好像實時微調輸出的HDR meta也可以達到校正亮度的目的耶(?
不過好像沒人實作 XD

K:
說到HDR meta
不知道哪邊有HDR->SDR的演算法能看?

A:
因為看不懂演算法,所以不知道哪裡可以找到~"~
mpv player程式碼裡應該有...

HDR->SDR似乎分成兩種,一種是Hard Clip,另一種是Roll-Off,
如果設定相同的話,Hard Clip的效果應該是會接近的,
Roll-Off的話,則因滾降曲線不同,效果會有差異。

或者可以找看看 HDR -> HDR 的算法,
因為顯示器規格不一定完全符合HDR最高的要求,
所以之間也有個EETF轉換函數,
可以參考ITU的BT.2390
https://www.itu.int/pub/R-REP-BT.2390

K:
感謝~沒想到可以往mpv去找
翻到一個討論串
https://github.com/mpv-player/mpv/issues/4997
看來可以用ffmpeg來做
有空再來研究^^

A:
前面那張彗星HDR->SDR的圖片我是用Vapoursynth轉換的

K:
想想這樣似乎沒有參考到HDR metadata?
之前說到每個frame的都會不一樣的樣子
這部份有參考資料嗎?

A:
ITU的BT.2390對於HDR有比較明確的說明。
http://wwwa.itu.int/pub/R-REP-BT.2390

HDR metadata似乎是給HDR螢幕做EETF用的,
因為HDR螢幕不一定滿足影片的參數。(局部峰值亮度丶平均最高亮度)

SDR螢幕似乎就用不太到,
至少我這裡測試不同HDR meta對於madvr的HDR->SDR的結果沒有讓我發覺有變化,
madvr似乎是實時計算平均亮度來調整的,無視影片的HDR meta。

我猜可能是SDR能顯示的亮度範圍太小,
如果依照HDR meta來壓縮亮度的話,畫面會變很灰暗。

K:
我翻了下LAVFilters和ffmpeg的程式碼
就我比較熟悉的mp4檔格式來說
在檔頭裡會有SMPTE-2086 Mastering Display Metadata
和CEA 861.3 Content Light Level
然後解碼後會將這些帶在每張frame的sidedata
所以其實同一個檔案的frame的這些HDR metadata都是相同的

madVR實時計算平均亮度我覺得不太合理
一來有點浪費效能
二來隨著影片播放平均值會起伏畫面變化會很明顯

A:
因為有的HDR片段對比很高,
超出SDR螢幕顯示能力,
如果以固定的方式來壓縮亮度的話,
不是犧牲高亮度區塊的訊號,
就是影片對比會變很低。

madvr計算平均亮度來調整,
是計算數秒內的平均亮度,
所以應該不會有太明顯的變化。
不過在突然劇烈變亮的場景可能會延遲?

K:
只計算數秒內的平均亮度不會和HDR metadata是整片的平均差異很大嗎?
我是覺得這樣的效果有限又浪費效能
madVR應該不會用這方法才是

A:
HDR->SDR比SDR更吃效能,要降一些選項,
這年頭低階顯卡想看個影片也不容易呀XD

K:
我是覺得nv和amd的dxva升頻都太差了
反而內顯得效果好些
如果能有super-xbr等級的話就好了XD

A:
好像有線材可以升頻,之前有看到網友提過

找到了,這篇
https://www.ptt.cc/bbs/PC_Shopping/M.1514820002.A.4E1.html

K:
太厲害了!
居然可以把電視的功能作到線材上
不只要能升頻反鋸齒還要再轉回HDMI訊號輸出
不過不便宜
難怪顯卡都只給最普通的升頻XD

A:
不過缺點似乎也很明顯,
不論畫面是什麼,全都都有處理,
連文字也都有抗鋸齒,細的部分都糊掉了XD

K:
這點倒是還好
只要看影片時再開啟功能就好了

----------------------------------------------------------------------------------------
2018.02.23

A:
之前有提到的 SVP播放HDR影片時會閃爍及嚴重色帶

K:
只看得出閃爍
不過之前好像也有遇過補幀會閃爍的情況?
還是說SVP補出來的缺少HDR metadata造成顯示出來的亮度不一?

A:
之前閃爍的情況是線性光的BUG,
我原本也以為這次也是線性光造成的,有試著關閉SVP的線性光,不過沒有改善。

如果是缺少HDR metadata的狀況,那就要等SVP官方修復了。

K:
這可能要先看AviSynth/VapourSynth有沒有丟棄HDR metadata
畢竟不是在NV12,P010這些裡面而是類似frame的時間戳之類的資料
然後對於補出來的幀的metadata又該怎麼生出來應該也是問題

A:
Avisynth確定無法攜帶這類資料,
前幾天看到網友的文章才想到,HDR-10還要求色域是DCI-P3或BT.2020,
但ffdshow根本不支援這兩種色域。 orz

K:
colormatrix和3D的資料應該也是像HDR用sidedata傳遞

A:
除非從渲染器端來改,把輸出換成正確的色域 + 使用PQ曲線轉換,
這樣就能獲得缺乏部分HDR meta的HDR影片。(會少MaxCLL和MaxFALL)

Vapoursynth應該可以攜帶HDR meta,讓它保存在FrameProps傳遞

1月底時有問人要怎麼添加,不過我弄不出來orz

K:
其實問題是這個sidedata是由LAVFilters和madVR之間
講好一個新的directshow資料格式傳遞
所以VapourSynth不跟隨這個格式是無法讓
madVR這些後端的renderer得到

A:
嗯,
mpv目前好像還不支援直接輸出hdr,
所以hdr meta不存在也有可能。

不過DirectShow播放器只要關閉ffdshow,
統統沒有這些問題,
所以應該是ffdshow的問題。

K:
所以除了madVR以外的renderer也都支援HDR metadata嗎?

A:
HDR metadata有四個
MasteringDisplay_ColorPrimaries : BT.2020
MasteringDisplay_Luminance      : min: 0.0050 cd/m2, max: 1000 cd/m2
MaxCLL                          : 777 cd/m2
MaxFALL                         : 370 cd/m2

由上而下是
後期工程時的顯示器色域丶
後期工程時的顯示器最小/大亮度丶
影片峰值亮度丶
影片最大平均亮度。

基本上補幀不會改變HDR meta,頂多影片平均最大亮度可能會有少許變化,
所以應該是不用太煩惱HDR meta變化。

K:
嘛,反正從現在ffmpeg有支援的格式來看本來就不會變化XD

A:
另外,
有發現部分原生HDR影片就是沒有MaxCLL和MaxFALL這兩項的。

K:
應該是在檔案裡就沒有寫入這些資料
畢竟檔案的格式也是後來才更新的

A:
不知道少了這兩項後,
在HDR範圍小的HDR螢幕上要怎麼顯示呢?

K:
應該就變成非HDR而是10bit影片播放吧?

A:
經測試MaxCLL和MaxFALL很明顯對於HDR螢幕輸出的亮度有影響,(HDR->SDR似乎沒影響)
推測可能顯示器色調映射有關聯。

前幾天有去翻了一下線性光的說明,
因為人眼對於光線強度變化的程度不一,對於暗處變化較為敏感,
所以添加了Gamma參數,亮度較低處的色階變化較小,
Luma數值與實際亮度關係非線性,導致在計算中間值時會有誤差
以下圖來解釋,橫軸為Luma數值,縱軸為實際亮度

計算最暗與最亮中間的50%亮度,
若直接取Luma=0.5的話,實際亮度只有0.2左右,而不是0.5。
實際上應該Luma約為0.75才是正確的50%亮度。

所以在計算時,最好都轉換成線性光來計算,才是正確的。
不過手繪動畫有描黑邊的習慣,
SVP在運算時,如果使用線性光的話,
邊線可能會有閃爍/吃線的現象,邊線亮度 0.0 -> 0.5 -> 0.0,
若是關閉線性光,由於其特性
邊線閃爍的情況可能會有所減緩,邊線亮度 0.0 -> 0.2 -> 0.0。

換句話說,
因為手繪動畫有描黑邊這種不自然的畫面,
導致使用線性光計算的效果不全然是正面的。

但如果是密集的黑白相間畫面移動時,
關閉線性光則會造成明顯的閃爍,亮度變化不均勻。

K:
這段我要花點時間消化XD

A:
線性光計算對於漸層類型的畫面表現很好,
不過對於Dirac delta function(線條)這類畫面有時候會比較差。

現實生活中大多是漸層或step function這類變化,
那線性光計算的效果普遍是正面的,
所以真人電影開線性光計算應該會比較好。

日系手繪動畫因為主體有描邊(線條),
用線性光計算可能會比較差一些。

K:
原來如此
不過因為效果好像沒有很明顯到讓我察覺
所以我都讓它保持預設的開啟就是


2 則留言:

  1. 菊苣的真是有毅力啊,差不多持續了一年的研究。今日有幸在google上搜到你這篇文章,真是太幸運了。

    回覆刪除
    回覆
    1. 會有這篇文章有很大一部分要歸功於Kevingwn大,
      不然就我自己一人也不知道SVP可以調整這麼多,
      不過最近更新頻率應該會趨緩,
      今年8~9月時主要在開發新參數,因此更新很頻繁,
      現在大致參數已經漸漸穩定了,在微調細項。

      很感謝您的閱讀,
      如果疑問都可以提出來,一起討論,
      若有意一同研究參數也十分歡迎。

      刪除

熱門文章