Aby alpha blending fungoval korektne, musi byt proveden fyzikalne korektne.
To znamena sRGB data nejdrive prekonvertovat do linearnich fotometrickych (na to je potreba nejmene 48 bitu barevne hloubky na pixel aby nedoslo k posterizaci), potom provest alpha blending a pak to kovertovat zpet do sRGB na zobrazeni na obrazovce.
Podporuje to recena knihovna?
Jinak vznikaji takove nesmylsne absurdity, ze smichate dve barvy, a vysledek je tmavsi nez obe z nich!!!!
Alpha blending ale i bezna interpolace barev - to je v RGB prostoru problem vzdycky :-) proto taky nektere akceleratory dokazaly uz davno pracovat s YCbCr.
Textury nejsou vetsinou ulozeny v sRGB, ale v linearnim RGB, i kdyz OGL >2.x podporuje i sRGB, konkretne GL_SRGB8 (bez alfa kanalu) a GL_SRGB8_ALPHA8 (s alfa kanalem).
OT: Jinak alpha je vzdycky chapana jako vaha <0, 1> pro blending funkci, neprovadi se s ni zadna gamma korekce ani dalsi operace.
Pri pouziti shaderu je to jedno, tam se da naprogramovat cokoli, i kdyz namisto 48bitovych integeru bude lepsi pouzit normalni (podporovane) floaty, alespon na soucasnych GPU.
"proto taky nektere akceleratory dokazaly uz davno pracovat s YCbCr" - a k cemu je YCbCr, ktery nema zaklad ani fyzikalni, any perceptualni? Tak jedine snad, ze s nim pracuji televize a video formaty, ale to je u alpha blendingu zcela irrelevantni!
Myslis si, ze kdyz se alpha blending udela v YCbCr, bude pak korektni? Ne! Jediny korektni je v linear photometric
To si nemyslim (kdyby to bylo tak jednoduche!), jen jsem pokracoval v tve myslence dal, ze v (s)RGB vlastne nefunguje korektne i mnoho dalsich operaci, tento barvovy prostor pro to nebyl vytvoren (a ano, spousta SW provadi filtraci, interpolaci apod. prave v RGB nebo sRGB ;) Obecne prostory, kde je Y slozka samostatne jsou pro mnoho operaci lepsi, treba tam nenastane tvou zmineny problem ze po blendingu dostaneme tmavsi barvu.