שיפור איכות תמונות באמצעות בינה מלאכותית באפליקציה לנייד

מדוע שיפור תמונות ב‑AI נכשל בצילומים אמיתיים

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

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

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

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

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

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

מה נותן שיפור תמונות ב‑AI באפליקציה: האפקט במדדים

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

שיעור הפריימים הכושלים

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

מהירות תגובה ועומס על המכשיר

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

שימור משתמשים והמרה לפרסום

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

מצבי עיבוד: על המכשיר, בענן, היברידי

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

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

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

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

שלבי ההטמעה: מביקורת ועד מסירה לצוות

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

1. ביקורת העיבוד. נפרק את מסלול הפריים הנוכחי: לכידה, דחיסה, חיתוך, קידוד חוזר בהעלאה. נמצא באיזה שלב אובדת החדות ובאיזה מצב הפריים מגיע לשיפור.
2. תרשים מסלול העיבוד. נקבע את מקום השיפור: על המכשיר, בשרת או משולב. נקבע את ההתנהגות ללא רשת, בסוללה חלשה וברקע, כדי שהעיבוד לא יחסום את הממשק.
3. כיול פרמטרים. נתאים את עוצמת ההשפעה, הפחתת הרעש והחדות לפי מחלקות סצנה — פורטרט, לילה, מסמך, נוף. למכשירים חלשים נכין מצב מוקל שבו המהירות חשובה יותר.
4. בקרת איכות. נריץ את הפתרון על פריימים אמיתיים, נשווה לפני ואחרי לפי חדות, רעש וטבעיות. פריימים שהתוצאה בהם גרועה מהמקור ייבדקו בנפרד ונתקן את הספים.
5. אינטגרציה ורגרסיה. נבדוק את זמן העיבוד, גידול בגודל הקובץ וההתנהגות בתורים ארוכים של העלאה; נוודא שתרחישי צילום קיימים אינם נשברים.
6. נראות וחזרה לאחור. נוציא מדדים של שיעור הכשלים וזמן העיבוד, נשאיר מתג שמחזיר את ההתנהגות הקודמת בלי להוציא גרסה חדשה.
7. מסירת תיעוד. נמסור את תרשים מסלול העיבוד, ערכי הפרמטרים, סטי פריימים לבדיקה, הוראות לעדכון המודל ולטיפול בתקלות. נקיים הדרכה לצוות ונלווה את תקופת ההפעלה הראשונה.

תוצרי המסירה: תרשימים, מדיניות, נהלים

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

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

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

מקרה בוחן: כיצד עלתה איכות צילומי הלילה

מקרה ההטמעה התחיל בשירות שבו המשתמש מצלם אובייקט בתאורה חלשה: פריימי לילה היוו כשליש מההעלאות וכמעט את כל הפניות לתמיכה. תמונה שצולמה בערב לא עברה לעיתים קרובות בדיקת איכות אוטומטית ונשלחה לצילום חוזר — המשתמש נשאר להמתין לתוצאה.

המדדים לפני ואחרי נאספו באירועים ישירות באפליקציה. לפני העבודה: 22% מפריימי הלילה נפסלו, 9% מהמשתמשים במקום לצלם מחדש כתבו לתמיכה, זמן עיבוד הפריים הגיע ל‑4-5 שניות, ובמכשירים חלשים הצילום נקטע בגלל פסק זמן והפריים אבד. צילומים חוזרים של אותו אובייקט הגיעו ל‑38% לעומת 10-15% הצפויים.

מה שינינו

הרכבנו מסלול עיבוד משלבים עוקבים: הערכת רמת הרעש לפי הפריים, הפחתת רעש תוך שימור טקסטורה עדינה, הגברת חדות מקומית לפי מסכת פרטים והרמת צללים בלי לשרוף את מקורות האור. חישוב המודל מתבצע על המכשיר דרך Google ML Kit — הפריים אינו נשלח לשרת, והתוצאה אינה תלויה באיכות החיבור.

מה קרה בסוף

שיעור פריימי הלילה שנפסלו ירד מ‑22% ל‑7%, תלונות על איכות הצילום — פי שלושה פחות, זמן עיבוד הפריים התקצר ל‑1-1.5 שניות. הצילומים החוזרים ירדו ל‑12%, ומספר פריימי הלילה הנשמרים למשתמש עלה ב‑40%.

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

מה לעשות אם באפליקציה כבר קיימת עיבוד תמונות?

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

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

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

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

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

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

ספקות טכניים: פרטיות, עומס, איכות

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

מה עם צריכת הסוללה?

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

בכמה יגדל גודל האפליקציה?

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

הפונקציה עובדת בלי רשת?

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

כיצד שומרים על צפיות התוצאה?

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

נדון במשימה: נחזור עם הערכה ותוכנית עבודה

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

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

תארו את המשימה — ונחזור עם הערכת מורכבות, תוכנית הטמעה וקריטריוני קבלה:

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

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