כיצד כיילתי גמה בפלזמה, עבור כניסת ה VGA PC

[unsound_methods]

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

בהעדר ציוד מדידה מקצועי, השתמשתי במבחן ה checkerboard pattern ובעיניים הביוניות הסופר-וידאופיליות שלי ... לצורך הבדיקה, חובה שהמחשב יעבוד ב native resolution של המסך, פיקסל לפיקסל.

למעשה, הזנתי מהמחשב test pattern שבו רצועות של checkerboard pattern (עם שחורים של 0 ולבנים של 255), ורצועות אחידות בבהירות ביניים (אפור 127).
המטרה: הגוון של רצועות האפור 50% צריך להראות זהה לגוון "הכולל" בצפיה על רצועות ה checkerboard מרחוק. קביעת גמה נכונה אמורה לכוון את האפור 50% בהתאם.

להפתעתי, גיליתי שהגוון של אפור הביניים היה כהה בהרבה מאשר "הבהירות הממוצעת" הנצפית מרצועות ה checkerboard, כאשר הגמה היא 2.5 ו 2.2.
רק כאשר הגמה היא 2.0, הרצועות רק התחילו להיות קרובות בגווניהן (עדיין כהות מסוימת לרצועות אפור הביניים).
כרטיס המסך הוא fx5200 של gainward.

מסקנתי היא, שהכרטיס מסך שלי עובד בגמה של פחות מ 2.0 - אני מהמר משהו כמו 1.8.
לאחר שקבעתי הגמה ל 2.0 - ביצעתי כיול מחדש ל black level ול peak white (ברייטנס וקונטרסט). חייבים לכייל אותם מחדש, בעיקר כי ה black level זז (לדוגמא אצלי, כאשר הגמה היתה 2.5 כיול b.l. נכון היה באמצעות brightness של 3, וכשעברתי לגמה 2.0 כיול b.l. נכון היה באמצעות brightness של מינוס 1).

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

ועוד משהו קטן - באופן מוזר מאד, הפלזמה מרצדת (כן, כן מרצדת, כמו flicker של CRT) באזור של רצועות ה checkerboard... עוד תופעה משונה בלתי מוסברת...

לבסוף: אם יש עניין - אצרף את קובץ ה test pattern שהכנתי.

[MartinHSabag]

אני לא מבין משהו.
אם עקומת הגאמה היא לא לינארית, איך השוואה של שתי נקודות בלבד נותנת לך את הגאמה הנכונה?

או שלא הבנתי מה עשית כמו שצריך.

[unsound_methods]

המטרה שלי היתה לבחור transfer function (גאמה) כזאת, שעבורה, כניסה של בהירות 50% אפור, תהיה "שקולה" בבהירותה לדמוי 50% אפור שנוצר ע"י pixels checkerboard (של לבנים ושחורים) - כלומר "שקולה" ל 1/2 מבהירות ה peak white.
הרעיון הגיע תודות למאמרו של עופר
http://www.hometheater.co.il/modules.ph ... cle&sid=30

ה grayscale transfer function אמורה להיות לינארית בהסתכלות של log scale על בהירות המסך המופקת.
ראה
http://www.displaymate.com/ShootOut_Part_2.htm
במיוחד figure 2 וההברים הנלווים לו.

כלומר, אני בעצם בוחר את המקדם (השיפוע) הנכון בהתאם ל source input שלי.

הכל טוב בתאוריה. בפרקטיקה ברור לי שמקדם הגאמה אינו קבוע, אלא עלול להשתנות מעט כפונ' של הבהירות בתמונה (כלומר הגרף אינו לינארי לחלוטין בהסתכלות log scale), בגלל מגבלות הטכנולוגיה. אבל אני מניח (גם לפי המאמר שקראתי) שרב העיוותים בלינאריות הגאמה (בהסתכלות לוגריתמית) מתרחשים בקצה התחתון של הגרף, כלומר עבור בהירות נמוכה במיוחד.

לכן, בתור כלל אצבע, הסתמכות על מדידה בעין של 50% לבן, נראה לי פשרה סבירה בהחלט, לאור העובדה שאין לי ציוד מדידה...

[MartinHSabag]

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

[oferlaor]

אוקיי, זה די פשוט.

אם ניקח קוים אופקיים (זה חייב להיות NATIVE RATE, אחרת ה-SCALER הפנימי של המסך יקלקל את כל התאוריה) במרווחים של אחד כן אחד לא, אז בעצם יש לנו 50% תאורה, נכון?

