Hard Боремся с чересстрочной развёрткой

Gamerun, пардон, не "field shift", а "field delay" встроенный называется, перепутал.

И с ним "bob doubler" не нужен.

 

Если оставить "field delay", то прочие фильтры будут не нужны.
Если не брать в расчет черезстрочность(если смотреть покадрово), то в остальном изображение четкое, без дерганий и сильно заметных шумов.

 

Gamerun, а если смотреть покадрово и брать в расчёт чересстрочность? Можешь кадры результата приложить?

 

Если смотреть покадрово и брать в расчёт чересстрочность, то все не так уж и хорошо. Есть ощущение, что 480i - максимум, так как иначе нужна система, которая сделает нечто вроде 480p и в несколько этапов сделает чистое, четкое, относительно резкое изображение.

Иными словами, либо мириться с тем что есть, либо терять качество изображения в обмен на отсутствие чересстрочности.

 

В данный момент ограничился модифицированным скриптом avisynth отсюда, так как в данный момент более лучшие варианты вряд ли возможны в ближайшее время(либо плохо искал).

Разве что еще попробовать Sony Vegas с Adobe Premiere Pro, но имеют место быть сомнения.

 

Gamerun, сложно советовать, не видя, какие фильтры стоят и как меняется картинка.

Судя по последним JPG-ам - "field delay", похоже, не до конца убрал чересстрочность, поэтому после него нужно ещё что-нибудь вроде Smart Deinterlacer, и в нём подобрать способ определения движения ("Motion Processing") и порог движения ("Motion threshold"), чтобы он срабатывал только на движение, а неподвижную картинку менее чёткой не делал.
После него полосатости остаться не должно.

И на всякий случай: фильтры для удаления чересстрочности рассчитаны только на "родной" размер картинки по вертикали - 480 NTSC / 576 PAL.

 

Правильно ли понимаю, что имеется ввиду список фильтров в VirtualDub? То, как меняется картинка сделаю позже.

В курсе. Вертикаль стараюсь, по возможности, не менять.

 

989 - без фильтров
990-992 - smart deinterlace
993 - без фильтров
995-996 - deinterlace smooth (как понял по 100fps.com - один из, минимум, двух лучших вариантов)

 

Gamerun, у "smart deinterlace" нужно подбирать настройки - он должен только движение обрабатывать, а сейчас и статичную картинку тоже изменяет, это видно по менее чётким мелким буквам на заставке.

Попробуй сначала "field delay", чтобы основное "разъезжание" убрать без потери чёткости, а после него "smart deinterlace", и в нём подобрать "Frame-only / Field-only / Frame-and-field differencing" - смотря с каким меньше ошибок определения движения будет.

И ещё "Motion threshold" можно увеличить - если не убирает полосы, когда они не очень заметные - или уменьшить, если делает нечёткой неподвижную картинку.

---------- Сообщение добавлено в 01:58 ---------- Предыдущее сообщение размещено в 01:42 ----------

Ещё, кстати, в "smart deinterlace" можно попробовать "Edge-directed interpolate" - это он попытается определить и не смазать контуры.

 

Абсолютно пофиг, хоть 1280. Это всего лишь задаёт частоту дискретизации аналогового видеосигнала захватывалкой. Поэтому чем ширина больше, тем лучше - больше шума потом отфильтруется при ресайзе и чище будет результирующая картинка. Но чем ширина больше, тем больше шансов, что байтики с видеохваталки попросту не будут успевать пролезать сквозь шину к процу и дальше на винт. Так что хватать с шириной 1920 я б таки не стал бы. :-)
Ещё один фактор: исходное горизонтальное разрешение генератора картинки в игровой приставке болтается где-то между 288 и 320. Т.е. надо сначала его точно определить, а потом уже решать - захватывать ли с кратной шириной или нет, каким алгоритмом ресайзить чтобы не было муара и т.д.

 

Методы определения?

