अल्ट्रा एचडीआर इमेज फ़ॉर्मैट v1.1

परिचय

इस दस्तावेज़ में, एक नए फ़ाइल फ़ॉर्मैट के काम करने के तरीके के बारे में बताया गया है. यह फ़ॉर्मैट, लॉगारिदमिक रेंज गेन मैप इमेज को JPEG इमेज फ़ाइल में बदल देता है. नए फ़ॉर्मैट के साथ काम न करने वाले लेगसी रीडर, इमेज फ़ाइल से सामान्य तौर पर कम डाइनैमिक रेंज वाली इमेज को पढ़ते और दिखाते हैं. इस फ़ॉर्मैट के साथ काम करने वाले रीडर, मुख्य इमेज को गेन मैप के साथ जोड़ते हैं. साथ ही, काम करने वाले डिसप्ले पर हाई डाइनैमिक रेंज इमेज को रेंडर करते हैं.

इस दस्तावेज़ के बाकी हिस्से में, इस फ़ॉर्मैट का इस्तेमाल करने के लिए ज़रूरी प्रोसेस के तरीकों के बारे में बताया गया है. इस फ़ॉर्मैट के मुताबिक, किसी इमेज का लाइफ़ साइकल इस तरह का होता है:

1. एन्कोडिंग

   1. मैप जनरेशन
   2. मैप को कंप्रेस करें
   3. मैप कंटेनर जनरेट करें

2. डिकोड किया जा रहा है

पहला डायग्राम. फ़ाइल लेआउट और काम के मेटाडेटा का उदाहरण.

वजह

इस फ़ाइल फ़ॉर्मैट का मकसद एसडीआर इमेज फ़ाइलों में ज़्यादा जानकारी को कोड में बदलना है. इस जानकारी को डिसप्ले तकनीक के साथ एक ही फ़ाइल में अपने लिए सबसे सही एचडीआर क्वालिटी में बनाने के लिए इस्तेमाल किया जा सकता है.

यह सुविधा काम की हो, इसके लिए फ़ाइल फ़ॉर्मैट में ये चीज़ें होनी चाहिए:

• पुराने सिस्टम के साथ काम करने की सुविधा हो, ताकि नए दर्शकों को सामान्य एसडीआर इमेज दिखे.
• यह बहुत ज़्यादा जगह नहीं लेता है.

इसके अलावा, डिसप्ले तकनीक में ये चीज़ें भी होनी चाहिए:

• डिकोड करने के लिए भारी प्रोसेसिंग की ज़रूरत नहीं होती.
• डिसप्ले के एचडीआर और एसडीआर के व्हाइट पॉइंट के बीच के अनुपात के हिसाब से काम करना चाहिए. यह अलग-अलग डिवाइस के हिसाब से अलग-अलग हो सकता है या किसी एक डिवाइस पर थोड़े समय के लिए भी हो सकता है.

आखिर में, इस तकनीक से पहले की सभी कार्रवाइयां करने में सक्षम होना चाहिए, यह ज़रूरी नहीं है:

• हाइलाइट की गई क्लिप.
• गहरे हिस्सों को हल्का करना.
• लोकल कंट्रास्ट को बदलना या कंप्रेस करना.
• सीन में मौजूद ऑब्जेक्ट के बीच, टोन के रिलेटिव रिलेशनशिप में बदलाव करना.

डिपेंडेंसी

इस स्पेसिफ़िकेशन के लिए, यहां दिए गए रेफ़रंस मान्य हैं:

• Adobe XMP स्पेसिफ़िकेशन का तीसरा भाग: Files में स्टोरेज
• ISO 16684-1:2019 XMP की खास जानकारी का पहला हिस्सा
• आईएसओ/आईईसी 14496-12 आईएसओ बेस मीडिया फ़ाइल फ़ॉर्मैट
• T.81 (09/92) डिजिटल कंप्रेशन और कंटिन्यूअस स्टिल इमेज की कोडिंग
• CIPA DC-x 007-2009 मल्टी-पिक्चर फ़ॉर्मैट का व्हाइट पेपर

परिभाषाएं

• एसडीआर डिसप्ले

  • एक सामान्य डिसप्ले, जिसे एचडीआर कॉन्टेंट दिखाने के लिए डिज़ाइन नहीं किया गया है. आम तौर पर, इन डिसप्ले में 400 cd/m² या इससे कम की सबसे ज़्यादा चमक होती है.

• एचडीआर डिसप्ले

  • एचडीआर कॉन्टेंट के लिए डिज़ाइन किया गया डिसप्ले. आम तौर पर, ये डिसप्ले एसडीआर डिसप्ले के मुकाबले ज़्यादा चमक पैदा करते हैं. आम तौर पर, इनकी चमक 800 सीडी/एम² या इससे ज़्यादा होती है. साथ ही, आम तौर पर इनका कंट्रास्ट रेशियो भी एसडीआर डिसप्ले के मुकाबले बेहतर होता है.

• मुख्य इमेज

  • GContainer फ़ाइल में मौजूद इमेज का पहला इंस्टेंस, जिसमें सेकंडरी मीडिया फ़ाइलें जोड़ी गई हैं. मुख्य इमेज में GContainer XMP मेटाडेटा शामिल है, जो फ़ाइल कंटेनर में बाद के सेकंडरी मीडिया आइटम फ़ाइलों का क्रम और प्रॉपर्टी तय करता है.

• दूसरी इमेज

  • बाद में आने वाली मीडिया आइटम फ़ाइलें, जिन्हें किसी GContainer फ़ाइल की मुख्य इमेज में जोड़ा जाता है.

• रेंज कंप्रेस करना

  • फ़ोटोग्राफ़ी में, असल दुनिया के सीन में अक्सर ज़्यादा डाइनैमिक रेंज होती है, जितनी कि एसडीआर डिसप्ले दिखा सकता है. रेंज कंप्रेसन जैसे ऑपरेशन, इमेज की डाइनैमिक रेंज को कम करने के लिए ज़रूरी होते हैं. इन्हें लोकल टोन मैपिंग भी कहा जाता है. इस कमी के दौरान, हाइलाइट को क्लिप करने या शैडो को कम करने से बचना ज़रूरी है. साथ ही, लोकल कंट्रास्ट को जितना ज़्यादा हो सके उतना सुरक्षित रखा जाना चाहिए.आप इमेज में चमक के बड़े किनारों के साइज़ को कम करने की कोशिश करते हैं, जो इसके ग्लोबल कंट्रास्ट को ज़्यादा अहमियत देते हैं. साथ ही, छोटे चमक वाले किनारों के साइज़ को सुरक्षित रखने की कोशिश करते हैं.हालांकि, इसे इस्तेमाल करने के कई तरीके हैं, लेकिन आज के दौर में ज़्यादातर आधुनिक डिजिटल कैमरों पर इस तरह का तरीका अपनाया जाता है.

• एसडीआर व्हाइट पॉइंट

  • किसी डिसप्ले पर, किसी तय समय पर SDR कॉन्टेंट का ज़्यादा से ज़्यादा लीनियर ल्यूमिनेंस.

• एचडीआर व्हाइट पॉइंट

  • किसी समय पर डिसप्ले पर एचडीआर कॉन्टेंट की ज़्यादा से ज़्यादा लीनियर ल्यूमिनेंस. आम तौर पर, यह वैल्यू एसडीआर व्हाइट पॉइंट से ज़्यादा होती है.

• बूस्ट

  • एचडीआर के व्हाइट पॉइंट को एसडीआर के व्हाइट पॉइंट से भाग दिया जाता है.

