LINUX.ORG.RU
Ответ на: комментарий от mx__

imho: Получается что directx, opengl, vulkan рендерят sdr по дефолту, и нужно сообщить им как-то чтобы генерировали hdr, что и делаю DE если умеют. Потому что sdr игра знать не знает что такое hdr. Но да лучше чтобы по дефолту сразу hdr везде был конечно, только это не работает наверное.

loglogav
() автор топика
Ответ на: комментарий от loglogav

Да я теперь сам репу чешу, что это за фигня такая. Раз моник HDR дрова HDR разве не пофигу что там в ДЕ и игре? Странно как то.

У меня есть подозрение что кнопка HDR в DE и играх это для того чтобы иметь возможность отключить HDR на своем HDR монике (хз зачем это нужно но всеже) может кому то не нравится обоженые цвета.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

может кому то не нравится обоженые цвета

Перенасыщенные цвета - это последствия отсутствия конверсии при выводе картинки имеющей низкий цветовой охват (sRGB, например) на монитор с широким цветовым охватом (100% DCI-P3, например).

red75prim ★★★
()
Ответ на: комментарий от cobold

А откуда информация про дополнительные цвета возьмётся? У hdr пикселя 16 бит на канал

Вот к этому вопросу я и хотел подвести форум в свете примера в теме ! Вывод: windows как обычно всех дурит?

mx__ ★★★★★
()
Ответ на: комментарий от loglogav

Получается что directx, opengl, vulkan рендерят sdr по дефолту

Нет, они рендерят так как скажет разработчик, в карту цветов большей битности RGBA16+16+16+ HDR или меньшей RGBA8-8-8-, часто при отложенном рендериге пишут в HDR, а потом применяют тональную компресиию перед выводом на экран.

Потому что sdr игра знать не знает что такое hdr

HDR это просто маркетинговое понятие, игры оперируют часто данными в разы большей битности, например могут быть карты цветов 32 бит на канал в HDR это 10 или 11 бит всего. И потом они в финале приводятся до 8 бит на канал.

В шейдерах может использоваться half или float для вычислений картинки с последствиями. И так далее.

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

HDR это не что-то особенное, это тупо тупая больная разрядность картинки, и если игра выдаёт картинку в формате R8G8B8 а ты привёл её своими приколами к R10B10G10 то никакого HDR не будет, просто нет данных чтобы отобразить их. Не, хаками, выкручиванием цветов с добавлением промежуточных цветов можно, и видимо это оно и есть.

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

Короче если там что-то и преобразуется, то это как минимум на 50% просто выкручивание гаммы и запихивание результата перед выводом в карту цветов большей битности чтобы при выкручивании гаммы не переполнились значения и всё.

В теории можно для opengl mesa сделать графический хук, который будет перед glSwapBuffers перехватывать картинку, обрабатывать ещё, подмнять и потом вызывать уже настоящий glSwapBuffers. Ну или типа того, смысл будет тот же.

Наверняка такое уже есть, нужно просто хорошо поискать =)


P.S. Буду рад если меня кто-то поправит.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

если игра выдаёт картинку в формате R8G8B8 а ты привёл её своими приколами к R10B10G10 то никакого HDR не будет

А тупо заменить R8G8B8 на R10B10G10 прямо в opengl нельзя? Понимаю что текстуры не изменить, но сглаживание дыма, тени или прочие динамические данные которые на лету генерируются?
Програмист написал например R8G8B8, но опенгл перехватил и подменил это на R10B10G10.

fucpsy
()
Последнее исправление: fucpsy (всего исправлений: 1)
Ответ на: комментарий от fucpsy

Это в теории частично может сработать, если полноценные float пишутся в итоговую текстуру с преобразованием

псевдокод

uint8_t R = color.r * 255
uint8_t G = color.g * 255
uint8_t B = color.b * 255

