§ 42. Организация данных

Введем понятие обобщенного файла изображения. Разработка программного обеспечения сильно упрощается, если, где это возможно, файлы дисковых данных и устройства, на которых записываются и с которых считываются изображения, рассматриваются как «эквивалентные дисковые файлы изображений» в одном стандартном формате. Например, файлы, содержащие одномерные и двумерные гистограммы, графы, просмотровые таблицы и изображения, — все это можно рассматривать как изображения. Такие устройства, как НМЛ, память для обновления информации на экране интерактивного дисплея и устройство цветной фоторегистрации, могут рассматриваться как эквивалентные дисковые файлы изображений. Ибо программы ввода-вывода таких устройств автоматически отыскивают требуемую

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

Новые устройства можно добавлять к существующей системе, просто изменяя соответствующие системнозависимые подпрограммы, управляющие вводом-выводом. В отличие от реальных дисковых файлов эти устройства требуют определения дополнительных параметров. Мы используем систему сокращений, включающую все такие параметры в качестве части заголовка файла. Например, означает реверсировать пропустить два файла и затем считать частичное изображение 128 строк на 128 элементов с первой строкой номер и первым элементом номер Более понятен, может быть, пример который означает: считать следующий файл изображения с и затем перемотать ленту. Для всех параметров используется разумное задание параметров по умолчанию, а из заголовка изображения (о чем см. ниже) извлекается максимум информации.