• कॉन्टेंट बूस्ट की ज़्यादा से ज़्यादा सीमा (समीकरण में max_content_boost)

  • इस वैल्यू की मदद से, कॉन्टेंट क्रिएटर यह तय कर सकता है कि एसडीआर रेंडरेशन के मुकाबले, एचडीआर डिसप्ले पर इमेज कितनी ज़्यादा चमकदार दिखेगी.
  • यह वैल्यू, किसी इमेज के लिए कॉन्स्टेंट होती है. उदाहरण के लिए, अगर वैल्यू चार है, तो किसी भी पिक्सल के लिए, डिसप्ले किए गए एचडीआर रेंडर की लीनियर ल्यूमिनेंस, ज़्यादा से ज़्यादा एसडीआर रेंडिशन की लीनियर ल्यूमिनेंस से चार गुना होनी चाहिए. इसका मतलब है कि सीन के चमकीले हिस्सों को चार गुना ज़्यादा चमकीला दिखाया जा सकता है.
  • व्यावहारिक तौर पर, यह वैल्यू आम तौर पर 1.0 से ज़्यादा होती है.
  • यह हमेशा कॉन्टेंट के लिए मिलने वाले कम से कम बूस्टर से ज़्यादा या उसके बराबर होना चाहिए.

• कॉन्टेंट बूस्ट की कम से कम वैल्यू (समीकरणों में min_content_boost)

  • इस वैल्यू की मदद से, कॉन्टेंट क्रिएटर यह तय कर सकता है कि एसडीआर रेंडरेशन के मुकाबले, एचडीआर डिसप्ले पर इमेज कितनी गहरे रंग की हो सकती है. यह वैल्यू किसी खास इमेज के लिए एक जैसी रहती है.
  • उदाहरण के लिए, अगर वैल्यू 0.5 है, तो किसी भी पिक्सल के लिए, डिसप्ले किए गए एचडीआर रेंडर की लीनियर ल्यूमिनेंस, एसडीआर रेंडिशन की लीनियर ल्यूमिनेंस से 0.5 गुना होनी चाहिए.
  • व्यावहारिक तौर पर, यह वैल्यू आम तौर पर 1.0 के बराबर या उससे कम होती है.
  • हमेशा ज़्यादा से ज़्यादा कॉन्टेंट बूस्ट की वैल्यू से कम या इसके बराबर.

• डिसप्ले में ज़्यादा से ज़्यादा बढ़ोतरी (समीकरणों में max_display_boost)

  • किसी दिए गए समय में, डिसप्ले के साथ काम करने वाला ज़्यादा से ज़्यादा बूस्ट. यह वैल्यू समय के साथ बदल सकती है. ऐसा डिवाइस की सेटिंग और दूसरी चीज़ों, जैसे कि आस-पास की रोशनी की स्थिति या स्क्रीन पर कितने चमकदार पिक्सल होने पर होता है.
  • उदाहरण के लिए, अगर यह वैल्यू 4.0 है, तो डिसप्ले में ऐसा पिक्सल दिखाया जा सकता है जिसकी चमक एसडीआर के व्हाइट पॉइंट से चार गुना ज़्यादा हो. यह वैल्यू हमेशा 1.0 से ज़्यादा होती है, क्योंकि डिसप्ले हमेशा एचडीआर व्हाइट को कम से कम एसडीआर व्हाइट के तौर पर दिखा सकता है.

• डिसप्ले बूस्ट

  • यह कॉन्टेंट के लिए ज़्यादा से ज़्यादा और विज्ञापन के लिए ज़्यादा से ज़्यादा बूस्टर में से कम वैल्यू होती है. यह वैल्यू हमेशा >= 1.0 होती है.
  • उदाहरण के लिए, अगर कॉन्टेंट बूस्ट की ज़्यादा से ज़्यादा वैल्यू 4.0 और डिसप्ले बूस्ट की ज़्यादा से ज़्यादा वैल्यू 3.0 है, तो डिसप्ले बूस्ट की वैल्यू 3.0 होगी. पिक्सल की चमक एसडीआर की तुलना में तीन गुना ज़्यादा होती है, क्योंकि इसमें डिसप्ले सीमित होता है.
  • दूसरे उदाहरण के लिए, अगर कॉन्टेंट बूस्ट की ज़्यादा से ज़्यादा वैल्यू 4.0 है और मैक्स डिसप्ले बूस्ट 5.0 है, तो डिसप्ले बूस्ट की वैल्यू 4.0 होगी. पिक्सल, एसडीआर के मुकाबले चार गुना ज़्यादा चमकदार दिखते हैं, क्योंकि कॉन्टेंट का इंटेंट ही सीमित करने वाली फ़ैक्टर है.

• एचडीआर रेंडरिंग को टारगेट करें

  • कॉन्टेंट क्रिएटर के हिसाब से, HDR में वीडियो का सबसे सही रींडर.

• एडैप्टेड एचडीआर रेंडरिंग

  • डिसप्ले पर दिखाया जाने वाला फ़ाइनल एचडीआर रेंडरेशन. यह रेंडरेशन, मौजूदा डिसप्ले बूस्ट के लिए टारगेट एचडीआर रेंडरेशन को अडैप्ट करने के बाद मिलता है.

• मैप पाएं (समीकरणों में recovery(x, y))

  • टारगेट एचडीआर रेंडरेशन बनाने के लिए, एसडीआर रेंडरेशन में हर पिक्सल को कितना चमकाना है, यह बताने वाला मैप. यह मैप, एक चैनल या कई चैनल वाला हो सकता है. मल्टी-चैनल मैप हर रंग के चैनल के लिए अलग फ़ायदे दिखाता है, जैसे कि लाल, हरा, और नीला. इस दस्तावेज़ में, एक चैनल वाले मैप के बारे में बताया गया है.

• clamp(x, a, b)

  • वैल्यू x को [a, b] की रेंज में क्लैंप करें.

• exp2(x)

  • बेस 2 एक्सपोनेंशिएशन; 2^x.

• floor(x)

  • x के बराबर या उससे कम का निकटतम पूर्णांक लौटाता है.

• log2(x)

  • आधार 2 का लॉगरिदम; log₂(x)

• pow(b, x)

  • एक्सपोनेंशिएशन; b^x.

• XMP

  • बड़े किए जा सकने वाले मेटाडेटा प्लैटफ़ॉर्म. यह एक ऐसा स्टैंडर्ड है जो इमेज कंटेनर में मेटाडेटा को एन्क्रिप्ट करने का तरीका तय करता है. इसे ISO 16684-1:2011(E) XMP स्पेसिफ़िकेशन पार्ट 1 के ज़रिए तय किया गया है.

• मल्टी-पिक्चर फ़ॉर्मैट

  • मल्टी-पिक्चर फ़ॉर्मैट, कैमरा और इमेजिंग प्रॉडक्ट असोसिएशन (CIPA) की एक तकनीक है. इसका इस्तेमाल, एक ही JPEG फ़ाइल में कई JPEG कोड वाली इमेज सेव करने के लिए किया जाता है.
  • ज़्यादा जानकारी के लिए, इससे जुड़ी डिपेंडेंसी, CIPA के व्हाइट पेपर, DC-x 007-2009 मल्टी-पिक्चर फ़ॉर्मैट देखें.

• कंटेनर

  • GContainer, एक इमेज कंटेनर में कई इमेज को स्टोर करने का एक तरीका है. इसमें एक इमेज को मुख्य इमेज माना जाता है. किसी भी अन्य इमेज को वैकल्पिक वर्शन या सहायक इमेज माना जाता है. XMP मेटाडेटा का इस्तेमाल, किसी भी अतिरिक्त इमेज की मौजूदगी और उसके मतलब के बारे में बताने के लिए किया जाता है. ज़्यादा जानकारी के लिए, GContainer के बारे में जानकारी सेक्शन देखें.

कोड में बदलें

इस सेक्शन में, ज़रूरी शर्तें पूरी करने वाली JPEG फ़ाइल को कोड में बदलने का तरीका बताया गया है. JPEG फ़ॉर्मैट के बारे में ज़्यादा जानकारी के लिए, T.81 (09/92) कंटिन्यूअस-टोन स्टिल इमेज की डिजिटल कंप्रेशन और कोडिंग देखें.

