Имхо тут лучше разделить техническую и художественную составляющие.
С одной стороны, если фильм требуется масштабировать (в любую сторону) и/или пережимать, то делать это лучше без шумов, чтобы «зернистая ламповость» не превратилась в рябящее мыло. Потому что шумы алгоритмы сжатия видео не любят, особенно когда битрейт низкий (а в интернете он очень низкий). С другой стороны, желательно иметь возможность сохранить тёплошумную ламповость, хотя бы в каком то виде.
Можно действовать так:
Берём оригинальное видео А
Удаляем шум — получаем видео без шума Б
Попиксельно вычитаем из видео А видео Б — получаем видео с самим шумом В
Видео с шумом В дополнительно обрабатываем так, чтобы там полностью перестало проглядываться оригинальное видео Б — границы, тени, силуэты и прочее. Сделать это можно, например, с помощью двумерного преобразования Фурье и удалением низкочастотной составляющей + ещё парой допобработок.
Теперь, у нас есть:
Оригинальное видео с шумом А
Видео без шума Б
Видео только с самим шумом В
И если нам надо, например, отмасштабировать видео (апскейл/даунскейл), то мы:
Масштабируем видео без шума Б (нейросеткой/бикубически/билинейно/ланцош — не важно)
Накладываем на него шум В без масштабирования (!), при необходимости увеличиваем/уменьшаем интенсивность шума В — по вкусу. Если новый размер кадра меньше оригинала — обрезаем, если больше — дозаполняем каким‑нибудь дублированием с маскированием стыков. Вообще можно тупо выделять спектр шума и потом его заново генерить по этому спектру в требуемом разрешении, но это не подойдёт для всяких ворсинок и прочих аналоговых штук
Кодируем
Если при этом битрейт требуется очень низкий, то нужно предварительно поиграться со спектром шума на видео В и понизить амплитуду (по пространству и/или по времени), которые алгоритм сжатия превращает в мыло, а остальное оставить.
Если масштабирование не требуется — всё равно, мы можем что‑нибудь сделать с шумом, чтобы при сжатии кодеком он не мылился. Для совсем энтузиастов можно хранить их — видео Б и шум В — отдельно, и сводить непосредственно при просмотре.
Разумеется, все промежуточные результаты мы сохраняем либо в формат со сжатием без потерь (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 эксперта). Плюс сейчас постепенно много где появляется функция сжатия контекста — и в онлайновых, и в локальных фронтендах.
Давно уже есть в американцах, немцах и китайцах. Эта штука повышает безопасность, а не понижает, так как не приходится переводить и перефокусировать взгляд из дали на ближнее расстояние, где приборка. Визуально кажется, что проекция большая и в 15 метрах впереди, а не в плоскости лобового стекла. Это невозможно показать картинками через интернет, так как дисплеи у всех плоские, а не голографические.
попробует загрузиться и свалится с ошибкой OutOfMemory
-models-max 1 - это означает что на VRAM нужно держать только одну модель
Эм. А считать не по количеству моделей, а по потребляемой памяти?
Типа нужно загрузить X, если оно вместе с уже загруженным жрёт больше VRAM, чем есть, то узнаем, сколько надо выгрузить и ищем самую маленькую и редко используемую модель не меньше, чем столько, сколько нужно освободить, и выгружаем. И только после этого загружаем X. Еще можно прикрутить всякие миграции целиком и по слоям/кускам/экспертам между GPU, когда их несколько.
По-моему, это не такая уж сложная задача, её 100500 раз делали так или иначе в разных формах.
Ни VRR, ни G-Sync работать не будут. Более того, для 10-битного HDR 120 Гц 4:4:4 до сих пор исчезающе мало переходников.
Сам использую Club3D-CAC 1085 + оптика. Требуют отдельного питания, греются как сковородки, друг друга перегревают и тогда картинка пропадает. Пришлось ставить вентилятор.
Скрытый текст
Из плюсов — лага нет (видимо там FPGA построчно обрабатывает картинку), с вентилятором работают исправно.
Есть ещё проблема с аллокациями, которая частично решена в .NET 10. Там среда может разместить массив на стеке, а не в куче, если будет убеждена, что это безопасно. А вот List гарантированно улетит в кучу (приходилось делать список значимым типом для борьбы с этой проблемой).
HDR 10 бит 4К? То есть H265 он был? И 90 Гб превратились в 4 Гб без видимых потерь? Скриншоты (в оригинальном разрешении в HDR и не пережатые хабром и джипегами) в студию. В том числе динамичных сцен. А лучше примеры фильмов.
Имхо тут лучше разделить техническую и художественную составляющие.
С одной стороны, если фильм требуется масштабировать (в любую сторону) и/или пережимать, то делать это лучше без шумов, чтобы «зернистая ламповость» не превратилась в рябящее мыло. Потому что шумы алгоритмы сжатия видео не любят, особенно когда битрейт низкий (а в интернете он очень низкий). С другой стороны, желательно иметь возможность сохранить тёплошумную ламповость, хотя бы в каком то виде.
Можно действовать так:
Берём оригинальное видео А
Удаляем шум — получаем видео без шума Б
Попиксельно вычитаем из видео А видео Б — получаем видео с самим шумом В
Видео с шумом В дополнительно обрабатываем так, чтобы там полностью перестало проглядываться оригинальное видео Б — границы, тени, силуэты и прочее. Сделать это можно, например, с помощью двумерного преобразования Фурье и удалением низкочастотной составляющей + ещё парой допобработок.
Теперь, у нас есть:
Оригинальное видео с шумом А
Видео без шума Б
Видео только с самим шумом В
И если нам надо, например, отмасштабировать видео (апскейл/даунскейл), то мы:
Масштабируем видео без шума Б (нейросеткой/бикубически/билинейно/ланцош — не важно)
Накладываем на него шум В без масштабирования (!), при необходимости увеличиваем/уменьшаем интенсивность шума В — по вкусу. Если новый размер кадра меньше оригинала — обрезаем, если больше — дозаполняем каким‑нибудь дублированием с маскированием стыков. Вообще можно тупо выделять спектр шума и потом его заново генерить по этому спектру в требуемом разрешении, но это не подойдёт для всяких ворсинок и прочих аналоговых штук
Кодируем
Если при этом битрейт требуется очень низкий, то нужно предварительно поиграться со спектром шума на видео В и понизить амплитуду (по пространству и/или по времени), которые алгоритм сжатия превращает в мыло, а остальное оставить.
Если масштабирование не требуется — всё равно, мы можем что‑нибудь сделать с шумом, чтобы при сжатии кодеком он не мылился. Для совсем энтузиастов можно хранить их — видео Б и шум В — отдельно, и сводить непосредственно при просмотре.
Разумеется, все промежуточные результаты мы сохраняем либо в формат со сжатием без потерь (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 эксперта). Плюс сейчас постепенно много где появляется функция сжатия контекста — и в онлайновых, и в локальных фронтендах.
Там памяти чуть меньше 1500 Гб ;)
Давно уже есть в американцах, немцах и китайцах. Эта штука повышает безопасность, а не понижает, так как не приходится переводить и перефокусировать взгляд из дали на ближнее расстояние, где приборка. Визуально кажется, что проекция большая и в 15 метрах впереди, а не в плоскости лобового стекла. Это невозможно показать картинками через интернет, так как дисплеи у всех плоские, а не голографические.
Эм. А считать не по количеству моделей, а по потребляемой памяти?
Типа нужно загрузить X, если оно вместе с уже загруженным жрёт больше VRAM, чем есть, то узнаем, сколько надо выгрузить и ищем самую маленькую и редко используемую модель не меньше, чем столько, сколько нужно освободить, и выгружаем. И только после этого загружаем X. Еще можно прикрутить всякие миграции целиком и по слоям/кускам/экспертам между GPU, когда их несколько.
По-моему, это не такая уж сложная задача, её 100500 раз делали так или иначе в разных формах.
Ни VRR, ни G-Sync работать не будут. Более того, для 10-битного HDR 120 Гц 4:4:4 до сих пор исчезающе мало переходников.
Сам использую Club3D-CAC 1085 + оптика. Требуют отдельного питания, греются как сковородки, друг друга перегревают и тогда картинка пропадает. Пришлось ставить вентилятор.
Скрытый текст
Из плюсов — лага нет (видимо там FPGA построчно обрабатывает картинку), с вентилятором работают исправно.
Есть ещё проблема с аллокациями, которая частично решена в .NET 10. Там среда может разместить массив на стеке, а не в куче, если будет убеждена, что это безопасно. А вот List гарантированно улетит в кучу (приходилось делать список значимым типом для борьбы с этой проблемой).
HDR 10 бит 4К? То есть H265 он был? И 90 Гб превратились в 4 Гб без видимых потерь? Скриншоты (в оригинальном разрешении в HDR и не пережатые хабром и джипегами) в студию. В том числе динамичных сцен. А лучше примеры фильмов.