Искажения сканера Epson Perfection V350 Photo (в продолжение темы с ixbt)

Долго, по началу, исправлял искажения (растягивания по ширине) простым линейным сжатием (умножал ширину в пикселях на 0.975). Что действительно устраняло общее уширение по листу. Но, как оказалось, локальная ширина плавала туда сюда.
Легко проверялось сканированием какой-нибудь таблицы, сжатием по ширине, распечаткой и наложением на просвет с оригиналом - ширина столбцов была разная.

Для выяснения характера искажений, нарисовал сетку (таблицу) на листе A4.
Сетка 4х4 см, т.е. в пикселях должно быть (4 см делим на 2,54 дюйм/см и умножаем на разрешение 300 точек/дюйм):
4/2,54*300=472,44 ( или 472+-1)

Скан сетки (высота ячеек стабильно 473 пкс., т.е. как заданная, а вот ширина плавает заметно; хорошо, что стабильно по высоте)

Далее провел замеры ширины. Составил таблицу и глянул на график - "Ох! Ничего себе, как бык поссал!".

График 1. Измеренная ширина ячеек в каждой строке.

Собственно, графики линейной регрессии - это и есть способ прямой (линейной) компенсации, которым пользовался поначалу (умножал ширину скана на 0.975, хотя после уточнения 0.971). Но, как оказалось, нелинейные искажения никуда не деваются.

График 2. Относительное уширение ячеек (в %)

...
Начал думать и искать способ более точной компенсации (калибровки).
Поиски привели к RxSpotlight. С виду программа страшная, своим функционалом, нагруженный интерфейсом. Как там у Голубицкого - кривая (курва) обучения задрана высоко. Софтина заточена на профприменение. Но главное умеет калибровать изображения. Есть в ней и скрипты, для автоматизации. Вот и состряпал таблицу калибровки. Составил простой скрипт, который вначале повышает резкость, потом калибрует (сжимает) как раз по сетке 4х4 см.

Откалиброванный скан (уже много лучше, но первый столбец чуть хуже; потери деталей несущественны)

Мой старый термопот

Шесть лет отслужил, из заявленных семи. Неплохой результат, однако.
Моторчик ослаб совсем, а так - греет.

Голый, без кожуха

Отверстия в крышке для пара, пластик расcыпается (крошится, от пост. нагрева - слабое место)

Крышка, сталь и резиновое кольцо (в порядке)

Колба, ржа от воды, лимонкой не отмывается

Анаморфные приключения

22.07.09 01:20
Так, практически разобрался с PAR.

Оказывается, есть два разных способа указать PAR:

1) при кодировании в Vdub:XviD(или xvidencraw):Aspect:PAR<>1 (т. е. не квадратные пикселы),

2) при сохранении в AVI в стандарте AVI2.0 (OpenDML).

VDub и xvidencraw на выходе выдают avi (для 1 или 2ГБ, avi1.1 или всё же AVI2.0, не разобрался) не выставив в его заголовке значение PAR, только флажки в поток видео xvid (aspect_ratio_info). Но вот какая штука, старые плееры, работающие через DirectShow и декодер ffdshow и выводящие через Overlay (искл. VLC, KMP, но у них внутренние декодеры), не принимают флажки из xvid. Плееры же, выводящие через VMR7/9, принимают значение PAR из флажков через ffdshow (там галочку output:overlay_mixer (Set pixel aspect ratio in output media type) в “серое” среднее положение нужно поставить или полностью включить, а так же выключить (снять галочку) или в среднее положение (серая галочка) - output:Allow output format changes during playback).

Т.е., вот закодировал с флажками PAR в xvid: Insomnia_720x368 и для AVI1.0 (без OpenDML) это так. Но всё путём, когда есть PAR в AVI2.0 заголовке — 864x368. Чтобы получить такой avi, нужно его пересохранить (прогнать) через ”ffmpeg -vcodec copy”. Он прочтёт PAR из флажков xvid и пропишет его в заголовок avi (ещё говорят, что то же делает mencoder, но у меня никаких изменений после него). Последние опыты показывают, что, похоже, xvid прописывает PAR где-то ещё (читаем дальше, на этом этапе я ещё не знал, что виноват не xvid).

