תופעה משונה ב PWD8 - בקר ה picture לא מתנהג בצורה אחידה

[unsound_methods]

שוב תופעה משונה מאד ב PWD8.
הייתי שמח לשמוע האם מישהו מבעלי הפנסוניק נתקל בה.

התופעה נחשפת בעל כיול ה"קונטרסט" (picture).
נניח כיילנו black level בצורה נכונה באמצעות בקר ה brightness ו test pattern מסוג PLUGE. המדיד של ה brightness נמצא בדיוק ברמה בה הרקע באמת שחור - כך שהזזה של המדיד יחידה אחת למעלה תגרום לרקע להיות קצת מעל שחור (אם נתקרב למסך, נראה קצת פיקסלים מרצדים).
נישאר בתמונת ה PLUGE, וכעת נעבור על מדיד ה Picture, שלב שלב מ 30- עד 0, לאט לאט, בתור ניסוי.
מה אמור לקרות? שום דבר מעניין פרט לכך שלאט לאט רמת הבהירות ב bars של ה PLUGE אמורה לעלות קצת.

מה באמת קורה ?
בערכים מסוימים של picture, שחור הרקע משתנה קצת ומתבהר (צריך להסתכל מקרוב מאד, בחושך מוחלט - ניתן להבחין בניצנוצי פיקסלים).
תופעה זו מוכרת לי כבר, הזכרתי אותה בעבר בפורום, מדובר ב floating blacks (נקרא גם DC restoration).

אבל קורה כאן משהו מוזר הרבה יותר:
יש ערכים מסוימים ספציפיים של picture בהם התופעה לעיל מתרחשת - לדוגמא, בכל הרמות מ 30- עד 17-, רמת השחור נשמרת נכון. ואז, שמעלים את ה picture ל 16-, אז שחור הרקע מתבהר (מבחינים בנצנוץ). אם נמשיך להעלות ל 15-, אז שחור הרקע חוזר לקדמותו (שחור אמיתי ותקין) !!! נמשיך להעלות המדיד עד 9-, הכל בסדר, רמת השחור נשמרת. נעלה המדיד ל 8- והפלא ופלא, שחור הרקע מתבהר!! נמשיך להעלות ל 7-, והוא חוזר לקדמותו !!! הכצעקתה ???

אם כבר קיימת תופעת floating black level, מדוע היא מתרחשת בערכים ספציפיים של מדיד הקונטרסט ?
ואם כבר, הייתי מצפה ל"אחידות" ול"רציפות" בהשפעתו של בקר ה picture - כלומר, לא הייתי מצפה שב 9- וב 7- ה black level זהה אבל ביניהם ב 8- ה black level זז !!!
הייתי מצפה ל"רציפות" - נניח, החל במינוס 8 [ולכל הערכים מעל מינוס 8] רמת ה black level הוסטה קצת [ממה שהייתה עבור ערכים מתחת למינוס 8].

מה קורה פה??
נראה לי שהתוכנה של עיבוד התמונה בפנסוניק ממש זולה/באגית...

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

[motico]

unsound_methods

מה זה Picture ב PWD8 ? האם זה שם אחר ל brightness ?

[unsound_methods]

picture זה מה שברוב המסכים נקרא contrast.
בקר זה שולט בעוצמת התאורה של הלבן. מטרת כיולו היא לגרום לכך שסיגנל המציין לבן (100 IRE) יפיק את הרמה הנכונה של הבהירות.
זהן בעצם gain (פקטור) על כל ה grayscale transfer function.
במסך אידאלי בקר זה לא אמור להשפיע על ה black level.

[oferlaor]

unsound_methods,

תופעה ידועה, שים לב שה-AGC שלך וה-BLACK EXTENSION שלך כבויים ושאתה לא במצב SCURVE.

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

[unsound_methods]

עופר,

כל העיבודים ה"מתוחכמים" (AGC ו B.E.) כבויים אצלי, גאמה על 2.5 בהמלצתך...

