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

Точность преобразования srgb -> linear

Страницы: 1 2 Следующая »
#0
1:41, 23 мая 2020

День добрый,
Работаю с HDR цветами. Создаю в рантайме текстуру, сохраняю её в EXR формат и читаю текстуру в шейдере.
При конвертации srgb-> linear теряется точность. Как можно её минимизировать?
Брал формулы отсюда
http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html?m=1

Если кодирую мировую позицию (диапазон от -100 до 100 юнитов) с точностью half, то погрешность почти не заметна (после преобразования srgb->linear).

Но, если кодирую целые числа от 0 до 100, а затем нормализую результат после преобразования в шейдере srgb->linear, то слишком большая погрешность.
Если нормализовать числа до стадии записи в текстуру, то точность после преобразования в шейдере srgb->linear уже выше, но недостаточна.
Как корректно закодировать целые числа в текстуру, с этими упоротыми преобразованиями и уменьшить погрешность?


#1
2:28, 23 мая 2020

Kripto289
Эм. А банально использовать штатную формулу, а не аппроксимацию - не подходит?

И вообще, можно подробнее - что делается?
Если записываются произвольные числа, не имеющие отношения к цветам ("кодирую мировую позицию (диапазон от -100 до 100 юнитов)") - так зачем sRGB, почему не интерпретировать текстуру, как линейную сразу?

#2
3:01, 23 мая 2020

FordPerfect
Что за штатная формула?
Я бы предпочёл вообще не использовать в шейдере преобразование.

Подробнее кодирую позицию вершин меша.
Движок unity. Я перестал понимать как там эта убогая конвертация работает. В мануалах пишут что с hdr текстурами и render texture srgb игнорируется. Но при сохранении и чтении такой текстуры, в шейдере результат не корректный, пока нет гамма преобразования. Но документация утверждает что оно не нужно. Как-то все через жопу у них сделано.

#3
(Правка: 3:05) 3:04, 23 мая 2020

Danilw
> exr сохраняет raw-значения же, откуда srgb
>
> откуда ты взял преобразование вообще
Так экспортер unity так текстуру читает, игнорируя принудительное отключение srgb.
Я без понятия как еще принудительно указать ему, что бы использовалось линейное пространство

#4
(Правка: 3:57) 3:57, 23 мая 2020

Danilw
> не пользуйся этим
Я бы с радостью, но не хочу (с) фиби

Danilw
> (и в названии темы надо это указывать)
Так тема не имеет отношения к юнити. Меня вопрос точности интересует. Как я понял этот баг пофиксили только в 2020 версии, но я вынужден работать с предыдущими версиями.
Поэтому планировал такое

#if UNITY_VERSION_2020_OR_NEW 
{ обычный код } 
#else 
{ srgb -> linear код} 

Danilw
> напиши свой экспортер модулем, или скриптом читай и транслируй байтики в
> текстуру без конвертирования
Так это костыль какой-то. Надо сперва разобраться с проблемой, а не пытаться её обходить.

#5
15:10, 23 мая 2020

Kripto289
так ты определись, тема о srgb преобразовании или о юнити? потому что если она о srgb преобразовании, то его руками вообще никогда не надо делать (более того, оно может быть каким угодно и зависит от платформы). если тема о юнити, то что она делает в этом разделе?

#6
(Правка: 16:36) 16:34, 23 мая 2020

Suslik
> так ты определись, тема о srgb преобразовании или о юнити? потому что если она
> о srgb преобразовании, то его руками вообще никогда не надо делать (более того,
> оно может быть каким угодно и зависит от платформы). если тема о юнити, то что
> она делает в этом разделе?
О преобразовании.
Я не силён в преобразованиях, но если их никто не делает, то для чего эта статья?
http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html?m=1

#7
(Правка: 19:14) 19:11, 23 мая 2020

Danilw
> ты не можешь вообще никак преобразовать rgb->srgb->rgb и в итоге получить
> исходный rgb
> такое просто невозможно
Я в первом сообщении спросил как можно уменьшить погрешность, а не убрать ее.

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

Прими успокоительное. Я записываю симуляцию жидкости в текстуру, для дальнейшего чтения в рантайме для движка unity.
У тебя уже горит. Расскажи свой подход? Ты же современный эксперт, не то что я, совок.
Первое твоё ноухау будет "откажись от юнити и пиши свой движок"? Невероятно. Так и вижу как в компании, под твоим крылом, на первую проблему меняется движок.
Второе ноухау это транслировать hdr цвет в байтики? Учитывая что стандартный texture2D делает ту же самую конвертацию, что и стандартный экспортер, то твое решение такое же нерабочее.

#8
19:13, 23 мая 2020