И если PAR был выставлен правильно при кодировании, то всё нормально получится. Но если был неправильный, как это было с двумя первыми моими анаморфными рипами: 1) Nausicaa_xvid_672x520_anamorf — указан как 66:65, т.е. 682x520 (66/65*672=682), а должно быть 239:168, т.е. 956x520 (и тут ошибочка, нацело не делится на 16, ниже разбор) ; 2) We_Were_Soldiers_xvid608x368_anamorf221x100 (тут та же ошибка), то, даже после выставления через MPEG4Modifier правильных флажков в xvid, остаётся в каком-то месте первоначальное значение (читаем дальше). И хоть ffmpeg в статистике показывает правильное значение PAR, после изменения в MPEG4Modifier, но вписывает в заголовок avi именно то самое первоначальное значение (как оказалось, вывод неверный — он просто не меняет его, если уже видит в заголовке, об этом читаем дальше).

Как это выяснилось? Тестом.

Test.avi: 720x368, PAR=60:45., т. е. с восстановленными пропорциями: 960x368.

Обозначим вывод через overlay (заголовок avi, OpenDML) = OVL, а через VMR7/9 (xvid PAR флажки,) = VMR.

Тогда плееры, что выводят в OVL: Crystal, BSPlay:OVL, LA, MPC:OVL.

Выводят в VMR: MPC:VMR, VLC:OVL (искл.), KMP:OVL(искл.).

Результаты: 1) xvidPAR (кодирование) → OVL:720x / VMR:960x; 2) ffmpeg -vcodec copy (копирование) → OVL:960x / VMR:960x; 3) MPEG4Modifier (просто уменьшил, т. е. изменил PAR) → OVL:960x / VMR:864x; 4) ffmpeg -vcodec copy (повторное копирование) → OVL:960x / VMR:864x (т.е. изменения во флажках он видит, но ставит из другого места с прежним PAR выставленном в xvid, или вообще не меняет, видя уже прописанное ранее значение). Приплыли, т.е. неправильно выставил PAR в xvid и в OVL уже не изменить (об этом далее).

27.07.09

Опыты с Навсикаей - неправильно закодированный PAR.

Nausicca_672x520_anamorph (неправильный xvidPAR = 66:65)

VOB:PAL=720x576 (16:9); 16/9=DAR=1.78; 576*16/9=1024 => 1024/720=h*DAR/w=PAR=1.4(2)

crop: w=16, h=32 => 704x544; resize: 672x520 672*PAR(1.42)=956!, а в MPC и Crystal выставив 16/9 получается неправильно: 520*DAR(16/9)=924 – точность потеряна из-за кропа.

Новый DAR=956/520=1.839 (239:130); PAR=956/672=1.4(2) (239:168; для 1024 => 256:180, 128:90, 64:45)

Далее про AC3 interleaving.

VDub standard 500ms / 1 frame

Но, нашёл на форуме упоминание про соответствие kbps / chanels / Preload (ms) / Interleaving (ms):

448/6/128/128; 384/6/160/160; 256/2/48/48;

224/2/64/64; 192/80/80

Кто-то пишет, что для PAL надо 2 кадра (1000/50=20ms), другие, что блоки AC3 идут по 32ms, и надо кратно ему, т.е. 64ms, 96ms.

Прогон через ffmpeg даёт 32/32ms (0.80 frame).

Т.е. можно исправить в Навсикае хотя бы xvidPAR (через MPEG4Modifier прямо с AC3 ?), а потом пропустить через ffmpeg, чтобы он сремуксил до 32/32ms.

31.07.09

Новые результаты.

1024/720=PAR(64:45)

Т. к. 672*PAR=955.7(3)=956 не делится нацело ни на 8, ни на 16, то выбрал ближайшее 960.

Ошибка меньше 0.5%, зато всё делится на 8 и почти всё на 16 (кроме 520): 960/672=PAR(10:7); 960/520=DAR(24:13).

Но это не главное - важно, что теперь найден путь исправления не только флажков xvid с ошибочным PAR (через MPEG4Modifier) но и, после этого, ещё и PAR в заголовке avi. Видимо, ffmpeg только один раз вносит эту запись, а потом, сколько не меняй флажки xvid, толку уже не будет.