Но не будет иметь смысла если для вычислений внутри используется half. Просто записью в карту цветов большей битности ты не спасёшь данные если они уже предусмотрительно ограничены разработчиком чтобы не переполнялись цвета.

В теории можно подменить вызовы конечно, но эт надо точечно, я бы попробовал хуки-перехватчики для mesa написать, для переопределения поведения, но мне тупо не на чем увидеть результат, в смысле адекватный результат, а не месиво.

Ах да, стоит упомянуть, насколько я понял (почитал) виндовый авто хдр игра должна явно поддерживать, тоесть разработчик игры должен прям для винды сделать возможность отдавать картинку на экран, минуя тональную компрессию в SDR, так что никакой магии нету. Просто винда сообщает игре что у пользователя моник может в хдр и игра просто выдаёт другую картинку. Так что это не фича винды, а просто договорняк, работающий только с некоторыми играми, а для других игр возможно оффтопик делает просто фейк коголовного мозга полшьзователя, выкручивая цвета пост эффектом и называя это ХДР! =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от fucpsy

Была утилита driconf потом была adriconf обе загнулись, они позволяли вроде менять типы текстур, и навешивать пост эффекты на что угодно, менять форматы и прочее, короче вклиниваться немножко.

Можно посмотреть как в них было сделано. Но в целом это переопределение настроек mesa и LD_PRELOAD с подменой функций наверное.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от mx__

Вот к этому вопросу я и хотел подвести форум в свете примера в теме ! Вывод: windows как обычно всех дурит?

Дурение началось уже там где кто-то придумал впаривать домохозяйкам (и не только им) какую-то чушь, назвав её HDR и придумав кучу рекламных статей о том как оно круто. Ну а винда не против поучаствовать, да. Эпл скорее всего тоже примазался.

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

firkax ★★★★★
()
Ответ на: комментарий от fucpsy

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

Чёт даже интересно стало, сел писать программу. В чём суть, мы сможем перехватывать вызовы glgentextures получая их ID также мы может опеределять был ли это вызов до glgenrenderbuffers или просле, если до это просто загрузка текстуры из загруженной в память RGB (или иного) карты цвета, если после это вероятно MRT или просто промежуточная текстура, в любом случае это одна из текстур в которую пишет шейдер, так как в отложенном рендеринге несколько этапов рендеринга это может быть карта нормалей, карта цветов, карта глубины, некоторые из них можно отсечь и определить кто есть кто, но некоторые будут обычными RGB картами, и вот если одна из таких промежуточных текстур имеет RGB больше 8 на канал, можно подозревать что это промежуточное HDR представление в рендере, ID этой текстуры можно схоронить.

Далее, мы отпускаем игру делать свои дела до момента пока она не вызовет glswapbuffers и вот тут-то мы её снова ловим, мы сохранили ранее предположительную HDR текстуру, теперь мы вызываем свой шейдер и отдаём в неё эту текстуру, затем перерисовываем backbuffer и вызываем уже настоящий glswapbuffers таким образом, мы можем выводить на экран любой этап рендеринга, подменяя им уже отрисованную картинку, так как мы просто запишем её поверх.

В теории должно сработать, но есть минус, так как игра может для своего внутреннего пайплайна рендеринга генерировать десятки текстур мы просто так не угадаем что ловить, так что библиотека перехватчик должна запускать GUI который будет в динамике ловить вызовы и идентификаторы текстур и так же в динамике переключать наши вызовы перехватчики и обычные вызовы. Типа будет открываться окно в котром будет динамический список ID текстур и обозначения они внутри redertarget или просто текстуры, кликом по элементу списка мы инициируем подмену вызова glswap и эту текстуру выбранную рисуем поверх уже готовой картинки.

В мыслях так, только с гуем проблемы хз как делать, оверлей нахреначивать такое себе, а что-то внешнее хз даже. Но без него будет лютый гемор, так как потребуется запуск игры, смотреть лог, потом задавать например через ENV что перпехватывать и потом снова запускать, и если не повезло то всё по новой, а в динамике было бы прикольно.

