Bukankah semua gambar digital pada akhirnya hanya nilai piksel antara 0 - 255?

Saya punya beberapa pertanyaan yang sangat mendasar (bodoh?) Tentang gambar; khususnya, format gambar dan nilai piksel.

Maafkan saya, saya bukan fotografer. Saya hanya seseorang yang bekerja dengan gambar, dan bagi saya, itu hanya baris dan kolom angka.

Pertanyaan saya adalah:

Jika pada intinya, foto hanyalah 3 saluran nilai piksel [0, 255] X RBG, lalu bagaimana mungkin ada perbedaan antara dua format gambar? Maksud saya, apa yang membuat RAW berbeda dari TIFF - bukankah ini semua terbatas pada nilai antara 0 - 255? Angka adalah angka - bukankah seharusnya hanya ada satu format yang ditetapkan? Atau, bukankah dua gambar dengan tinggi dan lebar yang sama harus dikunci agar memiliki ukuran file yang sama?

Selanjutnya, dari sudut pandang numerik, apa yang membuat sesuatu seperti gambar 16-bit berbeda dari gambar 32-bit? Sekali lagi, gambar hanyalah sebuah array dengan nilai integer antara 0 -255.

Melanjutkan dengan perspektif ini bahwa gambar pada sistem file komputer hanyalah array 3-channel bilangan bulat antara 0 - 255, apa gunanya mengompresi gambar ke dalam, format lossy seperti, misalnya, JPG? Katakanlah algo kompresi mengubah beberapa nilai piksel dari 254 ke 255 atau apa pun. Begitu? Bagaimana hal itu memberikan penghematan dalam ukuran file atau berdampak pada kualitas visual?

Saya tahu bahwa ada banyak cara berbeda untuk menyimpan data gambar. Tapi saya tidak bertanya tentang apa pun selain gambar RBC 3-channel dasar. Yang saya tahu adalah bahwa jika seseorang memberi saya salah satunya, saya sekarang memiliki sejumlah angka. Saya tidak punya alasan untuk tahu mengapa satu array angka mungkin bisa berbeda dari beberapa array angka lainnya dari 0 hingga 255. Saya harap ini masuk akal. Pertanyaan ini tidak terbatas pada format RAW! Sebaliknya, ini tentang array nilai piksel

Maaf, tetapi premis dasar Anda salah: gambar dapat dikodekan sebagai array piksel RBG dengan 8 bit per nilai, tetapi ada banyak cara lain:

• satu saluran dengan satu bit / saluran (hitam dan putih murni),
• satu saluran dengan x bit / saluran (format skala abu-abu, x biasanya akan menjadi 8 atau 16, memberikan nilai 256 atau 65536),
• berbagai format berbasis palet (lih. GIF)
• penuh warna dengan (setidaknya dalam teori) sebanyak saluran yang Anda inginkan dengan kedalaman bit yang diperlukan.

Dan itu untuk gambar yang disimpan dalam RAM komputer saat mengedit / melihat. Saya mengabaikan berbagai format gambar RAW yang ada (di sini dan di sisa posting ini).

Untuk fotografi , paling umum adalah 3 saluran dengan 8, 16 atau 32 bit / saluran (biasanya integer, tetapi setidaknya beberapa program bekerja secara internal dengan angka floating point 32-bit). Seringkali ada saluran ke-4 (alfa), terutama ketika program memungkinkan penggunaan lapisan. Dan di suatu tempat, dimensi array gambar perlu disimpan.

Ada berbagai alasan untuk berbagai format ini. Untuk format dalam memori, pertimbangan penting yang digunakan adalah ukuran data, dan kecepatan (lebih cepat untuk memanipulasi satu saluran 8-bit daripada 4 saluran 32-bit). Itu kurang penting saat ini, tetapi kami mendapat manajemen warna penuh dengan berbagai ruang warna. Beberapa dari mereka (mis. Prophoto RGB) membutuhkan setidaknya 16 bit / saluran untuk menjaga perbedaan antara warna tetangga yang cukup kecil untuk menghindari garis yang terlihat. Dan karena perawatan menjadi lebih rumit, ada keuntungan menggunakan angka floating point 32-bit (di mana warna dikodekan dengan nilai antara 0,0 dan 1,0, dan perawatan memungkinkan nilai menengah di luar kisaran ini).

Jika Anda ingin dapat menyimpan gambar ke file, dan memuatnya ke data dalam memori yang sama, Anda harus menggunakan setidaknya bit per saluran sebagai format memori-im, dan Anda harus menyimpan informasi tentang dimensi gambar, kedalaman bit dan ruang warna.

Pengguna gambar-gambar itu juga suka menyimpan beberapa informasi tambahan tentang gambar (keterangan, judul, siapa yang mengambil gambar, dll ...). Lagi-lagi berbagai cara untuk menyimpan informasi ini.

Lalu ada berbagai cara mengompresi data gambar untuk penyimpanan file. Salah satu yang lebih sederhana adalah RLE (Run Length Encoding), tempat Anda menyimpan nilai hitungan dan piksel setiap kali Anda menjumpai nilai piksel berulang. Lainnya, seperti jpeg, jauh lebih rumit, tetapi juga memberikan lebih banyak kompresi. Misalnya jpeg menggunakan transformasi kosinus, dan membuang informasi frekuensi tinggi (kurang terlihat), memberikan tingkat kompresi yang tinggi dengan biaya kehilangan informasi (ada lebih banyak untuk itu, tetapi ini menjadi terlalu lama seperti itu).

Ini sudah memberi banyak cara untuk menyimpan informasi pada disk, tetapi apa pun cara Anda memilih, formatnya harus ditentukan dengan baik untuk memungkinkan interpretasi yang benar tentang memuat gambar.

Lalu ada pengembangan konstan dalam mis. Teknik kompresi lossless, yang formatnya tidak selalu bisa menangani.

Jadi kita berakhir dengan berbagai format file, dengan berbagai trade-off antara kesetiaan informasi yang tersimpan, ruang disk yang ditempati dan kecepatan membaca, menulis dan mentransmisikan (bandingkan ukuran TIFF yang tidak dikompresi dan jpg kualitas yang layak) .

Jika Anda ditangani gambar dalam memori, itu akan dalam bentuk satu atau lebih array. Pada saat itu, format file asli seharusnya tidak lagi berperan . Saya akan menganggap Anda menangani data Anda dengan 8 bit / saluran.

Tetapi Anda harus tahu apakah Anda memiliki gambar yang diproses atau gambar mentah, karena ada dua perbedaan penting di antara mereka:

• gambar mentah biasanya memiliki 1 warna per piksel , dan piksel biasanya diatur dalam array Bayer dengan 2 piksel hijau, 1 merah dan 1 piksel biru per kuadrat dari 4 piksel. Nilainya proporsional dengan intensitas adegan (kecuali nilai yang sangat rendah dan sangat tinggi).
• gambar yang diproses dapat disusun sebagai array rekaman 2D yang berisi 3 nilai numerik, atau sebagai bidang warna (3 array 2D, satu untuk masing-masing R, G, B). Selain itu, nilainya biasanya tidak sebanding dengan intensitas adegan . Lebih buruk lagi, hubungan yang tepat antara nilai piksel dan intensitas adegan tergantung pada pemrosesan gambar yang dimiliki. Dan keseimbangan antara warna telah disesuaikan agar sesuai dengan respons mata manusia (Keseimbangan Putih, merah dan biru diperbesar relatif terhadap hijau).

Jadi, jika Anda mendapatkan gambar mentah dengan 3 nilai warna per piksel, gambar mentah itu telah memiliki beberapa perawatan (setidaknya baik demosaicing , atau binning sederhana 4 piksel mentah menjadi 1 piksel gambar). Apakah itu dapat diterima, akan tergantung pada aplikasi Anda.

Jika pada intinya, foto hanyalah 3 saluran nilai piksel [0, 255] X RBG,

Tetapi foto bukan "hanya 3 saluran nilai piksel" bahkan "pada intinya." Layar komputer biasanya terdiri dari array RGB piksel, jadi jika Anda ingin menampilkan gambar pada layar komputer Anda harus, di beberapa titik, peta data gambar apa pun yang Anda miliki ke array RGB piksel, tapi itu data hanya render tertentu dari data gambar. Data dalam gambar mungkin tidak terdiri dari aliran nilai piksel sama sekali. Untuk mendapatkan nilai piksel dari suatu gambar, Anda harus tahu bagaimana cara data diformat.

lalu bagaimana mungkin ada perbedaan antara dua format gambar? Maksud saya, apa yang membuat RAW berbeda dari TIFF - bukankah ini semua terbatas pada nilai antara 0 - 255?

Itu adalah dua contoh yang baik, karena tidak satu pun dari format tersebut yang memiliki array nilai RGB.

RAW bukan format tunggal sama sekali - ini semacam nama catch-all untuk file yang berisi data yang direkam langsung dari sensor gambar. Jadi, file RAW mungkin berisi urutan nilai yang mewakili voltase yang dibaca dari berbagai situs sensor. Situs-situs itu seperti piksel gambar, tetapi bukan piksel RGB. Untuk mendapatkan piksel RGB dari file RAW, Anda harus menginterpretasikan data tersebut dalam konteks informasi tentang sensor, pengaturan kamera pada saat itu, dll. Dengan kata lain, Anda dapat membuka file RAW dalam hex editor dan lihat semua yang Anda inginkan, tetapi Anda tidak akan menemukan nilai RGB tunggal.

