Жаль, была надежда что хотя бы в AndroidTV это вменяемо сделано :) На WebOS официально это не работает, насколько я знаю, и народ ставит ломанные прошивки с эксплоитами, с которыми очень не хотелось связываться.
Я думаю, что так сделано для минимизации лага при отображении картинки с ПК. Штош, продолжаем сидеть на DirectX, видимо альтернатив пока не предвидится.
Касательно лага — у себя практически не наблюдал, напротив у меня при восроизведении видео с Jellyfin клиента — подсветка обгоняет картинку) Поэтому и добавил параметры задержки.
Ага, то есть анализируется, по‑видимому, не то, что непосредственно на экране, а картинка из буфера плеера. Скажите пожалуйста, Вы случайно не тестировали софт, когда происходит трансляция картинки с внешнего HDMI источника (например, ПК)?
А HDR должен автоматически конвертироваться в SDR через MediaProjection API (8-битный RGBA_8888).
Ясно, спасибо за информацию. Загуглил — вроде бы да, MediaProjection кроме RGBA_8888 в другие форматы пока не умеет :(
Интересно узнать, как обстоят дела с лагом и FPS, а также с HDR — оно там по‑настоящему его обрабатывает или в SDR переводит? То есть именно сам процесс быстрого захвата картинки и анализа. Сам использую DIY подсветку на ПК, были мысли перенести анализ картинки из ПК в сами экраны, но неясно насколько хорошо это будет работать, и стоит ли результат всех танцев с бубном.
Nvidia одно время пыталась это реализовать в виде VXGI, но не взлетело. В изначально воксельных играх (типа Minecraft) это работает.
В остальных случаях приходится одновременно держать в памяти воксельное и обычное представления мира и синхронизировать их. Это кушает память, ресурсы и генерирует потенциальные баги.
Тупые численные методы со временем почти всегда побеждают более хитрые сложные алгоритмы, как только появляются соответствующие вычислительные мощности.
Только вот имхо, трасировка пути — это уже настоящее, а будущее — это нейрорендеринг, а потом и комплексный нейросинтез развлечений в реальном времени под индивидуальные предпочтения. Когда игра сможет для каждого человека индивидуально придумать историю, атмосферу, антураж, персонажей, ситуации, диалоги и прочее по его — игрока — предпочтения. А графика отойдёт на второй план, с ней уже почти все проблемы решены.
Предположу, что существуют разные тетрахроматы с разным спектром чувствительности четвёртой колбочки.
Тетрахромат Кончетта Антико рисует картины, на которых изображает обычными цветами то, что видит сама глазами
Так или иначе, то, что у обычных людей сливается в один цвет, тетрахроматы способны видеть как отдельные оттенки. Что‑то типа биологического 10-битного режима цветности.
Там сначала выбираешь небольшой участок изображения, на котором отчётливо видно, как размыт какой‑либо объект. По этому участку оно вычисляло ядро свёртки, по которому, с его точки зрения, было размыто изображение. Причём, нехилого такого размера — можно и 300×300 пикселей сделать. Это могло быть и радиальное размытие, и размытие в движении, даже по сложной траектории, а не просто по прямой. Ещё, по‑моему, можно было загрузить своё ядро из картинки.
И вот далее по этому ядру свёртки оно пыталось деблюрить картинку. В принципе работало, но не то что бы прям хорошо. На 4 с минусом.
Была ещё фишка, что для разных участков картинки можно было указать/вычислить разное ядро, и оно к разным частям применяло разный деблюр, плавно переходя от одного ядра к другому.
Хотелось бы увидеть сравнение результатов при разрядности 8, 16 и fp32 бит на канал. И что будет, если заблюренная картинка будет предварительно закодирована в JPEG и снова открыта. Потому что из RAW, даже с шумом, вытаскивать исходные данные куда проще, чем из перешакаленного JPEG/H264 с кубиками.
Тут суть имхо не в GIMPе, а в разложении деблюра на простейшие операции с изображением. Такое можно поворачивать и в фотошопе, и в Nuke, и в AfterEffects и другом софте.
Например, этот метод можно превратить в шейдер и деблюрить видео в реалтайме и/или больших разрешениях. Для современной видеокарты такие операции — пыль. Плюс его можно впихивать во всякие ПЛИС и контроллеры с дефицитом вычислительных ресурсов.
Для обычных ситуаций сейчас конечно лучше использовать нейронки, ещё лучше — граф из нейронок в каком‑нибудь ComfyUI. Практика показывает, что наилучшие результаты происходят при комбинации традиционного подхода и нейронок. Но такая комбинация требует танцев с бубном.
Бессмысленно сравнивать это, слишком разная архитектура. Если упростить, у яблок скорость достигается за счёт очень тесной интеграции компонентов — всё рядом. У обычного компа память/шины/gpu и прочие штуки больше архитектурно удалены друг от друга, но а) масштабируются б) могут быть сильно больше и/или мощнее.
Поэтому в одних задачах да, оно лучше, в других задачах — нет, оно хуже. Это примерно как сравнивать хороший спорткар и хороший трактор.
Глядя на современные тенденции про «а давайте все вайбкодить» и «1 инженер 1 месяц 1 миллион строк кода» я боюсь, что деланье каждого пикселя <div>ом может стать нормой в ближайшем будущем. «Мы не в 80х, зачем экономить вычислительные ресурсы» и вот это всё.
С одной стороны да, если это эффективнее решает задачу, то почему нет. Именно благодаря этому подходу мы сейчас не пишем всё на ассемблере.
С другой стороны качество софта нынче летит в пропасть, и даже на топовом железе всё работает плохо и тормозит. И однажды кто‑нибудь сделает такое не <div>ах, а на виртуальных машинах, где на каждом пикселе будет стоять отдельная винда и менять цвет обоев.
Имхо тут лучше разделить техническую и художественную составляющие.
С одной стороны, если фильм требуется масштабировать (в любую сторону) и/или пережимать, то делать это лучше без шумов, чтобы «зернистая ламповость» не превратилась в рябящее мыло. Потому что шумы алгоритмы сжатия видео не любят, особенно когда битрейт низкий (а в интернете он очень низкий). С другой стороны, желательно иметь возможность сохранить тёплошумную ламповость, хотя бы в каком то виде.
Можно действовать так:
Берём оригинальное видео А
Удаляем шум — получаем видео без шума Б
Попиксельно вычитаем из видео А видео Б — получаем видео с самим шумом В
Видео с шумом В дополнительно обрабатываем так, чтобы там полностью перестало проглядываться оригинальное видео Б — границы, тени, силуэты и прочее. Сделать это можно, например, с помощью двумерного преобразования Фурье и удалением низкочастотной составляющей + ещё парой допобработок.
Теперь, у нас есть:
Оригинальное видео с шумом А
Видео без шума Б
Видео только с самим шумом В
И если нам надо, например, отмасштабировать видео (апскейл/даунскейл), то мы:
Масштабируем видео без шума Б (нейросеткой/бикубически/билинейно/ланцош — не важно)
Накладываем на него шум В без масштабирования (!), при необходимости увеличиваем/уменьшаем интенсивность шума В — по вкусу. Если новый размер кадра меньше оригинала — обрезаем, если больше — дозаполняем каким‑нибудь дублированием с маскированием стыков. Вообще можно тупо выделять спектр шума и потом его заново генерить по этому спектру в требуемом разрешении, но это не подойдёт для всяких ворсинок и прочих аналоговых штук
Кодируем
Если при этом битрейт требуется очень низкий, то нужно предварительно поиграться со спектром шума на видео В и понизить амплитуду (по пространству и/или по времени), которые алгоритм сжатия превращает в мыло, а остальное оставить.
Если масштабирование не требуется — всё равно, мы можем что‑нибудь сделать с шумом, чтобы при сжатии кодеком он не мылился. Для совсем энтузиастов можно хранить их — видео Б и шум В — отдельно, и сводить непосредственно при просмотре.
Разумеется, все промежуточные результаты мы сохраняем либо в формат со сжатием без потерь (ProRes какой‑нибудь), либо в виде сиквенсов. Можно и fp32, если место есть.
То есть мы отдельно протаскиваем через обработку отдельно картинку без шума, отдельно сам шум, и работаем с ними независимо, чтобы сохранить максимум художественной составляющей в конце по вкусу. Нравится шум — будет шум, нравится без шума — будет без шума, хочется чего‑то промежуточного — тоже можно.
Фокус в том, что если что‑то пойдет не так, эту штуку можно разобрать и сделать обычным тепловым генератором. Тепло добыть можно кучей способов — поджечь что‑нибудь, сфокусировать солнечный свет и тому подобное. С топливным элементом такую универсальность получить гораздо сложнее.
Там почти не вертишь, смотришь в середину, боковушки для перефирического зрения. Но иногда глянуть вбок, пока в кого‑то целишься — большое преимущество
Мне норм. Играю в шутеры в основном. На боковушках картинка растянута конечно, но я привык (пересел с трех 24") + погружение очень мощное, особенно когда они под 90° выставляются.
Спасибо за информацию!
Жаль, была надежда что хотя бы в AndroidTV это вменяемо сделано :) На WebOS официально это не работает, насколько я знаю, и народ ставит ломанные прошивки с эксплоитами, с которыми очень не хотелось связываться.
Я думаю, что так сделано для минимизации лага при отображении картинки с ПК. Штош, продолжаем сидеть на DirectX, видимо альтернатив пока не предвидится.
Ага, то есть анализируется, по‑видимому, не то, что непосредственно на экране, а картинка из буфера плеера. Скажите пожалуйста, Вы случайно не тестировали софт, когда происходит трансляция картинки с внешнего HDMI источника (например, ПК)?
Ясно, спасибо за информацию. Загуглил — вроде бы да, MediaProjection кроме RGBA_8888 в другие форматы пока не умеет :(
Интересно узнать, как обстоят дела с лагом и FPS, а также с HDR — оно там по‑настоящему его обрабатывает или в SDR переводит? То есть именно сам процесс быстрого захвата картинки и анализа. Сам использую DIY подсветку на ПК, были мысли перенести анализ картинки из ПК в сами экраны, но неясно насколько хорошо это будет работать, и стоит ли результат всех танцев с бубном.
Nvidia одно время пыталась это реализовать в виде VXGI, но не взлетело. В изначально воксельных играх (типа Minecraft) это работает.
В остальных случаях приходится одновременно держать в памяти воксельное и обычное представления мира и синхронизировать их. Это кушает память, ресурсы и генерирует потенциальные баги.
Тупые численные методы со временем почти всегда побеждают более хитрые сложные алгоритмы, как только появляются соответствующие вычислительные мощности.
Только вот имхо, трасировка пути — это уже настоящее, а будущее — это нейрорендеринг, а потом и комплексный нейросинтез развлечений в реальном времени под индивидуальные предпочтения. Когда игра сможет для каждого человека индивидуально придумать историю, атмосферу, антураж, персонажей, ситуации, диалоги и прочее по его — игрока — предпочтения. А графика отойдёт на второй план, с ней уже почти все проблемы решены.
Поисковые системы отчуждают память, ИИ отчуждает мышление
Предположу, что существуют разные тетрахроматы с разным спектром чувствительности четвёртой колбочки.
Так или иначе, то, что у обычных людей сливается в один цвет, тетрахроматы способны видеть как отдельные оттенки. Что‑то типа биологического 10-битного режима цветности.
А ещё в фотошопе была функция Camera Shake Reducion, предназначенная для удаления смаза с фоток.
Там сначала выбираешь небольшой участок изображения, на котором отчётливо видно, как размыт какой‑либо объект. По этому участку оно вычисляло ядро свёртки, по которому, с его точки зрения, было размыто изображение. Причём, нехилого такого размера — можно и 300×300 пикселей сделать. Это могло быть и радиальное размытие, и размытие в движении, даже по сложной траектории, а не просто по прямой. Ещё, по‑моему, можно было загрузить своё ядро из картинки.
И вот далее по этому ядру свёртки оно пыталось деблюрить картинку. В принципе работало, но не то что бы прям хорошо. На 4 с минусом.
Была ещё фишка, что для разных участков картинки можно было указать/вычислить разное ядро, и оно к разным частям применяло разный деблюр, плавно переходя от одного ядра к другому.
Хотелось бы увидеть сравнение результатов при разрядности 8, 16 и fp32 бит на канал. И что будет, если заблюренная картинка будет предварительно закодирована в JPEG и снова открыта. Потому что из RAW, даже с шумом, вытаскивать исходные данные куда проще, чем из перешакаленного JPEG/H264 с кубиками.
Тут суть имхо не в GIMPе, а в разложении деблюра на простейшие операции с изображением. Такое можно поворачивать и в фотошопе, и в Nuke, и в AfterEffects и другом софте.
Например, этот метод можно превратить в шейдер и деблюрить видео в реалтайме и/или больших разрешениях. Для современной видеокарты такие операции — пыль. Плюс его можно впихивать во всякие ПЛИС и контроллеры с дефицитом вычислительных ресурсов.
Для обычных ситуаций сейчас конечно лучше использовать нейронки, ещё лучше — граф из нейронок в каком‑нибудь ComfyUI. Практика показывает, что наилучшие результаты происходят при комбинации традиционного подхода и нейронок. Но такая комбинация требует танцев с бубном.
Бессмысленно сравнивать это, слишком разная архитектура. Если упростить, у яблок скорость достигается за счёт очень тесной интеграции компонентов — всё рядом. У обычного компа память/шины/gpu и прочие штуки больше архитектурно удалены друг от друга, но а) масштабируются б) могут быть сильно больше и/или мощнее.
Поэтому в одних задачах да, оно лучше, в других задачах — нет, оно хуже. Это примерно как сравнивать хороший спорткар и хороший трактор.
Глядя на современные тенденции про «а давайте все вайбкодить» и «1 инженер 1 месяц 1 миллион строк кода» я боюсь, что деланье каждого пикселя <div>ом может стать нормой в ближайшем будущем. «Мы не в 80х, зачем экономить вычислительные ресурсы» и вот это всё.
С одной стороны да, если это эффективнее решает задачу, то почему нет. Именно благодаря этому подходу мы сейчас не пишем всё на ассемблере.
С другой стороны качество софта нынче летит в пропасть, и даже на топовом железе всё работает плохо и тормозит. И однажды кто‑нибудь сделает такое не <div>ах, а на виртуальных машинах, где на каждом пикселе будет стоять отдельная винда и менять цвет обоев.
Имхо тут лучше разделить техническую и художественную составляющие.
С одной стороны, если фильм требуется масштабировать (в любую сторону) и/или пережимать, то делать это лучше без шумов, чтобы «зернистая ламповость» не превратилась в рябящее мыло. Потому что шумы алгоритмы сжатия видео не любят, особенно когда битрейт низкий (а в интернете он очень низкий). С другой стороны, желательно иметь возможность сохранить тёплошумную ламповость, хотя бы в каком то виде.
Можно действовать так:
Берём оригинальное видео А
Удаляем шум — получаем видео без шума Б
Попиксельно вычитаем из видео А видео Б — получаем видео с самим шумом В
Видео с шумом В дополнительно обрабатываем так, чтобы там полностью перестало проглядываться оригинальное видео Б — границы, тени, силуэты и прочее. Сделать это можно, например, с помощью двумерного преобразования Фурье и удалением низкочастотной составляющей + ещё парой допобработок.
Теперь, у нас есть:
Оригинальное видео с шумом А
Видео без шума Б
Видео только с самим шумом В
И если нам надо, например, отмасштабировать видео (апскейл/даунскейл), то мы:
Масштабируем видео без шума Б (нейросеткой/бикубически/билинейно/ланцош — не важно)
Накладываем на него шум В без масштабирования (!), при необходимости увеличиваем/уменьшаем интенсивность шума В — по вкусу. Если новый размер кадра меньше оригинала — обрезаем, если больше — дозаполняем каким‑нибудь дублированием с маскированием стыков. Вообще можно тупо выделять спектр шума и потом его заново генерить по этому спектру в требуемом разрешении, но это не подойдёт для всяких ворсинок и прочих аналоговых штук
Кодируем
Если при этом битрейт требуется очень низкий, то нужно предварительно поиграться со спектром шума на видео В и понизить амплитуду (по пространству и/или по времени), которые алгоритм сжатия превращает в мыло, а остальное оставить.
Если масштабирование не требуется — всё равно, мы можем что‑нибудь сделать с шумом, чтобы при сжатии кодеком он не мылился. Для совсем энтузиастов можно хранить их — видео Б и шум В — отдельно, и сводить непосредственно при просмотре.
Разумеется, все промежуточные результаты мы сохраняем либо в формат со сжатием без потерь (ProRes какой‑нибудь), либо в виде сиквенсов. Можно и fp32, если место есть.
То есть мы отдельно протаскиваем через обработку отдельно картинку без шума, отдельно сам шум, и работаем с ними независимо, чтобы сохранить максимум художественной составляющей в конце по вкусу. Нравится шум — будет шум, нравится без шума — будет без шума, хочется чего‑то промежуточного — тоже можно.
Фокус в том, что если что‑то пойдет не так, эту штуку можно разобрать и сделать обычным тепловым генератором. Тепло добыть можно кучей способов — поджечь что‑нибудь, сфокусировать солнечный свет и тому подобное. С топливным элементом такую универсальность получить гораздо сложнее.
Там почти не вертишь, смотришь в середину, боковушки для перефирического зрения. Но иногда глянуть вбок, пока в кого‑то целишься — большое преимущество
Мне норм. Играю в шутеры в основном. На боковушках картинка растянута конечно, но я привык (пересел с трех 24") + погружение очень мощное, особенно когда они под 90° выставляются.
Скрытый текст
Да, видюха 5090
11520×2160 (сцепка из трёх 3840×2160 в один виртуальный дисплей)
Из 2025. А Вы?