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

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

DEINTERLACING, SCALING, הורדת רעשים, UPCONVERSION, TRANSCODING.
unsound_methods (פותח השרשור)
סמל אישי של משתמש
חבר פעיל במיוחד
חבר פעיל במיוחד
הודעות: 563
הצטרף: אפריל 2006
מיקום: מרכז
נתן תודות: 0
קיבל תודות: 0

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

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

שוב בענייני color decoder.
אני מזהיר - זה די טכני. אבל יש שאלות ומסקנות מעניינות בסוף.

אתחיל בהקדמה למע' encoder/decoder של צבע.
(אני מתייחס לעולם אנאלוגי, אבל דיגיטאלי מאד דומה)

מע' encoder טיפוסית (מצלמת וידאו):

--> א --> ב --> ג --> ד -->

א' היא מטריצה לינארית 3X3. בכניסה מקבלת 3 ערכי צבע לפי הפריימריס של המצלמה, וממירה לערכי RGB סטנדרטים - כלומר ערכי RGB שמתאימים למערכת פריימריס ו white balance סטנדרטיים (לפי אזשהו סטנדרט - נניח Rec 709 עבור HD).

ב' זו התמרה לא לינארית לכל רכיב RGB, קרי תיקון גאמה (נניח תיקון גאמה לפי הפונקציה המוגדרת ב Rec 709). נקרא לתוצאה `R`G`B כדי לציין ערכים מתוקני גאמה.

ג' היא מטריצה לינארית 3X3, שממירה ערכי 'R'G'B לרכיבים הבאים: לומה והפרשי צבע, קרי Y'PbPr. המקדמים במטריצה לפי סטנדרט המרה מסוים, נניח Rec 709.

ד' ביצוע subsampling של קומפוננטות הפרשי הצבע PbPr, על ידי low pass filter.

מה יצא? קומפוננט - שמשודר או נשמר על DVD וכו'.

ועכשיו decoder (אמצעי התצוגה):

--> #ג --> #ב --> #א -->

#ג - מטריצה לינארית 3X3: מקבלת ערכי קומפוננט Y'PbPr, ממירה ל 'R'G'B לפי סטנדרט מסוים (ההופכית של ג)

#ב - התמרה לא לינארית לכל רכיב 'R'G'B (פונ' גאמה), המוציאה ערכי RGB המתאימים למערכת פריימריס ו white balance סטנדרטית (שוב נניח Rec 709).

#א - מטריצה לינארית הממירה ערכי RGB של מערכת צבע סטנדרטית, לערכי RGB המתאימים לפריימריס (מערכת הצבע) של אמצעי התצוגה.

מה יצא? ערכי RGB שמתאימים למערכת הפריימריס של המסך (מכאן: להזין אותם חשמלית לכל פיקסל, הפיזיקה וחוש הראיה יעשו את שלהם).


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

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

שאלות מעניינות:

- למה במסכים יש בקר color?
בקר זה מפעיל gain על הפרשי הצבע PbPr, רגע לפני שהם נכנסים ל #ג.
למה שבכלל נרצה להפעיל עליהם gain?? הרי הם נכונים! הם יצאו החוצה מה encoder!(על ידי המטריצה ההופכית ג).

