Чи не всі цифрові зображення в кінцевому рахунку є лише значеннями пікселів між 0-255?

У мене є кілька неймовірно базових (дурних?) Питань щодо образів; конкретно, формати зображення та значення пікселів.

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

Мої запитання:

Якщо в основі, фотографії - це лише 3 канали значень пікселів [0, 255] X RBG, то як могла бути різниця між будь-якими двома форматами зображень? Я маю на увазі, чим RAW відрізняється від TIFF - чи не всі вони обмежені значеннями від 0 до 255? Число - це число - чи не може бути лише один встановлений формат? Чи не повинні два жодні зображення з однаковою висотою та шириною фіксуватися таким самим розміром файлу?

Далі, з числової точки зору, що робить щось на зразок 16-бітових зображень, відмінних від 32-бітових зображень? Знову ж таки, зображення - це лише масив із цілими значеннями між 0 -255.

Продовжуючи цю точку зору, що зображення у файловій системі комп'ютера - це лише 3-канальний масив цілих чисел між 0 - 255, який сенс стискання зображення у формат втрат, як, наприклад, JPG? Скажімо, альго стиснення змінює деякі значення пікселів з 254 до 255 або будь-яке інше. Тому? Як це забезпечує економію розміру файлу чи впливає на якість візуалізації?

Я знаю, що існує багато різних способів зберігання даних про зображення. Але я не запитую про щось, окрім базового 3-канального RBC-зображення. Все, що я знаю, це те, що якщо хтось передасть мені одну з них, у мене зараз є масив чисел. У мене немає підстав знати, чому один масив чисел може бути іншим, ніж якийсь інший масив чисел від 0 до 255. Я сподіваюся, що це має сенс. Це питання не обмежується форматом RAW! Скоріше, мова йде про будь-який масив значень пікселів

Вибачте, але ваша основна передумова помилкова: зображення можна кодувати як масив пікселів RBG з 8 бітами на значення, але існує маса інших способів:

• один канал з одним бітом / каналом (чисто чорний і білий),
• один канал з x біт / канал (формати сірого масштабу, x зазвичай буде 8 або 16, даючи значення 256 або 65536),
• різні формати на основі палітри (cf.GIF)
• повнокольоровий з (принаймні теоретично) якомога більше каналів з будь-якою необхідною глибиною бітів.

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

Для фотозйомки найбільш поширеними є 3 канали з 8, 16 або 32 біт / канал (як правило, цілими, але принаймні деякі програми працюють внутрішньо з 32-бітовими числами з плаваючою комою). Часто є 4-й канал (альфа), особливо коли програма дозволяє використовувати шари. І десь розміри масиву зображень потрібно зберігати.

Існують різні причини цих різних форматів. Для формату в пам'яті важливим фактором є розмір даних та швидкість (набагато швидше керувати одним 8-бітовим каналом, ніж 4 32-бітні канали). Сьогодні вони менш важливі, але ми отримали повне управління кольорами з різними кольоровими просторами. Деякі з них (наприклад, профото RGB) потребують принаймні 16 біт / канал, щоб зберегти відмінності між сусідніми кольорами невеликими, щоб уникнути видимого смуги. Оскільки лікування стає складнішим, є переваги використання 32-бітних чисел з плаваючою точкою (де кольори кодуються значеннями від 0,0 до 1,0, а обробка дозволяє проміжні значення поза цим діапазоном).

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

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

Потім існують різні способи стиснення даних зображень для зберігання файлів. Один з найпростіших - RLE (Run Run Encoding), де ви зберігаєте кількість і значення пікселя кожного разу, коли ви стикаєтесь із значенням повторного пікселя. Інші, як jpeg, набагато складніші, але також дають набагато більше стиснення. Наприклад, jpeg використовує косинусну трансформацію і викидає (менш видиму) високочастотну інформацію, даючи високі показники стиснення за рахунок втрати інформації (її тут більше, але це стає занадто довго).

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

Тоді відбувається постійний розвиток, наприклад, методів стиснення без втрат, з якими існуючі формати не завжди можуть впоратися.

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

Якщо ви обробляєте зображення в пам'яті, воно буде у вигляді одного або декількох масивів. На той момент оригінальний формат файлу більше не повинен грати ролі . Я припускаю, що ви обробляєте свої дані за допомогою 8 біт / канал.

Але вам доведеться знати, чи є у вас оброблене зображення або неочищене зображення, оскільки між ними є дві важливі відмінності:

• необроблені зображення зазвичай мають 1 колір на піксель , а пікселі зазвичай розташовані в масиві Bayer з 2 зеленими, 1 червоними та 1 синіми пікселями на квадрат 4 пікселів. Значення пропорційні інтенсивності сцени (крім дуже низьких і дуже високих значень).
• оброблені зображення можуть бути розташовані як двовимірний масив записів, що містить 3 числові значення, або як кольорові площини (3 2D масиви, по одному для кожного з R, G, B). Крім того, значення зазвичай не пропорційні інтенсивності сцени . Гірше, що точне співвідношення між значеннями пікселів та інтенсивністю сцени залежить від обробки зображення. А баланс між кольорами налаштовано відповідно до відповіді людського ока (баланс білого, червоний і синій посилюються відносно зеленого).

Отже, якщо ви отримуєте неочищене зображення з 3 значеннями кольорів на піксель, це необроблене зображення вже мало обробляти (принаймні, або демозаспособлення , або просте binning з 4 необроблених пікселів на 1 піксель зображення). Чи прийнятно це, залежатиме від вашої заявки.

Якщо в основі, фотографії - це лише 3 канали значень пікселів [0, 255] X RBG,

Але фотографії не є "лише 3-ма каналами значень пікселів", навіть "в основі". Екрани комп'ютерів, як правило, складаються з масиву пікселів RGB, тому, якщо ви хочете відобразити зображення на екрані комп'ютера, вам в якийсь момент потрібно відобразити всі дані зображень у масив пікселів RGB, але ці дані є лише особливе відображення даних зображень. Дані на зображенні можуть взагалі не складатися з потоку значень пікселів. Для отримання значень пікселів із зображення, ви повинні знати, як формуються дані.

то як могла бути різниця між будь-якими двома форматами зображень? Я маю на увазі, чим RAW відрізняється від TIFF - чи не всі вони обмежені значеннями від 0 до 255?