ב PHD ניתן לטפל בבעית floating blacks ע"י שינוי ב service menu (משהו שנקרא "letterbox mode" בגלל שאנשים בד"כ שמו לב לתופעה ב bars של הלטרבוקס).
בתוכנה שנמצאת על ה PWD לצערי לא ניתן לטפל בבעיה.

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

2.
אני רוצה לנטרל לחלוטין (to bypass) עיבודי תמונה שנעשים ע"י הפנסוניק. איזה אפשרויות עומדות בפניי?
חייב פרוססור חיצוני? ועדיין, נניח פרוססור חיצוני, עדיין יבוצעו עיבודיים של המסך על הכניסות, לא? האם ב DVI לא יבוצעו העיבודים הנ"ל?

3.
רוצה לשדרג התוכנה לזו שיש ב PHD. מנסיונך, שמעת על אפשרות כזו?

[oferlaor]

אגב, איך אתה נכנס ל-SERVICE MENU הנ"ל?

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

2. תלוי איזה עיבודים. ניתן במידה מסויימת להוריד את הגאמה, COLOR CORRECTION וSCALING/DEINTERLACING אבל כל אלה דורשים HTPC או לפחות פרוססור (כלומר, עלות השקעה ראשונית גבוהה למדי ביחס לעלות המסך).

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

[unsound_methods]

אגב, איך אתה נכנס ל-SERVICE MENU הנ"ל?

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

...

גישה ל CATS service menu
http://www.bruzzi.ws/plasma-faq/showthread.php?t=142

(3)
אגב, ההבחנה בין software ל firmware היא בעיני המתבונן.
בעולם המונחים בסביבה שאני מגיע ממנה, קוד שרץ על המעבד הראשי נחשב "התוכנה" (לא משנה אם הוא שמור במקור על דיסק, פלאש או אפרום). מה שרץ על מעבדי עזר ו- accelerator processors למינהם נחשב "firmware".
בנוסף, ההנחה שלך שהתוכנה שונה לא בהכרח נכונה. אם המוצרים דומים, מאד קל ליצרנים לייצר תוכנה אחת, שחלק מהפיצ'רים חסומים (או ע"י זיהוי ב runtime או ע"י קריאת ערכי קונפיגורציה). ראה לדוגמא כל ה"מודמים" ל DSL ש"נפרצים" בקלות והופכים לראוטרים.
לבסוף, למסכים אלה יש serial port. הוא לא סתם נמצא שם, אני בטוח שניתן לשנות באמצעותו קונפיגורציה ואולי יותר מזה... אבל אין תעוד.

[eugbuber]

למרות שהפעלתי את הLETTER BOX MODE בSEVICE MENU. הוא גם לא אמור היה לטפל בבעיה הזאת אלא בשינוי דינמי של ה BLACK LEVEL בזמן צפיה.

[unsound_methods]

eugbuber שפן הנסיונות שלי - תודה !

נכון, אני מסכים, ה letterbox mode אמור לטפל בשינוי הדינמי של ה b.l. כאשר ה APL של התמונה משתנה.

אבל אני נוטה (בעצם, נטיתי) לחשוב שיש אזשהו קשר בין הדברים.
אם ה letterbox mode אכן מקבע את ה b.l. (כלומר גורם לכך שרק מדיד ה brightness שולט בו, כמו שאמור להיות במסך אידאלי) - אז ציפיתי שהוא יהיה באמת קבוע, ולכן אצלך (אחרי שתיקנת את ה letterbox mode ב PHD), לא תהיה התופעה המשונה של ה"קפיצות" ב b.l בעת שינוי הקונטרסט.
מסתבר שטעיתי...
העסק פה ממש מסתורי. אני לא מצליח לבנות שום הסבר לוגי לתופעה. נראה כמו באג.

[motico]

unsound_methods

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

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

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

[unsound_methods]

מוטיקו,
אכן דברים מעניינים.

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

...

