Ubah Ukuran Gambar

Mengapa memperkecil sekaligus hasilnya buruk

Saat browser menggambar gambar besar ke ruang yang jauh lebih kecil dalam satu langkah, browser hanya mengambil sampel sejumlah piksel sumber dan mengabaikan sisanya. Detail yang berada di antara sampel tidak dirata-ratakan, melainkan dibuang, dan hasilnya adalah aliasing: garis diagonal bergerigi, tekstur halus yang berkedip, dan teks yang berubah menjadi noise. Inilah sebabnya gambar yang diperkecil hanya dengan atribut width biasanya terlihat lebih buruk daripada gambar yang sama yang diperkecil dengan editor gambar.

Solusi yang dipakai di sini adalah membagi dua gambar berulang kali dan baru mengambil langkah kecil terakhir di akhir. Setiap pembagian dua merata-ratakan kelompok empat piksel, sehingga saat ukuran target tercapai, setiap piksel output berasal dari seluruh area yang diwakilinya, bukan dari satu sampel sembarang di dalamnya. Prinsipnya sama dengan mipmapping dalam grafika komputer, dan pada pengecilan yang besar perbedaannya tidak samar.

Alat khusus melangkah lebih jauh dengan filter Lanczos atau sejenisnya, yang menimbang area sekitar yang lebih luas dan mempertahankan sedikit lebih banyak ketajaman yang terlihat. Pembagian dua berturut-turut sudah cukup dekat sehingga perbedaannya sulit dilihat pada foto, dan cukup cepat untuk langsung ditampilkan pratinjaunya di ponsel.

Memilih ukuran target

Tentukan ukuran berdasarkan tempat gambar akan ditampilkan, lalu perhitungkan kepadatan piksel. Foto yang tampil selebar 800 piksel CSS di halaman memerlukan sekitar 1600 piksel agar tajam di ponsel atau laptop modern, yang memiliki dua piksel perangkat per piksel CSS. Di atas 2x, peningkatan yang terlihat sangat kecil sementara biaya ukuran file-nya besar.

Untuk halaman yang melayani banyak perangkat, jawaban yang lebih baik adalah menyediakan beberapa ukuran dengan atribut srcset dan membiarkan browser memilih. Lebar umum 640, 960, 1280, dan 1920 mencakup sebagian besar tata letak. Untuk email, cukup sekitar 600 piksel. Untuk dokumen atau slide, sesuaikan dengan ukuran penempatannya dikali 2.

Jangan pernah memperbesar demi mencapai target. Memperbesar hanya mengarang piksel yang tidak pernah difoto; gambar yang lembut menjadi lebih besar dan lebih lembut, dan file-nya membesar tanpa manfaat. Jika sesuatu harus lebih besar dari sumbernya, yang harus diganti adalah sumbernya.

Batas atas, dan mengapa ada

File diterima hingga 30 MB, dan gambar hingga sekitar 16,7 juta piksel - kira-kira 4000 kali 4000, atau bentuk lain dengan total luas yang sama.

Batas itu berasal dari canvas browser, bukan kebijakan sembarangan. Safari di iOS khususnya membatasi luas area yang boleh dicakup canvas, dan kegagalan di atas batas itu adalah jenis yang paling buruk: tanpa error, tanpa exception, hanya gambar putih kosong yang dikembalikan seolah semuanya berhasil. Agar hal itu tidak terjadi, apa pun yang melebihi batas ditolak disertai penjelasan. Jika Anda punya ekspor RAW 50 megapiksel untuk diperkecil, editor gambar desktop adalah alat yang tepat.

Batas yang sama menjadi alasan batch diproses satu gambar demi satu, bukan secara paralel. Gambar yang sudah didekode menempati lebar kali tinggi kali empat byte di memori, sekecil apa pun file terkompresinya, sehingga memproses beberapa gambar besar sekaligus adalah hal yang membuat browser ponsel menutup tab.

Mengubah ukuran, memotong, atau mengompresi

Ketiganya menyelesaikan masalah yang berbeda dan sering tertukar ketika tujuan sebenarnya adalah file yang lebih kecil.

Mengubah ukuran mengubah jumlah piksel dan sejauh ini merupakan cara paling efektif untuk memengaruhi ukuran file, karena efeknya kuadratik - membagi dua lebar dan tinggi membuat jumlah piksel tinggal seperempat. Yang terlihat pada ukuran penuh berubah, tetapi seluruh bingkai tetap utuh.

Memotong (crop) mengubah apa yang ada di dalam bingkai. Ini juga mengurangi piksel, tetapi merupakan keputusan komposisi, bukan teknis, dan tidak bisa dibatalkan.

Mengompresi mengubah seberapa presisi piksel yang ada disimpan, yaitu pengaturan kualitas di alat konversi gambar. Dimensinya tidak berubah, dan ketepatan ditukar dengan ukuran.

Untuk foto yang terlalu berat untuk halaman web, urutan yang berhasil adalah ubah ukuran ke ukuran tampil terlebih dahulu, lalu encode sebagai WebP atau JPG dengan kualitas yang wajar. Melakukan langkah kedua saja biasanya menyia-nyiakan sebagian besar penghematan.

Mengapa memperkecil gambar butuh filter

Memperkecil gambar berarti menjawab satu pertanyaan untuk setiap piksel keluaran: warna apa yang mewakili wilayah ini pada gambar asli. Mengambil piksel sumber terdekat dan mengabaikan tetangganya adalah jawaban termurah sekaligus terburuk, karena detail yang jatuh di antara titik-titik pengambilan sampel dibuang begitu saja alih-alih dirata-ratakan, dan detail yang dibuang itu muncul kembali sebagai pola yang sebenarnya tidak pernah ada di foto tersebut.

Itulah aliasing, dan gejalanya sama dengan roda pedati yang tampak berputar mundur di film. Mengambil sampel pada laju yang lebih rendah daripada yang dituntut detailnya tidak membuat detail itu hilang diam-diam; detail tersebut terlipat kembali ke dalam gambar sebagai pola palsu berfrekuensi lebih rendah. Tekstur halus jadi berkelip, garis diagonal jadi bertangga, dan teks kecil berubah menjadi derau.

Perbaikannya adalah merata-ratakan seluruh area yang diwakili setiap piksel keluaran, dan tiap filter memberi bobot pada rata-rata itu dengan cara berbeda. Rata-rata kotak sederhana dan hasilnya sedikit lembut; Lanczos memberi bobot pada lingkungan yang lebih luas dengan kurva berbasis sinc dan mempertahankan lebih banyak ketajaman yang terasa, dengan konsekuensi munculnya ringing tipis di dekat tepi yang keras. Pengurangan separuh secara berulang, yang dipakai di sini, mencapai hasil yang hampir sama dengan biaya jauh lebih kecil.

Ukuran, rasio aspek, dan pemotongan

Mengubah ukuran mempertahankan keseluruhan bingkai dan hanya mengubah berapa banyak piksel yang menggambarkannya. Memotong mengubah bingkainya. Mencampuradukkan keduanya menghasilkan gambar-gambar gepeng yang sering terlihat di situs yang dibuat asal-asalan, ketika foto lebar dipaksa masuk ke wadah persegi karena kedua dimensinya diatur sendiri-sendiri.

Bila tata letak menuntut bentuk yang tetap, potonglah dengan sengaja alih-alih menarik gambarnya. CSS object-fit dengan cover melakukan ini di peramban dan sudah memadai untuk gambar dekoratif; tetapi untuk apa pun yang subjeknya penting, memotong lebih dulu memberi Anda kendali atas apa yang tetap berada dalam bingkai. Pemotongan tengah otomatis dengan sangat konsisten memenggal kepala orang dalam foto bersama.

Art direction adalah kasus ketika satu potongan saja tidak cukup: gambar utama yang lebar dan bekerja baik di desktop sering memerlukan potongan potret yang lebih rapat di ponsel, bukan sekadar versi lebih kecil dari bingkai yang sama. Untuk itulah elemen picture dengan media condition ada, berbeda dari srcset yang menyajikan potongan yang sama dalam berbagai ukuran.

