Підготуйтеся до величезної посади - так, це вийшло з рук ...
Обов’язковий xkcd:
На жаль, не існує простого "найкращого" формату. Деякі дуже добре підтримуються, деякі пропонують надзвичайну універсальність, деякі пропонують стиснення без втрат, ...
Перша частина цієї відповіді ("Особливості" та "Короткий огляд форматів") розповість про технічні можливості, а друга частина ("(Інші) Речі, які слід врахувати") більш спрямована на практичні аспекти вибору формату .
Особливості:
Зауважте, що включити кожен хак до кожного формату майже неможливо - наприклад, GIF можна зберегти без стиснення, ігноруючи таблицю LZW. Чому я не згадую про це нижче? Тому що 99% усіх GIF, з якими я коли-небудь стикався, використовували LZW, тому що LZW на сьогоднішній день є непродуманим в обчислювальній потужності, і тому, що цей пост намагається прояснити ситуацію для популярних ситуацій, а не для відділу досліджень і розробок ILM. Фотографи використовуватимуть свої файли для архіву, публікації та друку, тому це я розглядаю тут.
Інформація перевірена між відповідними статтями, специфікаціями, порівнянням Wiki та списком метаданих exiftool .
| Bits per | | Supported by
Codec | Lossy | Channel | Metadata | Channels | Programs | Good for (IMHO)
-------------------------------------------------------------------------------------------------
BMP | n | <= 8 | - | RGBA | Most propr. & free | Archival
BPG | y | <= 14 | EXIF+XMP | RGBA | |
EXR | o | <= 32 | y(?) | RGBAD | | VFX workflow
FLIF | o* | <= 16 | EXIF+XMP | RGBA | | To be seen
GIF | n | <= 8* | XMP | RGB | Most propr. & free | GIFs ;-)
HEIF | o* | <= 16 | EXIF+XMP | RGB(A/D) | | To be seen
JPEG | y* | <= 8 | EXIF+IPTC+XMP | RGB | ~ all propr. & free | Online; Easy access
JP2K | o | <= 32 | EXIF+IPTC+XMP | RGBA | |
JXR | o | <= 32 | EXIF+IPTC+XMP | RGBA | |
PNG | n | <= 16 | EXIF+IPTC+XMP*| RGBA | Most propr. & free | CAD-drawings; Online
TGA | n | <= 8 | y(?) | RGBA | |
TIFF | o | <= 32 | EXIF+XMP | RGBA | Most propr. & free | Archival; Editing
WebP | o | <= 8 | EXIF+XMP | RGBA | |
Легенда : o
... Необов’язково; n
... недоступний; y
... в наявності; D
... Глибина; *
... Подивіться нижче на текст.
Короткий огляд форматів:
BMP
Feature |
-----------------------------------------------------------------
Introduced | 1990
Open + Free | Both per Microsoft's Open Specification Promise
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 1:0:0[:0], 5:6:5, 8:8:8[:8]
Compression | None [RLE in 5:6:4] (so: lossless)
Maximum Size | 4 GiB
Metadata | [ICC]
OS support | Virtually all OSs with a graphical interface
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
Файли "Бітові карти" кодуються рядками і зазвичай не стискаються, тому один біт фліп знищить лише одну лінію зображення, доки він не перегортає заголовок, що ускладнить розшифровку - спробуйте для себе HEX редактор! . Оскільки він не пропонує (хорошого) стиснення, розміри файлів величезні, оскільки він повинен зберігати повну інформацію для кожного пікселя. Через свою жорсткість це може бути корисним для довготривалого архівування.
БПГ
Feature |
---------------------------------------------------------------------
Introduced | 2014
Open + Free | Yes (but HEVC patents might be problematic)
Colorspace | R:G:B[:A] (4:4:4[:4]); Y:Cb:CR[:A] (4:2:0[:4] - 4:4:4[:4]);
| Y:Cg:Co[:A] (4:2:0[:4] - 4:4:4[:4]); C:M:Y:K (4:4:4:4)
b/c/p | 8 - 14
Compression | HEVC (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (at least through browser decoding)
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
"Краща портативна графіка" (BPG) використовує HEVC, про який ви можете знати з відеокодеку h.265 . Це мало бути спадкоємцем JPEG, але так і не отримало достатньої популярності. З підвищенням HEIF, який є в чомусь подібним, але більш популярним, можна вважати, що HEIF буде надавати перевагу. HEVC набагато перевершує за рівнем стиснення порівняно з DCT JPEG - однак, він не порівнює в усіх, окрім нижчих бітових швидкостей, оскільки він, як правило, розмито.
EXR
Feature |
---------------------------------------------------------------------
Introduced | 1999
Open + Free | Yes
Colorspace | R:G:B[:A][:D] (4:4:4[:4][:4])
b/c/p | <= 32
Compression | [RLE]; [ZIP]; [PIZ]; ... [lossless (usual) / lossy]
Maximum Size | > 4 GiB
Metadata | [Yes (XMP-style)]
OS support | Linux, Mac, Windows (through library)
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
OpenEXR був розроблений Industrial Lights and Magic (ILM) як проміжний формат для робочих процесів VFX. Він може вміщувати кілька каналів на дуже великій глибині бітів, кілька зображень та метаданих в одному файлі. Він пропонує різні алгоритми стиснення - або зовсім не стиснення. EXR можна порівняти з TIFF - EXR пропонує більше варіантів, в той час як TIFF далеко не популярний.
ФЛІФ
Feature |
---------------------------------------------------------------------
Introduced | 2015
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4]) (CMYK and YCbCr in ToDo-List)
b/c/p | <= 16
Compression | MANIAC (variant of CABAC, used in AVC/HEVC) (lossless / lossy (1st generation))
Maximum Size | > 4 GiB
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (through provided viewer)
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
"Безкоштовний формат зображення без втрат" (FLIF) використовує похідне стиснення HEVC, яке не має втрат. FLIF стверджує, що має надзвичайний коефіцієнт стиснення порівняно з усіма іншими формати того часу - хоча мої власні тести змусили мене повірити в це, йому дійсно потрібна обчислювальна потужність, щоб бути корисною (кілька хвилин кодування часу для однієї картинки 24 МП із гіперточеною Шестикосний 4,3 ГГц - це не так добре: D) . Однак, оскільки це молодий кодек, можливі вдосконалення. Він пропонує підтримку анімації, альфа-каналів, прогресивного декодування та навіть кодування втрат (без втрати більше покоління після першого кодування). Тільки час покаже, чи вдасться це зробити, і якщо чесно, я дуже сподіваюся на це, оскільки, здається, пропонує єдине рішення для кількох проблем.
GIF
Feature |
---------------------------------------------------------------------
Introduced | 1987
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 2 (palette of 256 colors in total)
Compression | LZW (lossless)
Maximum Size | < 4 GiB
Metadata | [XMP]
OS support | Virtually all OSs with a graphical interface
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
У той час як "Формат графічної взаємодії" (GIF) пропонує 8 біт на канал на піксель, це зменшить їх до палітри кольорів у 256 кольорів (яка може включати "колір фону"). В основному використовується для анімації - єдине, що PNG не може зробити краще, оскільки PNG сам по собі не пропонує підтримку анімації.
HEIF
Feature |
----------------------------------------------------------------------
Introduced | 2015
Open + Free | No (patents)
Colorspace | ? Y:Cb:Cr[:A/:D] (4:2:0[:4]) ?
b/c/p | <= 16
Compression | HEVC (lossy)
Maximum Size | < 4 GiB
Metadata | [EXIF]; [XMP]
OS support | Linux, Mac, Windows
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
Формат зображення високої ефективності (HEIF) також використовує HEVC для стиснення. Крім кольорових каналів, він також може містити або альфа-канал, або карту глибини (використовується для пізніших програмних ефектів глибинного поля ). Також рудиментарне редагування може відбутися без втрат. Кодуючи специфікації, він також має режим стиснення без втрат. Оскільки всі основні ОС підтримують його, схоже, це найвірогідніший претендент на перехід JPEG (якщо він колись є).
JPEG
Feature |
----------------------------------------------------------------------
Introduced | 1991
Open + Free | Sort of (free library, but patent might apply)
Colorspace | Y:Cb:Cr (4:2:0 (typical) - 4:4:4)
b/c/p | 8
Compression | DCT (lossy)
Maximum Size | < 2 GiB
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Virtually all OSs with a graphical interface
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
"Спільна група експертів з фотографічних питань" (JPEG) - це, мабуть, найпоширеніший формат зображення сьогодні. При цьому використовується дискретна косинусна трансформація (DCT), яка має втратний вид. Існує специфікація без втрат, але вона використовується не надто часто. Деякі програми можуть виконувати певні рудиментарні дії (наприклад, обертання) без втрат, хоча для цього також потрібно, щоб ширина та висота зображення були розділені на 8 (розмір блоку JPEG) - наприклад, 800x640 буде працювати, 804x643 не буде. JPEG не має можливості зберігати зображення в RGB - він перетворює зображення в кольоровий простір YCbCr і часто зменшує піксельну інформацію з 4: 4: 4 (кожен піксель має всі канали) до 4: 2: 0 (кожен канал має яскравість, але лише кожен 4- й піксель отримує значення Cb / Cr). Як і у більшості перетворень кольорового простору, це може призвести до помітних відмінностей, особливо в екстремальних кольорах. JPEG швидко кодує і не надто поганий у налаштуваннях високої якості, але мені, згадані вище речі не змусили б плакати, якби коли-небудь зникало - він нам добре служив, але використовувані формати зображень можуть бути трохи більше ... останнім часом. Адже комп’ютери розвивалися добре з 1991 року.
JP2k
Feature |
----------------------------------------------------------------------
Introduced | 2000 (duh...)
Open + Free | No (patents)
Colorspace | ? Y:Cb:Cr[:A] (4:4:4[:4]) ?
b/c/p | 8 - 32
Compression | Wavelet (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Linux, Mac, Windows (at least through viewer programs)
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
"JPEG 2000" (JP2k або JP2) є офіційним наступником JPEG. Він використовує вейвлети замість DCT, які пропонують менше блокованих артефактів і в цілому більш універсальні, ніж JPEG. Незважаючи на все це, він ніколи не наздоганяв JPEG.
JXR
Feature |
----------------------------------------------------------------------
Introduced | 2009
Open + Free | Yes (Microsoft Open Specification Promise)
Colorspace | Y:Cb:Cr[:A] (4:2:0[:4] - 4:4:4[:4]); Y:Cg:Co[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
| C:M:Y:K [4:4:4:4]
b/c/p | 8 - 32 (16 for CMYK)
Compression | DCT (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Linux, Mac, Windows (at least through viewer programs)
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
'Розширений діапазон JPEG' (JPEG XR, JXR) - ще одна спроба досягти успіху в JPEG. Її колірний простір YCgCo перевершує YCbCr, оскільки він є повністю оборотним. Хоча якесь програмне забезпечення підтримує його, воно також ніколи не наближалося до слави інших форматів.
PNG
Feature |
----------------------------------------------------------------------
Introduced | 1996
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 8 - 16
Compression | DEFLATE (lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Virtually all OSs with a graphical interface
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
"Портативна мережева графіка" (PNG) була введена як наступник GIF. Незважаючи на те, що дизайн без втрат, файли PNG можна оптимізувати за допомогою декількох інструментів, деякі з яких стискатимуть файл збитково. PNG використовує стиснення DEFLATE, тому він досить ефективний для графіки (як CAD-малюнки, скріншоти, ...), але менш ефективний для фотографій. Хоча вона пропонує підтримку метаданих, деякі програми мають проблеми з їх читанням. Дякую за голову, @mattdm !
TGA
Feature |
----------------------------------------------------------------------
Introduced | 1984
Open + Free | ? Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | <= 8
Compression | RLE (lossless)
Maximum Size | ? < 2 GiB
Metadata | Rudimentary
OS support | ? Virtually all OSs with a graphical interface
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
'Truevision TGA' / 'TARGA' (TGA) - це формат файлів, який я включив лише тому, що всі, здається, це знають. Він був представлений у 1984 році. Він підтримує стиснення без втрат (RLE), що буде добре працювати з графікою, але не дуже добре для фотографій.
TIFF
Feature |
----------------------------------------------------------------------
Introduced | 1986
Open + Free | ? Yes
Colorspace | R:G:B[:A] (4:4:4[:4]); Y:Cb:Cr[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
| C:M:Y:K (? 4:4:4:4 ?); L:a:b[:A] (? 4:4:4:[A] ?)
b/c/p | 8 - 32
Compression | [LZW (lossless)]; [ZIP (lossless)]; [JPEG (lossy)]
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Virtually all OSs with a GUI support >= 1 of the compression types
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
"Формат файлу тегів зображень" (TIF або TIF) також існує давно. Він пропонує підтримку шарів (тобто декілька RGBA-зображень, що складені). TIFF часто використовуються як проміжні файли, оскільки вони широко підтримуються та досить гнучкі з точки зору своїх можливостей.
WebP
Feature |
----------------------------------------------------------------------
Introduced | 2010
Open + Free | Yes
Colorspace | R:G:B:A (4:4:4[:4]) lossless; Y:Cb:Cr[:A] (4:2:0[:4]) lossy
b/c/p | 8
Compression | VP8 (lossless / lossy)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (at least through browser decoding)
Легенда : b/c/p
... біт на канал (наприклад, R, G, B) на піксель. речі в [ ]
необов’язкові; ?
... освічена здогадка / ніякого поняття.
'WebP' використовує VP8 (формат конкурентів з відкритим кодом для AVC). Як і у BPG, він ніколи не робив цей стрибок у споживчі пристрої, хоча, здається, він використовується багатьма інтернет-сервісами.
(Інше) Що слід врахувати:
Перекодування (втрата генерації)
Перекодування файлу без втрат нічого не змінить - повторне кодування втратного файлу майже напевно призведе до артефактів. JPEG може впоратися з цим досить добре, якщо ви збережете файл у тій же настройці якості, що і раніше.
Це відео доволі добре показує втрати покоління - перший кадр показує оригінальний файл, а всі інші демонструють повторне стиснення при різних параметрах якості. (Зверніть увагу, що FLIF знаходиться в режимі втрати, тому перший кадр буде виглядати інакше.)
Артефакти не обов'язково будуть смертним вироком - наприклад, для швидкої публікації в Інтернеті чи попереднього перегляду на мобільних пристроях це може бути не дуже погано.
Довговічність кодека
Коли я писав цю відповідь, я думав собі, "хто б зараз використовував TARGA?" і це змусило мене задуматися: я б ніколи не вагався керувати автомобілем, зробленим у 80-х. Я б не вагаючись дивився на знімки, зняті у 80-х. Я б використовував будь-які камери, зроблені в той час. Але я б не використовував кодек такого старого. Чому?
Зрештою, немає впевненого способу сказати, чи переживе один кодек чи інший певний проміжок часу. Якби HEIF замінив JPEG на всіх споживчих пристроях завтра, скільки часу знадобиться, щоб програми припинили підтримку JPEG? Скільки поколінь комп’ютерів - і що ще важливіше: ОС - буде, перш ніж ви більше не зможете їх відкрити?
З іншого боку, відносно прості кодеки, такі як TARGA, вимагають лише читати їх відносно прості програми, тоді як сучасні кодеки та їх декодери мають декілька залежностей. Отже, хоча простота погана для стиснення, це може бути добре для архівування в апокаліптичному сценарії. Дякуємо @lijat за вказівку на це!
На мою думку, для цього потрібно враховувати декілька ракурсів: який кодек досить популярний, щоб підтримка не опускалася відразу? Який кодек підтримується спільнотою з відкритим кодом (оскільки ніхто не підтримуватиме фірмові формати фірми-банкрута)? Крім того, здається, що щонайменше кожні десятиліття потрібно бачити, чи є необхідність перейти до нового, краще підтримуваного кодека (Див. "Перекодування (втрата генерації)") - ви б, наприклад, не хотіли ваша колекція TARGA буде завтра нечитабельною, правда?
Це, до речі, особливо хвилює, коли думаєш про файли RAW .
Підтримка програми (Довголіття №2)
Найпопулярніший, найкращий кодек буде недостатньо хорошим, якщо ви не можете його використовувати. І хоча я б не використовував неповноцінні кодеки лише тому, що певна програма не підтримує її, можливо, буде погано використовувати кодек, який належним чином підтримує лише одна програма.
Які функції мені потрібні?
Особисто я все ще кодую більшість своїх файлів у JPEG - я можу їх читати на будь-якому пристрої і ледве (якщо взагалі) бачу артефакти. 8 біт достатньо хороший для більшості пристроїв, і альфа-канали насправді не потрібні для перегляду зображень.
Для всіх файлів, які не "редагуються одноразово", я зберігаю свої RAW або принаймні 16-бітові TIFF, щоб вони були корисні в майбутньому.
PSD? DNG?
"Документ Photoshop" (PSD) - це формат Photoshop у форматі TIFF. Технічно він досить схожий на TIF. Є також PSB, що те саме, що стосується розмірів файлів понад 4 Гб. В цьому немає нічого поганого, але особисто я віддаю перевагу TIFF, наскільки це можливо.
"Цифровий негатив" (DNG) - це спроба створити відкритий стандарт RAW. Хоча я люблю цю ідею, і вона працює досить добре, зауважте, що деякі редактори RAW мають проблеми з ними - наприклад, Capture One зазвичай забуває баланс білого в камері, встановлюючи таким чином повзунок на 5000 К, незалежно від того, яке фактичне значення має. Інші програми в минулому показували їх як цілісні білі або рожеві зображення або надають їм пурпурний відтінок. Якщо розмір файлу не стосується вас, то ви можете включити оригінальну RAW у свій DNG - якщо вам це буде потрібно знову, ви можете просто витягнути його знову. Мої 2 копійки? Спробуйте це з улюбленим програмним забезпеченням - і якщо воно добре працює, використовуйте його.
Інші формати?
Оскільки це вже вийшло з рук, я не хотів звертатися до ще більше форматів зображень. Однак це не означає, що ті, хто не перераховані, не варто розглядати.