Most web apps still handle image uploads like a black box. A user drops a file, the browser ships it off, and the server

பெரும்பாலான இணையச் செயலிகள் இமேஜ் அப்லோடுகளை (image uploads) ஒரு கருப்புப் பெட்டி (black box) போலவே கையாளுகின்றன. ஒரு பயனர் ஒரு கோப்பைத் தேர்ந்தெடுத்துப் பதிவேற்றும்போது, பிரவுசர் அதை அனுப்பிவிடும், சர்வர் அதை ஏற்றுக்கொண்டாலோ அல்லது யாரும் எதிர்பார்க்காத 413 பிழையைத் (error) தூண்டினாலோ தான் அடுத்தது நடக்கும். பிரவுசர் பக்கத் தரவுச் சுருக்கம் (Browser-side compression) இந்தச் சூழலை மாற்றுகிறது. இது தரவுத் தொகுப்புகள் (payloads) இணையக் கட்டமைப்பிற்குள் செல்வதற்கு முன்பே அவற்றின் அளவைக் குறைக்க உங்களுக்கு ஒரு வாய்ப்பை வழங்குகிறது; இதன் மூலம் வேகமான அப்லோட்கள், குறைந்த அலைக்கற்றை (bandwidth) கட்டணங்கள் மற்றும் குறைவான சர்வர் டைம்அவுட்கள் (server timeouts) சாத்தியமாகும். ஆனால், இந்த வேலையைச் சரியாகச் செய்யாமல் தவறு செய்ய வாய்ப்புகள் அதிகம். நீங்கள் தரத்தை (quality) மட்டும் மாற்றும் ஒரு மாய ஸ்லைடராகச் சுருக்கத்தை நடத்தினால், சிதைந்த படங்கள், நீட்டப்பட்ட தம்ப்நெயில்கள் (thumbnails) மற்றும் குழப்பமான பயனர் அனுபவங்களை நீங்கள் வழங்க நேரிடும். சிறந்த அணுகுமுறை என்பது இந்த முழுச் செயல்பாட்டையும் ஒரு பைப்லைனாக (pipeline) கருதுவதாகும்.

ஸ்லைடர்களைப் பற்றி நினைக்காமல், பைப்லைன்களைப் பற்றிச் சிந்தியுங்கள்

வேலையைத் தனித்தனி நிலைகளாகப் பிரியுங்கள். இன்புட் எலிமெண்டிலிருந்து (input element) கோப்பைப் படிக்கவும். படத்தின் அளவை உங்கள் இலக்கு பரிமாணங்களுக்குக் குறைக்கவும். ஒரு புதிய Blob-ஐ என்கோட் (encode) செய்யவும். பின்னர் அதன் முடிவை மீண்டும் பயனருக்குக் காட்டவும். ஒவ்வொரு நிலையானது ஒரு வேலையை மட்டும் செய்து, அதன் வெளியீட்டை அடுத்த நிலைக்கு அனுப்புகிறது. இந்தத் தனித்தனிப் பிரிப்பு வெறும் சுத்தமான குறியீட்டிற்காக (cleaner code) மட்டுமல்ல; இது யூனிட் டெஸ்டிங்கை (unit testing) எளிதாக்குகிறது. ஒரு கோப்பு இன்புட்டைத் தொடாமலேயே, ஒரு குறிப்பிட்ட பஃபரை (buffer) ஸ்கேலிங் நிலைக்குள் (scaling stage) உள்ளீடாக வழங்க முடியும். சர்வர் பதிலுக்காகக் காத்திருக்காமலேயே, உங்கள் என்கோடர் 200 KB-க்கும் குறைவான JPEG-ஐ உருவாக்குவதை நீங்கள் சரிபார்க்க முடியும். ஏதேனும் ஒன்று முறிந்தால், எந்தப் படி தோல்வியடைந்தது என்பதை நீங்கள் துல்லியமாகத் தெரிந்துகொள்ளலாம்.