Це два хороших приклади, оскільки жоден з цих форматів не обов'язково містить прямокутний масив значень RGB.

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

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

Число - це число - чи не може бути лише один встановлений формат?

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

Чи не повинні два жодні зображення з однаковою висотою та шириною фіксуватися таким самим розміром файлу?

Ні, це було б страшно. Якщо розмір кожного файлу зображень повинен бути по суті width * height * 3(припускаючи 24-бітний колір), ви втратите багато місця для зберігання. Більшість фотографій містять багато надмірності, тобто регіони, де один і той же колір повторюється багато разів. Для економії місця на зберіганні часто має сенс усунути цю зайву інформацію. Наприклад, одним із способів є, наприклад, кодування довжиниабо RLE. Наприклад, якщо у вас є область з 4195 пікселів, які є всіма білими, набагато ефективніше кодувати це як "наступні 4195 пікселів - всі {255, 255, 255}", а не просто зберігати стільки білих пікселів у файл. RLE фактично використовується в деяких форматах зображень, але багато форматів мають набагато складніші схеми, що економить набагато більше місця, а це означає, що ви можете зберігати багато більше зображень на жорсткому диску чи картці пам'яті. Це також набагато швидше надсилає зображення комусь іншому.

Продовжуючи цю точку зору, що зображення у файловій системі комп'ютера - це лише 3-канальний масив цілих чисел між 0 - 255, який сенс стискання зображення у формат втрат, як, наприклад, JPG?

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

Скажімо, альго стиснення змінює деякі значення пікселів з 254 до 255 або будь-яке інше. Тому? Як це забезпечує економію розміру файлу чи впливає на якість візуалізації?

Розглянемо мій приклад RLE вище. Скажімо, у вас є фотографія з великою порожньою стіною, тому великі ділянки вашої фотографії мають однаковий колір, за винятком того, що є розсіювання трохи темніших пікселів, ледь навіть помітних на зображенні. Ці пікселі знижують ефективність стиснення. Замість того, щоб можна було просто сказати, що "наступні 500 000 пікселів - це все {243, 251, 227}", вам потрібно виконати довжину, кодуючи ще багато набагато менших шматочків, тому що кожен так часто ви натрапляєте на один із цих трохи пікселів. Якщо ви дозволите алгоритму стиснення вносити невеликі зміни, можливо, лише змінюючи будь-який піксель не більше ніж на 1% або 2%, то ви можете отримати набагато вищий коефіцієнт стиснення, не помітно змінюючи зображення. Це компроміс: ти відмовившись від невеликої кількості інформації у вихідному зображенні взамін на велике зменшення розміру файлу. Точно там, де ви хочете провести цю лінію, може змінитися, тому втрачені формати, такі як JPEG, дозволяють користувачеві вибрати, який рівень стиснення він бажає.

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

Кодеки призначені для:

• Бути без втрат проти втрати
• Кодуйте швидко проти зменшення розміру файлів
• Асиметричне проти симетричного en- / декодування
• Будьте сумісні з програмним забезпеченням
• Будьте сприйнятливими майже без втрат у різних рівнях / ситуаціях стиснення
• Є функції, які інші кодеки не пропонують, зокрема:
  • бути безоплатним
  • підтримка шарів
  • підтримка альфа-каналу (наприклад, RGBA) / транспаранти
  • пропонуємо швидкий перегляд веб-сторінок
  • підтримка високої (ер) бітової глибини
  • підтримка декількох кольорових просторів (RGB / CMYK)
  • підтримка метаданих / версій / ...

Деякі з цих речей взаємно виключають. І через це нам залишається безліч кодеків.

Кілька прикладів

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

Мабуть, найбільш відомий формат - JPEG . Це дуже широко підтримуваний, але старий формат. Він використовує DCT (дискретна косинальна трансформація), тому, хоча він пропонує досить гарну якість при своїх найвищих настройках якості, блокування з’явиться з нижчими.

Тоді JPEG 2000 прийшов на зміну JPEG: Він заснований на Wavelet-трансформації, тому, хоча він пропонує приблизно таку ж якість, як JPEG у налаштуваннях вищої якості, він пропонує набагато кращу якість в налаштуваннях нижчої якості (блоки трохи розмиті ). Також JPEG 2000 пропонує регіони, що цікавлять (висока якість в одній області зображення, нижча якість деінде) та підтримка 16 біт. (Також, деякі інші речі.) На жаль (?), Оскільки він обчислювально дорожчий за JPEG та через деякі проблеми з ліцензуванням, JPEG 2000 не настільки широко підтримується, як JPEG.

PNG - це ще один широко відомий формат - він без втрат і підтримує альфа-канали, але не пропонує підтримку кольорових просторів без RGB (наприклад, CMYK). Тому це "лише онлайн" -формат.

Потім є VFX формати, такі як OpenEXR . Всі вони обертаються навколо якості та швидкості: OpenEXR без втрат, підтримує до 64 біт і швидко кодує / декодує. В основному використовується в галузі VFX як проміжний формат.

TIFF - ще один формат без втрат, який досить популярний у фотографів. Для стиснення він не пропонує / ZIP / RLE / LZW / JPEG. Він підтримує до 32 біт. Завдяки вибраному стисненню, він є досить адаптивним, але через свою втрату він більше офлайн-формату.

HEIF - один із останніх кодеків зображень. Він використовує те саме стиснення, що і HEVC / h.265, і, отже, очікується, що він дасть кращий коефіцієнт стиснення, ніж JPEG. Однак, оскільки він є досить новим і оскільки він підпадає під патенти, він не настільки широко підтримується, як будь-який із перерахованих вище.

Зображення RAW. ^{Дивіться також, що} це не реальні фотографії: вони більше є контейнером для необроблених даних (звідси назва) датчиків зчитування. Тільки за допомогою програмного забезпечення, яке вміє інтерпретувати дані, можна отримати зображення. Ось чому тому перетворювачі RAW, такі як Lightroom / Capture One / DarkTable / ..., потребують оновлень для підтримки нових камер, які використовують уже вказані контейнери типу * .CR2 для Canon. Це також причина, чому 14-бітова RAW пропонує більше варіантів редагування, ніж 32-бітний TIFF, який ви експортували з тієї ж RAW.

Intermisision: Без втрат проти втрат