मैप जनरेशन

कैमरा इमेजिंग पाइपलाइन आम तौर पर रेंज कंप्रेस करने की प्रोसेस करती हैं, ताकि ज़्यादा डाइनैमिक रेंज के ल्यूमिनेंस डेटा को, सामान्य SDR डिसप्ले की कम रेंज में कंप्रेस किया जा सके. गेन मैप, मूल और ज़्यादा डाइनैमिक रेंज के ल्यूमिनेंस डेटा को वापस पाने के लिए ज़रूरी डेटा को सेव करने का तरीका उपलब्ध कराता है.

इस सेक्शन में नीचे दी गई कैलकुलेशन, फ़्लोटिंग पॉइंट अंकगणित पर आधारित हैं.

ध्यान दें: नीचे दिए गए फ़ॉर्मूले के बारे में बताने के लिए, इस दस्तावेज़ में यह माना गया है कि आपने सिंगल-चैनल गेन मैप का इस्तेमाल किया है.अगर ऐसा नहीं है, तो इन प्रॉपर्टी से जुड़े फ़ॉर्मूला का अनुमान, हर कलर चैनल के लिए लगाया जा सकता है. SDR(x, y) और HDR(x, y) को Ysdr(x, y) और Yhdr(x, y) में बदलने के बजाय, pixel_gain(x, y) को SDR(x, y) और HDR(x, y) के हिसाब से वेक्टर फ़ंक्शन के तौर पर तय किया जाता है. ज़रूरत पड़ने पर, हर चैनल के लिए मेटाडेटा वैल्यू का भी इस्तेमाल किया जाता है. जब भी मुमकिन हो, एक चैनल वाले गेन मैप का इस्तेमाल करें.

यहां दिए गए फ़ंक्शन, एसडीआर इमेज के बारे में बताते हैं:

• SDR'(x, y), तीन चैनल वाली प्राइमरी इमेज है. नॉन-लीनियर (आम तौर पर, गामा कोड में बदली गई) प्राइमरी इमेज होती है.
• SDR(x, y), तीन चैनल वाली मुख्य इमेज का लीनियर वर्शन है. इसे मुख्य इमेज के कलर स्पेस के लीनियर वर्शन में बदलकर मिलता है. उदाहरण के लिए, sRGB में ट्रांसफ़र फ़ंक्शन वाले कलर स्पेस से लेकर लीनियर कलर स्पेस तक, जो बुनियादी sRGB वाले कलर को बनाए रखता है.

Ysdr(x, y) फ़ंक्शन को 0.0 से 1.0 की रेंज में तय किया गया है. यह स्टैंडर्ड डाइनैमिक रेंज की प्राइमरी इमेज की लीनियर ल्यूमिनेंस है:

Ysdr(x, y) = primary_color_profile_to_luminance(SDR(x, y))

एचडीआर इमेज के लिए भी ऐसी ही परिभाषाएं मौजूद हैं.

• HDR'(x, y), तीन चैनलों वाली नॉन-लीनियर इमेज है. इसका मतलब है कि यह PQ या HLG में एन्कोड की गई इमेज है.
• HDR(x, y), तीन चैनल वाली लीनियर एचडीआर इमेज है.

Yhdr(x, y), एचडीआर इमेज के दिए गए पॉइंट पर चमक को दिखाता है:

Yhdr(x, y) = primary_color_profile_to_luminance(HDR(x, y))

कॉन्टेंट बूस्ट को ज़्यादा से ज़्यादा बढ़ाने के लिए, Yhdr(x, y) को 0.0 की रेंज में तय किया गया है.

एसडीआर और एचडीआर में ली गई इमेज का रिज़ॉल्यूशन एक जैसा होना चाहिए. एसडीआर इमेज की कलर प्रोफ़ाइल, एचडीआर इमेज के कलर स्पेस के बारे में बताती है.

उदाहरण के लिए, अगर एसडीआर प्राइमरी इमेज में Display-P3 कलर प्रोफ़ाइल है, तो एचडीआर इमेज को उस प्रोफ़ाइल के प्राइमरी कलर के हिसाब से तय किया जाता है. इसका मतलब है कि एचडीआर इमेज में Display-P3 के बुनियादी रंग भी होंगे.

गेन मैप की गिनती दो लीनियर इमेज से की गई है, जिनमें ज़रूरी एचडीआर इमेज की ल्यूमिनेंस, Yhdr(x, y), और स्टैंडर्ड रेंज ल्यूमिनेंस इमेज Ysdr(x, y) शामिल है.

pixel_gain(x, y) फ़ंक्शन को Yhdr(x, y) फ़ंक्शन और Ysdr(x, y) फ़ंक्शन के बीच के अनुपात से तय किया जाता है:

pixel_gain(x, y) = (Yhdr(x, y) + offset_hdr) / (Ysdr(x, y) + offset_sdr)

pixel_gain(x, y) फ़ंक्शन का काम करने का तरीका, लागू करने के तरीके के हिसाब से तय होता है. ऐसा तब होता है, जब Ysdr(x, y) और offset_sdr, दोनों शून्य हों.

उदाहरण के लिए, लागू करने की प्रोसेस में, pixel_gain(x, y) को 1.0 के तौर पर तय करके, Ysdr(x, y) और offset_sdr, दोनों के शून्य होने की स्थिति को मैनेज किया जा सकता है. इसके अलावा, लागू करने की सुविधा में शून्य offset_sdr का इस्तेमाल करके, ऐसी स्थिति से बचा जा सकता है.

लागू करने पर, offset_sdr और offset_hdr की वैल्यू चुनी जा सकती हैं.

सलाह: offset_sdr और offset_hdr के लिए 0.015625 (1/64) की वैल्यू का इस्तेमाल करें. इन वैल्यू का मकसद, काले बच्चों के आस-पास हाइट को बढ़ाने की क्षमता और गेन वैल्यू को सटीक तौर पर कोड में बदलने की क्षमता को संतुलित करना है. इन ऑफ़सेट वैल्यू को बढ़ाने से, map_max_log2 के लिए सही वैल्यू बनाए रखते हुए, काले रंग के करीब के रंगों को ठीक करने की क्षमता बढ़ जाती है. वैल्यू बहुत ज़्यादा बढ़ाने से, मैप ज़्यादा सटीक नहीं हो सकता.

गेन मैप एक स्केलर फ़ंक्शन है, जो कॉन्टेंट के ज़्यादा से ज़्यादा और कम से कम बूस्टर के हिसाब से, pixel_gain(x, y) को लॉगारिदमिक स्पेस में कोड करता है:

map_min_log2 = log2(min_content_boost)
map_max_log2 = log2(max_content_boost)

log_recovery(x, y) = (log2(pixel_gain(x, y)) - map_min_log2)
                   / (map_max_log2 - map_min_log2)
clamped_recovery(x, y) = clamp(log_recovery(x, y), 0.0, 1.0)
recovery(x, y) = pow(clamped_recovery(x, y), map_gamma)

recovery(x, y) फ़ंक्शन का व्यवहार, जहां pixel_gain(x, y) शून्य है, लागू करने के तरीके के हिसाब से तय होता है, क्योंकि log2(0) की वैल्यू तय नहीं है.

सलाह: pixel_gain(x, y) के शून्य होने पर, recovery(x, y) को 0.0 के तौर पर तय करें. ऐसा इसलिए है, क्योंकि recovery(x, y) का 0.0, सबसे ज़्यादा ऐट्यूनेशन दिखाता है, जिसे गेन मैप में सेव किया जा सकता है.

map_gamma एक फ़्लोटिंग पॉइंट नंबर है, जो 0.0 से ज़्यादा होना चाहिए. इसे लागू करने के दौरान चुना जाता है.

