GPT API इमेज इनपुट: विज़न एनालिसिस और डिटेल सेटिंग्स

request body का एक फ़ील्ड तय करता है कि एक फ़ोटो 85 टोकन लगेगी या 3,000। वह फ़ील्ड detail है, वह image object के अंदर URL के बगल में रहता है, और ज़्यादातर ट्यूटोरियल या तो उसे छोड़ देते हैं या ऐसे नंबर बताते हैं जो दो मॉडल पीढ़ियों पहले सही थे। अगर आप GPT मॉडल को स्क्रीनशॉट, रसीदें, प्रोडक्ट फ़ोटो या चार्ट भेजते हैं, तो यह सेटिंग आपका बिल, आपकी latency और यह तय करती है कि मॉडल तस्वीर का कितना हिस्सा असल में पढ़ पाएगा।

यह लेख request का फ़ॉर्मेट, चार detail वैल्यू, tile आधारित और patch आधारित मॉडल के लिए टोकन गणित, उन स्थितियों को जहाँ low उलटा पड़ता है, और production में भेजने से पहले जानने लायक सीमाएँ समझाता है। नंबर OpenAI के API documentation के image input पेजों से लिए गए हैं जैसे वे आज हैं, और हर उदाहरण अपना हिसाब दिखाता है, ताकि आप उसे अपने responses के usage ब्लॉक से मिलाकर जाँच सकें। ऐसे पेज अक्सर बदलते हैं, इसलिए टोकन काउंट लॉग करना बेहतर है, किसी टेबल पर भरोसा करने के बजाय, नीचे वाली टेबल पर भी नहीं।

एक फ़ोटो टोकन कैसे बनती है

GPT मॉडल आपकी JPEG फ़ाइल को कभी फ़ाइल की तरह नहीं पढ़ता। API उसे resize करता है, छोटे-छोटे ब्लॉक में काटता है, और हर ब्लॉक को टोकन में बदल देता है जो आपके टेक्स्ट के बगल में कॉन्टेक्स्ट विंडो में रहते हैं। ये टोकन मॉडल की सामान्य input दर पर बिल होते हैं, इसलिए बड़ी या ज़्यादा शार्प इमेज का मतलब बड़ा बिल और ज़्यादा latency है। जब request में कई तस्वीरें हों, तो ये टोकन उसी context window में आपके प्रॉम्प्ट और जवाब से भी जगह के लिए होड़ करते हैं।

Request का ढाँचा

इमेज यूज़र मैसेज के भीतर content parts के रूप में जाती हैं। Responses API input_text और input_image parts इस्तेमाल करता है, जबकि Chat Completions text और image_url इस्तेमाल करता है। दोनों में detail इमेज part पर होता है। यह रहा GPT 5.4 पर एक रसीद रीडर:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4",
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": "List every line item and the total."},
                {
                    "type": "input_image",
                    "image_url": "https://example.com/receipt.jpg",
                    "detail": "original",
                },
            ],
        }
    ],
)

print(response.output_text)
print(response.usage.input_tokens)

प्रॉम्प्ट कॉपी करें

GPT-4o के साथ Chat Completions पर वही कॉल URL को एक स्तर और गहराई में रखती है:

completion = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Describe this photo in one sentence."},
                {
                    "type": "image_url",
                    "image_url": {"url": "https://example.com/photo.jpg", "detail": "low"},
                },
            ],
        }
    ],
)

print(completion.usage.prompt_tokens)

प्रॉम्प्ट कॉपी करें

हर कॉल के बाद Responses पर usage.input_tokens या Chat Completions पर usage.prompt_tokens पढ़ें। लागत पर बहस सुलझाने वाला यही एकमात्र नंबर है।

पिक्सल भेजने के तीन तरीके

• सार्वजनिक URL। सबसे सरल विकल्प, पर OpenAI के सर्वर को उसे जल्दी fetch कर पाना ज़रूरी है।
• Base64 data URL। निजी फ़ाइलों के लिए inline data:image/jpeg;base64,... string काम करती है, और payload का आकार लगभग एक-तिहाई बढ़ा देती है।
• File ID। Files API के ज़रिए vision purpose के साथ एक बार अपलोड करें, फिर image part पर file_id फ़ील्ड में ID देकर उसे कई requests में दोबारा इस्तेमाल करें।

स्वीकृत फ़ॉर्मेट हैं PNG, JPEG, WEBP और non-animated GIF।

चार Detail वैल्यू

