Gemini Omni 1.1 Flash का 4K एक upscale है। यहाँ फिर भी 41% सस्ता है

हम वही ज़ाहिर-सा परीक्षण चलाने निकले और वह पहले ही क़दम पर ढह गया, जो कि इससे भी दिलचस्प नतीजा निकला।

योजना मामूली थी: एक prompt, एक तय seed, दो resolutions, फिर दोनों stills को एक-से-एक pixel पर खोलकर देखना कि सबसे ऊपरी पायदान क्या जोड़ता है। जो लौटा वे दो अलग फ़िल्में थीं। वही prompt text, वही seed — और 720p take में frame के नीचे-बाएँ बैठा पीतल का आवर्धक 4K वाले में frame के दाएँ और और पीछे बैठा है। Pigment के कटोरे अलग तरतीब में रखे हैं और उनकी संख्या भी ज़्यादा है — 720p take में साढ़े पाँच सेकंड पर frame में सात भरे कटोरे हैं, जबकि 4K वाले में पाँच। लिनन पीछे रखी मुड़ी हुई गड्डी से बदलकर दाईं ओर चौड़ा फैला हुआ हो जाता है।

इसे साफ़-साफ़ कहना ज़रूरी है, क्योंकि prompting सलाह इसका उल्टा मान लेती है: कोई seed किसी shot को एक ही resolution के भीतर दोबारा बनाता है, resolutions के आर-पार नहीं। पायदान बदलिए और आपने अपने मौजूदा take का बड़ा प्रिंट नहीं, एक नया take मँगवा लिया है। जो कोई सस्ते में draft बनाकर एक ही seed से महँगे में फ़िनिश करने की योजना बना रहा हो, वह इसे दो बार पढ़े।

तो तुलना एक ही डिलीवर हुई फ़ाइल पर खड़ी करनी पड़ी। एक 4K frame लीजिए, उसे 1920 गुणा 1080 तक छोटा कीजिए, फिर 3840 गुणा 2160 तक वापस बड़ा कीजिए। जो कुछ एक 1080p master ले जा सकता था, वह इस सफ़र से बच जाता है; जो कुछ 1080p की प्रस्तुत करने की क्षमता से बारीक है, वह नहीं। round-trip की native से तुलना कीजिए और अंतर वही है जो सबसे ऊपरी पायदान 1080p के ऊपर असल में देता है।

नियंत्रण, माप से भी ज़्यादा मायने रखता है, क्योंकि H.264 का grain ठीक उसी बैंड में रहता है जिसे मापा जा रहा है। इसलिए परीक्षण दो तरह के क्षेत्रों पर चला: बनावट वाले इलाक़े जहाँ असली डिटेल रह सकती है, और सपाट, फ़ोकस से बाहर के इलाक़े जो उसे रोक ही नहीं सकते। सपाट क्षेत्र आपको noise floor देते हैं।

बनावट वाले हिस्से का अधिशेष noise floor से साफ़ ऊपर बैठता है, यानी डिलीवर हुआ 4K उससे ऊपर असली संरचना ले जाता है जो 1080p रोक सकता था — सिर्फ़ grain नहीं। पर उसका आकार भी पढ़िए: मोटे तौर पर floor का तीन गुना, जबकि pixels नौ गुना। और चूँकि compression का शोर माप को डिटेल पाने की ओर झुका देता है, इसे अनुमान नहीं, एक छत मानिए।

हाथ से रखे तीन पैच इसके लिए पतला आधार हैं, इसलिए हमने वही 512 pixel की खिड़की 128 pixel के क़दमों में पूरे frame पर सरकाई और नतीजों को इस आधार पर बाँटा कि हर पैच असल में कितनी बनावट रखता है। सबसे सपाट तेरह 1.08x और 1.35x के बीच आते हैं; सबसे ज़्यादा बनावट वाले ग्यारह 2.86x और 3.86x के बीच। यह फ़ासला frame की ख़ासियत है, इसकी नहीं कि हमने डिब्बे कहाँ रखे।

