سلام،
خب، پیش‌تر در تاپیک S3IS کمی در این باره صحبت شده‌بود:
کد:
http://www.akkasee.com/forum/showpost.php?p=70332&postcount=121
ولی برای این‌که اون توضیحات کامل‌تر بشن عرض می‌کنم، برای انتقال اطلاعات تصویر راه‌های مختلفی وجود داره. ساده‌ترین راه انتقال جداگانه‌ی اطلاعات هر رنگ هستش که البته با این‌که ساده هستش ولی پهنای باند زیادی می‌گیره. اطلاعات آنالوگ رو می‌شه به صورت سه رنگ جدا به همراه اطلاعات سینک ارسال کرد (یعنی روی ۴ کانال، مثل مانیتور آنالوگ کامپیوتر)، می‌شه همه‌ی اطلاعات رنگی رو یک جا مدوله کرد و روی یک کانال فرستاد و اطلاعات کنتراست (یعنی تصویر سیاه‌وسفید یا همون Luma) رو روی یک کانال دیگه (مثل ارتباط S-Video)، می‌شه اطلاعات سیاه‌وسفید و رنگ‌ها رو همه یک‌جا مدوله کرد و همه رو روی یک کانال فرستاد (مثل همین Composite Videoهای رایج (پورت‌های زرد رنگ RCA)) و ... . مساله این‌جاست که بستر انتقالی (که در اکثر موارد سیم مسی هست) یک محدودیت‌هایی داره از نظر مقدار سیگنال (در واقع پهنای باند) قابل انتقال در یک فاصله‌ی معین (با یک مقدارِ حداکثری به عنوان نویز قابل قبول). خب. حالا مساله این‌جاست که حداکثر استفاده رو از پهنای باندی که موجود داریم بکنیم تا بتونیم بیشترین حجم اطلاعات مورد نیاز رو روی بستر موجود انتقال بدیم. یکی از این متدها YCbCr هست. من اول از YPbPr شروع می‌کنم:
در YPbPr سه تا سیگنال رو جدا گانه از منبع به مقصد انتقال می‌دیم و برای این منظور هم معمولاًً از سه تا سیم جدا استفاده می‌شه (خروجی Component در بیشتر DVD Playerها و ورودی مشابه روی تلویزیون‌ها) این سیگنال‌ها چی هستند؟ Y که همان Luma باشد یا خیلی خودمانی‌تر اطلاعات کنتراست یا در واقع یک تصویر سیاه و سفید. یعنی اگر DVD Player رو که با سیم Component به تلویزیون وصل کردید، سیم‌های Pbو Pr رو ازش جدا کنید، یک تصویر سیاه و سفید (در واقع خاکستری) از DVD Player خروجی خواهید گرفت. چرا این Luma رو جدا انتقال می‌دیم؟ چون علم ثابت کرده که چشم به کنتراست بین نقاط خیلی حساس‌تر است تا به تفاوت رنگ‌ها.
اصولاً سلول‌های شبکیه دو دسته‌ی اصلی‌اند، سلول‌های میله‌ای (Rod) و سلول‌های مخروطی (Cone). تعداد سلول‌های میله‌ای حدود ۲۰ برابر سلول‌های مخروطی است و جالب است بدانید سلول‌های میله‌ای اصلاً نمی‌توانند رنگ را تشخیص دهند. تصویر Luma هم در واقع به عنوان خوراکی اولیه برای این سلول‌ها تهیه می‌شود، یعنی با توجه به دقت ۲۰ برابری چشم در تشخیص جزییات ِکنتراست ما هم در فشرده‌سازی تصویر (که همانطور که عرض کردم برای استفاده‌ی بهینه از پهنای‌باند مجبور به انجام آن هستیم) بیشتر به Lumaدقت می‌کنیم تا رنگ‌ها.
(خارج از این، البته، در نقطه‌ی Fovea در شبکیه تعداد Coneها خیلی زیاد است، یعنی توزیعِ این سلول‌ها یکسان نیست، و ما در نقطه‌ی Foveaی چشممان -که همان‌جایی است که هدف فرم حلزونی ترکیب‌بندی است- خیلی دقیق‌تر می‌بینیم، هم از نظر رنگ، هم کنتراست)
خب. پس یک کانال شد Luma. اما اصل اطلاعات رنگ که در واقع حجم عظیم اطلاعات تصویر بودند هنوز مانده‌اند! در YPbPr این رنگ‌ها را در دو کانال Pb و Pr جابه‌جا می‌کنیم. این کانال‌ها چه هستند؟ خیلی ساده، اطلاعات رنگ هست در فرم زیر:
Pb تفاوت بین مقدار نقاط آبی و نقاط مشابه در Luma است،
Pr تفاوت بین مقدار نقاط قرمز و نقاط مشابه در Luma است.
سبز را هم لازم نیست جابه‌جا کنیم، چون با توجه به این مابه‌تفاوت‌ها در گیرنده به راحتی قابل محاسبه خواهد بود (و جالب است که همیشه این سبز است که وضعش فرق دارد! در چشم Coneهایی که سبز و امثالهم را تشخیص می‌دهند حدود دو برابر دیگر Coneها هستند، در سنسورها هم با توجه به Bayer Pattern معمولاً فیلتر سبز دو برابر بقیه است!)
محاسبه‌ی این‌ها هم خیلی ساده‌است. همان فرمول‌هایی که دوستمان Capture گرفتند و همین‌جا گذاشته‌اند نشان می‌دهد که چطور می‌شود از روی اطلاعات سه رنگ RGB (و در واقع R'G'B' که به نسبت گاما بیان می‌شوند) مقادیر Y و Pb و Pr را محاسبه کرد. محاسباتی ساده هستند که تنها نکته‌ای که دارند این است که به دو ثابت Kr و Kb بستگی دارند.
Kr و Kb برای این وجود دارند چون YPbPr اصولاً خودش یک Color Space نیست و مقدارها را نسبی بیان می‌کند، یعنی به نسبت یک فضای رنگی. این جاست که متوجه می‌شویم تصویر Encode شده با YPbPr صاحب یک فضای رنگی محض نیست و وابسته است، برای همین هم هر دستگاهی که می‌خواهد یک تصویری را با YPbPr بسته‌بندی کند از کاربر می‌پرسد با چه فضای رنگی این کار را بکنم (همین که در دوربین می‌گویید sRGB یا Adobe RGB). این هم از این.
حالا YCbCr چیست؟ خیلی ساده YCbCr دیجیتال همان YPbPr است :) این‌که شما در Jpeg می‌بینید تصویر اطلاعاتی در مورد YCbCr دارد بابت این است که Jpeg در داخل خودش و در فرآیند فشرده‌سازی (که در تاپیک S3IS توضیح داده‌ام) در JFIF و به صورت ذاتی اولین کاری که می‌کند این است که تصویر را از RGB خارج کرده و آن را با استفاده از همین تکنیکی که عرض کردم، به اطلاعات Yو Cb و Cr تبدیل می‌کند (که البته می‌تواند نکند). یعنی حجم تصویر همین اول تقریباً نصف شده و در ضمن از فضای رنگی نیز کنده می‌شود و با آن یک نسبت پیدا می‌کند (می‌شود فضا را sRGB گرفت و عکس را تعبیر کرد یا می‌شود رنگ‌ها را بر اساس یک ICC Profile دوباره سازی کرد) بعد از این Luma را جدا و رنگ‌ها را جدا کوانتیزه و فشرده می‌کند. (همینطوری: این مرحله‌ی اول طبق استاندارد اختیاری است!)
البته دانستن همه‌ی این‌ها مهم هم هست، چون این‌طوری کاربر می‌داند که چرا Color Space در خود عکس Jpeg نیست، چرا باید کالیبره بود و چرا Jpeg مشکلاتی مانند Color Bleeding دارد.
یک نکته‌ی دیگر این اعدادی است که در YCbCr دیده می‌شوند. مثلاً 4:1:1 یا 4:2:2 یا 4:4:4. در واقع 4:4:4 مدل رفرنس است. یعنی همان‌قدر که لوما داریم (رقم اول متعلق به نسبت Lumaاست) همان‌قدر هم Cr (عدد دود نسبت Crاست) و همان‌قدر هم Cb داریم. همه‌ی این‌ها نسبت افقی هستند و به طور رایج 4:2:2 یا 4:1:1 به کار می‌رود. جالب است بدانید Jpeg از یک مدل خاص 4:2:0 استفاده می‌کند! البته ۰ معنی خاصی دارد، یعنی Cb به اندازه‌ی همان Cr است و این‌که صفر می‌گذاریم بابت این است که این اعداد در فرمول‌های محاسبه‌ی پهنای باند درست دربیایند. یعنی برای محاسبه‌ی نسبت پهنای باند باید همه‌ی این اعداد را جمع بزنیم و تقسیم به ۱۲ کنیم. مثال می‌زنم، یک تصویر بدون اعمال YCbCr اگر ۱۰ کیلوبیت فضا اشغال کند با اعمال 4:2:2 فقط ۵ کیلوبیت و با اعمال 4:2:0 فقط ۲ کیلوبیت جا می‌گیرد. پس Jpeg همان اول تصویر ۱۰ کیلوبیتی را ۲ کیلوبیت می‌کند، بعد حسابی روی آن کار می‌کند و تازه به شیوه‌ی مخرب خودش! عکس را کوچک می‌کند.
ببخشید که طولانی شد، چون سعی کردم ساده باشد بعضی‌جاها کمی غیرعلمی (اما نزدیک به صحیح!) است که از دوستان پوزش می‌طلبم :) این هم یک‌سری لینک:
کد:
http://en.wikipedia.org/wiki/Chroma_subsampling http://www.wfu.edu/~matthews/misc/jpg_vs_gif/JpgCompTest/JpgChromaSub.html http://www.impulseadventure.com/photo/chroma-subsampling.html http://www.projectorcentral.com/component.htm http://en.wikipedia.org/wiki/YPbPr
ممنونم.