सलाह: map_gamma के तौर पर 1.0 का इस्तेमाल करें. अगर आपके गेन मैप में log_recovery(x, y) वैल्यू का डिस्ट्रिब्यूशन बहुत असमान है, तो आपके पास किसी दूसरी वैल्यू का इस्तेमाल करने का विकल्प है. उदाहरण के लिए, ऐसा तब हो सकता है, जब गेन मैप में एसडीआर रेंज (छोटी log_recovery(x, y) वैल्यू के तौर पर दिखाया गया) के ठीक ऊपर बहुत ज़्यादा जानकारी हो और एचडीआर रेंडरिंग की पसंदीदा चमक के सबसे ऊपरी हिस्से के लिए बहुत बड़ी map_max_log2 वैल्यू हो (बड़ी log_recovery(x, y) वैल्यू के तौर पर दिखाया गया). इस मामले में, 1.0 से ज़्यादा वैल्यू वाले map_gamma का इस्तेमाल किया जा सकता है, ताकि recovery(x, y), log_recovery(x, y) के लो एंड और हाई एंड, दोनों फ़ॉर्मैट में जानकारी को सटीक तरीके से कोड में बदल सके.

कॉन्टेंट बूस्ट की ज़्यादा से ज़्यादा वैल्यू और कम से कम कॉन्टेंट बूस्ट की वैल्यू, लागू करने के तरीके पर आधारित होती हैं. इन्हें कॉन्टेंट क्रिएटर अपने हिसाब से तय कर सकता है. कॉन्टेंट के लिए तय की गई ज़्यादा से ज़्यादा बढ़ोतरी, 1.0 या इससे ज़्यादा होनी चाहिए. कॉन्टेंट पर मिलने वाले कम से कम बूस्टर की वैल्यू, [0.0, 1.0] की रेंज में होनी चाहिए.

ध्यान दें: उदाहरण के लिए, मान लें कि इमेज कैमरे से ली गई है और कैमरे की इमेज-प्रोसेसिंग पाइपलाइन, ज़्यादा डाइनैमिक रेंज इनपुट पर रेंज कंप्रेस करके, एसडीआर इमेज जनरेट करती है. इसके बाद, ज़्यादा से ज़्यादा कॉन्टेंट बूस्ट और कम से कम कॉन्टेंट बूस्ट, रेंज कंप्रेशन की मात्रा के हिसाब से हो सकता है और यह इस बात पर भी निर्भर करता है कि इससे रोशनी के किन हिस्सों पर असर पड़ा.

अगर ऐसी पाइपलाइन, एसडीआर इमेज के मुकाबले एचडीआर इमेज के किसी भी हिस्से को एन्कोड नहीं करना चाहतीं, तो ऐसी पाइपलाइन 1.0 का कम से कम कॉन्टेंट बूस्ट चुन सकती हैं. इसके अलावा, अगर एसडीआर और एचडीआर रेंडरेशन के आधार पर गेन मैप जनरेट किया जाता है, तो कॉन्टेंट में होने वाले ज़्यादा से ज़्यादा और कम से कम बूस्टर को इन दोनों रेंडरेशन के बीच बदलने के लिए ज़रूरी ज़्यादा से ज़्यादा और कम से कम गेन के आधार पर तय किया जा सकता है.

कॉन्टेंट क्रिएटर्स या एडिटर, कॉन्टेंट को ज़्यादा से ज़्यादा बेहतर बनाने की सुविधा में बदलाव भी कर सकते हैं. इससे, इमेज दिखने पर एसडीआर और एचडीआर के बीच लाइमिनेंस में ज़्यादा से ज़्यादा अंतर को कंट्रोल किया जा सकता है.

recovery(x, y) में वैल्यू, [0.0, 1.0] की रेंज में होनी चाहिए.

ध्यान दें: आम तौर पर, इमेज में सबसे ज़्यादा चमकने वाली जगहों पर recovery(x, y) की वैल्यू 1.0 के आस-पास होती है. वहीं, इमेज के गहरे रंग वाली जगहों की वैल्यू 0.0 के आस-पास होती है.

गेन मैप को सेकंडरी इमेज JPEG में सेव किया जाता है. इसलिए, इसे 8-बिट, बिना साइन वाली पूर्णांक वैल्यू का इस्तेमाल करके एन्कोड किया जाना चाहिए. इसकी रेंज [0, 255] होनी चाहिए. हर वैल्यू, recovery(x, y) वैल्यू को दिखाती है और इसे सेकंडरी इमेज के एक पिक्सल में सेव किया जाता है.

साइन नहीं किए गए 8-बिट इंटिजर स्टोरेज के लिए, कोड में बदली गई वैल्यू को इस तरह बताया जाता है:

encoded_recovery(x, y) = floor(recovery(x, y) * 255.0 + 0.5)

एन्कोड फ़ंक्शन की गिनती फ़्लोटिंग पॉइंट में की जाती है और आखिर में, दिए गए तरीके के हिसाब से राउंड करके 8-बिट के बिना साइन वाले पूर्णांक के नतीजे में बदल दी जाती है.

इस एन्कोडिंग की वजह से, recovery(x, y) वैल्यू को 0.0 से 1.0 के बीच, आठ बिट के बिना साइन वाले पूर्णांक के तौर पर दिखाया जाता है. कोड में बदले गए गेन मैप को, JPEG के तौर पर सेकंडरी इमेज आइटम में सेव किया जाना चाहिए. लागू करने की प्रोसेस, JPEG कोड में बदलने के दौरान इस्तेमाल किए जाने वाले कम्प्रेशन की मात्रा चुनती है.

सलाह: ज़्यादातर JPEG एन्कोडिंग लागू करने के लिए, लागू किए गए JPEG एल्गोरिदम की क्वालिटी पैरामीटर को 100 में से 85 से 90 या इससे मिलते-जुलते पैरामीटर से शुरू करें.

गेन मैप को सेकंडरी इमेज में सेव करने के बाद, उसे MPF और GContainer XMP मेटाडेटा के साथ मुख्य इमेज में जोड़ दिया जाता है. मुख्य इमेज GContainer डायरेक्ट्री में, गेन मैप इमेज के लिए कोई आइटम होना चाहिए.

सेव किए गए गेन मैप का रिज़ॉल्यूशन, लागू करने के तरीके के हिसाब से तय किया जाता है. साथ ही, यह मुख्य इमेज के रिज़ॉल्यूशन से अलग हो सकता है. अगर स्टोरेज के लिए, गेन मैप को प्राइमरी इमेज से अलग रिज़ॉल्यूशन में स्केल किया जाता है, तो सैंपलिंग का तरीका, बायलाइनियर या उससे बेहतर होना चाहिए. साथ ही, इसे लागू करने का तरीका तय किया जाना चाहिए.

सलाह: गेन मैप को स्टोरेज से पहले, मुख्य इमेज के 1⁄4 साइज़ (हर डाइमेंशन पर 1⁄4) तक कम कर दें, जैसे कि 1920x1080 की प्राइमरी इमेज के लिए 480x270 गेन मैप. गेन मैप का आसपेक्ट रेशियो, प्राइमरी इमेज के आसपेक्ट रेशियो जैसा होना चाहिए.

गेन मैप का ओरिएंटेशन, प्राइमरी इमेज से मेल खाना चाहिए. अगर मौजूद है, तो सेव की गई गेन मैप इमेज में, EXIF जैसे कि किसी ओरिएंटेशन (स्क्रीन की दिशा) मेटाडेटा का इस्तेमाल नहीं किया जाता.

अगर यह मौजूद है, तो गेन मैप की कलर प्रोफ़ाइल का इस्तेमाल नहीं किया जाता.

मैप कंटेनर पाना

कलर प्रोफ़ाइल

मुख्य इमेज के लिए, ICC प्रोफ़ाइल के ज़रिए इमेज की कलर प्रोफ़ाइल को दिखाया जाना चाहिए.

सलाह: Display-P3 कलर प्रोफ़ाइल का इस्तेमाल करें.

XMP एट्रिब्यूट