उसी frame का वही 512 pixel का क्षेत्र — frame 96, चार सेकंड पर, pixel (2944, 1152) पर — इसलिए इन दोनों का अंतर पूरा-का-पूरा वही है जो सबसे ऊपरी पायदान एक 1080p master के ऊपर जोड़ता है। दूसरा एक round trip है, 1080p render नहीं — और हम उसे वैसा लेबल नहीं करेंगे।

और अगर आपको ये दोनों लगभग एक जैसे लगें, तो यही सही पाठ है, दृष्टांत की नाकामी नहीं। इनमें ज़्यादा से ज़्यादा 255 में से 9 मानों का, औसतन 0.82 का अंतर है, 47.1 dB PSNR पर। यह कोई नरम करके चुना गया उदाहरण भी नहीं है: वह पैच पूरे frame का सबसे ज़्यादा बनावट वाला 512 pixel वर्ग है। उच्च-आवृत्ति band में 3.62x का अनुपात एक असली नतीजा है, पर यह एक ऐसी मात्रा का तीन गुना है जो कभी बड़ी थी ही नहीं — यह footage शुरू से आख़िर तक नरम है। सबसे ऊपरी पायदान यहाँ जो जोड़ता है, वह ऐसी चीज़ है जिसे spectrum अलग कर सकता है और आँख ज़्यादातर नहीं।

इसे दोहराने वालों के लिए एक पद्धति-नोट: high-frequency energy वह हिस्सा है जो रेडियल रूप से औसत किए गए power spectrum में 1080p की Nyquist सीमा से ऊपर पड़ता है, जो 4K frame के 512 pixel के पैच के लिए radius bin 128 है। Round trip है ffmpeg -vf "scale=1920:1080,scale=3840:2160" डिफ़ॉल्ट bicubic पर, पैच काटने से पहले पूरे frame पर लगाया गया।

तीखेपन के लिए सामान्य त्वरित विकल्प Laplacian variance ज़्यादा भोथरा औज़ार है: यह बनावट वाले पैच को 1.70x पर रखता है और सपाट वालों को 1.36x तथा 1.07x पर, जबकि spectral माप 3.62x बनाम 1.10x और 1.15x देता है। यह उन्हें अलग तो करता है, पर इतने छोटे अंतर से कि उस पर बहस हो सकती है, क्योंकि यह डिटेल के साथ-साथ compression का शोर भी गिनता है।

फ़ाइल पर दो जाँचें, क्योंकि ऊपरी tier नक़ली दिखाना आसान है। ffprobe सच्चा 3840 गुणा 2160 बताता है, फ़ाइल का bitrate 25,583,339 bit/s — उसी prompt के 720p take का 8.84 गुना, जबकि pixel अनुपात 9.00। यानी कोई आपको UHD की पैकिंग में भूखी स्ट्रीम नहीं थमा रहा। और वह ठीक 24 fps मापता है, 8.000 सेकंड में 192 frames: यह आँकड़ा Google के छापे किसी दस्तावेज़ के बजाय तीसरे-पक्ष के schema दस्तावेज़ों के बल पर घूमता था, और यहाँ हमारे अपने output में पुष्ट होता है।

तो ईमानदार जवाब उन दो में से कोई नहीं है जो आप आमतौर पर सुनते हैं। सबसे ऊपरी पायदान न तो दोबारा लेबल की गई 1080p फ़ाइल है, न ही तस्वीर का चार गुना। नौ गुना pixels आपको संरचना के तीन गुने के क़रीब कुछ ख़रीदकर देते हैं — यही वजह है कि इसकी क़ीमत का सवाल ध्यान से पूछे जाने लायक़ है।

उस कोष्ठक में "upscaled" क्या कर रहा है

