Яка межа даних стиснення без втрат? (якщо існує така межа)

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

Поки єдиним джерелом, яке я міг знайти на цю тему, була Вікіпедія:

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

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

Я не впевнений, чи хтось ще пояснив, чому магічне число здається рівним 1: 2, а не, наприклад, 1: 1,1 або 1:20.

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

Я зробив дуже простий експеримент:

• Я взяв сіру карту . Для людського ока це виглядає як звичайний нейтральний шматок сірого картону. Зокрема, інформації немає .

• І тоді я взяв звичайний сканер - саме такий пристрій, який люди можуть використовувати для оцифрування своїх фотографій.

• Я просканував сіру карту. (Насправді я просканував сіру карту разом з листівкою. Листівка була там для перевірки правильності, щоб я міг переконатися, що програмне забезпечення сканера не робить нічого дивного, наприклад, автоматично додавати контраст, коли він бачить безхарактерну сіру карту.)

• Я обрізав частину сірої картки розміром 1000x1000 пікселів і перетворив її на масштаб сірого (8 біт на піксель).

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

Однак при більшому збільшенні це насправді виглядає так:

Немає чітко видимого малюнка, але він не має рівномірного сірого кольору. Частина його, найімовірніше, викликана недосконалістю сірої картки, але я б припустив, що більшість це просто шум, що видається сканером (тепловий шум у датчику комірки, підсилювач, перетворювач A / D тощо). Схоже на гауссовий шум; ось гістограма (в логарифмічному масштабі):

Тепер, якщо припустити, що кожен піксель має свій відтінок в цьому розподілі, скільки ентропії ми маємо? Мій сценарій Python сказав мені, що у нас є 3,3 біта ентропії на піксель . І це багато шуму.

Якби це було дійсно так, то це означало б, що незалежно від того, яким алгоритмом стиснення ми користуємося, растровий малюнок 1000x1000 пікселів був би стислий, в кращому випадку, у файл 412500-байт. І що відбувається на практиці: я отримав файл PNG 432018-байт, досить близько.

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

• "корисна" інформація (якщо така є),
• шум, прибл. 3 біта на піксель.

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

Ще один приклад із спробою пошуку наддеалізованих умов:

• Сучасна камера DSLR, що використовує налаштування найнижчої чутливості (найменший шум).
• Позафокусований знімок сірої картки (навіть якщо в сірій картці була якась видима інформація, вона буде розмитою).
• Перетворення файлу RAW у 8-бітове зображення сірого масштабу, без додавання контрасту. Я використовував типові налаштування в комерційному перетворювачі RAW. Перетворювач намагається зменшити шум за замовчуванням. Більше того, ми зберігаємо кінцевий результат як 8-бітний файл - ми, по суті, викидаємо біти найнижчого порядку з неочищених показань датчика!

І який був кінцевий результат? Це виглядає набагато краще, ніж те, що я отримав від сканера; шум менш виражений, і точно нічого не видно. Тим не менш, шум Гауса є там:

А ентропія? 2,7 біт на піксель . Розмір файлу на практиці? 344923 байт для 1М пікселів. У справді найкращому випадку, з деяким обманом, ми піднесли коефіцієнт стиснення до 1: 3.

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

Ви вже знаєте про безшумну теорему кодування Шеннона ? Ця теорема встановлює теоретичні обмеження стиснення без втрат. Деякі зауваження інших, здається, припускають, що ви знаєте про цю теорему, але з питання, я думаю, це може бути відповідь, яку ви шукаєте.

$n>0$

1. $n$

2. Поширеним практичним рішенням є використання 8 біт, якщо єдиними цілими числами, які ви коли-небудь кодуєте, є всі від 1 до 256 (узагальнюйте до 16, 32 та 64 біт, якщо хочете).

3. $n+1$$n$$n$

4. $\lceil\log_2 n\rceil$$\lceil\log_2 n\rceil+1$$n$$\lceil\log_2 n\rceil-1$$\lceil\log_2 n\rceil$$2\lceil\log_2 n\rceil-1$$n$$\lg n=\max(1,\lceil\log_2 n\rceil)$

5. $2\lceil\log_2 n\rceil-1$

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

Є ціла спільнота, яка працює над складністю Колмогорова та його варіантами, а інша спільнота працює над стисненням без втрат (приклад на цілі числа, які я використав, еквівалентний для багатьох інших типів даних), я ледве подряпав поверхню, а інші можуть додати точності (Колмогоров насправді не є моєю спеціальністю), але я сподіваюся, що це може допомогти вам уточнити своє питання, якщо не обов'язково дасть вам відповідь, на яку ви сподівалися :)

(лише розширення мого коментаря)

(Як вказував Джо у своїй відповіді) Шеннон - у своїй статті 1948 р. " Математична теорія комунікації " сформулював теорію стиснення даних і встановив, що існує фундаментальний обмеження стиснення даних без втрат. Ця межа, яка називається швидкістю ентропії, позначається H. Точне значення H залежить від джерела інформації --- точніше, від статистичної природи джерела. Можна стиснути джерело без втрат зі швидкістю стиснення, близькою до H. Зробити це математично неможливо краще, ніж H.

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

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

Використовуючи "стиснення медичного зображення без втрат", я знайшов наступні статті, які можуть вам допомогти:

Нещодавнє (2011 р.) Опитування щодо методів стиснення медичних зображень: дві мірні методи стиснення медичного зображення - опитування

... У цьому документі представлений огляд різних методів стиснення на основі DCT, DWT, ROI та нейронних мереж для двомірних (2D) нерухомих зображень.

Детальна презентація двох стандартних алгоритмів стиснення без втрат: JPEG-LS та JPG2000 в режимі без втрат: Стиснення без втрат медичних зображень у відтінках сірого - Ефективність традиційних та найсучасніших підходів

... Було випробувано три тисячі, шістсот сімдесят дев'ять (3679) однокадрових зображень сірого кольору з різних анатомічних регіонів, модальностей і постачальників. ...

Ще одне опитування: опитування сучасних методик стиснення медичних зображень

EDIT

Можливо, ви все ще замислюєтесь: "Що за чорт, це ентропія зображення?" ... Гаразд, це кількість інформації, що міститься на зображенні ... але щоб краще зрозуміти, вам слід прочитати щось про 3 фази, які зазвичай використовуються при стисненні зображення :

• перетворення (наприклад, дискретна вейвлетська трансформація)
• квантування
• ентропійне кодування

Ви можете використовувати Google для пошуку підручника чи книги щодо стиснення зображень (наприклад, швидкого підручника ) або спробувати переглянути технічне відео в Інтернеті (наприклад, Лекція 16 - Введення в кодування зображень та відео ).

Подумайте про файл, як про рядок.

Ніколи не можна обійтися кращою за складність Колмогорова струною (це за визначенням складності Комогорова).

Зафіксуйте довжину рядка. Отже, зараз ми дивимося лише на рядки довжиною n.

Половину всіх таких рядків можна стиснути не більше ніж на 1 біт. 1/4 всіх рядків можна стиснути щонайбільше 2 бітами. 1/8 всіх таких рядків можна стиснути щонайбільше 3 бітами.

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

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

На перевернутому боці - сильно стискаються струни. Візьміть такий рядок: 100000..000 (за ним 1 мільйон нулів). Опис цього вмісту входить у попереднє речення, і комп'ютер міг би його реконструювати з цього опису (або одного, який він дуже любить). І все ж цей опис ніде не перевищує мільйон цифр.

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