Paket revisinya masuk sekaligus lewat WhatsApp, lebih dari 15 item, campuran bug, urusan UX, terjemahan, dan permintaan fitur baru, dan semuanya harus ditriase di bawah kenyataan anggaran 7 juta rupiah. Baris nomor 8 di tabel triase saya isinya pendek: intro video atau hero pecah di mobile, kategori Asset upgrade. Yang menandai itu klien, bukan saya, dan yang dia tunjuk spesifik, yaitu urutan bingkai hero di homepage yang jalannya digerakkan scroll.
Kata "upgrade" di kategori itu menjanjikan ada master yang lebih baik untuk diambil dari suatu tempat. Waktu saya cari, tidak ada. Berkas webp yang duduk di disk itulah satu-satunya master yang tersedia: lossy, 1920x1004, VP8 di kualitas sekitar 75 sampai 80, totalnya sekitar 25MB untuk 196 bingkai. Tidak ada folder PNG asli di belakangnya. Jadi jalannya tinggal satu, yaitu menambah piksel ke bahan yang sudah terlanjur dikompresi, dan untuk itu saya butuh upscaler berbasis model.
Modelnya jalan sampai selesai, hasilnya bergaris
Titik awal yang wajar untuk bahan foto adalah realesrgan-x4plus, model serba guna yang biasanya dipakai duluan. Upscale urutan 196 bingkai hero dengan model itu selesai tanpa error, dan hasilnya membawa artefak garis tile yang kelihatan.
Kalau belum pernah ketemu bentuknya, mekanismenya begini. Upscaler ncnn memotong gambar jadi petak-petak supaya muat di memori GPU, memproses tiap petak, lalu menjahitnya kembali jadi satu bingkai. Waktu jahitan itu tidak benar-benar menyatu, sisanya adalah kisi garis tipis yang persis mengikuti batas petak, dan kisi itu paling gampang terbaca di area yang datar seperti langit atau bidang dinding polos.
Catatan yang saya tinggalkan waktu itu menyebut garisnya muncul pada build biner yang saya pakai, bukan sebagai sifat model x4plus secara umum. Catatan yang sama menuduh penyebabnya bug yang sudah dikenal di build biner Windows Real-ESRGAN-ncnn-vulkan v0.2.x, tapi tidak ada satu pun nomor issue atau rujukan yang saya sertakan di sana. Jadi perlakukan bagian penyebabnya sebagai dugaan yang saya tulis sendiri, bukan sesuatu yang sudah diverifikasi.
Yang tidak perlu ditebak adalah versinya. Biner yang saya jalankan Real-ESRGAN-ncnn-vulkan v0.2.5.0, bundel Windows yang modelnya sudah ikut di dalam, diambil dari repo utama xinntao/Real-ESRGAN. Ini bukan repo Real-ESRGAN-ncnn-vulkan yang dikirim tanpa model, dan perbedaan itu layak dipastikan sebelum mengunduh apa pun.
Device 0 ternyata bukan kartu yang saya kira
Driver NVIDIA dan Vulkan SDK sudah terpasang di mesin itu, dan binernya mendeteksi dua perangkat sendiri, RTX 5060 dan Intel iGPU. Sampai situ semuanya terdengar beres.
Yang tidak saya duga, secara bawaan dia memilih Intel iGPU sebagai device 0, bukan GPU NVIDIA-nya. Tidak ada peringatan, tidak ada pertanyaan, dan kalau keluaran deteksinya cuma dilewati sekilas, seluruh pekerjaan ini akan berjalan di kartu yang salah tanpa pernah mengumumkan apa-apa. Jadi GPU NVIDIA saya paksa lewat flag -g 1, dan GPU itu adalah NVIDIA RTX 5060 Laptop GPU.
Satu batas yang jujur perlu saya sebut: catatan dari pekerjaan ini tidak memuat waktu jalan di kedua device, jadi tidak ada angka percepatan yang bisa saya tunjukkan di sini. Yang bisa saya katakan cuma bahwa device bawaannya bukan device yang saya maksud.
Perintah yang akhirnya dipakai
Modelnya saya tukar ke realesr-animevideov3, dan garis tile-nya tidak muncul lagi.
# x4plus -> tile seams (v0.2.x binary bug); use animevideov3 + force NVIDIA:
realesrgan-ncnn-vulkan -n realesr-animevideov3 -s 2 -g 1 ...Dengan -s 2, 196 bingkai itu selesai dalam 57 detik, sekitar 0,3 detik per bingkai. Angkanya gampang diperiksa sendiri, 57 dibagi 196 keluar di 0,29 detik.
Dua catatan kecil soal lingkungannya, karena keduanya menentukan apakah perintah di atas bisa langsung jalan besok. Binernya saya ekstrak ke folder sementara, dan itu sengaja tercatat, karena begitu folder sementara itu ikut kena bersih-bersih, binernya harus diunduh ulang dari nol. ffmpeg-nya sendiri hasil pasang WinGet dan memang sudah tersedia di mesin, jadi tahap berikutnya tidak menambah instalasi apa pun.
Naik ke 3840, lalu turun lagi ke 2560
-s 2 di atas master 1920x1004 memberi 3840x2008. Itu perkalian lurus, 1920 dikali 2 sama dengan 3840, dan 1004 dikali 2 sama dengan 2008.
Hasil itu tidak dipakai apa adanya. Saya turunkan lagi ke 2560x1338 dengan lanczos, alasannya mengejar target lebar 2K sambil mempertahankan rasio bingkai aslinya. Penurunannya bisa diulang siapa saja: 2560 dibagi 3840 sama dengan dua pertiga persis, dan 2008 dikali dua pertiga keluar di 1338,67 yang jatuh ke 1338. Rasionya memang terjaga, karena 1920 dibagi 1004 sama dengan 1,912 sementara 2560 dibagi 1338 sama dengan 1,913.
Digabung, dua langkah itu kali 2 lalu kali dua pertiga, yang sama dengan kali empat pertiga. Jadi bingkainya tidak pernah dua kali lipat, dia naik sepertiga dari aslinya.
ffmpeg ... -vf scale=2560:1338:flags=lanczos # then webp q92WebP-nya di-encode ulang di kualitas 92 dengan threads auto, dan 196 bingkai selesai dalam 45 detik. 45 dibagi 196 keluar di 0,23 detik per bingkai, jadi kedua tahap digabung memakan 57 ditambah 45 sama dengan 102 detik, satu menit lewat 42 detik untuk seluruh set. Kualitas 92 itu sendiri naik dari sekitar 75 sampai 80 yang dibawa aset lamanya, jadi detail hasil upscale tidak langsung dibuang lagi oleh encoder di langkah terakhir.
Yang berubah, dan yang sengaja tidak disentuh
Efek bersihnya dua angka. Dimensinya naik dari 1920x1004 ke 2560x1338, dan total ukurannya dari 25MB ke 50MB. Lebarnya naik sepertiga, karena 2560 dibagi 1920 sama dengan 1,333, sementara ukurannya persis dua kali lipat. Diratakan per bingkai, 25MB dibagi 196 keluar di sekitar 128KB dan 50MB dibagi 196 keluar di sekitar 255KB. Yang saya catat waktu membandingkan hasilnya adalah tekstur yang terlihat lebih tajam dan pemulihan detail yang lebih rapat di vegetasi, beton, dan pantulan kaca.
Sisi JavaScript-nya tidak saya ubah sama sekali. Canvas-nya sudah menyesuaikan skala sendiri lewat Math.max, jadi bingkai yang lebih besar cuma memberi ruang piksel lebih di layar retina dan 2K, tanpa satu baris pun perlu digeser. Satu-satunya sentuhan di kode adalah komentar header di berkas skrip hero, yang saya perbarui supaya pipeline barunya terdokumentasi dan siapa pun yang memegang berkas ini berikutnya tahu cara membangun ulang setnya.
Pekerjaannya dikirim sebagai rilis 1.11.3 lewat commit ef45781, dan lewat rilis itulah item nomor 8 di tabel triase ditutup. Sebelas item yang memang dikerjakan dari paket revisi tadi diverifikasi dengan klik lewat Playwright di breakpoint desktop dan mobile.
Yang saya bawa dari kasus ini
- Dua hambatan di pekerjaan ini datang dari tempat yang sama, yaitu nilai bawaan, dan dua-duanya salah untuk pekerjaan yang sedang saya lakukan. Model bawaannya meninggalkan garis, device bawaannya bukan GPU yang saya kira, dan tidak satu pun dari keduanya melempar error.
- Baca keluaran deteksi perangkatnya sebelum menekan enter.
-g 1cuma berarti kalau daftar device yang dicetak binernya benar-benar dilihat dulu. - Kalau
x4plusmeninggalkan kisi garis di build yang kamu pakai,realesr-animevideov3layak dicoba sebelum sibuk mengutak-atik ukuran petak. - Kategori "asset upgrade" belum tentu berarti ada master yang lebih bagus. Cek dulu apa yang benar-benar ada di disk, karena itu yang menentukan seluruh strategi berikutnya.
- Upscaler tidak mengembalikan detail yang memang tidak pernah ada di master lossy 1920x1004. Yang dia lakukan menebak dengan lebih rapi, dan untuk keluhan yang bunyinya "pecah di mobile", tebakan yang lebih rapi ternyata cukup untuk menutup itemnya.
- Kalau klien nanti mengirim video intro beresolusi lebih tinggi, rencananya tetap sederhana: asetnya ditukar, lalu setnya dibangun ulang.