இத்தகையப் பொறுப்புகளைத் தனித்தனியாகப் பிரித்து வைப்பது அப்லோட்களின் போது எதிர்பாராத சிக்கல்களைத் தவிர்க்கிறது. ஸ்கேலிங் மற்றும் என்கோடிங் ஆகிய இரண்டையும் ஒரே சிக்கலான செயல்பாடாக (function) இணைத்தால், இடையில் ஏற்படும் ஒரு டீகோடிங் பிழை (decoding error) உங்கள் அப்லோட் வரிசையை (upload queue) ஒரு நிலையற்ற நிலைக்குத் தள்ளக்கூடும். ஒரு பைப்லைன் ஒவ்வொரு எல்லையிலும் தரவைச் சரிபார்க்க (validate) உங்களைக் கட்டாயப்படுத்துகிறது. கோப்பை டீகோட் செய்ய முடியாவிட்டால், நீங்கள் கேன்வாஸை (canvas) உருவாக்குவதற்கு முன்பே அதைக் கண்டறியலாம். என்கோட் செய்யப்பட்ட Blob மிகவும் பெரியதாக இருந்தால், அதைச் சேமிக்க நீங்கள் சர்வருக்குக் கோரிக்கை விடுப்பதற்கு முன்பே அதைக் கண்டறியலாம்.

குறியீட்டை எழுதுவதற்கு முன்பே ஒரு ஒப்பந்தத்தை வரையறுக்கவும்

யாராவது ஒரு canvas draw அழைப்பை எழுதுவதற்கு முன்பே, விதிகளை எழுதி வைத்து அவற்றை அணியினருடன் (team) பகிர்ந்து கொள்ளுங்கள். ஏற்றுக்கொள்ளப்பட்ட MIME வகைகளைத் தேர்ந்தெடுங்கள். JPEG, PNG, WebP அல்லது AVIF ஆகியவற்றில் எதை அனுமதிப்பீர்கள்? ஆல்ஃபா சேனல்கள் (alpha channels), பிரவுசர் ஆதரவு மற்றும் CPU செலவு ஆகியவற்றில் ஒவ்வொன்றும் தாக்கத்தை ஏற்படுத்தும். அதிகபட்ச இன்புட் அளவை நிர்ணயியுங்கள். ஒரு முன்னணி போனில் இருந்து வரும் 30 MB அளவுள்ள மூலப் படத்தை (raw photo) முழுமையாக மெமரியில் டீகோட் செய்ய முயன்றால், அது பழைய லேப்டாப்பை முடக்கிவிடலாம் அல்லது செயலிழக்கச் செய்யலாம். அதிகபட்ச வெளியீட்டுப் பரிமாணங்களை (output dimensions) வரையறுக்கவும். உங்கள் UI ஒருபோதும் 2048 பிக்சல்களுக்கு அகலமான படங்களைக் காட்டவில்லை என்றால், 6000 பிக்சல் அகலமுள்ள ஒரு படத்தை பைப்லைனுக்குள் அனுமதிக்க எந்தக் காரணமும் இல்லை.

மிக முக்கியமாக, டீகோடிங் தோல்விகளுக்காகத் திட்டமிடுங்கள். ஒரு சிதைந்த கோப்பு (corrupted file), ஒரு விசித்திரமான கலர் ப்ரொஃபைல் (color profile) அல்லது பாதியிலேயே நின்ற அப்லோட் ஆகியவை Image கன்ஸ்ட்ரக்டரில் (constructor) பிழையை ஏற்படுத்தலாம். உங்கள் பைப்லைனில் தெளிவான catch block மற்றும் மனிதர்கள் எளிதில் புரிந்துகொள்ளக்கூடிய பிழைச் செய்தி (error message) இருக்க வேண்டும். பிரவுசர் அமைதியாகச் செயலிழந்து, பயனர் எதையும் செய்ய முடியாமல் ஒரு ஸ்பின்னரை (spinner) பார்த்துக் கொண்டிருக்க அனுமதிக்காதீர்கள்.

படத்திற்கு மதிப்பளிக்கவும்

