Качественное преобразование pdf файла в файлы изображений

[Жрец Нефтиды]

Эта тема, вроде бы достаточно широко освещённая в Сети, имеет некоторое количество тонкостей, напрямую влияющих на качество конечных файлов tif и png.
Хороший конвертер pdf в изображения должен обладать следующими характеристиками:
1. Преобразовывать без вопросов любые pdf, которые открываются в просмотровщиках (PDFMaster, Stduviewer и других).
2. Предоставлять пользователю возможность напрямую задать нужное разрешение (а не просто выбрать разрешение из списка).
3. Предоставлять пользователю возможность из многостраничного pdf либо создать один многостраничный tif-файл, либо серию файлов png. (Я не рассматриваю конвертацию во всякие там форматы с потерями: в наше время терабайтных дисков мелочная экономия на килобайтах себя изжила.)
4. Точно, без искажений, передавать изображения в конечный файл.
5. Работать стабильно, без сбоев (а не через раз).
6. Быть абсолютно бесплатным навсегда.
7. В большинстве случаев при конвертировании pdf в tif или в png производится изменение размеров (ресайз). А по какому алгоритму производится это изменение размеров? Я не нашёл, чтобы во всей великой Сети этот вопрос кто-то поднимал. А мы такой вопрос здесь поднимем и решим.
В данной теме мы не будем говорить об извлечении изображений без пережатия из pdf: такую задачу я уже рассмотрел в одной из тем. Здесь мы поговорим именно о качественном экспорте pdf в серию изображений. В некоторых случаях нам это может потребоваться.
Просмотрев несколько десятков (!) конвертеров, и бесплатных, и шароварных, на старт соревнований я вывел следующие программы, о которых вроде бы хорошие отзывы и которые достаточно широко известны:
XnViewMP [Для просмотра данной ссылки нужно зарегистрироваться]
Ирфан [Для просмотра данной ссылки нужно зарегистрироваться] (для его инсталляции потребуются три инсталлятора: собственно Ирфан, плагины и русский язык)
STDU Viewer [Для просмотра данной ссылки нужно зарегистрироваться]
PDFCreator [Для просмотра данной ссылки нужно зарегистрироваться]
PDF24 [Для просмотра данной ссылки нужно зарегистрироваться]
TTRPDFToJPG3
В любом случае нам потребуется установить Ghostscript, она потребуется для нескольких программ [Для просмотра данной ссылки нужно зарегистрироваться]
Из гонки сразу же выбывает воспетый некоторыми советчиками LibreOffice: он позволяет конвертировать страницы из многостраничного pdf только поштучно, да и с разрешением у него оказалось, в моих исследованиях, не всё ладно.
Задание разрешения в XnViewMP довольно неочевидно, и делается так: "Инструменты" – "Настройки" – "Поддерживаемые форматы" – "Чтение" – "PS/PDF".
В Ирфане ещё интереснее: "Сервис" – Настройки программы" – "Plugins" – кнопка "PDF". Очень важно здесь убрать птицу у "Use (new) "PDF.DLL" Plugin…." Тогда мы заставим Ирфана декодировать pdf не своим внутренним декодером, а декодером из Ghost. Программисты из Ghost лучше всех, имхо, преуспели в декодировании pdf для сторонних программ. Птицу у "Saving options" тоже рекомендую убрать.
Задаём разрешение. OK.
Это ещё не всё!!! Жмём кнопку "Postscript". В двух боксах вводим непременно то же самое разрешение, что мы ввели после нажатия кнопки "PDF".
Птицу ставим у интерполяции. Вот он, выход на п.7 !
Птицу ставим у антиалаизинга.
Птицу у многопоточного режима, видимо, не стоит ставить: так надёжнее.
Я так и не понял, на что в нашей задаче влияет размер бумаги: каким бы мы его здесь ни задали, конечные файлы tif или png будут побайтно идентичны.
Замечу, что когда я оставлял птицу у "Use (new) "PDF.DLL" Plugin….", то Ирфан слетал, работая с некоторыми pdf при задании разрешения 600. Видимо, трудно быть хорошим программистом и для программ работы с изображениями, и для программ работы с pdf: эти файлы устроены совсем по-разному.
OK.
Эксперимент № 1 – на точное соответствие исходного bmp-файла и файла, полученного в результате экспорта.
Возьмём какой-нибудь исходный файл bmp размером 1920x1080 со сложным цветным рисунком (все размеры здесь взяты для из моего FJLL HD монитора 1920x1080). Я нашёл его в фотографиях подводного мира. Назовём его 1920.bmp. Из этого bmp сделаем при помощи OpenOffice файл 1920.pdf, в котором сжатие без потерь, полей нет. Замечу, что OpenOffice – одна из немногих бесплатных программ, которая позволяет при создании pdf не производить пережатие изображений во всякие там джипеги с потерями. Создание такого pdf в Опенофисе – задача не совсем тривиальная. Например, "Стиль углов" нужно сменить со "Скруглённый" на "нет".
Чтобы вышедшим на старт софтинушкам служба мёдом не показалась, запаролим pdf так, чтобы его можно было только читать, и ничего более.
Поскольку мы создали pdf с разрешением 72, то в этом эксперименте мы будем производить экспорт тоже с разрешением 72. Именно такое разрешение зададим во всех программах (а в STDU Viewer это будет разрешение "Исходное"). Просмотреть размеры и разрешение pdf-файла можно, открыв его в STDU Viewer, через "Файл" – "Свойства".
Экспортируем в tif или png – это не важно. Далее tif или png при помощи XnViewMP превращаем в bmp. Побайтно сравниваем полученный bmp с 1920.bmp.
XnViewMP из гонки выбывает: размеры bmp в пикселях получились отличными от 1920x1080.
TTRPDFToJPG3 из гонки тоже выбывает: он отказывается работать с таким pdf-файлом, а если пароля нет, то размеры bmp в пикселях тоже получились отличными от 1920x1080.
Ирфан и PDFCreator дают идентичные друг другу файлы, которые отличаются от исходного файла 1920.bmp на 4 байта, отличия лежат в служебной области.
Количество отличий bmp из PDF24 от исходного 1920.bmp находится в районе 25-30%, на глаз еле заметны, но математически они есть.
Количество отличий bmp из STDU Viewer от исходного 1920.bmp находится в районе 70%, на глаз они видны довольно отчётливо.
Программы развиваются, возможно, через некоторое время что-то изменится, но на сегодняшний день у меня получилось так.
Как там в песне из фильма про мушкетёров? "Увы, мой друг, теперь нас только двое": Ирфан и PDFCreator.
Эксперимент № 2 – на алгоритм изменения размеров.
Создадим bmp файл размером 50x50 пикселей. В нём проведём по диагоналям две перекрёстные линии. Также сделаем из него 50.pdf. Этот файл я прикрепил к теме.
Оставшимися в гонке программами экспортируем изображение из 50.pdf, установив разрешение 1555. Именно при таком разрешении мы получим изображение размером 1080x1080. Смотрим изображение в просмотровщике.
В изображении, произведённом Ирфаном, изменение размеров было сделано по алгоритму, похожему на Митчелла из XnViewMP.
В изображении, произведённом PDFCreator, изменение размеров было сделано по пиксельному алгоритму – самому простому. Все другие исследованные мной программы также изменяли размеры по пиксельному алгоритму. Возможно, кому-то и нравится лобовое пиксельное изменение размеров, но только не мне. Замечу, в Ирфане тоже можно сделать пиксельное изменение размеров, для этого нужно убрать птицу у интерполяции.
Также обращаем внимание, что в Ирфане мы можем задать параметры сжатия без потерь для файлов tif и png. В PDFCreator-е мы ничего такого сделать не можем.
На финиш с большим отрывом от соперников первым прибежал Ирфан, и получил призовую ленточку с надписью "Качество – всё!"
А какое же разрешение лучше задавать? Некоторые "советчики" рекомендуют в любом случае врубить 600, и начать самоутверждаться. Но это не есть правильный подход. Посмотри STDU Viewer-ом, какие пиксельные размеры и разрешение у исходного pdf, и прикинь, что получится. Возможно, получишь tif таких размеров, что на просмотр не хватит памяти. Если целью экспорта в изображения является просто просмотр, то нет смысла получать изображения, у которых пиксельные размеры больше, чем у твоего древнеегипетского монитора. Если же ты собираешься скормить tif Файнрайдеру, то осторожно предложу начать с 400, и если распознается плохо, то поднимать до 600 или даже выше.
Конвертирование в Ирфане не совсем очевидно, поэтому напишу, как оно делается.
Если тебе нужно получить многостраничный tif, то "Сервис" – "Многостраничное изображение" – "Создать многостраничный tif".
Если тебе нужно получить серию png, то "Файл" – "Открыть", открываешь pdf, и далее "Сервис" – "Извлечь все кадры", задаёшь номера нужных страниц.
Использовать Ирфан для просмотра изображений – это на любителя. Я использую XnViewMP.
STDU Viewer со счетов сбрасывать не будем: он идеально извлекает текстовый слой из любых pdf-файлов.