TIFF adalah singkatan dari format file gambar yang ditandai , dan ini adalah format yang sangat menarik karena dapat berisi banyak representasi berbeda dari suatu gambar. File TIFF tunggal dapat berisi gambar "sama" dalam beberapa ukuran, seperti thumbnail, gambar resolusi layar, dan gambar resolusi cetak, dan mungkin juga memiliki versi warna dan skala abu-abu. Tahukah Anda bahwa mesin faks biasanya mengirim data mereka sebagai file TIFF? Untuk mendapatkan piksel RGB dari file TIFF, Anda perlu memahami tidak hanya format TIFF, tetapi juga format representasi gambar tertentu dalam file tersebut.

Angka adalah angka - bukankah seharusnya hanya ada satu format yang ditetapkan?

Tidak. Ada banyak format gambar yang berbeda karena masing-masing orang melayani kebutuhan yang berbeda. Kompresi JPEG yang hilang sangat bagus untuk mendapatkan file gambar yang sangat kecil, tetapi itu tidak baik untuk gambar yang harus diedit beberapa kali. Beberapa format menggunakan interlacing , yang membuatnya sangat cepat untuk membaca gambar pada beberapa resolusi berbeda. Dan seterusnya ... setiap format menawarkan campuran keuntungan dan kompromi sendiri.

Atau, bukankah dua gambar dengan tinggi dan lebar yang sama harus dikunci agar memiliki ukuran file yang sama?

Tidak, itu akan mengerikan. Jika ukuran setiap file gambar pada dasarnya width * height * 3(dengan asumsi warna 24-bit), maka Anda akan menghabiskan banyak ruang penyimpanan. Sebagian besar foto mengandung banyak redundansi, yaitu daerah di mana warna yang sama diulang berkali-kali. Untuk menghemat ruang penyimpanan, seringkali masuk akal untuk menghilangkan informasi yang berlebihan itu. Salah satu cara untuk melakukan itu, misalnya, menjalankan pengkodean panjang, atau RLE. Misalnya, jika Anda memiliki wilayah 4195 piksel berurutan yang semuanya berwarna putih, akan jauh lebih efisien untuk menyandikan bahwa "4195 piksel berikutnya semuanya {255, 255, 255}" daripada hanya menyimpan banyak piksel putih dalam berkas. RLE sebenarnya digunakan dalam beberapa format gambar, tetapi banyak format memiliki skema yang jauh lebih canggih yang menghemat lebih banyak ruang, dan itu berarti Anda dapat menyimpan lebih banyak gambar pada hard drive atau kartu memori. Ini juga membuatnya lebih cepat untuk mengirim gambar ke orang lain.

Melanjutkan dengan perspektif ini bahwa gambar pada sistem file komputer hanyalah array 3-channel bilangan bulat antara 0 - 255, apa gunanya mengompresi gambar ke dalam, format lossy seperti, misalnya, JPG?

Intinya adalah itu membuat file jauh lebih kecil. Kompresi JPEG sering mengurangi ukuran file dengan faktor 10 atau lebih. Itu berarti Anda dapat memuat lebih banyak gambar pada perangkat penyimpanan yang diberikan, Anda dapat menyalinnya lebih cepat, Anda dapat membukanya lebih cepat, dan Anda dapat mengunggah dan mengunduhnya lebih cepat. Menyimpan gambar yang sama (atau hampir seperti itu) di ruang yang jauh lebih kecil menggunakan sumber daya lebih efisien, dan karenanya mengurangi biaya. Pikirkan hal itu dalam skala besar: kemungkinan persentase yang sangat besar dari informasi yang tersedia di Internet terdiri dari gambar dan film, dan tanpa kompresi kita membutuhkan lebih banyak pusat data yang lebih besar dan mengkonsumsi lebih banyak energi.

Katakanlah algo kompresi mengubah beberapa nilai piksel dari 254 ke 255 atau apa pun. Begitu? Bagaimana hal itu memberikan penghematan dalam ukuran file atau berdampak pada kualitas visual?

Pertimbangkan contoh RLE saya di atas. Katakanlah Anda memiliki foto yang menyertakan dinding kosong besar, sehingga area besar foto Anda semuanya berwarna sama, kecuali ada hamburan piksel yang sedikit lebih gelap, bahkan nyaris tidak terlihat dalam gambar. Piksel tersebut mengurangi efektivitas kompresi. Alih-alih hanya bisa mengatakan "500.000 piksel berikutnya semuanya {243, 251, 227}," Anda harus menjalankan panjang kode lebih banyak potongan yang jauh lebih kecil, karena sering kali Anda mengalami salah satu piksel yang sedikit berbeda. Jika Anda mengizinkan algoritma kompresi melakukan perubahan kecil, mungkin hanya mengubah piksel apa pun dengan tidak lebih dari 1% atau 2%, maka Anda bisa mendapatkan rasio kompresi yang jauh lebih tinggi tanpa mengubah gambar secara jelas. Pertukaran: Anda kembali sedikit informasi dalam gambar asli dengan imbalan pengurangan besar dalam ukuran file. Tepat di mana Anda ingin menggambar garis itu dapat berubah, sehingga format lossy seperti JPEG memungkinkan pengguna memilih tingkat kompresi yang diinginkannya.

Selain jawaban fantastis @ remco , saya ingin menambahkan mengapa ada codec yang berbeda untuk (kira-kira) tujuan yang sama.

Codec dirancang untuk:

• Jadilah lossless vs lossy
• Mengkodekan dengan cepat vs. mengurangi ukuran file
• En- / decoding asimetris vs. Simetris
• Kompatibel dengan perangkat lunak
• Secara persepsi, hampir tanpa kehilangan dalam berbagai level / situasi kompresi
• Memiliki fitur yang tidak ditawarkan oleh codec lain, termasuk:
  • bebas royalti
  • dukungan untuk lapisan
  • dukungan untuk alpha-channel (mis RGBA) / transparansi
  • menawarkan tampilan web cepat
  • mendukung kedalaman bit tinggi
  • mendukung banyak ruang warna (RGB / CMYK)
  • dukungan untuk metadata / versi / ...

Beberapa hal itu saling eksklusif. Dan karena itu, kita dibiarkan dengan banyak codec.

Beberapa contoh

Catatan: Tidak ada daftar codec yang lengkap, juga tidak semua fitur mereka (atau kekurangannya) disebutkan. Jika jawaban ini terbukti bermanfaat bagi seseorang, saya mungkin menambahkan beberapa informasi lebih banyak (dan sedikit lebih tepat).

Mungkin format yang paling dikenal adalah JPEG . Ini adalah format yang sangat luas didukung, tetapi lama. Ia menggunakan DCT (Discrete Cosine Transformation), jadi meskipun ia menawarkan kualitas yang cukup baik pada pengaturan kualitas tertinggi, pemblokiran akan muncul dengan yang lebih rendah.

Kemudian JPEG 2000 datang untuk menggantikan JPEG: Itu didasarkan pada Wavelet-Transformation, jadi sementara itu menawarkan kualitas yang kira-kira sama dengan JPEG dalam pengaturan kualitas yang lebih tinggi, ia menawarkan kualitas yang jauh lebih baik dalam pengaturan kualitas yang lebih rendah (blok agak buram ). Juga, JPEG 2000 menawarkan wilayah yang menarik (kualitas tinggi di satu area gambar, kualitas lebih rendah di tempat lain) dan dukungan 16bit. (Juga, beberapa hal lain.) Sayangnya (?), Karena lebih mahal komputasi daripada JPEG dan karena beberapa masalah perizinan, JPEG 2000 tidak didukung secara luas seperti JPEG.

PNG adalah format lain yang dikenal luas - itu lossless dan mendukung saluran alpha, tetapi tidak menawarkan dukungan untuk ruang warna non-RGB (seperti CMYK). Oleh karena itu, ini adalah format "online saja".

Lalu ada format VFX seperti OpenEXR . Mereka semua berputar di sekitar kualitas dan kecepatan: OpenEXR adalah lossless, mendukung hingga 64bit, dan mengkodekan / mendekode dengan cepat. Ini terutama digunakan dalam industri VFX sebagai format perantara.

TIFF adalah format lossless lain yang cukup populer di kalangan fotografer. Untuk kompresi, ia tidak menawarkan / ZIP / RLE / LZW / JPEG. Ini mendukung hingga 32bit. Dengan kompresi yang dapat dipilih, ini cukup adaptif, namun karena losslessness, ini lebih merupakan format offline.

HEIF adalah salah satu codec gambar terbaru. Ia menggunakan kompresi yang sama seperti HEVC / h.265 dan karenanya diharapkan untuk memberikan rasio kompresi yang lebih baik daripada JPEG. Namun, karena cukup baru dan karena itu tunduk pada paten, tidak seperti luas didukung sebagai salah satu di atas.

Gambar RAW ^{Lihat juga} bukan gambar nyata, sungguh: Mereka lebih merupakan wadah untuk data pembacaan sensor mentah (karena namanya). Hanya dengan perangkat lunak yang tahu bagaimana menafsirkan data, dimungkinkan untuk mendapatkan gambar. Itu juga sebabnya konverter RAW seperti Lightroom / Capture One / DarkTable / ... perlu pembaruan untuk mendukung kamera baru yang menggunakan wadah yang sudah ditentukan seperti * .CR2 untuk Canon. Ini juga merupakan alasan mengapa RAW 14bit menawarkan lebih banyak opsi pengeditan daripada TIFF 32bit yang Anda ekspor dari RAW yang sama.

Intermisision: Lossless vs lossy

