Badilisha muundo wa picha _

Jinsi ubadilishaji wa picha unaotegemea kivinjari unavyofanya kazi

Kila ubadilishaji ni bomba la hatua nne linaloenda kwenye kivinjari chako. Kwa JPEG na PNG, Canvas API yenyewe ya kivinjari hushughulikia usimbaji moja kwa moja. Kwa WebP kwenye Safari na AVIF kwenye kila kivinjari, ukurasa hupakia kodeki nyepesi ya WebAssembly inapohitajika — bado yote ndani ya kifaa, picha zako hazitoki kwenye kifaa kamwe.

1. Soma kila faili iliyopakiwa kama Blob na utengeneze URL ya kitu ili kivinjari kisimbue ndani ya kompyuta, bila kunakili baiti kwenye seva au kuzihifadhi kwenye diski.
2. Chora picha iliyosimbuliwa kwenye kipengele cha Canvas kisichoonekana, ukitumia kizuizi chochote cha kubadilisha ukubwa ukihifadhi uwiano wa asili wa kipengele. Ukichagua upana wa juu au kipimo cha juu, hapa ndipo kupungua kwa ukubwa kunatokea.
3. Piga canvas.toBlob(callback, targetMimeType, quality) ili kusimba upya saizi kwa PNG, JPEG na Chrome/Firefox WebP. Kwa Safari WebP na usimbaji AVIF, mfanyakazi wa kodeki ya WebAssembly hupakia wakati wa matumizi ya kwanza na hushughulikia usimbaji katika uzi wa nyuma. Pato la PNG ni lisilo na hasara kila wakati; JPEG, WebP na AVIF hufuata kitelezi cha ubora, ambacho huramani moja kwa moja kwenye mpangilio wa upimaji wa kisimbaji.
4. Onyesha picha ndogo ya kabla/baada na vipimo vya matokeo na ukubwa wa faili, kisha toa kitufe cha upakuaji kwa kila picha au ZIP moja kwa kundi lote. ZIP inajengwa kwenye kumbukumbu ukitumia fflate, maktaba ya KB 8 inayofanya kazi kabisa kwenye kichupo.

Kwa nini kubadilisha muundo wa picha?

• Kubadilisha kutoka PNG kwenda WebP hupunguza ukubwa wa kawaida wa faili kwa asilimia 25 hadi 35 bila kupoteza ubora unaoonekana kwa ubora wa 0.8, ambayo hupunguza uzito wa ukurasa moja kwa moja na kuboresha alama za LCP za Core Web Vitals. Kwenye ukurasa wa kawaida wa maelezo ya bidhaa wenye picha nane za kishujaa, hiyo ni tofauti kati ya uchoraji wa kwanza wa MB 4 na wa MB 2.6.
• PNG huhifadhi uwazi ambapo JPEG huuondoa. Kwenda PNG kwenda JPEG huwakilisha pikseli za uwazi dhidi ya mandharinyuma nyeupe, ambayo ni hasa unachotaka wakati marudio (mteja wa barua pepe, CMS ya zamani, kiolezo cha uchapishaji) hawezi kukubali PNG kwanza kabisa.
• Majukwaa ya kijamii na mitandao ya matangazo yana mahitaji madhubuti ya muundo. Facebook na LinkedIn wanapendelea JPEG kwa upakiaji wa picha, pipeline ya hakiki ya OG ya Twitter inakubali WebP, na seva fulani za matangazo ya programu zinakataa chochote ambacho si JPEG. Upitio wa haraka wa ubadilishaji kabla ya kupakia huepuka ping-pong ya ubunifu uliokataliwa.
• Kufanya picha nyingi za muundo mchanganyiko (picha ndogo za PNG, picha za JPEG, usafirishaji wa WebP kutoka kwa msanifu) kuwa muundo mmoja wa matokeo kabla ya kupakia kwenye CMS au DAM huondoa matawi ya kushughulikia muundo kutoka pipeline ya kuingiza. Muundo mmoja ndani, muundo mmoja nje, njia chache sana za msimbo wa masharti chini ya mkondo.

Matumizi ya kawaida

Ubadilishaji wa muundo unatokea kila wakati muundo wa chanzo na matarajio ya marudio hayalingani. Mifumo mitatu tunaona mara kwa mara.

• Kuandaa picha za bidhaa kwa duka la Shopify au WooCommerce. Asili za JPEG zinabadilishwa kwenda WebP kwa ubora wa 0.85 kwa duka la umma, wakati nakala za PNG zinawekwa kando kwa usafirishaji uliokusudiwa kuchapishwa na orodha za soko ambazo bado zinakataa WebP.
• Kubadilisha usafirishaji wa PNG uliosaidiwa na msanifu kwenda JPEG au WebP kabla ya kuingia kwenye ujenzi wa React au Next.js. Pipeline ya picha ya mfumo huchukua chanzo kidogo zaidi na vifurushi vya uzalishaji husafirisha baiti chache zaidi kwa kila njia.
• Kuchakata kwa wingi folda ya picha ndogo za skrini kutoka safari ya QA. PNG kwenda JPEG kwa ubora wa 0.9 kwa kawaida hupunguza hifadhi ya picha ndogo 50 kutoka karibu MB 120 hadi chini ya MB 20 kabla ya kuambatanishwa kwenye tikiti ya kifuatilia hitilafu.