मुख्य इमेज में XMP मेटाडेटा होता है, ताकि एचडीआर गेन मैप फ़ॉर्मैट के लिए, अतिरिक्त सेमैटिक जानकारी वाली कम से कम दो इमेज तय की जा सकें.

नीचे दिए गए सबसेक्शन में, इस फ़ॉर्मैट के बारे में खास जानकारी दी गई है. GContainer के साथ काम करने के सामान्य तरीके के बारे में ज़्यादा जानकारी, GContainer की जानकारी सेक्शन में दी गई है.

नीचे दी गई टेबल में एट्रिब्यूट की जिन वैल्यू के बारे में बताया गया है उन्हें, तय किए गए XMP बेसिक वैल्यू टाइप की XMP सामान्य वैल्यू के तौर पर सेव किया गया है.

आइटम सिमैंटिक मान

Item:Semantic प्रॉपर्टी, कंटेनर डायरेक्ट्री में मौजूद हर मीडिया आइटम के ऐप्लिकेशन का मतलब तय करती है.

वैल्यू	ब्यौरा
मुख्य	इससे पता चलता है कि मीडिया आइटम मुख्य इमेज है, जो कंटेनर में दिखाने के लिए तैयार है. डायरेक्ट्री में एक "प्राइमरी" आइटम होना चाहिए.
गेनमैप	इससे पता चलता है कि मीडिया आइटम, गेन मैप है. डायरेक्ट्री में ज़्यादा से ज़्यादा एक "GainMap" आइटम हो सकता है.

एचडीआर गेन मैप मेटाडेटा

गेन मैप मेटाडेटा, प्राइमरी इमेज का एचडीआर वर्शन बनाने के लिए, गेन मैप को समझने और लागू करने के तरीके के बारे में जानकारी कोड में बदलता है.

गेन मैप मेटाडेटा XMP एक्सटेंशन के लिए, XMP नेमस्पेस का यूआरआई http://ns.adobe.com/hdr-gain-map/1.0/ है. डिफ़ॉल्ट नेमस्पेस प्रीफ़िक्स hdrgm है.

यह मेटाडेटा, गेन मैप इमेज के XMP पैकेट में सेव होता है. साथ ही, गेन मैप इमेज के XMP के rdf:Description में ये प्रॉपर्टी दिखनी चाहिए:

नाम	टाइप	ब्यौरा
hdrgm:Version	टेक्स्ट	इस्तेमाल किए जा रहे गेन मैप फ़ॉर्मैट का वर्शन. यह वर्शन "1.0" है. Required.
hdrgm:BaseRenditionIsHDR	बूलियन	प्राइमरी इमेज की डाइनैमिक रेंज दिखाता है. "गलत" से पता चलता है कि मुख्य इमेज SDR है और गेन मैप को इसके साथ जोड़कर, एचडीआर रेंडिशन बनाया जा सकता है. "सही" से पता चलता है कि मुख्य इमेज एचडीआर है और गेन मैप को इसके साथ जोड़ा जा सकता है, ताकि एसडीआर रेंडिशन बनाया जा सके. "गलत" होना चाहिए. ज़रूरी नहीं; डिफ़ॉल्ट वैल्यू "गलत है" है.
hdrgm:GainMapMin	रीयल या ऑर्डर किए गए रीयल टाइम का कलेक्शन	map_min_log2 की वैल्यू सेव करता है. यह कम से कम कॉन्टेंट बूस्ट का log2 है. यह किसी पिक्सल पर, टारगेट एचडीआर रेंडरेशन के लिए, लीनियर ल्यूमिनेंस के कम से कम अनुमति वाले अनुपात को एसडीआर इमेज के अनुपात से (इसमें divide किया गया) सेट करता है. यह कोई एक रियाल या रीयल का ऑर्डर वाला कलेक्शन हो सकता है. रीयल के क्रम वाले कलेक्शन में, एक आइटम मौजूद हो सकता है जो सभी चैनलों पर लागू होता है. इसके अलावा, लाल, हरे, और नीले चैनलों के लिए तीन आइटम पर लागू होता है. यह hdrgm:GainMapMax से कम या इसके बराबर होना चाहिए. ज़रूरी नहीं; डिफ़ॉल्ट वैल्यू 0.0 है.
hdrgm:GainMapMax	रीयल या ऑर्डर किए गए रीयल टाइम का कलेक्शन	map_max_log2 की वैल्यू सेव करता है. यह ज़्यादा से ज़्यादा कॉन्टेंट बूस्ट का log2 है. यह किसी पिक्सल में, एसडीआर इमेज के मुकाबले टारगेट एचडीआर रेंडरिंग के लिए लीनियर ल्यूमिनेंस का ज़्यादा से ज़्यादा अनुपात है. यह कोई एक रियाल या रीयल का ऑर्डर वाला कलेक्शन हो सकता है. रीयल के क्रम में लगाए गए कलेक्शन में, एक ऐसा आइटम हो सकता है जो सभी चैनलों पर लागू होता हो. इसके अलावा, इसमें लाल, हरे, और नीले चैनलों के लिए, तीन आइटम भी हो सकते हैं. hdrgm:GainMapMin से ज़्यादा या इसके बराबर होना चाहिए. ज़रूरी है.
hdrgm:Gamma	रीयल या क्रम से लगाए गए रीयल का कलेक्शन	map_gamma की वैल्यू सेव करता है. यह गामा है, जिसे सेव किए गए मैप की वैल्यू पर लागू किया जाता है. यह एक रीयल वैल्यू या रीयल वैल्यू का क्रम से लगाया गया ऐरे हो सकता है. रीयल के क्रम वाले कलेक्शन में, इसमें एक आइटम हो सकता है जो सभी चैनलों पर लागू होता है या रेड, ग्रीन, और ब्लू चैनलों के लिए तीन आइटम. यह वैल्यू 0.0 से ज़्यादा होनी चाहिए. ज़रूरी नहीं; डिफ़ॉल्ट वैल्यू 1.0 है.
hdrgm:ऑफ़सेटSDR	रीयल या क्रम से लगाए गए रीयल का कलेक्शन	offset_sdr की वैल्यू सेव करता है. यह गेन मैप जनरेट करने और लागू करने के दौरान, SDR पिक्सल वैल्यू पर लागू होने वाला ऑफ़सेट है. यह एक रीयल वैल्यू या रीयल वैल्यू का क्रम से लगाया गया कलेक्शन हो सकता है. रीयल के क्रम वाले कलेक्शन में, एक आइटम हो सकता है जो सभी चैनलों पर लागू होता है. इसके अलावा, लाल, हरे, और नीले चैनलों के लिए तीन आइटम पर लागू होता है. यह वैल्यू 0.0 या उससे ज़्यादा होनी चाहिए. ज़रूरी नहीं; डिफ़ॉल्ट वैल्यू 0.015625 (1/64) है.
hdrgm:OffsetHDR	रीयल या ऑर्डर किए गए रीयल टाइम का कलेक्शन	offset_hdr की वैल्यू सेव करता है. यह ऑफ़सेट है, जिसे मैप बनाने और उसे लागू करने के दौरान एचडीआर पिक्सल की वैल्यू पर लागू किया जाता है. यह कोई एक रियाल या फिर रीयल का ऑर्डर वाला कलेक्शन हो सकता है. अगर रीयल के लिए व्यवस्थित किए गए कलेक्शन में एक आइटम है, तो यह सभी चैनलों पर लागू होगा. इसके अलावा, अगर इसमें तीन आइटम हैं, तो ये रेड, ग्रीन, और ब्लू चैनलों पर लागू होंगे. 0.0 या इससे ज़्यादा होना चाहिए. ज़रूरी नहीं; डिफ़ॉल्ट वैल्यू 0.015625 (1/64) है.
hdrgm:HDRCapacityMin	रीयल	hdr_capacity_min की वैल्यू सेव करता है. यह सबसे कम डिसप्ले बूस्ट वैल्यू का log2 है, जिसके लिए मैप लागू किया गया है. इस वैल्यू से यह भी तय होता है कि डिसप्ले में बढ़ोतरी के आधार पर, गेन मैप को कितना लागू करना है. यह वैल्यू 0.0 या उससे ज़्यादा होनी चाहिए. ज़रूरी नहीं; डिफ़ॉल्ट वैल्यू 0.0 है.
hdrgm:HDRक्षमतामैक्स	रियल	hdr_capacity_max की वैल्यू सेव करता है. यह मैप को पूरी तरह से लागू करने के लिए, ज़्यादा से ज़्यादा डिसप्ले बूस्ट वैल्यू का log2 है. इस वैल्यू का असर इस बात पर भी पड़ता है कि डिसप्ले में बढ़ोतरी के आधार पर, गेन मैप को कितना लागू करना है. यह वैल्यू, hdrgm:HDRCapacityMin से ज़्यादा होनी चाहिए. ज़रूरी है.

