Fahrur Razi : Analisis Pengaruh Panjang Bit Kode Pada Kinerja Program Kompresi Yang Menggunakan Algoritma Lempel Ziv Welch LZW, 2009.
USU Repository © 2009
didesain sebagai penerus dari GIF. Algoritma LZ78 telah digunakan pada standar komunikasi modem V.42bis, dan program kompres Unix bernama compress, dan
pada GIF format file citra Hankerson et al, 2003.
Algoritma Lempel Ziv ini terbagi atas dua varian utama yaitu LZ77 dan LZ78. Perbedaan utama kedua algoritma ini adalah pada teknik pembuatan dictionary. Pada
LZ77 dictionary adalah fragmen dari sebuah window sliding window. LZ78 menggunakan frase-frase yang pada file sebagai dictionary. Algoritma LZW adalah
varian dari algoritma LZ78. Keunggulan masing-masing adalah algoritma LZ78 menggunakan struktur data yang lebih kompleks dalam mengelola penyimpanan
dictionary, LZ77 mengubah dengan cepat dictionary dan lebih cepat pada saat decoding. Pada aplikasi pemilihan skema dapat sangat kompleks karena telah
dipatenkan Hankerson et al, 2003.
2.5 Algoritma Lempel Ziv 77 LZ77
Pada dasarnya algoritma LZ77 membagi window dengan dua bagian yaitu history dan lookahead. Dalam pertimbangan pembuatan dictionary maka history akan digunakan
sebagai dictionary sehingga history harus memiliki panjang lebih dari lookahead. Idenya adalah menggantikan segmen dari lookahead dengan pointer pada dictionary,
dan menggeser prosesnya sepanjang window Hankerson et al, 2003.
Gambar 2.1 Ilustrasi contoh cara kerja algoritma LZ77
Pada Gambar 2.1 misalkan segmen inisial ‘he’ sama dengan karakter kedua dari frase dictionary ‘shell’ dan pada contoh ini digunakan offset 10 pada dictionary
Fahrur Razi : Analisis Pengaruh Panjang Bit Kode Pada Kinerja Program Kompresi Yang Menggunakan Algoritma Lempel Ziv Welch LZW, 2009.
USU Repository © 2009
dan dihitung dari kanan ke kiri. Dimana komponen ketiga adalah karakter selanjutnya dari file sumber dan kemudian window digeser lihat Gambar 2.2.
Gambar 2.2 Ilustrasi penggeseran window pada algoritma LZ77
Kemudian ‘he’ diganti menjadi sebuah token yaitu 10,2,spasi. Dimana 10 berarti jarak karakter dengan karakter lookahead, 2 berarti panjang string yang sama,
dan spasi adalah karakter setelah karakter ‘he’ tersebut. Kompresi akan sukses jika token ini menghasilkan jumlah bit yang lebih sedikit dari pada file sumber.
Selanjutnya karakter yang tidak sama pada token dapat mengakibatkan suatu kasus dimana tidak ada karakter yang sama pada history. Maka penggunaan offset,length
dapat digunakan ketimbang token triple sebelumnya. Gambar 2.3 menunjukkan beberapa langkah proses pada contoh masalah:
Gambar 2.3 Ilustrasi penggunaan token offset,length
Sebuah decoder menerima output token, dimana token tersebut akan dibangun ulang. Menurut Hankerson 2003, hal:231 ada beberapa hal yang harus diperhatikan
pada algoritma ini, yaitu:
Fahrur Razi : Analisis Pengaruh Panjang Bit Kode Pada Kinerja Program Kompresi Yang Menggunakan Algoritma Lempel Ziv Welch LZW, 2009.
USU Repository © 2009
1. Decoder harus dapat membedakan antara sebuah token dengan sebuah karakter
asli.
2. Kualitas kompresi akan bergantung pada token, tepatnya pada panjang string
token. Dimana panjang yang terlalu pendek dapat menyebabkan rasio kompresi membesar.
3. String yang sama didasarkan pada lookahead. Seperti pada Gambar 2.4 dimana
window berisi fragmen tersebut.
Gambar 2.4 Ilustrasi contoh fragmen lookahead yang terdapat pada history
4. Setiap langkah, maka digunakan greedy parsing dimana dictionary dicari untuk
sebuah string sama yang terpanjang pada inisial segmen. Tidak ada jaminan penggunaan greedy parsing adalah maksimal. Pencarian untuk longest match
pada dictionary adalah hal yang cukup sulit. Dimana banyak varian LZ77 yang menggunakan struktur data yang baik untuk mempercepat pencarian.
5. Banyak varian LZ77 yang mempunyai kecepatan tinggi saat proses decoding,
akan tetapi diperlukan kerja keras untuk mencari algoritma dan struktur data yang cepat pada proses encoding.
6. Sebuah token dapat dikompres lagi dengan metode kompresi tertentu. Sebuah
contoh, seharusnya digunakan jumlah bit yang tetap untuk menyimpan match length kemudian match length tersebut dikompres lagi dengan menggunakan
metode kompresi probabilistik seperti Huffman akan menambah efektivitas dari algoritma LZ77.
Fahrur Razi : Analisis Pengaruh Panjang Bit Kode Pada Kinerja Program Kompresi Yang Menggunakan Algoritma Lempel Ziv Welch LZW, 2009.
USU Repository © 2009
Implementasi dari LZ77 file sumber tentu berisi ASCII akan terdiri dari 256 karakter dan panjang bit adalah 8 bit. Kemudian history dan lookahead keduanya
mempunyai panjang yang tetap, dengan offsets menggunakan 12 bits dan length menggunakan 4 bits. Dan 1 bit digunakan sebagai penanda atau flag yang
membedakan antara token dengan sebuah karakter asli.
Sehingga total bit yang dibutuhkan adalah 17 bits sedangkan sebuah karakter asli membutuhkan 9 bits. Oleh sebab itu, maka token hanya digunakan untuk match
length minimal 2 karakter. Penggunaan 4 bits pada length merepresentasikan panjang 2 sampai 17. Pada Gambar 2.5 dapat dilihat ilustrasi cara kerja dari implementasi
algoritma LZ77.
Gambar 2.5 Ilustrasi implementasi dari algoritma LZ77
File sumber membutuhkan 36 x 8 = 288 bits. Sedangkan hasil kompresi algoritma LZ77 adalah 6 token dan 18 karakter asli sehingga jumlah bit hasil kompresi
adalah 6 x 17 + 18 x 9 = 264 bits. Sehingga proses kompresi dapat menghemat 24 bit. LZ78 adalah algoritma yang tipikal menggunakan sebuah trie untuk
menyimpan seluruh pola string. Sebuah dictionary pada algoritma LZ78 adalah sebuah set entry pola, dimana diindex dari 0 dan bernilai integer. Mirip dengan LZ77
dimana index menunjuk pointing pada sebuah kata pada dictionary yang disebut token. Berbeda dengan algoritma LZ77 output dari proses encoding algoritma LZ78
hanya berupa deretan token saja sehingga tidak dibutuhkan bit tambahan yang digunakan sebagai flag seperti algoritma LZ77.
2.6 Algoritma Lempel Ziv 78 LZ78
