منشورك العمودي يفشل قبل أن يولد Higgsfield أي صورة

Error: Invalid values: aspect_ratio=4:5

فشل المنشور قبل أن يولد Higgsfield أي صورة.

أشارت رسالة الخطأ الكاملة إلى القيم المقبولة:

Error: Invalid values: aspect_ratio=4:5 (allowed: 1:1,4:3,3:4,16:9,9:16,3:2,2:3)
Hint: Run: hf model get gpt_image_2

استخدمت 4:5 لأنها الشكل العمودي المعتاد الذي توقعته لقطعة موجهة إلى شبكات التواصل. ويدعم Higgsfield هذه النسبة في أحد مسارات GPT Image 2.

لكنه لا يدعمها في المسار الذي كنت أستخدمه.

المسار هو الذي يحدد النسب المسموحة

كان الافتراض الخاطئ أن نسب الأبعاد تخص النموذج. فكلا الأمرين ينتهي بـgpt_image_2، فتعاملت مع قائمة النسب على أنها قدرة تشمل النموذج كله.

لكن النسب المقبولة كانت تتغير فعليا بحسب الأمر الفرعي.

كنت قد رأيت 4:5 في مسار تصوير المنتجات ونقلتها إلى التوليد المباشر. فرفضها الخادم قبل أن يضع الطلب في الطابور.

يسهل أن يفوت هذا لأن المسارين يستخدمان نموذج الصور نفسه. وقد يبدو توثيق تصوير المنتجات قائمة كاملة بما يقبله ذلك النموذج، لكنه قائمة خاصة بذلك المسار وحده.

النص المطبوع حدد المسار الذي أحتاج إليه

كان المنشور يحتوي على نص مطبوع. وهذا يعني أنني أحتاج إلى generate create، حيث أستطيع تقديم البرومبت المكتوب كاملا.

لم يكن مسار تصوير المنتجات يسمح لي بكتابة ذلك البرومبت. وتغيير المسار لمجرد الاحتفاظ بـ4:5 كان سيسلبني التحكم الذي يحتاج إليه المنشور.

كان الحل العملي هو 3:4.

هذه النسبة يقبلها generate create gpt_image_2. وتشغل تقريبا المساحة العمودية نفسها في الخلاصة، ولا تتطلب قصا.

أما في صورة منتج خالصة بلا نص مطبوع، فالاختيار مختلف. يمكن لتلك القطعة أن تستخدم:

product-photoshoot --mode lifestyle_scene

وفي هذا المسار تكون 4:5 صالحة.

إذن محتوى القطعة هو الذي يحدد المسار، والمسار هو الذي يحدد النسبة. أما البدء بالنسبة المرغوبة وإجبار كل قطعة على المرور بها فيقلب هذه العلاقة.

لم يستهلك الفشل أي رصيد

تحقق الخادم من نسبة الأبعاد قبل وضع التوليد في الطابور. لم تولد أي صورة، فكلف الطلب الفاشل صفرا من الرصيد.

لكن تكلفة الوقت قد تكبر بسرعة.

إذا أطلقت عشر قطع عمودية بالتوازي بالنسبة غير الصالحة نفسها، فقد تموت العشر كلها عند خطأ التحقق نفسه. لا توجد نتيجة إبداعية تراجعها، ولا تنوع في الإخفاقات. الدفعة تكرر المعامل غير المدعوم نفسه فحسب.

لهذا يجب أن يأتي هذا الفحص قبل التوليد المتوازي.

والخطأ نفسه يقدم تلميحا مباشرا:

hf model get gpt_image_2

قبل إطلاق أي دفعة، أستخدم JSON:

higgsfield model get gpt_image_2 --json

أفحص القيم المقبولة لمسار الأمر المحدد قبل إطلاق المجموعة. ولا أعتمد على النسبة التي استخدمتها في سير عمل آخر داخل Higgsfield، حتى لو تطابق اسم النموذج.

auto ليس مخرج طوارئ آمنا

يتفق هذا السلوك الخاص بكل مسار مع إخفاق آخر في نسبة الأبعاد داخل Higgsfield: فقد يفشل --aspect_ratio auto في nano_banana_2.

الدرس أوسع من الاختيار بين 4:5 و3:4. فقوائم القيم المسموحة لنسب الأبعاد خاصة بالمسار الذي يستقبلها. ولا تورث بشكل موثوق بين الأوامر لمجرد أنها تتشارك نموذجا أو تنتمي إلى المنصة نفسها.

في حالة المنشور، صرت أقرر بهذا الترتيب.

هل تتطلب الصورة نصا مطبوعا؟ إذا كان الجواب نعم، فهي تمر عبر التوليد المباشر بنسبة مدعومة هناك. وفي قطعة عمودية للخلاصة تكون تلك النسبة 3:4.

هل هي صورة منتج خالصة بلا نص مطبوع؟ إذا كان الجواب نعم، فيمكن لمسار تصوير المنتجات أن يستخدم 4:5.

قبل أي دفعة، أستعلم عن معلومات النموذج وأتأكد من النسبة في المسار الدقيق الذي أنوي استدعاءه.

القاعدة التي أعمل بها الآن

أتحقق من نسبة الأبعاد بحسب الأمر الفرعي، لا بحسب النموذج.

نجاح 4:5 في product-photoshoot create لا يقول شيئا عما إذا كان generate create gpt_image_2 سيقبلها. في المنشور العمودي الذي يحمل نصا مطبوعا أستخدم 3:4. وفي صورة المنتج بلا نص أستطيع استخدام مسار تصوير المنتجات والاحتفاظ بـ4:5.

قبل أن تطلق دفعتك العمودية التالية، شغل أمر فحص النموذج وقارن النسبة بقائمة التوليد المباشر. هذا الفحص لا يكلف شيئا، وقد يمنع فشل كل عنصر في الدفعة قبل التوليد.

---

كل حل في هذا المقال سبقه خطأ دفعت ثمنه. الأفضل أن يحدث في فيلمي لا في علامتك التجارية.