Mfano uliofanyiwa kazi: PNG ya MB 2 kwenda WebP ya KB 300

Picha ya kishujaa ya PNG ya MB 2 yenye pikseli 2400×1600 ni mzigo wa kawaida kwenye kurasa za kutua za uuzaji. Ni kipimo kizuri cha kile ubadilishaji huokoa kwenye ukurasa wa kweli.

Tupa PNG kwenye eneo la upakiaji, chagua WebP kama muundo wa marudio, weka ubora kwenye 0.8, na weka upana wa juu kwenye 1200 kupunguza vipimo vya pikseli nusu. Pipeline ya Canvas huchora picha kwa 1200×800 ukiwa na uwiano umehifadhiwa, kisha husimba upya kwenda WebP. Kadi ya matokeo inaonyesha matokeo, kwa kawaida katika safu ya KB 280 hadi 320, ambayo ni kupunguzwa kwa takriban asilimia 85 dhidi ya asili. Bonyeza Pakua kwenye kadi kupata faili moja, au bonyeza Pakua .zip chini ya paneli ukibadilisha picha kadhaa kwa upitio mmoja. Safari nzima, kutoka kutupa hadi kupakua, inafanya kazi katika milisekunde chache mia kwa picha ya ukubwa huu na hutumia upana wa bendi sifuri baada ya ukurasa wenyewe kukamilika kupakia.

Muundo gani unasaidiwa?

Kwa upande wa ingizo, umbiza lolote ambalo kivinjari linaweza kusimbua linakubaliwa: PNG, JPEG, WebP, GIF na BMP hufunika takribani kila faili ambayo mbunifu au zana ya picha ya skrini hutoa. Umbiza la pato ni PNG (lisilo na hasara kila wakati), JPEG, WebP na AVIF. Pato la AVIF linaungwa mkono kupitia kisimbaji cha WebAssembly kinachopakia inapohitajika katika kila kivinjari — hakuna kisimbaji cha asili cha Canvas kinachohitajika.

Je, hii inafanyika kwenye kifaa changu?

Ndio, kabisa. Ukurasa hutumia Canvas API asili ya kivinjari na Web File API kusimbua na kusimba upya kila picha kwenye kumbukumbu. Hakuna data ya picha inayotumwa kwa seva, hakuna upakiaji wa muda, hakuna safari ya pande zote ya wingu. Unaweza kuithibitisha mwenyewe: fungua DevTools, nenda kwenye paneli ya Mtandao, na endesha ubadilishaji. Maombi pekee ya kutoka nje utakayoyaona ni upakiaji wa kwanza wa ukurasa na wito wa matangazo. Hakuna kitu chenye sura ya picha kinachotoka kwenye kichupo.

Je, mfumo wa ubora kati ya PNG na JPEG ni upi?

PNG ni muundo bila hasara. Kila pikseli inabaki kwenye mzunguko wa kusimba hasa, ambayo inafanya PNG kuwa chaguo sahihi kwa picha ndogo za skrini, kunasa UI, na picha yoyote yenye kingo kali au maeneo makubwa ya rangi tambarare. JPEG hutumia ukandamizaji wa DCT na hutupilia mbali maelezo mazuri ambayo jicho mara nyingi haliyaoni, ambayo inafanya iwe chaguo sahihi kwa picha. Ubora wa 0.8 ni hatua ya kawaida nzuri ambapo tofauti ya kuona na asili ni ngumu kuona lakini faili huwa ndogo mara 4 hadi 6 kuliko sawa ya PNG. WebP inaweza kufanya kazi katika hali zote za bila hasara na za kupoteza; kitelezi cha ubora hapa kinaendesha encoder ya kupoteza, na kwa ubora wa 0.85 WebP kwa kawaida inazidi JPEG kwa asilimia 25 hadi 30 kwenye maudhui ya picha za asili.

Je, matokeo ya AVIF yanafanyaje kazi?

Usimbaji wa AVIF hutumia kodeki ya WebAssembly inayopakia inapohitajika mara ya kwanza unapochagua umbiza la AVIF — hakuna programu-jalizi, hakwa bendera ya kivinjari, hakuna kusubiri toleo la baadaye la Chrome. BINARI ya WASM hutolewa kutoka asili yetu wenyewe, husimba picha yako kabisa katika uzi wa nyuma, na kurudisha blob ya kawaida ya image/avif tayari kwa kupakuliwa. Ombi pekee la mtandao ni kuchukua kodeki yenyewe mara moja; hakuna data ya picha inayotoka kwenye kifaa chako kamwe. Ikishapakiwa, kisimbaji hubaki kwenye akiba kwa kipindi cha matumizi ili ubadilishaji unaofuata uwe haraka. Faili za AVIF kwa kawaida ni 20-30% ndogo kuliko WebP na 50% ndogo kuliko JPEG kwa ubora sawa, na kuzifanya kuwa chaguo bora kwa tovuti nyeti kwa utendakazi.

Tupa picha zako, chagua muundo, badilisha. Kila kitu kinafanya kazi kwenye kichupo chako. Hakuna kupakia, hakuna akaunti, hakuna kusubiri foleni ya seva.