एचडीआर कैसे काम करता है?


17

मैं यह समझने की कोशिश कर रहा हूं कि एचडीआर क्या है और यह कैसे काम करता है।

मैं बुनियादी अवधारणाओं को समझता हूं और थोड़ा सा विचार है कि इसे डी 3 डी / एचआरएसएल के साथ कैसे लागू किया जाता है।

हालांकि यह अभी भी बहुत धूमिल है।

कहते हैं कि मैं पृथ्वी की बनावट और सितारों के रूप में कार्य करने के लिए कोने की एक छोटी सी सूची के साथ एक क्षेत्र प्रदान कर रहा हूं, मैं इसे एचडीआर में कैसे प्रस्तुत करूंगा?

यहाँ कुछ चीजें हैं जिनके बारे में मुझे भ्रम है:

  • मैं अनुमान लगा रहा हूं, मैं बनावट के लिए बस किसी भी मूल छवि प्रारूप का उपयोग नहीं कर सकता क्योंकि मान एक सीमा में [0, 255] तक सीमित होंगे और [0, 1] से जुड़े होंगे। वही पीछे के बफर के लिए जाता है, मैं इसे लेता हूं प्रारूप को एक फ्लोट बिंदु प्रारूप होने की आवश्यकता है?

  • अन्य कदम क्या शामिल हैं? निश्चित रूप से एक रेंडर टारगेट को रेंडर करने के लिए फ्लोटिंग पॉइंट फॉरमेट का उपयोग करने से ज्यादा कुछ होना चाहिए और फिर पोस्ट प्रोसेस के रूप में कुछ ब्लॉम लागू करें? (वैसे भी आउटपुट 8bpp होगा) पर विचार

मूल रूप से, एचडीआर के लिए कदम क्या हैं? यह कैसे काम करता है ? मुझे लगता है कि इस के अलावा अन्य किसी भी अच्छे कागजात / लेख को प्रक्रिया का वर्णन नहीं किया जा सकता है , लेकिन यह मूल बातें पर थोड़ा ध्यान केंद्रित करता है, इसलिए यह भ्रामक है।

जवाबों:


19

एचडीआर तकनीक आपको पारंपरिक प्रकाश / बनावट के मुकाबले स्क्रीन पर देखने की तुलना में अधिक से अधिक विस्तार की नकल करने की अनुमति देती है। आप इसकी तुलना इस बात से कर सकते हैं कि प्रकाश की विभिन्न मात्राओं के संपर्क में आने पर आंख कैसे व्यवहार करती है - जब बहुत ज्यादा रोशनी होती है तो आंखें कम रोशनी देती हैं, तब भी चीजें आपकी दृश्यमान सीमा में होती हैं। जब पर्याप्त प्रकाश नहीं होता है, तो आईरिस अधिक खुलता है इसलिए अधिक विवरण देखे जा सकते हैं।

bit-tech.net HDR तुलना

इस छवि का दाहिना हाथ एचडीआर का उपयोग कर रहा है। यह रंगों की सीमा का अधिक उपयोग करता है, गहरे रंग गहरे होते हैं और उज्ज्वल क्षेत्र उज्जवल होते हैं। छवि के बाएं हाथ की तुलना में थोड़ा सपाट दिखता है।

बुनियादी कदम हैं:

  1. अपने मॉडल पर अन्य फ़्लोटिंग पॉइंट टेक्सचर का उपयोग करके फ़्लोटिंग पॉइंट टेक्सचर (A16B16G16R16F जैसे प्रारूप के साथ) और / या लाइट्स जिनकी चमक 1.0f से अधिक हो सकती है, को रेंडर करें।

  2. इस बनावट को प्रदर्शित करने के लिए दृश्यमान रंगों की सीमा को आपकी स्क्रीन पर प्रदर्शित करने योग्य किसी चीज़ में परिवर्तित करने की आवश्यकता है - इस प्रक्रिया को टोन मैपिंग कहा जाता है , और विभिन्न प्रभावों को प्राप्त करने के लिए विभिन्न प्रकार के टोन मैपिंग समीकरणों का उपयोग किया जा सकता है। यह एक जरूर है क्योंकि मॉनिटर रंग या ल्यूमिनेंस की पूरी श्रृंखला को प्रदर्शित नहीं कर सकता है जिसे हम फ्लोटिंग पॉइंट टेक्सचर में स्टोर कर सकते हैं (यदि यह संभव हो तो शांत होगा, लेकिन यह एक अंधा खतरा भी होगा ...)।

  3. ब्लूम और अन्य प्रभावों के बाद जोड़ दी गई चीजों के ल्यूमिनेंस में अंतर को और अधिक बढ़ा दिया जाता है। ब्लूम की गणना फ्लोटिंग पॉइंट बफर से की जाती है और इसे टोन मैप्ड इमेज के साथ जोड़ा जाता है।

