و باز هم یک پروژه بسیار مفید برای پردازش تصویر کاران گرامی،
شما با استفاده از این پروژه میتونید، تصویر زنده گرفته شده از ویکم کامپیوتر و یا لبتابتون رو به صورت مستقیم پردازش کنید و نمودار هیستوگرام را به صورت دو بعدی و سه بعدی مشاهده کنید، وقتی که تصویر ثابت باشه هم نمودار سه بعدی شروع به چرخیدن به صورت خودکار میکنه
این فایل ترجمه فارسی مقاله زیر می باشد:
RGB Histogram based Color Image Segmentation Using Firefly Algorithm
چکیده
در این مقاله، تقسیم بندی تصویر چند سطحی بهینه با استفاده از الگوریتم کرم شب تاب (FA) ارائه شده است. در این کار، هیستوگرام RGB تصویر برای تقسیم بندی دو سطحی و چند سطحی در نظر گرفته شده است. آستانه بهینه برای هر جزء رنگ توسط ماکزیمم سازی تابع واریانس بین طبقه اوتسو به دست آورده شده است. روش تقسیم بندی ارائه شده با استفاده از مجموعه داده استاندارد RGB نشان داده شده است و با استفاده از FA موجود در ادبیات همراه با سه راهبر جستجوی تصادفی، مانند توزیع براونی، پرواز لوی و توزیع گاوسی متغیر تصادفی مربوط اعتبارسنجی شده است. ارزیابی عملکرد بین FA ها با استفاده از پارامترهایی مانند مقدار هدف، PSNR، SSIM و زمان CPU انجام شده است.
توضیحات: فایل ترجمه به صورت word می باشد و دارای 19 صفحه است.
لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل:Word (قابل ویرایش و آماده پرینت)
تعداد صفحه:31
فهرست مطالب
مقدمه 1
معماری query optimizing 5
معماری کلی 5
عملکرد ماژول 6
تمرکز روی توضیحات 8 فضای جبری 8
Planner 13
الگوریتم های برنامه نویسی داینامیک 13
الگوریتم های تصادفی 18
سایر استراتژیهای جستجو 19
تخمین زننده اندازه توزیع 21
هیستوگرام 22
سایر تکنیک ها 24
محیط های غیر متمرکز 24
پایگاه داده های موازی 24
پایگاه داده ای توزیع شده 25
خلاصه 26
منابع و مأخذ 27
ما از query optimizing برای حل مسائل زیادی استفاده می کنیم. زمانی که یک query مطرح می شود، سیستم مدیریت بانک اطلاعاتی (DBMS ) می تواند از روش های مختلفی برای پردازش آن query و رسیدن به جواب استفاده کند. همه آن روش ها در نهایت یک نتیجه را تولید می کنند ولی از نظر هزینه های انجام شده مانند کل زمان مورد نیاز برای اجرا متفاوت اند. چه روشی حداقل زمان را برای اجرا نیاز دارد؟
در یک DBMS ، بهینه سازی query بسیار ضروری می باشد. هزینه انجام دو selection مختلف می تواند بسیار متفاوت باشد. برای مثال به شمای بانک اطلاعاتی زیر که ممکن است در طی این بخش از آن استفاده شود توجه نمایید :
emp (name,age,sal,dno)
dept (dno,dname,floor,budget,mgr,ano )
acnt ( ano,type,balance,bno )
bank ( bno,bname,address )
به Query ساده زیر توجه کنید :
Select name, floor
From emp, dept
Where emp.dno=dept.dno and sal>100k
ویژگیهای زیر را برای محتوا، ساختار و محیط هنگام اجرا در نظر بگیرید :
شرح پارامتر
مقدار پارامتر
تعداد صفحات emp
20000
تعداد tuple های emp
تعداد tuple های emp که sal>100K
10
تعداد صفحات dept
10
تعداد tuple های dept
100
نشانه های emp
کلاستر B + درخت روی emp.sal
( عمق سه سطحی )
نشانه های dept
کلاستر hashing روی dept.dno
) میانگین طول باکت 1.2 صفحه )
تعداد صفحات بافر
3
هزینه دسترسی به یک صفحه دیسک
ms 20
به سه روش متفاوت زیر توجه کنید :
P1 :
از طریق B + - tree تمام tuple های emp را که شرط emp.sal را ارضا می کنند پیدا می کنیم. برای هر کدام، از hashing index برای یافتن tuple های مناسب dept استفاده می کنیم. ( حلقه های تو در تو، استفاده از index روی هر دو رابطه)
P2 :
برای هر صفحه از dept، کل رابطه emp اسکن می شود. اگر مقدار dno یک tuple از emp با مقدار tuple روی یک صفحه dept برابر باشد و شرط انتخاب روی emp.sal را ارضا نماید، زوج tuple emp – dept در نتیجه ظاهر می شود. ( حلقه های تودرتو در سطح صفحه، بدون استفاده از index )
P3 :
به ازای هر dept tuple ، کل رابطه emp اسکن شده و تمام زوج های emp – dept tuple ذخیره می شوند. سپس، این مجموعه از زوج ها اسکن می شوند و ، به ازای هر کدام، بررسی می شود آیا هر دو dno یک مقدار دارند و آیا شرط روی emp.sal را ارضا می کنند یا خیر. (ساخت عرضی tuple ها، با اسکن ثانویه برای تست پیوند و اتصال)
محاسبه هزینه مورد انتظار I/O این سه طرح نشان می دهد که چه تفاوت بزرگی از نظر کارایی میان این سه روش وجود دارد در صورتی که هر سه یک نتیجه را تولید می کنند. P1 32/0 ثانبه، p2 کمی بیشتر از یک ساعت و p3 بیشتر از یک روز کامل نیاز دارد. Query optimizer تمام انتخاب های ممکن را بررسی می کند، به همین دلیل انتخاب p1 برای پردازش query نباید خیلی سخت باشد.
مسیری که یک query از DBMS تا رسیدن به جواب طی می کند در شکل 1 نشان داده شده است. ماژولهای سیستمی که از طریق آن حرکت می کند عملکردهای زیر را دارد :
پرس و جو ها از طریق کاربران فعال و یا برنامه هایی که به زبان های همه منظوره ای که پرس و جوها را به صورت مخفی درون خود دارند ( مانند c یا c++ ، فرترن یا PL-1 ) ، نوشته شده اند و برای DBMS ارسال می شوند. یک پرس و جوی فعال در مسیری که در شکل 1 نشان داده شده است حرکت می کند. به عبارت دیگر، یک پرس و جوی مخفی در زمانیکه برنامه ای که در آن مخفی است کامپایل می شود ( زمان کامپایل ) بین سه مرحله اول تنها یکبار عبور می کند.
بنابراین، مستقل از تعداد دفعاتی که یک query مخفی نیاز دارد که اجرا شود، بهینه سازی تکرار نمی شود مگر اینکه بهنگام سازی بانک اطلاعاتی طرح دسترسی را غیر معتبر کند ( مانند حذف ایندکس )، یا بهینه سازی فرعی به صورت بهینه سازی بالا ( تغییرات گسترده در محتوای بانک اطلاعاتی ). هیچ تفاوت واقعی بین بیهنه سازی فعال یا پرس و جوهای مخفی نیست، بنابراین در این فصل تمایزی بین آنها قائل نمی شویم.
کدهای اجرایی برای ترسیم هیستوگرام تصویر و خواندن تصویر BMP و نمونه ای از صف و پشته به همراه مثالهای ساده دیگر