0x4E69676874466F78
commented
2 weeks ago https://www.polyphony.co.jp/publications/sa2018/ тут чуваки делают HDR LUT для 10000 нит, это требует преобразований чтобы подогнать данные до этих 10к а потом обратно. Возможно нам так же нужно.
По хорошему цветами надо рулить не через тонемаппер, а через LUT (look-up texture/table). Задача тонемаппера прижать значения выходящие за низкий динамический диапазон в его рамки, цветовая коррекция там происходит в процессе как побочный эффект этого прижатия. Тем более в HDR у нас не всегда есть возможность использовать тонемаппер руками (EXTENDED_SRGB_LINEAR уже содержит компонент тонемаппера), а LDR тонемапперы даже если их вытянуть вряд ли корректно применимы в рамках HDR вывода. Ознакомиться как работает типичная LUT можно тут: https://lettier.github.io/3d-game-shaders-for-beginners/lookup-table.html Но это не наш случай, этот вариант расчитан на LDR, а нам надо HDR. Юнити для HDR использует Alexa LogC (El 1000) https://xibanya.github.io/UnityShaderViewer/Library/PostProcessing/Colors.html При этом если для LDR использовались LUT-текстуры 1024х32, то для HDR там CUBE файл который можно получить например от Photoshop или от DaVinci Resolve. CUBE файл это довольно простой текстовый файл, но совсем некомпактиный и неоптимальный. Есть ещё 3DL файл который раза в два компактнее, но всё равно текстовый. Мы могли бы хранить эти значения в текстурах как типичные LUT-текстуры только вместо 8бит, 16/32бит float. Можно было бы сгенерячить нейтральную текстуру в формате OpenXR и работать с ней в darktable, потом этот EXR преобразовать в KTX2, без сжатия (со сжатием думаю поплывут цвета). Comressonator умеет работать с OpenXR.
Альтернативный вариант это не пытаться использовать таблицу, а манипулировать шейдерными функциями цветокоррекции, которым пробросить через UBO параметры читаемые из файла предустановок цветокоррекции (коих может быть множество). Это потенциально будет дороже по вычислениям чем готовая текстура.
Низкий приоритет.