Напоследок несколько замечаний относительно разницы в терминоло­гии, путаницы при сравнении рейтингов алгоритмов и т. п.

Посмотрите на краткий перечень форматов, достаточно часто исполь­зуемых на PC, Apple и UNIX платформах: ADEX, Alpha Microsystems BMP, Autologic, AVHRR, Binary Information File (BIF), Calcomp CCRF, CALS, Core IDC, Cubicomp PictureMaker, Dr. Halo CUT, Encapsulated PostScript, ER Mapper Raster, Erdas LAN/GIS, First Publisher ART, GEM VDI Image File, GIF, GOES, Hitachi Raster Format, PCL, RTL, HP-48sx Graphic Object (GROB), HSI JPEG, HSI Raw, IFF/ILBM, Img Software Set, Jovian VI, JPEG/JFIF, Lumeiia CEL, Macintosh PICT/PICT2, MacPaint, MTV Ray Tracer Format, OS/2 Bitmap, PCPAINT/Pictor Page Format, PCX, PDS, Portable BitMap (PBM), QDV, QRT Raw, RIX, Scodl, Silicon Graphics Image, SPOT Image, Stork, Sun Icon, Sun Raster, Targa, TIFF, Utah Raster Toolkit Format, VITec, Vivid Format, Windows Bitmap, WordPerfect Graphic File, XBM, XPM, XWD.

В оглавлении вы можете видеть список алгоритмов компрессии. Един­ственным совпадением оказывается JPEG, а это, согласитесь, не повод, что­бы повсеместно использовать слова формат и алгоритм компрессии как синонимы (что, увы, можно часто наблюдать).

Между этими двумя множествами нет взаимно-однозначного соответст­вия. Так, различные модификации алгоритма RLE реализованы в огром­ном количестве форматов. В том числе в TIFF, BMP, PCX. И если в опре­деленном формате какой-либо файл занимает много места, это не озна­чает, что плох соответствующий алгоритм компрессии. Это означает зачастую лишь то, что реализация алгоритма, использованная в этом фор­мате, дает для данного изображения плохие результаты. Не более того. (См. примеры в приложении 2.)

В то же время многие современные форматы поддерживают запись с использованием нескольких алгоритмов архивации либо без использования архивации. Например, формат TIFF 6.0 может сохранять изображения с использованием алгоритмов RLE-PackBits, RLE-CCITT, LZW, Хаффмана с фиксированной таблицей, JPEG, а может сохранять изображение без архи­вации. Аналогично форматы BMP и TGA позволяют сохранять файлы как с использованием алгоритма компрессии RLE (разных модификаций!), так и без использования оного.

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

Можно пополнить перечень ситуаций некорректного сравнения алго­ритмов. При сохранении абсолютно черного изображения в формате 1000x1000x256 цветов в формате BMP без компрессии мы получаем, как и положено, файл размером чуть более 1 000 000 байт, а при сохранении с компрессией RLE, можно получить файл размером 64 байта. Это был бы превосходный результат- сжатие в 15 тыс. раз(!), если бы к нему имела от­ношение компрессия. Дело в том, что данный файл в 64 байта состоит толь­ко из заголовка изображения, в котором указаны все его данные. Несмотря на то что такая короткая запись изображения стала возможна именно благо­даря особенности реализации RLE в BMP, еще раз подчеркнем, что в дан­ном случае алгоритм компрессии даже не применялся. И то, что для абсо­лютно черного изображения 4000x4000x256 мы получаем коэффициент сжатия 250 тыс. раз, совсем не повод для продолжительных эмоций по по­воду эффективности RLE. Кстати, данный результат возможен лишь при определенном положении цветов в палитре и далеко не на всех программах, которые умеют записывать BMP с архивацией RLE (однако все стандартные средства, в том числе средства системы Windows, читают такой сжатый файл нормально).

Всегда полезно помнить, что на размер файла оказывают существенное влияние большое количество параметров (вариант реализации алгоритма, параметры алгоритма - как внутренние, так и задаваемые пользователем, -порядок цветов в палитре и многое другое). Например, для абсолютно чер­ного изображения 1000x1000x256 градаций серого в формате JPEG с помо­щью одной программы при различных параметрах всегда получался файл примерно в 7 Кб. В то же время, меняя опции в другой программе, я полу­чил файлы размером от 4 до 68 Кб (всего-то на порядок разницы). При этом декомпрессированное изображение для всех файлов было одинаковым - аб­солютно черный квадрат (яркость 0 для всех точек изображения).

Дело в том, что даже для простых форматов одно и то же изображение в одном и том же формате с использованием одного и того же алгорит­ма архивации можно записать в файл несколькими корректными спосо­бами. Для сложных форматов и алгоритмов архивации возникают ситуации, когда многие программы сохраняют изображения разными способами. Та­кая ситуация, например, сложилась с форматом TIFF (в силу его большой гибкости). Долгое время по-разному сохраняли изображения в формат JPEG, поскольку соответствующая группа ISO (Международной организа­ции по стандартизации) подготовила только стандарт алгоритма, но не стандарт формата. Сделано так было для того, чтобы не вызывать "войны форматов". Абсолютно противоположное положение сейчас с фрактальной компрессией, поскольку есть стандарт де-факто на сохранение фрактальных коэффициентов в файл (стандарт формата), но алгоритм их нахождения (быстрого нахождения!) является технологической тайной создателей про­грамм-компрессоров. В результате для вполне стандартной программы-декомпрессора могут быть подготовлены файлы с коэффициентами, суще­ственно различающиеся как по размеру, так и по качеству получающегося изображения.

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

Вывод 2. Если вы не умеете пользоваться программами архивации или пользуетесь программами, в которых "для простоты использования" убрано управление параметрами алгоритма, не удивляйтесь, что для отличного ал­горитма компрессии в результате получаются большие файлы.