You are not logged in. Please login or register.
SmoothVideo Project → Эксплуатация SVP → Прежде чем делать апгрейд: модификация SVP (скрипты, настройки)
ну да, учитывая что это 6600 и P4
но для 7900 и Core 2 Duo уже что-то придумать то и можно
И так - появился конкурент : сцылки на конкурентов преследуются по закону военного времени!
Не буду разглагольствовать особо . Против свп ДР имеет ряд спорных преимуществ . Главное из которых уплавнение всего и вся . И , на мой взгляд, действительно достойное - это блюр локального движения . Конечно в разумных пределах .
Построитель (шейдер в свп) , который использует ДР в свп недоступен . Но "раскачать" вектора , чтобы размазать локальное движение векторами - это мы могЁм 
Здесь представлен скрипт для свп 3.0.7 . Который имеет похожие на ДР симптомы , но гораздо более детализирован .Хотя у меня лишь 7770 на частотах 1000*1300 , вполне возможно на более мощной видяйке ДР более детализирован. Как обычно - уточнение сильно желательно . Скрипт для "мониторных" размеров видео . Особо не настраивал - будет интерес - можно будет ковырят дальше .
Это попытка получить картинку ближе к ДР , чем это предлагает свп 3.1 .
Поскольку возможности написания скриптов для свп 3.1 ограничены : следует установить шаг 28 пиксел в профиле (24 - тоже вариант) . Глобальное уточнение желательно . Скрипт подходит от 720р до 1080р . Обязательно испытайте на 13 (стандарт) и 11блочном . Маски 21 и 23 шейдера не трогал - не до них . Если построение на видяйке - включите подавление площадных артефактов "ниже среднего" , просто полезно . Адаптивный режим не содержит режима 1м , посмотрите - может понравится .
Скрипт дает лучшую картинку , чем 3.0 , но относительно тяжелый .
Следует заменить файл override в папке : C:\Program Files (x86)\SVP
Не забудьте скопировать оригинальный override куда-нибудь Подальше , чтобы потом поближе взять .
я это смотреть не могу - более резкий ДР в чистом виде ....Для тех , кто не боится экспериментов , предлагаю поиграться с некоторыми параметрами из override .
В двух словах , основное отличие скрипта , что выше , от умолчательного в свп :
1 Это параметр analyse.main.search.coarse.trymany = true;
Что приводит к значительной , очень значительной стабилизации изображения . Наиболее эффективно для крупных блоков=шага . Грубо говоря - полезно для большОго шага 32-24 пиксела . Для меньшего шага приход гораздо меньше . Лучшим будет шаг 28 пиксел .
Это позволило уменьшить лямбда :
analyse.main.penalty.lambda = 0.1;
analyse.main.penalty.plevel = 1.4;
analyse.main.penalty.lsad = 4800;
В данном случае в 100 раз от умолчания . Вы можете экспериментировать с этим значением , благо картинка с trymany= true очень стабильна = согласована .Чем меньше analyse.main.penalty.lambda , тем больше свободы движению . Но это палка о двух концах .
2 В свп 3.1 появилась новая строчка : повторный широкий поиск . Т.е. поиск проводится дважды . Первый раз - собственно основной поиск (точный) . Затем , если основной поиск не привел к желаемым результатам - идет повторный (широкий , но неточный) .
По умолчанию повторный широкий поиск призван "поймать" вылетевшие блоки . Я же использую оба типа поиска ВСЕГДА .
Наверно все помнят классический блок 16*16 с радиусом 2 пиксела . Это был "безартефачный" поиск в прошлых версиях . Здесь это параметр :
analyse.main.search.coarse.distance = 3;
Оптимальные значения для шага 32-24 пиксела 2 и 3 . Оно конечно , этого очень мало для большОй амплитуды движения . Но зато крупные объекты (тело) в кадре выводятся очень детализированными , как и отсутствие проблем с площадными артефактами . Но как быть с ушами и хвостами ? Для этого используется повторный широкий поиск , именно для поиска , а не для ловли мух .
analyse.main.search.bad.sad = 100;
analyse.main.search.bad.range = 32;
Здесь значения около того , что есть .
3 Смена сцен ...тут сложно :
smooth.scene.limits.blocks = 23;
Меняйте это значение от 0-100 % . 100% даст полное отключение смены сцен - привет ДР
Скрипт более-менее нормально отработал ремукс мультфильма Мадагаскар3 . С нагрузкой около 50% на ай52500к (4200мгц) . Выводы делайте самостоятельно . Но для видео меньше 720р настройки могут привести к непредсказуемым результатам .
так что за конкурент то?, дайте название, поглядеть то хочецо, чисто из интереса
конкурента обсуждаем тут "Просмотр видео на компьютере с эффектом плавности движений" ixbt
отличается от SVP необходимостью делать апгрейд видеокарты вместо апгрейда проца
Chainik,
а апгрейд видеокарты... всего лишь... почти нигде.
Средняя карточка даёт заметный прирост в скорости работы интерфейса винд от висты до 8-ки(естественно по сравнению с совсем low end), во всяких современных видео-редакторах, которые научились использовать DirectX 11/open cl и прочее.
Я вон попробовал использовать в тайм-линии(куда набухано штук 20 lossless файлов FHD) в последнем видео-редакторе magix, только СPU 6-ядерный cо старым DX 9, такое лагалово только во сне приснится может. 
Сверхвысокие разрешения в нелинейных редакторах стали достпуны благодаря совр.картам.
Это конечно же всё касается определённых узконаправленных вещей, по вычислениям общего назначения - CPU пока что нет равных(хоть и медленней).
название можно, название - не сцылка
Отвлеклись от темы ...однако .
Эксперименты с ДР закончены . Как я не пытался заставить свп находить вектора согласованно и независимо , что 3.0 , что 3.1 этого сделать не в состоянии .
Единственно - это использование перекрытия , достаточного для согласованного поиска большИм радиусом без существенной лямбда-согласованности . Но для нормальной работы этого скрипта нужны блоки 32*32 (крупные , можно ещё крупнее) , перекрытие 12-14 пиксел и радиус от 8 пиксел (честный радиус , не свп 3.1) . Тогда можно воспользоваться меньшим числом уровней пирамиды и найти более разнонаправленные вектора . Короче , даже со всеми твиками 3.0 жарит мой ай5 2500к (4400мгц) .
Забросил я это дело , ибо поддержки идей снижения нагрузки от поиска у разработчиков не нашел . А без снижения нагрузки на камень в разы - кому нравится ДР - тот его и глядит .
Пока же представляю новые идеи , которые вылезли в борьбе за плавную и ещё плавнее картинку . От умолчательного в свп 3.0.7 поиска здесь чуть другие штрафы и т.д.
Принципиальные отличия :
trymany= true - позволяет обойтись меньшим радиусом поиска , нет присущего свп 3.0 ограничения уплавнения крупными блоками из-за маленького радиуса . Как и особо толку от перекрытия с этим параметром я не увидел . Если не хуже .
divide= 1 - теперь блоки всегда делятся на 2 . При обычном поиске блоками 32*32 без уточнения - на выходе шаг 32*32 . Теперь есть деление . Что значит - на выходе шаг 16*16 . При включенном уточнении деление происходит ещё раз . Поиск блоком 8*8 даст ошибку - так и должно быть . Ибо 8*8 /4 это 2*2 - этот размер отсутствует как класс .
badSAD = 30 ,badrange=8 - это РАБОТАЮЩИЙ повторный поиск , сделано для снижения нагрузки и относительного снятия ограничения неповоротливости крупных блоков .
Как обычно - присутствую "дыры" смены сцен . Настроено на максимальную плавность .
В предложенном скрипте практически отсутствую площадные артефакты , нагрузка на камень растет более адекватными темпами .
Крупные блоки дают более адекватную картинку против 3.0 , далеко не ущербную ...если не лучшую - при меньшей загрузке камня .
3.1 - это другая опера , там слишком много незнакомых инструментов ......Сравните самостоятельно .
Копировать с заменой в свп 3.0 .7 .
Чтобы улучшить согласованность векторов без использования перекрытия - поменяйте значение
analyse.main.search.coarse.trymany = true;
C:\Program Files (x86)\SVP файл override . Меняете false на true .
Нагрузка немного вырастет , но и отпадет необходимость в перекрытии .
Т.е. используя шаг 32*32 , 16*16 и 8*8 вы получите лучшую картинку с включенным параметром trymany . Чем вы будете использовать перекрытие : шаг 28 ,24 , 14 ,12 ,7,6 пиксел .
Вредность перекрытия можно увидеть глазами - достаточно воспользоваться свп3.0 , там можно установить любое перекрытие с шагом 2 пиксела . Например , можно поставить перекрытие 20 пиксел для блока 32*32 . И это практически полностью остановит поиск векторов .
В 3.1 поиск работает значительно лучше 3.0 . Никакой необходимости в использовании перекрытия , как способа получить согласованные вектора нет .
Дополнительный поиск вокруг кандидатов (trymany) собственно и призван глобально стабилизировать картинку . Т.е. делает тоже самое , что и перекрытие . Но при этом не ограничивает движение , как это делает перекрытие блоков .
да, самая интересная тема на форуме А точность векторов (1/2 1 2) как влияет на общую картину ? Радиус поиска ставить максимальным ?
dlr5668
Радиус поиска ставить максимальным ?
Чем крупнее блок - тем больше должен быть радиус поиска . В 3.0 радиус поиска можно установить ручками . В 3.1 - используется "хитрый" радиус ....на мой вгляд "средний" - это 2 пиксела , максимальный - 3 пиксела , что там на самом деле-понятия не имею .
Точность векторов ...понятие относительное .
Например - мы выбрали блок 32*32 . Это значит , что поиск будет происходить блоком 32*32 . Т.е. блок может найти ..скажем горизонтальную линию - до пиксела . Но блок такого размера будет слеп к сложному движению . Разнонаправленное движение просто не увидит .
Вопрос : использовать меньший блок и учитывать движение более мелких объектов - но пиксельной точности . Или использовать более крупные блоки , зато с полупиксельной точностью движения крупных объектов ...Тут кому как нравится .
Одно могу сказать точно - для поиска векторов достаточно пиксельной точности по отношению к размеру монитора . Для монитора 1080р достаточно пиксельной точности , если это ремукс1080р . Меньшее же разрешение нужно увеличивать на входе .
В случае построения на видеокарте - вообще без нюансов , там всегда одна точность . В случае построения процессором - сейчас поиск и построение имеют одну и ту же точность .
Т.е. нельзя получить полупиксельное построение , если не использовать полупиксельный поиск . ЭТО очень плохо .
На самом деле невооруженным глазом видно разницу между полу, четверть пиксельным построением , но ни разу не видно точности поиска большей , чем размер реального монитора .
"допиленный" предложенный ранее скрипт для 3.0.7 . Его нельзя назвать "легким" , но всё же не забываем , что выбирая блоки поиска 32*32 на выходе без уточнения будут блоки 16*16 . С уточнением - блоки 8*8 .
Если вы выбрали блоки 16*16 , тогда при включенном уточнении на выходе блоки 4*4 .
Советую не игнорировать данный скрипт . Хотя бы для того , чтобы сравнить две версии свп и ДР . Этот скрипт практически не отключает плавность , целиком и полностью полагаясь только на поиск .
Супруга сегодня подошла к телевизору , на сцене Властелина Колец - Две Башни , когда изгоняется Саурон из короля Теодена . Еле отогнал
Несколько советов по настройкам :
1 Достаточным является рад 1 пиксел , недостатка в амплитуде уплавнения вы не увидите .
2 Для блоков 32*32 хорошим будет радиус 3 пиксела .
Для блоков 16*16 - 2 пиксела . Конечно больше-лучше , но не критично .
3 Тип поиска для фулки лучше установить логарифмический . Никакой необходимости в большей точности нет .
4 Если используется видеокарта - полупиксельную точность векторов на фулке устанавливаете в последнюю очередь .
Приоритеты нагрузка-качество выглядят следующим образом : уточнение , радиус выше хорошего , размер блока , затем полупиксельная точность .
В любом случае - при серьезном недогрузе камня нужно использовать увеличение размера входящего видео вместо уменьшения размеров блока и полупиксельной точности векторов .
ещё одна вариация скрипта , что выше .
Целью скрипта является объединение положительных качеств 11 и 13 шейдера .
Мои характеристики 11 шейдера - плавный , с 13 даже сравнивать нельзя . И , против 11 блочного "сопливый" - как любой , кроме 11 блочного и 13 .
13 шейдер ...единственное достоинство - способен избавить не только от "соплей" , а также от проблемных деталей в кадре .
Главной фишкой является применение медианного деления . Грубо говоря - 13 шейдер , но с нормальным уплавнением , или 11 , с ограниченным уплавнением . Естественно , "обрезание" происходит лишь на мелких деталях . Но поскольку после деления алгоритм пытается поискать ...Вообщем смотрите сами .
Попутно выяснилась ещё одна особенность медианного деления - смена сцен детектируется намного точнее . Плавность отключается чаще , чем обычно - но зато там , где это действительно необходимо .
Для работы алгоритма "как задумано" - берем ремукс (обрезаем черныполосы) , выбираем блоки 32*32 с уточнением (можно и без) . Радиус желательно 4 пиксела . Для фулки и 3.0 полупиксель противопоказан - можно получить недоуплавненную картинку .
Шейдер - 11 , или 21 с отсутствием подавления контурных артефактов ...что есть одно и тоже .
Предупреждаю - нагрузка с уточнением далеко не маленькая .
На меньших разрешениях можно выбрать полупиксел - лишним не будет . Но блок 32*32 с уточнением нужно сохранить .
а что отвечает за более точное преобразование? ну то есть если объект быстро движется и это всё крупным планом - вокруг него образовываются не комфортные "ауры", как бы эти вещи выпилить?
flashlight
как бы эти вещи выпилить?
Можно конечно , но двумя способами - ценой недоуплавнения мелких объектов в других сценах . Ибо либо деформация и плавно . Либо нет деформации и плавно только крупным объектам , мелкие получатся наложением .
Можно пробовать 11 блочный с перекрытием . Но не для этого скрипта негодится ...Там будут более четкие контура + размазанный фон . Визуально значительно лучше . Но удержать такую картинку трудно . Построение блоками чревато "вылетами" - это квадрат , его очень хорошо видно .
Попробуйте поиграть со штрафами . Главным образом pnew=64 . Значения от -100 до 100 . Здесь лямбда лучше не трогать - значение на грани фола .
Это как то печально, но всё равно спасибо, будем думать тыкать лазать
flashlight
Это как то печально
Ничего нет страшного и печального . Нет одинаково хороших настроек для видео любого размера и любых блоков .
Конкретно под размер подобрать можно . Элементарное перекрытие может изменить картинку до неузнаваемости . Можешь испытать перекрытие 4 пиксела
overlap=4, overlapv=4,
Для блоков 32*32 и 11блочный в этом скрипте . Ореолы значительно снизятся .
А если без скрипта? Я просто для оптимальной производительности сбросил настройки и отталкиваюсь от дефолта I5 mobile через интерфейс программы (прошу прощения), в принципе уменьшив шаг сетки и увеличив точность движения векторов стало приемлимо, если вам знакомы ролики с канала 0420to на ютубе то на них хорошо заметны расплывчатости, вот я на их ролике сравнивал влияние этих параметров на то что меня интересует - стало лучше и хватит
flashlight
вот я на их ролике
Какие ролики ? чего там можно уплавнить ?
Здесь про 1080р ,720р и размер видео=реальным мониторным пикселам .
Для мелких размеров может элементарно нехватить пиксельной скорости из-за меньшего количества уровней . Меньшие блоки дадут больше уровней=большую возможную амплитуду уплавнения .
Именно с этим связано заблуждение - мол чем меньше блок , тем лучше . Это - неправда . Чем крупнее блок , тем точнее поиск . Тем он тяжелее , причем в разы .
На пальцах это выглядит так :
8*8 , радиус 2 пиксела
16*16 , радиус 4 пиксела
32*32 радиус 8 пиксел
Это одно и тоже , если для блока 8*8 изображение будет 250р , для 16*16 = 500р , для 32*32 = 1000р .
Последний вариант от первого потребует примерно в 500 раз большей вычислительной мощности . И даст лучший результат , но вовсе не в 500 раз .
Другое дело , что это крайне неэффективно .
Эффективно использовать свой размер блока там , где это действитеельно нужно .
Чего кому хватит - каждый решает сам . Кому-то и ДмитрийРендер шедевром кажется
Уважаемый gaunt большинство людей не понимает ваши разъяснения,прилагайте к вашим скриптам картинки настроек чтоли,обычным людям ваши заумные речи нафиг ненужны
ну как-то так к последнему (у меня один профиль в 3.0.7 версии)
Нагрузка около 80% на core i7 4.4Ghz + 7850 ati. Работает неплохо даже на 720p, нужно больше тестов.
SmoothVideo Project → Эксплуатация SVP → Прежде чем делать апгрейд: модификация SVP (скрипты, настройки)
Powered by PunBB, supported by Informer Technologies, Inc.