Я досі не впевнений, що ви насправді запитуєте, тому я подумав, що не завадить додати невелике пояснення щодо програшів без втрат.

Стиснення без втрат працює, виконуючи кодування довжини пробігу (RLE) / кодування Хаффмана / ... для стиснення даних. Самі дані не змінюються, а зберігаються у меншому пакеті. Наприклад, візьмемо RLE: Скажімо, у нас є бітовий потік R-каналів (від пікселя 0,0до пікселя 0,11) 255,255,255,255,255,215,215,235,100,000,000,000- RLE кодує це як 52552215123511003000- це набагато менше, і оскільки ми знаємо, що він зберігається в групах по 4 цифри і що перша цифра - це лічильник, а останні три цифри - це значення, потім ми можемо відновити повну 255,255,255,255,255,215,215,235,100,000,000,000.

Стиснення втрат, з іншого боку, намагається стиснути навіть далі, ніж це може зробити втрата. Для цього кодеки, що втрачають свою програму, зазвичай намагаються видалити речі, які не сприймають. Візьмемо, наприклад, YUV( YCbCr, на самом деле) модель JPEG (і майже кожен відеокодек) використовує: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Людина не може визначити різницю між 4:2:0(кожен піксель має значення освітленості, але кольори зберігаються в блоках по 2x2 по черзі) та кодом 4:4:4(у кожному пікселі є яскравість і обидва кольорові канали). Це пов'язано з фізіологією нашого ока : ми не можемо побачити відмінності в кольорі, а також можемо побачити відмінності в освітленості.

Це працює добре протягом більшої частини часу, але порівнюйте його з файлом MP3: майже ніхто не може розрізнити між 192 кбіт / с і 320 кбіт / с, але нижче 64 кбіт / с і речі швидко стають некрасивими. Крім того, повторне кодування ще більше знизить якість, оскільки можуть з’явитися небажані артефакти (наприклад, у JPEG невеликі блоки з кодувань високої якості будуть розглядатися як деталі зображення у подальших кодуваннях).

Нижня лінія

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

Якщо вам потрібна якась конкретна функція, може (і майже напевно: буде) кодек, який охоплює це.

Якщо в основі, фотографії - це лише 3 канали значень пікселів [0, 255] X RBG

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

Я маю на увазі, чим RAW відрізняється від TIFF - чи не всі вони обмежені значеннями від 0 до 255?

Термін "необроблений" може позначати дві різні речі, зображення "необробленого камери" або файл, що містить неочищені дані зображення без заголовків.

Зображення "необроблене камерою" зберігає необроблені дані, оскільки вони виходять із датчика. Більшість сучасних датчиків камери мають АЦП з більш ніж 8 бітами, але вони також збирають дані інтенсивності лише для одного кольорового компонента в кожному місці. Геометрія може бути спотворена лінзою, значення інтенсивності від АЦП можуть не робити гарної роботи для відображення сприйняття людиною інтенсивності, кольорові компоненти можуть не відображатись точно з тими, які використовуються вашим монітором тощо.

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

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

Tiff - це складний формат файлів, який може зберігати зображення у найрізноманітніших форматах із найрізноманітнішими метаданими. На практиці він, як правило, використовується для зберігання стислих або без втрат стиснених зображень RGB або CMYK.

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

Далі, з числової точки зору, що робить щось на зразок 16-бітових зображень, відмінних від 32-бітових зображень?

На жаль, "російський біт" може означати дві різні речі. Це може означати, що всі кольорові компоненти набиті в бітну кількість (наприклад, 5 біт для червоного, 5 біт для синього і 6 біт для зеленого для 16 біт або 8 біт червоного, 8 біт зеленого, 8 біт синього і 8 біт альфа для 32 біта) або at може означати, що кожен кольоровий компонент має n біт інформації в кожному піксельному розташуванні.

Продовжуючи цю точку зору, що зображення у файловій системі комп'ютера - це лише 3-канальний масив цілих чисел між 0 - 255

Знову ж, ця перспектива є просто неправильною.

Файл - це послідовність байтів, але ці байти майже ніколи не є "лише 3-канальним масивом цілих чисел між 0-255"

Ви можете зберігати подібне зображення. Деякі інструменти навіть підтримують читання та запис таких файлів, але проблема полягає в тому, що це означає, що ви повинні знати про файл, перш ніж можете прочитати його. Припустимо, у вас був такий файл розміром 3000 байт, у вас є 1000 24-бітових RGB-пікселів? 3000 8-бітових пікселів у відтінках сірого? 3000 8-бітових пікселів з піддону? У якому порядку входять кольорові компоненти? яку форму має зображення? кольорові компоненти в порядку RGB або BGR? Якщо ви не знаєте відповідей на ці запитання, ви не можете змістовно прочитати такий файл.

Тож практичні формати зображень зазвичай починаються з одного або декількох заголовків, які ідентифікують тип файлу, розміри зображення та спосіб зберігання фактичних даних зображення. Вони також можуть містити необов'язкові метадані.

який сенс стискання зображення у формат втрат, як, наприклад, JPG? Скажімо, альго стиснення змінює деякі значення пікселів з 254 до 255 або будь-яке інше. Тому? Як це забезпечує економію розміру файлу чи впливає на якість візуалізації?

Алгоритми стиснення не просто "змінюють значення", вони кодують інформацію абсолютно іншим чином, наприклад JPEG можна приблизно описати як