- בציוד קצה שמוציא ממשק 'R'G'B - לדוגמא נניח ממיר שמוציא 'R'G'B או ממשק VGA של כרטיס מסך - אותו ציוד ביצע את #ג בעצמו (המיר מקומפוננט ל 'R'G'B מתוקני גאמה, לפי מטריצת המרה סטנדרטית).
מה שנשאר למסך לעשות, זה להפעיל גאמה (שלב #ב) ואז להמיר למע' הפריימריס של המסך (מטריצה #א).
ואכן, שמזינים אות כזה למסך, בקר ה color נעלם (כי המסך לא מבצע את #ג).
במצב זה, אנו תלויים באיכות המימוש של #ג בממיר/כרטיס מסך. בד"כ אין לנו שליטה על זה. ההנחה שלי היא שהמימוש במסכים יקרים טובה יותר מאשר בכרטיסי מסך/ממירים זולים. בנוסף, במסכים דיגיטאלים יקרים ניתן לקנפג את ה decoder.
לכן, להוציא 'R'G'B מציוד הקצה לא בהכרח יניב איכות טובה יותר מאשר להוציא קומפוננט.
יש השגות בעניין זה?

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

eugbuber
חבר פעיל
חבר פעיל
הודעות: 86
הצטרף: אפריל 2006
נתן תודות: 0
קיבל תודות: 0

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

למה צריך COLOR...הניחוש שלי יהיה: מכייון שהמסכים לא ממשים את א# (הPRIMARIES הם תלוי הפוספורים בהם משתמשים) אז על מנת לפצות ולקבל את הPRIMARIES יותר קרובים לSTANDARD עושים adjustment לPbPr לפני ששולחים אותם לדקודר.

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

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

unsound_methods
- למה במסכים יש בקר color?
...
כמעט מאותה סיבה שצריך בקר בהירות ובקר קונטרסט.
תיאורטית אתה צודק.
אם כל התהליך היה דיגיטאלי אז בהחלט המידע היה מגיע לדריבר של המסך בצורה נכונה. כשמדובר בתהליכים אנלוגיים הסיפור כבר שונה. פשוט אין אפשרות (במחיר סביר) להגיע לאורך כל התהליך לדיוק הרצוי. מספיק אם משתתפים בחגיגה 5 נגדים שכל אחד רק 1% דיוק וכבר יש לך סטיה של 5% בתוצאה.
ב DVD זה כמעט נכון שלא צריך בקר COLOR. למה כמעט, כי גם DVD מוציא אותות מורכבים (כמו Composite), והמסך במקרה הזה צריך לבודד את אותות הצבע מהשחור/לבן.
אותות הש/ל ואותות הצבע עוברים מסלולים שונים גם בתהליך שנוצר אחרי המטריצה במקודד וגם בתהליך שמשחזר את האות לפני הכניסה למטריצה במשחזר. המסלולים אמנם מקבילים אבל לא שווים, כלומר לא עוברים את אותה אלקטרוניקה או את אותו סוג של גלאי. כתוצאה מכך אות הצבע מגיע למטריצה בעוצמה שונה מאות הש/ל וגם לא תמיד בפאזה הנכונה. ושוב, על המעגלים מוטלת החובה ליצור תאום בין הרמות השונות לפני הכניסה למטריצה.
יותר מזה, בשידור באוויר (או אפילו בחיבור כבל וידאו ארוך) התדרים השונים מגיעים למקלט בעוצמות לא שוות, ושוב יש צורך בקיזוזים של האלקטרוניקה.
בקר זה מפעיל gain על הפרשי הצבע PbPr
...
Gain זה לא בהכרח הגברה (זה גם ניחות). כמו שאתה מבין, העניין קצת יותר מורכב ולכל אורך האפנון והגילוי יש צורך בתהליך מדויק שקשה לבצע.

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

ולמרות כל מה שכתבתי, אני חושב שנתינת אפשרות לצופה לשלוט על עוצמת רווית הצבע לפי טעמו זה התירוץ הטוב ביותר להשאיר את בקר ה COLOR על כנו.

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

- האם מסכים דיגיטאליים אכן ממשים את מטריצה #א, או שערכי RGB סטנדרטיים מוזנים ישירות לפיזיקה של הפיקסל?
...
לדעתי המסכים כן ממשים את מטריצה #א.
למעשה השאלה הזאת היא הבסיס לתהליך המורכב של ה- Color Management.
מה זה צבע אדום? מה אורך הגל המדויק של צבע אדום?
אם לדוגמה יש אות RGB שמכיל ירוק וכחול שווים ל 0, ואדום שווה ל 255 (רק אדום), איזה צבע אדום (או אורך גל) המסך שלי יקרין?
כל מסך והכימיה שלו וסביר שעבור אותו מספר של Red, המסך שלי ושלך יתנו צבע קצת שונה, ולכן אין מנוס מהתמרה של המספרים הדיגיטאליים לצבע מוסכם המוגדר בתקן, וזאת הסיבה שאני חושב שבהחלט ממשים את מטריצה #א.

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

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

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

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

motico,

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

כעת, בו נבודד את הדיון לעבר setup מוגדר יותר: תוכן דיגיטאלי - נניח DVD , או שידורים דיגיטאליים; כמו כן נניח שהממשק הוא קומפוננט.

במצב זה, היציאה של מע' ה encoder (אחרי ד') היא subsamlped Y'CbCr; וזה נכנס אל הדוחס (mpeg encoder).
קצת לפני הכניסה ל decoder (לפני #ג) פועל הפורס (mpeg decoder), שמוציא את אותם subsampled Y'CbCr, שעוברים אינטרפולציה (להשלים את ה samples החסרים כדי שהממדים של הקומפוננטות יהיו זהים) ואז נכנסים לתוך הדקודר (לתוך #ג).

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

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


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

ציינת בתשובתך שיש להבין מהו "צבע" מסוים לצורך מתן תשובה לשאלה.
לשמחתנו, יש הגדרה די ברורה לצבע. ערכי CIE X Y Z (או x ו- y).
עבור מקור שיש לו spectral distribution מסוים, ניתן להעביר (להכפיל) אותו דרך שלושה פילטרים (שלוש פונקציות אנליזה על ה spectral dist) - לעשות אינטגרציה לפי שלושת הפילטרים הללו - ולקבל ערכי X Y Z שאמורים לייצג את ה"עוצמה" שאנו חשים בכל אחד משלושת סוגי הקולטנים שיש לנו בעין.
שים לב - ייתכנו שני מקורות שונים, כל אחד עם spectral dist אחר, אשר יניבו ערכי X Y Z זהים - מבחינתנו, אנחנו נראה את אותו הצבע! כלומר X Y Z הם ההגדרה לצבע.
ובאופן יותר מדויק, אם נבצע "היטל" שלהם (נירמול של כל אחד מהם לפי הסכום X+Y+Z) אז נקבל קואורדינטות x,y שהם הגדרה לצבע טהור (ללא תלות ב"עוצמת" ההארה).

סטנדרט צבע מסוים מגדיר מהם הפריימריס שלו, כלומר את ה"צבע" (x,y chromaticity) של כל פריימרי, ומגדיר את ה white point.
לכל סטנדרט ישנה מטריצת המרה מערכי ה RGB שלו, לערכי XYZ (למעשה מטריצה זו מגדירה את מע' הצבע). כאשר מכניסים למטריצה (1,0,0) - כלומר רכיב R בלבד - מקבלים את ה XYZ של הפריימרי האדום. כנ"ל לשני הרכיבים האחרים. שמכניסים למטריצה (1,1,1) מקבלים את ה XYZ של ה whitepoint שמוגדר עבור אותו סטנדרט (בד"כ זה D65).

לסטנדרטים שונים (PAL, 480i SDTV, HDTV REC 709) מוגדרים פריימריס שונים (כלומר בעלי xyz chromaticity שונים). אם זאת, הם מאד מאד קרובים, ומגדירים משולש גאמוט מאד דומה. כולם משתמשים ב D65 white.

ואיך כל ההקדמה הזו קשורה להשערה שלי?
מכיוון שמשולשי הגאמוט של התקנים הללו קרובים מאד, לא נראה לי שמימשו אוסף מטריצות #א שתעבירנה מכל תקן אפשרי אל מערכת הפריימריס של המסך בפועל - היצרנים מניחים שהפריימריס שלהם מספיק קרובים לתקנים השונים - בדיוק כמו ב CRT (שם לא ניתן בכלל לממש את המטריצה).
וזו כנראה התשובה לשאלה ששאלתי פעם: מדוע צריך לכייל את המסך בנפרד לכל סוג אות (PAL, NTSC, HD) - בדיוק בגלל שאין המרה #א; אנחנו מפצים על כך באמצעות כיול color,tint ו- white balance לכל סוג אות (כלומר "משחקים" עם מקודד הצבע כדי לקבל את ההתאמה הנדרשת). כאן אני מסכים עם תשובתו של eugbuber.

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

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

unsound_methods

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

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

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


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

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

לגביי סעיף 1.
אני מניח שזאת הכוונה שלך להמרה #א.
זה נכון שהתקנים מגדירים תחום צבע דומה אבל זה לא אומר שהמספרים שמגדירים את אותו צבע הם אותם מספרים.
צבע מסוים יוגדר בתקן אחד כ 100.20.20 , בתקן אחר אותו צבע יוגדר כ 100,20,25.
וזה כמובן מחייב המרה של המספרים בין התקנים.

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

oferlaor
סמל אישי של משתמש
מנהל
מנהל
הודעות: 75316
הצטרף: נובמבר 2004
שם מלא: עפר לאור
מיקום: מודיעין, ישראל
נתן תודות: 640 פעמים
קיבל תודות: 4750 פעמים

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

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

כיום כמעט אף מסך פרט ל-CRT לא מכסה את REC709 או אפילו REC601. אני חושב ש-VW100 הוא המקרן היחיד שיש לו GAMUT מספיק רחב בכדי לעשות זאת. ההפרש ב-PRIMARIES בין שני אלה, אגב, הוא קטן.

ברגע שהמסכים יכסו את ה-GAMUT כראוי, אז בוודאי יתווספו יכולות PRIMARIES טובות יותר במסכים...

אגב, יש חברה ישראלית בשם ג'נום או משהו כזה, שעוסקת בהרחבת ה-COLOR GAMUT עבור LCD ופלאזמות על ידי הוספת שניים או שלושה SECONDARIES אקטיביים.

איתי_הגיתי
סמל אישי של משתמש
חבר מכור קשה
חבר מכור קשה
הודעות: 6031
הצטרף: נובמבר 2004
נתן תודות: 92 פעמים
קיבל תודות: 76 פעמים

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

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

udif
חבר ותיק
חבר ותיק
הודעות: 2067
הצטרף: אוקטובר 2005
מיקום: תל אביב
נתן תודות: 37 פעמים
קיבל תודות: 124 פעמים

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

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

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

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

motico,

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

שלב #ב הוא החלק בדקודר שמבצע גאמה על כל רכיב 'R'G'B. הפלט הוא ערכי RGB "לינאריים" לפי מערכת (תקן) צבע מסוימת. אלו הם ערכים שבאים מעולם הפיזיקה - linear light quantities שצריך לתת לכל פריימרי כדי לשחזר את הצבע, כלומר לגרום לכך שבסך הכל, ערכי ה xyz שיתקבלו יהיו זהים לאלה שנתפסו בסצנה המקורית.

נניח שישנו מסך תאורטי ובו הפריימריס תואמים בדיוק לפריימריס שהוגדרו בתקן; כלומר, ה"צבע" (ערכי xyz) של כל אחד משלושת הפוספורים הוא בדיוק אותו "צבע" שמוגדר בתקן עבור כל פריימרי. בנוסף, נניח שבמסך התאורטי הנ"ל, ישנו קשר לינארי בין מתח הכניסה לכל subpixel (קרי: לכל פריימרי) לבין ה physical intensity שיוצאת החוצה מאותו subpixel.
במצב תאורטי שכזה, כל מה שיש לעשות, זה להזין את ערכי ה RGB הלינאריים שיצאו משלב #ב לכל subpixel.
בגלל שכל פוספור הוא בעל אותו "צבע" כפי שמוגדר בתקן, ובגלל הקשר הלינארי של האופן בו מפעילים subpixels, מובטח לנו שחזור מדויק של הצבע.
למעשה, אני מניח שאלה "שני השלבים" שאתה מתייחס אליהם.

עכשיו, טענתי היא שהקשר הפיזיקלי להפעלת כל subpixel בהתאם לערך R או G או B המתאים לו (שקיבלנו מ #ב) אכן קיים, אבל איננו מעניין אותנו לצורך הדיון הזה. למה? כי זה קשר שפועל ברמת רכיב הצבע הבודד (R או G או B); זה איננה טרנספורמציה לינארית שמעבירה ממרחב RGB אחד למשנהו. אחזור לזה מיד.

לאט לאט נחזור לפרקטיקה. נבחר בפלזמה לשם הדיון.
עדיין, נניח לרגע כי הפריימריס של הפלזמה (ה"צבע" של כל פוספור) הם בדיוק כפי שדורש התקן.
תחילה, נעסוק בקשר הפיזיקלי להפעלת כל subpixel בהתאם ל linear light quantity שקיבלנו מ #ב. למזלנו, בפלזמה זה אכן קשר לינארי. האופן בו שולטים ב physical intensity של כל subpixel הוא באמצעות PWM, שהוא הרי לינארי. לדוגמה, אם ערך ה R שקיבלנו הוא 0.7 (סקלה של 0 ל1), אז הדרייבר של ה PWM צריך לגרום שאותו subpixel יהיה דלוק בממוצע 70% מהזמן.
בטכלונוגיות אחרות, זה כמובן פועל אחרת, ולא בהכרח באופן לינארי.
אבל זה האספקט שלא מעניין אותנו בדיון הזה - בעיניי, הדרייבר הפיזיקלי שאחראי לגרום לכך שבהינתן linear light quantity של רכיב צבע בודד (R או G או B) ה subpixel המתאים יפיק את ה physical intensity הרצוי, איננו חלק מהמערכת שאני קורה לה color decoder.

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

לבסוף, דוגמא. נניח שהתקן (מערכת הצבע) בו השתמשו לייצג את הצבע באות המקורי הוא REC 709. נניח שהפריימריס של המסך (הפוספורים) הם בעלי "צבע" כפי שמוגדר בתקן PAL. מטריצה #א במקרה זה, אמורה להיות המטריצה הממירה ממרחב RGB לפי REC709 למרחב RGB לפי PAL.
אגב, מכיוון ששני התקנים הללו הם בעלי פריימריס חופפים (כמעט זהים), אז מטריצת ההמרה היא כמעט מטריצת היחידה (המקדמים מחוץ לאלכסון נושקים לאפס, ואלה על האלכסון נושקים לאחד).
אחרי שהפעלנו את #א, שולחים את ערכי הרכיבים שהתקבלו אל הדרייבר הפיזיקלי של המסך (שפועל על כל רכיב בנפרד, כדי "להפעיל" כל subpixel). וכאמור, שלב זה בלתי תלוי בתהליך הדקודר, תמיד צריך לבצע אותו, הוא איננו המרה לינארית בין שני מרחבי צבע, ולכן בעיניי הוא איננו חלק מתהליך הדקודר.

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

(וואו זה היה מתיש)

איתי_הגיתי
סמל אישי של משתמש
חבר מכור קשה
חבר מכור קשה
הודעות: 6031
הצטרף: נובמבר 2004
נתן תודות: 92 פעמים
קיבל תודות: 76 פעמים

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

unsound
מה אתה אומר על מה שכתבתי?
אני לא טכני, במטוטא ממך...
8)
יש לך שם רגיל, אגב?

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

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

איתי,

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

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

oferlaor
סמל אישי של משתמש
מנהל
מנהל
הודעות: 75316
הצטרף: נובמבר 2004
שם מלא: עפר לאור
מיקום: מודיעין, ישראל
נתן תודות: 640 פעמים
קיבל תודות: 4750 פעמים

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

איתי,

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

unsound_methods,

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

איתי_הגיתי
סמל אישי של משתמש
חבר מכור קשה
חבר מכור קשה
הודעות: 6031
הצטרף: נובמבר 2004
נתן תודות: 92 פעמים
קיבל תודות: 76 פעמים

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

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

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

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

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

עופר, אולי אתה יודע - (שאלתי זאת בשרשור אחר) למה הפוספורים של הפלזמה לא מדויקים ספקטרלית כמו אלה של CRT ?

oferlaor
סמל אישי של משתמש
מנהל
מנהל
הודעות: 75316
הצטרף: נובמבר 2004
שם מלא: עפר לאור
מיקום: מודיעין, ישראל
נתן תודות: 640 פעמים
קיבל תודות: 4750 פעמים

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

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

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

שלח תגובה

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