Memahami persyaratan memori untuk file gambar

9

Saya ingin memahami persyaratan memori untuk file sumber daya gambar yang akan ditampilkan pada layar resolusi 240x400.

Layar memiliki spesifikasi sebagai berikut:

Ini mendukung kedalaman warna hingga 18 bit dan menggunakan driver layar ILI9327.

Dengan asumsi saya perlu menampilkan 50 ikon berbeda, masing-masing berukuran 10 mm X 10 mm, berapa ruang penyimpanan yang diperlukan?

Berikut perhitungan saya:

Piksel per mm = 400 / 61.2 = 6.536

Jumlah piksel dalam satu gambar = 65,36 x 65,36 = 4272 piksel

Setiap piksel akan membutuhkan 18 bit X 3 (untuk R, G dan B) = 54 bit

Total bit yang dibutuhkan = 4272 x 54 = 230688 bit = 28,16 kilobyte

Untuk 50 gambar, saya akan membutuhkan penyimpanan 1,375 megabita.

Apakah perhitungan saya benar?

display

— Whiskeyjack
sumber

2

Anda sedang menghitung persyaratan penyimpanan tingkat atas. Biasanya gambar dikompresi, dan seringkali lebih cepat untuk membaca dan mendekompres dengan cepat (dari kartu SD) daripada membaca byte tambahan dari file yang tidak dikompresi. Ini sering karena perangkat I / O adalah hambatan.

— Kingsley

17

Piksel per mm = 400 / 61.2 = 6.536

Ya.

Jumlah piksel dalam satu gambar = 65,36 x 65,36 = 4272 piksel

Maksud Anda piksel per ikon. Namun demikian, Anda tidak dapat menghasilkan piksel fraksional, sehingga jumlah Anda harus 65 x 65 atau 66 x 66. Dan ini mengarah pada penyederhanaan lebih lanjut. Mengapa tidak membuat ikon Anda 64 x 64? Ini akan menyederhanakan perhitungan alamat untuk memori Anda, dan hanya akan menghasilkan "penyusutan" sekitar 2%. Dan percayalah, pada ukuran ini tidak ada yang akan memperhatikan. Maka ikon Anda akan berukuran 4.096 piksel.

Setiap piksel akan membutuhkan 18 bit X 3 (untuk R, G dan B) = 54 bit

Nggak. Seperti yang baru saja dijawab jms, totalnya adalah 18 bit per piksel, atau 6 bit per warna. Sekali lagi, Anda harus mempertimbangkan untuk tidak terlalu mengkhawatirkan level bit. Simpan nilai warna Anda sebagai byte parsial (6 bit per byte) dengan byte terpisah per warna. Ini akan memakan 33% lebih banyak memori, tetapi secara drastis akan mengurangi beban pemrosesan Anda saat mentransfer dari memori ke layar.

Total bit yang dibutuhkan = 4272 x 54 = 230688 bit = 28,16 kilobyte

Total bit adalah 4096 x 24, atau 98304 bit, atau 12288 byte.

Untuk 50 gambar, saya akan membutuhkan penyimpanan 1,375 megabita.

12288 kali 50 menghasilkan 614400 byte.

— WhatRoughBeast
sumber

1

Tapi tentu saja jika kita berbicara tentang penyimpanan persisten maka Anda akan menyimpan ikon Anda dikompresi sebagai milik PNG atau JPEG? Atau jika kita berbicara framebuffer maka itu hanya (display_width * display_height * bpp) / 8byte?

— Agustus

@aroth - Ini membuat Anda langsung masuk ke ranah pengorbanan. Apa yang lebih penting, ukuran memori atau tuntutan pemrosesan? Memilih gambar yang tidak terkompresi memungkinkan transfer ke layar tanpa rasa sakit dengan biaya file besar. Ini bahkan lebih mudah tanpa perlu membongkar data warna dari kata yang lebih besar. Membongkar gambar yang dikompresi dan / atau menerapkan tabel warna memungkinkan file data yang jauh lebih kecil, tetapi upaya pemrosesan dapat mengintimidasi bagi pemula. Ini semua masalah prioritas dan selera.

— WhatRoughBeast

11

Jadikan hidup sederhana untuk diri sendiri dengan membuat ikon 64 × 64 piksel. Gambar perbatasan di sekitar mereka jika Anda ingin mereka terlihat lebih besar.

Dengan format warna 16-bit, ini hanya membutuhkan 8 kB per ikon, atau 400 kB untuk set 50.

Salah satu bentuk kompresi sederhana adalah dengan menggunakan tabel warna alih-alih menyimpan warna setiap piksel secara langsung. 16 warna seringkali lebih dari cukup untuk sebuah ikon, terutama jika Anda menerapkan sedikit dithering kreatif. Ini mengurangi penyimpanan menjadi 2 kB per ikon, ditambah 32 byte untuk tabel warna. Total penyimpanan sedikit di atas 101 kB jika setiap ikon memiliki tabel warnanya sendiri.