Буду пробовать. Если что-то получится отпишусь.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от firkax

HDR это больше про маркетинг, да. Но всё же определяет его не матрица, а данные. Это буквально на картинка где 5 бит на канал и картинка где 8 бит на канал. Понятно что 8 бит на канал сможет содержать больше информации в изображении, например градиент цвета будет градиентом, а не резкими границами переключения оттенков цвета, тоже самое и с яркостью, ну в смысле никакого цвета не существует, есть просто яркость каналов цветов. И в случае 5 бит на канал тёмная лягушка в тени будет просто ничем, там будет просто чёрная тень со значениями цвета 0 при 8 бит на канал там будет видно силуэт лягушки. Тоже самое и с SDR 8 бит на канал и HDR 10 или 11 бит на канал. В пограничных ситуациях просто будет больше видно,НО только если уже есть эта информация которую можно увидеть. Если есть RGBA8888 картинка, хоть ты лопни и тресни переведя её в RGBA101010 даже ничего нового в ней не увидишь, и никаких улучшений там в принципе быть не может и оно не может быть HDR в принципе разницы будет ровно 0 и вот тут ан поле выходят маркетологи, ведь технически монитор HDR он отображает 10 бит на канал из данных где 10 бит на канал, значит картинка HDR, а то что никакой разницы для этого случая между SDR и HDR нет от слова совсем им пофигу, так как они тупо берут и гамму +1 делают, цвета стали более яркими, и типа а вот и разница!. Так что тут двоякая ситуация, с одной стороны HDR это просто про более детальные данные, с другой стороны это про приведение форматов данных, формат то стал HDR технически, только вот сами данные то не стали.

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

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от anonymous

Тогда нужны данные для отображения больше 8 бит. Иначе ты получишь туже самую картинку, учитывая количество HDR контента это будет в 99,9% случаев и на HDR мониторе ты будешь видеть тоже самое что и на SDR мониторе. Иными словами тебе нужен HDR тогда, и только тогда когда у тебя есть явный HDR контент специальным образом сохранённый.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от Aceler

Это если у него железо новое, а иначе

dron@gnu:~$ gamescope glxgears
[gamescope] [Info]  console: gamescope version 
...
[gamescope] [Info]  vulkan: selecting physical device 'llvmpipe (LLVM 19.1.7, 128 bits)': queue family 0 (general queue family 0)
[gamescope] [Info]  vulkan: physical device supports DRM format modifiers
[gamescope] [Error] vulkan: physical device doesn't support VK_EXT_physical_device_drm
terminate called without an active exception
Аварийный останов
dron@gnu:~$ 

Вулкан как всегда «кроссплатформенный» :)

Но всё же учитывая что ТС заикался про вулкан, видимо всё хорошо с ним, тогда

Арчевики как всегда молодец :D

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от anonymous

А должна быть по сути та же самая, если есть SDR пиксель со значением R=50 G=70 B=115 то по хорошему он должен отображаться что на SDR что на HDR одинаково в итоге на экране, разницы быть не должно (ну это я по своей логике, ибо сфигали она должна быть то), просто если значения цветов будут R=525 G=700 B=920 SDR монитор покажет кашу, а HDR покажет эти цвета как есть. Значит там есть у тебя крутилка которая меняет тон, попробуй найти и выставить на ней, ну эмм типа чтобы она ничего не меняла.

Или да, как выше сказали у тебя SDR моник, и включение ограничивает тональность, опять же, даже если так, где то есть крутилка.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

по хорошему он должен отображаться что на SDR что на HDR одинаково в итоге на экране, разницы быть не должно

Ну это по-хорошему, если в мониторе аппаратный LUT. В большинстве случае будет абы как и надо будет настраивать вручную как миниму яркость.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Ой тут тогда надо ещё калибратор ну и всё пошло поехало, захотел челобречик поиграть в майнкрафт на ХДР, а по итогу устроил дома фотолабораторию :D и читает с моноклем и тростью научные статьи о цветопередаче и прочей колористике.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от mx__