• Перетворити дані з RGB в YUV
• (необов'язково) зменшують резонансну здатність кольорових каналів в 2 рази в одному або обох вимірах
• Розбийте дані для кожного каналу на 8x8 блоків.
• Перетворіть блоки в частотну область за допомогою дискретного косинусного перетворення
• Проаналізуйте кількість результатів, зберігаючи інформацію низької частоти, зменшуючи при цьому точність інформації високої частоти.
• Кодуйте отримані числа як послідовність байтів, використовуючи схему кодування змінної довжини (або кодування Хаффмана, або арифметичне кодування)
• Збережіть ці байти у файлі разом із відповідними заголовками.

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

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

Є кілька причин, чому це припущення є невірним, і всі вони зводиться до одного:

Яку шкалу ви фактично використовуєте?

І це можна розбити трохи далі:

Що таке 255?

"Колір" не є властивістю фізичної всесвіту. Це відчуття, яке виникає в розумі. І це включає такі речі, як "синій", "зелений" та "червоний". Шкала від 0 означає "зовсім не синій" до 255, що означає "все синє!" насправді 255 не може представляти платонічний ідеал синього , тому що ... в реальному світі немає такої ідеальної речі. Отже, чи означає це:

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

Звук надуманий? Ні! Це фактично реальні приклади. Перегляньте ці представлення кожного вибору. Вигнута область - це двовимірний фрагмент кольорового простору зору людини, а трикутник показує область, яку можна представити, надаючи конкретний вибір для червоного, зеленого або синього.

По-перше, ось профіль для екрана мого ноутбука, який є досить представником сучасних пристроїв середнього класу:

Тепер ось простір Adobe RGB. Зверніть увагу, наскільки це більше, ніж те, що може показати мій екран!

Отже, ось sRGB - стандартний простір дефокто та простір за замовчуванням, як правило, передбачається, коли нічого не вказано. Це означає бути "досить хорошим" у більшості ситуацій.

І нарешті, ProPhoto RGB, який використовує уявні кольори як праймери, щоб зробити трикутник досить великим, щоб вмістити майже весь людський зір.

Тепер киньте в колір самого світла, а хроматичну адаптацію - здатність системи зору людини пристосовувати сприйняття до навколишнього середовища. Насправді, не лише здібності: річ, що відбувається, хочете ви цього чи ні . Чи означає «чистий синій», що річ виглядає так синьо, як це можливо, під цим розжареним світлом? Якою має бути цінність, якщо ми замість цього фотографуємо на сонячному світлі?

Тож "255" може означати дуже багато різних речей.

Що таке 0?

Це досить просто - наскільки чорним вам потрібно 0? Це чорноморський чорний? Якщо це так, але всі фактичні відтінки на вашій сцені набагато менш екстремальні , чи дійсно ви хочете "витратити" купу потенційних значень для динамічного діапазону, який не є у вас на сцені - і який, як і колір, може Ви навіть не будете представлені будь-яким пристроєм або принтером, до якого Ви маєте доступ?

Яка ваша крива?

Отже, як тільки у вас є кінцеві точки, як ви переходите від однієї до іншої? Людське сприйняття яскравості, безумовно, нелінійне . У вашій шкалі 0-255 має бути 100 вдвічі яскравіше 50, чи це має бути якийсь більший фактор? Чи повинна різницю сприйняття між, скажімо, 3 та 4, такою ж, як між 203 та 204?

Якщо ви вирішили використовувати систему зберігання журналів, чи слід оптимізувати цю криву відповідно до зору людини, або для оптимізації даних, або для чогось іншого?

Існує багато можливостей, для різних потреб.

На стиснення

Ви запитаєте.

Скажімо, альго стиснення змінює деякі значення пікселів з 254 до 255 або будь-яке інше. Тому? Як це забезпечує економію розміру файлу чи впливає на якість візуалізації?

Сучасні алгоритми стиснення є складнішими за це, але це є хорошим прикладом. Я буду використовувати шістнадцятковий FFдля представлення 255 та FEдля представлення 254, і уявімо, що ми використовуємо кодування довжини запуску як форму стиснення. А для простоти, припустимо, замість кольору чорно-білі. При цьому, якщо у нас є ряд даних, який виглядає приблизно так:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

ми можемо стиснути це до дуже простого

16×FF 

... що є досить очевидною економією. В основному ми можемо зберігати 16 байт у двох (один для підрахунку, два для даних). Але давайте скажемо:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Тепер кодування довжини виконання дає нам:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

... що зовсім не є економією, і насправді міг збільшити розмір файлу. Але якщо ми округлимо всі FEзначення до FF, ми повернемося до першого випадку зі значним зменшенням розміру, з невеликим, але, ймовірно, важко помітити вплив на якість файлу.

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

На бітовій глибині

Далі, з числової точки зору, що робить щось на зразок 16-бітових зображень, відмінних від 32-бітових зображень? Знову ж таки, зображення - це лише масив із цілими значеннями між 0-255.

Отже ..... масив цілих значень між 0-255 - це восьмирозрядний масив. (2⁸ = 256.) З трьома каналами це 24-бітове зображення; деякі формати також мають прозорий ("альфа") канал для 32 біт. Можна також використовувати більш високе значення на канал, яке зазвичай мається на увазі, коли ми говоримо "16-бітова глибина". Це означає, що масив переходить від 0-65535 (2¹⁶ = 65536), а не від 0-255. Як правило, в такій схемі це в основному просто множник, де найвище значення представляє одне і те саме на кожній шкалі, але більша бітова глибина дає більше можливих нюансів. (Дивіться цю відповідь для отримання докладнішої інформації про це.) Існують також деякі спеціалізовані формати файлів, які використовують 64-бітні поплавці (!) Замість цілих чисел для значень або інших типів даних залежно від випадку використання, але основна концепція така ж .

Ні, зображення - це не лише значення RGB в діапазоні 0-255. Навіть якщо ви ігноруєте формати зберігання, існує багато способів описати колір. Ось кілька прикладів:

• Червоні, зелені та сині компоненти (RGB)
• Блакитний, пурпуровий, жовтий і чорний компоненти (CMYK)
• Відтінок, насиченість та легкість / значення (HSL / HSV)
• Кількість світла, яке потрапило на групу датчиків у камері
• Кількість світла та його напрямок при попаданні на датчики (у світловим камері )

Перші два найчастіше використовуються для відображення на моніторах та для друку відповідно.

Крім того, зображення - це не лише пікселі, а й метадані. Це можуть бути такі речі, як ширина в кількості пікселів, фізична ширина, якби ви її надрукували, ескіз зображення або навіть географічне розташування камери під час зйомки.

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

Однак формати файлів різні. В основному існує кілька різних способів представити це одне і те ж зображення, як згадують люди: bmp, png, jpg тощо. Звичайно, щойно розшифруєш їх, дві закодовані без втрат версії одного і того ж зображення призведуть до однакових матриць.
Подумайте про це як .txt файл, який ви стиснули за допомогою zip. З додаванням дивацтва, що кодування без втрат поверне текст, не такий, як оригінал, але насправді близький, майже як скинутий текст тексту.

Дотримуючись аналогії тексту, скажімо, у вас той самий текст, збережений як .txt, .docx, .pdf тощо. Чому всі файли не є однаковими, якщо вміст однаковий? (Ок, txt не має форматування, але інші).

До речі, перевірте, чим кодування Netpbm насправді відрізняється від JPEG .

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

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

Хорошим прикладом причини цього є відмінності в стисненні між файлом PNG і TIFF.

Файли PNG використовують один конкретний алгоритм стиснення. Це означає, що зображення не просто зберігатиметься як великий список номерів для кожного пікселя. Спрощений приклад: він може зберігати щось, що говорить "у цьому блоці пікселів 10x10, усі пікселі мають кольоровий XYZ". Потім замість того, щоб зберігати цю інформацію 100 разів, вона зберігає її один раз, а також трохи інформації про регіон, до якого застосовується інформація.

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

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

Файли TIFF, з іншого боку, підтримують безліч різних алгоритмів стиснення. Насправді він навіть може зберігати різні частини зображення, стиснуті по-різному. І він підтримує "розширення", тому ви можете стискати зображення, використовуючи власні способи. Тож можливо верхня половина вашого зображення буде стиснута за допомогою аналогічного методу PNG, але це не вдасться стиснути нижню половину, тому нижня половина стискається за допомогою іншого методу.

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

Отже, ви запитаєте

Але я не запитую про щось, окрім базового 3-канального RBC-зображення. Все, що я знаю, це те, що якщо хтось передасть мені одну з них, у мене зараз є масив чисел. У мене немає підстав знати, чому один масив чисел може бути іншим, ніж якийсь інший масив чисел від 0 до 255.

Щоб передати це вам, хтось повинен знати, як зберігається зображення і як перевести це у масив чисел. (Або, можливо, якесь програмне забезпечення робить цей переклад для вас невідомим).

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

Растрові карти

Растрова карта (BMP) - це, по суті, те, що ви описуєте, масив чисел, що представляють кольори пікселів. Наприклад, щось подібне

1, 1, 1, 0, 1, 1, 1, 1, 1, 1

Стиснення без втрат

Тепер визначимо схему стиснення. У нашій схемі стиснення у нас буде масив пар чисел. Напр

3, 1, 1, 0, 7, 1

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

Очевидно, це дещо спрощений вигляд зображення (наприклад, це лише один ряд) та схема стиснення. Але, сподіваємось, це дозволяє вам побачити, як схема стиснення змінює формат зображення. Ось так GIF відноситься до BMP. GIF використовує схему стиснення під назвою Lempel-Ziv-Welch замість цієї спрощеної.

Ми описали тут схему стиснення без втрат. Проблема зі схемами стиснення без втрат полягає в тому, що для деяких входів закодована форма може бути довшою за оригінал. Напр

1, 0, 1, 0, 1

Кодування є

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Ну, це було марно. Ми зробили вхід вдвічі довше.

Ще одне стиснення без втрат

Тепер розглянемо іншу схему стиснення. У цьому ми зобразимо зображення як накладені кола. Для кожного кола визначимо центр, радіус та колір.

Нашим першим растровим зображенням стане

5, 5, 1, 3, 0, 0

Це така ж довжина, як і наш перший метод стиснення.

І нашим другим може бути будь-який

2, 2, 1, 2, 1, 0, 2, 0, 1

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

1, 1, 1, 1, 1
1, 0, 0, 0, 1
1, 0, 1, 0, 1

Або

2, 2, 1, 1, 0, 0, 3, 0, 0

Це той самий початковий круг, але охоплений двома точковими колами. По кроках було б

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Вони обидві коротші, ніж перша кодована версія, але все ж довші за оригінал.

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

Стиснення втрат

Також у нас є концепція схем стиснення втрат. Ці схеми стиснення без втрат можна повернути в початковий масив растрових зображень. Схеми стиснення втрат можуть бути незворотними.

Розглянемо втрачену версію методу наших кіл. У цьому ми будемо використовувати просте правило. Ми не зберігатимемо жодних кіл із радіусом, меншим від 1. Отже, у наших останніх двох кодуваннях ми б замість цього мали

2, 2, 1, 2, 1, 0

і

2, 2, 1

які знову перетворюються в пікселі

1, 0, 0, 0, 1

і

1, 1, 1, 1, 1

Перша версія лише на один елемент довша за оригінал. Другий варіант коротший. Обидва дійсні, тому алгоритм вільний розробити обидва та вибрати коротший.

Ми описуємо зображення з більш обмежувальними правилами як такі, що мають нижчу якість.

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

На відміну від GIF, JPEG насправді є іншим способом подання зображення. GIF - це ще пікселі. Вони просто зберігаються по-іншому. JPEG - це форми. Щоб переглянути JPEG, ми перетворюємо фігури в пікселі, тому що так працюють екрани. Теоретично ми могли б розробити екран, який не працював би таким чином. Замість пікселів він може створювати форми, щоб краще відповідати формату JPEG. Звичайно, на цьому екрані не вдалося б показати растрові карти. Щоб відобразити BMP або GIF, нам доведеться перейти в JPEG.

Якщо ви конвертуєте стандартний GIF, скажімо, 300x300 пікселів, перетворюєте його в JPEG і прокручуєте якісний шлях вниз, основні форми, які він використовує, повинні бути видимими. Багато JPEG уникають цих артефактів, починаючи із зображення із значно більшою роздільною здатністю.

JPEG добре масштабуються, оскільки вони мають форму, а не пікселі. Тож якщо ви почнете із зображення 8000x8000, перетворите його в JPEG і покажете його як зображення розміром 300x300, значна частина деталей, що були втрачені, у будь-якому разі втрачена. Якщо ви перетворили растровий графік 8000x8000 в растровий файл розміром 300x300, а потім у JPEG, результати часто будуть нижчої якості.

MPEG

Ми говорили про нерухомі зображення. Група Moving Picture Experts Group або MPEG-формат використовує такий же тип стиснення, як JPEG, але він також робить щось інше. Хоча простий спосіб створення відеозаписів - це надсилання послідовності нерухомих зображень, MPEG насправді надсилає кадр з наступною деякою кількістю кадрів з переліком змін та закінченням кінцевого кадру. Оскільки більшість кадрів схожі на попередній кадр, список змін часто менше, ніж другий образ.

Послідовність зазвичай не така довга, скажімо, п'ять кадрів. Але це допомагає зробити потік меншим, ніж це було б інакше.

Спрощення

Я багато ігнорував. Мої зображення мають лише два кольори (1-бітове), а не 256 8-бітових зображень і, звичайно, не 4,294,967,296 32-бітного зображення. Навіть з 8-бітовими зображеннями зауважте, що для зображення часто можна вибирати різні палітри. Отже, два 8-бітні растрові карти з однаковими послідовностями можуть представляти зображення, які виглядають по-різному (однакова форма, але різного кольору).

Мої зображення є однорядними, а не двовимірними. Більшість зображень матимуть певний розмір рядка, що робить масиви двовимірними.

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

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

Скажімо, це було правдою, що кожен піксель складав лише три числа (червоне, зелене та синє), кожне в діапазоні 0-255. Інші відповіді почали (правильно) оскаржуючи це припущення, але для простоти скажемо, що це правда.

Я пам’ятаю (але, на жаль, не можу знайти в Інтернеті) мультфільм з підручника з лінгвістики: двоє давньоєгипетських різьбярів з каменю сидять виснажені внизу масивної стіни, на якій вони вирізали дуже велику кількість маршируючих фігур. Один каже іншому: "Напевно, має бути простіший спосіб написати:" У фараона було 100 000 солдатів? "". Майте на увазі цю ідею.

Тепер, припустимо, перший рядок вашого зображення містить 1800 чорних пікселів. Як би це було представлено?

0 0 0    0 0 0     0 0 0   ....

Так скільки місця для цього потрібно? Кожне значення - байт. Три байти на піксель, 1800 пікселів у рядку, тобто вже 5400 байт у рядку. Отже зображення з розмірами 1800 х 1200 повинно займати в 1200 разів більше, що перевищує 6 мегабайт. Отже, тепер перейдемо до пошуку зображень Google і завантажимо пару зображень розміром 1800x1200 - скажімо, одне .pngзображення та одне .jpgзображення. Подивіться на розмір файлу: це 6 Мб? Ні в якому разі, як правило, це набагато менше цього. І це бажано, звичайно, весь цей простір економив, і коротший час завантаження ....

Отже, що відбувається? Ключовим є те, що навіть якщо у вас є стільки номерів для зберігання, існують різні способи представленняці числа у файлі. Приклад ефективнішого представлення тут є у моїй відповіді, два абзаци тому. Я написав слова "1800 чорних пікселів". Це 17 символів, і тому не потрібно займати більше 17 байт, але він чудово описує ту саму інформацію, для якої ми думали, що нам потрібно 5400 байт. І ви, безумовно, могли б зробити краще 17 байт (а також заощадити багато зусиль на впровадженні кодування / декодування), якби ви не використовували англійську мову для кодування цієї інформації, а скоріше більш спеціальну мову. Отже, ми вже розмістили більше одного формату стиснення зображень: той, який використовує англійські слова, і той, який є більш ефективним. Бачите, куди це йде?

Гаразд, ви кажете, це працює, якщо ціла купа суміжних пікселів має один і той же колір. Але що робити, якщо вони цього не роблять? Ну, звичайно, це залежить від змісту конкретного зображення: чим більше надмірності , тим легше стискати інформацію. Надлишок означає, що частини зображення можна передбачити досить добре, якщо ви вже знаєте інші частини. Стиснення означає лише записувати мінімальний мінімум, необхідний для реконструкції інформації. Не кожне можливе зображення має надмірність, але будь-яке реальне зображення, яке має значення для людського ока та мозку, незважаючи на те, що воно є складнішим, ніж мій чорно-чорний приклад, все ще має тенденцію до надмірності. І існує безліч різних способів стиснення. Деякі методи стиснення без втрат, що означає, що інформацію можна реконструювати таким чином, щоб вона була математично ідентичною оригіналу, як у моєму прикладі чорних рядків пікселів. Більшість .pngфайлів використовують метод стиснення без втрат. Деякі методи є втратними : реконструкція не є досконалою, але помилки приховані таким чином, що людське око та мозок майже не помічають їх. Більшість .jpgфайлів є втратними.

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

Кілька коментаторів вище зробили обґрунтовані здогадки про те, де могло виникнути ваше помилкове уявлення. У вашому запитанні вам здається, що стиснення просто трохи змінює значення пікселів (і, безумовно, методи стиснення втрати роблять це місцями, але лише як небажаний побічний ефект), не змінюючи інформаційний макет. Коли ви відкриваєте файл і дивитесь на вміст зображення (наприклад, як масив чисел у Matlab або як зображення на екрані у Photoshop), ви дивитесь не на стислий вміст файлу, а на реконструкцію, який має той самий макет, що і оригінал (він не був би великою частиною реконструкції, якби не відтворив макет правильно). Процедура відкриття файлу видалила інформацію з файлу в повне нестиснене представлення в пам'яті. Якщо порівнювати дві нестиснені реконструкції, то насправді немає нічого, що можна відрізнити між двома різними форматами зображень, з яких вони виникли (крім помилок відновлення, якщо такі є).

Так, але те, як дістатися до цих 1 і 0, дуже відрізняється.

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

Для ускладнення питань існують різні канали. CMYK, RGB, B&W, лише декілька. Ми не будемо робити це. Існують також різні етапи, такі як захоплення, зберігання та показ. Ми підемо в цьому, хоча знову ж таки приклад повинен показати, що він не є точним. Якщо ви хочете точних прикладів, вам потрібно буде знайти тонну технічних документів.

Тож у нашому зразку ми будемо розглядати чорно-біле зображення.

00067000
00067000
00567800
04056090
40056009

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

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

302730
302730
204820
*04056090
1420262019

Тепер саме так ми зберігаємо зображення на диску. Це займає менше місця і дозволяє нам виробляти більшу частину оригінального зображення.

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

00011000
00011000
00111100
01011010
10011001

Це виводить зображення на розумний вигляд, але ви можете бачити, навіть на прикладі нестандартної якості. Але ей, це вина принтера.

Нарешті, ви переходите до друку зображення на хорошому принтері з 10 рівнями чорного. Те саме, що ваша камера. Таким чином, ви використовуєте збережене і стиснене зображення.

00077000
00077000
00888800
04056090
40066009

Як бачите, зображення є "кращим", але було трохи змінено з оригіналу.

У будь-який момент часу ви правильно, що це лише сила каналу. І, крім іншого, стиснене зображення, яке так чи інакше треба декомпресувати, воно залишається досить вірним.

Однак стислий формат втрачає багато "інформації". Чи важлива ця інформація? Ну, це залежить від артиста та аудиторії. Існує кілька компромісів між економією місця, часу обробки, якістю остаточного / збереженого зображення та потребою. Я сканую більшість своїх документів у кольорі чорного кольору, тому що це все, що мені потрібно. Однак мої весільні фотографії є ​​у ​​ВЕЛИЧОГО формату RAW, тому що я ніколи не знаю, коли мені захочеться зробити їх передрук. Це означає, що коли я переношу їх (фотографії) на цифрову рамку зображення, я перетворюю їх у JPEG, щоб заощадити місце. Різні канали, різні фільтри та різні методи стиснення - це низка компромісів. Це як цифрова версія трикутника принтерів.

Я підкажу трохи інформації, оскільки я працював із зондуванням зображень та кодуванням / стисканням, хоча переважно рухомих зображень.

У своїй базовій формі зображення (БУДЬ-яке зображення), яке відображається на певному екрані, дійсно є лише ідентичним масивом чисел. Ці числа можуть бути 0-255 або 0-65535 або 0-будь-що-32-біт-це-я-забув-go-google-it.

АЛЕ Є так багато способів зберігання та транспортування інформації, що багато з них - це просто продукти технологій, втрачених у туманах часу.

Крім того, одна деталь, про яку я не бачив жодного з інших педантів, тут згадує, що справді дані датчика RAW-зображення із цифрової камери цілком можуть бути RGrGbB у шаблоні байєра, або щось таке, що потрібно хоч трохи обробити, щоб зробити будь-якого сенсу до очного яблука Mk.1. Цілком ймовірно, що ви ніколи не отримаєте цього навіть у форматі RAW, збереженому вашим DSLR, оскільки це марно, поки ви не перетворите його на приємну сітку пікселів RGB або YUV, будь то 8, 16, 32 або одинадцять-шільйон біт.

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

Щоб прочитати час перед сном, перегляньте розділ "Формат зображення кадру": http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

У будь-якому випадку ... повернемося до вашого початкового запитання про різницю між нестисненими файлами зображень, такими як TIFF / RAW / IFF / PNG.

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

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

Традиційно це так, що вони можуть змусити вас (або, швидше за все, професійних фотографів) використовувати своє власне (а іноді і дороге) програмне забезпечення для обробки цих зображень більш високої якості, інакше ви можете почати використовувати дороге програмне забезпечення інших людей. Крім того, можливо, Adobe Photoshop хочуть підтримати їх формат, тому, можливо, вони можуть зарядити Adobe $$$ за цю інформацію, так що більш професійні фотографи купуватимуть PS та, можливо, купуватимуть цю камеру, оскільки PS підтримує її зараз. Затишно!

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

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

IFF (так, це річ) був подібним форматом, який використовується на комп'ютерах Amiga, я вважаю, винайдений ними або одним із популярних пакетів фарб. Але я використовую це як приклад, тому що, хоча він зберігає бітові карти зображення, як і інші, він підтримує нестиснені або RLE дані, змінну глибину бітів від 1-бітного моно-до 8-бітного 256-кольорового (але з 3x8-бітна палітра RGB на вибір для кожного з кольорів), а також спеціальні режими під назвою Halftone та Hold-And-Modify, що дозволяють отримати набагато більше кольорів, ніж інші машини епохи. Ох, і він підтримував анімацію (як GIF), щоб файл IFF міг зберігати будь-яку кількість кадрів із змінними затримками між кадрами, і кожен кадр міг мати власну палітру. Отже, IFF міститиме додаткові дані для обробки всього цього порівняно з, скажімо, файлом TIFF.

PNG - це ще один формат зображення без втрат, який знову зберігає растрові дані, але підтримує деякі прикольні функції, такі як 8-бітний альфа-канал для різної прозорості зображення (корисно на веб-сторінках), тому знову дані про зображення "корисний вантаж" можуть виглядати дуже схоже але обгортка навколо нього інша, і корисне навантаження може містити RGBA, а не просто дані RGB на піксель.

Отож, це 4 різних формати файлів зображень, описаних - ви можете зберігати зразковий повнокольоровий HD-зображення кота в будь-якому з 4-х, і це буде ЛОГАТИ ідентично, кожен піксель на вашому екрані мав би значення ТОЧНЕ ІМЕНЕ і не було б НІ різниця в якості між 4 ... але 4 файли, ймовірно, будуть різними за розміром, компонуванням і будуть легшими або складнішими для завантаження та обробки програмного забезпечення.

Сподіваюся, що це допомагає!

Я просто подумав, що я подзвоню сюди з інформацією, яка мала бути в першій відповіді на це питання.

Пікселі на зображенні не зберігаються в байті - якщо тільки зображення не є однотонним, тобто лише чорно-білим.

Якщо у вас є справжнє кольорове зображення, то кожен піксель представлений 16 бітами, або 2 байти - як одне значення. Якщо у вас є 32-бітове зображення, то для кожного пікселя потрібно 32 біти або 4 байти, знову ж таки як одне значення.

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

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

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

Ось чому у нас є такі речі, як 16-бітні та 32-бітні зображення, а також 16-бітні та 24-бітні аудіофайли. Чим більше бітів ви використовуєте для пікселя або звукового зразка, тим виразніше ви можете бути - 16 біт можуть визначати лише 64 К унікальних кольорів, але 32 біти можуть визначати понад 4 мільйони унікальних кольорів. Для монохромного зображення використовується 1 біт на піксель - він увімкнено або вимкнено.

З аудіофайлами, чим більше бітів ви використовуєте на зразок, тим більш детальною і нюансованою може бути запис.

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

Навіть не згадуючи кольорові домени, стиснення, розміри бітів та формат каналу, існує безліч форматів файлів, абсолютно не схожих на піксельні карти. І все ж векторні формати також набагато «кращі» для представлення певних типів зображень, як правило, створюваних комп’ютером, а не камерою.

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

Перше питання тут:

Далі, з числової точки зору, що робить щось на зразок 16-бітових зображень, відмінних від 32-бітових зображень? Знову ж таки, зображення - це лише масив із цілими значеннями між 0 -255.

Як було представлено раніше: Ні, це не так. Зображення - це не просто масив цілих значень між 0-255. Насправді це може бути одиночний або багатовимірний масив від 0 до 65535 значень, масив від 0 до 4294967295 або навіть масив бітів (біт може містити 0 або 1 значення, ось і все), що перетворюється програмним забезпеченням, здатним читати файли зображень у цілі числа відповідно до різних правил кодування.

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

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

• BIT - тримаючи 0 або 1
• UINT8 - 8-бітне ціле число без підпису - вони можуть утримувати значення між інтервалом [0 до 255].
• INT8 - 8-бітове підписане ціле число - вони можуть утримувати значення між інтервалом від -126 до 127].
• UINT16 - 16-бітове ціле число без підпису - вони можуть утримувати значення між інтервалом [0 до 65535].
• INT16 - 16-бітне ціле число без підпису - вони можуть утримувати значення між інтервалом від −32768 до 32767].
• UINT32 - 32-бітове ціле число без підпису - вони можуть утримувати значення між інтервалом [0 до 4294967295].
• INT32 - 32-бітове ціле число без підпису - вони можуть містити значення між інтервалом [−2147483648 до 2147483647].
• АБО комбінація всіх цих типів даних у більш складному форматі. Наприклад, UINT16 (16 BIT), що містить 3 різних значення, перші 4 значення BIT утримують від 0 до 127, наступне утримування BIT 0 або 1 і так далі.

