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

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

Страницы: 14 5 6 712 Следующая »
#60
13:37, 1 дек. 2017

kas
> > sRGB в PBR нужно только на альбедо. Но даже альбедо не надо перерисовывать
> это не правда конечно же. зависит от того кто и как арт делал

ты, главное, не останавливайся... мысль продолжи


#61
13:46, 1 дек. 2017

innuendo
> ты, главное, не останавливайся... мысль продолжи
выносить цветовое пространство в настройки ресурсов, дабы исправлять рукожопие в один клик

#62
13:52, 1 дек. 2017

kas
альбедо как была создана в линейном пространстве, так она и остается, просто при загрузке автоматически будет компенсироваться, что бы при преобразовании в гамму 2.2 она стала выглядеть так же, как и была до преобразования.

#63
13:55, 1 дек. 2017

std::cin
> Никто не хочет написать термин для сайта про sRGB?
Как-то так:

+ Показать

На термин длинновато, на статью - коротковато. Что с ним делать?

Ну и комментарии приветствуются.

#64
13:57, 1 дек. 2017

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

#65
14:14, 1 дек. 2017

FordPerfect
> Ну и комментарии приветствуются.
Если причины использования поместить сразу за расшифровкой аббревиатуры, то станет много лучше, на мой извращенный вкус.

#66
15:00, 1 дек. 2017

Suslik
Ну тогда и не в термины, наверно.

#67
16:25, 1 дек. 2017

"sRGB - форма сжатия динамического диапазона, пришедшая из лохматых восьмибитных времён и эксплуатирующая тот факт, что человеческий глаз на самом деле воспринимает не яркость, а логарифм от оной. Реальная физическая яркость является экспонентой от того числа (0..255 или 0.0..1.0) к которому мы все привыкли, поэтому любые расчёты (а особливо блендинг) где с этими числами пытаются работать, как с линейными величинами, дают на выходе жопу."

Так для первого абзаца сойдёт?

#68
18:27, 1 дек. 2017

про жопу особенно интересно. продолжай ))

#69
19:26, 1 дек. 2017

kas
> это не правда конечно же. зависит от того кто и как арт делал
Конечно зависит. Поэтому ориентируемся на грамотных дядек, которые знают что делают.

#70
4:03, 2 дек. 2017

А при чём тут ЭЛТ-мониторы? Сейчас все проф.мониторы идут с 99% охватом цветового пространства sRGB :)

#71
11:41, 2 дек. 2017

да ну? у меня на работе проф нэк итам охват поболе сргб будет....

#72
13:46, 2 дек. 2017

barnes
Ну я о том, что sRGB удел не только лучевых трубок, но и LCD с ним работают, и это вполне актуальное цветовое пространство.
Я позже обязательно разберусь, как с ним работать и добавлю в свой движок.
У меня просто Viewsonic, а они поддерживают только 99% sRGB. А старый NEC не знаю даже, что поддерживал.

#73
14:13, 2 дек. 2017

Даниил, там цветовой охват еще не все. Если дельта больше трех, то монитор для работы с цветом мало пригоден

#74
22:41, 22 дек. 2017

Попытка разложить по полочкам кусочки темы у себя в голове (в преддверие необходимости прикрутить sRGB в своём движке):

0) sRGB это нелинейное RGB пространство, которое более оптимально (с точки зрения человеческого зрения) распределяет точность, и приблизительно соответствует гамме-кривой со степенью 2.2. Выполнять линейные операции (такие как blending, освещение) с sRGB цветом нельзя - необходимо сначала перевести цвет в линейное пространство RGB (а потом обратно в sRGB, если надо); приблизительно (но не абсолютно точно) sRGB -> RGB переводится возведением в степень 2.2, а обратно RGB -> sRGB возведением в степень 1/2.2. Всё это НЕ относится к Alpha компоненте - она всегда линейна, даже если основной цвет в sRGB, и НЕ подлежит возведению в степень 2.2 (при ручной конверсии).

1) sRGB текстуры нужны для корректного (и автоматического) чтения цвета из текстуры, созданных, собственно, в sRGB пространстве (а создавать их имеет смысл для более эффективного использования 8-бит на компоненту с учётом человеческого зрения; хотя изначальный смысл - возможность вывода картинки на экран без конвертации цвета, предполагая что экран в том же sRGB цветовом пространстве).

2) Для чего нужно создавать sRGB rendering target (FBO с sRGB текстурой) в случае использования промежуточных внеэкранных буферов кадра, если при последующем чтении из sRGB буфера снова понадобится переводить цвет в линейное пространство (RGB -> sRGB -> RGB)? Результаты вычислений будут правильными и при использовании линейного RGB буфера! Но использование sRGB для промежуточного хранения цвета позволит сохранить точность именно в видимом человеческому глазу диапазоне (хотя чтобы понять с чего вдруг, придётся немного напрячь мозг). Разумеется, это имеет смысл только для 8-бит (на компоненту) RGB(A) текстур, тогда как для 16/32-bit float текстур sRGB не имеет смысла (с точки зрения упаковки), и таких форматов текстур просто нет (соответственно в случае с HDR нет смысла думать об sRGB rendering targets). Помимо использования sRGB текстуры для FBO attachment, необходимо ещё и активировать флаг (в OpenGL) для проведения, собственно говоря, преобразования при записи.

3) Самое мутное, это определить, в каком же цветовом пространстве (линейном, sRGB или ином) находится буфер окна - разумеется, с той точки зрения, что в него записывать (и читать), а не то, как оно реально хранится. Следует предположить, что он должен быть sRGB (или около того) на всех современных системах. Но если это так, то какого чёрта драйвер не выполняет конвертацию из линейного RGB в sRGB сам? И каким образом правильно указать, чтобы драйвер это делал?

4) Далее следуют пространные баги в реализации OpenGL драйверов, различное поведение драйверов Intel/AMD/NVIDIA, недописанное кривое описание расширения ARB_framebuffer_sRGB и отличия в описании логики между OpenGL и OpenGL ES. Теоретически, всё должно заработать правильно просто указанием sRGB формата текстуры и включением автоматической конвертации; но судя по топикам на форумах, это вовсе не так. Так же придётся подумать, что же делать с устаревшим, но всё ещё актуальным, железом, не поддерживающим sRGB текстуры (OpenGL ES 2.0).
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_framebuffer_sRGB.txt

5) Непонятно что делать с цветами, которые задаются не через текстуры. Очевидно, что при задании background цвета (как в первом посте), пользователь ожидает увидеть тот же цвет, что и был задан - то есть такие параметры задаются как бы sRGB, но ведь не предусмотрено нормального API для конвертации цвета помимо текстур (учитывая, что возведение в степень 2.2 не совсем тоже самое, что будет делать OpenGL драйвер)! Тоже самое касается и основного цвета материала (если материал задан без текстуры).

innuendo

kas
sRGB в PBR нужно только на альбедо. Но даже альбедо не надо перерисовывать

это не правда конечно же. зависит от того кто и как арт делал

ты, главное, не останавливайся... мысль продолжи

В спецификации glTF 2.0, к примеру, явно указано, что текстуры baseColorTexture (альбедо) и emissiveTexture должны быть в sRGB (остальные текстуры - нет).
Страницы: 14 5 6 712 Следующая »
ПрограммированиеФорумГрафика