”یہ تصویر کمپریس کریں“ دراصل چار الگ الگ کام ہیں جو ایک ہی بٹن پہن کر بیٹھے ہیں۔ یہ جان لینا کہ ان میں سے کون سا آپ کا معیار کھاتا ہے، ترتیبات کا سارا اسرار ختم کر دیتا ہے۔
پہلا مرحلہ: ڈی کوڈنگ
دبی ہوئی فائل واپس پکسل کے جال میں بدلی جاتی ہے۔ براؤزر یہ کام مقامی کوڈ میں کرتے ہیں، اور جہاں پلیٹ فارم دے وہاں ہارڈویئر کی مدد سے، اور وہ JPEG، PNG، WebP اور AVIF سنبھالتے ہیں — نیز ایپل کے پلیٹ فارم پر HEIC بھی، کیونکہ آپریٹنگ سسٹم وہ ڈی کوڈر پہلے ہی ساتھ لاتا ہے۔
فائل کے لحاظ سے ڈی کوڈنگ بغیر نقصان کے ہوتی ہے: آپ کو بالکل وہی پکسل ملتے ہیں جو فائل بیان کرتی ہے۔ نقصان تو پہلے ہی ہو چکا ہوتا ہے، اُس وقت جب جس چیز نے یہ فائل بنائی، اُس نے اسے اینکوڈ کیا۔
دوسرا مرحلہ: رخ
فون کے کیمرے سینسر کا اصل رخ محفوظ کرتے ہیں اور ساتھ ایک الگ EXIF ٹیگ لکھتے ہیں جو بتاتا ہے کہ اسے کتنا گھمانا ہے۔ جو سافٹ ویئر اس ٹیگ کو نظرانداز کرتا ہے وہ تصویریں ٹیڑھی نکالتا ہے۔ اسے لاگو کرنے کا مطلب ہے کہ کسی اور چیز کے چھونے سے پہلے اصل پکسل جال کو گھما دیا جائے — اس کے بعد ٹیگ کی ضرورت ہی نہیں رہتی، اور یہی ایک وجہ ہے کہ دوبارہ اینکوڈ کرنے پر میٹا ڈیٹا ختم ہو جاتا ہے۔
تیسرا مرحلہ: ری سیمپلنگ
اگر پوری ریزولوشن پر مطلوبہ سائز نہ مل سکے تو تصویر چھوٹی کر دی جاتی ہے۔ محسوس ہونے والا بہت سا معیار خاموشی سے یہیں جیتا یا ہارا جاتا ہے۔ سستا باکس فلٹر ساتھ والے پکسل کا اوسط لے کر ہر چیز نرم کر دیتا ہے؛ Lanczos فلٹر زیادہ چوڑے پڑوس کو تولتا ہے اور کنارے کرارے رکھتا ہے۔
ری سیمپلنگ واقعی تباہ کن ہے — پھینکے گئے پکسل واپس نہیں آتے — مگر چھوٹے ہدف تک پہنچنے کا یہ اکثر سب سے کم تباہ کن راستہ ہوتا ہے، کیونکہ یہ وہ تفصیل ہٹا دیتا ہے جسے بیان کرنے کی ناکام کوشش میں اینکوڈر اپنا سارا بجٹ لگا دیتا۔
چوتھا مرحلہ: اینکوڈنگ
یہی نقصان والا حصہ ہے۔ JPEG تصویر کو روشنی اور رنگ والی صورت میں بدلتا ہے، رنگ کی کچھ ریزولوشن پھینک دیتا ہے (آنکھ کو مشکل ہی سے پتہ چلتا ہے)، تصویر کو 8×8 کے بلاکوں میں توڑتا ہے، ہر بلاک کو تعدد کے اجزا میں بدلتا ہے، اور پھر کوانٹائز کرتا ہے — یعنی اونچے تعدد کی تفصیل کو گول کر کے اڑا دیتا ہے۔ معیار کی قدر دراصل اسی گولائی کا موٹا پن ہے۔ اس کے بعد کا سب کچھ بغیر نقصان والی اینٹروپی کوڈنگ ہے، اور اسی لیے بہتر بنایا ہوا ہفمین جدول یا پروگریسو اسکین مفت میں بائٹ بچا دیتا ہے۔
WebAssembly یہاں کہاں آتا ہے
براؤزر کا اپنا اینکوڈر ایک بند ڈبہ ہے: آپ صرف معیار کا ایک عدد مانگ سکتے ہیں، اور بس۔ نہ بہتر بنائے ہوئے اینٹروپی جدول، نہ بیس لائن یا پروگریسو کا انتخاب، نہ ری سیمپلنگ فلٹر پر کوئی اختیار، اور نہ آزمائے بغیر یہ جاننے کا کوئی طریقہ کہ کوئی ترتیب کتنے بائٹ بنائے گی۔
WebAssembly میں کمپائل کیا ہوا کوڈیک یہ سب واپس دے دیتا ہے، اور قیمت وہ بائٹ ہیں جو اسے ڈاؤن لوڈ کرنے میں لگتے ہیں۔ ToolZool پوری پائپ لائن اِسی طرح چلاتا ہے — ڈی کوڈ، رخ، ری سیمپل اور اینکوڈ، سب Rust ہے جو WebAssembly میں کمپائل ہوتا ہے اور پس منظر کے ورکر میں چلتا ہے — ڈی کوڈ براؤزر کے حوالے کرنے کے بجائے۔ اس کی تین وجوہات ہیں، اور تینوں عملی:
- تلاش کو کئی اینکوڈ چاہئیں۔ مقررہ سائز تک پہنچنے کا مطلب ہے ایک ہی تصویر کو پانچ چھ بار اینکوڈ کرنا۔ اینکوڈر اپنا ہونا ہی اسے سستا اور بار بار قابلِ اعتماد بناتا ہے۔
- ڈی کوڈر کو ”نہیں“ کہنا آنا چاہیے۔ جو فائل 60,000 × 60,000 پکسل کا دعویٰ کرے، اسے میموری مانگنے سے پہلے مسترد ہونا چاہیے، اور ادھوری فائل کو آدھی تصویر لوٹانے کے بجائے ناکام ہونا چاہیے۔ براؤزر کا ڈی کوڈر وہاں اپنے فیصلے خود کرتا ہے؛ ہمارا حدیں بتاتا بھی ہے اور نافذ بھی کرتا ہے۔
- ایک ہی ان پٹ سے ایک ہی نتیجہ نکلنا چاہیے۔ براؤزروں کے ڈی کوڈر رنگ سنبھالنے میں اور خراب فائلوں کے ساتھ سلوک میں مختلف ہوتے ہیں۔ جو پائپ لائن دونوں سرے اپنے پاس رکھے، وہ ہر ڈیوائس پر وہی بائٹ بناتی ہے — اور یہی چیز نتیجے کو جانچنے کے قابل بناتی ہے۔
قیمت کھلی ہوئی ہے: وہ انجن ایک ڈاؤن لوڈ ہے۔ وہ تبھی منگوایا جاتا ہے جب آپ فائل چنتے ہیں، سو اِس جیسا صفحہ پڑھنے پر اس کی قیمت کبھی نہیں دینی پڑتی۔
تلاش کوڈیک سے زیادہ اہم کیوں ہے
مقررہ فائل سائز دے دیا جائے تو اچھے اینکوڈر اور بہترین اینکوڈر کا فرق چند فیصد کا ہوتا ہے۔ معیار کے سلائیڈر پر اندازہ لگانے اور صحیح قدر تلاش کرنے کا فرق کہیں بڑا ہے، کیونکہ جو اندازہ آپ کی گنجائش کے 60% پر آ کر رکے، اُس نے وہ ایک تہائی معیار پھینک دیا جس کے آپ حق دار تھے۔ پورا خیال یہی ہے جو مقررہ سائز تک کمپریس کرنے کے پیچھے ہے، اور 50 KB کی حد تک پہنچنا دکھاتا ہے کہ رینج کے سب سے سخت سرے پر یہ تلاش آپ کو کیا دیتی ہے۔
