# מעבדת תנועת המצלמה: איך 147 סרטונים לימדו אותנו להזיז מצלמה

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

Source: https://nodaro.ai/he/docs/research/camera-motion-lab

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

- משך המחקר: 25 ימים
- סרטונים: 147
- תמונות בסיס: 13
- אפשרויות שאושרו: 64 מתוך 64
- קרדיטים: 72,118
- המודל העיקרי: Seedance 2.5

בהתחלה, הבעיה נראתה פשוטה.

יש לנו בורר [תנועת מצלמה](https://nodaro.ai/docs/nodes/creative-controls/camera-motion). בוחרים בו תנועה, כגון Orbit, Truck, Dolly In או Whip Pan, ואנחנו מוסיפים לפרומפט של רכיב הווידאו תיאור קצר של התנועה הזו.

התחלנו מההוראה המקצועית הפשוטה ביותר:

```
המצלמה עושה טראק שמאלה
```

הפרומפט המקורי באנגלית:

```
camera trucks to the left
```

כל צלם או במאי היה מבין מיד את ההוראה הזו. **המודל כמעט לא זז.**

ניסינו את Orbit:

```
המצלמה מקיפה את הנושא שמאלה, במסלול מעגלי
```

הפרומפט המקורי באנגלית:

```
camera orbits around the subject to the left in a circular path
```

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

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

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

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

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

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

## מה בדקנו בפועל
המחקר נמשך 25 ימים. יצרנו 147 סרטונים ו-13 תמונות בסיס, ובסך הכול הוצאנו 72,118 קרדיטים: בערך $200–$220 לפי מחירי טעינת הקרדיטים שפורסמו בזמן המחקר.

98 סרטונים נוצרו עם [Seedance 2.5](https://nodaro.ai/docs/models/video/seedance-2-5) ב-480p, עוד 47 עם [Seedance 2 Fast](https://nodaro.ai/docs/models/video/seedance-2-fast) ושניים עם VEO 3.1, בהשוואת ספקים בשלב מוקדם.

<StackedBar
title="147 סרטונים לפי מודל"
ariaLabel="Seedance 2.5: 98 סרטונים. Seedance 2 Fast: 47. VEO 3.1: 2."
parts={[
{ label: 'Seedance 2.5', value: 98 },
{ label: 'Seedance 2 Fast', value: 47 },
{ label: 'VEO 3.1', value: 2 },
]}
/>

בסוף, כל 64 האפשרויות של הבורר תנועת מצלמה שנכללו במחקר אושרו: 61 על Seedance 2.5 ושלוש על Seedance 2 Fast.

**היקף המחקר: מחקר שנעשה כחלק מפיתוח המוצר, לא בנצ׳מרק סטטיסטי:** 
לא הרצנו כל פרומפט מאות פעמים כדי להעריך הסתברות הצלחה כללית. המטרה הייתה למצוא לכל אפשרות בבורר הוראה גנרית ואמינה מספיק, כדי שאפשר יהיה להשתמש בה בפרודקשן. הבדיקות נעשו בעיקר עם Seedance 2.5 ו-Seedance 2 Fast, בהרצות מתמונה לווידאו, ברזולוציה של 480p ועם פרומפטים באנגלית. כשהמאמר הזה אומר שמשהו ״עבד״ או ״נכשל״, הכוונה למה שקרה בסדרת הניסויים הזו. זה לא אומר שכל מודל וידאו יתנהג תמיד באותו אופן.

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

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

<Tally
ariaLabel="התנועה שמאלה הצליחה שלוש פעמים מתוך שלוש. התנועה ימינה הצליחה פעם אחת מתוך שלוש."
rows={[
{ label: 'שמאלה', passed: 3, total: 3 },
{ label: 'ימינה', passed: 1, total: 3 },
]}
/>

התנועה שמאלה הצליחה שלוש פעמים מתוך שלוש. התנועה ימינה הצליחה פעם אחת מתוך שלוש. הדפוס נשמר לאורך 12 ניסיונות ימינה, בארבעה ניסוחים שונים.

המסקנה נראתה מובנת מאליה: למודל יש הטיה שמאלה. אפילו הקצינו לזה תקציב נוסף של 240 קרדיטים. **טעינו.**

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

זה הפך לאחד הלקחים החשובים ביותר בפרויקט:

<Lesson label="לקח">
דפוס כשל עקבי לא בהכרח מגלה משהו על המודל. לפעמים הוא מגלה משהו על הניסוח שלכם.
</Lesson>

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

1. מה המצלמה עושה פיזית.
2. מה נשאר קבוע.
3. איך אלמנטים קרובים ורחוקים צריכים לזוז זה ביחס לזה.
4. איך נקודת המבט הסופית צריכה להיראות.
5. אילו תנועות לא רצויות אסור שיקרו.

כך נראה הפרומפט שאושר, משפט אחד לכל אחד מחמשת הדברים:

| חלק | המשפט בפרומפט המאושר של Arc ימינה |
| --- | --- |
| **1. תנועה** | `The camera slowly moves sideways to the right while curving around the subject, continuously turning toward the subject to keep the same centered framing.` (המצלמה נעה לאט הצידה ימינה תוך כדי עיקול סביב הנושא, ופונה כל הזמן אל הנושא כדי לשמור על אותו מסגור ממורכז.) |
| **2. קבוע** | `The camera maintains constant distance from the subject.` (המצלמה שומרת על מרחק קבוע מהנושא.) |
| **3. עומק** | `As the viewpoint changes, strong natural parallax is visible: nearby environmental elements shift right noticeably while distant background elements shift right more slowly.` (ככל שנקודת המבט משתנה, נראית פרלקסה טבעית וחזקה: אלמנטים קרובים בסביבה זזים ימינה באופן בולט, ואלמנטים רחוקים ברקע זזים ימינה לאט יותר.) |
| **4. מצב סיום** | `The shot ends from a slightly different three-quarter viewing angle.` (השוט מסתיים מזווית צפייה שונה מעט, של שלושה רבעים.) |
| **5. מעקה בטיחות** | `No zoom, no push-in, no pull-out.` (בלי זום, בלי התקרבות, בלי התרחקות.) |

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

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

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

Comparison: Arc ימינה, לפני ואחרי, מאותה תמונת בסיס.
- Before: [Arc ימינה בניסוח הישן: המצלמה נעה בקשת לכיוון הלא נכון. ניסוח שמסתפק בשם התנועה, טייק 1 מתוך 12. ביקשנו קשת ימינה, והמצלמה הלכה שמאלה](https://nodaro.ai/docs-media/research/camera-motion-lab/arc-before.mp4)
- After: [Arc ימינה בניסוח הגאומטרי: קשת נקייה ימינה. ניסוח גאומטרי, טייק ראשון](https://nodaro.ai/docs-media/research/camera-motion-lab/arc-after.mp4)

## איך יודעים אם המצלמה באמת זזה?
ההבדל בין התנועה של עצמים קרובים לתנועה של עצמים רחוקים הפך לאחד מכלי האבחון השימושיים ביותר שלנו.

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

כך קיבלנו סיווג שימושי:

| תנועה | מה המצלמה עושה | מה אמורים לראות |
| --- | --- | --- |
| **הקפה, דולי, טראק, פדסטל, מנוף** | נעה במרחב | שינוי ברור ביחס בין אלמנטים קרובים לרחוקים |
| **פאן, טילט, רול** | מסתובבת במקום | הפריים זז, אבל בלי אותו שינוי בעומק |
| **זום** | לא זזה | הפרספקטיבה נשארת קבועה, כאילו אותה תמונה הוגדלה או הוקטנה |
| **Dolly Zoom** | נעה, ובאותו זמן אורך המוקד משתנה | מבחן אחר, שקשה לזייף, ומופיע בהמשך |

ב-Dolly Zoom, זה המבחן שכתבנו בפרומפט:

```
הנושא אף פעם לא משנה את הגודל שלו.
```

הפרומפט המקורי באנגלית:

```
THE SUBJECT NEVER CHANGES SIZE.
```

המקור באנגלית כתוב באותיות גדולות, בדיוק כמו בפרומפט המאושר.

## הקפת ה-360 שנכשלה חמש פעמים
הקפה מלאה סביב הנושא הייתה אחד המקרים הקשים ביותר בתחילת המחקר. הניסוח המקורי אפילו לא התקרב לזה.

ניסינו `180 degrees` (180 מעלות), וקיבלנו משהו קרוב יותר להקפה מלאה, בכיוון הלא נכון. ניסינו:

```
כל הדרך מסביב … וחוזרת לנקודה שבה התחילה
```

הפרומפט המקורי באנגלית:

```
all the way around ... returning to where it started
```

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

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

```
כל חלק בסביבה עובר בתורו מאחורי הנושא
```

הפרומפט המקורי באנגלית:

```
every part of the surroundings passes behind the subject in turn
```

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

```
בלי היפוך כיוון
```

הפרומפט המקורי באנגלית:

```
no reversal of direction
```

הניסוח החדש עבר כבר בטייק הראשון.

Comparison: ניסיון הקפת 360 שנכשל, לצד הקפת ה-360 שאושרה.
- Before: [הקפה מלאה בניסוח המקורי של הקטלוג: רחוק מהקפה שלמה. הניסוח המקורי של הקטלוג. רחוק מהקפה מלאה](https://nodaro.ai/docs-media/research/camera-motion-lab/orbit360-before.mp4)
- After: [הקפה מלאה, כשהמסלול מתואר כרצף של מצבים: הקפה שלמה. המסלול כרצף של מצבים, ועוד המבחן שקשה לזייף. טייק ראשון](https://nodaro.ai/docs-media/research/camera-motion-lab/orbit360-after.mp4)

## לפעמים בקשה ל״יותר״ נותנת פחות
בשלב אחר ניסינו להאריך את המסלול בעזרת הביטוי:

```
נעה דרך ארוכה מסביב
```

הפרומפט המקורי באנגלית:

```
travelling a long way around
```

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

<OrbitClock
start={6}
ariaLabel="מיקומי ההקפה על לוח שעון: ההתחלה ב-6, הפרומפט עם הביטוי נעצר ליד 5, והפרומפט בלעדיו הגיע ל-4."
runs={[
{ label: 'עם "travelling a long way around" (נעה דרך ארוכה מסביב): נעצרה ליד 5.', end: 5, highlight: true },
{ label: 'בלעדיו: המשיכה עד 4 בערך.', end: 4 },
]}
note="שתי ההרצות התחילו ב-6, מול הנושא."
/>

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

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

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

<Rule label="כלל עבודה">
אם התנועה הנכונה מסתיימת ואז מתחילה לחזור לאחור, בדקו קודם אם הקליפ צריך להיות קצר יותר. אל תמהרו לכתוב את הפרומפט מחדש.
</Rule>

יש חריג חשוב: האפשרויות מצלמה נושמת ו-Push-Pull / נדנוד. בשתיהן, התנועה החוזרת פנימה והחוצה היא התנועה עצמה. בהן הארכנו את הקליפ ל-10 שניות, כדי שלחזרה יהיה מספיק זמן להיראות בבירור.

## לבקש את המראה של המהירות
גם מילים כמו "fast" (מהר) או "slow" (לאט) לבדן לא נתנו לנו מספיק שליטה. מה שעבד טוב יותר היה לתאר את ההשפעה הנראית לעין של המהירות. למשל, ב-Whip Pan כתבנו:

```
כל הפריים נמרח לטשטוש תנועה אופקי וכבד
```

הפרומפט המקורי באנגלית:

```
the whole frame smears into heavy horizontal motion blur
```

ב-Creep-In עשינו כמעט את ההפך:

```
התמונה נשארת חדה לגמרי, בלי שום טשטוש תנועה
```

הפרומפט המקורי באנגלית:

```
the picture stays completely sharp with no motion blur at all
```

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

<BarChart
title="אורך הקליפ לכל אפשרות"
ariaLabel="משך הקליפ לכל אפשרות: Creep-In: 10 שניות, Dolly In: 7 שניות, Push In: 4 שניות."
max={10}
rows={[
{ label: 'Creep-In', note: 'האיטי ביותר', value: 10, display: '10 שנ׳' },
{ label: 'Dolly In', note: 'יציב', value: 7, display: '7 שנ׳' },
{ label: 'Push In', note: 'המהיר ביותר', value: 4, display: '4 שנ׳' },
]}
/>

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

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

הרצנו שלושה טייקים עם:

```
בלי זום, בלי התקרבות
```

הפרומפט המקורי באנגלית:

```
no zoom, no push-in
```

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

```
המצלמה שומרת על מרחק קבוע מהנושא.
```

הפרומפט המקורי באנגלית:

```
The camera maintains constant distance from the subject.
```

ורק אחר כך להוסיף:

```
בלי זום, בלי התקרבות, בלי התרחקות.
```

הפרומפט המקורי באנגלית:

```
No zoom, no push-in, no pull-out.
```

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

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

- **Pedestal למעלה.** כתבנו `rock strata ... descend into view` (שכבות הסלע … יורדות אל תוך התמונה). המודל לא רק שינה את נקודת המבט: הוא גרם לסלעים עצמם ליפול ולהיערם בסוף הקליפ. המשפט ציין עצם מסוים בסצנה וקשר את הפעולה כלפי מטה לעצם, במקום למצלמה.
- **Dolly Zoom.** השתמשנו במילים כמו `bend` (להתעקם) ו-`dizzying` (מסחרר). במקום למתוח את העומק, הפריים עשה רול של כ-90 מעלות. המודל ראה במילים שנבחרו כדי לתאר תחושה בקשה לרול.
- **Screen Tap.** הביטוי `finger tap` (הקשה באצבע) גרם למודל לצייר אצבע אמיתית בתוך הסצנה, כולל צליל נקישה.
- **היפוך טלפון.** המילה `rotates` (מסתובב) הפכה לסיבוב חלק ורציף, כמו של קרוסלה, במקום היפוך מהיר אחד.

<Rule label="כלל עבודה">
השתמשו רק במילים ששייכות לתנועה שאתם באמת רוצים, ושמרו במפורש על הצירים שלא אמורים להשתנות.
</Rule>

למשל, ב-Dolly Zoom:

```
הפריים נשאר זקוף ומפולס לגמרי לאורך כל השוט.
```

הפרומפט המקורי באנגלית:

```
The frame stays perfectly upright and level throughout.
```

Comparison: Dolly Zoom שעושה רול של כ-90 מעלות, לצד התוצאה שאושרה.
- Before: [Dolly Zoom, טייק ראשון: הפריים עושה רול הצידה. טייק 1, עם "bend" (להתעקם) ו-"dizzying" (מסחרר). הפריים עשה רול של כ-90 מעלות](https://nodaro.ai/docs-media/research/camera-motion-lab/dollyzoom-before.mp4)
- After: [Dolly Zoom, טייק שני: העומק נמתח והפריים נשאר מפולס. טייק 2. ניסוח שעוסק רק בעומק, והפריים נשאר מפולס](https://nodaro.ai/docs-media/research/camera-motion-lab/dollyzoom-after.mp4)

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

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

מצד שני, גם יותר מדי הפשטה יכולה להזיק. ב-Truck ניסינו להחליף את `new elements keep entering from the left edge` (אלמנטים חדשים ממשיכים להיכנס מהקצה השמאלי) בניסוח מופשט יותר. הניסיון נכשל. המילה `elements` (אלמנטים) לא מצביעה על שום תוכן מסוים בסצנה, ולכן החזרנו את הניסוח המקורי.

<Rule label="כלל עבודה">
אפשר לתאר את ההתנהגות של אלמנטים ושל שכבות עומק. אל תזכירו בשם עצמים שאולי לא יהיו בסצנה הבאה.
</Rule>

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

אבל זה יצר מלכודת נוספת. כתבנו:

```
דולי על גלגלים שנוסע לאורך מסילה
```

הפרומפט המקורי באנגלית:

```
a wheeled dolly running along a track
```

המודל פשוט רינדר את המסילה בתוך השוט.

Comparison: מסילת הדולי מרונדרת בתוך השוט, לצד ה-Dolly In שאושר.
- Before: [Dolly In כשהציוד מוזכר בפרומפט: הדולי והמסילה מופיעים בשוט. הציוד מוזכר בפרומפט. המודל צייר את המסילה בתוך השוט](https://nodaro.ai/docs-media/research/camera-motion-lab/track-before.mp4)
- After: [ה-Dolly In שאושר, בלי אזכור של ציוד. Dolly In, בלי אזכור של ציוד](https://nodaro.ai/docs-media/research/camera-motion-lab/track-after.mp4)

<Rule label="כלל עבודה">
אם משתמשים בציוד כעוגן פיזי בפרומפט, ציינו ציוד שנמצא באופן טבעי מאחורי המצלמה ולא אמור להופיע בתוך הפריים.
</Rule>

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

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

### POV שלא הצליח להפוך ל-POV
בדקנו את האפשרות POV הליכה על תמונה של אדם שהולך ביער, וביקשנו מהמצלמה להפוך לנקודת המבט של אותו אדם. האדם נשאר בפריים.

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

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

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

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

Comparison: מעבר טיסה על תמונת הבסיס הישנה, מול תמונת הבסיס החדשה.
- בסיס ישן: [מעבר טיסה על תמונת הבסיס של העיר: המצלמה שוקעת לעבר הגגות. תמונת בסיס של עיר במבט החוצה ולמטה, וניסוח מחוזק. המצלמה עדיין שקעה](https://nodaro.ai/docs-media/research/camera-motion-lab/flyover-before.mp4)
- בסיס חדש: [מעבר טיסה על תמונת הבסיס בגובה שיוט: טיסה יציבה ומפולסת. תמונת בסיס מפולסת בגובה שיוט. טייק ראשון](https://nodaro.ai/docs-media/research/camera-motion-lab/flyover-after.mp4)

<Rule label="כלל עבודה">
אם אותו כשל חוזר גם אחרי שני תיקונים של הפרומפט, בדקו מה פריים הפתיחה מזמין את המודל לעשות, לפני שאתם כותבים אותו שוב.
</Rule>

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

<ImageGrid
items={[
{ src: '/docs-media/research/camera-motion-lab/base-terrace.webp', alt: 'מרפסת פתוחה בראש צוק, עם גבר בסוודר אדום, עמוד תאורה, ברוש ועמק נהר מאחור', title: 'מרפסת · הקפה, פאן, טילט', caption: 'מרפסת פתוחה עם כמה נקודות ציון חזותיות ומעקה קרוב, כך שקל לזהות שינויים בנקודת המבט.' },
{ src: '/docs-media/research/camera-motion-lab/base-fjord-pier.webp', alt: 'מזח ארוך של עמודים שמתרחקים לעבר נקודת מגוז בפיורד', title: 'מזח · זום', caption: 'עמודים שמתרחקים לעבר נקודת מגוז. אם המצלמה זזה במקום לעשות זום, היחסים בין שכבות העומק חשפו את זה מיד.' },
{ src: '/docs-media/research/camera-motion-lab/base-gorge-waterfall.webp', alt: 'נקיק גבוה עם מפל ושכבות סלע אופקיות זו על גבי זו', title: 'נקיק · פדסטל, מנוף', caption: 'שכבות סלע אופקיות, כמעט כמו סרגל אנכי.' },
{ src: '/docs-media/research/camera-motion-lab/base-library.webp', alt: 'מסדרון ארוך בספרייה, עם רצפה מעוטרת ומדפים שמתרחקים אל המרחק', title: 'ספרייה · דולי', caption: 'רצפה מעוטרת ואלמנטים בעומקים רבים. גם Creep עדין מאוד נשאר גלוי על הרצפה, כשעל המדפים כמעט אי אפשר היה להבחין בו.' },
]}
/>

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

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

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

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

<Rule label="נוהל">
קליפ יכול להיראות טוב ועדיין להיכשל בכמה דרכים בלתי תלויות בבת אחת.
</Rule>

## לא כל אפשרות היא באמת תנועת מצלמה
המחקר חשף גם בעיית סיווג. האפשרויות Match Cut Zoom, Velocity Edit, Screen Tap והיפוך טלפון הן לא תנועות מצלמה מסורתיות. הן קרובות יותר לאפקטים של עריכה או של מעבר.

למשל, ב-Screen Tap, ברגע שתיארנו את הפעולה הפיזית שמפעילה את האפקט, המודל רינדר את הפעולה הזו. הניסוח שהצליח תיאר במקום זה מה קורה לפריים כתוצאה מהמעבר. זה מרמז שמקומן של ארבע האפשרויות האלה אולי בין המעברים, ולא בין תנועות המצלמה; ראו את הבורר [מעבר](https://nodaro.ai/docs/nodes/creative-controls/transition).

Comparison: Screen Tap עם האצבע, לצד הגרסה שאושרה.
- Before: [Screen Tap בניסוח הישן: אצבע אמיתית נכנסת לשוט. ניסוח עם "finger tap" (הקשה באצבע). הופיעה אצבע אמיתית. בטלו את ההשתקה כדי לשמוע את הנקישה](https://nodaro.ai/docs-media/research/camera-motion-lab/screentap-before.mp4)
- After: [Screen Tap בניסוח שעוסק רק בפריים: חיתוך מהיר ונקי. ניסוח שעוסק רק בפריים, על תמונת בסיס בלי אדם](https://nodaro.ai/docs-media/research/camera-motion-lab/screentap-after.mp4)

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

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

<BarChart
title="טייקים לכל אפשרות שאושרה"
ariaLabel="טייקים לכל אפשרות שאושרה: הקפה וקשת 10.2, 59 האפשרויות האחרות כ-1.5."
max={12}
rows={[
{ label: 'הקפה וקשת', note: '5 אפשרויות · 51 טייקים', value: 10.2, display: '10.2' },
{ label: '59 האפשרויות האחרות', note: '91 טייקים', value: 1.5, display: '1.5', highlight: true },
]}
/>

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

<Rule label="נוהל">
לפני שכותבים משהו מחדש, בדקו את הניסוח הגנרי הקיים כמו שהוא, על תמונת בסיס מתאימה.
</Rule>

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

## 13 הכללים ששמרנו
1. אל תשתמשו במספרים כדי לתאר זווית, גודל תנועה או מהירות בתוך פרומפט התנועה. משך הקליפ הוא פרמטר נפרד.
2. השתמשו בכיוון ברור אחד לתנועת המצלמה. אפשר לתאר כמה נקודות ציון לאורך אותו מסלול, אבל אל תתנו הוראות כיוון סותרות.
3. הנושא יכול לשמש עוגן גאומטרי. מרחק, גודל הנושא ומסגור הם נקודות ייחוס לגיטימיות, אבל פרומפט התנועה לא אמור להכתיב לנושא מה לעשות או איך להתנהג.
4. אל תזכירו תוכן מסוים של הסצנה. ההוראה צריכה להישאר שמישה גם כשהתמונה משתנה.
5. השתמשו במילים ששייכות לתנועה שאתם מתכוונים אליה, ושמרו במפורש על הצירים שלא אמורים להשתנות.
6. הגדירו קודם, בניסוח חיובי, מה המצלמה צריכה לעשות. החרגות שליליות הן מעקה בטיחות נוסף, לא תחליף לתיאור התנועה הרצויה.
7. אל תתארו שכבת עומק אחת כאילו היא כמעט לא זזה. כדי להעביר עומק, תארו הבדל הדרגתי בתנועה בין אלמנטים קרובים לרחוקים.
8. באפשרויות מצלמת יד, Steadicam, Vlog במצלמת יד וסחיפה עדינה צריך לכתוב אם המצלמה נשארת במקום. אחרת, הרעידות או הנדנוד עלולים להפוך לתזוזה לא רצויה.
9. אם התנועה הנכונה מסתיימת ואז חוזרת לאחור, בדקו קודם את משך הקליפ. החריג הוא תנועות כמו מצלמה נושמת ו-Push-Pull / נדנוד, שבהן החזרה היא חלק מהתנועה.
10. כששתי אפשרויות חולקות את אותה גאומטריה, הבדילו ביניהן דרך האופי שלהן או דרך מבחן חזותי שקשה לזייף.
11. באפקטים של עריכה, תארו מה קורה לפריים, לא את הפעולה הפיזית שמפעילה את האפקט.
12. תמיד בדקו קודם את הניסוח הקיים. אם צריך לכתוב מחדש, שמרו על ניסוח גנרי ואל תתאימו אותו לתוכן של תמונת הבדיקה.
13. אם אותו כשל חוזר גם אחרי שני תיקונים של הפרומפט, הפסיקו לכתוב מחדש ובדקו את פריים הפתיחה.

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

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

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

## מה זה שינה במוצר
כל 64 האפשרויות שנבדקו בבורר [תנועת מצלמה](https://nodaro.ai/docs/nodes/creative-controls/camera-motion) משתמשות עכשיו בניסוח שאושר במעבדה. ארבע עשרה מהן שמרו על הניסוח המקורי, כי הוא כבר עבד. בדיקת רגרסיה מונעת עכשיו שינוי בטעות של ניסוח שאושר.

המחקר גם השאיר כמה שאלות פתוחות:

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

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

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

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

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

<Lesson label="בשורה אחת">
ככל שתיארנו טוב יותר את הפיזיקה, כך היינו צריכים לתאר פחות את הקולנוע.
</Lesson>

*מעבדת תנועת המצלמה, רשימות מחקר, ספטמבר 2026. כל קליפ בדף הזה הוא טייק אמיתי מהמחקר: הרצה מתמונה לווידאו ב-480p, לצד הטייק שהחליף אותו.*

## שאלות נפוצות

### איך גורמים למודל AI לווידאו להזיז את המצלמה כמו שרוצים?

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

### למה המצלמה בסרטון ה-AI שלי זזה בכיוון הלא נכון?

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

### האם מספרים כמו "180 degrees" (180 מעלות) עובדים בפרומפטים של תנועת מצלמה?

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

### האם פרומפטים שליליים מונעים תנועות מצלמה לא רצויות?

רק כמעקה בטיחות. "No zoom, no push-in" (בלי זום, בלי התקרבות) לבדו לא מנע התקרבות. מה שעבד טוב יותר: להגדיר קודם את ההתנהגות הרצויה, למשל "the camera maintains constant distance from the subject" (המצלמה שומרת על מרחק קבוע מהנושא), ורק אחריה להוסיף החרגות.

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

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