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.