सलाह: जब भी हो सके, हर उस प्रॉपर्टी के लिए सिर्फ़ एक रीयल वैल्यू का इस्तेमाल करें जो एक वैल्यू या वैल्यू के कलेक्शन की अनुमति देती है. साथ ही, हर कलर चैनल के लिए एक वैल्यू का इस्तेमाल करें. HDRCapacityMax को GainMapMax के बराबर और HDRCapacityMin को GainMapMin या 0.0 से ज़्यादा पर सेट करें. इस दस्तावेज़ का बाकी हिस्सा यह मान लेता है कि उन सभी प्रॉपर्टी के लिए एक ही रीयल वैल्यू का इस्तेमाल किया जा रहा है जिनमें रीयल वैल्यू का कलेक्शन हो सकता है. इन प्रॉपर्टी के बारे में इस्तेमाल किए गए फ़ॉर्मूले के आधार पर, हर कलर चैनल के लिए फ़ॉर्मूले का इस्तेमाल किया जा सकता है. हालांकि, ऐसा तब होगा, जब ऐसा नहीं हो.

गेन मैप XMP का उदाहरण

गेन मैप के मान्य XMP पैकेट के इस उदाहरण में, शुरुआती जानकारी सेक्शन में बताई गई उदाहरण फ़ाइल से लिया गया मेटाडेटा शामिल है.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0"
     hdrgm:GainMapMin="-0.57609993"
     hdrgm:GainMapMax="4.7090998"
     hdrgm:Gamma="1"
     hdrgm:OffsetSDR="0.015625"
     hdrgm:OffsetHDR="0.015625"
     hdrgm:HDRCapacityMin="0"
     hdrgm:HDRCapacityMax="4.7090998"
     hdrgm:BaseRenditionIsHDR="False"/>
  </rdf:RDF>
</x:xmpmeta>

गेन मैप का एमपीएफ़ स्टोरेज

गेन मैप की इमेज को अतिरिक्त इमेज के तौर पर सेव करना चाहिए, जैसा कि CIPA-x 007-2009 मल्टी-पिक्चर फ़ॉर्मैट में बताया गया है. इसके बारे में डिपेंडेंसी सेक्शन में बताया गया है.

डिकोड करें

इस सेक्शन में, JPEG फ़ाइल से गेन मैप को डिकोड करने का तरीका बताया गया है.

फ़ॉर्मैट का सिग्नल

इस फ़ॉर्मैट के मुताबिक बनी JPEG फ़ाइल की पहचान, प्राइमरी इमेज के XMP पैकेट में hdrgm:Version="1.0" की मौजूदगी से की जा सकती है. यहां hdrgm, नेमस्पेस यूआरआई http://ns.adobe.com/hdr-gain-map/1.0/ है.

गेन मैप इमेज ढूंढना

इमेज को पार्स और डिकोड करने के बारे में जानकारी के लिए, नीचे दिया गया GContainer की जानकारी सेक्शन देखें. XMP में मौजूद "GainMap" सिमैंटिक आइटम rdf:Directory का इस्तेमाल, गेन मैप की इमेज की जगह के बारे में बताने के लिए किया जाता है. इसके अलावा, गेन मैप की जगह का पता लगाने के लिए, एमपीएफ़ इंडेक्स आईएफ़डी और स्कैनिंग इमेज के एक्सएमपी का इस्तेमाल किया जाता है.

अमान्य मेटाडेटा को मैनेज करना

अगर कोई ज़रूरी फ़ील्ड मौजूद नहीं है या किसी फ़ील्ड में अमान्य वैल्यू दी गई है, तो मेटाडेटा को अमान्य माना जाता है. कोई वैल्यू अमान्य हो सकती है, क्योंकि यह बताए गए टाइप के हिसाब से पार्स नहीं किया जा सकता. इसके अलावा, ऐसा इसलिए भी हो सकता है कि वह तय रेंज से बाहर हो.

अगर अमान्य मेटाडेटा मिलता है, तो गेन मैप को अनदेखा किया जाना चाहिए और एसडीआर की इमेज दिखाई जानी चाहिए.

डिसप्ले

एचडीआर गेन मैप फ़ॉर्मैट में एन्कोड की गई फ़ाइलों को, सामान्य एसडीआर डिसप्ले या ज़्यादा चमक वाले आउटपुट वाले एचडीआर डिसप्ले, दोनों पर रेंडर किया जा सकता है.

एचडीआर में बदले गए वीडियो बनाने के लिए, गेन मैप का इस्तेमाल करना 

इस सेक्शन में नीचे दी गई कैलकुलेशन, फ़्लोटिंग-पॉइंट अंकगणित पर आधारित हैं.

गेन मैप की इमेज से, encoded_recovery(x, y) सिंगल-चैनल, 8-बिट, और बिना साइन वाले इंटीजर की वैल्यू है.

अगर गेन मैप का रिज़ॉल्यूशन, प्राइमरी इमेज से अलग है, तो encoded_recovery(x, y) का पता लगाने के लिए, प्राइमरी इमेज की चौड़ाई और ऊंचाई की सीमा के आधार पर, x और y के लिए गेन मैप इमेज की फ़िल्टर की गई सैंपलिंग का इस्तेमाल किया जाता है. फ़िल्टर करने का तरीका बायलीनियर या बेहतर होना चाहिए. साथ ही, इसे लागू किया जाना चाहिए.

map_gamma की वैल्यू, hdrgm:Gamma मेटाडेटा फ़ील्ड से तय होती है.

लॉगारिद्मिक स्पेस में log_recovery(x, y), नॉर्मलाइज़्ड फ़्लोटिंग पॉइंट पिक्सल गेन है:

recovery(x, y) = encoded_recovery(x, y) / 255.0
log_recovery(x, y) = pow(recovery(x, y), 1.0 / map_gamma)

ज़्यादा से ज़्यादा डिसप्ले बूस्टर, स्केलर फ़्लोटिंग पॉइंट वैल्यू होती है. इसे मौजूदा एचडीआर व्हाइट पॉइंट और मौजूदा एसडीआर व्हाइट पॉइंट के बीच के अनुपात के तौर पर तय किया जाता है. यह वैल्यू, डिसप्ले सिस्टम से मिलती है और समय के साथ इसमें बदलाव हो सकता है.

hdr_capacity_max की वैल्यू, hdrgm:HDRCapacityMax मेटाडेटा फ़ील्ड से तय होती है. hdr_capacity_min को hdrgm:HDRCapacityMin मेटाडेटा फ़ील्ड से तय किया जाता है.

जब hdrgm:BaseRenditionIsHDR "गलत" होता है, तो weight_factor को इस तरह से तय किया जाता है:

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

जब hdrgm:BaseRenditionIsHDR "सही" है, तो दूसरा समीकरण इस तरह दिखता है:

weight_factor = 1.0 - clamp(unclamped_weight_factor, 0.0, 1.0)