Saya masih tidak yakin apa yang sebenarnya Anda tanyakan, jadi saya pikir tidak ada salahnya untuk menambahkan sedikit penjelasan tentang lossless vs lossy.

Kompresi lossless bekerja dengan melakukan pengkodean run-length (RLE) / Huffman coding / ... untuk mengompres data. Data itu sendiri tidak diubah, tetapi disimpan dalam paket yang lebih kecil. Sebagai contoh, ambil RLE: Katakanlah, kami memiliki bitstream R-channel (dari pixel 0,0ke pixel 0,11) dari 255,255,255,255,255,215,215,235,100,000,000,000- RLE akan mengkodekan ini sebagai 52552215123511003000- ini jauh lebih kecil, dan karena kita tahu bahwa itu disimpan dalam kelompok 4 digit dan bahwa digit pertama adalah penghitung dan tiga digit terakhir adalah nilainya, maka kita dapat merekonstruksi penuh 255,255,255,255,255,215,215,235,100,000,000,000.

Kompresi lossy , di sisi lain, mencoba untuk kompres lebih jauh daripada lossless dapat dilakukan. Untuk melakukan ini, codec lossy biasanya mencoba untuk menghapus hal-hal yang tidak didapat persepsi kita. Ambil, misalnya, YUV( YCbCr, benar-benar) Model JPEG (dan hampir setiap video codec) kegunaan: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Manusia tidak dapat melihat perbedaan antara 4:2:0(setiap pixel memiliki nilai luminance, tetapi warna disimpan dalam blok 2x2 secara bergantian) dan gambar 4:4:4(setiap pixel memiliki luminance dan kedua saluran warna) dikodekan. Ini disebabkan oleh fisiologi mata kita : Kita tidak dapat melihat perbedaan warna dan juga kita dapat melihat perbedaan dalam pencahayaan.

Ini berfungsi dengan baik sebagian besar waktu, tetapi bandingkan dengan file MP3: Hampir tidak ada yang bisa membuat perbedaan antara 192kbps dan 320kbps, tetapi pergi di bawah 64kbps dan semuanya menjadi jelek dengan cepat. Selain itu, pengkodean ulang akan semakin mengurangi kualitas, karena artefak yang tidak diinginkan mungkin muncul (misalnya dalam JPEG, blok kecil dari pengkodean berkualitas tinggi akan dianggap sebagai detail gambar dalam pengkodean lebih lanjut).

Intinya

Jika Anda tidak peduli dengan format gambar atau fitur-fiturnya, salah satunya akan baik-baik saja. Dengan pengaturan kualitas yang cukup tinggi, dimungkinkan dan diharapkan bahwa Anda bahkan tidak akan melihat perbedaan di antara mereka.

Namun, jika Anda memerlukan fitur spesifik, mungkin ada (dan hampir pasti: akan) ada codec yang dicakup.

Jika pada intinya, foto hanyalah 3 saluran nilai piksel [0, 255] X RBG

Itu adalah asumsi yang rusak parah dan sisa pertanyaan Anda sama sekali tidak dapat dijawab tanpa melepaskan diri darinya.

Maksud saya, apa yang membuat RAW berbeda dari TIFF - bukankah ini semua terbatas pada nilai antara 0 - 255?

Istilah "mentah" dapat merujuk pada dua hal yang berbeda, gambar "kamera mentah" atau file yang berisi data gambar mentah tanpa header.

Gambar "kamera mentah" menyimpan data mentah saat keluar dari sensor. Sebagian besar sensor kamera modern memiliki ADC dengan lebih dari 8 bit, tetapi mereka juga hanya mengumpulkan data intensitas untuk satu komponen warna di setiap lokasi. Geometri dapat terdistorsi oleh lensa, nilai-nilai intensitas dari ADC mungkin tidak berfungsi dengan baik dalam mencerminkan persepsi intensitas manusia, komponen-komponen warna mungkin tidak memetakan secara tepat dengan yang digunakan oleh monitor Anda dan sebagainya.

Proses pemetaan rumit yang melibatkan interpolasi diperlukan untuk mengubah data sensor mentah menjadi gambar RGB berkualitas baik dan tidak ada cara yang benar untuk melakukannya. Selain itu karena kebutuhan untuk menginterpolasi komponen warna, gambar RGB mungkin berakhir lebih besar dari data mentah.

Konversi dapat (dan sering) dilakukan di kamera, tetapi banyak fotografer meminta untuk menyimpan data mentah sehingga mereka dapat mengubah proses setelah fakta.

Tiff adalah format file kompleks yang dapat menyimpan gambar dalam berbagai format berbeda dengan beragam metadata. Dalam prakteknya meskipun biasanya digunakan untuk menyimpan gambar RGB atau CMYK tanpa kompresi atau tanpa kompresi.

File yang berisi data gambar mentah tanpa header jarang digunakan karena Anda harus mengetahui format dan dimensinya sebelum dapat membacanya. Beberapa alat pengolah gambar mendukungnya.

Selanjutnya, dari sudut pandang numerik, apa yang membuat sesuatu seperti gambar 16-bit berbeda dari gambar 32-bit?

Sayangnya "n bit" dapat berarti dua hal yang berbeda. Ini dapat berarti bahwa semua komponen warna dijejalkan ke dalam jumlah bit (misalnya 5 bit untuk merah, 5 bit untuk biru dan 6 bit untuk hijau untuk 16 bit atau 8 bit merah, 8 bit hijau, 8 bit biru dan 8 bit alpha untuk 32 bit) atau di dapat berarti bahwa setiap komponen warna memiliki n bit informasi di setiap lokasi piksel.

Melanjutkan dengan perspektif ini bahwa gambar pada sistem file komputer hanyalah array 3-channel bilangan bulat antara 0 - 255

Sekali lagi perspektif ini benar-benar salah.

File adalah urutan byte, tetapi byte itu hampir tidak pernah "hanya array 3-channel bilangan bulat antara 0 - 255"

Anda bisa menyimpan gambar seperti itu. Beberapa alat bahkan mendukung membaca dan menulis file seperti itu tetapi masalahnya adalah itu berarti Anda harus tahu tentang file tersebut sebelum Anda dapat membacanya. Misalkan Anda memiliki file berukuran 3000 byte, apakah Anda memiliki 1000 piksel RGB 24 bit? 3000 8 bit piksel abu-abu? 3000 8 bit piksel dari palet? Apa urutan komponen warna? apa bentuk gambarnya? Apakah komponen warna dalam urutan RGB atau BGR? Kecuali Anda tahu jawaban atas pertanyaan-pertanyaan ini, Anda tidak dapat membaca file seperti itu secara berarti.

Jadi format gambar praktis biasanya dimulai dengan satu atau lebih header yang mengidentifikasi jenis file, dimensi gambar dan bagaimana data gambar yang sebenarnya disimpan. Mereka juga mungkin mengandung metadata opsional.

apa gunanya mengompresi gambar ke dalam, format lossy seperti, misalnya, JPG? Katakanlah algo kompresi mengubah beberapa nilai piksel dari 254 ke 255 atau apa pun. Begitu? Bagaimana hal itu memberikan penghematan dalam ukuran file atau berdampak pada kualitas visual?

Algoritma kompresi tidak hanya "mengubah nilai", mereka menyandikan informasi dengan cara yang sama sekali berbeda, misalnya JPEG dapat secara kasar digambarkan sebagai

• Konversi data dari RGB ke YUV
• (opsional) mengurangi resolusi saluran chroma dengan faktor 2 dalam satu atau kedua dimensi
• Membagi data untuk setiap saluran menjadi 8x8 blok.
• Konversi blok ke domain frekuensi menggunakan transformasi cosinus diskrit
• Kuantisasi hasilnya, pertahankan informasi frekuensi rendah sambil mengurangi ketepatan informasi frekuensi tinggi.
• Mengkodekan angka-angka yang dihasilkan sebagai urutan byte menggunakan skema pengkodean panjang variabel (baik huffman coding atau arithmetic coding)
• Simpan byte tersebut di file bersama dengan header yang sesuai.

Sebaliknya, format yang dikompresi tanpa kehilangan sering kali dibangun di atas algoritma kompresi data tujuan umum tetapi kadang-kadang melengkapi dengan pra-pemrosesan khusus gambar, misalnya PNG.

• Konversi data ke salah satu format yang didukung (misalnya masing-masing bit untuk Merah, hijau dan biru dalam urutan itu)
• Untuk setiap baris gambar melakukan proses "pemfilteran", ada opsi pemfilteran serveral (termasuk tidak ada pemfilteran sama sekali), tetapi tujuan umumnya adalah untuk mengambil informasi khusus gambar yang pikselnya cenderung mirip dengan tetangganya dan menyandikannya itu dengan cara yang "mengempis" dapat menangani.
• Kompres data yang difilter menggunakan algoritma kompresi tujuan umum "deflate".
• Simpan byte tersebut di file bersama dengan header yang sesuai.

Ada beberapa alasan mengapa asumsi ini tidak benar, dan semuanya berujung pada satu hal:

Skala apa yang sebenarnya Anda gunakan?

Dan itu dapat dipecah sedikit lebih jauh:

Apa itu 255?

"Warna" bukan properti alam semesta fisik. Itu adalah sensasi yang muncul dalam pikiran. Dan, itu termasuk hal-hal seperti "biru", "hijau", dan "merah". Skala dari 0 yang berarti "sama sekali tidak biru" hingga 255 yang berarti "semua biru!" tidak dapat benar-benar memiliki 255 mewakili cita-cita biru platonis , karena ... tidak ada hal yang sempurna di dunia nyata. Jadi, apakah ini berarti:

