ಹೆಚ್ಚಿನ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಇಂದಿಗೂ ಇಮೇಜ್ ಅಪ್ಲೋಡ್ಗಳನ್ನು ಒಂದು 'ಬ್ಲಾಕ್ ಬಾಕ್ಸ್' (black box) ರೀತಿ ನಿರ್ವಹಿಸುತ್ತವೆ. ಬಳಕೆದಾರರು ಫೈಲ್ ಅನ್ನು ಡ್ರಾಪ್ ಮಾಡುತ್ತಾರೆ, ಬ್ರೌಸರ್ ಅದನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಆ ಪೇಲೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಯಾರೂ ನಿರೀಕ್ಷಿಸದ 413 ಎರರ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಬ್ರೌಸರ್-ಸೈಡ್ ಕಂಪ್ರೆಶನ್ (compression) ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಇದು ಡೇಟಾ ವರ್ಗಾವಣೆಯಾಗುವ ಮೊದಲೇ ಪೇಲೋಡ್ಗಳನ್ನು ಕುಗ್ಗಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ, ಇದರರ್ಥ ವೇಗವಾದ ಅಪ್ಲೋಡ್ಗಳು, ಕಡಿಮೆ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಬಿಲ್ಗಳು ಮತ್ತು ಕಡಿಮೆ ಸರ್ವರ್ ಟೈಮೌಟ್ಗಳು. ಆದರೆ ಈ ಕೆಲಸದಲ್ಲಿ ತಪ್ಪುಗಳು ನಡೆಯುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ನೀವು ಕಂಪ್ರೆಶನ್ ಅನ್ನು ಕೇವಲ "quality" ಎಂಬ ಲೇಬಲ್ ಇರುವ ಮ್ಯಾಜಿಕ್ ಸ್ಲೈಡರ್ ಎಂದು ಪರಿಗಣಿಸಿದರೆ, ನೀವು ಹಾನಿಗೊಳಗಾದ ಚಿತ್ರಗಳು, ಎಳೆಯಲಾದ (stretched) ಥಂಬ್ನೇಲ್ಗಳು ಮತ್ತು ಗೊಂದಲಮಯ ಬಳಕೆದಾರ ಅನುಭವಗಳನ್ನು ನೀಡಬೇಕಾಗುತ್ತದೆ. ಉತ್ತಮ ವಿಧಾನವೆಂದರೆ ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಒಂದು 'ಪೈಪ್ಲೈನ್' (pipeline) ಎಂದು ಪರಿಗಣಿಸುವುದು.
ಸ್ಲೈಡರ್ಗಳಲ್ಲ, ಪೈಪ್ಲೈನ್ಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಿ
ಕೆಲಸವನ್ನು ಪ್ರತ್ಯೇಕ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಿ. ಇನ್ಪುಟ್ ಎಲಿಮೆಂಟ್ನಿಂದ ಫೈಲ್ ಅನ್ನು ಓದಿ. ಚಿತ್ರವನ್ನು ನಿಮ್ಮ ಗುರಿ ಆಯಾಮಗಳಿಗೆ (dimensions) ಸರಿಹೊಂದಿಸಿ. ಹೊಸ Blob ಅನ್ನು ಎನ್ಕೋಡ್ ಮಾಡಿ. ನಂತರ ಫಲಿತಾಂಶವನ್ನು ಬಳಕೆದಾರರಿಗೆ ತೋರಿಸಿ. ಪ್ರತಿ ಹಂತವು ಒಂದು ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ಔಟ್ಪುಟ್ ಅನ್ನು ಮುಂದಿನ ಹಂತಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯು ಕೇವಲ ಕೋಡ್ ಅನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಮಾಡುವುದಿಲ್ಲ, ಬದಲಾಗಿ ಯೂನಿಟ್ ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ನೀವು ಫೈಲ್ ಇನ್ಪುಟ್ ಅನ್ನು ಮುಟ್ಟದೆಯೇ ಸ್ಕೇಲಿಂಗ್ ಹಂತಕ್ಕೆ ತಿಳಿದಿರುವ ಬಫರ್ ಅನ್ನು ನೀಡಬಹುದು. ಸರ್ವರ್ನ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯದೆ, ನಿಮ್ಮ ಎನ್ಕೋಡರ್ 200 KB ಗಿಂತ ಕಡಿಮೆ ಇರುವ JPEG ಅನ್ನು ನೀಡುತ್ತದೆಯೇ ಎಂದು ನೀವು ಪರಿಶೀಲಿಸಬಹುದು. ಏನಾದರೂ ತಪ್ಪಾದಾಗ, ಯಾವ ಹಂತವು ವಿಫಲವಾಯಿತು ಎಂಬುದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿಯುತ್ತದೆ.
ಈ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿರಿಸುವುದು ಅಪ್ಲೋಡ್ ಸಮಯದಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ನೀವು ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಎನ್ಕೋಡಿಂಗ್ ಅನ್ನು ಒಂದೇ ಗೊಂದಲಮಯ ಫಂಕ್ಷನ್ನಲ್ಲಿ ಸೇರಿಸಿದರೆ, ಅರ್ಧ ಹಂತದಲ್ಲಿ ಆಗುವ ಡಿಕೋಡಿಂಗ್ ದೋಷವು ನಿಮ್ಮ ಅಪ್ಲೋಡ್ ಕ್ಯೂ ಅನ್ನು ಅಸ್ಥಿರ ಸ್ಥಿತಿಗೆ ತಳ್ಳಬಹುದು. ಪೈಪ್ಲೈನ್ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಪರಿಶೀಲಿಸಲು (validate) ನಿಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತದೆ. ಫೈಲ್ ಅನ್ನು ಡಿಕೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ಕ್ಯಾನ್ವಾಸ್ (canvas) ರಚಿಸುವ ಮೊದಲೇ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು. ಎನ್ಕೋಡ್ ಮಾಡಿದ Blob ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಸರ್ವರ್ ಅನ್ನು ಅದನ್ನು ಸಂಗ್ರಹಿಸಲು ಕೇಳುವ ಮೊದಲೇ ನೀವು ಅದನ್ನು ತಡೆಯಬಹುದು.
ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು ನಿಯಮಗಳನ್ನು (Contract) ನಿಗದಿಪಡಿಸಿ
ಯಾರಾದರೂ ಕ್ಯಾನ್ವಾಸ್ ಡ್ರಾ ಕಾಲ್ (canvas draw call) ಬರೆಯುವ ಮೊದಲು, ನಿಯಮಗಳನ್ನು ಬರೆದು ತಂಡದೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಿ. ಸ್ವೀಕರಿಸಬಹುದಾದ MIME ಪ್ರಕಾರಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ನೀವು JPEG, PNG, WebP ಅಥವಾ AVIF ಅನ್ನು ಅನುಮತಿಸುತ್ತೀರಾ? ಪ್ರತಿಯೊಂದೂ ಆಲ್ಫಾ ಚಾನೆಲ್ಗಳು (alpha channels), ಬ್ರೌಸರ್ ಬೆಂಬಲ ಮತ್ತು CPU ವೆಚ್ಚದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಗರಿಷ್ಠ ಇನ್ಪುಟ್ ಗಾತ್ರವನ್ನು ನಿಗದಿಪಡಿಸಿ. ಫ್ಲ್ಯಾಗ್ಶಿಪ್ ಫೋನ್ನ 30 MB ರಾಗ್ ಫೋಟೋವನ್ನು ಇಡೀ ಮೆಮೊರಿಯಲ್ಲಿ ಡಿಕೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಹಳೆಯ ಲ್ಯಾಪ್ಟಾಪ್ ಫ್ರೀಜ್ ಆಗಬಹುದು ಅಥವಾ ಕ್ರ್ಯಾಶ್ ಆಗಬಹುದು. ಗರಿಷ್ಠ ಔಟ್ಪುಟ್ ಆಯಾಮಗಳನ್ನು (dimensions) ವ್ಯಾಖ್ಯಾನಿಸಿ. ನಿಮ್ಮ UI ಎಂದಿಗೂ 2048 ಪಿಕ್ಸೆಲ್ಗಿಂತ ಹೆಚ್ಚು ಅಗಲದ ಚಿತ್ರಗಳನ್ನು ತೋರಿಸದಿದ್ದರೆ, 6000 ಪಿಕ್ಸೆಲ್ ಅಗಲದ ಫೋಟೋವನ್ನು ಪೈಪ್ಲೈನ್ ಮೂಲಕ ಕಳುಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಎಲ್ಲಕ್ಕಿಂತ ಮುಖ್ಯವಾಗಿ, ಡಿಕೋಡಿಂಗ್ ವೈಫಲ್ಯಗಳಿಗಾಗಿ ಯೋಜಿಸಿ. ಹಾನಿಗೊಳಗಾದ ಫೈಲ್, ವಿಲಕ್ಷಣ ಕಲರ್ ಪ್ರೊಫೈಲ್ ಅಥವಾ ಅಪೂರ್ಣ ಅಪ್ಲೋಡ್ Image constructor ನಲ್ಲಿ ದೋಷವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ಗೆ ಸ್ಪಷ್ಟವಾದ catch block ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಅರ್ಥವಾಗುವಂತಹ ದೋಷ ಸಂದೇಶದ ಅಗತ್ಯವಿದೆ. ಬ್ರೌಸರ್ ಸುಮ್ಮನೆ ನಿಂತುಹೋಗಿ, ಏನೂ ಆಗದಂತೆ ಬಳಕೆದಾರರು ಸ್ಪಿನ್ನರ್ (spinner) ನೋಡುತ್ತಾ ಕುಳಿತುಕೊಳ್ಳುವಂತೆ ಮಾಡಬೇಡಿ.
ಚಿತ್ರಕ್ಕೆ ಗೌರವ ನೀಡಿ
ಚಿತ್ರದ ವಿರೂಪವು (Distortion) ಅಸಮರ್ಪಕವಾಗಿ ಕಾಣುತ್ತದೆ. ಆಸ್ಪೆಕ್ಟ್ ರೇಶಿಯೋ (aspect ratio) ಅನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿ ಮತ್ತು ಅತಿ ಉದ್ದದ ಬದಿಗೆ ಮಿತಿ ಹೇರてください. ನಿಮ್ಮ ಗುರಿ ಬಾಕ್ಸ್ 1024 x 1024 ಪಿಕ್ಸೆಲ್ಗಳಾಗಿದ್ದರೆ, 4000 x 3000 ಫೋಟೋವು 1024 x 768 ಆಗಿ ಬದಲಾಗಬೇಕೇ ಹೊರತು 1024 x 1024 ಆಗಬಾರದು. ಉದ್ದವಾದ ಬದಿಯಿಂದ ಸ್ಕೇಲ್ ಫ್ಯಾಕ್ಟರ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಿ ಮತ್ತು ಚಿಕ್ಕ ಬದಿಯು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿರಲಿ. ಇದು ಚಿತ್ರಗಳು ವಿಚಿತ್ರ ಆಕಾರಗಳಿಗೆ ಎಳೆಯಲ್ಪಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಅಸಲಿ ಎಕ್ಸ್ಪೋರ್ಟ್ (export) ಗಾಗಿ, ಕ್ಯಾನ್ವಾಸ್ನ toBlob ವಿಧಾನವನ್ನು ಬಳಸಿ. ಇದು ಔಟ್ಪುಟ್ ಫಾರ್ಮ್ಯಾಟ್ ಮತ್ತು ಗುಣಮಟ್ಟದ ಸೆಟ್ಟಿಂಗ್ ಮೇಲೆ ನಿಮಗೆ ನೇರ ನಿಯಂತ್ರಣ ನೀಡುತ್ತದೆ ಮತ್ತು ಇದು ಅಸಿಂಕ್ರೋನಸ್ (asynchronously) ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ ಮುಖ್ಯ ಥ್ರೆಡ್ ಅನ್ನು (main thread) ತಡೆಯುವುದಿಲ್ಲ. ಒಂದು ಆಫ್ಸ್ಕ್ರೀನ್ ಕ್ಯಾನ್ವಾಸ್ (offscreen canvas) ರಚಿಸಿ, ಅದರ ಮೇಲೆ ಮರು-ಅಳತೆಯ ಚಿತ್ರವನ್ನು ಬಿಡಿಸಿ, ನಂತರ ನಿಮ್ಮ ಆದ್ಯತೆಯ ಟೈಪ್ ಮತ್ತು ಗುಣಮಟ್ಟದ ಮೌಲ್ಯದೊಂದಿಗೆ canvas.toBlob ಅನ್ನು ಕರೆಯಿರಿ. ಆ ಹೊಸ Blob ಅನ್ನು ನೀವು ನಿಮ್ಮ ಅಪ್ಲೋಡ್ ಲಾಜಿಕ್ ಅಥವಾ ಸ್ಟೋರೇಜ್ API ಗೆ ನೀಡುತ್ತೀರಿ.
ಪುರಾವೆಗಳನ್ನು ತೋರಿಸಿ
ಕಂಪ್ರೆಶನ್ ಎಂಬುದು ಕಣ್ಣಿಗೆ ಕಾಣದ ಕೆಲಸ. ನೀವು ಅಂಕಿಅಂಶಗಳನ್ನು ತೋರಿಸದಿದ್ದರೆ, ಬಳಕೆದಾರರು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಂಬುವುದಿಲ್ಲ. ಮೂಲ ಫೈಲ್ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಹೋಲಿಸಲು ಅವರಿಗೆ ಅನುವು ಮಾಡಿಕೊಡುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಮೂಲ ಫೈಲ್ ಗಾತ್ರ, ಹೊಸ ಫೈಲ್ ಗಾತ್ರ, ಹೊಸ ಆಯಾಮಗಳು ಮತ್ತು ಅಂತಿಮ ಫಾರ್ಮ್ಯಾಟ್ ಪ್ರಕಾರವನ್ನು ಪ್ರದರ್ಶಿಸಿ. 4.2 MB ಫೋನ್ ಫೋಟೋವು 380 KB WebP ಆಗಿ ಇಳಿಯುವುದನ್ನು ನೋಡುವುದರಿಂದ, ನೀವು ರಹಸ್ಯವಾಗಿ ಅವರ ಚಿತ್ರವನ್ನು ಹಾಳು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬ ಭಯ ದೂರವಾಗುತ್ತದೆ.
ಈ ಪಾರದರ್ಶಕತೆಯು ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು (troubleshooting) ಸಹ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಅಪ್ಲೋಡ್ ವಿಫಲವಾಯಿತು ಎಂದು ಬಳಕೆದಾರರು ದೂರು ನೀಡಿದಾಗ, ನೀವು ಮೊದಲು ಪರಿಶೀಲಿಸಬೇಕಾದದ್ದು ಔಟ್ಪುಟ್ ಆಯಾಮಗಳು ನಿಮ್ಮ ಸರ್ವರ್ ಮಿತಿಯನ್ನು ಮೀರಿದೆಯೇ ಅಥವಾ ಫಾರ್ಮ್ಯಾಟ್ PNG ನಿಂದ JPEG ಗೆ ಬದಲಾಗಿ ಆಲ್ಫಾ ಚಾನೆಲ್ ಕಳೆದುಹೋಗಿದೆಯೇ ಎಂಬುದನ್ನು. ಬಳಕೆದಾರರು ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ (support ticket) ತೆರೆಯುವ ಮೊದಲು ಸ್ವತಃ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಆ ಡೇಟಾವನ್ನು UI ನಲ್ಲಿ ಇರಿಸಿ.
ರೀ-ಕಂಪ್ರೆಶನ್ (Re-compression) ಗಿಂತ ಪ್ರಿಸೆಟ್ಗಳು (Presets) ಉತ್ತಮ
ಒಂದೇ ಚಿತ್ರವನ್ನು ಎಂದಿಗೂ ಎರಡು ಬಾರಿ ಕಂಪ್ರೆಸ್ ಮಾಡಬೇಡಿ. ಲಾಸ್ಸಿ ಎನ್ಕೋಡರ್ (lossy encoder) ಮೂಲಕ ಪ್ರತಿ ಬಾರಿ ಹಾದುಹೋದಾಗ ಹೆಚ್ಚಿನ ವಿವರಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ ಮತ್ತು ಚಿತ್ರದಲ್ಲಿ ಕ್ಯೂಬ್ಗಳಂತಹ ಕಲೆಗಳು (blocky artifacts) ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಬಳಕೆದಾರರು ಪದೇ ಪದೇ "optimize" ಬಟನ್ ಒತ್ತಲು ಬಿಟ್ಟರೆ, ಮೂರನೇ ತಲೆಮಾರಿನ ಚಿತ್ರವು ಫೋಟೋಕಾಪಿಯ ಫೋಟೋಕಾಪಿ ತರಹ ಕಾಣಿಸುತ್ತದೆ. ಬದಲಾಗಿ, ಪ್ರತಿ ಔಟ್ಪುಟ್ ಅನ್ನು ಮೂಲ ಫೈಲ್ನಿಂದಲೇ ತಯಾರಿಸಿ ಮತ್ತು ಪ್ರಿಸೆಟ್ಗಳನ್ನು (presets) ನೀಡಿ:
- Smaller file: Push quality lower and cap dimensions aggressively for thumbnails or fast previews.
- Balanced: Target a moderate quality level with sensible dimensions, suitable for social feeds and galleries.
- More detail: Keep quality high and preserve larger dimensions for photography, artwork, or print previews.
Store the original Blob in memory so the user can switch between presets without stacking generations of loss. Always generate from the source, never from the last output.
Test Like Your Users Upload
Your development machine with a fiber connection and 32 GB of RAM is not reality. Test with the actual files real users carry. Phone photos from iOS and Android use different metadata orientations and may originate from HEIC sources. Transparent assets such as logos and icons behave differently under JPEG conversion because JPEG simply does not support alpha channels. Huge files will expose memory limits on devices with 2 GB of RAM. Slow mobile CPUs will reveal exactly how long that toBlob call really takes.
Use Chrome DevTools to throttle the CPU and network. Try a five-year-old Android phone. If your pipeline locks the UI for three seconds while encoding, you need to move the heavy work into a Web Worker so the interface stays responsive.
Ship the Basics First
It is tempting to support every format and