Google का model reference यह शब्द ऊपर के दो tiers पर हूबहू जोड़ता है: "1080p output (upscaled)" और "4K output (upscaled)" — यानी upscale किया गया output। Generation किसी नीचे वाले आंतरिक raster पर होता है और नतीजा बाहर निकलते वक़्त resize होता है, इसलिए सबसे ऊपरी पायदान जो भी संरचना ले जाता है उसे renderer ने हल नहीं किया, resize ने रखा। Google वह आंतरिक resolution नहीं छापता, इसलिए जो कोई आपको बढ़ाने का गुणक बताता है वह भी उसे नहीं जानता।

दो नतीजे। ख़राब take को आप काउंटर पर वापस नहीं ख़रीद सकते, क्योंकि ख़ामी resize से पहले की है और मक़ूल बनावट गढ़ने को तैयार upscaler सही बनावट नहीं गढ़ेगा। पर "बाद में ख़ुद ही बड़ा कर लेंगे" भी सुनने में जितना मज़बूत लगता है उतना नहीं है: मॉडल का resize delivery encode से पहले चलता है, आपका बाद में — उस फ़ाइल पर जिसकी quantisation पहले ही पक चुकी है।

पाँच काम जहाँ आयाम ही deliverable हैं

ईमानदार जानकारी जिसे दबा देती है वह यह है: बड़ा raster चाहने की एक वजह डिटेल है, और production में सबसे आम वजह नहीं।

ऐसा delivery spec जो raster का नाम लेता हो। प्रसारक और agencies अपनी शर्तें आयामों में लिखते हैं, और स्वचालित QC header पढ़ता है। UHD spec के सामने भेजी गई 1920 गुणा 1080 फ़ाइल किसी इंसान के देखने से पहले ही ख़ारिज हो जाती है। वहाँ कोई modulation transfer नहीं माप रहा — वे फ़ाइल माप रहे हैं।

एक archive master. जो सबसे बड़ा संस्करण आपने कभी बनाया हो उसे रखिए: मॉडल किसी दिन बंद कर दिया जाएगा, और जैसा ऊपर का seed नतीजा दिखाता है, आप prompt दोबारा चलाकर वह clip वापस नहीं पा सकते। Deliverables किसी master से नीचे की ओर बनते हैं, कभी ऊपर की ओर नहीं।

Reframe और punch-in की गुंजाइश। सबसे मज़बूत व्यावहारिक तर्क, और यह पूरी तरह अंकगणित है। Omni दो aspect ratios देता है, और कोई नहीं — 16:9 और 9:16 — इसलिए वर्गाकार या 4:5 जो कुछ भी है वह एक crop है। 1080p frame से बीच का 9:16 crop 608 pixel चौड़ा होता है — यानी 1080 चौड़ी vertical delivery का मतलब एक compressed फ़ाइल को फिर से बड़ा करना। वही crop UHD से 1215 चौड़ा निकलता है और आप spec की ओर छोटा कर रहे होते हैं। Punch-in भी वैसा ही: UHD पर 1.5× reframe आपको फिर भी native 1920 गुणा 1080 देता है, जबकि 1080p स्रोत 1280 गुणा 720 छोड़ता है।

बड़े फ़ॉर्मैट का प्रदर्शन। किसी LED wall या DOOH panel पर panel का pixel pitch तय करता है कि आप कौन-सी फ़ाइल सौंपेंगे, और उसे भरने के लिए खींचा गया 1080p स्रोत उस तरह साफ़ नज़र आने वाला मुलायम दिखता है जैसा browser के embed में कभी नहीं होता।

Compositing और VFX plates. Trackers और keyers pixels पर काम करते हैं, और चार गुना pixels planar solve को स्थिर करते हैं, भले ही वे sensor के बजाय किसी बढ़ाव से आए हों। आप composite को delivery spec पर ही ख़त्म भी करते हैं, इसलिए plate का पहले से वहाँ होना ज़रूरी है।

इन पाँचों में से कोई भी तस्वीर के बेहतर दिखने के बारे में नहीं है। पाँचों इस बारे में हैं कि आगे जो होना है उसके लिए फ़ाइल सही आकार की हो।

और तीन जहाँ आप एक resize के पैसे दे रहे हैं

Vertical social. हर बड़ा platform अपलोड पर दोबारा encode करता है और ज़्यादातर लंबी भुजा को UHD से काफ़ी नीचे बाँध देते हैं — यानी आप उन pixels के लिए सबसे ऊपरी tier का दाम दे रहे हैं जो ingest में ही फेंक दिए जाते हैं, किसी दर्शक के पोस्ट देखने से पहले।

Web embed. किसी लेख के कॉलम में clip शायद 800 pixel चौड़ाई पर चलती है। वहाँ एक UHD स्रोत आपको generation पर पैसा और delivery पर Largest Contentful Paint गँवाता है, एक दुर्लभ दोहरा नुक़सान।

आंतरिक समीक्षा passes. किसी camera move को मंज़ूर करना आकार और गति का फ़ैसला है, जो दो पायदान नीचे, पैसे के एक छोटे हिस्से में हो जाता है।

क़ीमत वाला हिस्सा, जो असल तर्क है

29 अगस्त 2026 को पढ़ा गया, इस मॉडल के लिए चलाने योग्य प्रति-सेकंड दर छापने वाले हर provider पर सबसे ऊपरी पायदान।

Google की अपनी दर के मुक़ाबले यह इकतालीस प्रतिशत नीचे है — और चारों tiers में साफ़ अंतर से सबसे बड़ा फ़ासला। एक पायदान नीचे, 1080p पर, फ़ासला घटकर ग्यारह प्रतिशत रह जाता है, $0.135 बनाम $0.1520, और उससे भी नीचे मैदान इतना पास-पास है कि एक पैराग्राफ़ के लायक़ नहीं।

Replicate उस तालिका से इस वजह से ग़ायब है जिसे ढँकने के बजाय कहना बेहतर है: वह मॉडल रखता है और किसी भी resolution पर प्रति-सेकंड कोई दर नहीं छापता। हमने 4K का आँकड़ा ढूँढ़ा और उद्धृत करने को कुछ नहीं है।

फ़ासला ऊपर ही क्यों चौड़ा होता है, इसकी वजह margin का बर्ताव नहीं बल्कि सीढ़ी की बनावट है, और दोनों बनावटें सार्वजनिक हैं। हर provider को उसके अपने 720p सेकंड के हिसाब से सामान्य कीजिए और दोनों तीन पायदानों पर सहमत हैं: draft tier पर एक-तिहाई, बीच में एक, 1080p पर डेढ़ गुना। चौथे पर वे अलग होते हैं — Google अपने 720p सेकंड का तीन गुना लेता है, हम अपने का दो गुना। इकतालीस प्रतिशत का हर डॉलर उसी एक क़दम से निकलता है।

इसे उन अवधियों तक खोलिए जो आप सचमुच मँगवाएँगे:

अगर आप किसी campaign की क़ीमत लगा रहे हैं तो वह आख़िरी पंक्ति थामे रखिए। चालीस सेकंड का UHD sequence किसी भी provider पर अलग-अलग बिल होने वाले चार काम है, और एक ही sequence पर दोनों कॉलम में लगभग पाँच डॉलर का फ़र्क़ है — और यह उन takes से पहले जो आप फेंक देते हैं, जिनमें से हर एक फ़ासले को गुणा करता है।

दोनों कॉलम वही weights, वही native audio, हर frame में वही SynthID watermark ख़रीदते हैं। इकतालीस प्रतिशत का कोई हिस्सा गुणवत्ता का सौदा नहीं है — और उसका कोई हिस्सा यह दावा भी नहीं करता कि आम तौर पर video बनाने का यह सबसे सस्ता तरीक़ा है, जो आमतौर पर नहीं है।

4K पर जाने से prompt में क्या बदलता है

लगभग कुछ नहीं, और वह "लगभग" ही दिलचस्प हिस्सा है।

Resolution एक API parameter है, और text में "4K" लिखने से tier नहीं चुना जाता। डिटेल वाले विशेषण ग़लत चरण को संबोधित हैं: बढ़ाव generation के बाद चलता है और आपका prompt कभी नहीं पढ़ता। वह नमूने गढ़ेगा, जैसा ऊपर की माप दिखाती है — बस किसी ऐसी दिशा में नहीं जिसे आपके शब्द चलाते हों।

Renderer तक जो पहुँचता है वह optics और रोशनी है, और रोशनी दोहरा काम करती निकलती है। छूता हुआ स्रोत ऊँचे contrast वाले किनारे बनाता है, और बढ़ाव से बचने वाली चीज़ ऊँचे contrast वाले किनारे ही हैं — चाहे upscaler उन्हें बचा रहा हो या दोबारा गढ़ रहा हो। बनावट के लिए रोशनी रचना, tier के लिए prompt लिखने के सबसे क़रीब की चीज़ है।

यही brief दो तरह से लिखा हुआ। पहले, वह तरीक़ा जिससे लोग resolution के पीछे भागते हुए लिखते हैं:

4K ultra detailed cinematic shot of a museum conservation bench, 8K,
hyper realistic, insanely sharp, maximum detail, best quality, intricate
textures, razor sharp focus, highly detailed surfaces, photorealistic
masterpiece, professional cinematography, award winning, unreal engine
render, ray tracing, ultra HD, crisp edges, no blur, extreme detail on
every surface, cinematic lighting, beautiful composition, trending.

पढ़िए कि यह असल में क्या निर्देश देता है। यह कहीं भी scene cuts मना नहीं करता, इसलिए मॉडल एक छोटी कथा गढ़ने को आज़ाद है — उसका दर्ज किया डिफ़ॉल्ट यही है। यह कोई रोशनी नहीं रखता, किसी lens का नाम नहीं लेता, कोई camera speed तय नहीं करता, और "unreal engine" किसी तस्वीर के बजाय गेम के render की ओर इशारा करता है। बाईस विशेषण, और उनमें से एक भी ऐसा निर्देश नहीं जिस पर renderer अमल कर सके।

और वह prompt जो हमने सचमुच चलाया — जिसने नीचे की clip, ऊपर के crops और इस पोस्ट का हर आँकड़ा बनाया:

Slow lateral pan, 50mm lens on a motorized slider, moving right to left
at a steady crawl across a museum conservation bench. The frame passes
over an unrolled length of raw linen, a brass magnifier resting on its
side, and a scatter of dry pigment powder in small glass dishes - ochre,
ultramarine, deep charcoal - then settles on the corner of an oil
painting where fine craquelure spiders across the varnish. Hard
low-angle tungsten light from the left rakes over every surface so the
linen weave, the dust and the cracked glaze all read as texture. Focus
stays locked on the bench plane throughout and nothing moves except the
camera. Sound: the faint whir of the slider motor and a room's worth of
quiet.

4K पर आठ सेकंड, यानी $1.44। ध्यान दीजिए कि काम कहाँ हुआ: bench पर से छूता हुआ एक तीखा, नीचे कोण वाला स्रोत, जिससे बुनाई, धूल और चटकी हुई वार्निश सब बनावट की तरह पढ़े जाते हैं। उस एक वाक्य ने बाईस विशेषणों से ज़्यादा किया, और यही वजह है कि round trip को ढूँढ़ने के लिए कुछ मिला।

एक production नोट। यह prompt पहली बार भेजने पर It seems there was an issue with the input you provided कहकर ठुकरा दिया गया, और दो शब्द बदलने के बाद दोबारा भेजने पर पास हो गया — camera का एक शब्दजाल हटाया, एक pigment का नाम बदला। लंबे prompts में एक ही शब्द पूरा अनुरोध गिरा सकता है, और error यह नहीं बताएगा कि कौन-सा।

जहाँ सबसे ऊपरी tier फिर भी आपकी मदद नहीं कर सकता

ख़ास तौर पर 4K के काम के इर्द-गिर्द चार सीमाएँ बैठती हैं। Aspect ratio 16:9 या 9:16 ही रहता है, इसलिए वर्गाकार और 4:5 deliverables एक crop से आते हैं, आप कोई भी पायदान चुका लें। हर frame एक SynthID watermark लिए है और कहीं कोई स्विच नहीं। चढ़ने के लिए कोई native-4K मोड नहीं और upscaler पर कोई नियंत्रण नहीं। और एक generation अब भी दस सेकंड पर रुक जाती है, इसलिए उससे लंबा UHD master एक extension chain है जिसमें हर नाकाम कड़ी अब $1.35 के बजाय $1.80 पड़ती है।

और पूरी पोस्ट पर समापन चेतावनी: इनमें से कुछ भी Omni को एक अकेली 4K clip के लिए सही मॉडल नहीं बनाता। Veo 3.1 Fast उसी key पर एक सेंट प्रति सेकंड चलता है। ऐसे अकेले shot के लिए जिस पर कुछ टिका न हो, अठारह गुना का गुणक बचाव के लायक़ नहीं, चाहे 4K की दर कितनी ही अच्छी दिखे।

सस्ते में draft, बड़े में delivery

सस्ते में दोहराइए और एक विजेता को ऊपर ले जाइए: 360p पर दस passes और एक finish $1.728 पड़ते हैं, जबकि 1080p पर दस $5.40। चालीस सेकंड वाली पोस्ट इसे ठीक से हल करती है।

UHD एक क़दम नहीं, एक चेतावनी जोड़ता है। $0.0297 प्रति सेकंड पर बेशक draft बनाइए, पर ऊपर का seed नतीजा यह कहता है कि विजेता एक मार्गदर्शक है, पूर्वावलोकन नहीं — जो take आप डिलीवर करेंगे वह अलग होगा। tier को delivery spec चुनने दीजिए, वह tier नहीं जिसमें आपने draft बनाया।

Capability के हिसाब से आँकड़े मशीन-पठनीय spec में हैं; मॉडल ख़ुद text-to-video पर है। दरें हिलती रहती हैं — पैसा लगाने से पहले हर provider के अपने पेज पर पुष्टि कर लीजिए। यह उन providers को कवर करता है जो 29 अगस्त 2026 को चलाने योग्य प्रति-सेकंड 4K दर छापते हैं।

अक्सर पूछे जाने वाले सवाल

क्या Gemini Omni 1.1 Flash 4K को natively render करता है?

नहीं। Google का model reference इसे "4K output (upscaled)" बताता है: generation किसी नीचे वाले आंतरिक raster पर होता है और frame delivery से पहले बड़ा किया जाता है, और वह आंतरिक resolution छापा नहीं जाता। फिर भी, 1080p से गुज़रते round trip के मुक़ाबले मापने पर फ़ाइल उससे ऊपर असली संरचना रखती है जो 1080p ले जा सकता था — बनावट वाले इलाक़ों में मोटे तौर पर noise floor का तीन गुना, जबकि pixels नौ गुना। एक असली अधिशेष, पर तस्वीर के नौ गुने जैसा कुछ नहीं।

Gemini Omni 1.1 Flash पर 4K की क़ीमत क्या है?

E2X पर $0.18 प्रति सेकंड — चार सेकंड के $0.72, आठ के $1.44, अधिकतम लंबाई वाली दस सेकंड की generation के $1.80। सीधे Google को कॉल करना प्रति सेकंड $0.3041 पड़ता है, उसके छापे token आँकड़ों से निकालकर। fal.ai $0.30, Runware $0.32, WaveSpeed $0.39 दर्ज करते हैं। Replicate किसी भी resolution पर प्रति-सेकंड दर नहीं छापता।