• jenis hal paling biru yang bisa Anda buat di perangkat di depan Anda?
• sedekat mungkin dengan pencocokan warna biru murni dari sudut pandang sistem penglihatan manusia, bahkan jika sebagian besar layar dan kombinasi printer / tinta / kertas tidak dapat mewakili itu?
• warna biru yang cukup bagus yang cenderung terwakili secara wajar di berbagai perangkat?
• biru yang berada di luar jangkauan penglihatan manusia, tetapi yang memungkinkan RGB Anda menutupi sebagian besar warna yang berada dalam jangkauan?

Terdengar dibuat-buat? Nggak! Ini sebenarnya contoh nyata . Lihatlah representasi masing-masing pilihan ini. Area melengkung adalah irisan 2D dari ruang warna penglihatan manusia, dan segitiga menunjukkan area yang dapat direpresentasikan dengan pilihan khusus untuk merah, hijau, atau biru.

Pertama, inilah profil untuk layar laptop saya, yang cukup mewakili perangkat kelas menengah saat ini:

Sekarang, ini ruang Adobe RGB. Perhatikan betapa jauh lebih besar dari ini yang dapat ditampilkan layar saya!

Jadi, inilah sRGB - standar de facto dan ruang default biasanya diasumsikan ketika tidak ada yang ditentukan. Itu dimaksudkan untuk menjadi "cukup baik" dalam kebanyakan situasi.

Dan akhirnya, ProPhoto RGB, yang menggunakan warna imajiner sebagai pendahuluan, untuk membuat segitiga cukup besar agar sesuai dengan hampir semua penglihatan manusia.

Sekarang berikan warna cahaya itu sendiri, dan adaptasi berwarna - kemampuan sistem visi manusia untuk menyesuaikan persepsi dengan lingkungan. Padahal, bukan sekadar kemampuan: hal yang terjadi baik Anda mau atau tidak . Apakah "biru murni" berarti benda itu tampak biru seperti mungkin di bawah cahaya pijar ini? Apa nilainya jika kita memotret di bawah sinar matahari?

Jadi "255" dapat berarti banyak hal yang berbeda.

Apa itu 0?

Ini cukup sederhana - seberapa hitam Anda perlu 0? Apakah vantablack hitam? Jika ya, tetapi semua warna aktual dalam adegan Anda jauh lebih tidak ekstrem , apakah Anda benar-benar ingin "membuang" banyak nilai potensial untuk rentang dinamis yang tidak ada dalam adegan Anda - dan yang, seperti warna, dapat bahkan dapat diwakili oleh perangkat atau printer yang Anda akses?

Apa lekuk tubuhmu?

Jadi, begitu Anda memiliki titik akhir, bagaimana Anda bisa berpindah dari satu ke yang lain? Persepsi kecerahan manusia jelas non-linear . Dalam skala 0-255 Anda, apakah 100 harus dua kali lebih terang dari 50, atau haruskah itu menjadi faktor yang lebih besar? Haruskah perbedaan persepsi antara, katakanlah, 3 dan 4 sama dengan perbedaan antara 203 dan 204?

Jika Anda memutuskan untuk menggunakan sistem penyimpanan log, haruskah kurva itu dioptimalkan agar sesuai dengan visi manusia, atau untuk optimasi data, atau untuk hal lain?

Ada banyak kemungkinan, untuk berbagai kebutuhan.

Pada kompresi

Anda bertanya.

Katakanlah algo kompresi mengubah beberapa nilai piksel dari 254 ke 255 atau apa pun. Begitu? Bagaimana hal itu memberikan penghematan dalam ukuran file atau berdampak pada kualitas visual?

Algoritma kompresi modern lebih rumit dari ini, tetapi ini memberikan contoh yang baik. Saya akan menggunakan hexadecimal FFuntuk mewakili 255 dan FEuntuk mewakili 254, dan bayangkan kita menggunakan pengkodean run length sebagai bentuk kompresi. Dan untuk kesederhanaan, mari kita asumsikan hitam dan putih, bukan warna. Dengan itu, jika kita memiliki deretan data yang terlihat seperti ini:

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

kita bisa mengompresnya menjadi sangat sederhana

16×FF 

... yang merupakan penghematan yang cukup jelas. Kami pada dasarnya dapat menyimpan 16 byte dalam dua (satu untuk hitungan, dua untuk data). Tetapi katakanlah kita memiliki:

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

Sekarang, enkode run-length memberi kita:

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

... yang tidak ada penghematan sama sekali, dan sebenarnya bisa meningkatkan ukuran file. Tetapi jika kita membulatkan semua FEnilai FF, kita kembali ke kasus pertama, dengan pengurangan ukuran yang signifikan, dengan dampak kecil tapi mungkin sulit untuk diperhatikan pada kualitas file.

Tentu saja itu adalah contoh yang sepele dan dibuat-buat, tetapi semua algoritma kompresi lossy berbagi sifat dasar ini: hilangnya data membuatnya lebih mudah untuk menggunakan format penyimpanan yang lebih kompak, dengan, mudah-mudahan, tidak terlalu banyak perubahan yang dirasakan .

Pada kedalaman bit

Selanjutnya, dari sudut pandang numerik, apa yang membuat sesuatu seperti gambar 16-bit berbeda dari gambar 32-bit? Sekali lagi, gambar hanyalah sebuah array dengan nilai integer antara 0-255.

Jadi ..... array nilai integer antara 0-255 adalah array delapan bit . (2⁸ = 256.) Dengan tiga saluran, ini adalah gambar 24-bit; beberapa format memiliki saluran transparansi ("alpha") juga, untuk 32 bit. Satu juga dapat menggunakan nilai yang lebih tinggi per saluran, yang biasanya apa yang kita maksud ketika kita mengatakan "kedalaman 16 bit". Itu berarti array berjalan dari 0-65535 (2¹⁶ = 65536) daripada 0-255. Umumnya dalam skema seperti ini, ini pada dasarnya hanya pengganda di mana nilai tertinggi mewakili hal yang sama pada setiap skala, tetapi kedalaman bit yang lebih tinggi memberikan nuansa yang lebih mungkin. (Lihat jawaban ini untuk lebih lanjut tentang ini.) Ada juga beberapa format file khusus yang menggunakan floats 64-bit (!) Alih-alih bilangan bulat untuk nilai-nilai, atau tipe data lain tergantung pada use case, tetapi konsep dasarnya sama .

Tidak, gambar bukan hanya nilai RGB di kisaran 0-255. Bahkan jika Anda mengabaikan format penyimpanan, ada banyak cara untuk menggambarkan warna. Berikut ini beberapa contohnya:

• Komponen merah, hijau dan biru (RGB)
• Komponen sian, magenta, kuning dan hitam (CMYK)
• Hue, saturasi dan ringan / nilai (HSL / HSV)
• Jumlah cahaya yang mengenai sekelompok sensor di kamera
• Jumlah cahaya dan arahnya ketika mengenai sensor (dalam kamera medan cahaya )

Dua yang pertama adalah yang paling umum digunakan untuk ditampilkan pada monitor dan untuk pencetakan.

Selain itu, gambar tidak hanya piksel, tetapi juga metadata. Bisa jadi hal-hal seperti lebar dalam jumlah piksel, lebar fisik jika Anda mencetaknya, gambar mini , atau bahkan lokasi geografis kamera ketika gambar diambil.

Premis Anda tidak salah: gambar apa pun dapat diwakili menggunakan array nilai dimensi hingga N-dimensi. Secara pribadi, saya menggeneralisasi bahwa menggunakan geometri diskrit bukan matriks, tetapi esensinya sama. Tapi itu isinya, bukan file.

Namun, format file berbeda. Pada dasarnya, ada beberapa cara berbeda untuk merepresentasikan gambar yang sama, seperti yang disebutkan orang: bmp, png, jpg, dll. Tentu saja, begitu Anda mendekodekannya, dua versi yang dikodekan lossless dari gambar yang sama akan mengarah ke matriks yang sama.
Anggap saja sebagai file .txt yang Anda kompres dengan zip. Dengan ditambahkan keanehan bahwa pengkodean non-lossless akan mengembalikan teks yang tidak sama dengan aslinya, tetapi sangat dekat, hampir seperti versi teks yang bodoh.

Tetap dengan analogi teks, katakanlah Anda memiliki teks yang sama, disimpan sebagai .txt, .docx, .pdf, dll. Mengapa tidak semua file persis sama, jika kontennya sama? (Ok, txt tidak memiliki format, tetapi yang lain melakukannya).

Omong-omong, periksa bagaimana pengkodean Netpbm benar-benar berbeda dari JPEG .

Untuk format RAW dan TIFF, sejauh yang saya tahu, jawabannya (seperti yang dikatakan orang lain) adalah bahwa mereka tidak selalu selalu menggunakan ruang warna yang sama (misalnya file RAW mungkin menggunakan lebih banyak bit per piksel sehingga dapat menyimpan informasi warna yang lebih baik) .

Tetapi untuk sampai pada inti pertanyaan Anda - terkadang ada gambar yang disimpan dalam format yang berbeda, tetapi masing-masing pada akhirnya mewakili susunan angka yang persis sama.

Contoh yang bagus untuk alasan ini adalah perbedaan dalam kompresi antara file PNG dan file TIFF.