[Жрец Нефтиды]

Предположим, нам нужно преобразовать doc-файл в один многостраничный tif-файл, либо в серию файлов png. Задача не часто встречающаяся, но всё же. Обычно для решения такой задачи предлагают установить в систему виртуальный принтер. Из бесплатных, имхо, самый лучший PDF Creator, для любителей отстёгивать можно предложить Файнпринт. Но в вордовском файле, кроме текста, могут быть ещё и рисунки, которые, скорее всего, будут растянуты или сжаты до размера страницы. По какому алгоритму будет производиться изменение размеров рисунков при прогоне через виртуальный принтер?
Дальнейшее лучше увидеть. Скачай прикреплённый к этому посту doc-файл. В нём расположен тестовый рисунок 50x50 из первого поста, растянутый почти до границ страницы. И немного текста.
Ворд так устроен, что в нём изображения изменяются в размерах для визуального просмотра по алгоритму, похожему на бикубический. Поэтому линии в тестовом рисунке, когда он открыт в Ворде, выглядят относительно гладкими. Теперь "распечатай" этот файл на виртуальном принтере. Разрешение задай 96 – тогда пиксельные размеры png будут примерно соответствовать монитору 1920x1080.
Просмотри png в просмотровщике. Ты увидишь, что тестовый рисунок изменён в размерах по пиксельному алгоритму, он же алгоритм ближайшего соседа. Все известные мне виртуальные принтеры именно так изменяют пиксельные размеры рисунков. Возможно, кому-то нравится такой алгоритм. Ну что ж, бывает. Но мне он не подходит.
Теперь преобразуем doc в png в два прохода. Вначале при помощи Опенофиса преобразуем doc в pdf. Тут главное – задать сжатие без потерь. Далее преобразуем pdf в png или в tif при помощи Ирфана, как описано в первом посте. Тоже с разрешением 96. Сравниваем результаты труда. Видим, что линии здесь сглажены по алгоритму, очень похожему на Митчелла. Конечно, алгоритм Митчелла – это не ланкзос, но всяко лучше, чем пиксельный алгоритм.
Теперь внимательно, под лупой, смотрим на текстовую составляющую. Она слегка отличается у продукта труда Ирфана и у продукта труда виртуального принтера. Что лучше? Выводим Ворд в режим просмотра, задаём масштаб 100%. То, что мы увидим, можно считать идеалом, к которому нужно стремиться. Продукт труда Ирфана точно соответствует этому идеалу. В продукте труда виртуального принтера расстояния между буквами слегка отличаются от того, что мы видим в Ворде. Не так, чтобы уж очень, но мелкие отличия есть.
Я предлагаю для решения данной задачи вообще отказаться от виртуальных принтеров, и идти в два прохода: Опенофис – Ирфан. Качество будет лучше, и не надо грузить систему виртуальными принтерами.
Но два прохода… Стройка древнеегипетская.