עכשיו, זו נקודה עם DIP רציני בגראף ולכן ההפרש די גבוה בין ה-50IRE לבין 50%.

הגראפים האלה (יש כזה גם ב-AVIA) מגלמים את זה על ידי הצבת מספר גוונים, כאשר הגוונים מגלמים את ההפרש בין הערך ב-IRE לבין הגוון שנוצר ב-50% קוים לבנים ושחורים. כאמור, זה יכול לעבוד רק ב-NATIVE RATE (למשל פלאזמות EDTV עם מקור NTSC) - אבל חייבים לוודא שרואים בפירוש קו כן קו לא... אני לא זוכר אם הקוים ב-AVIA הם הרקע או שהם הקוים של ה-GAMMA. בכל מקרה, יש בזה המון בעיות כי זה בעצם דוגם נקודה אחת בגרף (שלא בהכרח מייצגת את כל העקומה, במיוחד לאור התנהגות S CURVE במסכי LCD וגם במסכי פלאזמה).

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

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

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

[unsound_methods]

עופר,

1.
בעניין ה native resolution - מסכים לחלוטין - חובה שהמקור יהיה בדיוק ב native resolution של המסך, אחרת הבדיקה לא שווה כלום, כי לא תופק 50% בהירות בגלל שה scaler יפעל, יבצע antialiasing וכו'.
הבדיקה שלי נעשתה עבור כניסת ה VGA, שמחובר אליה כרטיס המסך של ה HTPC, שאכן מקונפג נכון - קל לבדוק זאת עם patterns של קוים אנכים / אפקיים ו- checkerboards.
אני לא ממש רואה אפשרות ריאלית לבצע זאת עם אותות PAL או NTSC, האם בכלל ניתן להכין patterns כאלו עבורם, והאם ניתן לכייל בשיטה זו כניסות חוץ מאשר כניסת ה VGA.

2.

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

...

גם אני הייתי מאד סקפטי לעניין (כהרגלי ), במיוחד אחרי שהבדיקה עבור מסך המחשב הייתה בלתי אפשרית, כי התבוננות במסך מחשב נעשית מקרוב, כלומר מבחינים ב checkerboard pattern ולא ב"ממוצע" התאורה.
אבל, ממרחק צפיה של 4 מ' לפלזמה, כשכל פיקסל בה הוא 1.08 מ"מ - הופתעתי, וגיליתי לשמחתי שהמצב שונה לטובה.
בכללי, מסכים שמדובר בכלי מדידה רחוק מאידאלי...

3.

בכל מקרה, יש בזה המון בעיות כי זה בעצם דוגם נקודה אחת בגרף

...

