Blognya Mba@hmo

Space … the final frontier …

Apakah Kompresi Citra Medik Diperlukan?

Ditulis oleh A.D Setiawan di/pada September 2, 2008

Apakah kompresi citra medik diperlukan? Ini adalah sebuah pertanyaan yang menggelitik di hati saya belakangan ini, meskipun saya memiliki pendapat tentang pertanyaan ini. Semua bermula dari kunjungan tamu dari Pakistan beberapa waktu yang lalu ke lab kami. Rombongan pertama berasal dari Aga Khan University, dan sewaktu saya presentasikan mengenai algoritma scalable fuzzy vector quantization (SFVQ) sekaligus dengan aplikasinya di PDA, mereka sangat berminat. Bahkan mereka meminta publikasi terkait dengan algoritma tersebut. Rombongan kedua datang beberapa hari kemudian, dan berasal dari Karachi University. Sewaktu saya menjelaskan hal yang serupa pada rombongan pertama, mereka justru tidak terlalu tertarik. Sebab selama ini mereka tidak memiliki masalah dengan bandwidth komunikasi, sehingga citra medik dikirimkan tanpa dikompres terlebih dahulu atau dikompres secara tidak merugi (lossless). Selain itu rombongan kedua tidak menggunakan asumsi yang digunakan dalam pengembangan algoritma SFVQ, yaitu pencermatan ahli medis terhadap suatu citra medik hanya berkisar pada bagian tertentu dari citra medik tersebut. Jadi pencermatan tidak dilakukan pada keseluruhan citra medik tersebut.

Menarik sekali pendapat kedua rombongan tersebut. Satu rombongan tertarik dan bahkan sedang bekerja dengan kompresi citra medik, sedangkan rombongan kedua tidak terlalu tertarik dengan kompresi citra medik. Pihak yang merasa perlu adalah pihak yang melihat potensi hambatan dari kapasitas penyimpanan dan lebar kanal komunikasi. Faktanya adalah ukuran citra medik itu besar, berkisar antara 3 hingga 10 MB atau mungkin juga lebih. Pihak yang merasa tidak perlu melihat bahwa harga media penyimpanan sudah semakin murah dengan orde kapasitas hingga ratusan GB bahkan hingga 1 TB. Sedangkan teknologi jaringan terkini sudah menyediakan lebar kanal yang besar dengan harga yang terjangkau, misalnya layanan speedy dari Telkom dengan harga 220.000 untuk 1 GB data per bulan dengan lebar kanal hingga 1 Mbps.

Baiklah kita coba kaji kedua pendapat tadi. Pendapat kedua (yang tidak memerlukan kompresi) cukup beralasan, namun bagaimana jika sebuah sistem melibatkan volume citra medik yang besar. Mari kita asumsikan untuk penyimpanan nasional secara terpusat, jika penduduk Indonesia adalah 250 juta dan masing2 memiliki 1 buah citra medik dan masing-masing citra medik berukuran 5 MB, maka diperlukan kapasitas penyimpanan sebesar kurang lebih 1.2 juta TB. Sebuah angka yang sangat besar. Baiklah bagaimana kalau sistemnya terdistribusi? OK … katakanlah penduduk kota Bandung adalah 2.5 juta (?) dan 10% nya berobat di sebuah rumah sakit.. Keperluan kapasitas media penyimpanannya akan menjadi 1220 TB. Angka-angka yang sangat besar. Bukan berarti tidak bisa dicapai, tapi berapa uang yang harus dikeluarkan. Jika 1 TB bisa dibeli dengan 3 juta, maka kita membutuhkan sekitar 3.6 milyar rupiah. Bagimana kalau kita harus menyediakan media penyimpanan dengan performansi yang tinggi, misalnya dengan mengimplementasikan RAID 0+1 dan SAN server? Jumlahnya akan berlipat beberapa kalinya. Belum lagi berbicara harga sistemnya. Sebuah rumah sakit mungkin lebih tertarik ke pengembangan jumlah tempat tidur, karena langsung berkorelasi dengan aliran dana masuk.