Hanya untuk memuaskan rasa ingin tahu saya sendiri, saya mengambil gambar "kasus terburuk" berikut (dari sini ):

Baris perintah ImageMagick ini

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

mengubahnya menjadi ini:

Tidak buruk, dan tentu saja sumber gambar dengan rentang warna yang lebih terbatas akan keluar lebih baik. Misalnya, inilah Olin, diproses dengan cara yang sama:

— Dave Tweed
sumber

2

Kata kunci: warna yang diindeks . Jika misalnya 16 warna per bitmap tidak mencukupi, Anda dapat membagi ikon ke beberapa bitmap yang lebih kecil, masing-masing dengan palet yang berbeda. Menerapkan dither dapat membantu juga.

— Jms

9

Lebih lanjut tentang kedalaman warna

Memperluas jawaban Dave Tweed, Anda bisa melakukan lebih baik dari apa yang dia tunjukkan.

Ini adalah asli ukuran besar yang sama yang digunakannya:

Dipotong menjadi persegi dan menyusut menjadi 64 x 64 piksel tetapi menggunakan hasil warna penuh (8 bit per merah, grn, blu):

Membulatkan informasi warna dari 8 bit per saluran menjadi 6 bit menghasilkan:

Itulah yang dapat dilakukan layar Anda, karena Anda mengatakannya mendukung kedalaman warna 18 bit.

Membulatkan informasi warna lebih lanjut menjadi 5 bit untuk merah, 6 untuk hijau, dan 5 untuk biru, dengan total 16 bit / piksel hasil:

Ini seharusnya cukup bagus untuk ikon.

Bahkan tanpa kompresi apa pun, ikon format ini hanya membutuhkan 64 x 64 x 2 = 8192 byte. 50 gambar seperti itu akan membutuhkan 409.600 byte.

— Olin Lathrop
sumber

2

Gambar saya dikompresi menjadi 4 bit per pixel (16 warna) - 2k byte per ikon, ditambah tabel pencarian 32 byte. Saya ingin menunjukkan seperti apa dithering dengan rangkaian warna terbatas.

— Dave Tweed

Karena kita sedang membandingkan kedalaman warna yang berbeda, mau menambahkan satu dengan colormap 8-bit? Itu akan setengah (secara logaritma) antara varian 4-bit dan 16-bit yang sudah kita miliki di sini.

— ilkkachu

@ Dave: Itu tidak jelas dari jawaban Anda, tapi itu menjelaskan artefak yang meremehkan.

— Olin Lathrop

8

Setiap piksel akan membutuhkan 18 bit X 3 (untuk R, G dan B) = 54 bit

Perkiraan Anda salah. Nilai "18 bit" adalah per piksel , bukan per warna. Saluran merah, hijau dan biru masing-masing memiliki kedalaman bit maksimum 6 bit (64 nilai berbeda), total 18 bit.
Pengontrol tampilan ini juga mendukung mode 16-bit (di mana data piksel hanya memiliki 5 bit untuk merah, 6 untuk hijau dan 5 untuk biru) yang membuatnya mudah untuk mengemas setiap piksel menjadi hanya dua byte. Ini membuatnya lebih mudah untuk menyimpan bitmap secara efisien dan meningkatkan jumlah piksel yang dapat Anda tulis ke layar per detik.

Jumlah piksel dalam satu gambar = 65,36 x 65,36 = 4272 piksel

Anda tidak dapat dibilang menyimpan pecahan piksel, sehingga bitmap Anda yang sebenarnya (gambar / sprite / karakter / apapun) mungkin akan menjadi 65 ² = 4225 piksel.

Melangkah dengan mudah (format 16-bit R5G6B5 pixel), 4225 * 16 bit akan berjumlah hingga 67600 bit per bitmap, atau 8450 byte per bitmap. 50 gambar membutuhkan 423 kB (tanpa kompresi).

Jika Anda benar-benar menginginkan kedalaman warna penuh, Anda membutuhkan lebih dari 2 byte per piksel. Pada tahap itu Anda mungkin juga mencurahkan satu byte untuk setiap warna (seperti yang disarankan WhatRoughBeast), yang selanjutnya akan meningkatkan kebutuhan penyimpanan sebesar 3/2 (634 kB untuk 50 65x65 bitmap).

Anda juga dapat mengemas piksel 18-bit tepat di samping satu sama lain dalam memori (bit subpixel tidak selaras dengan batas byte), tanpa membuang bit apa pun. Anda hanya membutuhkan 476 kB untuk bitmap 18-bit 50 65x65, tetapi akan merepotkan untuk diprogram dan lebih lambat untuk diproses.

— jms
sumber