ویب ورکر امیج پروسیسنگ کی بنیادی باتیں
ویب ورکر ایک الگ جاوا اسکرپٹ پر عمل درآمد کا سیاق و سباق ہے جو ایڈیٹر کے مین تھریڈ کو تمام کام کیے بغیر مہنگا حساب لگا سکتا ہے۔ براؤزر امیج پروسیسنگ کے لیے، اس کا مطلب ہے کہ ماڈل سیٹ اپ اور انفرنس بٹن، پروگریس میسجز، برش ان پٹ، اور اسکرین اپ ڈیٹس کے لیے ذمہ دار تھریڈ سے بھاگ سکتے ہیں۔
نتیجہ “مفت پس منظر کی پروسیسنگ” نہیں ہے۔ وہی آلہ اب بھی حساب کرتا ہے اور میموری کا استعمال کرتا ہے۔ آرکیٹیکچرل فائدہ علیحدگی ہے: ایک بھاری ماڈل آپریشن کے چلنے کے دوران انٹرفیس کے ہر ردعمل کو روکنے کا امکان کم ہوتا ہے۔
مین تھریڈ میں یوزر انٹرفیس کا کام ہے۔
براؤزر کا صفحہ عام طور پر جاوا اسکرپٹ کو مرکزی دھاگے پر چلاتا ہے۔ وہ تھریڈ لے آؤٹ، پینٹنگ اور ان پٹ کو بھی مربوط کرتا ہے۔ اگر ایک لمبا حساب اس پر قابض ہو جائے تو کلکس میں تاخیر محسوس ہو سکتی ہے، اینیمیشن رک سکتی ہے، اور براؤزر متنبہ کر سکتا ہے کہ صفحہ غیر جوابی ہے۔
تخمینہ شروع ہونے سے پہلے ایک تصویری ایڈیٹر کے پاس بہت ساری اہم ذمہ داریاں ہوتی ہیں:
- فائل کا انتخاب، پیسٹ، یا ڈراپ وصول کریں۔
- تصویر کو ڈی کوڈ اور ڈسپلے کریں۔
- پیشرفت اور غلطی کی حالتوں کو اپ ڈیٹ کریں۔
- پیش نظارہ کینوس کھینچیں؛
- برش موومنٹ شامل اور مٹانے کو ہینڈل کریں؛
- ڈاؤن لوڈ یا کلپ بورڈ کی کارروائیاں تیار کریں۔
ایک سیگمنٹیشن ماڈل کے عددی کام کو ایک ہی دھاگے پر ڈالنے سے وہ کام براہ راست مقابلہ کر سکیں گے۔ ایک کارکن ایک واضح حد بناتا ہے۔
پیغام پر مبنی حد
ایڈیٹر اور کارکن عام متغیرات کا اشتراک نہیں کرتے ہیں۔ وہ پیغامات بھیج کر بات چیت کرتے ہیں۔ ایک آسان بہاؤ اس طرح لگتا ہے:
- ایڈیٹر کسی کارکن کو تخلیق یا دوبارہ استعمال کرتا ہے۔
- یہ کارکن سے رن ٹائم اور ماڈل کو شروع کرنے کو کہتا ہے۔
- یہ تصویر کا ڈیٹا تیار کرتا ہے اور ایک تخمینہ کی درخواست بھیجتا ہے۔
- کارکن ڈیٹا کو ماڈل کے متوقع ان پٹ میں تبدیل کرتا ہے۔
- کارکن ماڈل چلاتا ہے اور ماسک ویلیوز تیار کرتا ہے۔
- یہ ماسک یا نتیجہ کا ڈیٹا واپس بھیجتا ہے۔
- ایڈیٹر پیش نظارہ کو کمپوزٹ کرتا ہے اور ریفائنمنٹ یا ایکسپورٹ کو قابل بناتا ہے۔
پیغامات میں صحیح درخواست کے جواب سے ملنے کے لیے کافی سیاق و سباق شامل ہونا چاہیے۔ اس سے فرق پڑتا ہے اگر کوئی صارف پچھلا کام ختم ہونے سے پہلے دوسری تصویر کا انتخاب کرتا ہے۔ انٹرفیس کو نئے ماخذ پر پرانا نتیجہ ظاہر کرنے سے گریز کرنا چاہیے۔
تصویری ڈیٹا کو کاپی اور ٹرانسفر کرنا
ایک چھوٹا ٹیکسٹ میسج بھیجنا سستا ہے۔ اگر براؤزر کو پورے بفر کو کاپی کرنا پڑے تو لاکھوں پکسل ویلیو بھیجنا مہنگا پڑ سکتا ہے۔ ویب APIs اس کے بجائے بعض بائنری بفرز کی ملکیت منتقل کر سکتے ہیں۔ ایک منتقل شدہ بفر بھیجنے والے کی طرف قابل استعمال ڈپلیکیٹ کو برقرار رکھے بغیر وصول کنندہ کو دستیاب ہو جاتا ہے۔
یہ اصلاح ایک ڈیزائن کی رکاوٹ کے ساتھ آتی ہے: منتقلی کے بعد، بھیجنے والا ایک ہی بفر کا استعمال جاری نہیں رکھ سکتا گویا وہ اب بھی ڈیٹا کا مالک ہے۔ ایک ایڈیٹر ایک علیحدہ ڈسپلے کی نمائندگی کو برقرار رکھ سکتا ہے، ایک وقف شدہ انفرنس بفر بنا سکتا ہے، یا بعد میں اس کی ضرورت کی تشکیل نو کر سکتا ہے۔
ہر عمل درآمد بالکل اسی جگہوں پر منتقلی کا استعمال نہیں کرتا ہے۔ عام سبق یہ ہے کہ دھاگے کی علیحدگی ڈیٹا کی نقل و حرکت کو غائب نہیں کرتی ہے۔ تصویر کے طول و عرض، بفر سائز، اور تبادلوں کی تعداد اب بھی تاخیر اور میموری کو متاثر کرتی ہے۔
جو Easy Background Remover ورکر میں ڈالتا ہے۔
Easy Background Remover آن ڈیوائس سیگمنٹیشن کے لیے براؤزر انفرنس رن ٹائم کے ساتھ ویب ورکر کا استعمال کرتا ہے۔ بھاری خودکار کٹ آؤٹ مرحلہ ایک ماسک تیار کرتا ہے۔ اس کے بعد ایڈیٹر مرکب نتیجہ دکھاتا ہے اور CPU-کینوس برش کو بہتر بنانے کی حمایت کرتا ہے۔
یہ علیحدگی ناکامیوں کو زیادہ مفید حد فراہم کرتی ہے۔ اگر کارکن ابتداء نہیں کر سکتا یا تخمینہ کے دوران کریش ہو جاتا ہے، تو انٹرفیس صرف سگنل کے طور پر مستقل طور پر منجمد ٹیب پر انحصار کرنے کے بجائے کارکن سے متعلق غلطی کی اطلاع دے سکتا ہے۔
یہ مقامی پروسیسنگ کے دعوے کو بھی قابل فہم رکھتا ہے۔ ایکسٹینشن پیج سے اپنے کارکن کو پکسلز بھیجنا براؤزر کے ماحول میں مواصلت ہے، ریموٹ کٹ آؤٹ API پر اپ لوڈ نہیں۔ پہلا سیشن الگ سے دوبارہ قابل استعمال ماڈل اثاثہ ڈاؤن لوڈ کر سکتا ہے۔ دیکھیں پہلے رن کیوں ماڈل ڈاؤن لوڈ کرتا ہے۔
ایک کارکن حساب کو فوری نہیں کرتا ہے۔
کارکن ردعمل کو بہتر بناتے ہیں، نہ کہ خام ڈیوائس کی صلاحیت۔ ماڈل اب بھی CPU، GPU، یا دیگر رن ٹائم وسائل استعمال کرتا ہے اس کے مطابق جو براؤزر فراہم کر سکتا ہے۔ ایک بڑے ان پٹ میں اب بھی زیادہ وقت لگ سکتا ہے اور اسے چھوٹی سے زیادہ میموری کی ضرورت ہوتی ہے۔
کئی حدود باقی ہیں:
- ماڈل کی ابتداء کی اصل قیمت ہوتی ہے۔
- اگر کاپی کیا جائے تو پکسل بفرز دونوں طرف میموری پر قبضہ کرتے ہیں۔
- سائز تبدیل کرنے اور فارمیٹ کی تبدیلی میں وقت لگتا ہے۔
- کم میموری والے آلات بڑی تصاویر کے ساتھ جدوجہد کر سکتے ہیں۔
- زیادہ کارکن تنازعات کو کم کرنے کے بجائے بڑھا سکتے ہیں۔
- برآمد اور کینوس اپ ڈیٹس میں اب بھی مرکزی دھاگہ شامل ہوسکتا ہے۔
پانچ امیجز کے لیے پانچ انفرنس ورکرز کو شروع کرنا خود بخود پانچ گنا تیز نہیں ہوتا ہے۔ کارکن ایک ہی مشین کا اشتراک کرتے ہیں۔ متوازی ملازمتیں میموری بینڈوڈتھ اور عمل درآمد کے وسائل کے لیے مقابلہ کر سکتی ہیں، جب کہ ہر ماڈل کی مثال اپنی میموری کی قیمت لے سکتی ہے۔
پیش رفت کی رپورٹنگ تعاون پر مبنی ہے۔
ایک کارکن اسٹیٹس پیغامات بھیج سکتا ہے، لیکن یہ خود بخود نہیں جانتا کہ ترقی کا فیصد درست محسوس ہوگا۔ ماڈل ڈاؤن لوڈ، رن ٹائم ابتدا، ان پٹ کی تیاری، تخمینہ، ماسک کنورژن، اور پیش نظارہ رینڈرنگ مختلف اوقات کے ساتھ الگ الگ مراحل ہیں۔
کچھ مراحل میں قابل پیمائش بائٹ شمار ہوتے ہیں۔ ایک ماڈل پر عمل درآمد صرف “شروع” اور “ختم” کو ظاہر کر سکتا ہے۔ ایک ہموار فیصد جو یکساں طور پر آگے بڑھتا ہے اس لیے درست پیمائش کے بجائے کاسمیٹک ہو سکتا ہے۔
مفید پیشرفت UI جب ممکن ہو تو مرحلے کا نام دیتا ہے: ماڈل کی تیاری، تصویر پر کارروائی، یا عمارت کا نتیجہ۔ یہ اسپنر کو بغیر کسی وضاحت کے چھوڑنے کے بجائے ناکامی اور منسوخی کو بھی سنبھالتا ہے۔
منسوخ کرنا اسپنر کو چھپانے سے زیادہ ہے۔
اگر صارف کسی تصویر کو بند کرتا ہے یا دوبارہ شروع کرتا ہے، تو انٹرفیس پرانی درخواست کے حتمی جواب کو نظر انداز کر سکتا ہے۔ بنیادی حساب کتاب کو فوری طور پر روکنے کے لیے رن ٹائم سے اضافی مدد کی ضرورت ہو سکتی ہے یا کارکن کو ختم کرنے اور دوبارہ تخلیق کرنے کی ضرورت پڑ سکتی ہے۔
کسی کارکن کو ختم کرنا فیصلہ کن ہے، لیکن یہ اس کی ابتدائی حالت کو رد کر دیتا ہے۔ اگلی نوکری میں ماڈل کو دوبارہ لوڈ اور شروع کرنے کی ضرورت پڑسکتی ہے۔ ایک مختصر آپریشن کے لیے، نتیجہ باسی کو نشان زد کرنا ہر چیز کو پھاڑنے سے سستا ہو سکتا ہے۔
صحیح انتخاب کا انحصار میموری کے دباؤ، آپریشن کی مدت، اور رن ٹائم کی صلاحیتوں پر ہے۔ صارف کے نقطہ نظر سے، اہم اصول یہ ہے کہ باسی کام کو موجودہ ترمیم کو اوور رائٹ نہیں کرنا چاہیے۔
غلطیوں کو بھی حد سے گزرنا پڑتا ہے۔
ایک کارکن کے اندر ایک استثناء عام مین تھریڈ کی رعایت نہیں بنتا ہے۔ کارکن کو قابل استعمال غلطیوں کی اطلاع دینی چاہیے، اور ایڈیٹر کو کارکن کی سطح کی ناکامیوں کو سننا چاہیے۔
اچھی خرابی سے نمٹنے سے کم از کم فرق ہوتا ہے:
- ماڈل اثاثہ دستیاب نہیں؛
- ماڈل کی شروعات ناکام ہوگئی؛
- تصویر کو ڈی کوڈ یا ان پٹ کی تیاری ناکام ہوگئی۔
- اندازہ ناکام؛
- کارکن غیر متوقع طور پر رک گیا؛
- نتیجہ اب موجودہ درخواست سے تعلق نہیں رکھتا۔
یہ عام “کچھ غلط ہو گیا” کے مقابلے میں زیادہ قابل عمل ہے، خاص طور پر جب پہلی بار چلنے والی سیٹ اپ اور عام امیج پروسیسنگ میں مختلف علاج ہوتے ہیں۔
ورکر آؤٹ پٹ اب بھی صرف پہلا ماسک ہے۔
تھریڈ فن تعمیر خود ایک مبہم کنارے کو بہتر نہیں کرتا ہے۔ کارکن تکنیکی طور پر درست ماسک واپس کر سکتا ہے جس میں کھال، شفاف مواد، تنگ پٹے، یا مطلوبہ سایہ نہ ہو۔ وہ سیگمنٹیشن اور نیت کے سوالات ہیں۔
ایڈیٹر کا کام اندازہ لگانے کے بعد دوبارہ شروع ہوتا ہے: ماسک کو ورکنگ کوآرڈینیٹ سسٹم میں پیمانہ کریں، ایک پیش نظارہ بنائیں، صارف کو اسے بہتر کرنے دیں، اور موجودہ حالت کو برآمد کریں۔ ماسک ریزولیوشن بمقابلہ پیش نظارہ سائز بتاتا ہے کہ ان کوآرڈینیٹ سسٹمز کو الجھن کیوں نہیں ہونی چاہئے۔
ایک جامع ذہنی ماڈل
میسج ونڈو کے پیچھے کارکن کے بارے میں ایک مقامی ماہر کے طور پر سوچیں:
- ایڈیٹر تعامل کا مالک ہے۔
- کارکن بھاری تخمینہ کام کا مالک ہے؛
- بائنری امیج ڈیٹا ایک متعین حد کو عبور کرتا ہے۔
- کارکن ایک ماسک واپس کرتا ہے، ہر کنارے کے بارے میں مکمل فیصلہ نہیں؛
- ایڈیٹر موجودہ حالت، جائزہ، تطہیر اور برآمد کے لیے ذمہ دار رہتا ہے۔
خود پکسلز کے ماڈل کے نظارے کے لیے، واٹ ایک آن ڈیوائس کٹ آؤٹ ماڈل دیکھتا ہے کے ساتھ جاری رکھیں۔ آخر سے آخر تک عملی جائزہ کے لیے، دیکھیں مقامی پس منظر کو ہٹانا کیسے کام کرتا ہے۔