gain_map_max की वैल्यू, hdrgm:GainMapMax मेटाडेटा फ़ील्ड से तय होती है. gain_map_min को hdrgm:GainMapMin मेटाडेटा फ़ील्ड से तय किया जाता है. offset_sdr को hdrgm:OffsetSDR मेटाडेटा फ़ील्ड से तय किया जाता है. offset_hdr को hdrgm:OffsetHDR मेटाडेटा फ़ील्ड से तय किया जाता है.

लीनियर फ़ॉर्मैट के एचडीआर वर्शन का हिसाब इस तरह से लगाया जा सकता है:

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

ज़रूरत पड़ने पर, लागू करने की प्रोसेस में HDR(x, y) पर ट्रांसफ़ॉर्म लागू किया जा सकता है, ताकि डेटा को डिसप्ले के हिसाब से जगह पर रखा जा सके. इस तरह का कोई भी बदलाव, रंग के हिसाब से सही होना चाहिए.

ध्यान दें: गेन मैप को पहले दिखाए गए तरीके (एक्सपोनेंशियल का इस्तेमाल करके) के मुताबिक लागू किया जाना चाहिए, ताकि डिसप्ले में ज़रूरत के मुताबिक बढ़ोतरी के साथ, इमेज के अलग-अलग हिस्सों के बीच सही रिलेटिव टोनल रिलेशनशिप (अलग-अलग ब्राइटनेस वाले हिस्सों के बीच) ठीक से जनरेट हो सके. अगर गेन मैप को किसी दूसरे तरीके से लागू किया जाता है, जैसे कि सिंपल लीनियर इंटरपोलेशन के ज़रिए, तो इमेज में रिलेटिव टोनल रिलेशनशिप सिर्फ़ ज़्यादा से ज़्यादा कॉन्टेंट बूस्टर पर सही होते हैं. साथ ही, बूस्टर के दूसरे फ़ैक्टर पर इनमें बदलाव होता है.

एडैप्ट किए गए एचडीआर रेंडरेशन को वापस पाने के लिए बताए गए तरीके का मतलब है कि डिसप्ले के बेहतर होने के साथ-साथ, डिसप्ले के नतीजे भी आसानी से ट्रांज़िशन हो जाते हैं. इस तरीके से, डिसप्ले का ऐसा नतीजा हमेशा मिलता है जो कॉन्टेंट क्रिएटर के इंटेंट से मेल खाता है. साथ ही, वह इमेज क्वालिटी की उन सभी ज़रूरी शर्तों को पूरा करता है जिनके बारे में मोटिवेशन सेक्शन में बताया गया है.

अगर कॉन्टेंट के लिए कम से कम बढ़ावा 1.0 से कम है, तो घटाने की मात्रा भी डिसप्ले के लिए ज़्यादा से ज़्यादा बढ़ावा और कॉन्टेंट के लिए ज़्यादा से ज़्यादा बढ़ावा के बीच के संबंध के आधार पर तय की जाती है. उदाहरण के लिए, अगर कॉन्टेंट के लिए ज़्यादा से ज़्यादा बूस्टर 4.0, कम से कम बूस्टर 0.5, और डिसप्ले के लिए ज़्यादा से ज़्यादा बूस्टर 2.0 है, तो डिसप्ले की गई इमेज का ज़्यादा से ज़्यादा अट्यूनेशन 0.5 के बजाय 0.7071 होगा. ऐसा तब होगा, जब डिसप्ले के लिए ज़्यादा से ज़्यादा बूस्टर 4.0 या उससे ज़्यादा हो.

GContainer की जानकारी

इस सेक्शन में, अन्य ज़रूरी शर्तों के बारे में बताया गया है, ताकि यह फ़ॉर्मैट GContainer एक्सएमएल मेटाडेटा के मुताबिक हो. मेटाडेटा को ISO 166841:2011(E) XMP स्पेसिफ़िकेशन पार्ट 1 के हिसाब से क्रम में लगाया जाता है. साथ ही, इसे मुख्य इमेज फ़ाइल में एम्बेड किया जाता है, जैसा कि Adobe XMP स्पेसिफ़िकेशन पार्ट 3 स्टोरेज इन फ़ाइल्स में बताया गया है. मुख्य इमेज फ़ाइल में ये आइटम होते हैं, जिन्हें RDF/XML फ़ॉर्मैट में फ़ॉर्मैट किया जाता है.

XMP पैकेट से जुड़ी ज़रूरी शर्तें

XMP पैकेट में, नेमस्पेस यूआरआई http://ns.adobe.com/hdr-gain-map/1.0/ के ज़रिए, गेन मैप मेटाडेटा XMP एक्सटेंशन शामिल होगा. नेमस्पेस का डिफ़ॉल्ट प्रीफ़िक्स hdrgm है.

XMP पैकेट में hdrgm:Version="1.0" की जानकारी होगी.

कंटेनर एलिमेंट

GContainer XMP एक्सटेंशन के लिए XMP नेमस्पेस, http://ns.google.com/photos/1.0/container/ है. डिफ़ॉल्ट नेमस्पेस प्रीफ़िक्स Container है.

मुख्य इमेज के XMP मेटाडेटा में एक Container:Directory एलिमेंट होता है. इससे फ़ाइल कंटेनर में आने वाली मीडिया फ़ाइल का क्रम और प्रॉपर्टी तय होती है. कंटेनर की हर फ़ाइल के लिए, Container:Directory में एक मीडिया आइटम होता है. मीडिया आइटम, फ़ाइल कंटेनर में मौजूद जगह और जोड़ी गई हर फ़ाइल की बुनियादी प्रॉपर्टी के बारे में बताता है.

कंटेनर एलिमेंट को मुख्य इमेज के XMP मेटाडेटा के तौर पर एन्कोड किया जाता है और कंटेनर में मीडिया आइटम की डायरेक्ट्री तय की जाती है. मीडिया आइटम, कंटेनर फ़ाइल में उसी क्रम में होने चाहिए जिस क्रम में डायरेक्ट्री में मीडिया आइटम एलिमेंट हैं. साथ ही, उन्हें कसकर पैक किया जाना चाहिए.

डायरेक्ट्री में सिर्फ़ एक "प्राइमरी" इमेज आइटम हो सकता है. यह डायरेक्ट्री का पहला आइटम होना चाहिए.

एलिमेंट का नाम	टाइप	ब्यौरा
कंटेनर:डायरेक्ट्री	स्ट्रक्चर का ऑर्डर वाला कलेक्शन	क्रम से लगाए गए स्ट्रक्चर का कलेक्शन. हर स्ट्रक्चर में एक Container:Item स्ट्रक्चर होता है, जिसमें कंटेनर के लेआउट और कॉन्टेंट की जानकारी होती है.

आइटम का एलिमेंट

आइटम के एलिमेंट बताते हैं कि ऐप्लिकेशन में हर मीडिया आइटम का इस्तेमाल कैसे किया जाता है.

GContainer आइटम के XMP एक्सटेंशन के लिए XMP नेमस्पेस यूआरआई, http://ns.google.com/photos/1.0/container/item/ है. डिफ़ॉल्ट नेमस्पेस प्रीफ़िक्स Item है.

पहला मीडिया आइटम, मुख्य इमेज होना चाहिए.  इसमें Item:Semantic = "Primary" और सामान के MIME टाइप की वैल्यू में दी गई Item:Mime की जानकारी होनी चाहिए.

मुख्य इमेज आइटम की लंबाई, मुख्य इमेज को पार्स करके तय की जाती है. यह पार्स करने के लिए, फ़ाइल कंटेनर की शुरुआत से लेकर MIME टाइप तक का इस्तेमाल किया जाता है.

मीडिया आइटम में एक Item:Padding एट्रिब्यूट हो सकता है, जो मीडिया आइटम के आखिर और अगले मीडिया आइटम की शुरुआत के बीच अतिरिक्त पैडिंग के बारे में बताता है. Container:Directory में आखिरी मीडिया आइटम पर मौजूद होने पर, Item:Padding से आइटम के आखिर और फ़ाइल के आखिर के बीच के पैडिंग के बारे में पता चलता है.