[Жрец Нефтиды]

Очень часто рисунок распечатывается не в его истинный размер, а растягивается или сжимается под размер печатного листа. А задумывались ли вы, по какому алгоритму производится изменение размеров при печати на реальном принтере?
Попробуй распечатать тестовый рисунок 50.bmp из первого поста под размер страницы A4 на своём принтере. Увидишь, что растяжение произвелось по пиксельному алгоритму (алгоритму ближайшего соседа). Если это годится, то и вопросов нет. А если не устраивает? В этом случае ответ очевиден: перед подачей на печать нужно изменить пиксельные размеры изображения.
Попробовав с десяток программ-просмотровщиков, я убедился, что самый лучший результат выдаёт Быстрый камень.
Открываем изображение, "Изменить размер". В графе "Разрешение" задаём разрешение нашего древнеегипетского принтера. Например, 1200 тчк/дюйм (у моего HP разрешение именно такое). Дальше продумаем, что мы хотим сделать. Предположим, растянуть по ширине до заполнения страницы, а высота – уж какая получится. Нужно решить, поля какого размера мы хотим оставить. Допустим, 1 см с каждой стороны. Тогда для печати на А4 ширина будет 21-1-1=19 см. Вот её и вводим, а размер в пикселях программа посчитает сама.
Какой алгоритм изменения размеров задать? Однозначно Lanczos2 (резче). Это – единственный известный мне ланкзос, который не создаёт звона. Проверь на файле 50.bmp. Замечу, что ланкзосы из других программ могут не выдавать видимый на экране звон. Но звон всё-таки там есть, и при печати он будет виден на бумаге. Попробуй, убедись сам.
Очень важно, когда мы дальше выйдем на печать, ввести поля страниц именно такими, какими мы приняли их в этих расчётах.
В настройках "Размер" точку ставим у "Исходный размер". Тогда программа точно больше не будет масштабировать.
Реально тебе вряд ли достанется файл размером 50x50 пикселей. Создай белое полотно 300x300 пикселей, нарисуй на нём любые линии разной толщины – от 1 до 6, измени размеры Ланкзосом из Быстрого камня и распечатай. Чёткие линии тебя порадуют.
В Быстром камне есть ещё возможность печатать через "Композиция и печать". Там программа на автомате отмасштабирует рисунок по какому-то ланкзосу. Но это будет не тот замечательный Lanczos2 (резче), и при печати проявится звон. Убедись в этом сам. Так что таким путём мы не будем печатать.
Теперь скачай и распечатай на реальном принтере файл Море.doc из второго поста. Ты увидишь, что рисунок на бумаге увеличился снова по пиксельному алгоритму, хотя на экране мы видим сглаженные линии. Вот незадача-то древнеегипетская: на папирусе получилось не то же самое, что на экране.
Рекомендация жреца такова. Прежде, чем вставлять файл рисунка в Ворд, ты измени его размеры Быстрым камнем. Измени так, чтобы относительный размер вставленного рисунка в Ворде был равен 100%. Вот и всё.
Разумеется, вся эта мелочная возня имеет смысл только в том редком случае, когда ты собираешься распечатывать doc-файл на бумаге, и хочешь, чтобы получилось очень качественно. Если файл предназначен для просмотра на мониторе, то просто вставляй туда любые рисунки, как они есть: Ворд или Опенофис дальше позаботятся о сглаживании сами.
[Для просмотра данной ссылки нужно зарегистрироваться]