detail फ़ील्ड low, high, original और auto स्वीकार करता है। अगर इसे छोड़ दें, तो auto मिलता है, यानी मॉडल की अपनी डिफ़ॉल्ट sizing। नाम एक सीधी सीढ़ी जैसे लगते हैं, पर हर पायदान क्या करता है, यह इस पर निर्भर है कि आप कौन सा मॉडल कॉल कर रहे हैं।

Low: मोटा और सस्ता, ज़्यादातर

पुराने tile आधारित मॉडलों पर low एक निश्चित शुल्क है: GPT-4o और GPT 4.1 पर 85 टोकन, फ़ाइल का आकार चाहे जो हो। मॉडल को 512 x 512 पिक्सल का संस्करण मिलता है, जो यह बताने के लिए काफ़ी है कि "समुद्र तट पर एक कुत्ता है", पर सड़क का साइनबोर्ड पढ़ने के लिए नहीं। इसे classification, मोटे captions, moderation जाँच और routing के फ़ैसलों के लिए इस्तेमाल करें, जहाँ सिर्फ़ मोटा अर्थ चाहिए।

High और Auto: रोज़ का डिफ़ॉल्ट

tile मॉडलों पर high पहले इमेज को 2,048 x 2,048 के वर्ग में फिट करता है, फिर सबसे छोटी भुजा को 768 पिक्सल तक स्केल करता है, और फिर 512 पिक्सल के tiles गिनता है। GPT 5.x परिवार पर यह इसके बजाय 32 पिक्सल के patches पर काम करता है, GPT 5.4 और उसके छोटे भाई-बहनों पर 2,048 पिक्सल की सबसे लंबी भुजा और 2,500 patch budget के साथ। फ़ोटो, प्रोडक्ट शॉट और आम स्क्रीनशॉट के लिए यह काफ़ी है। घने दस्तावेज़ों और बहुत छोटे interface टेक्स्ट में यह दिक्कत देने लगता है, जहाँ कुछ खोए हुए पिक्सल 6 को 8 बना देते हैं।

Original: जब पिक्सल मायने रखते हैं

original GPT 5.4 और उसके समकक्ष मॉडलों पर सीमा को 10,000 patches और 6,000 पिक्सल की सबसे लंबी भुजा तक बढ़ा देता है। OpenAI इसे बड़ी, घनी, स्थानिक रूप से संवेदनशील या computer-use इमेज के लिए, और OCR या छोटी वस्तु पहचान जैसे coordinates पर निर्भर काम के लिए बताता है। एक 4K स्क्रीनशॉट सोचिए जहाँ मॉडल को किसी बटन की स्थिति लौटानी है, या एक फ़्लोर प्लान जहाँ एक पतली रेखा अर्थ रखती है। इस तीक्ष्णता की कीमत चुकानी पड़ती है: 1.2 multiplier पर प्रति तस्वीर 12,000 इमेज टोकन तक।

व्यावहारिक नियम यह है कि यह सेटिंग तभी लें जब उसकी ज़रूरत साबित हो। एक task high से शुरू करें, विफलताएँ इकट्ठी करें, और सिर्फ़ विफल होने वाली इमेज प्रकारों को original पर ले जाएँ। अगर कोई फ़ील्ड high पर गलत पढ़ा गया और original पर सही पढ़ा गया, तो अतिरिक्त टोकन ने कुछ खरीदा। अगर दोनों सेटिंग एक ही तरह से विफल होती हैं, तो समस्या prompt या मूल इमेज में है, और ज़्यादा पिक्सल मदद नहीं करेंगे।

टोकन गणित, हल करके

Tile आधारित मॉडल

Tile billing एक base fee है plus हर 512 पिक्सल tile की fee। GPT-4o और GPT 4.1 पर 85 base और प्रति tile 170 लगते हैं। GPT 5.1 पर 70 और 140। GPT 4o Mini पर 2,833 और 5,667, इसलिए इमेज का काम mini मॉडल पर ले जाने से टोकन कम होने के बजाय बढ़ जाते हैं। प्रति टोकन दर नहीं, कुल लागत की तुलना करें।

Patch आधारित मॉडल

