Programu nyingi za wavuti bado hushughulikia upakiaji wa picha kama mfumo usiojulikana (black box). Mtumiaji anapakia faili, kivinjari kinakituma, na seva ama inakubali mzigo huo wa data au inatoa kosa la 413 ambalo hakuna aliyelitarajia. Kubana picha upande wa kivinjari (browser-side compression) kunabadilisha hali hii. Inakupa nafasi ya kupunguza ukubwa wa data kabla haijatumwa mtandaoni, jambo ambalo linamaanisha upakiaji wa haraka, gharama ndogo za bandwidth, na kupungua kwa muda wa seva kuisha (server timeouts). Lakini kazi hii ni rahisi kukosewa. Ukichukulia ukandamizaji kama kioleo cha kichawi kilichoandikwa "ubora" (quality), utatuma picha zilizoharibika, picha ndogo zilizovutwa vibaya, na uzoefu wa mtumiaji unaochanganya. Njia bora ni kuchukulia mchakato mzima kama mfumo wa hatua (pipeline).

Fikiria kama Mfumo wa Hatua, si kama Violeo vya Kurekebisha

Gawanya kazi katika hatua mbalimbali zinazojitegemea. Soma faili kutoka kwenye kipengele cha input. Punguza ukubwa wa picha hadi vipimo unavyotaka. Badili kuwa Blob mpya. Kisha onyesha matokeo kwa mtumiaji. Kila hatua inafanya jambo moja na kupitisha matokeo yake kwa hatua inayofuata. Mgawanyo huu si kwa ajili ya kuweka kodi safi tu. Unafanya majaribio ya vipande vya kodi (unit testing) kuwa rahisi. Unaweza kuingiza buffer inayojulikana kwenye hatua ya kupunguza ukubwa bila hata kugusa file input. Unaweza kuhakikisha kuwa kigeuzi chako (encoder) kinatoa JPEG chini ya 200 KB bila kusubiri mzunguko wa mawasiliano na seva. Kitu kinapoharibika, unajua hasa hatua ipi imefeli.

Kuweka majukumu haya tofauti pia kunazuia mambo yasiyotarajiwa wakati wa upakiaji. Ukijumuisha upunguzaji ukubwa na ukandamizaji (encoding) kwenye kazi moja iliyochanganyikana, kosa la ufunguzi (decoding error) katikati ya mchakato linaweza kuacha foleni yako ya upakiaji katika hali isiyo thabiti. Mfumo wa hatua unakulazimisha kuhakiki katika kila mpaka. Ikiwa faili haliwezi kufunguliwa, unaligundua kabla hata hujatengeneza canvas. Ikiwa Blob iliyokandamizwa ni kubwa mno, unaligundua kabla hujaomba seva itunze.

Weka Makubaliano Kabla ya Kuandika Kodi

Kabla ya mtu yeyote kuandika amri ya kuchora kwenye canvas, andika kanuni na uzishirikishe na timu. Chagua aina za MIME zinazokubalika. Je, utaruhusu JPEG, PNG, WebP, au AVIF? Kila moja ina athari kwa alpha channels, uwezo wa kivinjari, na gharama ya CPU. Weka ukubwa wa juu wa faili linaloingizwa. Picha mbichi ya 30 MB kutoka kwa simu ya kisasa itafanya laptop ya zamani iwe nzito au iweze kuzima ikiwa utajaribu kuifungua yote kwenye kumbukumbu (memory). Bainisha vipimo vya juu vya matokeo. Ikiwa UI yako haionyeshi picha zenye upana zaidi ya piksel 2048, hakuna sababu ya kuruhusu picha yenye upana wa piksel 6000 kupita kwenye mfumo.

Jambo la muhimu zaidi, panga kwa ajili ya makosa ya ufunguzi (decoding failures). Faili lililoharibika, wasifu wa rangi usio wa kawaida, au upakiaji uliokatika unaweza kusababisha hitilafu kwenye Image constructor. Mfumo wako unahitaji catch block iliyo wazi na ujumbe wa kosa unaosomeka kwa urahisi na binadamu. Usiruhusu kivinjari kifo kimya kimya na kumwacha mtumiaji akitazama alama ya mzunguko (spinner) wakati hakuna kinachotokea.

Iheshimu Picha

Picha iliyopindika inaonekana kama kazi ya mshamba. Zingatia uwiano wa upana na urefu (aspect ratio) na uweke kikomo kwenye upande mrefu zaidi. Ikiwa sanduku lako la lengo ni piksel 1024 kwa 1024, picha ya 4000 kwa 3000 inapaswa kuwa piksel 1024 kwa 768, siyo 1024 kwa 1024. Piga hesabu ya kiwango cha upunguzaji (scale factor) kutokana na upande mrefu na uache upande mfupi ufuate. Hii inazuia picha zisivutwe na kuwa na maumbo ya ajabu.

Kwa ajili ya usafirishaji (export) halisi, tumia njia ya canvas.toBlob. Inakupa udhibiti wa moja kwa moja juu ya muundo wa matokeo na mipangilio ya ubora, na inafanya kazi kwa njia isiyo ya moja kwa moja (asynchronously) ili usizuie mchakato mkuu (main thread). Tengeneza offscreen canvas, chora picha iliyopunguzwa ukubwa juu yake, kisha ita canvas.toBlob ukitumia aina na thamani ya ubora unayopendelea. Blob hiyo mpya ndiyo unayopitisha kwenye mantiki yako ya upakiaji au API ya hifadhi.

Onyesha Ushahidi

Ukandamizaji ni kazi isiyoonekana. Ikiwa hautatoa namba zinazoonekana, watumiaji hawatakuamini mchakato huo. Jenga kiolesle (interface) kinachowaruhusu kulinganisha picha ya asili na matokeo. Onyesha ukubwa wa faili ya asili, ukubwa wa faili mpya, vipimo vipya, na aina ya muundo wa mwisho. Kuona picha ya simu ya 4.2 MB ikishuka hadi 380 KB WebP kunaondoa hofu kwamba unaharibu picha yao kwa siri.

Uwazi huu pia husaidia katika kutatua matatizo. Mtumiaji anapolalamika kuwa upakiaji umefeli, jambo la kwanza utakaloangalia ni kama vipimo vya matokeo vilizidi kikomo cha seva yako, au kama muundo ulibadilika kutoka PNG kwenda JPEG na kupoteza alpha channel. Weka data hiyo kwenye UI ili mtumiaji aweze kutambua tatizo mwenyewe kabla ya kufungua tiketi ya msaada.

Mipangilio ya Awali ni Bora kuliko Kubana Upya

Usikandamize picha moja mara mbili. Kila mara inapopita kwenye kigeuzi cha kupoteza ubora (lossy encoder), inapoteza maelezo zaidi na kuleta picha zenye madoa (blocky artifacts). Ukimruhusu mtumiaji kubonyeza "optimize" mara kwa mara, toleo la tatu litafanana na nakala ya photocopy ya photocopy nyingine. Badala yake, tengeneza kila matokeo kutoka kwenye faili ya asili na toa mipangilio ya awali (presets):

  • Faili ndogo: Punguza ubora na uweke kikomo cha vipimo kwa ukali kwa ajili ya picha ndogo (thumbnails) au maonyesho ya haraka.
  • Iliyobalansiwa: Lenga kiwango cha ubora cha wastani kikiwa na vipimo vinavyofaa, kinachofaa kwa mitandao ya kijamii na maktaba za picha.
  • Maelezo zaidi: Weka ubora ukiwa juu na uhifadhi vipimo vikubwa kwa ajili ya upigaji picha, kazi za sanaa, au maonyesho ya uchapishaji.

Hifadhi Blob ya asili kwenye kumbukumbu ili mtumiaji aweze kubadilisha kati ya mipangilio (presets) bila kuongeza mfululizo wa upotevu wa ubora. Daima tengeneza kutoka kwenye chanzo, kamwe usitengeneze kutoka kwenye matokeo ya mwisho.

Jaribu Kama Watumiaji Wako Wanavyopandisha Faili

Mashine yako ya maendeleo yenye muunganisho wa fiber na RAM ya 32 GB siyo uhalisia. Jaribu kwa kutumia faili halisi ambazo watumiaji wa kweli wanatumia. Picha za simu kutoka iOS na Android hutumia mwelekeo tofauti wa metadata na zinaweza kutokana na vyanzo vya HEIC. Vitu vya uwazi (transparent assets) kama vile nembo na ikoni hutenda tofauti wakati wa ubadilishaji wa JPEG kwa sababu JPEG haikubali kabisa njia za alpha (alpha channels). Faili kubwa zitafichua mipaka ya kumbukumbu kwenye vifaa vyenye RAM ya 2 GB. CPU za simu zenye kasi ndogo zitadhihirisha kwa usahihi jinsi mwito huo wa toBlob unavyochukua muda.

Tumia Chrome DevTools kupunguza kasi ya CPU na mtandao. Jaribu simu ya Android ya miaka mitano iliyopita. Ikiwa mchakato wako unazuia UI kwa sekunde tatu wakati wa kuandika (encoding), unahitaji kuhamisha kazi nzito kwenye Web Worker ili kiolesura (interface) kibaki kinachoitikia haraka.

Toa Mambo ya Msingi Kwanza

Ni rahisi kushawishika kusaidia kila muundo na