Розуміння вимог до пам'яті для файлу зображення

9

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

Дисплей має такі характеристики:

Він підтримує до 18 біт глибини кольору і використовує драйвер дисплея ILI9327.

Якщо припустити, що мені потрібно відобразити 50 різних значків розміром 10 мм X 10 мм, який необхідний простір для зберігання?

Ось мої розрахунки:

Пікселів на мм = 400 / 61,2 = 6,536

Кількість пікселів в одному зображенні = 65,36 x 65,36 = 4272 пікселів

На кожен піксель буде потрібно 18 біт X 3 (для R, G і B) = 54 біта

Загальна кількість бітів = 4272 х 54 = 230688 біт = 28,16 кілобайт

Для 50 зображень мені буде потрібно 1,375 мегабайт пам’яті.

Чи правильний мій розрахунок?

display

— Віскі
джерело

2

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

— Кінгслі

17

Пікселів на мм = 400 / 61,2 = 6,536

Так.

Кількість пікселів в одному зображенні = 65,36 x 65,36 = 4272 пікселів

Ну, ви маєте на увазі пікселі на піктограму. Але навіть у цьому випадку ви не можете створювати дробові пікселі, тому ваше число повинно бути або 65 x 65, або 66 x 66. І це призводить до подальшого спрощення. Чому б не зробити свої іконки 64 x 64? Це спростить обчислення адреси для вашої пам’яті та призведе до «усадки» приблизно на 2%. І повірте, такого розміру ніхто не помітить. Тоді ваші значки будуть розміром 4096 пікселів.

На кожен піксель буде потрібно 18 біт X 3 (для R, G і B) = 54 біта

Ні. Як щойно відповіли jms, це 18 біт на піксель, або 6 біт на колір. Знову ж таки, вам слід подумати про те, щоб не дуже хвилюватися щодо рівня бітів. Зберігайте свої значення кольорів як часткові байти (6 біт на байт) з окремими байтами на колір. Це займе на 33% більше пам’яті, але різко скоротить завантаження вашої обробки при перенесенні з пам'яті на екран.

Загальна кількість бітів = 4272 х 54 = 230688 біт = 28,16 кілобайт

Загальна біт - 4096 х 24, або 98304 біт, або 12288 байт.

Для 50 зображень мені буде потрібно 1,375 мегабайт пам’яті.

12288 разів 50 дає 614400 байт.

— WhatRoughBeast
джерело

1

Але, звичайно, якщо ми говоримо про постійне зберігання, то ви зберігаєте свої значки, стиснуті як PNG або JPEG? Або якщо ми говоримо фреймбуфер, то це просто (display_width * display_height * bpp) / 8байти?

— aroth

@aroth - Це дозволяє вам прямо увійти до сфери компромісів. Що важливіше, об'єм пам'яті або обробка даних? Перегляд нестиснених зображень дозволяє по суті безболісно перенести на екран ціною великих файлів. Це ще простіше, не потрібно розпаковувати кольорові дані з більшого слова. Розпакування стисненого зображення та / або застосування кольорових таблиць дозволяє набагато менші файли даних, однак обробка може залякати новачка. Це все питання пріоритетів та смаку.

— WhatRoughBeast

11

Зробіть життя простим для себе, зробивши піктограми 64 × 64 пікселів. Намалюйте рамку навколо них, якщо ви хочете, щоб вони виглядали більше.

При 16-бітовому кольоровому форматі для цього знадобиться лише 8 кБ на піктограму або 400 кБ для набору 50.

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

Тільки щоб задовольнити власну цікавість, я схопив наступне «найгірше» зображення ( звідси ):

Цей командний рядок ImageMagick

convert image.jpg -crop 267x267+66+0 -resize 64x64 -colors 16 final.png

перетворив це на це:

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

— Дейв Твід
джерело

2

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

— jms

9

Детальніше про глибину кольору

Розкриваючи відповідь Дейва Твіда, ви можете зробити навіть краще, ніж те, що він показав.

Ось той самий оригінальний розмір, який він використовував:

Обрізаний, щоб бути квадратним і зменшитися до 64 x 64 пікселів, але використовуючи повний (8 біт на червоний, GRN, blu) кольоровий вихід:

Округлення кольорової інформації від 8 біт на канал до 6 біт призводить до:

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

Заокруглення інформації про колір далі до 5 біт для червоного, 6 для зеленого та 5 для синього, для загального виходу 16 біт / пікселів:

Це дійсно повинно бути досить хорошим для іконок.

Навіть без будь-якого стиснення значки цього формату займають лише 64 x 64 x 2 = 8192 байт. 50 таких зображень потребували б 409 600 байт.

— Олін Латроп
джерело

2

Моє зображення стискається до 4 біт на піксель (16 кольорів) - 2 к байтів на піктограму, плюс 32-байтна таблиця пошуку. Я хотів показати, як виглядає забарвлення з обмеженим набором кольорів.

— Дейв Твід

Оскільки ми порівнюємо різну глибину кольору, хочете додати її за допомогою 8-бітної кольорової карти? Це було б на півдорозі (логарифмічно) між 4-бітними та 16-бітовими варіантами, які ми вже маємо тут.

— ilkkachu

@Dave: Це не було зрозуміло з вашої відповіді, але це пояснює відмираючі артефакти.

— Олін Латроп

8

На кожен піксель буде потрібно 18 біт X 3 (для R, G і B) = 54 біта

Ваша оцінка неправильна. Значення "18 біт" - на піксель , а не на колір. Кожен червоний, зелений та синій канали мають максимальну глибину 6 біт (64 різних значення), загалом 18 біт.
Цей контролер дисплея також підтримує 16-бітний режим (де для піксельних даних є лише 5 біт для червоного, 6 для зеленого та 5 для синього), що дозволяє легко упакувати кожен піксель лише у два байти. Це полегшує ефективне зберігання растрових зображень і збільшує кількість пікселів, які ви можете записувати на дисплей за секунду.

Кількість пікселів в одному зображенні = 65,36 x 65,36 = 4272 пікселів

Ви не можете практично зберігати дробові пікселі, тому ваші фактичні растрові зображення (зображення / спрайти / символи / що завгодно), ймовірно, становлять 65 ² = 4225 пікселів.

Пройшовши простий шлях (16-бітний формат пікселів R5G6B5), 4225 * 16 біт складе 67600 біт на растрову карту, або 8450 байт на растрову карту. Для 50 зображень знадобиться 423 кБ (без стиснення).

Якщо вам дуже потрібна повна глибина кольору, вам потрібно більше 2 байт на піксель. На цьому етапі ви можете також виділити по одному байту для кожного кольору (як це пропонує WhatRoughBeast), що ще більше збільшить вимогу зберігання на 3/2 (634 кБ для 50 растрових карт 65 655).

Ви також можете запакувати 18-бітні пікселі безпосередньо поруч із пам’яттю (біти субпікселя, не узгоджені з межами байтів), не витрачаючи жодних бітів. Вам знадобиться лише 476 кб для 18-бітових растрових файлів розміром 50x65, але програмування буде болючим і повільніше обробляти.

— джм
джерело