हर मीडिया आइटम में Item:Mime टाइप और Item:Semantic एट्रिब्यूट होने चाहिए. सेकंडरी इमेज मीडिया आइटम में Item:Length एट्रिब्यूट होने चाहिए.

क्रम में चलने वाले मीडिया आइटम, फ़ाइल कंटेनर में संसाधन का डेटा शेयर कर सकते हैं. पहला मीडिया आइटम, फ़ाइल कंटेनर में संसाधन की जगह के बारे में बताता है. साथ ही, शेयर किए गए बाद के मीडिया आइटम का Item:Length 0 पर सेट होता है. अगर रिसॉर्स डेटा खुद एक कंटेनर है, तो Item:URI का इस्तेमाल रिसॉर्स में मीडिया आइटम के डेटा की जगह तय करने के लिए किया जा सकता है.

कंटेनर में मीडिया आइटम रिसॉर्स की जगह तय करने के लिए, प्राइमरी इमेज को एन्कोड करने में लगने वाले समय, पहले से मौजूद सेकंडरी मीडिया आइटम रिसॉर्स की Item:Length वैल्यू, और पहले से मौजूद सभी Item:Padding वैल्यू को जोड़ा जाता है. जिन मीडिया आइटम रिसॉर्स में Item:Padding की वैल्यू नहीं दी गई है उन्हें 0 माना जाता है.

विशेषता नाम	टाइप	ब्यौरा
आइटम:माइम	टेक्स्ट	कंटेनर में मौजूद मीडिया आइटम के MIME टाइप की जानकारी देने वाली आसान स्ट्रिंग. परिभाषा के लिए, आइटम के MIME टाइप की वैल्यू का सेक्शन देखें. Required.
आइटम:अर्थ:	टेक्स्ट	मीडिया आइटम के लिए, ऐप्लिकेशन के हिसाब से दी गई आसान स्ट्रिंग. परिभाषा के लिए, आइटम सिमैंटिक वैल्यू वाला सेक्शन देखें. Required.
आइटम:लंबाई	पूर्णांक	ऐसी आसान स्ट्रिंग जिसमें आइटम की लंबाई बाइट में, धनात्मक पूर्णांक के तौर पर दी गई हो. लंबाई 0 बताती है कि मीडिया आइटम संसाधन पिछले मीडिया आइटम के साथ शेयर किया गया है. सेकंडरी मीडिया आइटम के लिए ज़रूरी है. मुख्य इमेज के लिए वैकल्पिक है.
आइटम:लेबल	टेक्स्ट	लागू करने के लिए तय की गई स्ट्रिंग, जिसका इस्तेमाल एक ही Item:Semantic वाले कई आइटम एलिमेंट के बीच अंतर करने के लिए किया जाता है. ज़रूरी नहीं.
आइटम:पैडिंग	पूर्णांक	एक स्ट्रिंग, जिसमें मीडिया आइटम के आखिर और अगले मीडिया आइटम के शुरू होने के बीच, अतिरिक्त पैडिंग के बाइट में एक सकारात्मक पूर्णांक की लंबाई होती है. इसके अलावा, Container:Directory में आखिरी मीडिया आइटम पर इस्तेमाल करने पर, फ़ाइल के आखिर में भी यह पैडिंग होती है. मौजूद न होने पर, वैल्यू को 0 माना जाता है. ज़रूरी नहीं.
Item:URI	टेक्स्ट	ISO/IEC 14496-12 सेक्शन 8.11.9 के मुताबिक यूआरआई स्ट्रिंग, जिसमें मीडिया आइटम संसाधन में मीडिया डेटा का मिलता-जुलता यूआरआई होता है. डिफ़ॉल्ट रूप से, मुख्य इमेज का संसाधन इस्तेमाल किया जाता है. ISO बेस मीडिया फ़ाइल फ़ॉर्मैट ISO/IEC 14496-12 MIME टाइप के लिए ज़रूरी नहीं है. इसे किसी और तरीके से इस्तेमाल नहीं किया जा सकता.

आइटम के MIME टाइप की वैल्यू

Item:Mime एट्रिब्यूट, हर मीडिया आइटम के डेटा के MIME टाइप के बारे में बताता है.

वैल्यू	ब्यौरा
image/jpeg	JPEG इमेज.

GContainer XMP का उदाहरण

नीचे दिए गए एक मान्य GContainer XMP पैकेट के उदाहरण में, उदाहरण वाली फ़ाइल से मेटाडेटा लिया गया है. इस फ़ाइल के बारे में शुरुआती जानकारी सेक्शन में बताया गया है.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

ISO 21496-1 संगतता

ISO 21496-1, इमेज फ़ाइल में गेन मैप मेटाडेटा को एन्कोड करने के लिए, एन्कैप्सुलेट करने का एक वैकल्पिक तरीका उपलब्ध कराता है. फ़ाइल में एक ही गेनमैप इमेज का इस्तेमाल करके, एक JPEG फ़ाइल में अल्ट्रा एचडीआर मेटाडेटा और आईएसओ 21496-1 मेटाडेटा, दोनों को एन्कोड किया जा सकता है.

दूसरी इमेज. अल्ट्रा एचडीआर और आईएसओ 21496-1 के मेटाडेटा वाली फ़ाइल के लेआउट का उदाहरण.

क्रॉस-प्लैटफ़ॉर्म के साथ बेहतर तरीके से काम करने के लिए, Android और ऐसे ऐप्लिकेशन जो गेन मैप वाली JPEG फ़ाइलों को खुद ही कोड में बदलते या डिकोड करते हैं उन्हें अल्ट्रा एचडीआर v1 और ISO 21496-1 मेटाडेटा, दोनों के लिए कोड में बदलने और डिकोड करने की सुविधा काम करनी चाहिए. कोड में बदलने की कार्रवाई के दौरान, लागू करने या ऐप्लिकेशन को दोनों मेटाडेटा फ़ॉर्मैट को कोड में बदलना चाहिए. अगर डिकोड करने की कार्रवाई के दौरान दोनों तरह के मेटाडेटा मौजूद होते हैं, तो लागू करने वाले या ऐप्लिकेशन को ISO 21496-1 मेटाडेटा का इस्तेमाल करना चाहिए.

ध्यान दें: Android 15 (एपीआई लेवल 35) से शुरू होने वाले JPEG के लिए, Android पर ISO 21496-1 एन्कोडिंग काम करती है और इसे डिकोड किया जा सकता है.Bitmap Android 15, Bitmap ऑब्जेक्ट से अल्ट्रा एचडीआर JPEG फ़ाइलों को कोड में बदलते समय, अल्ट्रा एचडीआर v1 मेटाडेटा और ISO 21496-1 मेटाडेटा, दोनों को कोड में बदल देता है. इसके अलावा, सही फ़्लैग चालू होने पर, एओएसपी की लिबुलट्राह्ड्र लाइब्रेरी ISO 21496-1 एन्कोडिंग के साथ काम करती है.

लॉग बदलें

इस सेक्शन में, इस स्पेसिफ़िकेशन के वर्शन के बीच हुए बदलावों के बारे में जानकारी दी गई है.

v1.1

अल्ट्रा एचडीआर से जुड़ी खास बातों के इस वर्शन में किए गए सभी बदलावों से जानकारी मिलती है. साथ ही, ये बदलाव इस बारे में भी हैं कि ISO 21496-1 के साथ यह वर्शन काम करता है या नहीं. फ़ाइल के असल फ़ॉर्मैट में कोई बदलाव नहीं किया जाता.

• ISO 21496-1 कम्पैटिबिलिटी सेक्शन जोड़ें.

v1.0

अल्ट्रा एचडीआर की खास बातों के बारे में शुरुआती पब्लिकेशन.