Bobot gambar dan harganya bagi sebuah halaman

Gambar biasanya adalah hal terbesar yang diunduh sebuah halaman, dan largest contentful paint - salah satu metrik yang dilaporkan Google dalam Core Web Vitals - sangat sering berupa gambar. Setiap kilobyte yang tidak perlu dalam satu berkas itu menunda saat halaman terlihat sudah selesai dimuat.

Anggaran yang masuk akal adalah menjaga gambar utama di bawah sekitar 200 KB dan membuat segala sesuatu di bawah layar pertama jauh lebih kecil, dan itu bisa dicapai dengan pengaturan kualitas biasa begitu ukurannya sudah tepat. Menyajikan foto 3 MB lalu membiarkan CSS mengecilkannya adalah masalah performa paling umum di situs berbasis konten, dan itu merampas kuota data pengunjung sekaligus waktunya.

Separuh lainnya adalah kestabilan tata letak. Gambar tanpa width dan height yang dideklarasikan tidak menyisakan ruang, sehingga teks di bawahnya melompat ketika gambarnya datang. Menetapkan kedua atribut itu, atau aspect-ratio di CSS, adalah perubahan satu baris yang menghapus satu kategori cacat visual secara utuh.

Mengubah ukuran banyak gambar sekaligus

Untuk beberapa berkas saja, alat di peramban adalah jalur tercepat. Lewat dari beberapa lusin, atau sebagai bagian dari proses build, alat yang bisa diskripkan lebih baik: mogrify -resize 1600x -quality 82 *.jpg milik ImageMagick menangani satu direktori dalam satu perintah, sedangkan sharp, libvips, atau Pillow melakukan hal yang sama di dalam pipeline Node atau Python dengan pemakaian memori jauh lebih rendah daripada reputasinya.

Dua kebiasaan bisa mencegah kecelakaan yang biasa terjadi. Bekerjalah pada salinan, karena mogrify secara bawaan menimpa berkas di tempat dan tidak ada tombol undo. Lalu gunakan batasan lebar saja seperti 1600x, bukan ukuran tetap, supaya gambar potret maupun lanskap sama-sama tertangani tanpa menjadi gepeng.

Untuk situs yang menerima unggahan pengguna, pengubahan ukuran sebaiknya dilakukan sekali saat berkas masuk, bukan pada setiap permintaan, dan simpan aslinya kalau nanti Anda mungkin memerlukan ukuran lain. Menurunkan berbagai ukuran sesuai kebutuhan lewat CDN gambar adalah arsitektur lain yang masuk akal; melakukannya di halaman dengan CSS tidak, karena berkas utuhnya tetap diunduh.

Memperbesar gambar, dan apa yang diubah alat AI

Memperbesar gambar tidak bisa mengembalikan detail yang memang tidak pernah terekam. Interpolasi klasik - bilinear, bicubic, Lanczos - membuat gambar yang lebih besar dan mulus dari informasi yang sama, dan hasilnya terlihat lembek karena memang lembek. Itu bukan kekurangan algoritmanya; informasinya sungguh-sungguh tidak ada.

Pembesar berbasis machine learning menghasilkan sesuatu yang lebih tajam dengan mengarang detail yang masuk akal berdasarkan apa yang pernah dilihatnya. Untuk wallpaper atau cetakan foto liburan, itu sering kali persis yang Anda inginkan. Tetapi untuk apa pun yang bersifat pembuktian - pindaian dokumen, foto produk yang akan dijadikan pegangan pelanggan, gambar dalam sebuah laporan berita - ini masalah serius, karena detail tambahan itu hanyalah tebakan yang disajikan dengan keyakinan yang sama seperti piksel aslinya.

Aturan yang bisa diandalkan tetap sama: perbaiki sumbernya. Ekspor ulang dari berkas aslinya, pindai ulang pada resolusi lebih tinggi, atau mintalah materinya dalam ukuran yang Anda perlukan. Selain itu, semuanya hanyalah perbaikan dengan bahan yang dikarang.