Сетевая графика под Linux

Введение

Еще одной причиной приобщения к Линуксу для меня являлась необходимость работы с графикой вообще, картографическими материалами в частности и геологической картографией в особенности. То есть: считывать цифровые карты определнных форматов, их видоизменять и готовить для представления в Сети. О первых двух проблемах - как-нибудь в другой раз. А пока - о Сетевой графике. Как элементе не дизайна, но контента.

По сию пору едиственной общераспространенной формой Сетевой графики является растровая. Она существует в виде двух форматов - JPEG и GIF. Первый предназначен для фотореалистических изображений, второй - для штриховой графики и текстовых элементов. Для представления иллюстраций, сочетающих фотореалистические, штриховые и текстовые компоненты, надвано был предложен формат DjVu. Он пока не получил широкого распространения, но в ряде случаев представляется оптимальным.

Специфика геологической графики такова, что для ее представления подходят форматы GIF и DjVu. Какими же интсрументами для работы с ними мы располагаем по Линуксом?

И так, имеем выполненные в каком-либо графическом редакторе картматериалы, включающие: растровую подложку (аэро- или космофотоснимок, теневую или имиджевую карту рельефа по данным DEM и т.д.; отрисованные векторные элементы (стратиграфические и фациальные границы, разломы различной геометрии, кинематики и ранга); текстовые элементы (индексы геохронологической шкалы, названия геологических структур и тому подобное). Все это трансофрмировано в какой-либо общепринятый растровый формат без потери качества (например, TIFF).

Требуется превратить это безобразие в форму, пригодную для представления в Сети и понимаемую большинством общеприменяемых браузеров (возможно, после установки кое-каких plug-in'ов. И при этом занимающую по возможности минимальный объем. При том, что для понимания деталей геологии размер рисунка - не менее 600-800 пикселей по горизонтали (для определенности - 600, что может просматриваться практически на любом мониторе).

Сначала, колнечно

Традиционные методы

Для работы с растровой графикой под Линуксом имеется такой замечательный интсрумент, как

GIMP

Входящий ныне в стандартный комплект оконной среды KDE. Настало время поговорить о нем подробнее.

При запуске GIMP'а на экране появляется интсрументальная палетка (размер ее - изменяемый) со строкой меню в верхней части. В меню - только два пункта - File и Xtns. В первом - ограниченный набор базовых операций: открытие и создание файла, выход из программы, установки (в том числе - настройка инструментов, таких, как кисти, цветовые палитры и т.д.). В пункте Xtns - сканирование, снятие экранных копий, браузеры по веб-ресурсам и базе данных скриптов, а также сами скрипты. Все прочие манипуляции совершаются (после открытия или создания файла) щелчком правой клавиши мыши на изображении.

Отступление: В одной из предыдущих заметок я пожаловался на низкое качество скриншотов, получаемых штатным средством оболочки KDE - программой KSnapshot. Так вот, экранный грабер GIMP'а дает возможность делать экранные снимки существенно лучше; все скриншоты в настоящей заметке сделаны с его помощью.

И так, грузим наш tif-файл, принятый за исходный. Что можно сделать с ним средствами GIMP'а? Чтобы узнать это, прибегаем к помощи правой клавиши. И видим всплывающее меню с пунктами - file, edit, select, view, image, layers, tools, filters, script-fu, dialogs.

Назначение первого - понятно, это манипуляции с файлами, а также общепрограммные настройки и печать. Следует только отметить, что GIMP не имеет собственного формата файла. Но позволяет напрямую открывать практически любой растровый формат. И по умолчанию (командой save) сохраняет в формате открытого файла. Функция же экспорта осуществляется командой save as. Список экспортируемых форматов также очень широк. Интересно, что в нем учитывается характер изображения: скажем, файл в индексированных цветах (например, gif) нельзя напрямую сохранить в полнолноцветном виде (как tif или jpeg) и - наоборот, для сохранения tif-файла в формате gif необходимо предварительно выполнить индексацию. Сначала это кажется непривычным, но, по сути, логичнее, чем в PhotoShop'е (и требует меньше промежуточных манипуляций).

Пункт edit в основном аналогичен таковому стандартных Windows-программ: те же вырезание, копирование и вставка, undo и redo (число их уровней устанавливается в prefeneces, по умолчанию - 5). Смысл остальных подпунктов - понятен из их названий (fill - заполнение фоновым цветом, stroke - создание ограниченной области, и т.д.).

Пункты select и view - также не вызывает затруднений. В первом - всякого рода выделения (в том числе цветовых областей) и запись из в виде канала. Во втором - зуммирование, скрытие/показ линеек, направляющих и привязка к последним.

Следующие манипуляции с рисунком - в пункте image. Здесь его можно преобразовать (в RGB, индексированные цвета или градации серого), трансформировать, вращать, обрезать и т.д. Здесь же - работа с альфа-каналами и цветовыми палитрами. Интересны подпункты Resize и Scale. Первый - обрезает рисунок до заданного размера, тогда как собственно изменение его размера (то, что называется resize в PhotoShop'е)- осуществляется посредством scale (то есть масштабированием). Что, хотя и непривычно, но содержит больше логики.

С пунктом layers все ясно - это действия со слоями. Я вот в пункте tools - масса всяких подпунктов. Здесь и выделение областей всяческой формы (многоугольников, полигонов, произвольной формы и т.д.), и перемещение, и обрезание, и зеркалирование, и вращение (что частично совпадает с некоторыми подпунктами из пункта image). Сюда же, в соответствие с названием, попажают интсрументы типа кистей, ластика, пульверизатора и прочего. И здесь же - средства работы с текстом. Слдеует заметить, что многие эти действия доступны и из инструментальной палетки. Которая является плавающей и совершенно не зависит от окна с изображением.

Следующий пункт - filters - аналог соответствующего PhotoShop'овского. И подпункты его примерно совпадают со штатным набором последнего. Интересно тут то, что многие фильтры - неактивны; можно предположить, что они существуют в природе, но не входят в стандартную поставку или не устанавливаются по умолчанию.

Самое интересное в GIMP'е - пункт Script-Fu, не имеющий, насколько я знаю, аналогов в других растровых редакторах. Это - набор скриптов для содания всякого рода спецэффектов. Что в целом близко к назначению фильтров, но отличается тем, что скрипты эти может писать каждый. Если, разумеется, знает соответствующий язык (насколько я успел узнать - Tcl, Scheme и Perl). То есть мы имеем дело с неким набором интерпретируемых команд, посредством которых можно создавать какие-нибудь уникальные эффекты в личных (и не только) целях.

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

Последний пункт, dialogs - почти аналогичен таковому из меню files и содержит всякие инструментальные настройки, редакторы градиентных заливок и индексированных палитр, слоев и каналов.

Вот, вкратце, обзор основных возможностей GIMP'а. Что же из этого изобилия мы можем приспособить для нашей цели?

Поскольку предполагается, что исходный tif-файл при изготовлении был доведен до кондиции с точки зрения качества, единственное, что сейчас требуется от GIMP'а - это трансофрмировать его в GIF с минимальными потерями и максимальным сжатием.

Для чего сначала произведем индексацию (подпункт indexed в пункте image). Здесь перво-наперво нам предлагается выбор палитры: полной 256-цветной, вебовской 216-цветной, заказной (которую можно выбрать из готовых и потом отредактировать), или однобитной черно-белой. Здесь же - включается или отключается dithering.

Получив рисунок в индексированных цветах, просто сохраняем его (save as) как GIF. Для чего вводим новое имя (имя исходного tif'а не наследуется), выбираем определение типа (Determine file type - GIF, расширение при этом присваивается автоматически), и жмем OK. Нас спрашивают, желаем ли мы иметь черезстрочный GIF (по умолчанию - выключено) и не требуется ли комментарий (по умолчанию - Made with GIMP, но можно ввести свой; поскольку наша цель, кроме всего, еще и сжатие, последнее явно лишнее). Интересно, что я нигде не нашел опции - прозрачность GIF'а. Отношу это к недостаткам.

И как же GIMP справился с нашими основными задачами - сохранением качества и компрессией? С первой - вполне нормально, мои рисунки и в 256-, и в 216-цветной палитрах получились вполне пристойными. Причем практически неотличимыми друг от друга, что бывает не всегда.

С компрессией - неоднозначно. В 256-цветной палитре рисунок размером 600 на 540 пикселей (исходный tif - 970 килобайт) достиг научно-фантастического размера более 300 килобайт (в два раза больше, чем при экспорте из PhotoShop'а при аналогичных установках). Правда, при переходе к веб-палитре он волшебным образом уменьшился почти втрое - до 125 килобайт (повторяю, с точки зрения качества они при этом были неотличимы). Можно предположить, что путем редактирования палитры его можно уменьшить еще больше. что будет сопоставимо с результатами работы специализированных GIF-оптимизаторов для Windows (из которых большинство - лпатные, и весьма дорогие для shareware).

Ради интереса поэкспериментировал и с трансофрмацией того же файла в jpeg. Здесь результат был вполне ожидаемый: чуть больше 300 KB при минимальном сжатии, около 15 - при максимальном и чуть меньше сотни - при промежуточном (50%). В первом случае рисунок был почти читаемым, но для моих целей непригодным (артефакты вокруг букв и рисованных границ), в последнем - откровенно плох. Хотя при максимальном сжатии - еще хуже. Что лишний раз подчеркивает непригодность jpeg'а для поставленных в этой заметке целей.

Завершая затянувшийся разговор, подведем итоги.

GIMP в современном его виде (и без факультативных средств в виде фильтров и скриптов) вполне пригоден для выполнения большинства обыденных задач обработки растровой графики и представления ее в Сети. К достоинствам его следует отнести предельную логичность организации и простоту использования. И, как следствие - простоту освоения, особенно для человека, не испорченного PhotoShop'ом (авторы последнего явно больше тройки по классической логике не имели). С точки зрения возможностей - более чем достаточен для подавляющего большинства задач.

Недостатки - изрядная медлительность, особенно при трансформациях или применении таких ресурсопожирающих фильтов, как размытие; видимо, оптимизация последних версий PhotoShop'а под MMX дает себя знать (припоминаю, что раньше и там при сходных операциях можно было не только покурить, но и выпить-закусить). Ну и невозможность создать прозрачный GIF; хотя, возможно, я просто не понял, как это делается. А лично меня больше всего раздражала необходимость отключения вставки комментария при каждой записи (и перезаписи!) gif-файла. Может быть, авторы пойдут мне на встречу и сделают ее по умолчанию выключенной? Все же gif - формат в первую очередь для Сети, а там каждый лишний байт - лишний... Впрочем, это так, придирка.

Однако не GIMP'ом единым жив человек, готовящий Сетевую графику. Даже под Linux. В ряде случаев полезно воспользоваться такой программой, как

Compupic фирмы Photodex

Это - бесплатный для некоммерческого использования продукт, доступный (в виде rpm-пакета размером 1,8 мегабайта) на сайте соответствующей фирмы: http://www.compupic.com. Версия под Linux портирована с платформы Windows, что обуславливает многие ее особенности.

По своему предназначению Compupic - менеджер графических файлов, типа Ulead ImPal или PhotoImpact под Windows, например. После не вызывающей проблем распаковки и запуска появляется окно следующего вида: в левой стороне вверху - дерево каталогов (папки, содержащие графические файлы, выделены цветом), в правой - содержание выбранного каталога в виде иконок; те из них, которые соответствуют известным программе графическим файлам (среди которых - bmp, tiff, gif, jpeg, png, psd и другие) , представляют собой их миниатюризованные изображения; в левом нижнем углу - превью выбранного файла. Щелчок по нему (или непосредственно по иконке) вызывает файл для редактирования (рис. 8). img src="illustrations/ris08_compupic.png" width="470" height="355" border="0"

Рисунок 1. Compupic для Linux - менеджер графических файлов

Рисунок 1. Compupic для Linux - менеджер графических файлов

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

Кроме того, имеется возможность просмотра в виде полноэкранного слайд-шоу, автоматического или в произвольном порядке. Ну и еще всяческие опции (в частности, индексирование каталога).

В общем - простая и удобная база данных графических изображений. Функционально сходная, повторяю, с Ulead ImPal. В отличие от последнего, как будто не позволяется подключить внешний графический редактор. Однако имеются собственные функции редактирования изображения. Ограниченные, но в большинстве случаев вполне достаточные.

Как уже говорилось, щелчок левой клавишей мыши (двойной, что необычно для XWindow, сказывается тяжелое наследие Windows-режима) по иконке открывает окно редактирования изображения. А здесь по щелчку уже правой клавишей доступны (помимо стандартных операций с файлами, вырезания, вставки, масштабирования вида, вызова помощи и т.д.) многочисленные манипуляции непосредственно над рисунком (пункт меню Image).

Среди них:

Результаты этих манипуляций могут быть сохранены в различных форматах, среди которых - bmp, pcx, tiff, gif, jpeg, png и даже psd. Следует заметить, что при закрытии рисунка предложения сохранить изменения не следует - об этом следует помнить самому.

Качество изображения, получаемого при всех опробованных мной экспортных фильтрах, вполне приличное. А о размере получившихся файлов можно судить по таблице 2.

Все распространенные (и описанные выше) Сетевые растровые форматы - и GIF, и JPEG, и PNG, имеют один общий недостаток - они не масштабируются. А при анализе геологической графики очень существенно иметь возможность видеть один и тот же объект в различных масштабах - от предельно генерализованного для выявления региональных структур до максимально детального для локальных особенностей.

Восполнение этого (и ряда других) недостатка можно в нетрадиционных графических форматах, Один из которых именуется

DjVu

Формат со столь завлекательным названием был придуман в прошлом году фирмой AT&T. И по замыслу предназначался для сканированных изображений, совмещающих полноцветную графику и текст, для которого требовалась читабельность.

За без малого год жизни djvu весьма развился и ныне вполне пригоден для представления в Сети. Хотя широкого распространения там не получил, на мой взгляд - незаслуженно. В меру скромных сил стараюсь изменить к нему отношение. В том числе - и на платформе Linux. Для коей ныне имеется весь необходимый инструментарий и средства просмотра.

И так, на сайте AT&T ныне доступны: djvu sdk- инструментарий для изготовления DjVu-файлов, djvuedit - средства их редактирования, и npdjvu - plug-in для просмотра в браузерах. На настоящий момент текущие их версии - 2 с дальнейшими нулями и единицами, для кого как. Все это имеется практически для всех существующих платформ - Windows всякого рода (разумеется), Sun, SGI и, наконец, для Линукса (в вариантах libc5 и libc6). Интересно, что все они - бесплатны, за исключением sdk для всех Виндов: для тех предлагается trial. В чем его тральность - не разбирался, так как под Виндами пользуюсь бесплатной утилитой DjVuer фирмы Feith.

Версии для Линукса представляют из себя три архива tar.gz (размером, соответственно, 2 MB для sdk, 1,2 MB для edit'а и 1,1 MB - для plug-in'а. Превые два для скачивания требуют регистрации, через которую прорваться бывает нелегко. А само скачивание происходит медленно и печально, вне зависимости от канала и времени суток (видимо, сервер так работает).

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

А дальнейшее - это запуск инсталляционного скрипта (install.sh) в терминальном (или текстовом, разницы нет) режиме. Там для начала предлагается долго и нудно знакомиться с лицензионным соглашением (в enter по строчке). После согласия с его условиями вопрошают, не расхотелось ли Вам устанавливать программу. Если нет - все дальнейшее происходит быстро и просто. Инсталляшка предлагает ввести пути до исполнимых файлов, библиотек, man'ов, doc'ов и прочего; и при этом любезно подсказывает пути по умолчанию - достаточно просто жать enter. Следует только озаботиться, чтобы (если устанавливается из режима юзера) соответсвующие каталоги были ему, этому самому юзеру, доступны для записи. Затем с пулеметной скоростью мелькают компируемые файлы - и финал, поздравление с благополучной инсталляцией. Все. Вспомнив, с какими путями Вы согласились, и найдя соответствующие бинарные файлы, можно начинать работать.

Установка двух прочих наших пакетов происходит аналогично: распаковка архива, чтение README, запуск скрипта, чтение длинной лицензии, предложение путей и собственно установка. Единственно, для plug-in'а предлагается два режима установки - частный (private, то есть только для себя, любимого) и публичный (public, то есть - все для народа), первый - в режиме юзера, второй - root'а; если Вы запустите публичную установку, не имея соответствующих прав доступа, будет автоматически запущена приватная установка.

Теперь - к использованию. Пакет DjVu включает два основных компонента - djvuencode и djvudecode. Первый, как и следует ожидать, предназначен для преобразования всяких растровых файлов (TIFF, BMP, JPEG, GIF и еще нескольких) в формат DjVu. Второй - для обратной процедуры. Поскольку она представляется мне не актуальной, говорить об ней не буду.

djvuencode запускается в терминале (или текстовой консоли). Формат команды прост до безобразия - djvuencode [options] исходный_файл целевой_файл. Опций не очень много и принципиально важными кажутся две (хотя на самом деле - не одной). Те, которые отвечают за режим преобразования.

Режимов несколько, но большая их часть предназначена для сканирования вских разных типов фотографий, в чем я ничего не понимаю. Заслуживают внимания, как будто бы два - фото режим (-p или -photo) и режим документа (-d или -dpi). Фоторежим предназначен, как можно понять, для оригинальных (то есть нами созданных) изображений. И, согласно документации, обеспечивает оптимальные качество и размер. С чем, как будет видно ниже, следует согласиться.

Режим документа предназначен для сканированных изображений с текстом. Он требует еще одного параметра - разрешения (N). Каковых можно выбрать - 100, 200 или 300 dpi.

Следует сказать, что под разрешением в данном случае подразумевается нечто прямо противоположное прнятому среди простого народа. А именно - разрешение, с которым сканировался исходный документ. В соответствие с этим осуществляется его преобразование. То есть, чем ниже исходное разрешение, тем больше программа пытается улучшить изображение. В результате: при N, равном 100, мы имеем максимальный размер файла и наилучшее качество, а при 300 - наоборот, минимальный файл и качество отменной паршивости. Поскольку исходное наше экранное изображение имеет разрешение заведомо не выше 85 dpi (обычно - меньше).

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

Это можно проиллюстрировать на примере того же tif-файла, использованного в первом разделе. В фоторежиме из него получился djvu-файл в 122 килобайта, в режиме документа (и 300 dpi)- в 150 килобайт. При качестве, существенно лучшем в первом случае. Что можно видеть на рисунке (второй пример, ввиду его явной похабности, и приводить не буду).

Касаемо качества - оно не уступает gif'у в части передачи надписей и линий и lpeg'у с минимальной компрессией - в части передачи полутонов и фотоизображений. То есть, по моему мнению, близко к идеалу. При сопоставимом (или меньшем) размере сравнительно с обоими.

Ну, с процедурой создания djvu-файлов все более-менее ясно. Я уже был знаком с ней по указанной Виндовой утилите. Что оказалось для меня неожиданным в линуксовых версиях этого инструментария - это возможность редактирования (как это назвали авторы) djvu-файла. То есть - создания на нем активных областей (или, говоря по русски, image map), как на самом простом gif'е или jpeg'е. И привязки к ним любых гиперссылок (в том числе - с указанием target'а и альтернативного текста).

Надо сказать, что сам по себе djvu-файл связывается с html-файлом только посредством тэга 'a href="имя_файла.djvu"', можно - с укзанием target'а. В этом случае (при наличие plug-in'а, о чем - ниже) он открывается в окне браузера (том же или, соответственно, новом). Ни через 'scr img', ни через 'object' вставить в html-документ его нельзя. И, в следствие этого, ему нельзя придать ни титула, ни заголовка, ни какой-либо подрисуночной подписи: обо всем этом надо озаботится при создании исходного рисунка.

Так вот, процедуры эти осуществляются программой djedit из второго пакета (в который входит также djview - автономная гляделка djvu-файлов). При запуске его (в графическом режиме) для начала появляется предложение выбрать файл. Что можно сделать, нажав кнопку browse. Или - введя на память с полным путем.

После этого появляется собственно рабочее окно с изображением. На котором можно выбрать будущую активную область (в виде прямоугольника, овала или полигона). А в возникшем после этого окошке ввести URL (к сожалению, здесь-то никакого броузинга нет - или на память, или - из буфера), альтернативный текст и, при необходимости - target. Все, image map - готова. Впрочем, активную область можно отредактировать в любой момент - как в смысле размера, так и гиперссылки (правда, превратить прямоугольник в овал или полигон - нельзя). И автивных областей этих - можно наплодить, сколько поместится; разумеется, при перекрытии активными окажутся введенные последними.

Я проделал все эти манипуляции со своим тестовым рисунком (рис. 2). В результате теперь, ткнув мышь примерно в середину Камчатки (при попадании на активную область курсор из лапы превращается в стрелку), можно перейти к рисунку 3 - более крупномасштабной djvu-схеме того же района. Разумеется, в качестве целевого в гиперссылке можно указать и просто html-файл (скажем, текстовое описание геологической структуры).

Однако прежде чем воспользоваться плодами просвещения, требуется установить plug-in. В Виндовых браузерах процедура эта очень проста (по крайней мере, у меня не было проблем на четырех или пяти машинах): запускается самораспаковывающийся архив, находятся имеющиеся браузеры (MS IE и NN 4-х версий, с более ранними - не проверял) - и все, смотри и радуйся.

Под Линуксом я провел описанную выше процедуру установки (в режиме private), перезагрузил браузер (Netscape Navigator 4.6), как указано в инструкции - и получил вместо своей замечательной картинки plain text. Следуя виндовой практике, перезагрузил машину - с тем же результатом. Повторил установку в режиме public - опять закорючки вместо картинки.

Заглянул в настройки браузера, туда, где говорится о MIME-типах. Там в Description было указано такое: image/djvu и image/x-djvu, которым в Handled by соответствовало nsdjavu.so. В точности так, как должно быть в соответствие с мануальником.

Проверил, а есть по соответствующему адресу (также приведенному в man'е) эта самая nsdjavu.so. Был на положенном месте. Попытался подключить подключить вместо plug-in'а автономный djview в качестве приложения - безрезультатно. Пока опять не щелкнул на галочке включения plug-in'а. Тут-то и вылезло маленькое окошко с радостным сообщением, что описание MIME неправильно, а правильное - DjVu File. И было предложено с этим согласиться. другой бы спорил, а я так и драться не полез, нажав OK. И все чудненько стало на свои места. В том числе - djvu-картинки на место plain text'а.

На чем djvu-приключения мои и завершились благополучно.

Впрочем, благополучность я смогу проверить только после размещения этой заметки. Дело в том, что формат этот, естественно, требует серверной поддержки. Как ее включить - описано на том же сайте AT&T. А поскольку он до сих пор распространен мало, далеко не все сервера его поддерживают.

Так, на бесплатный американских серверах, где я до некоторого времени обретался, поддержка djvu имела быть на считанных. На Куличках - месте моего нынешнего Укрывища, - она имеется. И тестовые картинки с сервера смотрятся прекрасно. Мои же - через раз, причем - независимо, с какой машины. В чем тут дело - пока не разобрался. Но надеюсь.

Так что, если мои djvu-картинки Вы увидеть не сможете (даже после установки plug-in'а), не сочтите за труд написать мне. Я собираюсь довести это дело до победного конца, не жалея усилий.

Почему? Поскольку есть вероятность, что картинок видно не будет, отвечу на словах. Формат DjVu (помимо качества) имеет уникальную особенность, а именно - масштабирование. Что для представления геологической графики - вещь наипервейщая. Причем масштабирование - любое, от 25% до 300%, по ширине окна, по размеру страницы, а также произвольное. Выбиратеся масштаб либо из всплывающего по щелчку правой клавиши меню, либо из выдвижной панели в нижней части окна браузера.

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

А в нижней панели имеется (неактивизированная) возможность выбора страницы. То есть, предполагается, что DjVu-картинка может быть многостраничной. Как этого добиться - я не понял ни в Виндовом, ни в Линуксовом варианте. Может быть, эта опция присутствует в расчете на будущее?

Пора, однако, перейти к

Подведению итогов

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

Таблица

Файл TIFF GIF JPEG DjVu
nwpacific.* 973 126 98 122
kamchatka.* 728 42 65 87

Примечания: размер файлов - в килобайтах; GIF - 216-цветная палитра; JPEG - 50% сжатие; DjVu - фоторежим.

Из нее (и из приводимых рисунков) можно видеть, что DjVu вполне сопоставим с GIF'ом в отношении качаства и размера картинки, обладая при этом масштабируемостью. И заслуживает применения для ряда специальных целей.

Конечно, для целей картографии еще более подходящий формат - чисто векторный, допускающий наличие растровой подложки. Каковым является Macromedia Shockwave. Однако, помимо неоспоримых достоинст, он имеет и существенные недостатки. А именно - его воспроизведение на клиентсокй машине очень зависит от качества и (или) настроек монитора, типа (не обязательно качества) видеокарты, корректности установки plug-in'а. не говоря уже о том же факторе серверной поддержки: хотя в целом Shockwave поддерживается большим количеством серверов, чем DjVu, эта поддержка не всегда осуществляется корректно. И с точки зрения размера файла выигрыша он практически не имеет: если вся векторная часть рисунка обычно пренебрежимо мала, то растровая - представляет собой обычный JPEG-файл. Со всеми присущими последнему достоинтствами и недостатками.

Алексей Федорчук
Щербинка, 29 августа 1999 года


Stolica.ru
Реклама в Интернет
©Алексей Федорчук