דחיסת תמונות

[אוהב להתווכח]

דחיסת תמונות

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

אשמח לשמוע את דעתכם.

 

[user32]

בגדול הצדק איתך

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

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

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

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

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

מה שכן, בהרבה מהמקרים זיהינו את החלק הבעייתי עוד בשלבי הדיזיין והלקוח הבין את המשמעות. לא תמיד, אבל הרבה פעמים. פיצ'ר של העלאת תמונות אמור ישר להעלות את השאלה "באיזו רזולוציות?" וכשמדובר בכמה MB אז ישר מבררים מה הביצועים המצופים.

 

[d70]

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

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

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

לא בטוח שהפתרון כאן רלוונטי ,אבל עדיין מענין לקרוא.
[URL]https://code.facebook.com/posts/991252547593574/the-technology-behind-preview-photos/[/URL]

 

[יבגניי34]

For the record when instagram launched it was 640x640 proper

pics were downsampled.
Make the math 24 bpp + medium aggressive jpg compression (compression ratio 20-50 on the Q70 area) ==> no way it would allow > 1MB pic to upload *ever*...

 

[rj111]

נסה דחיסה משמרת מידע

יש שני סוגי דחיסות תמונה:
1. דחיסה מאבדת מידע כמו JPEG:
https://he.wikipedia.org/wiki/JPEG
2. דחיסה משמרת מידע כמו PNG:
https://he.wikipedia.org/wiki/PNG
אם תשתמש בדחיסה משמרת מידע, הנתונים יעברו מהר יותר מאשר נתונים לא דחוסים והתמונה לא תאבד מידע. לחילופין ניתן לדחוס ב-JPEG כך שאיבוד המידע אינו נראה לעין אבל יחס הדחיסה יהיה נמוך יותר.
https://he.wikipedia.org/wiki/דחיסת_נתונים

 

[אוהב להתווכח]

ניסינו png

אבל המהירות לא הייתה טובה.
נסינו jpeg עם q=90 והאיכות לא הייתה מספיק טובה בשבילו.

 

[יבגניי34]

אתה ניגש ל״בעייה״ (הלא קיימת) הפוך. גש ללקוח, הסבר לו

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

עכשיו:
- אל ״תנסה פורמטים״. תשתמש ב jpeg.
- downsample, downsample, downsample. אתה מציג במובייל? מה הרזולוציית מסך? מה רזולוציית המצלמה? ואידך זיל גמור.
- בחר Q דינמי לפי מהירות רשת. לך על 2 רמות: Q90 לרשת מהירה, Q70 לרשת איטית. רוב האנשים לא יבדילו בין מקור לדחוס ב Q90 ללא מבט מעמיק.

בהצלחה.

 

[rj111]

השווה זמני טעינה ואיכות הורדה עם איסטגרם ו-imgur

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

 

[אוהב להתווכח]

אינסטגרם לא מעלה את התמונה שלך כמות שהיא

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

 

[Miki Watts]

להגיד לך את האמת, נשמע שהלקוח שלך מסוג הלקוחות

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

 

[ipv6]

כנראה שהטענה שלך על אינסטגרם היא נכונה

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

 

[אוהב להתווכח]

נכון שכמויות הם פקטור משמעותי

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

 

[BravoMan]

ואולי ההנחה הזו היא הבעיה?

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

 

[אוהב להתווכח]

האמת היא שלא חשבתי על זה

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

 

[יבגניי34]

לקח זמן אבל בסוף תפסתי - אתה עובד עם sdk שלהם למובייל?

תבדוק מה התמיכה שלהם ב Incoming transformation
when you have to downsample - downsample, don't talk

 

[BravoMan]

מתי פעם אחרונה don't talk פתר לך בעיה מול לקוח?

אם אתה לא מסוגל לתת פתרון טכני שיענה בדיוק למה שהלקוח מצפה, talk זה האופציה היחידה שיש לך להסדיר את העניין.
&nbsp
אני לא רואה כיצד down sample יעזור מול לקוח שכל הזמן בוכה על איכות התמונה.
&nbsp
לפי התיאור, לא מדובר באפליקציית מסרים מידיים, אלא בשימוש טכני \ אומנותי כלשהו, שמחייב איכות גבוהה יותר מדברים כמו ווטסאפ \ אינסטגראם \ סנאפצ'ט ויתר החולרות.

 

[אוהב להתווכח]

מכיוון שארני מומחה די קטן בתחום

אשמח אם תרחיב על downsample מה ההבדל בין זה לבין שימוש בפורמט כמו JPEG.
&nbsp

 

[יבגניי34]

JPEG מוריד ״תדרים״ מהתמונה. אבל הוא לא ישנה את הגודל שלה.

סביר שבמקרה שלך (שלא פירטת) זה נכון לעשות resize לגודל של תצוגה על מסך מובייל, למשל 500x500. לזה קוראים ״down sampling״.

 

[vinney]

downsample != downsize

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

 

[יבגניי34]

אתה מדבר (אולי) על chroma downsample שזה חלק אינטגרלי מ JPEG

אני מדבר על זה שהוא (אולי) מעלה תמונות ברזולוציה מלאה וזה (אולי) לא הדבר הנכון לעשות...

downsize זה בהחלט סוג (אגרסיבי) של downsampling