Format Berkas Perantara untuk Komposit Render

02.05.11

Kategori: Blender

Saya masih meraba-raba cara kerja paling efisien dan fleksibel untuk mengolah komposit gambar menggunakan Blender. Proses render+komposit yang terakhir saya jalankan cukup fleksibel, tapi masih jauh dari efisien. Untuk animasi di bawah 2 menit, data yang harus saya kelola (termasuk berkas-berkas perantara) mencapai 60GB, dan di-render seminggu lebih dengan 4-5 komputer. Sangat tidak efisien untuk alur produksi serial animasi sebuah studio kecil. Proses optimasi yang saya bahas di sini berfokus pada format gambar yang dihasilkan proses render, sebagai input proses komposit.

Seperti tulisan sebelumnya, saya masih meminta agar rekan-rekan mempertimbangkan penggunaan OpenEXR, tapi sekarang dengan sedikit caveat. Sebagai ilustrasi, berikut output perangkat identify (bagian dari ImageMagick), untuk berkas-berkas hasil render adegan yang sama dalam beberapa format:

adhi@thinkpadr61i-adh:~/Desktop
$ for i in cube.*; do identify $i; done
cube.exr EXR 960x540 960x540+0+0 16-bit DirectClass 3.813MiB 0.010u 0:00.000
cube.png PNG 960x540 960x540+0+0 8-bit DirectClass 124KiB 0.030u 0:00.040
cube.tga TGA 960x540 960x540+0+0 8-bit DirectClass 1.483MiB 0.070u 0:00.079
cube.tif TIFF 960x540 960x540+0+0 8-bit DirectClass 116KiB 0.000u 0:00.000
adhi@thinkpadr61i-adh:~/Desktop
$

Setiap file tersebut sama-sama didapatkan dari prosedur Save Render Result, tanpa diolah kompositor atau program lain. Terlihat bahwa format OpenEXR sebagaimana didukung Blender menyimpan citra dalam pita data yang lebih lebar (16-bit) ketimbang format lain, meski semua format gambar tersebut menyediakan varian sampai 32-bit linear. Pertanyaannya kemudian adalah, apakah keunggulan relatif OpenEXR ini sepadan dengan hasil yang diinginkan? Untuk proyek-proyek yang telah dan akan kami tangani dalam waktu dekat ini, sepertinya belum. Kami belum menangani efek visual dan tidak mengejar kualitas visual realistik, apa lagi jika ia membuat proses pasca-produksi menghabiskan waktu terlalu lama.

Akhirnya setelah ditimbang-timbang, untuk proyek animasi selanjutnya sepertinya TARGA/TIFF/PNG sudah memadai :) OpenEXR akan tetap digunakan saat perlu Z-index, karena percobaan menyimpan Z-depth dalam format lain sering gagal (terjadi clipping). Berikut pemecahan render pass yang baru saya coba:

Untuk mayoritas render pass yang diperlukan, format output adalah TARGA. Patokan saya saat ini, bila informasi yang diperlukan bersifat visual (dapat langsung terlihat lewat penampil gambar biasa) dan tidak perlu dynamic range lebar, TARGA cukup aman untuk digunakan. Contohnya pass vektor normal (kiri), yang dapat digunakan untuk menciptakan pencahayaan semu setelah proses render (kanan):

Di sisi lain, untuk informasi citra yang bersifat non-visual seperti vektor kecepatan atau informasi visual yang perlu dynamic range lebar, OpenEXR tetap pilihan yang paling aman untuk mempertahankan presisi/detail informasi. Contohnya pass faktor kabut yang mengalami efek pita karena berkurang jauh presisinya, saat disimpan dalam format TARGA (kanan) ketimbang format OpenEXR (kiri):

Saya baru tahu bahwa prosedur pemisahan komponen render seperti ini umum digunakan studio animasi dan efek visual saat membaca buku Lee Lanier, "Professional Digital Compositing", dalam bab mengenai render CG. Hanya saja masih perlu eksperimen sendiri untuk mengetahui sampai mana ia dapat diterapkan dalam alur produksi berbasis software open source.

Sudah tersiar kabar, bahwa proyek terbuka Blender Institute selanjutnya akan berfokus mengasah kemampuan Blender di bidang efek visual. Mungkin kita dapat berharap, selepas proyek ini, Blender dapat memanfaatkan kemampuan maksimal masing-masing format gambar. Dengan implementasi Blender yang sudah ada, saya mulai mendapat gambaran, apa kira-kira format file yang tepat untuk hasil render terbaik: format OpenEXR untuk pass render non-visual dan citra high dynamic range imaging, dan format lain (terutama TARGA/TIFF/PNG) untuk pass visual yang tidak perlu presisi tinggi.