Далі БІЛЬШЕ Є що програмістам доводиться мати, коли читати чи записувати цілі типи даних із файлів. Ендіасильність.Під ендіантністю розуміється послідовний порядок, в якому байти (UINT8 з нашої таблиці) впорядковуються в більші числові значення при зберіганні в пам'яті або файлах. Ендіанс представляє інтерес для інформатики, оскільки два спільні та несумісні формати є загальноприйнятими: значення можуть бути представлені у форматі big-endian або little-endian, залежно від того, чи біти, байти чи інші компоненти впорядковані з великого кінця (найзначніше біт) або маленький кінець (найменш значущий біт). Простіше кажучи, ви можете зберігати таке значення, як це 0000000011011111 або ... подібне до цього 1101111100000000 залежно від або вибраного вами порядку. І ви вільні вибирати будь-яке замовлення, яке відповідає вашому призначенню. Інших правил немає, ніж ті, які ви створюєте під час проектування формату файлів зображень.

Будь ласка, зауважте, що в цілому комп'ютерному програмуванні цілі числа використовують більше або менше місця, залежить від значення. Як і вам потрібно більше паперу для написання 255255255, вам потрібно більше BIT, щоб написати більше значення. Потім пізніше, коли ви хочете прочитати значення, ви повинні точно знати правила, які ви створили під час написання. Інакше вам неможливо зрозуміти, як читати просто масив із цілими значеннями від 0 до 255, оскільки ви просто не знаєте, де ці числа зберігаються і як зберігаються ці числа, надаючи стільки варіантів (BIT, UINT8 , UINT16, UINT32 або комбінація всіх цих типів даних комп'ютера). І не забувайте, Ендіанес. Якщо ви не знаєте, дані були записані, використовуючи велике або ендіанське замовлення, ви не можете прочитати належне значення.