சிதைவு (Distortion) என்பது ஒரு அனுபவமற்றத் தன்மையைக் காட்டும். விகிதாச்சாரத்தைப் (aspect ratio) பேணுங்கள் மற்றும் நீளமான பக்கத்தின் அளவைக் கட்டுப்படுத்துங்கள். உங்கள் இலக்கு பெட்டி 1024 x 1024 பிக்சல்கள் என்றால், 4000 x 3000 அளவுள்ள ஒரு படம் 1024 x 768 ஆக இருக்க வேண்டுமே தவிர, 1024 x 1024 ஆக இருக்கக் கூடாது. நீளமான விளிம்பிலிருந்து ஸ்கேல் ஃபேக்டரை (scale factor) கணக்கிட்டு, குறுகிய விளிம்பை அதற்கேற்ப மாற்றவும். இது படங்கள் விசித்திரமான வடிவங்களில் நீள்வத்தாவதைத் தடுக்கும்.

உண்மையான ஏற்றுமதிக்கு (export), கேன்வாஸின் toBlob முறையைப் பயன்படுத்துங்கள். இது வெளியீட்டு வடிவம் மற்றும் தர நிர்ணயத்தின் (quality setting) மீது உங்களுக்கு நேரடித் கட்டுப்பாட்டை வழங்குகிறது, மேலும் இது அசிங்க்ரோனஸாக (asynchronously) இயங்குவதால் உங்கள் மெயின் த்ரெட்டை (main thread) இது முடக்காது. ஒரு ஆஃப்ஸ்கிரீன் கேன்வாஸை (offscreen canvas) உருவாக்கி, அதில் மாற்றியமைக்கப்பட்ட படத்தை வரைந்து, பின்னர் உங்கள் விருப்பமான வகை மற்றும் தர மதிப்பைப் பயன்படுத்தி canvas.toBlob ஐ அழைக்கவும். அந்தப் புதிய Blob தான் உங்கள் அப்லோட் லாஜிக் அல்லது ஸ்டோரேஜ் API-க்கு நீங்கள் வழங்க வேண்டியது.

ஆதாரத்தைக் காட்டுங்கள்

சுருக்குதல் (Compression) என்பது கண்ணுக்குத் தெரியாத வேலை. நீங்கள் எண்களை வெளிப்படுத்தவில்லை என்றால், பயனர்கள் இந்தச் செயல்பாட்டை நம்ப மாட்டார்கள். அசல் படத்தையும் அதன் முடிவையும் ஒப்பிட்டுப் பார்க்க உதவும் ஒரு இடைமுகத்தை (interface) உருவாக்குங்கள். அசல் கோப்பின் அளவு, புதிய கோப்பின் அளவு, புதிய பரிமாணங்கள் மற்றும் இறுதி வடிவ வகை ஆகியவற்றைத் திரையில் காட்டுங்கள். 4.2 MB அளவுள்ள போன் புகைப்படம் 380 KB WebP ஆகக் குறைவதைப் பார்க்கும்போது, நீங்கள் ரகசியமாகப் படத்தின் தரத்தைக் கெடுக்கிறீர்கள் என்ற பயம் பயனருக்கு இருக்காது.

இந்த வெளிப்படைத்தன்மை பிழைத்திருத்தத்திற்கும் (troubleshooting) உதவுகிறது. ஒரு அப்லோட் தோல்வியடைந்ததாகப் பயனர் புகார் கூறும்போது, வெளியீட்டுப் பரிமாணங்கள் உங்கள் சர்வர் வரம்பைத் தாண்டியதா அல்லது வடிவம் PNG-யிலிருந்து JPEG ஆக மாறி ஆல்ஃபா சேனலைத் தவறவிட்டதா என்பதை நீங்கள் முதலில் சரிபார்ப்பீர்கள். பயனர் ஒரு சப்போர்ட் டிக்கெட் (support ticket) திறப்பதற்கு முன்பே சிக்கலைத் தாங்களாகவே கண்டறிய ஏதுவாக அந்தத் தரவை UI-இல் காட்டுங்கள்.

ரீ-கம்ப்ரஷன் செய்வதை விட ப்ரீசெட்கள் சிறந்தது

