הגיגים על color decoder, ממשק RGB, ממשק קומפוננט ועוד

איך מכיילים מסך, מי יכול לכייל לי? מה הערכים הנכונים לכיול...

DEINTERLACING, SCALING, הורדת רעשים, UPCONVERSION, TRANSCODING.
motico
כתב
כתב
תגובות: 1509
הצטרף: מרץ 2005
מיקום: גבעתיים
נתן תודות: 100 פעמים
קיבל תודות: 114 פעמים

שרשור שלא נקרא #16 

unsound_methods

אני עדיין רואה 2 התמרות. התמרה מספר 2 לדעתך לא רלונתית לדיון. בא נשאיר את זה כרגע כך, נחזור לזה יותר מאוחר.
ההתמרות (או המטריצות) שאני רואה:
1. מטריצה #א , כניסה RGB, יציאה RGB, וזה ממשיך לכיוון המסך (הפנל).
מטריצה זו ממירה את המספרים הדיגיטאליים שמגיעים ממקור כל שהוא לאחר תיקון גאמה, למספרים קבועים של RGB. מספרים שהמסך אמור להכיר.
2. מטריצה מה RGB לכיוון ה DRIVER של המסך.
מטריצה זו מקבלת מספרי RGB מנורמלים ומתרגמת אותם לצבע הנכון שיוקרן על המסך. המטריצה הזו כביכול קבועה כי תמיד היא מקבלת בכניסה מספרים קבועים ומוציאה בהתאם את הצבע הרצוי על גבי המסך.
כאמור, זו המטריצה שאנחנו מתעלמים ממנה.

נחזור למטריצה 1, ונתייחס למשפט שכתבת:
נניח S זו המטריצה הממירה מ RGB תקני ל XYZ (המטריצה המגדירה את מע' הצבע התקנית). נניח T זו המטריצה הממירה מ RGB של המסך ל XYZ (מגדירה אמ מע' הצבע של המסך)
...
הייתי משנה במקצת את המשפט ואומר "שהמטריצה ממירה מ RGB בתקן מסויים ל XYZ......" .
לכל תקן יש את טבלת ה RGB שבה כל צרוף של RGB מגדיר צבע מסויים ולכן מבחינה תיאורטית, כל תקן מחייב טבלת המרה שונה, המתאימה את ערכי ה RGB של התקן לערכי ה RGB שיכנסו ל DRIVER של המסך.
השאלה האם לכל תקן יש RGB שונה? אני לא נכנסתי לנבכי התקנים אבל אם ה GAMUT של התקנים שונה, זה כמעט מחייב שגם מספרי ה RGB יהיו שונים.
אז #א היא בדיוק invT * S.
...

נכון אבל עבור תקן מסויים. בתקן אחר ה- S כבר שונה.


אני רואה כמה אפשרויות:
1. מספרי ה RGB שמגיעים למטריצה (או מבחינתי לטבלת ההמרה) שוים בכל התקנים. במקרה הזה אין צורך בהתמרות שונות והצבעים במעבר מתקן אחד לשני לא ישתנו. מצב אידיאלי.
2. מספרי ה RGB שמגיעים למטריצה (או מבחינתי לטבלת ההמרה) לא שוים בכל התקנים, אבל די דומים, והיצרנים לא מתייחסים לשינויים האלו, ובמעבר מתקן לתקן זה יגרום לשינויים בצבע. אני מניח שאתה, eugbuber ועפר סבורים שזה המצב, אבל לא ברור למה שיצרניי המסך ישאירו את זה כך, השיפור לא עולה להם כלום.
חוץ מזה אם זה נכון (לפי הדוגמה שנתת) הפריימריס של REC709 ו PAL כמעט זהים, אז מאיפה המסקנה שצריך איפוס שונה לכל אחד מהם?
3. מספרי ה RGB שמגיעים למטריצה (או מבחינתי לטבלת ההמרה) לא שוים בכל התקנים, ואז מופעלת מטריצה #א לתיקון והשואה בין התקנים. במקרה הזה הצבעים במעבר מתקן אחד לשני לא ישתנו.