File PNG menggunakan satu algoritma kompresi tertentu. Itu berarti gambar tidak hanya disimpan sebagai daftar besar angka untuk setiap piksel. Contoh sederhana: mungkin menyimpan sesuatu yang mengatakan "dalam blok 10x10 piksel ini, semua piksel berwarna XYZ". Kemudian alih-alih menyimpan informasi itu 100 kali lebih banyak, ia menyimpannya sekali, ditambah sedikit informasi tentang wilayah di mana informasi itu berlaku.

Masalahnya adalah untuk mendapatkan kembali array angka asli (mewakili warna), sehingga Anda dapat menunjukkan atau mengeditnya atau apa pun, Anda memerlukan perangkat lunak yang tahu bagaimana menafsirkan informasi terkompresi itu.

File PNG selalu menggunakan algoritma kompresi yang sama, sehingga mudah bagi perangkat lunak untuk mendukung semua file PNG yang valid. Di sisi lain, beberapa gambar memiliki struktur yang tidak cocok dengan algoritma kompresi PNG, sehingga beberapa file PNG Anda mungkin berakhir menjadi cukup besar.

File TIFF, di sisi lain, mendukung banyak algoritma kompresi yang berbeda. Bahkan, ia bahkan dapat menyimpan bagian-bagian berbeda dari gambar yang dikompres secara berbeda. DAN itu mendukung 'ekstensi', sehingga Anda dapat mengompres gambar menggunakan cara milik. Jadi mungkin setengah bagian atas gambar Anda akan dikompres menggunakan metode yang mirip dengan PNG, tetapi ini tidak akan mengkompres bagian bawah dengan sangat baik, sehingga bagian bawah dikompresi menggunakan metode yang berbeda.

Jadi file TIFF lebih fleksibel - Anda mungkin dapat menyimpan array angka yang sama persis menggunakan lebih sedikit byte. Tetapi perangkat lunak yang diperlukan untuk memecahkan kode gambar akan lebih rumit, dan mungkin tidak bekerja secara konsisten dengan setiap file TIFF yang Anda lemparkan, misalnya Anda mungkin menyimpan file TIFF dalam satu perangkat lunak dan tidak dapat membukanya menggunakan perangkat lunak yang berbeda, meskipun itu masih bekerja di aslinya.

Jadi kamu bertanya

Tapi saya tidak bertanya tentang apa pun selain gambar RBC 3-channel dasar. Yang saya tahu adalah bahwa jika seseorang memberi saya salah satunya, saya sekarang memiliki sejumlah angka. Saya tidak punya alasan untuk tahu mengapa satu array angka mungkin berbeda dari beberapa array angka lainnya dari 0 hingga 255.

Untuk memberikannya kepada Anda, seseorang harus tahu bagaimana gambar itu disimpan dan bagaimana menerjemahkannya ke dalam array angka. (Atau mungkin beberapa perangkat lunak melakukan terjemahan untuk Anda tanpa sepengetahuan Anda).

Anda dapat mencoba menyimpan gambar sebagai PNG dan lagi sebagai TIFF atau GIF dan melihatnya dalam penampil heksadesimal untuk melihat bagaimana mereka masing-masing mewakili array angka yang sama secara berbeda. Atau bacalah perincian tentang bagaimana file PNG dan file TIFF diwakili secara internal untuk memberi Anda gambaran tentang apa yang perlu dibangun ke dalam perangkat lunak untuk membaca array angka yang sama secara berbeda.

Bitmap

Bitmap (BMP) pada dasarnya adalah apa yang Anda gambarkan, sebuah array angka yang mewakili warna piksel. Misalnya sesuatu

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

Kompresi lossless

Sekarang, mari kita tentukan skema kompresi. Dalam skema kompresi kami, kami akan memiliki sejumlah pasangan angka. Misalnya

3, 1, 1, 0, 7, 1

Sekarang, hal pertama yang ingin saya tunjukkan adalah bahwa skema kompresi ini merepresentasikan piksel yang sama dengan array pertama. Array pertama memiliki tiga 1s diikuti oleh satu 0 dan kemudian tujuh 1s. Dan itulah yang kami wakili di sini. Format ini lebih pendek, karena mewakili beberapa piksel dengan dua angka. Format bitmap harus menggunakan satu angka untuk setiap piksel.

Jelas ini adalah tampilan gambar yang agak disederhanakan (misalnya hanya satu baris) dan skema kompresi. Namun mudah-mudahan ini memungkinkan Anda untuk melihat bagaimana skema kompresi mengubah format gambar. Ini adalah bagaimana GIF berhubungan dengan BMP. GIF menggunakan skema kompresi yang disebut Lempel-Ziv-Welch alih - alih yang sederhana ini.

Apa yang kami jelaskan di sini adalah skema kompresi lossless. Masalah dengan skema kompresi lossless adalah bahwa untuk beberapa input, bentuk yang disandikan mungkin lebih lama dari aslinya. Misalnya untuk

1, 0, 1, 0, 1

Pengkodean adalah

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

Yah, itu tidak berguna. Kami membuat input dua kali lebih lama.

Kompresi lossless lain

Sekarang, mari kita pertimbangkan skema kompresi yang berbeda. Di sini, kami akan menampilkan gambar sebagai lingkaran yang dilapis. Untuk setiap lingkaran, kita akan menentukan pusat, jari-jari, dan warna.

Bitmap pertama kami akan menjadi

5, 5, 1, 3, 0, 0

Ini sama panjangnya dengan metode kompresi pertama kami.

Dan yang kedua bisa juga

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

Ini adalah tiga lingkaran yang berpusat di elemen tengah (yang dalam penghitungan komputer adalah nomor 2, saat komputer mulai menghitung pada 0). Satu lingkaran memiliki jari-jari 2 dan warna 1. Kemudian kita menambahkan lingkaran warna 0 dan jari-jari 1. Akhirnya, kita memiliki lingkaran warna 1 dan jari-jari 0. Dalam langkah-langkahnya, ini akan menjadi

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

Atau

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

Ini adalah lingkaran awal yang sama tetapi ditutupi oleh dua lingkaran titik. Dalam beberapa langkah, itu akan menjadi

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

Keduanya lebih pendek dari versi yang disandikan pertama tetapi masih lebih lama dari yang asli.

Anda mungkin bertanya-tanya mengapa saya berbicara tentang lingkaran dan bukan rentang. Alasan utamanya adalah bahwa lingkaran lebih dekat dengan apa yang digunakan gambar dua dimensi nyata.

Kompresi lossy

Kami juga memiliki konsep skema kompresi lossy. Skema kompresi lossless ini dapat diubah kembali menjadi array bitmap asli. Skema kompresi yang hilang mungkin tidak dapat dibalik.

Mari kita pertimbangkan versi lossy dari metode lingkaran kami. Dalam hal ini, kita akan menggunakan aturan sederhana. Kami tidak akan menyimpan lingkaran apa pun dengan radius kurang dari 1. Jadi, dalam dua penyandian terakhir, kami akan melakukannya

2, 2, 1, 2, 1, 0

dan

2, 2, 1

yang dikonversi menjadi piksel lagi adalah

1, 0, 0, 0, 1

dan

1, 1, 1, 1, 1

Versi pertama hanya satu elemen lebih panjang dari aslinya. Versi kedua lebih pendek. Keduanya valid, sehingga algoritme bebas untuk mengembangkan keduanya dan memilih yang lebih pendek.

Kami menggambarkan gambar dengan aturan yang lebih ketat sebagai kualitas yang lebih rendah.

Representasi gambar ini sebagai koleksi overlay bentuk lingkaran mirip dengan cara kerja Kelompok Fotografi Bersama atau format JPEG . Bentuknya elips bukan lingkaran, tetapi idenya serupa. Alih-alih metode sederhana kami, ia menggunakan transformasi cosinus diskrit untuk menyandikan gambar.

Tidak seperti GIF, JPEG sebenarnya merupakan cara berbeda untuk mewakili gambar. GIF masih piksel. Mereka hanya disimpan dengan cara yang berbeda. JPEG adalah bentuk. Untuk melihat JPEG, kami kemudian mengonversi bentuk menjadi piksel karena itulah cara kerja layar. Secara teori, kita bisa mengembangkan layar yang tidak berfungsi seperti ini. Alih-alih piksel, itu bisa menghasilkan bentuk agar lebih cocok dengan format JPEG. Tentu saja, layar itu tidak dapat menampilkan bitmap. Untuk menampilkan BMP atau GIF, kami harus mengonversi ke JPEG.

Jika Anda mengonversi GIF standar, katakan 300x300 piksel, ubah menjadi JPEG, dan turunkan kualitasnya, bentuk dasar yang digunakan harus terlihat. Banyak JPEG menghindari artefak ini dengan memulai dengan gambar beresolusi jauh lebih tinggi.

Skala JPEG dengan baik karena mereka bentuk daripada piksel. Jadi, jika Anda mulai dengan gambar 8000x8000, konversikan ke JPEG, dan tampilkan sebagai gambar 300x300, banyak detail yang hilang akan hilang juga. Jika Anda mengonversi 8000x8000 bitmap menjadi 300x300 bitmap terlebih dahulu dan kemudian ke JPEG, hasilnya akan seringkali berkualitas lebih rendah.

MPEG

Kami sudah bicara tentang gambar foto. Grup Gambar Bergerak Pakar atau format MPEG menggunakan jenis kompresi yang sama seperti JPEG, tetapi juga melakukan hal lain. Sementara cara sederhana dalam melakukan video adalah mengirim urutan gambar foto, MPEG sebenarnya mengirim bingkai, diikuti dengan sejumlah perubahan daftar bingkai, dan diakhiri dengan bingkai akhir. Karena sebagian besar frame mirip dengan frame sebelumnya, daftar perubahan seringkali lebih kecil dari gambar kedua.

