تصویر کا فائل حجم کیسے کم کریں
اپ لوڈ فارم 2 MB سے کم مانگ رہا ہے اور میری تصویر 8 MB کی ہے۔ مجھے اصل میں بدلنا کیا ہے؟
تین لیور، اور ان میں سے ایک سب پر بھاری
ہر امیج کمپریسر انہی تین لیوروں کا کوئی نہ کوئی امتزاج کھینچ رہا ہوتا ہے: تصویر میں کتنے پکسل ہیں، اینکوڈر کو کتنی تفصیل پھینکنے کی اجازت ہے، اور وہ کون سا فارمیٹ لکھتا ہے۔ لوگ سب سے پہلے کوالٹی کے سلائیڈر کی طرف ہاتھ بڑھاتے ہیں، کیونکہ ہر ٹول سب سے پہلے یہی دکھاتا ہے۔ عام طور پر شروع کرنے کی یہ غلط جگہ ہے۔
ابعاد سب پر بھاری ہیں، کیونکہ فائل کا حجم تقریباً پکسلوں کی تعداد کے ساتھ بڑھتا ہے اور پکسلوں کی تعداد لمبائی کے مربع کے ساتھ۔ چوڑائی اور اونچائی آدھی کر دیں تو پکسل چوتھائی رہ جاتے ہیں۔ کوالٹی کے سلائیڈر سے آپ اتنا فیصلہ کن کام نہیں کر سکتے، اور نہ ہی کسی اور تدبیر کی قیمت محسوس ہونے والی کوالٹی میں اتنی کم پڑتی ہے — بشرطیکہ نتیجہ پھر بھی اُس ڈبے سے بڑا رہے جس میں اسے دکھایا جائے گا۔
طے کریں کہ آپ کو دراصل کتنے پکسل چاہئیں
جدید فون کیمرہ تقریباً 4000 پکسل چوڑی تصاویر بناتا ہے۔ لیپ ٹاپ پر پوری اسکرین کی تصویر تقریباً 1500 سے 2000 پکسل چوڑی دکھائی جاتی ہے، اور کسی مضمون کے اندر تصویر اکثر 800 پر دکھائی جاتی ہے۔ 800 دکھانے والے ڈبے میں 4000 پکسل بھیجنے کا مطلب یہ ہے کہ ڈاؤن لوڈ ہونے کے بعد تقریباً 96 فیصد پکسل دیکھنے والے کے سافٹ ویئر کے ہاتھوں پھینک دیے جاتے ہیں۔
| سب سے لمبا کنارہ | تخمینی پکسل | 4000 px اصل کا حصہ |
|---|---|---|
| 4000 px | 10.7 ملین | 100% |
| 2560 px | 4.4 ملین | 41% |
| 1920 px | 2.5 ملین | 23% |
| 1280 px | 1.1 ملین | 10% |
| 800 px | 0.4 ملین | 4% |
یہ فیصد حسابی ہیں، کسی خاص فائل کی پیمائش نہیں — کمپریس شدہ فائل اپنے پکسلوں کی تعداد کے عین تناسب سے نہیں سکڑتی۔ پھر بھی سب سے پہلے دیکھنے کے لیے یہی درست چیز ہیں، کیونکہ یہ بتاتے ہیں کہ سائز کم کرنا اینکوڈر کو تفصیل پھینکنا شروع کرنے سے پہلے کتنی گنجائش دے رہا ہے۔
کوالٹی کا سلائیڈر کر کیا رہا ہے
JPEG اینکوڈر میں کوالٹی کا عدد اُن تقسیم کاروں کی ٹیبل کو پیمانہ دیتا ہے جو ہر 8×8 بلاک کے فریکوئنسی کوایفیشنٹس پر لگائے جاتے ہیں۔ کم کوالٹی کا مطلب موٹی تقسیم، یعنی زیادہ کوایفیشنٹ صفر پر پہنچ جاتے ہیں، یعنی کم بٹس۔ نظر آنے والی قیمت سب سے پہلے سخت کناروں اور ہموار گریڈینٹس میں ظاہر ہوتی ہے: متن کے ساتھ رِنگنگ، اور آسمان میں بینڈنگ۔
یہ پیمانہ نہ لکیری ہے اور نہ مختلف فارمیٹس کے درمیان قابلِ موازنہ۔ JPEG اینکوڈر، WebP اینکوڈر اور AVIF اینکوڈر میں کوالٹی 80 تین بالکل الگ الگ عدد ہیں جن میں صرف رینج مشترک ہے۔ نتیجے کو پورے سائز پر دیکھ کر پرکھیں، عدد پر بھروسا کر کے نہیں۔
ہدف حجم سیٹنگ نہیں، تلاش کیوں ہے
کوئی اینکوڈر “اسے 500 KB کر دو” کو ہدایت کے طور پر قبول نہیں کرتا۔ وہ کوالٹی کی سیٹنگ لیتا ہے اور اُس خاص تصویر کے لیے وہ سیٹنگ جو حجم پیدا کرے، وہی دے دیتا ہے۔ چنانچہ جو ٹول آپ کو ہدف حجم کی سہولت دیتا ہے وہ دراصل ایک تلاش چلا رہا ہوتا ہے: اینکوڈ کرو، ناپو، کوالٹی بدلو، دوبارہ اینکوڈ کرو، اور جب نتیجہ بجٹ کے اندر آ جائے یا کوالٹی کی فرش تک پہنچ جائے تو رک جاؤ۔
اسی لیے ہدف ہمیشہ بہترین کوشش ہوتا ہے۔ ہو سکتا ہے تفصیل بھری، شور والی، اونچی ریزولوشن کی کوئی تصویر ایسی کسی بھی کوالٹی پر تنگ بجٹ میں نہ سمائے جو کسی انسان کو قبول ہو، اور ایمانداری کا تقاضا یہ ہے کہ فرش پر رک کر آپ کو بتا دیا جائے کہ کہاں رکے — نہ کہ تصویر برباد ہونے تک چلتے رہا جائے۔ FileSlimmer کے ہدف حجم والے ٹولز پہلے ابعاد کم کرتے ہیں، پھر مقررہ حدوں کے درمیان کوالٹی کو تنگ کرتے ہیں، اور جس سیٹنگ پر ختم ہوئے وہ بتا دیتے ہیں۔
تصویر کو 1 MB سے چھوٹا کیسے کریں
شروعات یوں کریں کہ فون کی تصویر کو اُن سب سے بڑے ابعاد پر لے آئیں جو منزل کو درکار ہیں۔ ای میل، فارم اور عام ویب صفحات کے لیے یہ اکثر کیمرے کی اصل تصویر سے کہیں نیچے ہوتا ہے۔ پھر ایک نئی JPEG یا WebP اعلیٰ مگر انتہائی نہیں والی کوالٹی پر اینکوڈ کریں، نتیجہ ناپیں، اور کوالٹی صرف اُس صورت میں آہستہ آہستہ کم کریں جب فائل اب بھی 1 MB سے اوپر ہو۔
صرف کوالٹی یہ طے نہیں کرتی کہ نتیجہ 1 MB سے نیچے آئے گا یا نہیں، کیونکہ تفصیل بھری تصویروں کو سادہ تصویروں سے زیادہ ڈیٹا درکار ہوتا ہے۔ اگر پہلا مرحلہ حد سے چوک جائے تو کوالٹی مزید نیچے دھکیلنے سے پہلے ابعاد کم کریں۔ عام طور پر اس سے تصویر ہر پکسل رکھ کر سخت بلاک یا رِنگنگ کے نقص شامل کرنے کے مقابلے میں زیادہ قدرتی لگتی ہے۔
جو چیزیں مدد نہیں کرتیں
- فائل کو ZIP میں ڈالنا۔ کمپریس شدہ امیج فارمیٹس میں اتنی زائد گنجائش باقی ہی نہیں بچتی کہ کوئی عام مقصد کا کمپریسر کچھ ڈھونڈ سکے؛ آرکائیو عموماً اصل حجم سے برائے نام ہی مختلف ہوتی ہے۔
- ایکسٹینشن بدل دینا۔ بائٹس نہیں بدلتے، اور جو سافٹ ویئر فائل کا اصل سگنیچر پڑھتا ہے وہ بس الجھ جائے گا۔
- JPEG کو اُسی کوالٹی پر دوبارہ سیو کرنا۔ یہ دوسرا لاسی مرحلہ ہے: فائل کسی کارآمد حد تک چھوٹی نہیں ہوتی اور تصویر تھوڑی اور خراب ہو جاتی ہے۔
- اگر صرف حجم مقصود ہو تو تصویر سے میٹا ڈیٹا ہٹانا۔ کئی میگا بائٹ پکسلوں کے سامنے چند کلوبائٹ کا EXIF شور کے برابر ہے۔ اسے پرائیویسی کی وجوہات سے ہٹائیں، جو حقیقی ہیں، حجم کے لیے نہیں۔
ایک طریقۂ کار جو عموماً منزل تک پہنچا دیتا ہے
- طے کریں کہ تصویر زیادہ سے زیادہ جس سائز پر دکھائی جائے گی وہ کیا ہے، اور سب سے لمبے کنارے کو اُسی پر لے آئیں۔
- مواد کے مطابق فارمیٹ چنیں: تصویروں کے لیے لاسی فارمیٹ، اسکرین شاٹس اور سادہ گرافکس کے لیے لاس لیس۔
- اعلیٰ مگر انتہائی نہیں والی کوالٹی سے شروع کریں اور اُس وقت تک نیچے آتے جائیں جب تک نقصان نظر آنے نہ لگے، پھر ایک قدم واپس اوپر ہو جائیں۔
- نتیجہ پورے سائز پر دیکھیں، اور اُسی قسم کی اسکرین پر جس کے لیے وہ بنا ہے۔
- اگر پھر بھی بڑا ہے تو پہلے قدم پر واپس جائیں۔ ابعاد میں تقریباً ہمیشہ کوالٹی سے زیادہ گنجائش ہوتی ہے۔
یہ کہاں کام کرنا چھوڑ دیتا ہے
کچھ تصاویر ان سب باتوں کے سامنے ڈٹ جاتی ہیں۔ باریک متن سے بھری اسکین شدہ دستاویز کو پڑھنے کے قابل رہنے کے لیے اپنے پکسل درکار ہوتے ہیں، اس لیے سائز کم کرنا فوراً نقصان دیتا ہے اور کوالٹی گھٹانے سے عین وہی نقص پیدا ہوتے ہیں جو متن کو پڑھنا مشکل بنا دیتے ہیں۔ اسپریڈ شیٹ کے اسکرین شاٹ کا مسئلہ بھی یہی ہے۔ ایسی صورتوں میں درست جواب اکثر کچھ کم کلوبائٹ کے بجائے کوئی مختلف فارمیٹ ہوتا ہے — لاس لیس، یا PDF۔
اور اگر کوئی پورٹل آپ کی فائل مسترد کر دے تو دیکھیں کہ حد فائل کے حجم پر ہے یا پکسل ابعاد پر۔ یہ دو الگ حدیں ہیں، اور جو فائل ایک پر پوری اترتی ہے وہ دوسری پر ناکام ہو سکتی ہے۔
اس کام کے ٹولز
مآخذ
- ITU-T T.81 — quantisation and the JPEG quality scale
- MDN — Image file type and format guide
- MDN — Responsive images and choosing a display width