ஒரே படத்தை இரண்டு முறை சுருக்காதீர்கள். ஒரு லாஸி என்கோடர் (lossy encoder) வழியாக ஒவ்வொரு முறை செல்லும்போதும் கூடுதல் விவரங்கள் நீக்கப்பட்டு, பிளாக் போன்ற சிதைவுகள் (blocky artifacts) உருவாகின்றன. ஒரு பயனர் மீண்டும் மீண்டும் "optimize" என்பதைக் கிளிக் செய்ய அனுமதித்தால், மூன்றாவது தலைமுறைப் படம் ஒரு நகலின் நகலைப் போலத் தோன்றும். அதற்குப் பதிலாக, அசல் மூலக் கோப்பிலிருந்து ஒவ்வொரு வெளியீட்டையும் உருவாக்கி, ப்ரீசெட்களை (presets) வழங்கவும்:

• சிறிய கோப்பு: தம்பnails அல்லது விரைவான முன்னோட்டங்களுக்குத் தரத்தைக் குறைத்து, அளவுகளைக் கடுமையாகக் கட்டுப்படுத்தவும்.
• சமநிலை (Balanced): சமூக ஊடகப் பதிவுகள் மற்றும் கேலரிகளுக்கு ஏற்றவாறு, சரியான அளவுகளுடன் மிதமான தரத்தை இலக்காகக் கொள்ளவும்.
• அதிக விவரங்கள்: புகைப்படம், கலைப்படைப்பு அல்லது அச்சு முன்னோட்டங்களுக்குத் தரத்தை உயர்வாகவும், பெரிய அளவுகளையும் அப்படியே வைத்திருக்கவும்.

பயனர்கள் தரக் குறைபாடுகள் மீண்டும் மீண்டும் சேராமல் (stacking generations of loss), presets-களுக்கு இடையே எளிதாக மாறக்கூடிய வகையில் அசல் Blob-ஐ நினைவகத்தில் (memory) சேமித்து வைக்கவும். எப்போதும் மூலத்திலிருந்து (source) உருவாக்கவும், கடைசி வெளியீட்டிலிருந்து (last output) உருவாக்க வேண்டாம்.

பயனர்கள் பதிவேற்றுவது போலவே சோதிக்கவும்

ஃபைபர் இணைப்பு மற்றும் 32 GB RAM கொண்ட உங்கள் மேம்பாட்டு இயந்திரம் (development machine) நிஜ நிலை அல்ல. உண்மையான பயனர்கள் பயன்படுத்தும் கோப்புகளைக் கொண்டு சோதிக்கவும். iOS மற்றும் Android போன்களில் இருந்து வரும் புகைப்படங்கள் வெவ்வேறு metadata திசைகளைப் (orientations) பயன்படுத்துகின்றன மற்றும் HEIC மூலங்களிலிருந்து வரக்கூடும். லோகோக்கள் மற்றும் ஐகான்கள் போன்ற வெளிப்படையான (transparent) சொத்துக்கள் JPEG மாற்றத்தின் போது மாறுபட்ட முறையில் செயல்படும், ஏனெனில் JPEG ஆல்பா சேனல்களை (alpha channels) ஆதரிக்காது. மிகப் பெரிய கோப்புகள் 2 GB RAM கொண்ட சாதனங்களில் நினைவக வரம்புகளை (memory limits) வெளிப்படுத்தும். மெதுவான மொபைல் CPU-க்கள் அந்த toBlob அழைப்பு உண்மையில் எவ்வளவு நேரம் எடுத்துக்கொள்கிறது என்பதைத் துல்லியமாகக் காட்டும்.

CPU மற்றும் நெட்வொர்க்கைக் கட்டுப்படுத்த (throttle) Chrome DevTools-ஐப் பயன்படுத்தவும். ஐந்து ஆண்டுகள் பழமையான ஆண்ட்ராய்டு போனைப் பயன்படுத்திப் பார்க்கவும். என்கோடிங் (encoding) செய்யும் போது உங்கள் pipeline UI-ஐ மூன்று விநாடிகள் முடக்கியால், இடைமுகம் (interface) சுறுசுறுப்பாக இருக்க அந்தப் பெரிய வேலைகளை ஒரு Web Worker-க்குள் மாற்ற வேண்டும்.

அடிப்படை விஷயங்களை முதலில் வழங்கவும்

ஒவ்வொரு வடிவத்தையும் ஆதரிக்கத் தூண்டுதல் இருக்கலாம் மற்றும்