עדיין, לא מבין למה יש פה "המון" בעיות. זו הערכה די טובה לדעתי, אנמק.
נניח יש שלוש transfer functions המייצגות כל אחת ערך גמה אחר.
אני בוחר את זו שממקמת אותי בתפוקה של 50% בהירות עבור אות 50%.
לכן, אם זו היתה transer function אידאלית (כזו שהיא לינארית לחלוטין בהסתכלות לוגריתמית על הבהירות המופקת, כלומר פונ' מעריכית מדויקת ללא עיוותים) - זה מספיק - כי עבור פונקציה אידאלית שכזו, בחירת נקודה אחת שמתאימה (וכאן זה בכלל לא חשוב שזו דווקא נקודת 50%), התאימה לנו את כל הגרף.
במציאות ה transfer function של המסך לא אידאלית.
לפי מה שהבנתי, העיוותים הם בעיקר בקצוות (כלומר הפונ' איננה לינארית בהסתכלות לוגריתמית על הבהירות, ולקצוות יש מקדם שיפוע שונה מאשר מקדם השיפוע ברב הגרף). תחת ההנחה הזו, בחירת נקודת ה 50% בתור נקודת ההתייחסות למציאת הפונ' הנכונה באה לסייע לנו - כי אנו בוחרים בעצם את הפונ' הנכונה ל"רב" ערכי ה IRE.
עכשיו, בוא נניח שעשיתי גם דגימות עבור 10 IRE ו 90 IRE, וגיליתי שהפונ' שבחרתי מתנהגת לא כל כך טוב בקצוות - אם אבחר פונ' אחרת שמתאימה לקצוות, אז היא לא תתאים במרכז (עבור 50 IRE)...
אז אני מסכים שהרבה דגימות אכן יאפשרו את בחירת הפונ' הקרובה ביותר.
אבל, תחת ההנחה שפונקציות הטרנספר של המסכים מתנהגות "רע" רק ממש בקצוות, נק' התייחסות של 50 IRE אמורה לתת מענה די טוב.

4.

עכשיו, זו נקודה עם DIP רציני בגראף ולכן ההפרש די גבוה בין ה-50IRE לבין 50%.

...

אנא הסבר, לא הבנתי המשפט. מה זה DIP?

[unsound_methods]

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

בבדיקה שלי השתמשתי בתמונת bitmap לצורך הבדיקה.
בהצגת תמונות מחשב סטטיות, כרטיס המסך מממש את תיקון הגאמה ע"י lookup tables בחומרה. בתאור גס ולא מדויק, אפשר לומר שלכל ערך דיגיטאלי בין 0 ל 255 יש ערך IRE מתאים באותן טבלאות (וזה לכל רכיב צבע), וההמרה הזו היא אחת משלבי ה D to A, בדרך אל אמצעי התצוגה.

אינני יודע אם בעת הצגת וידאו (על ידי video overlay), כרטיס המסך משתמש באותן lookup tables כמו בעת הצגת תמונות סטטיות.

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

חשבתי להכין סרט וידאו ובו ה test pattern המדובר, אבל הבעיה היא שבדחיסת הוידיאו האינפורמציה בתדרים הגבוהים מתחילה להשתבש, ואז ה checkerboard נהרס... אולי אנסה לקבוע bitrate גבוה יותר וקודק מוצלח יותר לדחיסה....

מישהו יודע עם שימוש בממשק video overlay של הכרטיס הגרפי משתמש באותם lookuptables ?

[motico]

unsound_methods

אנחנו שותפים לאותו רעיון - גם אני בניתי מזמן מנגנון לבדיקת הגאמה, דומה למה שאתה עשית.
המטרה שלי היתה לבצע את זה דרך DVD.
לשם כך כתבתי PLUG IN עבור ה PHOTOSHOP שבונה לבד את השורות השחורות והלבנות "בעובי" מתאים. (אני לא תכנת והיה לי די קשה לכתוב את זה).
אין אפשרות ליצור ב PAL את מספר השורות המדוייק של הפלאזמה כי DVD זה בפועל 480 לעומת 576 בדיסק כך שתמיד יש תיקון של תוכנת המסך. לשם כך בניתי עוביים שונים של הקוים השחורים והלבנים, אבל אז יש צורך להסתכל במסך מהבית של מהשכנים וזה לא ממש מעשי.

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

רק הערה קטנה, אם אתה בונה קובץ ל DVD קח בחשבון שלפני הצריבה יש להמיר את רמות לרמה של INVERSE GAMMA.

[unsound_methods]

motico,
רשמיך מעניינים מאד.

מבחינתי כל המשחק "אקדמי"

...

כן אני מודע לכך שאני משחק פה יתר על המידה ... אבל זה כיף.

מדדתי את רמות האפורים והתוצאות לא מסתדרות לי חישובית.
למעשה זה גם לא ממש מסתדר בפלאזמה, כלומר, מה שמראה דיסק הכיול ומה שרואים על המסך לא תואם את מה שכתוב ב MENU של הפלאזמה

...

מצטער, לגמרי לא הבנתי - איזו תמונה יש בדיוק ב AVIA? איך מדדת אם אין לך מכשיר מידה?
לפי עופר - ה MENUS בפלזמה לא מדויקים, הגאמה האמיתית נמוכה ממה שהם מציינים.

[motico]

unsound_methods

לגבי מדידת ממסך הכיול של AVIA, העתקתי את קטע הסרט שקשור לכיול הגאמה מה DVD למחשב, והעלתי FRAME אחד לתוכנת עיבוד תמונה. בעזרת התוכנה "מדדתי"את המספרים של קוביות האפור שמיצגות את הגאמה.
אם זה מעניין אותך, ממה שראיתי, עובי הקוים השחורים הוא 2 שורות, וכנ"ל הלבנים.

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

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

[oferlaor]

רק ה-SPYDER2 אמור להיות תואם פלאזמה.

לגבי AVIA אני לא מאמין גדול בעמוד הזה, בכל מקרה, כשהיה לי ציוד מדידה כבר לא היה לי מסך עם רזולוציה 480P ולכן AVIA כבר לא עובד (כאמור, ללא NR, הוא לא אפקטיבי).

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

לגבי העקומות צבע וגאמה - כל כרטיס מסך מתנהג אחרת. ב-NVIDIA בד"כ יש שתי טבלאות LUT - LOOK UP TABLE, אחת "רגילה" ואחת ל- OVERLAY. הכיול לא בהכרח זהה.

[unsound_methods]

עדכון לכל מי שחושב לחזור על הניסוי: יש כאן שגיאה.

השימוש בתמונות דיגיטאליות (ולא בוידאו דיגיטאלי) לצורך הכיול, איננו נכון ויכול להוביל לכיול שגוי.

לפי Poynton, בגרפיקה ממוחשבת (ואני מניח שזה כולל תמונות דיגיטאליות), ערכי ה intensity אמורים להיות לינאריים; ביצוע תיקון הגאמה נעשה ע"י כרטיס המסך, רגע לפני ההמרה לאות אנאלוגי, תוך שימוש ב Lookup Tables.
הערך המומלץ ב LUT הוא 0.45 (מתאים לגאמה 2.222).
הבעיה הראשונה היא, שאין אנו יודעים באמת באיזה ערך משתמש הכרטיס הגרפי.

בוידאו דיגיטאלי תקני, ערכי ה intesity במקור הם כבר מתוקני גאמה (לפי Rec 709 או SMTPE 240M, המגדירים תיקון המתאים לגאמה 2.222).
כלומר, אם משתמשים בממשק הצגת הוידאו של כרטיס המסך (נניח video overlay), לא יבוצע תיקון "נוסף" ביציאה מהכרטיס הגרפי.
וזו הבעיה העיקרית בשיטה שתוארה לעיל: בהצגת וידאו, מדובר בממשק שונה, שלא משתמש באותו תיקון גאמה כמו בהצגת תמונות - לכן כיול לפי תמונות דיגיטאליות אינו טוב.

הפתרון: להכין קובץ וידאו דיגיטאלי עם ה pattern האמור, ולכייל לפיו.

[oferlaor]

unsound_methods,

ניתן לבצע זאת, כאמור עם דיסק DVE.

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

[unsound_methods]

עופר,

האם נשמעת פה נימת זלזול?
ממש לא מסכים להגדרה נסיונות סרק / שעות מבוזבזות.
אני תמיד נהנה מלימוד עצמי; במקרה דנן למדתי המון, שלא לציין שהנושא מעניין אותי אישית. האם זה כדאי? מבחינתי, התועלת וההנאה מעל ומעבר.

כאנלוגיה, תחשוב על אותם אלה שמרכיבים HTPC בעצמם, נאבקים עם חומרה/תוכנה/קודקים/EPG שלא עובדים, ומורידים שעות סרט/סדרה מהאינטרנט. בשביל מה? לא לשלם 13 ש"ח לספריית הוידאו הקרובה? זה ניצול אופטימלי של הזמן?

[MartinHSabag]

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

תהנה !

[oferlaor]

בהחלט לא מזלזל, ההיפך הוא הנכון - אתה משקיע ולומד וזה מבורך!

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

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

אישית, אני חושב שכדאי לך לחשוב שוב על רכישת DVE (כפול - NTSC+PAL) ולפחות את SPYDERTV PRO אשר יתן לך את הכלים להתחיל לעשות את הדברים "נכון". בכל מקרה, אנחנו נהנים לקרוא את מסע המחקר שלך, הוא מזכיר לי את מה שאני עברתי לפני כמה שנים בכמה מובנים... רק שבמקרה שלי הייתי צריך לעבור את זה בסולו כי כמעט אף אחד לא ידע על מה אני מדבר...

[unsound_methods]

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

באופן כללי בחיים, אני די מעדיף פתרונות מוכנים מראש, ולשלם עבורם.
במקרה הספציפי הנ"ל, כפי שאמרתי, (1) זה פשוט מעניין, ואפילו אם הייתי קונה קיט יקר ומורכב שעושה הכל אוטומטית, הייתי מעדיף להבין מה קורה בעומקם של הדברים (2) יחס העלות של קיט יקר ומורכב (נניח colorfacts) הוא כמעט 1:1 למסך שלי (3) בשלב מסוים המטרה והדרך התהפכו - המסע הוא לא כל כך בשביל הכיול אלא יותר בשביל הלמידה...

בכל אופן, כן רכשתי DVE, למדתי את הכיולים העיקריים באמצעותו. אי אפשר בלעדיו.
וכן, ואני שוקל לקנות סנסור פשוט (spydertv) שלדעתי עם קצת ידע אפשר להפיק ממנו הרבה.