А кто его знает, что у них там внутри. А под названием может быть всё что угодно, названия это торговые марки, а не технические обозначения.

Новые игры по API получают данные что им отдавать на отрисовку, тут может быть всё честно, старые через шейдера прогоняют, вот и всё. А уж что как и в какой мере в точности, какие алгоритмы применяются для симуляции HDR в старых играх, хрен его знает, скорее всего сглаживают градиенты и выкручивают гамму.

По нормальному, у тебя просто должен быть HDR монитор и игра которая просто выдаёт картинку с 11 бит на канал и всё. Ну или фильм. Всё просто. А эти автохдры это тоже самое что взять 16 битную картинку и на truecolor мониторе сделать из неё 24 или 32 битные цвета, что конечно же напрямую невозможно, как была шакальная, так и останется шакальная.

Дело вообще не в HDR термине и его отображении, мониторах и прочем, суть вся в данных. Вот есть у тебя картинка в ней пиксель в три байта RGB. Не засунешь ты в байт значение большее чем 255, то есть у тебя 255 градаций серого на канал и всё. А HDR это 1024 градации. Вот и вся суть, от этой сути всё дальше и прыгает и называется.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от anonymous

А нафига тогда калибруют дома? =) В любом случае это уже за пределами моих знаний, дальше я только фантазировать начну, так как матчасть в этом плане мне не интересна, и она слишком глубока.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

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

anonymous
()
Ответ на: комментарий от anonymous

Ты думаешь например DLSS произвольную игру с нуля апскейлит нейронкой? Как бы не так, сначала игру запускают на суперкомпьютере где тренируют отдельную сетку специально для этой игры месяц и более.

А ты хочешь бац и поехал =) Не галюцинировать оно может, даже в реалтайме, но это будет как машинистка печатающая 1200 знаков в минуту =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от anonymous

Когда в kde переключаю hdr, то картинка не меняется, если при включенном hdr в кедах переключать на мониторе auto на hdr10 то ничего не меняется, с auto на sdr картинка меняется. При выключенном hdr в кедах наоборот, с auto на sdr не меняется, с auto на hdr10 меняется.
Если включить hdr в игре картинка становится тёмной в меню и тенях, какбудто гамму/яркость понизили, и чтобы увидеть что там в тени нужно в упор глазами к монитору прислониться, но зато реально можно различить что там в тени, без hdr в тенях всё различимо и светло даже слишком, яркие места тип солнце и облака наоборот более различимы стали.

loglogav
() автор топика
Последнее исправление: loglogav (всего исправлений: 2)
Ответ на: комментарий от mx__

В целом, если отбросить предрассудки, и подобные вещи, в сторону, то

  • Итоговая картинка, может отличаться
  • Итоговая картинка, пользователю будет нравится больше чем изначальная

Если это так, то не имеет никакого значения лажа это, не лажа, фейк это или нет, если нравится то хорошо.

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

Откуда в игровом движке Дум1 возметься ХДР.

Если очень сильно захотеть то возьмётся, но придётся поправить исходники.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от anonymous

Нет, просто надо различать формат данных размерностью 11 бит и то что записано в формат данных размерностью 11 бит, формат называется HDR, а записана туда может быть лажа 4битная, а может быть и нет. Ошибкой, которая стала нормой, является восприятие HDR не как типа данных, а как «больше видно, сочные цвета, живая картинка», тут уже маркетологи постарались и надо в беседе уточнять, мы о расширенном качестве изображения говорим, или о представлении типа данных который позволяет сделать расширенное качество изображения, но никак не гарантирует что это так и будет, ибо это тупо 11 (ну или 10) бит на один цветовой канал, едрить.

Так что доктор, твой диагноз идёт мимо, завтра я халат первый одену 😛

LINUX-ORG-RU ★★★★★
()