تحقیق مقاله فرمت فایل JPEG

مقدمه:

مزیت JPEG پیشرفته اینست که اگر یک تصویر ضمن اینکه منتقل می شود، بلافاصله نمایش داده شود، شما می توانید خیلی بسرعت کل تصویر را بطور تقریب با اصلاح تدریجی کیفیتببیند تا کسی که مدت طولانی تری منتظر می ماند و این خیلی مجهتر از یک نمایش کند ازبالا تا پایین تصویر می باشد. صغفش اینست که هر اسکنی حدوداًبه میزان یکسانی محاسبه برای نمایش، متوسل می شود همانطور که کل فایل JPEG خط مبنا باید باشد. بنابراین JPEG پیشرفته فقط وقتی حساس می شود که فردی کُدبرداری داشته باشد که در مقایسه با اتصال ارتباطی سریع

است. (اگرداده ها بسرعت برسد، یک کُدبرداری // پیشرفته می تواند بوسیله جهش بعضی گذرهای نمایشی، وفق یابد. از اینرو کُد برداری شما به قدر کافی فرمت دارد تا TI داشته باشد یا اتصالات شبکه ای سریعتر ممکن است هیچ تفاوتی رابین JPEG پیشرفته، و با قاعده نبیند، اما بر روی یک اتصال سرعت مودم، JPEG پیشرفته،  وسیع می باشد.)

تا همین اواخر، کاربردهای زیادی در JPEG پیشرفته که جذاب بنظر می رسید، وجود نداشت، بنابر این آن بطور وسیعی اجرا نمی گشت. اما با شهرت جستجو گرهای شبکه جهانی وب در اجرای اتصالات کند مودم و با اسب بخار در حال افزایش کامپیوترهای شخصی، JPEG پیشرفته برنده کاربرد شبکه جهانی وب شده است، نرم افزار JPEG آزاد JJG اکنون از JPEG پیشرفته  حمایت می کند وتوانایی جستجو گرها و دیگر برنامه های شبکه جهانی وب بسرعت گسترده می گردد. به استثنای توانایی  فراهم کردن نمایش پیشرفته، // JPEG پیشرفته و JPEG خط مبنا اساساً یکسان هستند و آنها بخوبی بر روی انواع تصویر های مشابه کار می کنند. ممکن است بین نمایش های خط مبنا و پیشرفته یک تصویررا بدون لطمه به کیفیت تبدیل می کند (اما برای انجام این مورد نرم افزارخاصی نیاز می باشد، تبدیل بوسیله خروج از فشردگی و دوباره فشرده کردن به دلیل خطاهای گردکردن برشی بدون خسارت نمی باشد.) یک فایل JPEG پیشرفته به هیچ وجه فقط بوسیله یک کُد برداری JPEG خط مبنا، قابل خواندن نیست، بنابر این نرم افزار موجود باید قبل از اینکه JPEG پیشرفته را بتوان بطور گسترده ای استفاده کرد، ارتقاء یابد. موضوع 16 در بخش 2 را برای آخرین اخبار در مورد برنامه هایی که از آن پشتیبانی می کنند، ببینید. می توانم من یک JPEG شفاف بسازم؟

نه. JPEG از شفافیت پشتیبانی نمی کند و احتمالاً آنرا به سرعت انجام نمی دهد. آن آشکار می کند که اضافه شدن شفافیت به JPEG نباید کار ساده ای باشد. اگر جزئیات کاملی می خواهید تا پایان بخوانید و کسب اطلاع کنید. شیوه قدیمی برای شفافیت کُد در GIF  دیگر الگوهای فایلی یافت شده، یک مقدار رنگی که از جهات دیگر استفاده نشده برای که نشانگر یک سلول تصویری شفاف می باشد، انتخاب می شود که نمی تواند در JPEG کار کند. زیرا JPEG پراتلاف می باشد. یک سلول تصویری ضرورتاً با همان رنگی که با آن شروع شده، آشکار نمی شود. بطور معمول یک خطای جزئی در مقدار سلول تصویری عیبی ندارد. زیرا بطور جزئی تصویر را تحت تأثیر قرار می دهد. اما اگر آن سلول تصویری را از شفاف به نرمال یابد. عکس تغییر دهد، این خطا کاملاً آشکار و مزاحم می باشد، بخصوص اگر زمینه اصلی کاملاً متفاوت از رنگ شفاف باشد. یک شیوه معقولانه تر ذخیره کردن کانال آنها (درصد شفافیت) همانند یک عنصر جداگانه رنگ در یک تصویر JPEG می باشد.

آن می تواند کار کند زیرا یک خطای کوچک در آلفا فقط تفاوتی جزئی در نتیجه کار ایجاد می کند. مشکل اینست که کانال آلفای معمولی دقیقاً نوعی از تصویر باشد که بطوری بدی بر روی JPEG انجام می شود. مقدار زیادی نواحی مسطح بزرگ و پرشهای ناگهانی. شما باید از یک مجموعه با کیفیت بسیار بالا برای کانال آلفا استفاده کنید. این کار را می توان انجام داد، اما این پنالتی برای اندازه فایل بزرگ می باشد. یک JPEG شفاف این شیوه را که می تواند به آسانی اندازه یک JPEG غیرشفاف را دوبرابر کند، انجام می دهد. قیمت پرداختی بیشترین کاربردهای شفافیت بسیار بالا می باشد. تنها راه حل واقعی اینست که ذخیره سازی پراتلاف تصویر JPEG را با ذخیره سازی بدون اتلاف یک الگوی (پوشش) شفافیت با استفاده از تعدادی الگوریتم دیگر ترکیب کنید. توسعه، استانداردسازی، و ترویج توانایی یک قالب فایل برای کارکردن، کار کوچکی نیست. تا آنجایی که من می دانم هیچ کار جدی بر روی آن انجام نشده و بنظر نمی رسد که شفافیت ارزش تلاش و کار بیشتری داشته باشد.

یک JPEG بدون اتلاف وجود ندارند؟

آشفتگی زیادی در مورد این موضوع وجود دارد که تعجب برانگیز نیست. زیرا چندین شیوه مقایسه ای مختلف وجود دارد که همگی بعنوان JPEG شناخته شده می باشد. شیوه ای که معمولاً استفاده می شود، JPEG خط مبنا می باشد. (یا نوع دیگرش JPEG پیشرفته می باشد.) همچنین استاندارد ایزو (JSO) مشابهی یک شیوه بسیار متفاوت بنام JPEG بدون اتلاف را تعریف می کند. اگر خیلی آشفته نباشد، یک استاندارد جدید بدون اتلاف بنام «JPEG LS» تقریباً سر از خیابانها درمی آورد. وقتی می گویم «بدون اتلاف» منظورم از بی اتلاف از نظر ریاضیاتی این می باشد که: یک الگوریتم مقایسه ای بدون اتلاف، الگوریتمی است که خروجی (برونداد) از فشردگی خارج شده اش را که بیت به بیت با ورود (درونداد) اصلی یکسان می باشد، ضمانت می کند. این یک ادعای قوی تر از «غیرقابل تفکیک شدن تصویری از اصل» می باشد.

JPEG خط مبنا می تواند به تصویری با قابلیت تفکیک پذیری برای تصاویری که بیشترین شباهت را به عکس دانرد، دست یابد، اما آن نمی تواند هرگز کاملاً بدون اتلاف باشد. JPEG بدون اتلاف یک شیوه کاملاً متفاوت است که واقعاً بدون اتلاف می باشد. با این وجود آن کمابیش همانند JPEG خط مبنا فشرده نمی شود، آن بطور معمولی می تواند داده های تمام رنگی را تا حدود 2:1 فشرده کند و JPEG بدون اتلاف بخوبی فقط بر روی تصاویر آهنگ پیوسته کار می کند.

آن فشردگی مُفیدی از تصاویر صفحه رنگ یا تصاویری با بیت عمق کم تهیه نمی کند. JPEG بدون اتلاف در حقیقت هرگز به شهرت نرسیده و هیچ کاربرد معمولی آنرا پشتیبانی نمی کند و آن اکنون کاملاً غیرقابل استفاده می باشد. (برای مثال استاندارد جدید PNG ، JPEG بدون اتلاف را بر روی بیشترین تصاویر فشرده می سازد.) با درک این مطلب کمیته ISO JPEG اخیراً یک استاندارد فشردگی بدون اتلاف کاملاً جدید بنام JPEG-LS را تکمیل کرده است. (شما همچنین ممکن است از آن تحت نام LOCO می شنوید.) JPEG-LS ، فشردگی بهتری از JPEG اصلی بدون اتلاف ارائه می دهد، اما هنوز نزدیک به آن چیزی که شما می توانید با یک شیوه پُراتلاف بدست آورید، نمی شود.

هر کسی حدس می زد که آیا این استاندارد جدید به شهرت می رسد یا نه. آن تکرار باارزشی می باشد که یک اجرای منظم JPEG را با حداکثر حالت کیفیتش آغاز می کند که به شما ذخیره سازی بدون اتلاف نمی دهد، حتی در بالاترین حالت کیفیت ممکن. JPEG خط مبنا پراتلاف می باشد. زیرا آن به خطاهای گِرد کردن برشی در محاسبات مختلف منوط می شود. خطاهای گِرد کردن برشی به تنهایی تقریباً همیشه خیلی کوچکتر از آنی است که دیده شود. اما اگر شما تصویر را از طریق چرخه های چندگانه فشردگی مرتبط کنید، آنها انباشته می شوند. خیلی از اجراها حتی به شما اجازه نمی دهند که به حداکثر محیط ممکن دست یابید، زیرا آن همانند یک شیوه کم بازده برای استفاده JPEG منظم می باشد. برای مثال با نرم افزار JJG JPEG شما مجبور نیستید فقط «کیفیت 100» را انتخاب کنید. همچنین نمونه برداری از کارافتاده کروما (رنگ) را برای به حداقل رساندن اتلاف اطلاعات، خاموش کنید. فایل های نتیجه خیلی بزرگتر می باشند و فقط از نظر کسری کیفیت بهتری از فایل های تولید شده در محیطهای معقولانه تری دارد. آنها هنوز کمی پراتلاف می باشند. اگر شما واقعاً به ذخیره سازی بدون اتلاف نیاز دارید، تلاش نکنید با JPEG منظم به آن نزدیک شوید.

چرا تمام مدارک در مورد قالبهای فایل می باشد؟

JPEG فقط به خانواده الگوریتم های فشردگی اشاره می کند نه به یک قالب فایل تصویر ویژه. کمیته JPEG از تعریف قالب فایل توسط جنگهای قلمروی در داخل سازمانهای بین المللی استانداردها جلوگیری می کند. از آنجایی که ما نمی توانیم عملاً تصاویر را هر شخص دیگری تعویض کنیم مگر اینکه بر روی یک قالب فایل مشترک توافق کنیم. این مورد برای ما یک مشکل بوجود می آورد. در غیاب استانداردهای رسمی، تعدادی از نویسندگان برنامه JPEG فقط برای انجام کارهای خودشان آنرا ترک می کنند و در نتیجه برنامه هایشان با هر شخص دیگری قابل وفق نیست. نزدیکترین چیزی که ما با یک قالب JPEG استاندارد داریم، تعدادی کار است که بوسیله مردم در میکروسیستم های C-Cube هماهنگ می شود. آنها دو قالب فایل بر مبنای JPEG را تعریف می کنند.

JFIF (قالب تغییر فایل JPEG) یک قالب ارزان قیمت که سلولهای تصویری را انتقال می دهد نه چیز دیگری را. TIFF/JPEG ، TIFF 6/0 aka ، توسعه قالب Aldus TIFF . TIFF یک قالب گران قیمت می باشد که به شما اجازه ثبت فقط در مورد چیزی را می دهد که شما همیشه می خواستید در مورد یک یک تصویر و اطلاعات جانبی تر بدانید. JFIF بعنوان یک استاندارد غیررسمی بر روی اینترنت ظاهر می شود و چیزی است که بطور معمول بوسیله یک «فایل PEG » معنی می شود. بیشترین خوانندگان JFIF همچنین توانایی دستکاری تعدادی قالبهای مختلف نه کاملاً قانونی JFIF را دارند. خصوصیت TIFF 6/0 برای یکپارچه کردن JPEG بطور وسیعی اجرا نمی شود، زیرا تا اندازه ای آن تعدادی نقص جدی طرحی دارد. طرح بازبینی شده TIFF/TPEG اکنون بوسیله یادداشت # 2 تکنیکی TIFF توصیف می شود، این طرح موردی بود که در 0/7 TIFF استفاده شد. اجراهای جدید TIFF باید از طرح یادداشت تکنیکی برای توکاری کردن TIFF 6/0 استفاده کند نه از طرح. (تا جایی که من می دانم، سیستم های Next Step (قدم بعدی) تنها سیستم هایی هستند که هرگونه کاربرد قابل توجهی از نوع TIFF/JPEG,TIFF 6/0 بوجود می آورند.) حتی وقتی که TIFF/JPEG ثابت است، آن هرگز بطور گسترده ای استفاده نخواهد شد.

TIFF خیلی پیچیده تر از JFIF می باشد و بطور کلی خیلی قابل انتقال نمی باشد، زیرا عرضه کننده های مختلف اغلب با اختلاف کمی اجرا می شود نه با همگامی دو یا چند عملکرد زیرمجموعه های TIFF. و اضافه کردن JPEG به این ترکیب هیچ کمک نکرده است. نرم افزار Quick Time مگینتاش از جریان داده های سازگار با JFIF بسته بندی شده داخل قالب DICT مخصوص Macاستفاده می کند. تبدیل بین JFIF و DICT/JPEG کاملاً مستقیم می باشد. و چندین برنامه Max (میگنتاش) برای انجام آن قابل دسترس می باشد. اگر شما ویراستاری دارید که فایل های دودویی را دستکاری می کند، شما می توانید یک فایل DICT/JPEG را با JFIF بوسیله دست تغییر دهید. برای جزئیات فصل بعد را ببینید.

فلاش خبر: کمیته SO JPEG بنظر می رسد در جنگهای قلمروی شان برنده شده اند. آنها ویژگی کامل قابل فایل را که در پسوندهای «بخش 3» جدید با استاندارد SPIFF,JPEG ، نامیده می شود، تعریف می کنند. اگرچه آن تا اندازه ای در بازی تازه است بنابراین آیا این تأثیر زیادی بر روی فایلهای دنیای واقعی خواهد داشت تا دیده شوند. SPIFF با JFIF سازگاری رو به پیشرفت می باشد، بنابراین اگر آن بطور گسترده ای پذیرفته شود، احتمالاً بیشتر کاربران حتی توجه هم نمی کنند.

چگونه بفهمم که من قالب فایل دارم و چه چیزی در مورد آن انجام دهم؟

اگر شما یک به اصطلاح فایل JPEG داشته باشید که نرم افزارتان آنرا نمی خواند، آن احتمالاً تعدادی قالب اختصاصی بر مبنای JPEG می باشد. شما می توانید با بررسی اولین چند بایت فایل بگوئید چه چیزی دارد:

1 فایل استاندارد JFIF با چهار بایت (hen) FF D8 FF EO شروع می شود و با دو بایت متغیر (اغلب hex oo) و سپس با JFIF دنبال می شود.

2 اگر شما FF D8 FF را در آغاز ببینید، اما نشانگر JFIF را نبینید، احتمالاً یک فایل ناقص JFIF JPEG دارید. بیشتر نرم افزارهای JFIF باید آنرا بدون شکایت بخوانند. اگر شما از چیزی استفاده می کنید که به اندازه کافی برای شکایت در مورد فقدان یک نشانگر JFIF سختگیر می باشد، کُدبردار دیگری را امتحان کنید.

(هم فایل های خیلی قدیمی JPEG و هم فایل های خیلی جدید JDEG ممکن است فاقد نشانگرهای JFIF باشد، استاندارد جدید SPIFF در بالا اشاره کرد که از نشانگر JFIF استفاده نمی کند. بنابراین فروشنده نرم افزارتان را بیابید اگر شما گمان می کنید این مشکل ساز شود.)

3 فایل DICT مگینتاش در صورتیکه JPEG فشرده شده باشد، چند صد بایت سرانداز (عنوان) خواهد داشت. (اغلب 726 بایت، اما نه همیشه) که به وسیله داده های JPEG دنبال می شود.

رشته 3 بایتی FF D8 FF را جستجو کنید. Pkoto - JPEG متن معمولاً قبل از این عنوان بطور ناگهانی ظاهر می شود، و Apple Mark یا JFIF معمولاً ناگهان بعد از آن ظاهر می شود. هر چیزی را قبل از FF D8 FF دور کنید و شما قادر خواهید بود از فایل کُدبرداری کنید. (اگر تصویر PICT به دو باند چندگانه تقسیم شود، این عمل شکست می خورد.)  PLCT همدسته شده خوشبختانه خیلی معمول نیستند. یک PICT همدسته شده، شامل جریانات داده هایی است که ارتفاعاتش به کل ارتفاع تصویر اضافه می شود. اینها باید با همدیگر به پشت و در داخل یک تصویر دوخته شوند. بِیلی براون برای این هدف بر روی صفحه وب، تعدادی ابزار ساده در http://www.isomedia (Com/homes/baily/photo-jpey/photo-jpeg.html) دارد.

4 اگر این فایل از مگینتاش سرچشمه بگیرد، آن می تواند یک فایل استاندارد JFIF همراه با یک عنوان Mac.Binan/ پیوست شده باشد. در این مورد، عنوان JFIF بایت را در این فایل ظاهر می کند. از اولین 128 بایت صرفنظر کنید و شما آماده هستید.

5 هر چیزی دیگری: آن یک قالب اختصاصی است یا اصلاً JPEG نمی باشد، اگر خوش شانس باشید، ممکن است این فایل شامل یک عنوان و یک جریان داده های خام JPEG باشد.

حداقل یک نشر (عرضه) HiJaak pro ، فایلهای JFIF را که ادعای بازبینی بیشتر 2.ol دارد، می نویسد. هیچ چنین خصوصیتی وجود  ندارد، آخرین بازبینی JFIF 1/02 می باشد. بنظر می رسد HiJaak موجب بایت ها بالا و پایین رو به عقب می شود. متأسفانه بیشترین خوانندگان JFIF از مواجه با این فایل ها صرفنظر می کنند، زیرا این ویژگی JFIF ، تغییر مهم شماره نگارش را با میانگین یک تغییر سازگار قالب تعریف می کند. اگر نسخه (نگارش) 2.ol وجود داشت. بنابراین باید شماره دار می بود. زیرا نرم افزار جاری نمی توانست آنرا بخواند و نباید تلاش کرد. (کسی نمی داند که آیا HiJaak تا به حال در مورد آزمایش متقابل با نرم افزار افراد دیگر شنیده است.) اگر شما یکی از این فایلهایی را که بَد شماره دار شده، اجرا کنید، می توانید آنرا با ویراستار فایل بدون دودویی و بوسیله تغییر دوازدهمین بایت فایل از 2 تا 1، ثابت کنید.

چه مشکلات مشترک سازگار دیگری وجود دارد؟

صرفنظر از مشکلات قال فایل که در فصل قبل به آن اشاره شد، دلایل دردسر مشترک دیگری با انتقال JPEG ها وجود دارد. کُدبردارهای قدیمی که JPEG پیشرشفته را دستکاری (کنترل) نمی کنند، اغلب وقتی یک JPEG پیشرفته را تغذیه می کنند، پیغام های خطای نسبتاً مبهمی را ارائه می دهند. اگر شما یک شکایت شبیه «نشانگر پشتیبانی نشده نوع OxC2» دریافت کنید، پس شما بطور یقین یک فایل JPEG پیشرفته و یک کُد بردار غیرپیشرفته دارید (بخش 2 از FAQ را برای اطلاعاتی در مورد برنامه های به روز شده، ببینید.) شما ممکن است یک پیغام خطای عمومی (ژنریک) دریافت کنید که ادعا می کند این فایل خراب شده یا اصلاً JPEG نیست. فتوشاپ آدوبی و تعداد دیگری از کاربردهای متمایل به پیش فشردگی، فایل های چهار کانالی JPEG CMYK را وقتی درخواست ذخیره سازی یک JPEG از حالت تصویر CMYK می شود، تولید می کنند. غیرمحتمل است هر چیزی که درایت از پیش فشردگی ندارد، جوابگوی JPEG CMYK باشد. (یا هر قالب CMYK دیگری برای آن موضوع). وقتی که JPEG ها برای استفاده وب ساخته می شوند، مطمئن شوید آنرا از RGB یا حالت مقیاس سایه زنی (خاکستری) ذخیره کرده اید. فتوشاپ همچنین عادت بستن یک تصویر نسبتاً بزرگ پیش نمایش / تصویر کوچک شده را داخل یک بخش کاربردی خصوصی از فایل های JPEG دارد. تعدادی از کاربردهای دیگر (بطور چشمگیری عرضه های اولیه از کتابخانه Suns Java) برای مسدود شدن بر روی این داده ها شناخته شده است. این مسلماً یک خطا در دیگر کاربردهای آنها می باشد. اما قابل دسترس ترین پیرامون کاری می گوید: فتوشاپ یک تصویر کوچک شده را ذخیره نمی کند. اگر شما در حل قرار دادن یک تصویر بر روی وب هستید. تعبیه کردن تصویر کوچک شده در آن، به هر صورت اتلاف زمان انتقال است. وقتی انتقال تصاویر بین ماشین هایی که سیستم های عملیاتی مختلف را اجرا می کنند برای کسب یک انتقال مستقیم «دودویی» بسیار با دقت باشد، هر نوع تبدیل فرمت (قالب) متن، فایل JPEG را خراب می کند. عملاً آن برای تمام قالب های تصاویری که فقط JPEG نیستند، درست می باشد.

چگونه JPEG کار می کند؟

جزئیات تکنیکی خارج از بحث FAQ می باشد اما شما می توانید یک مقدمه و مرجعی برای مطالب بعدی در Comp.Compress – in FAQ پیدا کنید که در این سایت قابل دسترس می FAQ باشد. http://www.faqs.org/fuqs/CompressiOn-faq (همچنین ببینید «کجا لیست های  بایگانی می شود؟»). ترکیب فشرده سازی FAQ یک نقطه شروع خوب برای اطلاعات بر روی دیگر شیوه های تکنولوژی جدید فشرده سازی تصویر می باشد همانند فراکتال (کسرینه) و موجهای کوچک.

یک فشرده سازی سریع: موجهای کوچک احتمالاً براساس نسل بعد استانداردهای پراتلاف فشرده سازی تصویر می باشند. اما شاید آنها 10 سال عقب تر از JPEG در استاندارد کردن خطوط موازی باشند. فراکتال ها (کسرینه ها) بوسیله مبلغان تجاری مهم شان بیش از حد تحریک شدند و بنظر می رسید که اشتیاق را از دست داده اند که مردم بیشتر در مورد توانایی ها و محدودیتهای حقیقی شان یاد بگیرند.

کُدنویسی محاسباتی (حسابی) چگونه کار می کند؟

ویژگی JPEG دوماژول (واحد) کمکی مختلف را برای خروجی نهایی داده های فشرده شده، تعریف می کند: امکان یا کُدنویسی (برنامه نویسی) Huffman یا برنامه نویسی محاسباتی می باشد. این انتخاب هیچ تأثیری بر روی کیفیت تصویر ندارد، اما برنامه نویسی محاسباتی معمولاً یک فایل فشرده شده کوچکتری ایجاد می کند. بر روی تصاویر معمولی، برنامه نویسی محاسباتی یک فایل 5 تا 10 درصدی کوچکتر از برنامه نویسی Huffmen (هافمن) تولید می کند. تمام شماره اندازه های فایل که قبلاً ذکر شده برای برنامه نویسی هافمن می باشد. متأسفانه، نوع خاصی از برنامه نویسی محاسباتی بوسیله استاندارد TPEG مشخص می شود، منوط به پروانه های ساخت توسط JBM ، AT8T و میتسوبیشی می باشد. بنابراین شما نمی توانید بطور قانونی از برنامه نویسی محاسباتی JPEG استفاده کنید مگر اینکه شما مجوزهای این شرکت ها را بدست آورید. (مورد استثناء «کاربرد آزمایشی» قانونی پروانه ساخت به مردم امکان می دهد تا یک شیوه قابل ثبت را در متن تحقیقات علمی آزمایش کنند، اما هیچ کاربرد شخصی تجاری یا روال (زیربرنامه)، قانون شکنی نیست.) من پیشنهاد کردم که مردم از برنامه نویسی محاسباتی JPEG استفاده نکنند، ذخیره سازی های فضایی آنقدر زیاد نیست که مجادلات بالقوه قانونی را توجیه کند. بخصوص برنامه نویسی محاسباتی نباید بر روی تصاویری که بر روی اینترنت تبدیل شده اند، استفاده شود. حتی اگر شما قانون روانه ساخت US را مراعات نکنید دیگر گروه ها آنرا انجام می دهند.