ملاحظة المؤلف: عند استخدام GPT Image 2.6 Sunburst لتوليد ملف GIF، تشير قيمة size إلى أبعاد الإطار الواحد، بينما يقع القيد الحقيقي على لوحة التجميع التي تتكوّن من جميع الإطارات. يفكّك هذا المقال هذه القواعد بندًا بندًا عبر الجداول، ويعرض الحدود القصوى للأبعاد المتاحة عند كل عدد من الإطارات.
يواجه كثير من المطوّرين، عند استخدام gpt-image-2.6-sunburst لإنشاء GIF لأول مرة، موقفًا مثل هذا: يضبطون size على 1024×1024 وعدد الإطارات على إطارين فقط، ومع ذلك تعيد الواجهة البرمجية الخطأ 400 مباشرة. السبب أن قواعد أبعاد GIF تختلف عن تلك الخاصة بالصور الثابتة. يقدّم هذا المقال «أبعاد الإطار الواحد → تخطيط لوحة التجميع → قيود لوحة التجميع» كطريقة تحويل من ثلاث خطوات، تساعدك على تحديد ما إذا كانت أي مجموعة من size وframe_count ستجتاز التحقق.
هذا ليس ترجمة مبسّطة لوصف المعاملات. القيم الحدّية في المقال مستمدة من نتائج قياس فعلية على مسار التحويل الرسمي بتاريخ 2026-11-09، وقد أُرفِق كل حدّ أقصى في الجداول بعملية حسابه كي تتمكّن من مراجعته بنفسك.
القيمة الأساسية: بعد قراءة المقال، ستتمكّن من اختيار أبعاد الإطار الواحد المناسبة بناءً على عدد الإطارات، وتجنّب أخطاء من نوع GIF frames exceed the total request pixel budget، ومعرفة كيف تختار بين 512×512 و768×768 و960×960.
نقاط أساسية حول أبعاد GIF في GPT Image 2.6 Sunburst
لنبدأ بجدول يوضح القواعد الأساسية المتعلقة بتوليد GIF، ثم نفصّل كل نقطة لاحقًا.
| النقطة | الشرح | تأثيرها عليك |
|---|---|---|
size هو أبعاد الإطار الواحد |
يشير size إلى عرض وارتفاع كل إطار، وليس أبعاد الفيلم النهائي |
ما يُتحقق منه فعليًا هو صورة التجميع (sprite sheet)، فلا يمكن التقدير بناءً على حجم الإطار الواحد |
| جميع الإطارات تشترك في صورة تجميع واحدة | يرسم النموذج كل إطار داخل نفس صورة sprite sheet أولًا، ثم يقطعها إلى GIF | كلما زاد عدد الإطارات، صغر الحجم المتاح لكل إطار |
| تخطيط صورة التجميع ثابت | من 2 إلى 8 إطارات يستخدم 4×2، و9 إطارات يستخدم 3×3، ومن 10 إلى 12 إطارًا يستخدم 4×3، ومن 13 إلى 16 إطارًا يستخدم 4×4 | إطاران و8 إطارات يشغلان نفس مساحة صورة التجميع |
| يجب أن يكون العرض والارتفاع من مضاعفات 16 | يمكن تمرير auto في size، أو WIDTHxHEIGHT بحيث يكون العرض والارتفاع من مضاعفات 16 |
القيم مثل 832 و816 و720 هي فقط القيم الصالحة |
| تجاوز الحد يعيد 400 | يكون param في رسالة الخطأ هو size |
عند مواجهة خطأ، افحص أولًا أبعاد صورة التجميع |
آلية توليد GIF عبر لوحة الإطارات في GPT Image 2.6
تتم عملية توليد GIF في GPT Image 2.6 Sunburst على خطوتين: أولاً تُرسم جميع الإطارات وفق شبكة ثابتة داخل صورة كبيرة واحدة، ثم تُقطّع تلك الصورة إلى إطارات منفردة وتُدمج في رسوم متحركة وفق frame_duration_ms. لذلك لا تُقاس قيود الحجم بالإطار الواحد، بل بطول ضلع لوحة التجميع، وإجمالي عدد البكسلات، ونسبة الضلع الطويل إلى القصير.
يُختار التخطيط حسب فئات عدد الإطارات، وليس بترتيب مضغوط بحسب العدد الفعلي للإطارات. فمثلاً عند ضبط frame_count على 2، يظل النظام يستخدم تخطيط 4×2. ويمكن إثبات ذلك بالمثال الوارد في المراجع: إطار واحد بدقة 2048×2048 مع إطارين فقط يتطلب لوحة تجميع بحجم 8192×4096. عند التقدير، استخدم دائمًا «عدد خلايا التخطيط»، وليس «عدد الإطارات الفعلي».
شرح المعلمات الأساسية لـ GIF في GPT Image 2.6
إلى جانب size، يمتلك GIF معلمتين خاصتين به: تتحكم frame_count في عدد الإطارات، وتتحكم frame_duration_ms في مدة عرض كل إطار. المدة الإجمالية تساوي عدد الإطارات مضروبًا في مدة الإطار. فمثلاً إطاران × 100ms = حلقة مدتها 0.2 ثانية.
| المعلمة | النطاق الرسمي والقيمة الافتراضية | الشرح التفصيلي |
|---|---|---|
frame_count |
2–16، الافتراضي 9 | كلما زاد عدد الإطارات، زاد عادةً وقت المعالجة والتكلفة؛ وإذا تجاوزت القيمة النطاق فلن يظهر خطأ، بل سيتم الرجوع إلى القيمة الافتراضية |
frame_duration_ms |
20–2000ms، الافتراضي 200ms | يُقرّب إلى أقرب مضاعف لـ 10ms؛ والتركيبة الافتراضية هي 9 إطارات × 200ms = 1.8 ثانية |
size |
auto أو WIDTHxHEIGHT |
يجب أن يكون العرض والارتفاع من مضاعفات 16، ويشير ذلك إلى حجم الإطار الواحد |
output_format |
اضبطه على "gif" |
تؤثر frame_count وframe_duration_ms في GIF فقط |
quality |
مثل low وغيرها |
يُنصح باستخدام low عند إجراء اختبارات منخفضة التكلفة |
يستحق سلوك تجاوز النطاق في frame_count انتباهًا خاصًا. عند تمرير 1 أو 17، لا تُرجع الواجهة الخطأ 400، بل تتجاهل frame_count وframe_duration_ms وترجع إلى الافتراضي: 9 إطارات و1.8 ثانية. أي أن الطلب يبدو «ناجحًا»، لكن النتيجة ليست ما تريده. في هذه الحالة، يجب التحقق من عدد الإطارات الفعلي بأداة بعد التوليد؛ والطريقة التفصيلية موجودة في قسم البدء السريع.
شرح تفصيلي لحدود أبعاد Sunburst GIF في GPT Image 2.6
هذا القسم هو محور المقال بأكمله. فبجمع قيود لوحة التجميع مع قواعد التخطيط، يمكن استنتاج الحد الأقصى للأبعاد عند كل مستوى من مستويات عدد الإطارات.
القيود الأربعة للوحة التجميع في GPT Image 2.6
| القيد | القيمة الحدية | التفسير |
|---|---|---|
| ضلع واحد في لوحة التجميع | ≤ 3840 | لا يمكن أن يتجاوز عرض لوحة التجميع وارتفاعها 3840 بكسل |
| الحد الأعلى لإجمالي بكسلات اللوحة | ≤ 8,294,400 | يساوي 3840×2160، أي كمية بكسلات صورة 4K واحدة |
| الحد الأدنى لإجمالي بكسلات اللوحة | ≥ حوالي 655,360 | في الاختبار العملي رُفض 589,824 ومرّ 665,856 |
| نسبة الضلع الطويل إلى القصير في اللوحة | ≤ 3:1 | اللوحة شديدة الاستطالة تُرفض |
| أبعاد الإطار | العرض والارتفاع من مضاعفات 16 | إذا لم يتحقق ذلك، لا يصلح كـ size صالح |
الحد الأعلى مفهوم نسبيًا. فالضلع الواحد 3840 وإجمالي البكسلات 8,294,400 بوابتان مستقلتان يجب تحقيقهما معًا. عندما يكون عدد الإطارات قليلًا، عادةً ما يصطدم عرض لوحة التجميع أولًا بحد الضلع الواحد؛ وعندما يكثر عدد الإطارات، ينفد إجمالي البكسلات عادةً أولًا.
الحد الأدنى كثيرًا ما يُغفل. القيمة المرفوضة 589,824 هي بالضبط 768×768، وتقابل 9 إطارات بإطار واحد 256×256 في لوحة 3×3. أما القيمة التي مرّت 665,856 فهي 816×816، وتقابل 9 إطارات بإطار 272×272. من ذلك نستنتج أن الإطار الصغير جدًا مع تخطيط قليل الخلايا قد يُرفض أيضًا لأن اللوحة صغيرة جدًا. مثلًا، تخطيط 4×2 مع إطار 256×256 ينتج لوحة 1024×512 فقط، بإجمالي 524,288 بكسل، وهو أقل من الحد الأدنى. لذلك فإن طريق “تصغير الأبعاد لتوفير التكلفة” له أيضًا حد أدنى.
أما تأثير نسبة الضلع الطويل إلى القصير فيظهر بوضوح أكبر في الإطارات غير المربعة. بحسب تخطيط 4×2، عندما يكون الإطار بنسبة 16:9، تكون نسبة عرض لوحة التجميع إلى ارتفاعها نحو 3.56:1، أي تتجاوز 3:1؛ وبالانتقال إلى تخطيط 3×3 أو 4×4 تنخفض النسبة. هذه النقطة مستنتجة من القواعد، ويُنصح بالتحقق منها عمليًا قبل الإطلاق.
الحد الأقصى للإطار المربّع الواحد في GPT Image 2.6 حسب عدد الإطارات
حُسبت الحدود أدناه وفق «إطار مربّع واحد + عرض وارتفاع من مضاعفات 16»، ويمكن الرجوع إليها مباشرة.
| عدد الإطارات | التخطيط | الحد الأقصى للإطار المربّع الواحد | طريقة الاحتساب |
|---|---|---|---|
| 2–8 | 4×2 | 960×960 | مقيّد بحدّ الضلع الواحد: 4×960 = 3840؛ إجمالي البكسلات 7,372,800، ضمن الميزانية |
| 9 | 3×3 | 960×960 | 9×960² = 8,294,400، يستخدم الميزانية كاملةً |
| 10–12 | 4×3 | 816×816 | 12×832² = 8,306,688، يُرفض لتجاوزه 12,288 بكسل، فيُخفَّض إلى 816 |
| 13–16 | 4×4 | 720×720 | 16×720² = 8,294,400، يستخدم الميزانية كاملةً |
هناك تفصيلان تجدر الإشارة إليهما.
- تُحتسب الإطارات 10–12 على أساس 12 خانة: التخطيط هو 4×3، وحتى لو كانت هناك 10 إطارات فقط، فإن الصورة المجمّعة تشغل بكسلات 12 خانة. في الاختبار الفعلي، رُفضت 12 إطارًا بحجم 832² لمجرد تجاوزها 12,288 بكسل، ما يؤكد أن الميزانية تُطبّق بصرامة.
- الإطارات 2–8 مقيّدة بحدّ الضلع الواحد: لا يزال لدى هذه الفئة هامش في إجمالي البكسلات، لكن عرض الصورة المجمّعة يبلغ 4 أضعاف عرض الإطار الواحد، لذا فإن 960 هو الحد الأقصى بالفعل. ولو استخدمنا 1024 فسيصبح عرض الصورة المجمّعة 4096.
كيف تختار الأحجام الشائعة في GPT Image 2.6
إذا حوّلنا الحدود القصوى المذكورة أعلاه إلى اختيارات عملية، يمكننا الوصول إلى الاستنتاجات التالية:
| حجم الإطار الواحد | عدد الإطارات المتاحة | مثال تجميع الإطارات | التوصية بالاستخدام |
|---|---|---|---|
| 512×512 | كل الإطارات من 2 إلى 16 متاحة | عند 16 إطارًا: 2048×2048 | الخيار الأكثر استقرارًا، مناسب لملصقات الدردشة وتحريك الأيقونات والتوليد بالدفعات |
| 768×768 | بحد أقصى 12 إطارًا | عند 12 إطارًا: 3072×2304 | عند 16 إطارًا يصبح التجميع 3072×3072 = 9,437,184، وهو يتجاوز الميزانية |
| 960×960 | بحد أقصى 9 إطارات | عند 9 إطارات: 2880×2880 | يُستخدم عند الحاجة إلى صورة كبيرة مع عدد قليل من الإطارات |
| 1280×720 | 9 إطارات | 3840×2160 | خيار الصورة العريضة، إذ يستهلك التجميع حد الضلع والميزانية بالكامل |
| 1024×1024 | غير متاح مع أي عدد من الإطارات | عند 2–8 إطارات يكون العرض 4096 | عند 9 إطارات يتجاوز الميزانية، وبقية الأعداد تتجاوز حد الضلع |
| 2048×2048 | غير متاح مع أي عدد من الإطارات | عند إطارين: 8192×4096 | يتجاوز جميع الحدود بكثير |
حجم 1024×1024 شائع في الصور الثابتة، لكنه غير قابل للاستخدام إطلاقًا في GIF. عند 2–8 إطارات و10–12 إطارًا، يكون عرض التجميع 4096، أي أكثر من 3840؛ وعند 9 إطارات يكون التجميع 3072×3072، بإجمالي بكسلات 9,437,184، وهو يتجاوز الميزانية؛ وعند 13–16 إطارًا يكون عرض التجميع أيضًا 4096. لذلك، عند الانتقال من الصور الثابتة إلى GIF، أول شيء يجب فعله هو تصغير الحجم الافتراضي.
إذا كنت بحاجة إلى صورة أفقية، نوصي باستخدام 9 إطارات مع 1280×720. في هذه الحالة يكون التجميع بتخطيط 3×3، أي 3840×2160 بالضبط، ونسبة الضلع الطويل إلى القصير 16:9، وبذلك تتحقق القيود الثلاثة جميعها.
💡 توصية الاختيار: الحدود القصوى للأحجام هي نتيجة حساب وفق القواعد، وقد يعدّل مزوّد النموذج الميزانية. قبل الإطلاق، نوصي بتشغيل مجموعة من اختبارات الحدود على APIYI apiyi.com باستخدام
quality: "low"، لتتأكد بأقل تكلفة من تركيبات الأحجام التي تستخدمها كثيرًا.
البدء السريع مع GPT Image 2.6 Sunburst GIF
مثال مبسّط لـ GPT Image 2.6 GIF
فيما يلي المثال منخفض التكلفة الوارد في المواد المرجعية: إطاران، مدة كل إطار 100ms، والزمن الإجمالي 0.2 ثانية، لتوليد حركة دورية لدائرة صفراء تتحرك إلى اليمين قليلاً ثم تعود إلى موضعها الأصلي. الحقول مثل frame_count خاصة بملفات GIF، وهنا نستخدم requests مباشرةً لإرسال JSON، وهي الطريقة الأكثر وضوحًا.
import base64, requests
resp = requests.post(
"https://api.apiyi.com/v1/images/generations",
headers={"Authorization": "Bearer YOUR_API_KEY"},
json={
"model": "gpt-image-2.6-sunburst",
"prompt": "A minimal two-frame looping animation of a yellow circle moving slightly right and returning to its starting position on a plain white background, no text, seamless loop.",
"output_format": "gif",
"quality": "low",
"size": "512x512",
"frame_count": 2,
"frame_duration_ms": 100,
"n": 1,
},
timeout=300,
)
resp.raise_for_status()
open("circle.gif", "wb").write(base64.b64decode(resp.json()["data"][0]["b64_json"]))
عند كتابة الموجه، احرص على وصف ثلاثة أمور بوضوح: ما هو العنصر الرئيسي، وكيف يتحرك، وكيف تتكرر الحركة دوريًا. فالعبارات مثل «العودة إلى موضع البداية» أو «seamless loop» تجعل انتقال الإطار الأول إلى الإطار الأخير أكثر سلاسة وطبيعية.
الفحص المسبق لأحجام GIF في GPT Image 2.6 مع التنفيذ الكامل
في بيئة الإنتاج، يُفضّل إجراء فحص مسبق محلي قبل إرسال الطلب، حتى تعترض الأحجام غير الصالحة مبكرًا وتوفّر رحلة ذهاب وإياب كاملة بسبب خطأ 400. يحوّل الكود التالي جدول التخطيطات والقيود الواردة في هذا المقال إلى دوال، وهو يدعم في الوقت نفسه واجهة التوليد وواجهة التحرير.
عرض كود التنفيذ الكامل (مع الفحص المسبق للأحجام)
import base64
import requests
from typing import Optional
API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.apiyi.com/v1" # واجهة APIYI المتوافقة مع OpenAI
MAX_EDGE = 3840
MAX_PIXELS = 8_294_400 # 3840 x 2160
MIN_PIXELS = 655_360 # قريب من الحد الأدنى المقاس فعليًا، للتنبيه فقط
MAX_RATIO = 3.0
def sheet_layout(frame_count: int) -> tuple[int, int]:
"""يعيد تخطيط الشبكة الثابت (الأعمدة، الصفوف) وفقًا لعدد الإطارات"""
if 2 <= frame_count <= 8:
return 4, 2
if frame_count == 9:
return 3, 3
if 10 <= frame_count <= 12:
return 4, 3
if 13 <= frame_count <= 16:
return 4, 4
raise ValueError("frame_count 必须在 2-16 之间，否则会被静默回退到 9 帧")
def check_gif_size(width: int, height: int, frame_count: int) -> list[str]:
"""يعيد قائمة بالمشكلات، والقائمة الفارغة تعني نجاح الفحص المسبق"""
issues = []
if width % 16 or height % 16:
issues.append("宽高必须是 16 的倍数")
cols, rows = sheet_layout(frame_count)
sw, sh = cols * width, rows * height
total = sw * sh
if max(sw, sh) > MAX_EDGE:
issues.append(f"拼图 {sw}x{sh} 单边超过 {MAX_EDGE}")
if total > MAX_PIXELS:
issues.append(f"拼图总像素 {total:,} 超过 {MAX_PIXELS:,}")
if total < MIN_PIXELS:
issues.append(f"拼图总像素 {total:,} 低于约 {MIN_PIXELS:,}，可能被拒")
if max(sw, sh) / min(sw, sh) > MAX_RATIO:
issues.append(f"拼图长短边比 {max(sw, sh) / min(sw, sh):.2f} 超过 3:1")
return issues
def create_gif(
prompt: str,
size: str = "512x512",
frame_count: int = 9,
frame_duration_ms: int = 200,
quality: str = "low",
image_url: Optional[str] = None,
out_path: str = "output.gif",
) -> str:
w, h = map(int, size.lower().split("x"))
problems = check_gif_size(w, h, frame_count)
if problems:
raise ValueError("尺寸预检未通过: " + "; ".join(problems))
payload = {
"model": "gpt-image-2.6-sunburst",
"prompt": prompt,
"output_format": "gif",
"quality": quality,
"size": size,
"frame_count": frame_count,
"frame_duration_ms": frame_duration_ms,
"n": 1,
}
endpoint = "images/generations"
if image_url: # واجهة التحرير: الصورة الأولى تُستخدم كموضوع للحركة
endpoint = "images/edits"
payload["images"] = [{"image_url": image_url}]
resp = requests.post(
f"{BASE_URL}/{endpoint}",
headers={"Authorization": f"Bearer {API_KEY}"},
json=payload,
timeout=600,
)
if resp.status_code == 400:
raise RuntimeError(f"参数被拒（多为 size 超界）: {resp.text}")
resp.raise_for_status()
item = resp.json()["data"][0]
if item.get("b64_json"):
data = base64.b64decode(item["b64_json"])
else:
data = requests.get(item["url"], timeout=120).content
with open(out_path, "wb") as f:
f.write(data)
return out_path
if __name__ == "__main__":
print(check_gif_size(768, 768, 16)) # المتوقع: إجمالي البكسلات يتجاوز الميزانية
print(check_gif_size(1280, 720, 9)) # المتوقع: [] أي اجتياز
create_gif(
prompt="让这只猫跳一小段舞，纯色背景，固定镜头，最后一个动作回到起始姿势",
size="512x512",
frame_count=16,
frame_duration_ms=100,
image_url="https://example.com/cat.png",
out_path="cat_dance.gif",
)
التحقق من العدد الفعلي لإطارات GIF في GPT Image 2.6 باستخدام ffprobe
عندما تتجاوز قيمة frame_count الحد المسموح، يعود النظام بصمت إلى 9 إطارات. لذلك يُفضّل في المهام المجمّعة إضافة خطوة للتحقق من العدد الفعلي للإطارات:
ffprobe -v error -count_frames -select_streams v:0 \
-show_entries stream=nb_read_frames -of csv=p=0 circle.gif
في المثال البسيط جدًا، يجب أن يكون الناتج 2. أما إذا كان الناتج 9، فهذا يعني أن معامل عدد الإطارات لم يُطبّق، ويجب التحقق مما إذا كانت القيمة المُمرّرة تقع بين 2 و16.
القيود الوظيفية لـ GIF في GPT Image 2.6
لا يدعم وضع GIF القدرات التالية، لذا لا تُضمّنها في الطلب:
streamللإخراج المتدفق والمعاينة التدريجية للصور الجزئية (partial images)- تخصيص
output_compression prompt_rewriter
بالإضافة إلى ذلك، يُستخدم frame_count و frame_duration_ms مع GIF فقط، فلا تمررهما في طلبات PNG أو JPEG أو WebP أو SVG.
🚀 بداية سريعة: ننصح بالتسجيل في APIYI عبر apiyi.com والاستفادة من رصيد الاختبار المجاني المخصص للمستخدمين الجدد. ابدأ بتشغيل سير العمل كاملاً بإعدادات 512×512 وعدد إطارات 2 و
quality: "low"، ثم زد عدد الإطارات والأبعاد تدريجيًا. توفر المنصة واجهة متوافقة مع OpenAI، ويكفي مفتاح API واحد لاستدعاء GPT Image وغيره من النماذج الشائعة.
الأسئلة الشائعة FAQ
س1: عند توليد GIF باستخدام GPT Image 2.6 Sunburst، ماذا يعني الحقل `size`؟
`size` هو أبعاد كل إطار على حدة، وليس أبعاد لوحة الصور المجمّعة النهائية. عند التحقق الفعلي، يختار النظام التخطيط بناءً على عدد الإطارات، ثم يحسب عرض اللوحة وارتفاعها وإجمالي البكسلات، ويقارنها بعد ذلك بالقيود التالية: 3840 للضلع الواحد، و8,294,400 بكسل إجمالي، ونسبة 3:1.
س2: لماذا لا يمكن توليد أي إطار واحد بمقاس 1024×1024 في GIF الخاص بـ GPT Image 2.6؟
لأنه يتجاوز الحدود في أي تخطيط. ففي تخطيطات 4×2 و4×3 و4×4 يكون عرض اللوحة 4096، وهو أكبر من 3840؛ أما تخطيط 3×3 فينتج لوحة بمقاس 3072×3072، أي إجمالي 9,437,184 بكسل، وهو خارج الميزانية. رسالة الخطأ تكون عادةً: `No supported sheet fits … The longest edge must be less than or equal to 3840.` في هذه الحالة يكفي تغيير الإطار الواحد إلى 960×960 أو أصغر.
س3: لماذا لا يظهر خطأ عند تمرير 1 أو 17 إلى frame_count؟
في المسار الحالي، لا تُرجع قيمة `frame_count` الخارجة عن النطاق 2–16 الاستجابة 400. بل يقوم النظام بإسقاط كل من `frame_count` و`frame_duration_ms` معًا، ويرجع إلى القيم الافتراضية: 9 إطارات ومدة 1.8 ثانية. لذلك يُنصح بالتحقق من النطاق على جانب العميل، ثم مراجعة عدد الإطارات الفعلي باستخدام ffprobe بعد التوليد.
س4: عندما تكون n أكبر من 1، هل تتراكم ميزانية البكسلات في GPT Image 2.6؟
في المسار الحالي، تُتحقق كل صورة على حدة ولا تتراكم الميزانية. فقد نجح اختبار فعلي بـ 2 صورة × 16 إطارًا × 512² (بإجمالي 8,388,608). لكن الدليل الرسمي ينص على أن الصور المتعددة يجب أن تقع ضمن الميزانية نفسها، لذا في سيناريوهات الدفعات اعتمد على الاستجابة الفعلية، وقسّم الطلبات إلى عدة طلبات بـ `n=1` عند الحاجة.
س5: كيف يمكن توليد GIF عبر API باستخدام GPT Image 2.6 Sunburst بسرعة؟
نوصي بالخطوات التالية:
1. زُر APIYI على apiyi.com وسجّل حسابًا للحصول على مفتاح API وحصة تجربة مجانية
2. اضبط base_url في كود هذا المقال على `https://api.apiyi.com/v1`
3. تحقّق من المسار بمثال بسيط جدًا بمقاس 512×512 وإطارين و`quality: “low”`، ثم عدّل المعاملات وفق جدول المقاسات
س6: هل يستطيع GPT Image 2.6 توليد GIF بناءً على صورة موجودة؟
نعم. يدعم `/v1/images/edits` أيضًا `output_format: “gif”`، ضع الصورة المرجعية في الحقل `images`، وستكون الصورة الأولى هي موضوع الحركة، أما بقية المعاملات فهي مطابقة لواجهة التوليد، وقواعد المقاسات متطابقة تمامًا أيضًا. يُفضّل أن تكتب في الموجه عبارات مثل «كاميرا ثابتة» و«العمل الأخير يعود إلى وضعية البداية»، ليكون التكرار أكثر سلاسة.
س7: هل تتغير حدود المقاسات المذكورة في هذا المقال؟
هذا ممكن. وفق قياس فعلي على مسار التحويل الرسمي بتاريخ 2026-11-09، ميزانية الصورة المجمّعة هي: 8,294,400 تمرّ عند الحد الأقصى، بينما 12 إطارًا بمقاس 832² تُرفض. قد يعدّل الجانب الخاص بالنموذج هذه الحدود، والمرجع النهائي هو خطأ 400 الذي تعيده الواجهة. يُنصح بجعل الثوابت داخل دالة الفحص المسبق قابلة للتهيئة، ليسهل تحديثها في أي وقت.
الخلاصات الرئيسية حول أبعاد GIF في GPT Image 2.6 Sunburst
- size هو مقاس الإطار الواحد: ينطبق الحد على الصورة المجمّعة التي تشترك فيها كل الإطارات، وليس على الإطار الواحد
- التخطيط ثابت حسب الفئة: أربعة تخطيطات هي 4×2 و3×3 و4×3 و4×4، وتقابل على الترتيب 2–8 و9 و10–12 و13–16 إطارًا
- ثلاثة قيود صارمة: كل ضلع من أضلاع الصورة المجمّعة ≤ 3840، وإجمالي البكسلات ≤ 8,294,400، ونسبة الضلع الأطول إلى الضلع الأقصر ≤ 3:1
- المقاس الأكثر أمانًا هو 512×512: جميع الإطارات من 2 إلى 16 متاحة؛ و768² بحد أقصى 12 إطارًا، و960² بحد أقصى 9 إطارات
- 1024² غير صالح تمامًا: عند نقل إعدادات الصورة الثابتة، يجب تصغير المقاس أولاً
- عدد الإطارات خارج النطاق يؤدي إلى تراجع صامت: يُنصح بأن يتحقق العميل من النطاق، وبعد التوليد يتحقق من عدد الإطارات باستخدام ffprobe
- اختبار منخفض التكلفة: شغّل اختبارات الحدود على APIYI apiyi.com باستخدام
quality: "low"، فالتكلفة هي الأدنى
الملخص
قواعد أحجام GIF عند التوليد باستخدام GPT Image 2.6 Sunburst تقوم على ثلاث خطوات أساسية:
- حدِّد التخطيط أولاً: بناءً على
frame_count، اختر التخطيط المناسب: 4×2 أو 3×3 أو 4×3 أو 4×4 - احسب أبعاد الشبكة بعد ذلك: اضرب عرض وارتفاع الإطار الواحد في عدد الصفوف والأعمدة للحصول على عرض الشبكة وارتفاعها وإجمالي البكسلات
- تحقّق أخيرًا: افحص الحد الأدنى والأعلى للضلع الواحد والإجمالي، ونسبة الطول إلى العرض، وتأكد من أن العرض والارتفاع من مضاعفات 16
في الاستخدام اليومي، يُعدّ 512×512 القيمة الافتراضية الأكثر توافقًا؛ وعند الحاجة إلى صورة كبيرة، يمكن استخدام 9 إطارات مع 960×960 أو 1280×720 لاستغلال الميزانية كاملة. وبدمج دالة الفحص المسبق الواردة في هذا المقال داخل كود العمل، يمكنك اكتشاف معظم أخطاء 400 محليًا قبل إرسال الطلب.
نوصي بتجربة تركيبات الأحجام بسرعة عبر APIYI على apiyi.com؛ إذ توفر المنصة حصة اختبار مجانية وواجهة موحّدة متوافقة مع OpenAI، وهي مناسبة لإجراء اختبارات الحدود قبل الدمج الرسمي.
📚 المراجع
- مركز وثائق APIYI – التوليد الحلقي المتحرك لـ GIF عبر GPT Image 2.6: شرح المعاملات الرسمية وحدود القياس الفعلي
- الرابط:
docs.apiyi.com/api-capabilities/gpt-image-2/gpt-image-2-6 -
الوصف: يتضمن نطاقات معاملات GIF، وقيود الشبكة، وأمثلة الأخطاء، وطريقة استخدام واجهة التحرير
-
وثائق FFmpeg الرسمية – ffprobe: أداة لعرض البيانات الوصفية للصوت والفيديو وملفات GIF
- الرابط:
ffmpeg.org/ffprobe.html - الوصف: تُستخدم للتحقق من العدد الفعلي لإطارات GIF المولَّدة ومدة كل إطار
المؤلف: فريق APIYI التقني
التواصل التقني: إذا واجهت أي مشكلة في ضبط أحجام GIF، يسعدنا تواصلك معنا عبر الصفحة الرئيسية لموقع APIYI للحصول على مزيد من الدعم في عملية الدمج.