नए मॉडल 32 x 32 पिक्सल के patches गिनते हैं: ceil(width / 32) x ceil(height / 32)। जब कुल संख्या budget से ज़्यादा होती है, तो इमेज तब तक सिकुड़ती है जब तक वह फ़िट न हो जाए, और अंतिम टोकन काउंट होता है patches गुणा मॉडल multiplier, ऊपर की ओर पूर्णांकित। multiplier GPT 5.2, GPT 5.4 और GPT 5.6 परिवार (Sol, Terra और Luna) के लिए 1.2 है, और GPT 4.1 mini के लिए 1.62।

4000 x 3000 वाली पंक्तियाँ प्रकाशित budgets से मेरा अपना हिसाब हैं, इसलिए उन्हें अनुमान मानें और usage से पुष्टि करें। 1080p वाली पंक्ति सटीक है, क्योंकि वह इमेज पहले से हर budget में फ़िट होती है।

पैमाना फ़र्क असली बनाता है। दस हज़ार प्रोडक्ट फ़ोटो, हर एक 2,448 टोकन, यानी prompt का एक भी शब्द जोड़े बिना 24.48 मिलियन input tokens। वही सेट GPT-4o पर हर एक 85 टोकन पर low से 850,000 होता है, यानी लगभग 29 गुना का फ़र्क, जो आपको सिर्फ़ कोड से कभी नहीं दिखेगा।

जब Low, High से ज़्यादा महँगा पड़ता है

दस्तावेज़ों में एक चेतावनी है जो लोगों को चौंकाती है: यह ज़रूरी नहीं कि low हमेशा high से कम टोकन ले। GPT 5.4 और उसके छोटे भाई-बहनों पर low 6,144 patch budget देता है, जबकि high 2,500 पर रुक जाता है, इसलिए एक बड़ी फ़ोटो low पर ज़्यादा बिल हो सकती है। GPT 5.2 और GPT 4.1 mini पर हर स्तर एक ही sizing नियम साझा करता है, 2,048 पिक्सल की सबसे लंबी भुजा और 6,144 patch budget, इसलिए low, high और auto एक जैसी गिनती लौटाते हैं, और original उपलब्ध नहीं है।

इससे दो बातें निकलती हैं। कभी मत मानें कि सस्ती सेटिंग सस्ती ही है, और मॉडल बदलने पर अपनी मौजूदा detail वैल्यू का अर्थ बदलने की उम्मीद रखें। एक छोटा टेस्ट दोनों बातें तय कर देता है:

1. तीन प्रतिनिधि इमेज चुनें: एक छोटी, एक 1080p स्क्रीनशॉट और एक 12 megapixel फ़ोटो।
2. हर एक को उस मॉडल की हर detail वैल्यू पर भेजें जिसे वह सपोर्ट करता है।
3. हर बार input tokens को जवाब की गुणवत्ता के साथ लॉग करें।
4. वह सबसे निचली सेटिंग रखें जो अब भी सही जवाब दे।

💡 अगर किसी मॉडल पर low और high एक ही टोकन काउंट लौटाते हैं, तो वहाँ यह फ़ील्ड कुछ नहीं करता। इसे अपने कोड से हटा दें, बजाय उस पैरामीटर को रखने के जो बचत का भ्रम देता है जो आपको मिल नहीं रही।

Production में नुकसान पहुँचाने वाली सीमाएँ

Payload और फ़ॉर्मेट की सीमाएँ

मौजूदा दस्तावेज़ कुल 512 MB payload और प्रति request 1,500 images तक की अनुमति देते हैं। पुराने लेखों में 50 MB और 500 images लिखे मिलते हैं, इसलिए जो लाइब्रेरी उन नंबरों को लागू करती है, वह पुरानी हो सकती है। 512 MB वाली request सीमा की समस्या बनने से बहुत पहले latency की समस्या बन जाती है, क्योंकि base64 बाइट्स को एक-तिहाई बढ़ा देता है, और हर इमेज फिर भी टोकन बिल करती है।

जहाँ Vision अब भी विफल होता है

OpenAI कमज़ोर जगहें साफ़ बताता है, और वे वही हैं जो production में दिखती हैं:

• विशेष मेडिकल इमेज, जैसे CT scans, उपयुक्त नहीं हैं।
• गैर-लैटिन वर्णमालाएँ, जैसे जापानी या कोरियाई, कमज़ोर प्रदर्शन कर सकती हैं।
• अलग-अलग line styles या रंगों वाले graphs, जहाँ ठोस, डैश वाली और बिंदु वाली रेखाओं में फ़र्क करना होता है, गलतियाँ करवाते हैं।
• सटीक spatial localization, जैसे शतरंज की स्थिति पढ़ना, भरोसेमंद नहीं है।
• Object counts अनुमान के रूप में लौटते हैं।
• CAPTCHAs ब्लॉक होते हैं।
• फ़ाइल नाम और metadata कभी नहीं पढ़े जाते।

