+3～+4でSSE2/SSSE3用コードにSSE4.1が混入していた問題を修正。
Athlon/Phenom、及び65nm世代までのCore2系で例外"0xc000001d"で動かなかったのを解消。
_mm_min_epu16ってSSE4.1ってのにはまった。なんかいかにもSSE2でありそうで…。すみません。
ダウンロード>>
対策として。
#include <intrin.h> を使わない。
CPU の拡張命令ターゲットに合わせて emmintrin.h とかを使い分けるとコンパイル時にエラーにしてもらえます。
ただし、VS2012 では stdafx で std 系ヘッダー使えなくなります。
（std::xallocがintrin.hをインクルードしてしまう）
それでも特権命令違反で落ちるより楽です。
なるほど…やはり使い分けることが重要ですね。
ちょっとインチキっぽい書き方をしてるので、そのへんが疎かになってしまっていました。
このコメントは管理人のみ閲覧できます
うーん、flash3kyuu_debandのことだと思うのですが、やはりやってることは同じだと思うので…
f3kdb(range=31, Y=96, Cb=96, Cr=96, sample_mode=2, dither_algo=1)
とかでどうでしょうか?
(sample_mode=1はちょっと違った感じになりますが、sample_mode=2は似た感じになると思うのですが…)
このコメントは管理人のみ閲覧できます
うーん、ダメでしたか… わたしはこんな感じで満足してしまったのですが…
http://1drv.ms/1lnblkM (bandingMT_sample.zip、プレビュー時のものです)
sample_mode=2だと両方とも処理の方法がほとんど同じなので、sample_mode=2でややデフォルトより強めにかけても違和感をお持ちの場合、結局新たに作っても同じことになってしまいます。(内部の処理形式が異なるため全く同じというわけではないですが、処理方法はほとんど同じです)
もし、感じておられる違和感がプレビュー時のものなら、それはプレビューの仕組みの違いによるものかもしれません。
Avisynthでは(プレビューの方法にもよりますが)色差成分を間引いたもの(YUV420)をプレビューしているのに対し、Aviutlは色差を間引いておらず(YUV444)、色の階調も16倍くらいある内部形式を直接プレビューしているので、その差かなと思います(Aviutlのプレビューはかなり綺麗です)。
違和感がエンコ後のものの場合…ちょっと原因がわからないです…。