Разберем теперь формат кодов элементов изображения. В настоящее время мы допускаем 1-, 8- и -битовые целые форматы кодов элементов, -битовый вещественный формат и -битовый комплексный формат. Нетрудно добавить сюда и другие форматы, но, как правило, любая конкретная программа по обработке изображений рассчитана только на два разных формата. Когда 8 битов не обеспечивают необходимой точности, мы используем -битовый формат (например, в случае изображения, каждый элемент которого есть высота поверхности в метрах). Вещественный и комплексный форматы обычно используются при применении БПФ. Отмстим, что -битовый формат чисел обычно отвечает диапазону Тем не менее некоторые компьютеры (например, фирмы осуществяют декодирование отдельных байтов в диапазоне от - 128 до 127. Поэтому желательно избегать -битовой арифметики и пользоваться цифровой арифметикой при точности 16 или 32 бит. Мы обычно используем -битовый формат при выполнении арифметических операций над -битовыми изображениями. При этом 16 бит декодируются в диапазон от до 32 767, чего, как правило, достаточно при пересылке изображения с одного компьютера на другой. Вещественные (или комплексные) форматы машинно-зависимы, так как размер и

расположение мантиссы и порядка, и лаже основания (например, 2 или 10) целиком зависят от выбора производителей компьютеров.

Это подводит нас к вопросу заголовков. Каждый файл изображения должен иметь соответствующий заголовок, содержащий информацию об изображении. По мере развития хорошей системы обработки изображений ее эффективность начинает ограничиваться структурой заголовка. Информация, содержащаяся в нем, делает ненужным постоянное запоминание и ввод информации об изображении и таким образом упрощает действие системы и уменьшает вероятность появления ошибок ввода. В некоторых системах заголовок хранится не вместе с изображением, а в отдельном файле. Но мы считаем это излишним усложнением и храним заголовки в виде встроенной части файла изображения, поскольку на магнитную ленту заголовок все-таки записывается вместе с изображением. Заголовок должен находиться в начале файла для того, чтобы при считывании с ленты можно было определить размер изображения, прежде чем считывать само изображение. Повсеместно принятого стандарта для заголовков не существует. Принятие такого стандарта привело бы к новым трудностям, так как все время создаются новые программы, а они требуют, чтобы заголовок нес специализированную информацию. Это означает, что заголовок должен каким-то образом расширяться. Мы приняли формат заголовка, состоящий из одной или более записей из 1024 символов ASCII (Американского стандартного кола для обмена информацией). Первая запись несет информацию о размере заголовка и размере изображения. Заголовок записан в коде ASCII, чтобы проще было его редактировать и просматривать, а также чтобы избежать трудностей при конвертировании двоичных данных (например, вещественных чисел) между компьютерами. Длина одной записи достаточно велика, так что лишь редко приходится прибегать к увеличению числа записей. Таким образом, существует возможность при необходимости редактировать заголовок или изображение, или и то и другое вместе непосредственно на диске. Если требуется внести в заголовок новые данные, то можно добавить новые позиции внутри существующих записей или даже новые записи. Мы включаем в заголовок всю историю обработки данного изображения с момента создания заголовка. По требованию эта история выводится на экран и значительно помогает при осуществлении сложной последовательности операций над изображением.

Рассмотрим содержание заголовка более детально. В нем должно содержаться несколько типов данных. Во-первых, информация о числе строк и элементов в изображении, число битов на один элемент, тип изображения (например, «Ландсэт» МСС), его спектральный диапазон

(например, 700 - 800 нм) и всемирное время, в которое изображение было получено и сформировано. Во-вторых, должна содержаться специальная информация об источнике данных. В случае данных, полученных с ИСЗ, эта информация будет включать положение ИСЗ, скорость, угол просмотра, а также высоту и азимутальные углы Солнца. В-третьих — информация о геометрии изображения, включающая в себя долготу и широту угловых точек изображения и центра, а также сведения о том. корректировалось ли изображение (методами, изложенными в гл. 8).

Если изображение геометрически скорректировано, то указывается вид картографической проекции, а также координаты верхнего левого и нижнего правого углов этой проекции и шаг дискретизации. В-четвертых, сведения о калибровке, которые включают в себя информацию о том, производилась ли калибровка изображения, единицы калибровки, а также соответствующий данным диапазон калибровки. Заметим, что изображение или псевдоизображение (например, гистограмма) может быть откалибровано как по его горизонтальным и вертикальным размерам, так и по интенсивности. Кроме того, последовательность изображений, составляющая кинофильм, может быть откалибрована и по времени. Необходима также информация о том, было ли изображение подвергнуто преобразованию Фурье и, если было, какова размерность преобразования. Дело в том, что двумерное изображение приобретает комплексные значения после одномерного или двумерного БПФ. Эти случаи необходимо различать. Остальная информация, которая должна содержаться в заголовке, зависит от области применения системы. Заметим, что для того, чтобы обеспечить хранение в заголовке указанной выше информации, необходимы определенные усложнения программы. Но они с лихвой компенсируются такими преимуществами, как возможность автоматически комбинировать или объединять откалиброванные и откорректированные наборы данных.

Следующий важный вопрос — структура дискового файла изображения. Доступные структуры дисковых файлов зависят от типа используемой операционной системы. Файловая структура должна допускать произвольный доступ к строке изображения, так как это необходимо для многих алгоритмов. Тем самым исключается использование файлов последовательного доступа. Большинство операционных систем (если не все) допускают использование файлов произвольного доступа с фиксированной длиной записи. Размер полного файла должен объявляться перед созданием файла. Некоторые операционные системы, такие, как UNIX, допускают использование файлов произвольного доступа с переменной длиной записи. В этой операционной системе

возможен произвольный доступ к любому байту в файле. Такая возможность очень желательна, но наличие ее может сказаться на переносимости программного обеспечения, так как указанная возможность не реализована в большинстве операционных систем. Мы уже упоминали, что желательно иметь фиксированную длину записи заголовка (например, 1024 байта). Эта длина может быть больше или меньше длины строки изображения, и, таким образом, возникает необходимость работы с записями переменной длины. Этот вопрос связан с поднятой выше проблемой переносимости. Мы разрешили его, записывая заголовок в блок в начале файла изображения. Размер равен наименьшему кратному длины строки изображения, необходимой для хранения полного заголовка. Это позволяет использовать для хранения наших изображений файлы произвольного доступа с фиксированной длиной записи. Длина равна числу байтов в строке изображения, округленному до ближайшего числа, кратного четырем (чтобы было целое число 32-битных слов). При первом считывании заголовка из файла изображения длина записи может быть определена соответствующим системным запросом.

Иногда важно знать, как физически изображения хранятся на диске. Например, при использовании системы организации веления записей VAX VMS каждая новая запись из файла произвольного доступа начинается на физической границе блока диска. Каждый такой блок имеет длину 512 байт. Это может быть очень неэкономным в отношении объема НМД. Кроме того, ввод и вывод буферированной системы, запрашиваемые на языке высокого уровня типа Фортран, могут быть весьма медленными. Поэтому для экономии объема и увеличения скорости иногда стоит заменить систему запросов ввода-вывода пакетом на Ассемблере, специалмю разработанным для файлов изображений. Именно такой подход мы приняли в своей системе, что значительно повысило скорость действия устройств ввода-вывода.

Некоторые алгоритмы, такие, как алгоритм геометрической коррекции больших изображений, требуют, чтобы файлы были побайтно адресуемы. Этого можно достичь двумя способами. Первый заключается в использовании подпрограммы на Фортране, которая считывает и записывает целиком строки изображения и извлекает или вносит требуемые байты. Эффективнее, однако, использовать систему ввода-вывода, подобную той, которая содержится в операционной системе UNIX, или специально написанный пакет на Ассемблере. Заметим, что использование системы ввода-вывода специального назначения не влияет на переносимость программ, так как эти системы остаются неизмененными по отношению к программам и подпрограммам высокого уровня.

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

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

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