Возможно ли описать более подробно? Кратная ширина вне DOSBox видится необходимостью(иначе - плохое изображение при увеличении выше 320х240), под алгоритмами ресайза понимаю фильтры и скрипты AVIsynth.
На всякий случай, еще упомяну такой момент - в MESS про Nintendo 64 прописано разрешение 640х240(как понимаю, учет того, что увеличение до 480 идет за счет чересстрочности или, как вариант, до 480i).

 

Глазами и руками. :-( Захватить с как можно бо́льшим разрешением кадр, в котором есть сетка погуще или иной фрагмент (чем шире тем лучше) с ярко выраженными отдельными пикселами, вычислить дробное число - ширину пиксела оригинала в пикселах захваченной картинки (например, поделить ширину фрагмента в пикселах захвата на количество пикселов оригинала (посчитать вручную), поделить ширину захваченного на ширину пиксела.

Ага. Это уже кое-что (хотя тоже надо проверять). Тогда с высотой проще пареной репы - одно поле выбросить (в avisynth'е это separatefields() и selecteven() / selectodd()) и растянуть на сколько надо.

Скорее страницы help'а по avisynth'у и его исходники, для понимания - какая, собственно, арифметика над пикселами выполняется.
Из готовых avisynth'овых фильтров самый не гадящий муаром и артефактами по краям - это spline64resize(). Годится даже для обработки сканов растровой печати (например, фоток в книгах и журналах).

---------- Сообщение добавлено в 17:00 ---------- Предыдущее сообщение размещено в 16:51 ----------

Пофиг: с какой бы шириной не захватил, всегда можно отресайзить до нужного. Но, к примеру, если в исходном видеосигнале изумительно чёткие края пикселов (технически: полоса частот видеосигнала широка и верхние частоты не завалены), то таки надо хватать с кратной шириной, вплоть до строго равной ширине оригинала (будь то даже 320 или 288 пикселов) - даже ценой некоторой зашумленности картинки и неизбежного лёгкого её замыливания при последующем растягивании. Но если в таком захвате появятся смазы (из-за кривости интерполяции сигнала устройством захвата) или, не приведи кришна, муар (из-за дрожания фазы строчной синхронизации между источником и хваталкой) - тогда увы: надо хватать с максимально доступной хваталке шириной и только потом, после обрезки-шумодава-итд, ресайзить.

 

Самостоятельное определение на глаз сделать не могу, так как не ясно, сколько пикселей должно быть при разности форматов(4:3, 5:4, 16:9, 16:10), так как разница понимается только в разрешении(640x360 для 16:9; 640x480 для 4:3). С определением кратности тоже есть затруднение - максимальное разрешение только 720х480 в VirtualDub и сделать больше вряд ли возможно по честному(как понимаю, только через, условно говоря, хаки)(было бы, во всяком случае, удобно записать сразу 720х576).

Попробую позже сделать новые записи, плюс попробую сделать запись на ноутбуке с XP. Есть мысль, что при увеличении в 2 раза или на полный экран(если проигрыватель), то выглядеть будет не так размазано, как может быть(при 320х240 или 320х288).

 

И всё-таки, похоже, там полноценное 640x480, а 320x240 идёт только на видео.
Видно на заставках:

Если уменьшить до 240, появляется заметная "лесенка".

 

Да кто тебя так обманул???
(подумав) А-аа. М.б. речь про макс. разрешение MPEG2? Ну так не хватай в MPEG2 (это с любой т.з. плохо - хоть из-за потерьного сжатия, хоть из-за P-кадров), хватай в какой-ньдь безпотерьный формат, в крайнем случае складируй несжатые YUY2...

А вот тут фиг: несовпадение кол-ва строк до добра не доводило никого и никогда - по вертикали картинка в принципе хваталкой не интерполируется: либо недостающие строки дублируются из предыдущих (здравствуй "ступенчатые" искажения и срыв чередования полей вдоль высоты кадра), либо лишние выбрасываются (с теми же последствиями). Кол-во строк должно соответствовать СТРОГО!

Не уловил, при чём тут "разность форматов". Подгонять надо ширину строки в пикселах захвата.

Ну вот слушай сюда. Аналоговый телесигнал идёт, гм, аналогово. Начало каждого поля отмечается кадровым синхроимпульсом, его длительность - более-менее 5-10% длительности поля. Поле длительностью 20 мс (для PAL/SECAM; для NTSC это 16 с копейками мс) состоит из нескольких сотен строк по 64 (опять же, для PAL/SECAM) мкс, начало каждой отмечается опять же синхроимпульсом длиной несколько мкс.
Т.о., сгенерированную процессором игровой приставки картинку для вывода на телевизор надо подогнать (интерполяциями или лучше изначально генерировать) по количеству кадров и строк под таковые для выбранного телестандарта, развернуть строка за строкой, между строками и между полями вставить синхроимпульсы, довести получившеся до максимальной похожести на стандартный видеосигнал (подогнать уровни белого-чёрного, закрутить цвет в цветоразностные сигналы и загнать их в положенную часть спектра, обрезать лишнюю частотку) и подать результат на видеовыход. В целом, получается вот такая осциллограмма (подробности тут):



Ширина полосы видеосигнала, напомню, по стандарту ТВ - более-менее 5 тире 6 МГц, что даёт нам как раз б/м три сотни линий разрешения по горизонтали (если попытаться впихнуть больше - пойдёт смазывание и/или муар), или шесть сотен точек.

Теперь смотри дальше. Хваталкой этот сигнал оцифровывается с частотой дискретизации б/м 40 МГц, полученное анализируется, в нём отыскиваются синхроимпульсы и выделяются массивы отсчётов по каждой строке по б/м 2.5 Кбайта каждый; затем эти массивы передискретизируются под заданное разрешение по горизонтали (320, 640, 720 пикселов) и уже в таком виде отдаются процу.

Всё! Наша задача - подобрать такую ширину строки, чтобы свести к минимуму суммарное сглаживание краёв пикселов на всех этапах: на перегонке картинки с приставочного проца в видеосигнал (переключением видеостандарта приставки), на обрезке спектра видеосигнала видеоусилителем приставки (подстройкой фильтров на ейном видеоблоке - для старых (больше пары лет) приставок это м.б. актуально, т.к. параметры фильров таки плывут, спроси у телемастеров), на искажении АЧХ видеосигнала при доставке к хваталке (подбором и/или доработкой и/или аккуратной прокладкой видеокабеля), на захвате и передискретизации видеосигнала обратно в картинку (подбором ширины выходной картинки с хваталки и её типа - RGB или YUV).

(мечтает вслух) В принципе, идеально было бы тырить картинку прямо с проца/ОЗУ приставки сразу в комп, но "съесть-то он съест, но кто ж ему даст?" (L) :-(((((

 

Рыжий Тигра

...и в этом момент приходит светлая мысль, что проще уж эмулятором.

 

...если есть. :-(

 

В том то и дело, что ни один эмулятор Nintendo 64 не эмулирует приставку на 100%(тем более точно) и именно поэтому интересует как лучше всего захватить, записать и, при необходимости, обработать видео и выложить как пример реальной работы реальной Nintendo 64.

---------- Сообщение добавлено в 22:10 ---------- Предыдущее сообщение размещено в 22:08 ----------

Иначе не дает - сообщает, что устройство не поддерживает. (уточняю, что это при записи в VirtualDub в AVI. Не припомню, чтобы VirtuaDub когда-либо работал даже с MPEG2)

 

А-аа. Тады извиняюсь. Никогда не юзал vdub в качестве хваталки, поэтому не в курсе.

 

Как понял, для Windows 7 лучше использовать VirtualDub и, возможно, еще одну утилиту, которую советовали Nubilius'у. Для XP, вроде как, возможно попробовать IUVCR.