Urutannya biasanya tidak terlalu panjang, misalnya lima frame. Tapi itu membantu membuat aliran lebih kecil dari yang seharusnya.

Penyederhanaan

Saya telah mengabaikan banyak hal. Gambar saya hanya memiliki dua warna (1-bit), bukan 256 dari gambar 8-bit dan jelas bukan 4.294.967.296 dari gambar 32-bit. Bahkan dengan gambar 8-bit, perhatikan bahwa Anda sering dapat memilih palet berbeda untuk gambar. Jadi dua bitmap 8-bit dengan urutan yang sama dapat mewakili gambar yang terlihat berbeda (bentuk yang sama tetapi warna berbeda).

Gambar saya adalah baris tunggal, bukan dua dimensi. Sebagian besar gambar akan memiliki ukuran baris tertentu yang disimpan, membuat array dua dimensi.

Saya belum mencoba untuk mewakili pengkodean yang sebenarnya sama sekali. Mereka jauh lebih kompleks daripada yang sederhana yang saya gunakan. Saya melakukan ini karena saya ingin dapat menggambarkan pengkodean dalam posting ini. Saya tidak yakin bahwa saya bisa menjelaskan perbaikan Lempel-Ziv apalagi perbaikan Lempel-Ziv-Welch yang lebih kompleks dalam satu jawaban. Dan saya tidak mengerti transformasi Fourier cukup baik untuk menjelaskannya.

Ini adalah versi yang sangat sederhana dari penanganan gambar yang sebenarnya. Namun, saya merasa bahwa untuk tujuan didaktik, lebih mudah dipahami daripada kenyataan yang lebih kompleks sambil tetap mengenai poin-poin penting.

Katakanlah itu benar, bahwa setiap piksel hanya tiga angka (merah, hijau dan biru) masing-masing dalam kisaran 0-255. Penjawab lain telah memulai dengan (dengan benar) menantang anggapan itu, tetapi untuk kesederhanaan anggap saja itu benar.

Saya ingat (tetapi sayangnya tidak dapat menemukan secara online) sebuah kartun dari buku teks linguistik: dua pemahat batu kuno Mesir sedang duduk kelelahan di bagian bawah tembok besar di mana mereka telah mengukir sejumlah besar tokoh-tokoh berbaris. Yang satu berkata kepada yang lain: "Tentunya harus ada cara yang lebih mudah untuk menulis, 'Firaun memiliki 100.000 tentara?'". Ingat ide itu.

Sekarang, misalkan baris pertama gambar Anda mengandung 1800 piksel hitam. Bagaimana itu diwakili?

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

Jadi berapa banyak ruang penyimpanan yang dibutuhkan? Setiap nilai adalah satu byte. Tiga byte per piksel, 1800 piksel di baris, jadi sudah 5400 byte per baris. Jadi gambar dengan dimensi 1800 x 1200 harus memakan waktu 1.200 kali lebih banyak, yaitu lebih dari 6 megabita. Jadi sekarang mari kita pergi dan melakukan pencarian gambar Google dan mengunduh beberapa gambar 1800x1200 — katakanlah, satu .pnggambar dan satu .jpggambar. Lihatlah ukuran file: apakah 6 MB? Tidak mungkin, biasanya jauh lebih kecil dari itu. Dan itu hal yang diinginkan, tentu saja, semua ruang yang dihemat, dan waktu pengunduhan yang lebih singkat ....

Jadi apa yang terjadi? Kuncinya adalah bahwa, meskipun Anda memiliki banyak angka untuk disimpan, ada berbagai cara untuk mewakiliangka-angka dalam file. Ada contoh representasi yang lebih efisien di sini dalam jawaban saya, dua paragraf yang lalu. Saya menulis kata-kata "1800 piksel hitam". Itu 17 karakter, dan jadi tidak perlu mengambil lebih dari 17 byte, namun itu dengan sempurna menggambarkan informasi yang sama persis yang kami pikir kami butuhkan 5400 byte. Dan Anda tentu bisa melakukan lebih baik dari 17 byte (dan juga menghemat banyak upaya dalam implementasi encoding / decoding) jika Anda tidak menggunakan bahasa Inggris untuk menyandikan informasi ini, tetapi lebih merupakan bahasa tujuan khusus. Jadi sekarang, sudah, kami menempatkan lebih dari satu format kompresi gambar: yang menggunakan kata-kata bahasa Inggris, dan yang lebih efisien dari itu. Lihat kemana ini?

OK, Anda berkata, itu bekerja jika sejumlah piksel yang berdekatan kebetulan memiliki warna yang sama. Tetapi bagaimana jika mereka tidak melakukannya? Ya, tentu saja, itu tergantung pada konten gambar tertentu: semakin banyak redundansi , semakin mudah untuk mengompres informasi. Redundansi berarti bahwa bagian gambar dapat diprediksi dengan cukup baik jika Anda sudah tahu bagian lain. Kompresi berarti hanya menuliskan minimum yang diperlukan untuk merekonstruksi informasi. Tidak setiap gambar yang mungkin memiliki redundansi, tetapi setiap gambar nyata yang memiliki makna bagi mata dan otak manusia, meskipun lebih kompleks daripada contoh hitam-murni saya, masih akan cenderung memiliki banyak redundansi. Dan ada banyak cara mengompresi. Beberapa metode kompresi bersifat lossless, artinya informasi tersebut dapat direkonstruksi menjadi identik secara matematis dengan aslinya, seperti pada contoh baris hitam piksel saya. Sebagian besar .pngfile menggunakan metode kompresi lossless. Beberapa metode bersifat lossy : rekonstruksi tidak sempurna, tetapi kesalahannya tersembunyi sedemikian rupa sehingga mata dan otak manusia sulit melihatnya. Sebagian besar .jpgfile bersifat lossy.

Rincian tentang bagaimana Anda mengenali pola redundansi yang rumit, dan bagaimana Anda menulis deskripsi terkompresi yang efisien dari mereka, sangat matematis — dan non-sepele, itulah sebabnya ada ruang untuk begitu banyak format berbeda di luar sana, sesuai dengan strategi kompresi yang berbeda. Tapi semoga Anda mendapatkan prinsipnya.

Beberapa komentator di atas telah membuat perkiraan yang masuk akal tentang di mana kesalahpahaman Anda muncul. Dalam pertanyaan Anda, Anda tampaknya berpikir bahwa kompresi hanya mengubah sedikit nilai pixel (dan tentu saja, metode kompresi lossy melakukannya di beberapa tempat, tetapi hanya sebagai efek samping yang tidak diinginkan) tanpa mengubah tata letak informasi. Ketika Anda membuka file dan melihat konten gambar (misalnya, sebagai array angka di Matlab atau sebagai gambar di layar di Photoshop), Anda tidak melihat konten file yang dikompresi, tetapi pada rekonstruksi, yang memiliki tata letak yang sama dengan aslinya (tidak akan banyak rekonstruksi jika tidak membuat ulang tata letak dengan benar). Prosedur pembukaan file telah mengurangi informasi dari file menjadi representasi penuh terkompresi dalam memori. Jika Anda membandingkan dua rekonstruksi terkompresi , maka memang tidak ada yang membedakan antara dua format gambar yang berbeda (kecuali untuk kesalahan rekonstruksi, jika ada).

Ya, tetapi bagaimana Anda sampai ke angka 1 dan 0 sangat berbeda.

Saya akan memberikan contoh, tetapi itu palsu dan seharusnya menggambarkan lebih dari akurat. Perlu diingat bahwa semua gambar digital diwakili dalam biner pada tingkat tertentu.

Untuk memperumit masalah, ada saluran yang berbeda. CMYK, RGB, B&W, hanya untuk beberapa nama. Kita tidak akan membahas itu. Ada juga berbagai tahapan, seperti menangkap, menyimpan, dan menampilkan. Kita akan membahasnya, meskipun sekali lagi contoh ini seharusnya menunjukkan tidak akurat. Jika Anda ingin contoh yang akurat, Anda perlu mencari banyak dokumen teknis.

Jadi dalam sampel kami, kami akan melihat gambar hitam dan putih.

00067000
00067000
00567800
04056090
40056009

Angka-angka menunjukkan seberapa kuat "Hitam" itu. Beginilah cara kamera menangkap gambar. Ini kamera yang layak jadi ini juga cara menyimpan gambar.

Sekarang menyimpan gambar di komputer, tetapi membutuhkan banyak ruang sehingga kita akan mengompresnya. Selain menumbuknya, kita juga tahu bahwa kebanyakan orang tidak dapat mendeteksi perbedaan 1 level hitam sehingga kita akan melicinkannya.

302730
302730
204820
*04056090
1420262019

Nah, begitulah cara kami menyimpan gambar di disk. Dibutuhkan lebih sedikit ruang dan memungkinkan kami menghasilkan banyak gambar asli.

Sekarang katakanlah kita ingin mencetaknya di printer. Printer hanya mencetak satu level hitam, sehingga komputer menerjemahkan gambar yang disimpan dan dikompres ke dalam printer.

00011000
00011000
00111100
01011010
10011001

Ini mencetak gambar yang tampak masuk akal, tetapi Anda dapat melihat, bahkan dalam contoh kurangnya kualitas extream. Tapi hei itu kesalahan printer.

Akhirnya, Anda pergi untuk mencetak gambar pada printer yang bagus dengan 10 level hitam. Sama seperti kamera Anda. Jadi Anda menggunakan gambar yang disimpan dan dikompresi.