रोज़मर्रा के काम में बारीक प्रिंट सबसे ज़्यादा नुकसान उठाता है। जब ज़रूरी हिस्सा छोटा हो, तो सिर्फ़ वही हिस्सा भेजें।

💡 भेजने से पहले crop करें। रसीद की कुल रकम वाली पंक्ति का 600 x 400 crop GPT 5.4 पर लगभग 300 टोकन लगता है (19 x 13 = 247 patches, गुणा 1.2)। पूरा 4000 x 3000 पेज original पर 12,000 तक पहुँच सकता है, और crop आमतौर पर बेहतर पढ़ा जाता है।

टोकन बर्बाद करने वाली गलतियाँ

ज़्यादातर ज़्यादा खर्च कुछ आदतों से आता है:

• कच्चे कैमरा फ़ाइलें अपलोड करना। 12 megapixel की मूल फ़ाइल वैसे भी आते ही मॉडल की सीमा तक सिकुड़ जाती है। पहले उस सबसे लंबी भुजा तक resize करें जिसकी आपकी detail वैल्यू अनुमति देती है (ज़्यादातर सेटिंग के लिए 2,048 पिक्सल, GPT 5.4 और उसके भाई-बहनों पर original के लिए 6,000), JPEG के रूप में export करें, और request बिना कुछ खोए तेज़ी से अपलोड होती है।
• एक collage को एक इमेज में जोड़ना। एक canvas पर चिपकाए गए छह स्क्रीनशॉट एक साथ सिकुड़ते हैं, इसलिए हर एक का resolution घट जाता है। छह अलग image parts भेजें और टेक्स्ट में उनके नाम लिखें: "Image 1 invoice है, image 2 packing slip है।" हर part अपने आप बिल होता है।
• एक ही बार में सब कुछ माँगना। एक prompt जो caption, रंगों की सूची, defect जाँच और OCR पास एक साथ माँगे, उथले जवाब देता है। हर call में एक संकीर्ण सवाल, या एक साफ़ क्रम वाली सूची, ज़्यादा साफ़ आउटपुट देती है।
• usage कभी लॉग न करना। हर request के input token counts के बिना, मॉडल बदलने या नए इमेज साइज़ से आपका बिल दोगुना हो सकता है, और कुछ भी आपको बताएगा नहीं।

काम के हिसाब से सेटिंग चुनें

रसीदें और दस्तावेज़

टेक्स्ट वह जगह है जहाँ resizing सबसे पहले नुकसान करता है। क्षेत्र को crop करें, सीधा करें, और एक तय JSON आकार माँगें ताकि गलत अंक आसानी से पकड़ में आए। मॉडल को कहें कि जो फ़ील्ड वह न पढ़ सके, उसके लिए unreadable लिखे, क्योंकि जिस मॉडल को अनुमान लगाने की छूट है, वह अनुमान लगाएगा, और एक आत्मविश्वास से लिखा गलत total खाली जवाब से बुरा है। अगर स्कैन धुंधला है, तो upload से पहले किसी AI image restoration टूल से उसे ठीक करें, क्योंकि कोई detail setting वे पिक्सल नहीं बना सकती जो कभी कैप्चर ही नहीं हुए।

चार्ट और घने स्क्रीनशॉट

चार्ट में पतली रेखाएँ, छोटे labels और मिलते-जुलते रंग एक साथ होते हैं, यही वह ठीक स्थिति है जिसे OpenAI चिह्नित करता है। मॉडल सपोर्ट करे तो इन्हें original पर भेजें। पहले अंतर्निहित संख्याएँ table के रूप में माँगें और व्याख्या बाद में, ताकि किसी भी ट्रेंड पर भरोसा करने से पहले आप मूल्यों को तस्वीर से मिलाकर जाँच सकें। जिन tables और charts को आप रोज़ निकालते हैं, उनके लिए Granite Vision 4.1 4B जैसे specialist के साथ आमने-सामने टेस्ट करना फ़ायदेमंद है।

बड़े पैमाने पर प्रोडक्ट फ़ोटो