Untuk kanal komunikasi, pendapat kedua menyatakan bahwa lebar kanal komunikasi saat ini sudah mampu mentransmisikan citra medik dalam waktu yang singkat. Sebagai contoh kalau kita menggunakan teknologi fast ethernet (100 Mbps), kita dapat mentransmisikan sebuah citra medik berukuran 3.7 MB hanya dalam waktu 1.7 detik. Permasalahan mungkin akan timbul jika kita melakukan kegiatan telemedicine. Oh … tidak ada masalah, karena bisa menggunakan komunikasi satelit dan fiber optik (FO).. Tidak masalah dari sisi lebar kanal, tapi bermasalah dengan tarif. Berapa tarif untuk menyediakan komunikasi satelit atau FO? Di Indonesia masih dirasakan mahal, karena di Indonesia masih dikenakan tarif bisnis, dan bukannya tarif khusus. Belum lagi kalau berbicara tentang telemedicine dengan daerah rural. Selain satelit, hanya beberapa teknologi dengan lebar kanal terbatas saja yang bisa mencapai daerah rural, diantaranya adalah PSTN (56 Kbps) dan celular (115 Kbps – 384 Kbps). Beberapa daerah di Indonesia memang telah dilalui infrastruktur FO, tetapi daerah lainnya tidakdemikian terutama di Indonesia bagian Timur (lihat gambar 1). Kemungkinan masalah lebar kanal komunikasi dapat diselesaikan jika infrastruktur PALAPA RING berhasil diwujudkan (lihat gambar 2.


Gambar 1. Kondisi jaringan fiber optik saat ini


Gambar 2. infrastruktur PALAPA RING

Menurut hemat saya (termasuk anggota dari kelompok pertama :D ), kompresi citra medik itu masih diperlukan, terutama untuk negara kita Indonesia. Dan jika menyangkut volume citra medik yang besar. Kompresi citra medik SFVQ yang selama ini telah dikembangkan berhasil mengkompres citra medik hingga 16 kalinya bahkan bisa dipaksa hingga 64 kalinya. Sehingga kebutuhan media penyimpanan dan lebar kanal komunikasi bisa dihemat sebesar itu juga. Tentu saja dengan asumsi bahwa bagain yang akan diamati pada sebuah citra medik bukanlah keseluruhan bagian, tetapi hanya bagian-bagian tertentu saja.

Memang terdapat sebuah pertentangan, bahwa jika kita ingin mendapatkan rasio kompresi yang tinggi, maka terdapat beberapa informasi yang hilang dan sebaliknya. Jika kita menginginkan tidak ada informasi yang hilang, maka rasio kompresi yang kita dapatkan hanya kecil. Kita tidak bisa mendapatkan sebuah sistem kompresi dengan rasio kompresi yang tinggi, namun (hampir) tidak ada informasi yang hilang. Hal yang mungkin dapat dilakukan untuk menyatukan dua buah kubu pertentangan ini adalah dengan mengembangkan skema pengkodean yang scalable atau progresif.

Pertentangan tersebut diakibatkan oleh adanya dinding diantara keduanya, yang disebut sebagai teorema shanon/nyquist, dan sebagai bahan renungan: mungkinkah dalam waktu dekat ini kita bisa membuat sistem pengkodean citra medik dengan rasio kompresi yang tinggi ( > 16 kali) dan hasil rekonstruksi citranya (hampir) sama dengan citra aslinya? BISA …. kalau saja dinding shanon/nyquist dapat dihancurkan. MUNGKINKAH ????

3 Tanggapan ke “Apakah Kompresi Citra Medik Diperlukan?”

  1. Arief berkata

    Mas, untuk citra medik memang harus online ya jika dikaitkan dgn telemedicine? Khan sudah ada teknologi kompresi .rar, .zip atau .7z yang mampu kompresi file jadi amat kecil. Kalau menurut saya, kompresi selalu dibutuhkan karena menghemat bandwidth dan imbasnya akan hemat cost juga ;) karena lebar kanal selalu ada batasnya.

  2. Yudhi berkata

    Ada kalanya.. kita mengingat, bahwa sebagian besar kaidah di IT (Information Technology) masih bersifat heuristik dan tidak memiliki pondasi teori yang kuat. Bukan berarti kaidah-kaidah itu salah, tetapi bahwa ternyata kaidah itu memiliki kondisi berlaku khusus yang biasanya tidak (belum) disebutkan. Semua kaidah IT sebenarnya bersifat kondisional, namun orang jarang mengattach kondisi secara lengkap ke masing2 kaidah. Mengapa aplikasi sebaiknya dibuat di atas platform Web standar (HTML/JavaScript)? Mengapa aplikasi lain ditulis dalam Java? Mengapa ada aplikasi yang idealnya ditulis dalam C++ ? Kapan kita gunakan client-server? Kapan kita gunakan three-tier? Kapan kita melakukan kompresi gambar? Kapan kita malah buat aplikasi seperti Mobile Google Maps untuk melihat gambar (umum) di server? Kapan kita malah buat device khusus dari nol untuk kepentingan ini..
    Tapi kayaknya, sebagian besar gambar di web bukan berwujud BMP. Kesimpulan saya ialah bandwidth merupakan sesuatu yang perlu dihemat. Lihat dari segi ini, bandwidth X tanpa kompresi dapat melayani 1 desa rural, bandwidth X dengan kompresi dapat melayani 16 desa rural.. Misalnya Bandwidth 20X dapat melayani satu rumah sakit, tanpa kompresi, maka tentunya kita dapat melayani 16 rumah sakit dengan kompresi?
    Tapi mungkin juga, ada cara menghemat bandwidth tanpa perlu menghilangkan informasi.. Misalnya konsep Mobile Google Maps tadi .. Hanya mendownload image yang perlu dilihat, dan user dapat memindahkan field-of-viewnya mendownload bagian lain dari image tsb, atau menzoom terhadap bagian tertentu sehingga mendownload image dengan resolusi lebih tinggi dari yang sedang ditampilkan. Ato jangan2 mas Tony sudah memikirkan hal itu?

  3. A.D Setiawan berkata

    Maaf ya baru merespon, kebetulan banyak kerjaan di lab.

    @ Arief
    Memang berbagai kompresi yang Anda sebutkan (entropy dan arithmatic coding) dapat memampatkan citra, tapi rasio kompresi yang dihasilkan hanya berada dalam kisaran maksimum 4 kalinya (maksudnya 4 x lebih kecil). Sedangkan algoritma kompresi JPEG, JPEG2000, SPHIT, VQ, dll menginginkan rasio kompresi yang lebih besar (belasan hingga puluhan kali) dengan cara mengeksploitasi redundansi dan irelevansi. Saya setuju bahwa bandwidth memang selalu ada batasnya, dan yg lebih penting lagi: orang selalu menginginkan kualitas yang lebih baik, seperti citra yg berkualitas lebih baik, video dengan fps yg lebih besar, dll. Akhirnya kompresi memang akan selalu dibutuhkan. Saya setuju dengan Anda :D

    @Yudhi
    Halo apa kabar Yud, seperti biasa ulasan Yudhi selalu komprehensif. Salut deh … Ya aku setuju sekali dengan komentarmu. Citra medik merupakan contoh kekhususan yang dirimu sebut di atas. Citra medis dibatasi oleh aspek legal; artinya informasi medik tidak boleh berubah, sebab hal ini memperngaruhi proses diagnosis dan terlebih lagi nyawa seseorang. Kebetulan penelitianku sekarang adalah mengembangkan algoritma kompresi untuk citra medik (dan tentu bisa juga untuk citra lain) dengan rasio kompresi yg tinggi, tetapi citra rekonstruksinya tetap memegang informasi2 medik seperti citra aslinya. Disertasiku bahkan mungkin dibilang rada2 ekstrim, karena mencoba melampaui batas entropy Shanon/Nyquist. Algoritma yg sudah kukembangkan adalah mengimplementasikan skema scalable, yg memungkinkan perbaikan kualitas citra di daerah yang diinginkan (sudah aku posting di postingan sebelumnya).

Tinggalkan Balasan

XHTML: Anda dapat gunakan tag ini: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>