המסקנה שלי (לא הידע), שמצב 3 הוא הנכון מהסיבות האלו:
1. ערכי ה RGB בתקנים השונים לא זהים כי ה GAMUT (של התקן) לא זהה.
2. התוצאה הסופית בקליטה של אות דיגיטאלי היא תמונה זהה במעבר מתקן לתקן (לפי עופר).

אוליי לא הבנתי בדיוק מה כונתך ב #ב או #א, אבל זה לא חשוב, מישהו צריך לנרמל את המספרים לפני שהם נכנסים ל DRIVER של המסך.


כמה מספרים:
ניקח לדוגמה צבע סגלגל שנמצא במרחב הצבעים sRGB שמפיקה כמעט כל מצלמה דיגיטאלית, ונשוה לתחומי צבע אחרים:
sRGB = 200,50,100
NTSC = 169,55,101
PAL = 195,53,100
HDTV = 195,27,64

נראה לך שלא צריך המרה בין התקנים? אפשר לוותר על מטריצה #א?


ואם נחזור להתמרה מספר 2 שכתבתי בתחילת התשובה הנ"ל, פה המצב יותר מסובך, או פשוט לחלוטין :wink: תלוי ביצרן. יש פה בעיה של תחום מספרים כתלות ב GAMUT של המסך. ככל שה GAMUT של התקן קטן יותר נוצרים "עודפי מספרים" שלא מנוצלים ושגורמים ל BANDING ועוד בעיות. בתהליך נכון (שוב, אני לא יודע אם זה נעשה בפלזמה) יש צורך לשנות גם את הטבלה של ה DRIVER בהתאם לתחום הצבעים בכניסה למסך כדי לנצל את כל תחום המספרים.

אני חושב שאין צורך להכנס כרגע לנושא הזה בשרשור הנ"ל, נמקד רק במטריצה #א שעומדת למבחן.

(צודק, גם זה די מתיש)
מוטי

unsound_methods פותח השרשור
סמל אישי של משתמש
חבר פעיל במיוחד
חבר פעיל במיוחד
תגובות: 563
הצטרף: אפריל 2006
מיקום: מרכז
נתן תודות: 0
קיבל תודות: 0

שרשור שלא נקרא #17 

מוטיקו,