Через це зображення НІКОЛИ не просто масив із цілими значеннями від 0 до 255. Деякі з них - це масиви UINT16 (16-бітові зображення), інші - масиви UINT32 (32-бітні зображення), а інші - масиви UINT8 (8-бітові зображення). Деякі дуже креативні комп'ютерні програмісти можуть навіть використовувати підписані типи, які живуть вам з масивами INT8, що означає масив значень між -126 та 127.

Насправді, коли ви читаєте файл зображення, однією з перших даних, з якою ви стикаєтесь, зазвичай є деякі біти, що представляють ширину та висоту зображення. І це не лише деякі значення 0-255. Це також деякі типи даних, обрані програмістом. Деякі програмісти вважають, що 16 біт-бітів однозначні для збереження максимальної ширини зображення в 65535 пікселів, оскільки вони розробляють формат зображення, який використовується в грі, щоб зберегти зображення невеликих кнопок. Деякі інші програмісти можуть використовувати тут 32-бітове значення, що дозволяє зберігати зображення до ширини та висоти 4294967295. Деякі божевільний програміст NASA може навіть використовувати 64-бітний для зберігання величезної фотографії галактики розміром до 18446744073709551615 пікселів.Якщо ви не знаєте правил, ви не можете прочитати ті "значення", як ви їх називаєте. Тому що ви не знаєте, з чого вони починаються у файлі зображень та де вони закінчуються. Таким чином, ви закінчите купу біт-бітів, про які нічого не розумієте.