उम्मीद है की वो मदद करदे


मुझे पता है कि यह एक (बहुत) पुराना सवाल है, लेकिन क्या आप मुझे एक अच्छे लेकिन सरल टोन मैपिंग एल्गोरिदम का उल्लेख कर सकते हैं?
JSQuareD

6

तकनीकी रूप से, एचडीआर का अर्थ केवल आपके ग्राफिक्स के लिए संभावित मूल्यों की एक बड़ी श्रृंखला का उपयोग करना है। आमतौर पर आप लाल, हरे और नीले चैनलों के लिए 256 असतत मानों तक सीमित रहते हैं, जिसका अर्थ है कि यदि आपके पास 2 आइटम हैं, तो एक दूसरे के समान दो बार उज्ज्वल है, और एक 3 जी जो पहले की तुलना में 10,000 गुना उज्ज्वल है, कोई नहीं है जिस तरह से आप एक ही दृश्य में सभी 3 को सही ढंग से प्रस्तुत कर सकते हैं - आप या तो पहले की तुलना में उज्ज्वल वस्तु को केवल 256x उज्जवल बनाते हैं, या आप दोनों सुस्त वस्तुओं को पूरी तरह से काला कर देते हैं (उनके बीच विपरीत को खोने) और फिर उज्ज्वल वस्तु असीम रूप से उज्जवल है उन दोनों की तुलना में।

लाल / हरे / नीले मूल्यों के लिए फ्लोटिंग पॉइंट वैल्यू का उपयोग करके इसे ठीक करना आसान है - लेकिन अब आपके सामने यह समस्या है कि इसे कैसे प्रदर्शित किया जाए एक ग्राफिक्स डिवाइस पर जो प्रति चैनल निश्चित संख्या में असतत मान (जैसे 256) को हैंडल करता है। । तो समस्या का दूसरा हिस्सा यह है कि अपने फ़्लोटिंग पॉइंट मानों को सीमित सीमा तक कैसे मैप किया जाए। तुच्छ समाधान सभी मानों को असतत सीमा में स्केल करना है, लेकिन इसका मतलब यह होगा कि 1 बहुत उज्ज्वल पिक्सेल स्क्रीन के बाकी हिस्सों को काला कर सकता है, आदि कभी-कभी यही आप चाहते हैं, कभी-कभी यह नहीं है - सिस्कोपफोन के टोन मैपिंग देखें। आप इसे कैसे देख सकते हैं, इसके उदाहरणों के लिए लिंक।

यह आम तौर पर आपके बनावट नहीं होते हैं जिन्हें एक नए प्रारूप में संग्रहीत करने की आवश्यकता होती है - यह तब होता है जब प्रकाश उन पर लागू होता है जो आपको बड़े मूल्यों को समायोजित करने में सक्षम होने की आवश्यकता होती है। जाहिर है, लेकिन अगर आपके पास प्रकाश स्रोत हैं जो बनावट में पके हुए हैं - जैसे। तारों की पृष्ठभूमि - आप वहां एक उच्च रिज़ॉल्यूशन प्रारूप चाहते हैं। या जब उन्हें रेंडर करने का समय आता है, तो ऐसी सामग्रियों के मूल्यों को बढ़ा दिया जाता है।


5

कंप्यूटर ने पारंपरिक रूप से प्रत्येक पिक्सेल को स्क्रीन पर केवल 24 बिट्स मेमोरी में प्रतिनिधित्व किया: 8 लाल के लिए, 8 हरे रंग के लिए, और 8 नीले रंग के लिए। यह लगभग पर्याप्त बिट्स है जो एक मानव नोटिस नहीं करेगा यदि आपने अधिक जोड़ा है, और 8-बिट बाइट माइक्रोप्रोसेसरों के लिए बहुत सुविधाजनक है, इसलिए यह अटक गया है।

