בתשובה לגלעד ברזילי, 11/05/03 17:48
 |
|
 |
||
|
||||
 |
המרת A\d? אגב מהו dc computation בהקשר הנ"ל? (סתם מנצל את הדיון להרחיב אופקים) |
 |
 |
 |
|
|
|
||
|
||||
|
המרת A/D זה בסך הכל Analog to Digital, או בלשון העם - דגימה. את המונח dc computation אני לא מכיר, אבל אשמח ללמוד עליו. באיזה הקשר בדיוק אתה מתכוון, ואיפה נתקלת בו? |
|
|
|
|
|
|
||
|
||||
|
נתקלתי בו מתישהו לפני מספר חודשים כשהזדמן לידי חומר מודפס(!) שתיאר אלגוריתם שתכליתו לייצר "חתימה" מקטע אודיו. אני חושב שזה משהו שקשור לאופן שבו כל דגימה בפורמט מכווץ של מוזיקה מכילה מידע הרלוונטי גם דגימות הבאות והקודמות, אבל לא עמדתי על ההגיון1 לאשורו. 1 הנה הסבר איך זה עובד בתמונות (http://www.google.co.il/search?q=cache:wSy7W70GFSkC:...), אבל אני לא רואה איך אותה טכניקה יכולה להיות מיישמת על קול. |
|
|
|
|
|
|
||
|
||||
|
ייתכן שאתה מדבר על קידוד דיפרנציאלי? מדובר בעקרון שיכול להיות מיושם בכל הקלטה או שידור של אות המשתנה בצורה יחסית רציפה ולא רק בתמונות וסאונד. הנחות יסוד: 1. ככל שהאות קטן יותר, הוא תופס פחות מקום (זה נכון בגלל קידודי האנטרופיה שמשתמשים בהם). 2. כל דגימה יחסית קרובה לדגימה הקודמת (בתמונה זה אומר שאין הרבה מעברים חדים בין אזורים בהירים מאוד לכהים מאוד). מסקנה: במקום לשמור את הדגימה הנוכחית במלואה, נשמור רק את ההפרש מהדגימה הקודמת. מכיוון שמדובר באות קטן יותר (לפי הנחה 2), הוא תופס פחות מקום (לפי הנחה 1) ולכן הרווחנו. בשחזור פשוט נחבר את ההפרש השמור עם הדגימה הקודמת (שכבר שוחזרה). בעיה: נניח והדגימה הקודמת נדפקה, גם כל הדגימות שאחריה נדפקות מכיוון שהן מתבססות עליה. פתרון: מדי N דגימות שומרים דגימה באופן מלא ולא באופן דיפרנציאלי כך שהרצף הדפוק נעצר. |
|
|
|
|
|
|
||
|
||||
|
טוב, איך מכווצים תמונה אני יודע, ואני גם יכול לראות איך זה תקף לקולות. יכול להיות שאני חוזר על מה שאתה כבר יודע, אבל נתחיל מהתחלה: נניח שיש לנו תמונת רמות אפור עם 8 ביט - בייט אחד, לפיקסל (ההכללה לצבע קלה - פשוט 3 תמונות של רמות אדום, כחול וירוק). נניח שהיא בגודל של 64 על 64 פיקסל. כדי לשמור אותה ישירות (נגיד בBMP) צריך 64 בריבוע בייט. איך נכווץ? נשמור רק את השורה הראשונה ואת הטור הראשון בתמונה במלואם (64*2 בייט), ונמצא נוסחת שיערוך שאומרת לנו מה הערך בפיקסל הנוכחי כפונקציה של הפיקסל משמאלו, מעליו, ושני הפיקסלים באלכסונים העליונים. נתחיל לעבוד משמאל לימין ומלמעלה למטה, כשאנו משערכים כל פעם את הערך בפיקסל הנוכחי. עכשיו, ברור שאין נוסחת קסם שתתן לנו את התמונה - אז נשמור עבור כל פיקסל את ה*שגיאה* מהנוסחה, וכך נקבל את הערך האמיתי באותו פיקסל. אם הנוסחה טובה (וניתן תמיד למצוא את המיטבית, זו בעייה פתורה) אז השגיאה תתפוס הרבה פחות מ8 ביט, יותר לכיוון ה5, ונחסוך המון מקום. ככה, על רגל אחת, עובד כיווץ. אותו דבר אפשר לעשות בקול - אם נשמור רק N ערכים תחיליים, ונוסחה שמחשבת את הערך הנוכחי על סמך N ערכים אחורה, ונשמור רק את השגיאה מהשערוך, נוכל לחסוך מקום רב. מה זה DC computation? זה טריק כדי להוסיף עוד כיווץ על כיווץ. מסתבר (ממה שקישרת, ואם הבנתי נכון) שאם נפרק את התמונה למרכיב הDC שלה לבד, ולתדרים גבוהים בנפרד, אז את מרכיב הDC קל לשחזר ע"ס רק טור אחד עם מעט שגיאה, ואת הAC משחזרים בנוסחה נפרדת, בשיטת הזיג-זג כפי שהוצגה שם. (לשאלה מה זה תדר גבוה ונמוך בתמונות, אני לא כל כך רוצה להכנס. אבל רק כדי לתת קצת אינטואיציה - מדברים על "תדר מרחבי", לא על תדר רגיל, ולמשטחים חלקים יש תדר נמוך, בעוד לשפות של אובייקטים, לדוגמא, יש תדר גבוה) איך עושים אותו דבר לקול? אני רק משער כאן, אבל אני מניח שהכוונה היא לשמור את הDC (הממוצע של האות, במקרה זה) בנפרד, ולשחזר את האות-פחות-התוחלת, בשיטה שהצגתי קודם. |
|
|
|
|
|
|
||
|
||||
|
אז כתוב שם: DC is the average value of the 8 x 8 original pixel values. באופן כללי יותר, זה שם לרמה של רכיב האפס בהתמרת פורייה. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |