integer version color conversion(YC48<->RGB(0-4096))

[yumetodo]

https://makiuchi-d.github.io/mksoft/doc/aviutlyc.html#3

YC48<->24bitRGBができるんだから、YC48<->RGB(0-4096)もできるはずだという思い

[yumetodo]

そもそも現在使っている変換行列だと 精度が不十分に思える

[YSRKEN]

実数演算？それとも整数演算＋ビットシフトかしら？

[YSRKEN]

(ぐっと速くなるから微妙な誤差は無視できる、という思想もありますので)

[yumetodo]

いや、Y=4096,Cb=0,Cr=0のときにR=G=B=4096にならないということは、値域が違うからシグモイド関数を誤って適用していることになる

[MaverickTse]

問題はあのmatrixかもしれません。 あのmatrixはこのmatrix solverで 入力は RED YUV: 1219, -692, 2048 RGB: 4096, 0, 0

Green YUV: 2401, -1357, -1717 RGB: 0, 4096, 0

Blue YUV: 462, 2048, -332 RGB: 0, 0, 4096 これらの数値は昔拡張編集で測ってものです

[yumetodo]

rigayaさんの資料だと http://1drv.ms/1gd1T2G

RGB->YUV2は だからYUV2->RGBはその逆行列の っぽい(LibreOfficeのMINVERSEで計算)

Cb,Crが0じゃないときのYUV2->RGBの検証って難しいな・・・

[MaverickTse]

The key thing is that do you observe color distortion visually? If the matrix is way off, running contrast and decontrast in pair with same parameters would also change the image in visible way.

you will need a particular filter in exedit to check the color value if you want. (I forgot the name...)

[yumetodo]

@MaverickTse SigmoidContrastとSigmoidDecontrastは逆関数なんだから、たとえRGB->YUV2,YUV2->RGB変換行列が間違っていても、2つの行列の積が単位行列Eになるかぎり、視覚的な変化は見られません。

変換行列の妥当性は別の方法で検証する必要があります

[MaverickTse]

actually you can try to derive that matrix yourself. I am lazy and use an online calculator, but you can solve it by hand after sampling at least 3 colors. Otherwise, even if you can prove the current matrix is wrong, you can't really fix it.

[yumetodo]

なんだか面倒になってきたので、 https://makiuchi-d.github.io/mksoft/doc/aviutlyc.html#3 の式をそのまま使って24bitRGBとしてsigmoid関数に渡すオプションつけてそれをデフォルトにしようかな・・・。

[MaverickTse]

I would say No, unless you understand how those numbers came about. At lease you need to double check with the internal rgb2yc(), yc2rgb(), or with exedit, as those published data are already many years old and none of them convert to 4097 scale. Again, I would suggest you removing your local fork so that I can transfer the whole repo to you, and remove my name from the version string. Then I won't care what you do. As of the current state of master branch, it is basically none of my work anymore.

[MaverickTse]

Not sure what other computers would be, but using the "Color key" to check for white, (255,255,255) does not translate to 4096

[yumetodo]

but using the "Color key" to check for white, (255,255,255) does not translate to 4096

・・・!?

Acoording to the @makiuchi-d 's document, https://makiuchi-d.github.io/mksoft/doc/aviutlyc.html#3 24bitRGB->YC48 conversion AviUtl version 0.98 does is same as below.

y  = (( 4918*R+354)>>10) + (( 9655*G+585)>>10) + (( 1875*B+523)>>10);
cb = ((-2775*R+240)>>10) + ((-5449*G+515)>>10) + (( 8224*B+256)>>10);
cr = (( 8224*R+256)>>10) + ((-6887*G+110)>>10) + ((-1337*B+646)>>10);

when R:255 G:255 B:255 , conversion result is Y:4096 Cb:0 Cr:0 http://melpon.org/wandbox/permlink/u62ulQrVppA8ivuG

---

Now, I investigated to check 24bitRGB->YC48 conversion AviUtl version 1.00 does is same as that.

https://bitbucket.org/yumetodo/aviutl_color_convert_test

And, the result is same.

---

So, RGB(255, 255, 255) should be converted to YCbCr(4096, 0, 0), and the "Color key" has bug, I think.

[MaverickTse]

You may need to confirm with Ken-kun to see if that is a bug or on purpose. Visually, not going to make a big difference however. That integer math is not very SIMD friendly IMO, as you need another 3x3 matrix for the addition, and extra bit-shift commands

[yumetodo]

@MaverickTse

You may need to confirm

I sent.

[yumetodo]

https://twitter.com/yumetodo/status/1173240914115907584?s=20 https://twitter.com/yumetodo/status/1173240916292902913?s=20 https://twitter.com/yumetodo/status/1173240917748113413?s=20

[yumetodo]

https://twitter.com/__kenkun/status/1173536002448613379?s=20

こちらですが実際の処理では画面上のRGB色を取得しているのではなく内部処理したYCデータから取得しているのでこのようになっている思います。恐らくRGB色空間の飽和オプションの処理誤差の影響だと思いますので外せば期待通りの値になると思います。

飽和オプションってなんだっけ