ملاحظة المؤلف: خياراتا 2K/4K في gpt-image-2.6-all هما مستويان للدقة الفائقة (Super Resolution)، فقد لا تعيد الاستجابة حقل size، وقد تختلف الأبعاد الفعلية بالبكسل أحيانًا عن المتوقع. يشرح هذا المقال السبب، ويقدّم طريقة عملية: احفظ الصورة أولًا، ثم اقرأ عرضها وارتفاعها الحقيقيين، وبعدها ابدأ التنسيق.
يربط كثيرون واجهة توليد الصور بقوالب الملصقات أو الصور الرئيسية للمتاجر الإلكترونية أو خطوط إنتاج أغلفة الفيديو، ويقرؤون حقل size من الاستجابة مباشرةً ليحسبوا منه أبعاد اللوحة والتخطيط. مع مستويي 2K/4K في gpt-image-2.6-all هذا الأسلوب محفوف بالمخاطر. فقد ذكر وصف النموذج الذي نشرته APIYI (apiyi.com) بتاريخ 2026-11-11 أن 2K/4K مستويان للدقة الفائقة، وأن الاستجابة قد لا تعيد حقل size، وأن الأبعاد الفعلية بالبكسل قد تختلف عن المتوقع في بعض الحالات. المرجع في المقاس هو العرض والارتفاع الفعليان لملف الصورة، وهذا هو ما تنص عليه الوثائق.
هذه المشكلة تؤثر مباشرةً في نتيجة التنسيق. فإذا عوملت صورة بأبعاد 1365x2048 على أنها بنسبة 9:16 ووُضعت في قالب عمودي، فقد تظهر مساحات فارغة أو تمدد في الصورة، وقد يُقصّ العنصر الرئيسي.
الفائدة الأساسية: بعد قراءة المقال ستعرف لماذا لا يصح الاعتماد على حقول الاستجابة مع مستويي 2K/4K، وستتعلم كيف تقرأ البكسلات الحقيقية بعد حفظ الصورة ثم تمررها إلى منطق التنسيق.
النقاط الأساسية حول أحجام 2K/4K في gpt-image-2.6-all
يلخّص الجدول التالي المعلومات المتعلقة بالأحجام الواردة في الوثائق، وتعتمد عليها الشفرة البرمجية وخطط التنسيق التي سنستعرضها لاحقًا.
| النقطة | الشرح | التأثير على التنسيق |
|---|---|---|
| 2K/4K فئتان تعتمدان على رفع الدقة | يمرّ الملف النهائي بمعالجة رفع الدقة، وتحدّد هذه المرحلة عدد البكسلات | لا يمكن استنتاج الحجم النهائي من معاملات الطلب |
| قد لا يُعاد حقل size | قد لا يظهر حقل size في الاستجابة لفئتي 2K/4K | إذا اعتمدت الشفرة على هذا الحقل فستقرأ قيمة فارغة أو يحدث خطأ |
| انحراف عرضي في البكسلات | قد تظهر أحيانًا القيمة 1365x2048 مع نسبة 9:16، والقيمة 4096x2731 مع فئة 4K |
قد تختلف نسبة العرض إلى الارتفاع عن النسبة المطلوبة |
| اختلاف مع quality=low | قد تُنتج فئة 2K الحجم 2048x1153 |
ينتج طول ضلع فردي، وقد يتسبب ذلك بأخطاء في بعض مسارات ترميز الفيديو |
| العبرة بالعرض والارتفاع الفعليين | تنص الوثائق صراحةً على أن المرجع هو العرض والارتفاع الحقيقيان لملف الصورة | قراءة البكسلات بعد حفظ الصورة هي مصدر البيانات الوحيد الموثوق |
لماذا لا يمكن الاعتماد على حقل size في gpt-image-2.6-all عند الدقة 2K/4K
يمكنك تصوّر مستوى الدقة الفائقة (Super Resolution) على أنه خطوتان: يُولَّد أولًا صورة أساسية، ثم تُكبَّر إلى 2K أو 4K. وعدد وحدات البكسل في الملف النهائي تحدده مرحلة التكبير هذه، أما حقل size في بنية الاستجابة فلا يتزامن معها بالضرورة. وتصف الوثائق الرسمية الدقتين 2K/4K بعبارة “قد لا يُعاد حقل size”. ويعني هذا أن الشفرة نفسها قد تقرأ الحقل في مرة ولا تجده في مرة أخرى.
أما الحالة التي تسبب المشكلة فعلًا فهي أن يكون الحقل موجودًا لكنه لا يطابق الملف. لن تظهر أي رسالة خطأ، وستبدو القيمة طبيعية، ولن يُكتشف الخلل إلا بعد أن تخرج نتيجة التنسيق والتخطيط. لذلك فالأسلم ألا تعتمد على size مصدرًا للأبعاد، وأقصى ما يصلح له هو المقارنة في السجلات (logs). أما العرض والارتفاع المستخدمان في التنسيق فاقرأهما دائمًا من ملف الصورة المحفوظ نفسه.
تفسير الانحرافات المعروفة في أبعاد الصور عند 2K/4K مع gpt-image-2.6-all
يذكر التوثيق عدة حالات عرضية تختلف فيها أبعاد الصورة الناتجة عن المطلوب. يحوّل الجدول التالي هذه الأبعاد إلى نسب عرض إلى ارتفاع، حتى يسهل تقدير أثرها على التخطيط والتنسيق.
| الحالة | الأبعاد الفعلية المحتملة | نسبة العرض إلى الارتفاع | مخاطر التخطيط |
|---|---|---|---|
| نسبة 9:16 | 1365x2048 |
نحو 0.667، قريبة من 2:3 | عند وضعها في قالب 9:16 ستظهر فراغات على الجانبين أو سيُقتطع جزء من الصورة |
| فئة 4K | 4096x2731 |
نحو 1.5، قريبة من 3:2 | الضلع القصير لا يطابق المتوقع، وسيختل موضع الصورة في اللوحة الثابتة |
| فئة 2K مع quality=low | 2048x1153 |
نحو 1.776، قريبة من 16:9 | الارتفاع عدد فردي، وستفشل أي عملية ترميز تشترط أبعادًا زوجية |
يتضح من هذه الأمثلة أن الضلع الطويل يستقر عادةً عند 2048 أو 4096، أما الضلع القصير فغير ثابت. الانحراف في النسبة واضح جدًا في الحالة الأولى: نسبة 9:16 تساوي نحو 0.5625، بينما تبلغ نسبة 1365x2048 نحو 0.667. فإذا حسب الكود اللوحة بناءً على نسبة 9:16 المطلوبة، ستظهر الفراغات بشكل لافت. أما في الحالة الثالثة فالنسبة تكاد لا تتغير، لكن 1153 عدد فردي. وتشترط صيغ البكسل الشائعة في ترميز الفيديو أن يكون العرض والارتفاع زوجيين، لذا قد يظهر خطأ أثناء التحويل إذا استخدمت هذه الصورة غلافًا لفيديو أو إطارًا أول له.
هذه الحالات “عرضية”، فقد تجرّب عدة صور أثناء الاختبار دون أن تلاحظ شيئًا، ثم تواجهها بعد الإطلاق. لذلك ينبغي أن يكون منطق التحقق بعد كل عملية توليد، وألا يقتصر على فحص عينات أثناء الاختبار.
البدء السريع مع gpt-image-2.6-all بدقة 2K/4K: قراءة البكسلات الفعلية
الفكرة الأساسية في جملة واحدة: احصل على المحتوى الثنائي للصورة واحفظه أولًا، ثم اقرأ عرضها وارتفاعها بمكتبة معالجة صور. يستخدم المثال أدناه حزمة SDK لـ Python المتوافقة مع OpenAI، ومعها Pillow. أما الصيغة الدقيقة لمعاملات الطلب، مثل مستوى الدقة 2K/4K والنسبة، فارجع فيها إلى وثائق APIYI. تركنا لها في المثال أماكن محجوزة فقط.
مثال مختصر: مقارنة حقل size في الاستجابة بالبكسلات الفعلية
يولّد هذا الكود صورة، ثم يطبع حقل الاستجابة والبكسلات الفعلية معًا، لترى الفرق بينهما مباشرة.
import base64， io， requests
from openai import OpenAI
from PIL import Image
client = OpenAI（api_key="YOUR_API_KEY"， base_url="https://api.apiyi.com/v1"）
resp = client.images.generate（
model="gpt-image-2.6-all"，
prompt="一张竖版城市夜景海报"，
# عبّئ معاملات مستوى الدقة 2K/4K وفق وثائق APIYI
）
item = resp.data[0]
raw = base64.b64decode（item.b64_json） if item.b64_json else requests.get（item.url， timeout=120）.content
img = Image.open（io.BytesIO（raw））
print（"真实像素："， img.size） # (العرض، الارتفاع)
print（"响应 size:"， getattr（resp， "size"， None）） # قد يكون None عند دقة 2K/4K
استخدمنا getattr لقراءة size حتى لا يُرمى استثناء إذا كان الحقل غير موجود. ويدعم الكود حالتي الاستجابة، سواء أعادت رابط URL أو base64، فيعتمد المنطق اللاحق على المحتوى الثنائي للصورة فقط. وإذا كانت طريقة الربط عندك في الوثائق تمر عبر واجهة أخرى، فكل ما عليك هو استبدال خطوة «الحصول على محتوى الصورة». أما جزء قراءة البكسلات فلا يحتاج إلى أي تعديل.
التنفيذ الكامل: التحقق بعد الحفظ وتوليد معاملات التخطيط
في بيئة الإنتاج يفضَّل جمع الخطوات التالية في دالة واحدة: حفظ الملف، وقراءة العرض والارتفاع الفعليين، ومقارنتهما بحقول الاستجابة، وفحص انحراف النسبة والأبعاد الفردية، ثم حساب نتيجة التحجيم بناءً على الأبعاد الفعلية.
import base64
import io
from pathlib import Path
from uuid import uuid4
import requests
from openai import OpenAI
from PIL import Image
client = OpenAI（
api_key="YOUR_API_KEY"，
base_url="https://api.apiyi.com/v1",
）
# معاملات مستوى 2K/4K والنسب وغيرها تُؤخذ من وثائق APIYI، وهذا مجرد عنصر نائب
TIER_PARAMS = {}
def fetch_image_bytes（item） -> bytes:
if getattr（item， "b64_json"， None）:
return base64.b64decode（item.b64_json）
return requests.get（item.url， timeout=120）.content
def parse_declared_size（resp）:
size = getattr（resp， "size"， None）
if not size or "x" not in str（size）.lower（）:
return None
w， h = str（size）.lower（）.split（"x"）
return int（w）， int（h）
def generate_and_measure（prompt， expected_ratio=None， out_dir="outputs"）:
resp = client.images.generate（
model="gpt-image-2.6-all"，
prompt=prompt，
**TIER_PARAMS，
）
raw = fetch_image_bytes（resp.data[0]）
img = Image.open（io.BytesIO（raw））
width， height = img.size # المصدر الوحيد الموثوق للأبعاد
Path（out_dir）.mkdir（exist_ok=True）
ext = （img.format or "png"）.lower（）
path = Path（out_dir） / f"{uuid4（）.hex[:8]}_{width}x{height}.{ext}"
path.write_bytes（raw）
declared = parse_declared_size（resp）
report = {
"path": str（path），
"width": width，
"height": height，
"declared": declared，
"declared_match": （declared == （width， height）） if declared else None，
"odd_dimension": width % 2 == 1 or height % 2 == 1，
}
if expected_ratio:
real_ratio = width / height
report["ratio_drift"] = round（abs（real_ratio - expected_ratio） / expected_ratio， 4）
return report
def fit_into_box（width， height， box_w， box_h， mode="contain"）:
if mode == "contain":
scale = min（box_w / width， box_h / height）
else:
scale = max（box_w / width， box_h / height）
return round（width * scale）， round（height * scale）
if __name__ == "__main__":
r = generate_and_measure（"竖版城市夜景海报"， expected_ratio=9 / 16）
print（r）
if r.get（"ratio_drift"， 0） > 0.01:
print（"比例漂移超过 1%，建议改用 contain 或重新生成"）
print（fit_into_box（r["width"]， r["height"]， 1080， 1920））
في هذا التنفيذ ثلاث نقاط تصميمية تستحق التوضيح:
- إضافة العرض والارتفاع الفعليين إلى اسم الملف: لا تحتاج الخدمات اللاحقة إلى فك ترميز الصورة مرة أخرى، فيكفي أن تقرأ الأبعاد من اسم الملف.
- استخدام declared_match للسجلات فقط: يساعدك على إحصاء عدد المرات التي يغيب فيها الحقل أو يختلف عن الأبعاد الفعلية، لكنه لا يدخل في حسابات التخطيط.
- اكتشاف odd_dimension مبكرًا: الصورة التي أبعادها مثل
2048x1153يمكن قصّ بكسل واحد منها أو إضافته قبل دخولها إلى ترميز الفيديو.
🚀 نصيحة للبدء السريع: جرّب أولًا على منصة APIYI (apiyi.com) باستخدام مفتاح واحد لتشغيل الدقتين 2K و4K كلًا على حدة، ثم اطبع التقرير (report) الوارد أعلاه، ولاحظ مدى تكرار الحقول المفقودة وانحراف النسب في الواقع، وبعدها قرّر عتبات التسامح مع الأخطاء في بيئة الإنتاج. تعتمد المنصة واجهة متوافقة مع OpenAI، فيكفي أن تعدّل
base_urlفي الشيفرة النموذجية لتعمل.
خطة ضبط التخطيط لصور gpt-image-2.6-all بدقة 2K/4K
الحصول على الأبعاد الحقيقية بالبكسل ليس سوى الخطوة الأولى، أما الخطوة التالية فهي أن يعتمد منطق التخطيط بالكامل على هذه البيانات. لذلك سنقارن أولًا بين ثلاثة مصادر لمعلومات الحجم، لنحدد أيّها يصلح لاتخاذ القرار.
| مصدر المعلومات | الموثوقية | الأداء عند 2K/4K | الاستخدام الموصى به |
|---|---|---|---|
| الدقة والنسبة المختارتان عند الطلب | منخفضة | قد تنحرف البكسلات الفعلية بعد التكبير الفائق الدقة (super-resolution) | للتعبير عن التوقع، وكمرجع لقياس انحراف النسبة |
| حقل size في الاستجابة | منخفضة | قد لا يُعاد في الاستجابة، وقد لا يطابق الملف | يُكتب في السجل فقط لأغراض الإحصاء |
| العرض والارتفاع الحقيقيان لملف الصورة | عالية | تنص الوثائق صراحةً على اعتماده مرجعًا | المرجع الوحيد للتخطيط والقص والترميز |
قراءة الأبعاد الحقيقية (العرض والارتفاع) لصور gpt-image-2.6-all بدقة 2K/4K في مختلف المراحل
قد تُولَّد الصورة في الواجهة الخلفية، ثم تُعرض في الواجهة الأمامية، وأخيرًا تُسلَّم إلى أداة معالجة الفيديو. لكل مرحلة طريقتها الخاصة في قراءة البكسلات الحقيقية، فلا داعي لتمرير معلومات الأبعاد من مرحلة إلى أخرى.
| المرحلة | طريقة القراءة | ملاحظات |
|---|---|---|
| الواجهة الخلفية (Python) | Image.open(...).size من مكتبة Pillow |
تقرأ ترويسة الملف فقط للحصول على العرض والارتفاع، فتكلفتها قليلة |
| الواجهة الأمامية (المتصفح) | img.naturalWidth / img.naturalHeight |
اقرأهما بعد حدث onload، ولا تعتمد على الأبعاد التي يعرضها CSS |
| سطر الأوامر أو تحويل الترميز | ffprobe أو identify من ImageMagick |
تحقق في الوقت نفسه، قبل الترميز، من أن طولَي الضلعين زوجيان |
| التخزين الكائني | اكتب العرض والارتفاع في البيانات الوصفية أو في اسم الملف عند الرفع | تقرؤها الخدمات اللاحقة مباشرة دون الحاجة إلى فك ترميز الصورة مرة أخرى |
الواجهة الأمامية هي أكثر المراحل التي يقع فيها الخطأ. فكثير من المكونات تضبط عرضًا وارتفاعًا ثابتين للصورة، وعندها تحصل على أبعاد العرض لا على بكسلات الصورة نفسها. وللتأكد من أن الصورة الأصلية قريبة من نسبة 9:16، استخدم naturalWidth وnaturalHeight.
التعامل مع انحراف النسبة في gpt-image-2.6-all عند الدقة 2K/4K
لا يمكن إزالة انحراف النسبة تمامًا، لكن يمكنك أن تقرر مسبقًا كيف ستتعامل معه عند حدوثه. الاستراتيجيات الثلاث التالية مرتبة من الأقل مخاطرة إلى الأعلى.
| الاستراتيجية | الطريقة | السيناريو المناسب | الكلفة |
|---|---|---|---|
| ملاءمة contain | تحجيم الصورة بنسبة ثابتة وفق عرضها وارتفاعها الفعليين، بحيث تدخل كاملة في اللوحة | الملصقات وصفحات تفاصيل المنتجات، حيث لا يجوز قص العنصر الرئيسي | قد تظهر مساحات فارغة، فتحتاج إلى لون خلفية أو صورة خلفية ضبابية لملئها |
| قص cover | تكبير الصورة بنسبة ثابتة حتى تملأ اللوحة، ثم قص الجزء الزائد | الأغلفة واللافتات (Banner)، حيث لا تهم المعلومات عند الحواف | خطر قص العنصر الرئيسي إذا كان قريبًا من الحافة |
| إعادة المحاولة عند الانحراف | إعادة التوليد إذا تجاوز انحراف النسبة العتبة المحددة | القوالب التي تشترط نسبة دقيقة | تكلفة استدعاء إضافي ووقت انتظار أطول |
بالنسبة للأطوال الفردية، يُنصح بمعالجتها قبل الدخول في مرحلة الترميز: إما بقص بكسل واحد، أو بإضافة حافة بكسل واحد بلون موحد. فعند قص 2048x1153 إلى 2048x1152 تصبح النسبة 16:9 القياسية تمامًا، ولا يكاد يُلاحظ أي فرق بصري.
gpt-image-2.6-all: أسئلة شائعة حول دقة 2K/4K
Q1: ما المقصود بفئتَي 2K/4K في gpt-image-2.6-all؟
بحسب وصف النموذج الذي نشرته APIYI بتاريخ 2026-11-11، فإن 2K/4K هما فئتان تعتمدان على الدقة الفائقة (Super Resolution)، أي أن الصورة النهائية تمر بمعالجة رفع الدقة قبل إخراجها. وهذا هو سبب اختلاف سلوك الأبعاد فيهما عن الفئات العادية: فقد لا تُرجع الاستجابة قيمة size، وقد تنحرف الأبعاد الفعلية بالبكسل أحيانًا عن المتوقع.
Q2: في فئتَي 2K/4K، هل أثق بقيمة size في الاستجابة أم بالأبعاد الحقيقية للملف؟
ثق بالملف. تنص الوثائق صراحةً على أن المرجع هو العرض والارتفاع الفعليان للصورة. قد تغيب قيمة size من الاستجابة في هاتين الفئتين، وحتى إن وُجدت فالأفضل الاكتفاء بتسجيلها في السجلات، ولا تعتمد عليها في حساب اللوحة أو مناطق القص أو معاملات الترميز.
Q3: ما الأبعاد المعروفة التي قد تخالف المتوقع؟
تذكر الوثائق الحالات التالية: نسبة 9:16 قد تخرج أحيانًا بأبعاد `1365×2048`، وفئة 4K قد تخرج أحيانًا بأبعاد `4096×2731`، وعند ضبط quality=low في فئة 2K قد تكون النتيجة `2048×1153`. كل هذه حالات متفرقة، لذلك يجب إجراء التحقق بعد كل عملية توليد، لا أن يقتصر على فحص عينات أثناء الاختبار.
Q4: هل يكفي التحقق من بضع صور في مرحلة الاختبار، وترك التحقق بعد الإطلاق؟
لا ننصح بذلك. المشكلات المتفرقة قد لا تظهر ولو مرة واحدة في عينة اختبار صغيرة. وقراءة العرض والارتفاع زهيدة التكلفة، إذ تكتفي Pillow بتحليل ترويسة الملف. وإضافة التحقق مباشرةً داخل دالة التوليد أسهل بكثير من البحث لاحقًا عن سبب اختلال التخطيط.
Q5: كيف أستدعي gpt-image-2.6-all عبر API وأتحقق من الأبعاد بسرعة؟
الخطوات كالتالي:
1. سجّل حسابًا في APIYI على apiyi.com، واحصل على مفتاح API ورصيد تجريبي للمستخدمين الجدد
2. اضبط base_url في الشفرة التجريبية على `https://api.apiyi.com/v1`، واملأ معامل الفئة وفق الوثائق
3. شغّل الشفرة الكاملة، ثم راجع declared_match وratio_drift وodd_dimension في report
Q6: ما تأثير ظهور ارتفاع فردي في فئة 2K؟
في عرض الصور الثابتة لا يكون له تأثير عادةً. لكن إذا كنت ستستخدم الصورة إطارًا أول لفيديو، أو غلافًا، أو مادة لإعادة الترميز، فإن كثيرًا من مسارات الترميز تشترط أن يكون العرض والارتفاع زوجيين. عند ظهور أبعاد مثل `2048×1153`، يُفضَّل قص بكسل واحد أو إضافته قبل تسليم الصورة إلى المرمّز.
Q7: كيف يُحتسب سعر gpt-image-2.6-all؟
تشير الوثائق إلى أن التسعير يكون لكل استدعاء، بمبلغ $0.025 في المرة الواحدة. وإذا اعتمدت استراتيجية «أعد المحاولة عند تجاوز انحراف النسبة للحد المسموح»، فاحسب عدد المحاولات الإضافية ضمن التكلفة. يمكنك أولًا استخدام الرصيد التجريبي في APIYI على apiyi.com لقياس تكرار الانحراف، ثم تقرر مدى صرامة الحد الذي تضبطه.
gpt-image-2.6-all 2K/4K: النقاط الرئيسية (Key Takeaways)
- 2K/4K هما مستويا تكبير فائق الدقة (Super-Resolution): عدد البكسلات النهائي تحدده مرحلة التكبير، ولا يمكن استنتاجه من معاملات الطلب.
- لا تعتمد على حقل size: قد لا تُعيد استجابات 2K/4K قيمة size، وأقصى ما يمكن فعله هو استخدامه للمقارنة في السجلات.
- الانحراف عرضي ويصعب إعادة إنتاجه: قد تظهر أبعاد مثل
1365x2048و4096x2731و2048x1153في بيئة الإنتاج. - احفظ الصورة أولًا، ثم اقرأ البكسلات: استخدم Pillow أو naturalWidth لقراءة العرض والارتفاع الفعليين للملف، ثم نفّذ التنسيق.
- عالج الأضلاع ذات الأطوال الفردية مبكرًا: قبل الدخول إلى ترميز الفيديو، اقتطع بكسلًا واحدًا أو أضفه.
- حدّد العتبات باستخدام رصيد الاختبار: أجرِ إحصاءً على دفعات صغيرة عبر APIYI على apiyi.com لقياس تكرار الانحراف، ثم حدّد استراتيجية إعادة المحاولة.
الخلاصة
النقاط الأساسية في التعامل مع أبعاد صور gpt-image-2.6-all بدقة 2K/4K:
- لا تثق بقيمة size في الاستجابة: قد لا تُعيد مستويات التكبير هذه الحقل أصلًا، وحتى لو وُجد فقد لا يطابق الملف الفعلي.
- اعتمد على العرض والارتفاع الفعليين للصورة: اقرأ البكسلات بعد حفظ الصورة، فهذا هو المعيار الذي تنص عليه الوثائق صراحةً.
- اجعل منطق التنسيق متسامحًا مع الانحراف: استخدم contain أو cover أو استراتيجية إعادة المحاولة للتعامل مع اختلاف النسب، وعالج الأضلاع ذات الأطوال الفردية مبكرًا.
عندما تدمج «قراءة البكسلات الفعلية» داخل دالة التوليد نفسها، تتجنب اختلال التخطيط من المصدر، ولن تحتاج الخطوات اللاحقة إلى الاهتمام بمدى موثوقية حقول الاستجابة. يُنصح بتجربة خطوات التحقق أعلاه عبر APIYI على apiyi.com باستخدام مفتاح API واحد، والتأكد من ثبات أداء مستوى 2K/4K في قوالبك قبل الإطلاق.
📚 المراجع
- ملاحظات إطلاق APIYI لـ gpt-image-2.6-all: شرح مستويَي الدقة الفائقة 2K/4K، وحقل size المُعاد، والأبعاد الفعلية بالبكسل
- الرابط:
docs.apiyi.com/live/2026-11/gpt-image-2-6-all-launch -
الوصف: يتضمن تعريف مستويات الدقة الفائقة، وحالات اختلاف الأبعاد العرضية، وتوضيحًا بأن العرض والارتفاع الفعليين هما المعتمدان، إضافةً إلى سعر الاستدعاء الواحد
-
التوثيق الرسمي لمكتبة Pillow: مكتبة بايثون لقراءة الصور
- الرابط:
pillow.readthedocs.io -
الوصف: طريقة استخدام
Image.openوالخاصيةsize، وهي مناسبة لقراءة الأبعاد الحقيقية بالبكسل من الخلفية (الخادم) -
توثيق MDN لـ HTMLImageElement: شرح خصائص الصور في المتصفح
- الرابط:
developer.mozilla.org/docs/Web/API/HTMLImageElement - الوصف: معنى naturalWidth وnaturalHeight، والفرق بينهما وبين أبعاد العرض على الصفحة
المؤلف: فريق APIYI التقني
للتواصل التقني: يمكنكم التواصل معنا عبر الصفحة الرئيسية لموقع APIYI، وللمزيد من المواد زوروا مركز التوثيق docs.apiyi.com