जबकि 8 बिट्स एक छवि प्रदर्शित करने के लिए लगभग पर्याप्त सटीकता है , यह निश्चित रूप से एक छवि की गणना करने के लिए पर्याप्त सटीकता नहीं है । छवि की गणना करते समय विभिन्न बिंदुओं पर, कम से कम 32 बिट्स की सटीकता की आवश्यकता होती है।

यही कारण है कि पिक्सेल शेड्स 32-बिट परिशुद्धता में रंगों की गणना करते हैं, तब भी जब आप 8-बिट सटीक छवि प्रदान कर रहे हैं। अन्यथा, आप उदाहरण के लिए 1000 से किसी मूल्य को विभाजित नहीं कर सकते हैं, और फिर बाद में इसे 1000 से गुणा कर सकते हैं, क्योंकि शून्य में 1000 परिणामों से किसी भी 8-बिट मूल्य को विभाजित करना ।

अंतिम समय तक सभी ग्राफिक्स को 8 बिट में रखने की दिशा में रीयलटाइम 3 डी ग्राफिक्स का चलन रहा है, जिस समय> 8 बिट्स लाल को 8 बिट्स तक डाउनस्लेम किया जाता है, और आगे ग्रीन और ब्लू के लिए।

एचडीआर उन छवियों को प्रस्तुत करने के कार्य को संदर्भित करता है जिनमें 8-बिट परिशुद्धता से अधिक है। समकालीन टीवी वीडियोगेम में, 16-बिट सटीक मानदंड है, और आने वाले वर्षों के लिए वीडियोगेम में यह "पर्याप्त" हो सकता है।


2

एक पहलू जो मुझे लगता है कि एचडीआर के लिए महत्वपूर्ण है मॉनिटर गामा का सही अनुप्रयोग है।

आप जिस मॉनिटर को देख रहे हैं, वह इनपुट पिक्सल के एक फंक्शन के रूप में प्रकाश पैदा करता है। आप उम्मीद कर सकते हैं कि मूल्य 255 के साथ एक पिक्सेल मूल्य 1 के साथ पिक्सेल की तुलना में 255 गुना अधिक (लगभग) उत्पादन करेगा। यह मामला नहीं है। 2.3 के मानक मॉनिटर गामा के साथ, यह 255 ^ 2.3 गुना तेज है, या लगभग 340000 है!

सामग्री (कैमरा मैनिफ़ेक्चरर) बनाने वाला हर कोई यह जानता है, या (यदि आप एक डिजाइनर हैं) तो आप इसके लिए क्षतिपूर्ति करते हैं।

यह सब ठीक है यदि आप बस बिटमैप (ज्यादातर समय) को प्रस्तुत करते हैं, लेकिन यदि आप उन्हें 3D दृश्य में बनावट के रूप में उपयोग करते हैं तो यह एक अलग कहानी है। यदि आप प्रकाश के साथ बातचीत को सही ढंग से करना चाहते हैं, तो आपको रेंडरिंग पाइपलाइन में रैखिक प्रकाश गणना का उपयोग करना चाहिए। इसका मतलब है की

  • गामा के लिए अपने बनावट को सही करना

  • सब कुछ रैखिक प्रकाश के साथ प्रस्तुत करें (जहां आपको उच्च गतिशील रेंज प्रकाश की वजह से बहुत अधिक सटीकता की आवश्यकता होती है),

  • इससे पहले कि आप स्क्रीन पर छवि डालते हैं, अंतिम चीज़ के रूप में मॉनिटर के उलटा गामा परिवर्तन लागू करें।

जब आप मौजूदा दृश्य को मौजूदा कलाकृति, रोशनी, आदि के साथ बदलते हैं, तो आपको संभवतः अपनी हल्की तीव्रता और बनावट को ठीक करना होगा, क्योंकि गैर-रैखिक प्रकाश के साथ प्रतिपादन करते समय उन्हें अच्छा दिखने के लिए चुना गया था। तो यह एक ऐसी सुविधा नहीं है जिसे आप सिर्फ "चालू" कर सकते हैं और यह अपेक्षा कर सकते हैं कि सब कुछ उसी तरह बेहतर हो।


2
गामा निश्चित रूप से महत्वपूर्ण है, और भौतिक रूप से आधारित प्रतिपादन प्राप्त करने के लिए महत्वपूर्ण है, लेकिन सीधे एचडीआर, आईएमओ के साथ कुछ भी नहीं करना है।
नाथन रीड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.