А способ такой. После исправления флажков vxid и открываем промежуточный avi в AVIMuxGUI, далее нажимаем generate и, щёлкнув ПКМ по видеодорожке, выбираем extract binary (raw), чтобы получить голую дорожку с расширением raw. Вот теперь её пропускаем через "ffmpeg -vcodec copy" и получаем avi уже с правильным (новым) PAR во вновь созданном заголовке. Тоже может и mencoder, но он не прописывает для avi его разрешение и fourcc (вид кодека). Впрочем, и ffmpeg прописывает свой fourcc=FM4, который лучше заменить на "XVID"любой программой, умеющей это делать (Nic's FourCC changer, abcAVI). Теперь осталось прикрепить аудио и вуаля!

Проблема ffdshow с PAR в Overlay Mixer

А у меня вот такой вопрос.
Почему он некоторые анаморфные XviD рипы может растягивать по горизонтали до указанных в потоке видео флажков PAR не только в VMR7/9, но и в OverlayMixer (LightAlloy 4.4, CrystalPlayer 1.8), а другие нет?
Знаю, чтобы он соблюдал пропорции, надо поставить:
1. В среднее положение (серая галочка) или полностью включить - Set pixel aspect ratio in output media type.
2. Выключить (снять галочку) или в среднее положение (серая галочка) - Allow output format changes during playback.

То, что в VMR оно правильно работает всегда, это проверено многократно. Но чем таким особенным могут отличатся AVI, закодированные в XviD с PAR отличным от 1:1 (рассматриваю только PAR > 1), что одни в верлее он растягивает, а другие не хочет. Пробовал кодировать даже в разных версиях XviD, менял по всякому PAR в MPEG4Modifier, бестолку.

Сканер Epson Perfection V100(300) Photo (тема с ixbt)

Предистория:

ВЕК
Откуда: Россия, Москва
написано 09.05.2007 02:36

Перед визитом в сервис - вопрос ко всем обладателям V100:
Обнаружил, что он по короткой стороне листа растягивает изображение на 4.5 мм (для рамки по краям листа А4). По длинной стороне - все ОК. У всех все нормально с этим?

-
spamusha
написано 02.10.2007 01:05

цитата:ВЕК:
VS
Спасибо, завтра понесу в сервис. Я искажение тож при сканировании диска обнаружил.

Несколько дней назад приобрел сабж. У меня тоже растягивает по короткой стороне. (карточку шириной 85 мм он видит как 87 мм). От параметров сканирования ничего не зависит, потому что все определяется при предпросмотре и выборе области сканирования.

Так что сказали в сервисе?

-
dioxin
Откуда: Россия, Москва
написано 04.10.2007 17:23

ВЕК растягивает изображение

у меня тоже самое, жаль поздно обратил внимание. правда модель v10 но глюк аналогичный. решил проблему перепродав сканер дальше. взял новый canon 8600, с ним всё ок, а к эпсону я больше не ходок, нет времени на сервисцентры тратить.

-
spamusha
написано 02.11.2007 22:31

цитата:Пламя:
ВЕК, MIDIMaker, spamusha, подскажите, проблема с искажением действительно имеет место быть?
Сканер нужен для перевода эскизов (шрифты) в векторную форму, и не хотелось бы, чтобы железка что-то додумывала за меня...

К сожалению, да (по крайней мере у меня). Как я уже писал выше, в сервисном центре попробовал два экземпляра V100 и один V200 - все растягивают. Однако, в принципе, не все так страшно. Проблема решается просто: сканируем, затем замеряем реальный размер (по ширине поля сканирования), открываем файл в фотошопе и непропорционально ужимаем до нужной величины (можно пересчитать в пикселах, можно в миллиметрах).
Кстати, только что проверил свою гипотезу по поводу борьбы с фальшивомонетчиками - отсканировал 1 доллар на 3200 dpi, а затем зажал в соответствии с физическим размером в фотошопе. Гипотеза не подтвердилась - ничего не размылось, микролинии видны. Значит, просто косяк изготовителей.
Конечно отдавать больше $100 за заведомо глюкавый продукт не очень интересно, поэтому советую при покупке особо уточнить у продавцов этот вопрос (возможно, что это просто дефектная партия, и вам попадется хороший). А проверить проще всего сканированием обычного компакта - овал вместо круга заметен на раз.

-
MaSciT
написано 06.11.2007 23:53

Пламя
ani_mator
А у меня прапорции правильные... так что видимо где как, когда покупал не знал, что такая проблема может быть... может просто повезло...

-
Rid0748
написано 25.04.2008 10:37

Купил Epson V200 и тоже по короткой стороне листа растягивает изображение на 2,8-3,0 процента. К примеру, сканирование топосъёмки по кускам с последующей склейкой вообще не возможно! Есть ли способ устранения этого? Кому-нибудь по гарантии удалось заменить на нормальный или все такие?

-
Fizick
написано 06.12.2008 14:20

Присоединяюсь к вопросу Rid0748.
Действительно обнаружил растягивание изображения вдоль короткой стороны (у аналогичного сканера V350).
Такое впечатление, что у них поперечный дюйм внутри считается по 25,0 мм (или еще меньше) вместо 25,4.
И нигде в в нерусскоязычном интернете ничего об этом.
Побовал ставить самый последний английский драйвер с японского сайта - тоже не помогло.
Проверяется очнь просто. Сканируем линейку с миллиметровыми делениями. Уже в окне предсмотра размер можно увидеть, выделяя область на линейке.
Я бы не удивился если бы вдоль листа изменение было, там ведь двигатель тянет. А поперек-то матрица лежит (вроде, или я ошибаюсь в устройстве сканера?)
У кого-то вообще нормально работает с руской Виндоуз? (Бред конечно.)

-
qb1
написано 07.12.2008 17:21

1. Появились подозрения на счет пыли под стеклом с внутренней стороны - заметил что пленка в автозагрузчике заряжается статическим зарядом - щелкает если подняв крышку дотронутся пальцем до нее, как обороть это не знаю, это видимо подло и натягивает под себя пыль.

2. Отсканировал линейку и открыл картинку в фотошопе. да, действительно по короткой стороне на 100 мм уходит где-то на 2.5 мм в плюс масштаб. По длинной стороне все ок

3. Галочка на повышение резкости упорно ставится автоматом только если создавать миниатюры, а если выводить всю ленту и выделив кадры сканировать то ок. Почему то при сохранении профиля настроек эта галочка не убирается и опять же выбранный новый профиль не остается по умолчанию.

Собственно, вот что с моим V350:

Хм, спустя полгода после покупки тоже обнаружил растяжение на своём V350 (те же 2.5%)
Не понятно только, это проблема дров (русских или версии конкретной) или аппарата? Может кто юстировку пробовал делать? (полагаю, это как здесь разбирали http://www.ixbt.com/digimage/epson1670b.shtml)
Другие дрова решают проблему? У меня 3.0.4.0, Epson Scan\About: 3.04E, а на сайте 3.04A - эт чё, старее там версия; вот Copy Utility у меня 3.23, на сайте 3.27 - сразу видно, что свежее.
Нашёл, что в СильвеФаст можно указать масштаб отдельно по горизонтали.

Способ записи большие HD файлы на однослойные болванки

Опишу способ, которым я подготавливаю HD-фильмы к записи на однослойные болванки
Прежде всего, конечно, пришлось на винте выделить раздел в 10ГБ под NTFS, чтобы сохранять на нем эти объемистые файлы (раз уж они >4ГБ), да хоть и поочередно.
Приобретать по каждый фильм двухслойную болванку жаба давит (100-110р против 2 х 12-14р).
Думал, вначале, резать файлы на части с помощью HJSplit. Потом нашел более интересный способ, как раз для mkv. Как раз, тут упомянутый mkvmerge_gui (mkvtoolnix), умеет разрезать mkv-шки на части хоть по указанному размеру, хоть по времени и при этом, если включить функцию link files, может выстроить из них связанную цепочку с единым временем. Т.е. при проигрывании, когда в haali splitter включена фишка Input\Try to open linked files, я и не заметил переходов между частями (физически отдельные файлы, похоже это как тома в rar - имеют внутри ссылки на друг друга).
Порезал на части по 1ГБ и сгенерировал в ICE ECC файлы восстановления для заполнения оставшегося места на болванках. А дальше... дальше можно уже раскидывать как душе угодно на стандартные dvd5!
(Ну и конечно можно выкидывать ненужные аудио дорожки, скажем зачем нам немецкая)