רק לחדד הנקודה - זה לא מה שטענתי. במסך אידאלי:
בקר ה"בהירות" מוסיף קבוע ל grayscale transfer function. ולכן, ברור שהוא משפיע על כל העקומה.
משתמשים בו כדי לכייל נכונה את ה B.L - להתאים העקומה כך שתתחיל באפס (ולא מעל אפס, כי אז אין שחזור של שחורים כלל, אלא מתחילים באפור כהה; ולא מתחת לאפס, כי אז אפורים כהים נקטמים לשחור). זה הכיול החשוב ביותר לדעתי.
בקר ה"קונטרסט" מכפיל את ה grayscale transfer function בפקטור קבוע. לכן, גם הוא משפיע על כל העקומה.
נעזרים בו כדי לכוון נכון את ה peak brightness; כשעשית זאת, קבעת בעצם על התחום הדינמי שאתה רוצה להציג.

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

...

הסבר טוב - ואכן כך אני מבצע את הכיול.

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

...

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

[eugbuber]

motico,

כל מה שאתה אומר הוא נכון - אבל התופעה שאנחנו ראוים היא לא רציפה! דרגה אחת של CONTRAST מקפיצה קצת את הBLACK LEVEL וזה הגיוני לפי ההסבר שלך, אבל למה בדרגה הבאה הוא חוזר חזרה?
ויש כמה נקודות "סינגולריות" כאלה על הסקלה של CONTRAST...

[unsound_methods]

נקודות "סינגולריות"

...

[motico]

לחדי העין

אני מבין שמה שמפריע זה חוסר הרציפות בנקודת השחור. אנחנו עושים במוח התמרה אנלוגית ולא מבינים למה שעוברים ממספר 7 ל 8 ולאחר מכן ל 9 השינוי הוא לא באותו כיוון.

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

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

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

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

מה דעתכם ?

[nirgen]

"שינויי ההגדרות יעשו באחריות המשתמש בלבד"
או
"אם אתה לא יודע מה זה אל תשחק עפ זה"

מפני שלאחר ש"למדתי" איך נכנסים ל SERVICE MENU שיחקתי שם עם הנתונים - איבדתי את השליטה עם השלט

לאחר מס' דקות לחוצות למדתי איך להשיבו לפעולה


unsound
אשמח ללמוד מהנסיון שלך מהם הפרמטרים המוגדרים כרגע במסך שלך ?

חג שמח

[unsound_methods]

motico,

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

מה שמוזר, שזה ניכר בקלות לעין, לא צריך משחק מיוחד, רק לעבור משנתה לשנתה במדיד הקונטרסט.
הנקודה שלי: בקרת האיכות היתה אמורה לעלות על התופעה, שלמשתמש הקצה נראית מאד מוזרה (בלשון המעטה) - ואז היו צריכים לשנות טיפה את האלגוריתם, המקדמים במשוואה, מה שזה לא יהיה. לתקן הבאג.
אחד הדברים החשובים בכל בקרי המשתמש, שהם אמורים להגיב בצורה "יוניפורמית" לדרישות המשתמש ולאיך שהוא חווה את תגובתם. אם ברסיבר/אמפליפייר שלך, היית מעלה את הווליום, ופתאום בשנתה X הוא היה קופץ משמעותית לרמות לא סבירות, ובשנתה X+1 הווליום היה נרגע - היית מחזיר אותו, הלא כן?

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

[unsound_methods]

nirgen,

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

אפרט רק לגבי כניסת ה SVIDEO (מסך PWD8 ממיר 3100S), שזו דווקא הכניסה הקשה יותר לכיול בהעדר test patterns מספקים.
כרגע:
picture -15, brightness 0, color -5
gamma 2.5, black ext 0, input level 0, color temp COOL, no AGC
בנוסף, אני מפעיל peak limit לכל הכניסות.

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

[nirgen]

הם תוכל לפרט מהם הגדרות התמונה אצלך
תודה מראש
ניר

[motico]

unsound_methods

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

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

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

[unsound_methods]

motico,

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

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

...

לא יכול שלא להסכים. הייתי רוצה התנהגות קצת יותר קוהרנטית, זה הכל... כנראה שרף הדרישות שלי בשמים