00077000
00077000
00888800
04056090
40066009

Seperti yang Anda lihat gambarnya "lebih baik" tetapi telah diubah sedikit dari aslinya.

Pada waktu tertentu Anda benar bahwa itu semua hanya kekuatan saluran. Dan selain gambar terkompresi, yang harus didekompresi, tetap benar untuk itu.

Namun, format terkompresi kehilangan banyak "informasi". Apakah informasi itu penting? Ya, itu terserah artis, dan penonton. Ada beberapa trade-off antara menghemat ruang, waktu pemrosesan, kualitas gambar akhir / disimpan, dan kebutuhan. Saya memindai sebagian besar dokumen saya dalam satu warna hitam karena hanya itu yang saya butuhkan. Namun, foto pernikahan saya dalam format BESAR RAW karena saya tidak pernah tahu kapan saya ingin mencetak ulang yang bagus. Yang mengatakan, ketika saya mentransfer (foto) ke bingkai foto digital saya mengubahnya menjadi JPEG untuk menghemat ruang. Saluran yang berbeda, filter yang berbeda, dan metode kompresi yang berbeda semuanya merupakan rangkaian pertukaran. Ini seperti versi digital dari segitiga printer.

Saya akan berpadu dengan sedikit info tambahan karena saya telah bekerja dengan penginderaan gambar dan pengkodean / kompresi, meskipun sebagian besar gambar bergerak.

Dalam bentuk dasarnya, sebuah gambar (gambar APA PUN) yang ditampilkan pada layar tertentu memang hanya array angka yang identik. Angka-angka itu semua mungkin 0-255 atau 0-65535 atau 0 -apapun-32-bit-adalah-saya-lupa-go-google-itu.

TETAPI ada begitu banyak cara untuk MENYIMPAN dan MENGIRIM informasi itu, banyak di antaranya hanyalah produk teknologi yang hilang karena kabut waktu.

Juga, satu detail yang saya belum melihat salah satu pedant lain yang disebutkan di sini adalah bahwa data sensor gambar RAW benar-benar dari kamera digital mungkin RGrGbB dalam pola bayer atau semacam itu yang perlu diproses setidaknya sedikit untuk membuat akal untuk bola mata manusia Mk.1. Kemungkinan Anda tidak akan pernah mendapatkan itu bahkan dalam format RAW yang disimpan oleh DSLR Anda karena tidak ada gunanya sampai Anda mengonversinya menjadi grid yang bagus dari piksel RGB atau YUV, baik dalam kedalaman 8, 16, 32 atau dalam bit kesebelas miliaran.

Hal-hal yang saya kerjakan menggunakan YUV secara internal untuk alasan apa pun, saya menganggap itu lebih mudah diproses oleh codec karena manusia merasakan kecerahan dengan sensitivitas lebih banyak daripada warna.

Untuk bacaan pengantar tidur ringan, lihat bagian "format gambar bingkai": http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

Pokoknya ... kembali ke pertanyaan awal Anda tentang perbedaan antara file gambar yang tidak terkompresi seperti TIFF / RAW / IFF / PNG.

Secara umum alasan ini ada adalah bahwa, beberapa bulan yang lalu, setiap komputer / OS / produsen printer datang dengan serangkaian persyaratan mereka sendiri yang sedikit berbeda untuk beberapa cara menyimpan / mengirim gambar.

Jadi, RAW sebagaimana dibahas oleh orang lain di utas ini adalah istilah umum untuk beberapa hal berbeda yang disimpan oleh kamera digital yang berbeda, menggunakan data apa pun yang dianggap penting oleh pabrikan kamera, berdasarkan fitur yang dimiliki atau mungkin dimiliki kamera di masa depan. Jadi, meskipun bit data gambar utama mungkin sangat mirip, "kemasan" di sekitarnya yang menggambarkan gambar dan semua pengaturan kamera dll. Sehingga satu file tidak akan dipahami oleh produsen yang berbeda.

Secara tradisional ini adalah agar mereka dapat membuat Anda (atau, lebih mungkin, fotografer profesional) menggunakan perangkat lunak berpemilik mereka (dan terkadang mahal) untuk memproses gambar berkualitas lebih tinggi ini, jika tidak, Anda mungkin mulai menggunakan perangkat lunak mahal milik orang lain. Juga, mungkin Adobe Photoshop ingin mendukung format mereka, jadi mungkin mereka dapat menagih Adobe $$$ untuk informasi itu sehingga fotografer yang lebih profesional akan membeli PS dan mungkin membeli yang membuat kamera karena PS mendukungnya sekarang. Nyaman!

RAW juga menyimpan informasi tentang cara mengubah bundel data itu kembali menjadi gambar yang dapat dilihat manusia, sederhananya semua tweak yang perlu Anda lakukan agar data membuat gambar terlihat "benar".

TIFF adalah format gambar awal yang, antara lain, digunakan untuk mengirim data grafis ke printer (ketika printer berkemampuan grafik mulai terjangkau). Itu cukup mendasar sehingga mudah diproses pada mikroprosesor kecil murah di dalam printer.

IFF (yeah, itu hal) adalah format yang sama yang digunakan pada komputer Amiga, saya percaya diciptakan oleh mereka atau salah satu paket cat populer. Tapi, saya menggunakannya di sini sebagai contoh karena meskipun ia menyimpan data gambar bit-map seperti yang lain, itu mendukung data terkompresi atau RLE, kedalaman bit variabel dari 1-bit mono ke 8-bit 256-warna (tetapi dengan palet RGB 3x8-bit yang dapat dipilih untuk masing-masing warna) serta mode khusus yang disebut Halftone dan Hold-And-Modify yang memungkinkan lebih banyak warna daripada yang dapat dikelola oleh mesin lain pada zaman itu. Oh, dan itu mendukung animasi juga (seperti GIF) sehingga file IFF dapat menyimpan sejumlah frame, dengan penundaan variabel di antara frame, dan setiap frame bisa memiliki palet sendiri. Jadi, IFF akan memasukkan data ekstra untuk menangani semua ini dibandingkan dengan, katakanlah, file TIFF.

PNG adalah format gambar lossless lain, lagi-lagi menyimpan data bitmap, tetapi mendukung beberapa fitur funky seperti saluran alfa 8-bit untuk transparansi variabel di seluruh gambar (berguna pada halaman web), jadi sekali lagi data gambar "payload" mungkin terlihat sangat mirip tetapi pembungkus di sekitarnya berbeda, dan payload mungkin mengandung RGBA daripada hanya data RGB per-pixel.

Jadi, itulah 4 format file gambar yang berbeda yang dijelaskan - Anda dapat menyimpan sampel gambar HD penuh warna dari kucing di salah satu dari 4 dan itu akan TERLIHAT identik, setiap piksel pada layar Anda akan memiliki nilai SAMA SEKARANG dan TIDAK akan ada perbedaan kualitas antara 4 ... tetapi 4 file kemungkinan akan berbeda dalam ukuran, tata letak, dan lebih mudah atau lebih sulit untuk memuat & memproses perangkat lunak.

Semoga itu bisa membantu!

Hanya berpikir saya akan berpadu di sini dengan informasi yang seharusnya menjadi jawaban pertama untuk pertanyaan ini.

Piksel dalam gambar tidak disimpan dalam byte - kecuali jika gambar tersebut monokrom, yaitu hanya hitam dan putih.

Jika Anda memiliki gambar tiga warna, maka setiap piksel diwakili oleh 16 bit, atau 2 byte - sebagai satu nilai. Jika Anda memiliki gambar 32bit, maka setiap piksel membutuhkan 32 bit atau 4 byte, sekali lagi sebagai nilai tunggal.

cukup menarik, file gambar dan suara dan setiap tipe data lainnya di komputer bermuara menjadi bit 1s dan 0's. Hanya dengan menafsirkannya dalam potongan berukuran benar bahwa makna diekstraksi dari mereka.

Misalnya, gambar dan dokumen kata dan file mp3 semuanya memiliki konten data dasar yang sama (banyak byte), dan salah satunya dapat ditafsirkan sebagai salah satu dari jenis lainnya - Anda dapat mengartikan kata doc sebagai suara. file dan Anda akan mendengar sesuatu, tetapi itu bukan musik. Anda pasti bisa mengartikan file suara sebagai gambar, dan itu akan menampilkan sesuatu, tetapi itu tidak akan menjadi gambar yang kohesif.

Jadi, untuk meringkas, komputer hanya tahu tentang bit - bit adalah 1 atau 0. Semua gambar, suara, dokumen, film, video, rekaman, permainan, panggilan telepon, pesan teks dan apa pun yang berlabel digital memiliki persis sama konten - sekelompok 1 dan 0. Angka 1 dan 0 menjadi gambar, suara, dan dokumen, dan yang lainnya karena kode yang membacanya tahu untuk membaca bit-bit itu dalam kelompok dan memprosesnya.

Itu sebabnya kami memiliki hal-hal seperti gambar 16 bit dan 32 bit, dan file audio 16 bit dan 24 bit. Semakin banyak bit yang Anda gunakan untuk piksel atau sampel suara, semakin ekspresif Anda - 16 bit hanya dapat menentukan 64 ribu warna unik, tetapi 32 bit dapat menentukan lebih dari 4 juta warna unik. Gambar monokrom menggunakan 1 bit per piksel - baik hidup atau mati.

Dengan file audio, semakin banyak bit yang Anda gunakan per sampel, rekaman dapat lebih detail dan bernuansa.