Ось чому Всесвіт заповнений такою кількістю різних форматів зображень. Тому що не існує стандартного рішення записувати деякі цілі значення у файл. Це вибір програміста, що повністю ґрунтується на багатьох факторах, таких як Endianess машини, над якою ви працюєте, мовою програмування, яку ви використовуєте для проектування оригінальної реалізації формату файлу, та багатьох інших речах, таких як мета формату зображення (як чітко зазначено раніше інші відповіді).

Практичний простий формат файлу чорно-білого зображення, що містить лише одне єдине значення 166 для зображення зображення 4x2 пікселів:

Зображення (1 - чорний піксель, 0 - білий піксель):

1010 
0110

Цей формат файлу використовує 1 BIT на PIXEL, що зберігається у вигляді єдиного цілого числа 16-бітового значення 166 (10100110). Це все. Не використовується масив значень 0-255, але 8 різних значень 0 або 1 зберігаються як значення 166.

Якщо ви використовували масив значень 0-255 для кожного пікселя * 3 рази для RGB, ви отримаєте зображення в 24 рази більше. Цей формат файлу просто заощадив у 24 рази більше місця на диску, щоб зберегти подібне зображення або в 24 рази менше пам'яті комп'ютера, необхідної для читання та збереження цього зображення в комп'ютерній оперативній пам’яті, коли ви використовуєте це зображення, наприклад, у високоефективній 3D-ігровій машині для намалюйте щось на екрані (текстурування тисяч пилових частинок, що летять навколо, може бути хорошим кандидатом :)).