Danilw
> у srgb нет "стандартной формулы" каждый ее крутит как хочет
Кто тебе такое сказал?

#9
19:19, 23 мая 2020

Danilw
> я так сказал, проблемы?
> сасай лалка
хех, я тебя понял)

#10
(Правка: 21:08) 21:05, 23 мая 2020

Danilw
> свой движок, или в худшем случае опенсурс движок модифицированный под задачу
Так я делаю проект не для себя. Моя задача лишь небольшая часть проекта.
Если тебе станет комфортнее, представь что я добавляю новую фичу уже в готовый проект.


Danilw
> ты из 2001 года пишешь походу
> какое текстуре2д в 2020
Texture2D это класс unity для создания и модифицирования текстур на лету. Любая текстура в проекте это texture2D.

Danilw
> какой hdr цвет
> ничего не понял
Байт вмещает в себя 255 значений. HDR цвет (на примере half точности) вмещает в себя 65к значений, включая дробную часть. Извращаться с кодированием 2-х байтов в 1 half я не умею и не хочу.
Это что ни на есть
Danilw
> подход к задаче у тебя просто поражает


Danilw
> хотя понял-вот это то что Юнити с людьми делает
А что юнити делает с людьми? Я как VFX художник, спустя несколько лет изучения unity могу написать в движке например объёмное кастомное освещение, запечь симуляцию жидкости, и т.д. Выучил шейдера и C#.
Да конечно, я не знаю внутреннюю кухню, потому что не писал свои движки, но я пытаюсь в ней разобраться. А не язвить на форуме на тему "выбрал плохой инструмент, сасай лалка"

Ох уж эта унылая тема "кококо он пишет на unity, кококо какое он днище, не то что я эксперт".

#11
2:18, 24 мая 2020

> Что за штатная формула?
https://en.wikipedia.org/wiki/SRGB :
Изображение
Изображение

#12
(Правка: 2:40) 2:31, 24 мая 2020

FordPerfect
> > Что за штатная формула?
> https://en.wikipedia.org/wiki/SRGB :
О я её оказывается использовал

inline float LinearToGammaSpaceExact (float value)
{
    if (value <= 0.0F)
        return 0.0F;
    else if (value <= 0.0031308F)
        return 12.92F * value;
    else if (value < 1.0F)
        return 1.055F * pow(value, 0.4166667F) - 0.055F;
    else
        return pow(value, 0.45454545F);
}
Но она весьма дорогостоящая. У меня 3 текстуры (xyz xyz xyzw), то вызывать 10 раз такую функцию это слишком жирно. Но она давала минимальную погрешность из всего того что я находил, и артефакты были всего лишь в парочке пикселей. Но раз уж это штатная формула, и других более точных формул уже не будет, то и тема уже не актуальна.

Кто-нибудь объясните человеческим языком, почему в современных движках без CRT мониторов (которые вымерли лет 15 назад) нужна эта гамма-коррекция и почему не использовать линейное пространство для всего?
Почему бы самой видеокарте не проводить гамма-коррекцию для вывода на монитор, а не разработчикам заботиться об этом?

#13
4:27, 24 мая 2020

Kripto289
> При конвертации srgb-> linear теряется точность.
Ну собственно так и должно быть. SRGB грубо можно представить как корень от цвета, фактически это растягивает область серого - картинка становится белесой. Обратное преобразование (квадрат от srgb) все ставит обратно. И все было бы замечательно, если бы не дискретность цвета. Поскольку у цвета обычно всего 256 уровней, то растягивая шкалу в середине, мы вместо шага 1/256 имеем там 1/128. (цифры разумеется условные, просто что бы было нагляднее). При любой манипуляции с цветами эта погрешность вылазит. И ничего тут поделать нельзя.

Не знаю как в юнити, можно ли это, но я в критических местах просто использую FLOAT формат. 16 бит вместо 8 решают все проблемы с дискретностью радикально.

#14
4:44, 24 мая 2020

Kripto289
> Кто-нибудь объясните человеческим языком, почему в современных движках без CRT
> мониторов (которые вымерли лет 15 назад) нужна эта гамма-коррекция и почему не
> использовать линейное пространство для всего?
> Почему бы самой видеокарте не проводить гамма-коррекцию для вывода на монитор,
> а не разработчикам заботиться об этом?
Нужно для того, чтобы в 24 бита вошло больше зрительно различимых цветов.

Kripto289
> Но она весьма дорогостоящая. У меня 3 текстуры (xyz xyz xyzw), то вызывать 10
> раз такую функцию это слишком жирно.
Сколько бит на компоненту у тебя в исходной текстуре? Если не больше 16, то можно предрассчитать функцию для всех аргументов заранее, записать в массив/текстуру и затем в рантайме просто брать число из массива/текстуры.

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