Saya belum membaca keseluruhan utasnya tetapi bagi saya banyak orang lupa tentang format gambar vektor. Itu bukan array piksel, karena konsep piksel bahkan tidak ada dalam format seperti itu. Terserah penyaji untuk mengetahui cara menghasilkan gambar di layar atau media lainnya.

Bahkan tanpa menyebutkan domain warna, kompresi, ukuran bit dan format saluran, ada satu set format file yang sama sekali tidak seperti peta piksel. Namun format vektor juga jauh "lebih baik" dalam mewakili jenis gambar tertentu, biasanya diproduksi oleh komputer dan bukan kamera.

Pertanyaan ini dijawab dengan cukup rinci sebelumnya. Namun meskipun ada banyak teori yang disajikan ke dalam jawaban, saya merasa ada beberapa mata pelajaran dasar, biasanya terkait dengan pemrograman komputer yang membutuhkan lebih banyak klarifikasi. Saya harus menyatakan saya seorang insinyur perangkat lunak. Setelah saya membaca pertanyaan saya menyadari ada sepenuhnya kesalahpahaman dari tipe data pemrograman dasar yang menghasilkan pertanyaan ini.

Pertanyaan pertama di sini adalah:

Selanjutnya, dari sudut pandang numerik, apa yang membuat sesuatu seperti gambar 16-bit berbeda dari gambar 32-bit? Sekali lagi, gambar hanyalah sebuah array dengan nilai integer antara 0 -255.

Seperti yang disajikan sebelumnya: Tidak, tidak. Sebuah gambar bukan hanya array nilai integer antara 0-255. Sebenarnya itu bisa berupa array tunggal atau multidimensi dari nilai 0 hingga 65535, array 0 hingga 4294967295 atau bahkan array bit (bit dapat menampung nilai 0 atau 1, itu saja) yang dikonversi oleh perangkat lunak yang mampu baca file gambar menjadi angka integer sesuai dengan berbagai aturan pengkodean.

Untuk memahami ini lebih lanjut, seperti yang dinyatakan sebelumnya, saya pikir diskusi tentang tipe data pemrograman dasar diperlukan. Saya akan mencoba menjelaskannya sesederhana mungkin sehingga siapa pun memahami masalah yang terkait dengan menyimpan nilai integer dalam file komputer.

Dalam pemrograman komputer kami menggunakan beberapa tipe data primitif dasar untuk menulis nilai ke dalam file, membacanya dari file ke dalam memori komputer, memanipulasi nilai-nilai tersebut menggunakan berbagai tipe data bahasa pemrograman tertentu dan akhirnya menyimpannya kembali ke file. Bilangan bulat dalam pemrograman komputer tidak hanya bilangan bulat. Ada semua jenis bilangan bulat, tergantung pada bahasa pemrograman yang kita gunakan dan berapa banyak memori yang kita butuhkan untuk masing-masingnya. Biasanya, dalam sebagian besar bahasa pemrograman kami memiliki tipe data berikut (dan cara untuk memanipulasi mereka):

• BIT - memegang 0 atau 1
• UINT8 - 8bit unsigned integer - mereka dapat menyimpan nilai antara interval [0 hingga 255].
• INT8 - 8bit integer bertanda - mereka dapat menyimpan nilai antara [-126 hingga 127] interval.
• UINT16 - 16bit unsigned integer - mereka dapat menyimpan nilai antara interval [0 hingga 65535].
• INT16 - 16bit unsigned integer - mereka dapat menyimpan nilai antara [−32768 hingga 32767] interval.
• UINT32 - 32bit unsigned integer - mereka dapat menyimpan nilai antara interval [0 hingga 4294967295].
• INT32 - 32bit unsigned integer - mereka dapat menyimpan nilai antara [−2147483648 hingga 2147483647] interval.
• ATAU kombinasi dari semua tipe data tersebut dalam format yang lebih kompleks. Misalnya sebuah UINT16 (16 BIT) memegang 3 nilai yang berbeda, 4 BIT pertama memegang nilai antara 0 hingga 127, BIT berikutnya memegang 0 atau 1 dan seterusnya.

Lebih jauh lagi, ada sesuatu yang harus dihadapi programmer ketika membaca atau menulis tipe data integer dari file. Kehebohan itu.Endianness mengacu pada urutan berurutan di mana byte (UINT8 dari tabel kami) disusun menjadi nilai numerik yang lebih besar saat disimpan dalam memori atau file. Endianness menarik dalam ilmu komputer karena dua format yang saling bertentangan dan tidak kompatibel yang umum digunakan: nilai dapat direpresentasikan dalam format big-endian atau little-endian, tergantung pada apakah bit atau byte atau komponen lain dipesan dari ujung besar (paling signifikan) bit) atau sedikit ujung (bit paling tidak signifikan). Sederhananya Anda dapat menyimpan nilai seperti ini 0000000011011111 atau ... seperti ini 1101111100000000 tergantung atau urutan endian yang Anda pilih. Dan Anda bebas memilih pesanan apa pun yang sesuai dengan tujuan Anda. Tidak ada aturan lain yang Anda buat saat mendesain format file gambar.

Harap perhatikan bahwa integer pemrograman komputer menggunakan lebih banyak atau lebih sedikit ruang, tergantung pada nilainya. Seperti Anda membutuhkan lebih banyak kertas untuk menulis 255255255 Anda membutuhkan lebih banyak BIT untuk menulis nilai yang lebih besar. Kemudian nanti ketika Anda ingin membaca nilai Anda harus tahu persis aturan yang Anda buat saat Anda menulisnya. Kalau tidak, tidak mungkin bagi Anda untuk mengetahui cara membaca kami hanya array dengan nilai integer antara 0 -255 karena Anda tidak tahu di mana angka-angka itu disimpan dan bagaimana angka-angka itu disimpan mengingat begitu banyak pilihan yang Anda miliki (BIT, UINT8 , UINT16, UINT32 atau kombinasi dari semua tipe data komputer tersebut). Dan jangan lupa, Endianness. Jika Anda tidak tahu data ditulis menggunakan urutan big-endian atau little-endian Anda tidak dapat membaca nilai yang tepat.

Karena gambar ini TIDAK PERNAH hanya sebuah array dengan nilai integer antara 0 - 255. Beberapa dari mereka adalah array dari UINT16 (gambar 16bit) yang lain adalah array dari UINT32 (gambar 32-bit) atau yang lain adalah array dari UINT8 (gambar 8-bit). Beberapa programmer komputer yang sangat kreatif bahkan dapat menggunakan tipe bertanda tangan yang menghidupi Anda dengan array INT8, yang berarti array nilai antara -126 dan 127.

Sebenarnya ketika Anda membaca file gambar, salah satu data pertama yang Anda temui biasanya beberapa BIT yang mewakili lebar dan tinggi gambar. Dan itu bukan hanya beberapa nilai 0-255. Itu juga beberapa tipe data yang dipilih oleh programmer. Beberapa programmer akan berpikir 16 BIT adalah enogh untuk menyimpan lebar gambar maksimum 65535 piksel, karena mereka merancang format gambar yang digunakan dalam permainan untuk menyimpan beberapa gambar tombol kecil. Beberapa programmer lain mungkin menggunakan nilai 32bit di sini memungkinkan Anda untuk menyimpan gambar dengan lebar & tinggi 4294967295. Beberapa programmer NASA gila bahkan mungkin menggunakan 64bit untuk menyimpan foto galaksi yang sangat besar hingga 18446744073709551615 piksel.Jika Anda tidak tahu aturannya, Anda tidak bisa membaca "nilai-nilai" itu sebagaimana Anda menyebutnya. Karena Anda tidak tahu di mana mereka mulai di file gambar dan di mana mereka berakhir. Jadi Anda berakhir dengan sekelompok BIT yang tidak Anda mengerti.

Itu sebabnya alam semesta penuh dengan begitu banyak format gambar yang berbeda. Karena tidak ada solusi standar untuk menulis beberapa nilai integer ke dalam file. Ini pilihan programmer sepenuhnya berdasarkan banyak faktor seperti Endianess dari mesin yang sedang Anda kerjakan, bahasa pemrograman yang Anda gunakan untuk merancang implementasi format file asli dan banyak hal lain seperti tujuan format gambar (seperti yang dengan jelas dinyatakan sebelumnya oleh jawaban lain).

Format file sederhana praktis dari gambar hitam & putih yang hanya memiliki satu nilai tunggal 166 untuk mewakili gambar 4x2 piksel:

Gambar (1 - piksel hitam, 0 - piksel putih):

1010 
0110

Format file ini menggunakan 1 BIT per PIXEL yang disimpan sebagai nilai integer 8bit TUNGGAL 166 (10100110). Itu saja. Tidak ada array nilai 0-255 yang digunakan tetapi 8 nilai 0 atau 1 yang berbeda disimpan sebagai nilai 166.

Jika Anda menggunakan array nilai 0-255 untuk setiap piksel * 3 kali untuk RGB, Anda akan mendapatkan gambar 24 kali lebih besar. Format file ini hanya menghemat 24 kali ruang disk yang Anda butuhkan untuk menyimpan gambar seperti ini atau 24 kali lebih sedikit memori komputer yang diperlukan untuk membaca dan menyimpan gambar ini ke dalam RAM komputer ketika Anda menggunakan gambar ini misalnya di mesin permainan 3D kinerja tinggi untuk menggambar sesuatu di layar dengan itu (tekstur ribuan partikel debu terbang di sekitar bisa menjadi kandidat yang baik :)).