Войти
ПрограммированиеФорумГрафика

sRGB - для чего? (7 стр)

Страницы: 16 7 8 912 Следующая »
#90
(Правка: 10:46) 10:46, 29 июля 2019

ещё следует учесть, во преобразование linear->srgb и обратно, вообще говоря, определяется вашим железом или реализацией драйвера. гарантируется лишь, что прямое, а потом обратное преобразование даёт исходный цвет. то есть если читать из srgb текстуры, то выборка будет в линейном пространстве благодаря автоматическому переводу srgb->linear, потом при записи этого значения в рендертаргет оно переведётся обратно linear->srgb и гарантируется, что полученный цвет в рендертаргете будет тем же самым, что и в текстуре. однако, если ты делаешь изначальное преобразование по каким-то причинам вручную, то вовсе не факт, что при записи после второго преобразования получишь тот же самый цвет на каком-нибудь иксбоксе, где гамма-кривая подобрана для телевизоров. valve даже выпускал статью, как они боролись с этой проблемой (дисклеймер: через боль).


#91
(Правка: 10:48) 10:47, 29 июля 2019

Suslik
> это неправильно, потому что srgb определяется рендертаргетом.
Это я делаю для вывода текстур, отличных от Альбедо, на экран = это уже не движок, а зачаток редактора объектов.
Т.е. текстуры тупо в 2D выводятся на экран.

#92
10:48, 29 июля 2019

Suslik
Тогда как вариант - заиметь 1D текстуру шириной в 256px, и отрендерить в нее SRGB [0, 255], а потом уже использовать ее,
как таблицу перевода.

#93
10:50, 29 июля 2019

nes
> Странно, что нет встроенной функции, чтоб без этих разветвлений...
самое близкое, что есть — это функция конвертации, реализованная, например, в glm: https://glm.g-truc.net/0.9.8/api/a00161.html#ga61c4f0efdf55c29d9cfbd26141fddef8

но ещё раз повторю — количество случаев, при которых эти функции вообще нужны, можно пересчитать по пальцам одной руки. одному пальцу. и не давая подобную функцию на уровне шейдеров, нам как бы намекают, что этого преобразования лучше вообще избегать.

#94
10:51, 29 июля 2019
Где гамма-кривая подобрана для телевизоров.
valve даже выпускал статью, как они боролись с этой проблемой (дисклеймер: через боль).

https://www.youtube.com/watch?v=Uu0to7YWv1c#t=22
#95
10:51, 29 июля 2019

nes
> Тогда как вариант - заиметь 1D текстуру шириной в 256px, и отрендерить в нее
> SRGB [0, 255], а потом уже использовать ее,
> как таблицу перевода.
таким образом можно сделать прямое преобразование (srgb->linear), но не обратное. на самом деле я не знаю ни одного случая, когда может понадобиться обратное, то есть linear->srgb.

#96
11:05, 29 июля 2019

Suslik
>таким образом можно сделать прямое преобразование (srgb->linear), но не обратное.
Так наоборот же, диапазон значений линейного у нас [0, 255], а диапазон SRGB шире.
Т.о. получается, что обычный линейный RGB более универсальный, а SRGB можно эмулировать дополнительной выборкой из текстуры.
Правда это не очень эффективно по производительности получается...

#97
11:09, 29 июля 2019

sRGB - за что!?

#98
(Правка: 12:01) 12:00, 29 июля 2019

nes
> Так наоборот же, диапазон значений линейного у нас [0, 255], а диапазон SRGB
> шире
диапазон srgb выбран так, чтобы на каждую дискретную единицу 0..255 приходилось как можно более равномерное изменение визуальной яркости. поэтому если хранить не в srgb, то у тебя кодирование получается неоптимальное.

nes
> Т.о. получается, что обычный линейный RGB более универсальный, а SRGB можно эмулировать дополнительной выборкой из текстуры.
то, что ты называешь "обычным rgb", то есть вычисление без преобразований — это на самом вычисление в пространстве srgb (нелинейном) без перевода в линейное. то есть на самом деле до изобретения srgb пайплайна, все вычисления производились в srgb, как будто бы он был линейным, а не наоборот. то есть когда изобрели srgb-пайплан, то изобрели на самом деле не сам srgb (в котором всё всегда и хранилось) а перевод из него в линейное пространство для выполнения промежуточных вычислений.

#99
12:02, 29 июля 2019

Suslik
Ну это если подразумевать под линейностью специфику человеческого зрения, тогда да.

#100
(Правка: 12:08) 12:05, 29 июля 2019

nes
это не особенность зрения, это особенность цветопередачи мониторов. потому что если чередовать полоски цвета (255, 255, 255) с полосками (0, 0, 0), то они при усреднении(не только визуальном, но и при количественном измерении интенсивности излучаемого монитором цвета) дадут не цвет (128, 128, 128), а (187, 187, 187), потому что цвет пикселя (который ещё со времён мамонтов хранится в пространстве srgb) складываются нелинейно.

#101
12:08, 29 июля 2019

Suslik
Странно тогда, почему до сих пор не научились в мониторы с линейным изменением интенсивности RGB.

#102
(Правка: 12:13) 12:13, 29 июля 2019

nes
> Странно тогда, почему до сих пор не научились в мониторы с линейным изменением
> интенсивности RGB.
потому что на существующих мониторах можно просто копировать srgb данные из текстуры в интенсивность пикселя, вообще минуя srgb-linear-srgb преобразование и всё будет работать корректно, если над цветом больше не производятся никакие операции. собственно, именно так работали все легаси рендеры до 2000х годов. если сейчас поменять мониторы, чтобы они принимали линейное значение яркости, то все те рендеры отвалятся, либо для них надо будет как-то костыльно выполнять srgb->linear преобразование на уровне драйвера.

#103
12:19, 29 июля 2019

Suslik
В этом плане мне больше по душе политика яблочников.

#104
20:54, 29 июля 2019

Suslik
> это не особенность зрения, это особенность цветопередачи мониторов.
Не согласен. Это таки связанно с особенностью зрения. Условно есть некоторый цветовой охват человеческого зрения. Цветовой профиль sRGB был разработан с таким учетом, чтобы иметь как можно более равномерную плотность точек в этом пространстве (само собой с учетом возможностей железа того времени). Ну то есть особенности человеческого зрения тут первичны. А цветопередача мониторов тут лишь ограничивающий фактор.

Страницы: 16 7 8 912 Следующая »
ПрограммированиеФорумГрафика