נראה לי שאנחנו מסכימים על רוב הדברים, אבל בו זמנית מדברים על דברים שונים.
אני לא מדבר על מעברים מסטנדרט צבע אחד לסטנדרט צבע אחר. זו לא מטריצה #א.
השאלה האם לכל תקן יש RGB שונה? אני לא נכנסתי לנבכי התקנים אבל אם ה GAMUT של התקנים שונה, זה כמעט מחייב שגם מספרי ה RGB יהיו שונים.
...
ברור -
ערכי RGB אינם מגדירים צבע אבסולוטי (בניגוד לקואודינטות x y על הגאמוט). ערכי RGB הם תמיד תלויי תקן - ותקן (מערכת צבע) מגדיר איפה ממוקמים הפריימריס שלו על הגאמוט, ואיפה ממוקם הלבן שלו על הגאמוט.
צבע (המיוצג ע"י שלשת RGB בתקן מסוים) מתמקם על הגאמוט לפי המשקלות של ה R ה G וה B בשלשה, לפי הפריימריס של התקן.

לדוגמא: 1,0,0 מתמקם בדיוק איפה שהפריימרי האדום של התקן. 0,1,0 מתקמם בדיוק על הפריימרי הירוק. 1,1,1 מתמקם בדיוק על הלבן שמוגדר באותו תקן. 1,0,1 (מג'נטה) מתמקם באמצע הישר שבין הפריימרי הכחול לפריימרי האדום של התקן.

קרי: שלשת RGB בתקן מסוים מגדירה צבע מסוים. אבל - אותה שלשה, בתקן אחר, מגדירה צבע אחר (כי הפריימריס שונים).
או בכיוון ההפוך (כמו שאתה מתאר זאת): צבע מסוים, יכול להיות מיוצג ע"י שלשות RGB שונות, כתלות בתקן ה RGB (מערכת הצבע) שמשתמשים בו.

ועכשיו לטענה שלי:
יש חוסר התאמה בין משולש הגאמוט של תקן (סטנדרט מסוים, לא חשוב איזה) למשולש הגאמוט של המסך. המסך עובד במערכת RGB אחרת, כפועל יוצא של הפוספורים שלו, המגדירים פריימריס אחרים משל התקן.
שלשת RGB (באותו סטנדרט מסוים) מגדירה צבע אבסולוטי; אבל אותה השלשה, תחת מע' הצבע של המסך, מגדירה צבע אחר.
אם תזין ערכי RGB שיצאו מהסיגנל (המתאימים למערכת צבע תקנית מסוימת) ישירות אל הדרייבר של המסך, שחזור הצבע יהיה לקוי. זאת בגלל שהפריימריס של המסך (מערכת הצבע שלו) שונים מאלה של התקן.
צריך מטריצה (מטריצות) שממירה ממערכת הצבע הסטנדרטית (יותר נכון: מכל מערכת צבע סטנדרטית שהיא) למערכת הצבע האינהרנטית של המסך, המוגדררת על ידי הפריימריס שלו (המוגדרים על ידי התכונות הספקטרליות של כל פוספור). זו מטריצה #א.
כפי שעופר ציין, וכפי ש eugbuber ואנוכי שיערנו, אין מטריצה כזו.

motico
כתב
כתב
תגובות: 1509
הצטרף: מרץ 2005
מיקום: גבעתיים
נתן תודות: 100 פעמים
קיבל תודות: 114 פעמים

שרשור שלא נקרא #18 

unsound_methods

יופי, אז אם אני מבין אותך נכון, אנחנו כן מדברים על אותו הדבר.
שנינו מבינים שצריך (עדיין רק בגדר צריך) מטריצה שממירה ממערכת צבע לפי התקן הנקלט, לפריימריס של המסך.
אני מניח שאנחנו מסכימים שחוסר במטריצה כזאת יגרום לצבע המוקרן להשתנות בין תקן אחד לשני.
אני רק בחזקת חושב שכן יש תאום בין התקנים בתוך הפלזמה (חזרנו למטריצה #א) ואתם חושבים שלא.

ופה נכנס הכיול לתמונה. קיימת טענה שבעזרת כיול אפשר לאפס את השינויים. האמנם ?

כיוון שהשרשור מעניין (לפחות אותי), אני אהפוך אותו לעוד יותר מעניין בעזרת תוספת של כמה מספרים.

לנוחיות אני מעתיק את מה שכבר כתבתי:
ניקח לדוגמה צבע סגלגל שנמצא במרחב הצבעים sRGB שמפיקה כמעט כל מצלמה דיגיטאלית, ונשוה לתחומי צבע אחרים:
sRGB = 200,50,100
NTSC = 169,55,101
PAL = 195,53,100
HDTV = 195,27,64

ועכשיו נוסיף את המספרים של אותם מרחבי צבעים אבל הפעם נתמקד באפור. מה דורש כל תקן כדי לייצג אפור, משהו כמו 100,100,100:
sRGB = 100,100,100
NTSC = 100,100,100
PAL = 100,100,100
HDTV = 65,65,65

ועוד אפור במספרים 200,200,200:
sRGB = 200,200,200
NTSC = 199,199,199
PAL = 199,199,199
HDTV = 177,177,177


שים לב, המספרים הנדרשים לרמת האפור שווים !!!
מה שמצביע על מסקנה בעייתית בכיול.
זה אומר שכיול מעולה ל D65 בכל תחום ה GREY SCALE לא מבטיח כלום לגביי דיוק הצבע באופן כללי, ובוודאי שלא במעבר מתקן אחד לתקן אחר.
כיול ברמה של אפורים לא יעזור לתאם בין התקנים.
מוטי

unsound_methods פותח השרשור
סמל אישי של משתמש
חבר פעיל במיוחד
חבר פעיל במיוחד
תגובות: 563
הצטרף: אפריל 2006
מיקום: מרכז
נתן תודות: 0
קיבל תודות: 0

שרשור שלא נקרא #19 

לא לגמרי ירדתי לסוף דעתך עם הדוגמה המספרית... ועם ההצהרה "מסקנה בעייתית בכיול"...
אבל לא חשוב.

חשובה המסקנה שלך:
זה אומר שכיול מעולה ל D65 בכל תחום ה GREY SCALE לא מבטיח כלום לגביי דיוק הצבע באופן כללי
...
מסכים בהחלט.
כיול D65 רק גורם לכך שהלבן יתמקם נכון (לפי התקן. כל התקנים השימושיים מגדירים D65 בתור הלבן שלהם).
זה גורם גם לצבעים ש"מסביבו" (כלומר הצבעים הלא רווים) להתמקם "יחסית" טוב בגאמוט, אבל כפי שאמרת - אין הבטחה לדיוק הצבע. ככל שנתרחק מ"מרכז" הגאמוט (נקודת ה D65), כך יהיו יותר עיוותים שנגרמים מכך שהפריימריז של המסך אינם כמו אלה של התקן (המסוים שכרגע בשימוש).

ולכן, צריך "לעזור" למקודד הצבע על ידי שינוי הסטורציה כללית, וסטורציה לכל רכיב.
כאמור, זה בפרוש tradeoff - אין זה מבטיח רפרודוקציה מדוייקת כלל וכלל. זהו רק "תיקון" טלאי.. עוזר קצת פה, מקלקל קצת שם...

motico
כתב
כתב
תגובות: 1509
הצטרף: מרץ 2005
מיקום: גבעתיים
נתן תודות: 100 פעמים
קיבל תודות: 114 פעמים

שרשור שלא נקרא #20 

unsound_methods

אני אנסה להסביר את נושא המספרים.

נניח שאנחנו רוצים לכייל את הפלאזמה פעם ל NTSC ופעם ל PAL.
הבקרים בפלזמה מאפשרים לכוון בכל צבע את נקודת העבודה ואת ההגברה שזה למעשה שיפוע הגרף. נכניס דיסק כיול שנותן רמות של GREY ונדאג לכוון את שלושת הצבעים היסודיים RGB להתלכדות, כך שעל ציר הבהירות נקבל הכי קרוב לאפור (D65).

בשלב ראשון נבצע את פעולת הכיול כשמקור ה GREY זה אות בתקן NTSC. כדי לקבל אפור, ל DRIVER של המסך נכנסים רמות שוות של RGB, מספרים כמו 10,10,10 או 20,20,20 וגם 30,30,30 וכו'....קפיצות קטנות (או גדולות) כדי לקבל תחום משחור עד לבן בכל הרמות.

אני מניח שזה מה שעשית עם הספיידר וסביר שעד כאן לא חידשתי דבר.

נזיז את כל הבקרים המתאימים בפלזמה, ולבסוף אחרי הכיול נקבל יופי של אפור. גם נקודה 100,100,100 מכויילת וגם 200,200,200 כבר מכויילת מעולה וכנ"ל כל נקודות האפור לכל אורך תחום הבהירות.
עכשיו ננסה לכייל את המסך לתקן PAL. נדאג להכניס לפלזמה מקור דיגיטאלי של PAL, נתבונן ב GREY, וראה זה פלא לא צריך לגעת בכלום.
כל הסקאלה מכויילת היטב, כאילו עדיין מקור האות הוא NTSC ולא PAL. למה? כי מספרי התקן האפור ב NTSC וב PAL שווים.
אם ב NTSC ה DRIVER של המסך קיבל 100,100,100 גם ב PAL הוא יקבל 100,100,100 ולכן התוצאה שוות.

הנה הרגנו 2 ציפורים במכה אחת. כיילנו תקן אחד והשני כוייל "בחינם".

אבל כמו שאתה מבין, זאת אשליה גדולה.
ברגע שנקבל מספרים "צבעוניים" המסך יגיב אחרת.
אם ב NTSC נקבל צרוף של צבע 169,55,101 , כשיגיע מספר זהה ב PAL, המסך יקרין צבע לגמריי שונה. צבע זהה במערכת PAL מוגדר כ 195,53,100.

ובהקשר למה שכתבת, "הצבעים" סביב האפור יוקרנו במדוייק, אבל לכל שאר הגוונים האחרים תגרם סטיה.

לזה התכוונתי שהכיול בעייתי, אתה מרגיש עם אבל הולך בלי :wink: .
מוטי

שלח תגובה

חזור אל “כיול ועיבוד תמונה”