Providers के बीच क़ीमत का फ़र्क़ 4K पर ही सबसे बड़ा क्यों है?

क्योंकि जो अलग है वह आधार दर नहीं, सबसे ऊपरी पायदान पर लगने वाला गुणक है। 720p को 1× मानें तो Google की सीढ़ी 0.33, 1, 1.5 और 3 चलती है; हमारी 0.33, 1, 1.5 और 2। दोनों नीचे के तीन पायदानों पर सहमत हैं और चौथे पर अलग होते हैं, जहाँ Google upscale के लिए तीन गुना करता है और हम दो गुना। वही एक क़दम पूरा इकतालीस प्रतिशत है।

4K की दर चुकाना कब सार्थक है?

जब आयाम ही शर्त हों: ऐसा delivery spec जो UHD raster का नाम लेता हो और स्वचालित QC से जाँचा जाता हो; ऐसा archive master जिससे आप आगे के deliverables काटेंगे; reframe की गुंजाइश, क्योंकि Omni सिर्फ़ 16:9 और 9:16 देता है; बड़े फ़ॉर्मैट या DOOH प्रदर्शन, जहाँ panel का pitch स्रोत तय करता है; और compositing plates, जिन्हें pixel संख्या चाहिए और जिन्हें spec पर ही ख़त्म होना है।

मुझे 4K पर render करने से कब बचना चाहिए?

Vertical social में, जहाँ platforms ingest पर दोबारा encode करते हैं और लंबी भुजा को UHD से काफ़ी नीचे बाँधते हैं; उन web embeds में जो कुछ सौ pixel चौड़ाई पर चलते हैं, जहाँ अतिरिक्त वज़न पैसे के साथ-साथ page performance भी ले जाता है; और हर आंतरिक अनुमोदन pass में, जो आकार और गति का फ़ैसला है और draft tier पर लागत के एक छोटे हिस्से में हो जाता है।

क्या prompt में "4K" या "ultra detailed" लिखने से output बेहतर होता है?

नहीं। Resolution एक API parameter है और prompt का text उसे नहीं चुनता। डिटेल वाले विशेषण ग़लत चरण को संबोधित हैं: बढ़ाव generation के बाद चलता है और prompt कभी नहीं पढ़ता। वह संरचना जोड़ता तो है — हमने मापा — पर आपका लिखा कुछ भी यह नहीं चलाता कि वह क्या जोड़े। Lens का चुनाव, रोशनी की दिशा और camera की गति बदलती हैं कि resize से पहले क्या render होगा, और prompt के शब्द अपनी जगह वहीं कमाते हैं।

क्या मैं 4K Omni clip को गुणवत्ता खोए बिना vertical में crop कर सकता हूँ?

आमतौर पर हाँ, और tier के लिए यही सबसे मज़बूत व्यावहारिक तर्क है। UHD से बीच का 9:16 crop 1215 pixel चौड़ा होता है, इसलिए 1080 चौड़ी vertical delivery एक downscale है। वही crop 1080p से 608 चौड़ा निकलता है और उसे पहले से compressed फ़ाइल से दोबारा बड़ा करना पड़ता है। Punch-in भी यही तर्क मानते हैं: UHD पर 1.5× reframe फिर भी native 1920 गुणा 1080 छोड़ता है।

क्या वही seed किसी दूसरे resolution पर वही shot देता है?

नहीं, और इसने हमें चौंकाया। एक prompt, तय seed पर, 720p और फिर 4K पर render करने से दो अलग shots लौटे — bench के उलटी तरफ़ रखी चीज़ें, pigment के कटोरों की अलग संख्या और अलग तरतीब, camera की अलग ऊँचाई। seed के निर्धारण को सिर्फ़ एक ही resolution के भीतर वैध मानिए, और ऐसी योजना मत बनाइए कि shot सस्ते में मंज़ूर करके फिर ठीक उसी shot को बड़े में render कर लेंगे।