कैटलॉग के काम के लिए, अपनी असली फ़ोटो पर ऊपर वाला तीन इमेज टेस्ट चलाएँ, फिर पूरे बैच के लिए सेटिंग और prompt तय करें। हर बार एक ही क्रम में एक जैसे गुण माँगें, जैसे रंग, सामग्री और दिखने वाले defects, तो आउटपुट डेटाबेस में आसानी से लोड हो जाता है। वस्तुओं की तस्वीरें भी एक जैसे तरीके से लें: एक समान background, दूरी और रोशनी से आप सस्ती सेटिंग इस्तेमाल कर पाते हैं, क्योंकि मॉडल को शोर से निपटने की मेहनत नहीं करनी पड़ती। सादी मेज़ पर समान रोशनी में ली गई प्रोडक्ट शॉट अक्सर high पर ठीक पढ़ी जाती है, जबकि भीड़भाड़ वाले किचन में वही मग शायद न पढ़ा जाए।

PicassoIA पर GPT 5.4 कैसे इस्तेमाल करें

मॉडल क्या पढ़ता है, यह देखने के लिए आपको कोड की ज़रूरत नहीं है। PicassoIA पर GPT 5.4 टेक्स्ट prompt के साथ इमेज स्वीकार करता है, और इसका फ़ॉर्म वही लीवर खोलता है जो आप API में ट्यून करते हैं: system prompt, verbosity, reasoning effort और completion token limit। इससे यह सेटिंग्स से पहले आने वाले सवालों को जल्दी सुलझाने की अच्छी जगह बन जाती है। कौन सा prompt शब्द-विन्यास काम करता है? क्या मॉडल इस तरह की तस्वीर पढ़ पाता है? क्या कोई सस्ता मॉडल काफ़ी है? एक चेतावनी: फ़ॉर्म में image input फ़ील्ड है, पर detail स्विच नहीं है, इसलिए नतीजों को prompt और मॉडल चुनाव का टेस्ट मानें, low बनाम high का मापन नहीं।

चरण-दर-चरण

1. GPT 5.4 पेज खोलें और Image Input फ़ील्ड ढूँढें।
2. अपनी टेस्ट इमेज जोड़ें। रसीद, डैशबोर्ड स्क्रीनशॉट या प्रोडक्ट फ़ोटो, सब चलते हैं।
3. एक संकीर्ण prompt लिखें: "तारीख और कुल रकम JSON में लौटाओ" में "इस इमेज का वर्णन करो" से बेहतर है।
4. एक System Prompt जोड़ें जो भूमिका और आउटपुट फ़ॉर्मेट तय करे।
5. निकालने वाले कामों के लिए Verbosity को low पर रखें, और विस्तृत विश्लेषण चाहने पर high पर।
6. साधारण पढ़ाई के लिए Reasoning Effort को none पर रहने दें। बहु-चरणीय सवालों के लिए बढ़ाएँ, और उसके साथ Max Completion Tokens भी बढ़ाएँ, क्योंकि ज़्यादा effort पूरा बजट reasoning में खर्च कर सकता है और खाली जवाब लौटा सकता है।
7. वही इमेज GPT-4o पर चलाएँ और दोनों आउटपुट की तुलना करें।

तुलना के लायक विज़न मॉडल

इमेज-टू-टेक्स्ट प्लेटफ़ॉर्म की अंतर्निहित क्षमताओं में से एक है, और कई लार्ज लैंग्वेज मॉडल इमेज स्वीकार करते हैं:

अपनी टेस्ट इमेज भेजें

अपने असली काम से पाँच इमेज चुनें: एक बहुत छोटी, एक 1080p, एक 12 megapixel फ़ोटो, एक रसीद और एक चार्ट। इन्हें PicassoIA पर GPT 5.4 और GPT-4o से चलाएँ, लिखें कि कौन से जवाब सही थे, और फिर विजेता को API पर ले जाकर हर detail वैल्यू पर टोकन काउंट की तुलना करें। ऐसा एक घंटे का टेस्ट किसी भी pricing बदलाव से ज़्यादा पैसे बचाता है।

टेस्ट सामग्री चाहिए? PicassoIA खोलें, टेक्स्ट-टू-इमेज मॉडलों से अपने दृश्य बनाएँ, और उन्हें अपने vision prompts के लिए टेस्ट सेट में बदलें। उपलब्ध सब कुछ picassoia.com/en/all-models पर देख सकते हैं। एक इमेज से शुरू करें, एक संकीर्ण सवाल पूछें, और देखें कि मॉडल असल में क्या पढ़ता है।