4.4. Формат tiff

Растровий формат TIFF (Tagged Image File Format) був створений для подолання труднощів, що виникають при переносі графічних файлів з IBM-сумісних ПЭВМ на ПЭВМ Macintosh і назад.

Специфікація TIFF була розроблена Aldus Corporation у 1986 р. і представила даний формат як стандартний метод збереження чорно-білих зображень, створених сканерами і програмними пакетами верстки. Широкого поширення набула розроблена в квітні 1987 р. модифікація формату 4.0, що змогла підтримувати обробку нестиснених кольорових RGB-зображень. TIFF модифікації 5.0 ( що з'явився у серпні 1988 р.) давав змогу зберігати кольорові зображення з палітрою і підтримувати алгоритм стиснення LZW.

Розроблений у червні 1992 р. TIFF 6.0 розширив свої функціональні можливості підтримкою кольорових зображень моделей СМYK і YCbCr, а також використанням методу стиснення JPEG.

TIFF сьогодні - це стандартний файловий формат, що підтримується більшістю графічних програм створення й обробки зображень, а також програмними пакетами верстки. Здатність до розширення, що дає змогу записувати растрові зображення з будь-якою глибиною кольору, робить цей формат досить перспективним для збереження й обробки графічної інформації.

TIFF став загальним форматом для систем введення зображень зі сканерів, використовується у видавничих системах і входить до складу дистрибутивних додатків Windows.

Організація файлу.

Файли TIFF складаються з трьох розділів: заголовка файлу зображення (Image File Header - IFH), директорії файлу зображень (Image File Directory - IFD) і растрових даних (Тег). З них необхідними є тільки IFH і IFD.

Отже, допускається можливість існування файлу TIFF, що не містить растрових даних. Файл TIFF, що містить декілька зображень, буде включати стільки ж директорій файлу і розділів растрових даних (по одному для кожного зображення). Структура формату представлена на рис. 4.9.

У структуру TIFF-файлу входять:

1.Заголовок, що включає: ідентифікатор порядку байтів у файлі (від старших до молодших або навпаки); номер версії; покажчик на першу директорію IFD.

2.Директорія (IFD) - містить опис одного зображення: лічильник тегів в директорії; послідовність тегів; покажчик на наступну директорію IFD.

3.Тег: ідентифікатор поля; тип поля (базове, інформаційне, факсимільне та поле запам'ятовування й відновлення документів); довжина поля; зміщення у файлі до даних.

Початковий заголовок містить 8 байт. Вся інформація і параметри, що мають відношення до зображення, зберігаються в полях ознак. Сучасні версії TIFF включають 45 таких полів. Однак фактично є два окремих поля ознак для точного визначення розмірів зображення, а також поля для визначення ПЭВМ, програмного забезпечення, дати створення файлу і т.д. Кілька полів містять значення за замовчуванням і, отже, не вимагають уточнення. TIFF наділений полями, що дають змогу правильно відтворювати зображення з нестандартною роздільною здатністю. TIFF є складним форматом, оскільки місце розташування кожної директорії та її даних (включаючи растрові дані) може змінюватися. Єдиною складовою частиною файлу TIFF, що має постійне місце, є заголовок - він завжди розташовується в перших восьми байтах кожного файлу TIFF. Всі інші дані файлу створюються з використанням інформації IFD. Директорія файлу зображення і зв'язаний з нею растр складають субфайл TIFF. Обмежень на кількість субфайлов у файлі TIFF не існує.

Кожна директорія файлу містить одну або кілька структур даних, що мають назву тегів. Кожен тег є 12-байтним записом, що містить визначену інформацію про растрові дані. Тег може зберігати дані будь-якого типу, і специфікація TIFF визначає понад 70 тегів, що використовуються для представлення заданої інформації. Теги кожної директорії поєднуються в неперервні групи.

Теги, визначені специфікацією TIFF, називаються загальнодоступними і не можуть змінюватися більше, ніж це передбачено специфікацією. Теги, визначені користувачем, називаються приватними і призначені для застосування в користувальницьких програмах через Developer's Desk фірми Aldus.

У специфікації TIFF 6.0 термін «тег» замінений терміном «поле». Тепер на весь 12-байтний запис даних вказує термін «поле», а термін «тег» перевизначений для вказівки тільки на число, що ідентифікує це поле.

Файл TIFF може містити будь-яку кількість зображень (включаючи нульову). Кожне зображення розглядається як окремий растровий субфайл, дані якого описуються інформацією IFD. Кожен субфайл TIFF може бути записаний у вигляді окремого файлу або разом з іншими субфайлами об’єднаний в один файл TIFF. Кожен растровий субфайл має свою директорію файлу зображення і може розташовуватися в будь-якому місці (після заголовка). Кожному зображенню може відповідати тільки одна директорія.

Розмір директорії файлу може змінюватися, оскільки вона, як правило, містить змінну кількість записів даних, тегів. Кожен тег, подібно до поля заголовка, зберігає унікальну інформацію. Проте між тегами існують певні відмінності. Вони можуть додаватися в директорію і видалятися з неї. Поля ж звичайного заголовку є постійними і непереміщуваними, тобто кількість тегів у IFD може змінюватися, а кількість полів звичайного заголовка є постійною.

Дані зображення. Файли TIFF зберігають тільки растрові дані, хоча, на думку фахівців, до складу файлу можна додати декілька тегів, що підтримують векторні зображення. Растрові дані у файлі TIFF не завжди розташовані відразу після заголовку, як у більшості інших форматів. Навпаки, вони можуть знаходитися майже в довільному місці файлу TIFF.

Зображення, записані у форматі TIFF 6.0, можуть бути організовані у вигляді смуг або у вигляді фрагментів.

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

Такий підхід, який також називається поділом на блоки або порції, існує і в деяких інших файлових форматах. Проте поділ на смуги у форматі TIFF має декілька істотних відмінностей від інших схожих концепцій.

Фрагменти. Смуги є не єдиним можливим способом організації растрових даних. У TIFF 6.0 представлена концепція поділу растрових даних на фрагменти. Смуга - це одномірний об'єкт, що має тільки довжину, а фрагмент можна розглядати як двомірні блоки (смуги), що мають довжину і ширину (подібно до растру). Фактично кожен фрагмент зображення можна розглядати як сегмент растру. Таким чином, зображення представляється у вигляді сукупності сегментів, що у специфікаціях TIFF носять назву фрагментів, з врахуванням їх місцезнаходження в оригіналі зображення.

Поділ зображення на прямокутні фрагменти має величезні переваги (особливо у випадку дуже великих зображень з високою роздільною здатністю) в порівнянні з поділом на горизонтальні смуги.

Як відомо, деякі програми EDIP не можуть маніпулювати зображеннями розміром більше Е (6848 пікселів в ширину на 8800 пікселів в довжину), оскільки для буферизації, розпакування та маніпулювання навіть декількома сотнями рядків даних зображення потрібно надто великий обсяг пам'яті комп'ютера. Якщо необхідно відобразити тільки верхній лівий кут зображення, прийдеться розпаковувати всю смугу растру, розмістивши її в пам'яті. Якщо ж дані цього зображення будуть розділені на фрагменти, то треба буде розпакувати тільки той фрагмент, що містить дані для зазначеної частини зображення.

Багато алгоритмів стиснення, і зокрема JPEG, використовують двомірні фрагменти-блоки, а не одномірні смуги. Збереження стиснених даних у вигляді фрагментів сприяє прискоренню дешифрування даних. Концепції поділу даних зображення на фрагменти (сегменти) включені в специфікацію TIFF 6.0.

Під раціональними розуміються такі розміри фрагмента, при яких розмір зображення буде перекриватися мінімально. При зазначеному вище розмірі зображення можна застосувати розбивку на фрагменти шириною 256 і довжиною 320 пікселів, тобто зберегти майже те саме співвідношення ширини і висоти, що й у вихідного зображення. Розбивка на фрагменти таких розмірів потребує використання по 104 додаткових пікселі набивки в кожному рядку і 30 додаткових рядків. Розмір даних зображення з врахуванням набивки тепер складе 2304 пікселі в ширину і 2880 пікселі в довжину, що дозволить точно розділити це зображення на 81 фрагмент розміром 256х320 пікселів.

Кольори зображення. Специфікація TIFF пропонує концепцію основних типів зображень: дворівневе, напівтонове, кольорове з палітрою і повноколірне. Для кожного основного типу зображень встановлений обов'язковий мінімальний обсяг тегів.

У специфікації TIFF 5.0 перераховані основні типи зображень були названі класами. Кожен файл TIFF будується з загального класу (Class X) і може модифікуватися додатковим класом, що залежить від типу збереженого зображення: Class У (дворівневе), Class G (напівтонове), Class P (палітрове) і Class R (повноколірне RGB).

У специфікації TIFF 6.0 ці класи перевизначені в чотири окремі конфігурації базових файлів. Клас Х об'єднаний з кожним з інших чотирьох класів для формування конфігурацій дворівневих, напівтонових, кольорових з палітрою і повноколірних файлів. І хоча специфікація TIFF 6.0 практично не передбачає використання класів, вважається досить ймовірним, що ще тривалий час TIFF-файли будуть визначатися згідно з цими позначеннями класів, оскільки файлів у форматі TIFF 5.0 існує значно більше, ніж будь-яких інших.

Фактично існує ще один клас TIFF - Class F, призначений для збереження факсимільних зображень у даному форматі. Цей клас файлів (також відомий під назвою Everex Fax File Format) був створений фірмою Cygnet Technologies. І незважаючи на те, що дана фірма перестала існувати, формат TIFF Class F продовжує застосовуватися.

TIFF підтримує два способи збереження колірних даних. TIFF-P подібний до GIF і використовує колірну палітру (карту) для зображення. Самі дані про зображення зберігаються як коди відповідно до колірної карти. Цей метод забезпечує ефективність збереження, але обмежує палітру 256 кольорами. Колірна карта створює свої елементи з 48-бітової палітри (основна структурна одиниця TIFF - 2-байтове слово, отже, по 16 кольорів надано кожній з колірних площин аддитивної колірної моделі RGB: червоній, зеленій і синій). TIFF-R використовується для визначення повних RGB-зображень. Елемент растру представляється трьома 8-бітними RGB-значеннями, що забезпечує більше 16 млн. кольорів.

Ці класи дозволяють прикладним програмам використовувати тільки ті можливості, що дійсно необхідні. Кожен клас містить той необхідний мінімум полів, що повинні підтримуватися для забезпечення сумісності, і позбавляє необхідності створювати непотрібні поля.

Стиснення. TIFF вважається добре стискаючим форматом. Він підтримує кілька схем стиснення, спеціальні функції керування зображенням і багато інших можливостей. Ще однією особливістю TIFF є специфікація роздільної здатності устаткування, наприклад IBM PC, Macintosh і т.д.

Розділ 5. Представлення анімаційної, відео- та звукової інформації

При роботі з цифровим відеосигналом виникає необхідність обробки, передачі й збереження дуже великих обсягів інформації. На сучасних носіях, таких, як компакт-диск (CD-ROM, 650 Мбайт) чи жорсткий диск (порядку тисячі мегабайт), зберегти повноцінний за часом відеоролик, записаний у поелементному форматі, не вдається. З іншого боку, відеоінформація повинна передаватися зі швидкістю її відтворення на екрані комп'ютера. Так, повноколірне (24 біт/ піксель) зображення розміром 720Х576 пікселів із розрахунку 25 кадр/с вимагає швидкості передачі відеоданих 240 Мбіт/с. Однак пропускна здатність каналів ЛВС FDDI - порядку 100-200 Мбіт/с, а Ethernet - лише 10 Мбіт/с.

Тому використання відеоданих у складі електронних видань виявилось неможливим. Розвиток технологій переведення відеоінформації у цифровий формат і їхнє подальше застосування в цифровому ТБ поставили проблему стиснення відеоданих у ряд найбільш важливих. Її позитивне рішення виявилося можливим лише на базі розробки ефективних методів і алгоритмів стиснення відеоданих.

Слід зазначити, що традиційні алгоритми стиснення даних без втрат тут практично незастосовні, оскільки дають незначний виграш для реальної відеоінформації. Наприклад, алгоритми, засновані на компресії за рахунок кодування довжинами серій і адресно-позиційного кодування (RLE, LZ, LZW і т.п.), не дають належного ефекту.

Для покадрового стиснення відеоданих можна використовувати алгоритми компресії статичної графіки - стиснення з втратами (JPEG). При цьому відновлене зображення кадру, як правило, не збігається з оригіналом. Однак реалізація таких алгоритмів досить складна і процеси декодування вимагають значних витрат часу.

Відеоінформація накладає специфічні обмеження на швидкість декодування даних: декодер (апаратно-програмний засіб, що здійснює декомпресію даних) повинен встигати розархівувати зображення за 1/25 с, поки на екрані відображається попередній кадр. Дане обмеження не дає можливості реалізувати алгоритми з більшим ступенем стиснення.

Ще одне обмеження - складність апаратної реалізації декодувальних пристроїв. У реальних додатках (цифрові відеокамери, відеотелефони, відеофони і т.д.) оптимальним рішенням проблеми є реалізація алгоритму на замовленому наборі мікросхем з обмеженим числом транзисторів у чіпі. Тому реалізація подібних швидкодіючих декодувальних апаратно-програмних пристроїв не завжди можлива.

Реальним розв’язанням проблеми стало стиснення усього відеоряду, що включає послідовність відеокадрів.

Стандартним методом цифрового кодування на комп'ютері є PCM (Pulse Code Modulation). Найбільш популярним форматом, який використовується для збереження нестиснених аудіоданих, є Microsoft PCM (WAV). Для відеороликів стандартним для комп'ютера вважається Microsoft Audio/Video Interleaved (AVI). Стиснення аудіо- чи відеоданих як процес має на увазі конвертацію відповідно нестисненого WAV- чи AVI- файлу в інший формат із використанням алгоритму стиснення (тому програми для компресії/декомпресії даних називають конверторами). При цьому може бути використаний будь-який формат (навіть WAV і AVI), якщо він підтримує цей алгоритм.

Важливу роль при розв'язанні проблеми стиснення відеоданих відіграли результати, отримані групою комітету зі стандартизації MPEG (Motion Pictures Experts Group). Ця група запропонувала технологію компактного представлення цифрових відео- і аудіосигналів. Основна ідея полягала в перетворенні потоку дискретних цифрових даних у потік деяких записів, що вимагали меншого обсягу пам'яті. Це перетворення базується на використанні статичної надмірності й особливостей людського сприйняття. Закодовані незалежно аудіо- і відеопотоки надалі зв'язуються системним потоком, що здійснює синхронізацію й об'єднання багатьох потоків різних даних в одну кодову послідовність.

Розроблений цією групою метод стиснення і відповідні формати сімейства MPEG успадкували багато чого у своїй структурі від JPEG. Однак на противагу графічним форматам MPEG використовував кодування відмінностей наступних кадрів від деяких базових зображень кадрів. У 1990 р. був створений формат MPEG-1, що орієнтувався на стиснення відео- і аудіоінформації.

Після розробки першого стандарту на стиснення відео- і аудіоінформації ця ж група створила формат і відповідну технологію, орієнтовану на застосування до потоків і відеоданих з більш високою роздільною здатністю. Ефективне представлення черезрядкової розгортки відеосигналу виявилося більш складною задачею, ніж прямі (не черезрядкові) сигнали, визначені MPEG-1. MPEG-2 ввів схему декореляції багатоканального дискретного аудіосигналу об'ємного звуку, використовуючи більш високий фактор надмірності.

Надалі були створені формати MPEG-3, MPEG-4, MPEG-7, MPEG-J.

Сьогодні MPEG - єдиний формат представлення даних специфікації United States Grand Alliance HDTV, групи European Digital Video Broadcasting і Digital Versital Disc (DVD).

У літературі MPEG може поділятися на фази (MPEG-1, MPEG -2, MPEG-4 і т.д.), а в області аудіоінформації - ще і на рівні (layers). Фази позначаються арабськими цифрами, рівні - римськими. Деякі фази MPEG так і не були закінчені. Наприклад, розробка MPEG-3, призначеного для телебачення високої чіткості (HDTV) із розмірами кадрів 1920Х1080 при частоті зміни 30 кадр/с і можливістю стиснення до 20-40 Мбіт/с, не була довершена, оскільки виявилося, що ця область підтримується форматом MPEG-2. Немає інформації про розробку MPEG-6, що призначався для безпровідної передачі даних; MPEG-8, ціль якого - чотиривимірний опис об'єктів.

Експертна група по мультимедіа і гіпермедіа MHEG (Multimedia Hypermedia Expert Group) визначила стандарт для обміну мультимедійними об'єктами (відео, звук, текст і інші довільні дані) між додатками, і передачі їх різними способами (локальна мережа, мережі телекомунікацій і віщання) із використанням MHEG object classes. Цей стандарт дав змогу програмним об'єктам містити в собі будь-яку систему кодування (наприклад, MPEG), що визначена в базовому додатку. MHEG був прийнятий радою по цифровому відео і звуку (DAVIC - Digital Audio-Visual Council).

MHEG-об'єкти створюються мультимедійними додатками.

Вважається, що MHEG - майбутній міжнародний стандарт для інтерактивного TV, тому що він працює на будь-яких платформах і його документація загальнодоступна.

Поряд із зазначеними стандартними форматами є певна множина форматів кодування відео- і аудіоінформації, запропонованих фірмами, що роблять різні програмні додатки. До них можна віднести: формат RealAudio, розроблений фірмою RealNetworks, для збереження стиснених голосових аудіоданих (мови); формат аудіоданих SoundVQ, розроблений компанією Yamaha; формат Windows Media Technology 4.0, представлений фірмою Microsoft, підтримує потокову передачу даних у Internet і має розвинену систему стиснення аудіо- і відеоданих; формат QuickTime фірми Apple був розроблений для використання в мультимедійних додатках на комп'ютерах Macintosh і т.п.