Предположу, что существуют разные тетрахроматы с разным спектром чувствительности четвёртой колбочки.
Тетрахромат Кончетта Антико рисует картины, на которых изображает обычными цветами то, что видит сама глазами
Так или иначе, то, что у обычных людей сливается в один цвет, тетрахроматы способны видеть как отдельные оттенки. Что‑то типа биологического 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° выставляются.
Играю в 12K, дефицит производительности всегда был нормой. Но нынешние DLSS и прочее апскейловое MFG уже выдают вменяемое качество, поэтому выйти на заветные 120fps не проблема. Для старых игр, где этого нет, карточки хватает в нативе, новые нормально работают с апскейлом. Разве что MFG не везде приемлемо, ибо инпутлаг создаёт ощутимый.
А вот чего оно в 5K тормозит для меня вопрос. Что‑то мне кажется, что дело не в картах, а в чьих‑то руках и нежелании заниматься оптимизацией.
Он даже на пустом документе тормозит. А ещё когда ПКМ щелкаю по рабочему столу, меню открывается только через полсекунды.
пересчитать длину всех строк выше открытой строки - нужен ли перенос и т.п.
Очень мало кто может сделать быстрый блокнот для больших файлов под миллион строк.
Эм. А зачем все строки то? Отресайзились — берем текст, который виден на экране и перебираем‑пересчитываем текст вверх и вниз до тех пор, пока не вылезем за пределы экрана. Только те куски, которые в поле зрения. Если пользователь начинает мотать куда‑то — досчитываем относительно того, что уже отобразили. Если мотает далеко — то считаем примерную позицию и снова считаем только то, что на экране. Я просто рассуждаю.
public static class UselessAwaitExtensions
{
public static TaskAwaiter GetAwaiter(this int milliseconds) => Task.Delay(milliseconds).GetAwaiter();
public static TaskAwaiter GetAwaiter(this string text) => Task.Delay(text?.Length ?? 100).GetAwaiter();
public static TaskAwaiter GetAwaiter<T>(this T anything) => Task.Delay(100).GetAwaiter();
}
Кроме шуток — в некоторых случаях конструкции вида await 500; в качестве пауз довольно удобны.
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Я видел её, но у меня на практике пока кроме падений (спасибо что без BSODов) никаких результатов нет :( Версии драйверов пробовал разные. То ли ждать обновы, то ли продолжить ковыряться...
Да, но он не везде нужен большой, и влияет нелинейно.
Например, на RTX 5090 GPT OSS 120b с окном 4096 выдает 15 т/с, а если поставить окно 32000, то будет около 11 т/с (4 эксперта). Плюс сейчас постепенно много где появляется функция сжатия контекста — и в онлайновых, и в локальных фронтендах.
Предположу, что существуют разные тетрахроматы с разным спектром чувствительности четвёртой колбочки.
Так или иначе, то, что у обычных людей сливается в один цвет, тетрахроматы способны видеть как отдельные оттенки. Что‑то типа биологического 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. А Вы?
Играю в 12K, дефицит производительности всегда был нормой. Но нынешние DLSS и прочее апскейловое MFG уже выдают вменяемое качество, поэтому выйти на заветные 120fps не проблема. Для старых игр, где этого нет, карточки хватает в нативе, новые нормально работают с апскейлом. Разве что MFG не везде приемлемо, ибо инпутлаг создаёт ощутимый.
А вот чего оно в 5K тормозит для меня вопрос. Что‑то мне кажется, что дело не в картах, а в чьих‑то руках и нежелании заниматься оптимизацией.
Он даже на пустом документе тормозит. А ещё когда ПКМ щелкаю по рабочему столу, меню открывается только через полсекунды.
Эм. А зачем все строки то? Отресайзились — берем текст, который виден на экране и перебираем‑пересчитываем текст вверх и вниз до тех пор, пока не вылезем за пределы экрана. Только те куски, которые в поле зрения. Если пользователь начинает мотать куда‑то — досчитываем относительно того, что уже отобразили. Если мотает далеко — то считаем примерную позицию и снова считаем только то, что на экране. Я просто рассуждаю.
А можно чтобы блокнот без тормозов ресайзился? на 16-ядером CPU с 5 ГГц
Скрытый текст
Кроме шуток — в некоторых случаях конструкции вида await 500; в качестве пауз довольно удобны.
Я видел её, но у меня на практике пока кроме падений (спасибо что без BSODов) никаких результатов нет :( Версии драйверов пробовал разные. То ли ждать обновы, то ли продолжить ковыряться...
Да, но он не везде нужен большой, и влияет нелинейно.
Например, на RTX 5090 GPT OSS 120b с окном 4096 выдает 15 т/с, а если поставить окно 32000, то будет около 11 т/с (4 эксперта). Плюс сейчас постепенно много где появляется функция сжатия контекста — и в онлайновых, и в локальных фронтендах.