मैं .png फ़ाइल में गेम मेटाडेटा को कैसे संग्रहीत कर सकता हूं?


208

बीजाणु एक .pngफ़ाइल निर्यात करके खिलाड़ी-निर्मित प्राणियों को साझा करने की अनुमति देता है । यह .pngप्राणी की एक तस्वीर है, लेकिन अगर इसे खेल में आयात किया जाता है, तो प्राणी की जानकारी (जैसे बनावट, आकार और आकार) भी इसके साथ आती है।

मैं इस तरह की सुविधा को कैसे लागू कर सकता हूं?


5
बहुत अधिक अंक होना चाहिए, यह एक बहुत ही दिलचस्प सवाल है।
पियरे अरलाउड

3
अल्फा चैनल को इसके लिए आंशिक रूप से दुरुपयोग किया जा सकता है ...
टोबियास किन्ज़लर

3
संभवतः उपयोग करने के लिए: stackoverflow.com/questions/9542359/…
लॉजिक-यूनिट

1
मुझे लगता है कि इस डेटा को किसी अन्य फ़ाइल में संग्रहीत करना बेहतर है। इस फ़ाइल में, बनावट फ़ाइल का नाम होना चाहिए जो उस इकाई से संबंधित है जिसे आप डेटा संग्रहीत करना चाहते हैं। पहली खोज के लिए (png प्रारूप ग्राफिक्स के लिए है - "पोर्टेबल नेटवर्क ग्राफिक्स"), दूसरी बात: एक स्थिति पर विचार करें जहां आप एक इकाई के साथ और अधिक छवियों को संग्रहीत करना चाहते थे, आप बस उस कस्टम फ़ाइल से इसके संदर्भ जोड़ सकते हैं। आपको शायद एक PNG में विभिन्न छवियों (अलग-अलग आकार, अलग गहराई आदि) को संग्रहीत करने में समस्या होगी।
luke1985

3
अल्फा चैनल का भारी उल्लेख किया गया है, और निश्चित रूप से पीएनजी वैसे भी मेटा डेटा का समर्थन करते हैं, लेकिन मैंने अभी सोचा था कि मैं एक ऐसी तकनीक साझा करूँगा जिसका मैंने उपयोग किया है - बाएं से दाएं, ऊपर से नीचे और निश्चित क्रम में चैनलों के माध्यम से। , और मानों को ऑड्स या इवेंस पर गोल करना - इससे कोई फर्क नहीं पड़ता कि यह ऊपर या नीचे है। किसी भी चैनल में 1 का परिवर्तन कोई ध्यान देने योग्य अंतर नहीं बनाता है, और 256x256 छवि (4 पिक्सेल प्रति पिक्सेल पर) में, आप एक प्रभावशाली 32KB डेटा स्टोर कर सकते हैं। यदि आपको और भी अधिक की आवश्यकता है, तो आप इसके बजाय% 4 पर गोल कर सकते हैं - बहुत अधिक और यह एक पुराने GIF दिमाग की तरह
लगने लगता

जवाबों:


56

यदि आप सभी को वास्तव में पीएनजी फ़ाइल की आवश्यकता थी, तो संभावना है कि वे बस जानकारी को फ़ाइल में जोड़ दें। यह वास्तव में स्टेग्नोग्राफ़ी का अभ्यास है । बहुत बार, इसका उपयोग उन चीजों में पेलोड या गुप्त संदेशों को छिपाने के लिए किया जाता है, जो आम तौर पर सार्वजनिक रूप से सामना कर रहे हैं। हालांकि, इस मामले में यह संभावना है कि इस पद्धति का उपयोग किया गया था। ठेठ स्टेगॉन्ग्राफी सामग्री को छिपाने के लिए रास्ते से बाहर चला जाएगा, लेकिन ऐसा कोई कारण नहीं है कि कोई फ़ाइल के अंत में छवि से डेटा को केवल संलग्न नहीं कर सका और इसे पुनर्प्राप्त कर सकता है।

कई उपकरण आपके लिए इस डेटा को एनकोड करते हैं, एक Google खोज कम से कम यह और यह लाता है ।

एक PNG में $89शुरुआत में बाइट सिग्नेचर होता है, इसलिए यह संभव है कि PNG संरचना के बाद ही जानकारी डाली गई हो और केवल SPORE गेम द्वारा पार्स किया गया हो।

हालाँकि, अन्य उत्तरों द्वारा दिए गए शोध और Google पर एक खोज से पता चलता है कि Spore वास्तव में अल्फा बिट्स में जानकारी छिपाने के लिए Stegongraphy के सिर्फ एक संस्करण का उपयोग कर रहा था। इसे ध्यान में रखते हुए, हम अनुप्रयुक्त डेटा या मेटा-डेटा की संभावना को नियंत्रित कर सकते हैं।

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


3
जहां तक ​​मुझे पता है, पीएनजी के अल्फा चैनल के अंदर जमा मेटाडाटा को बख्शा।
तारा

28
जब PNG अनियंत्रित मेटाडेटा विखंडू का समर्थन करता है तो अल्फा चैनल या स्टेग्नोग्राफ़ी का उपयोग क्यों करें?
रसेल बोरोगोव

8
"पीएनजी के पास शुरुआत में बाइट सिग्नेचर" 89 "है, इसलिए यह बहुत संभावना है कि जानकारी पीएनजी संरचना से पहले या बाद में डाली गई थी और केवल SPORE गेम द्वारा पार्स की गई थी। यदि ऐसा होता, तो यह होता। ' अब PNG फ़ाइल न बनें। यानी सामान्य छवि के दर्शक इसे प्रदर्शित नहीं कर पाएंगे।
12

3
@RussellBorogove एक काफी अच्छा कारण है: अगर PNG को बीजाणु / स्पोड के अलावा किसी चीज़ से इनकोडिंग किया जाता है, तो मनमाना मेटाडेटा विखंडन वास्तविक छवि डेटा की तुलना में अनदेखा या खो जाने की अधिक संभावना है। छवि में डेटा एन्कोड करने से इस संभावना में सुधार होता है कि यदि आप इसे देख सकते हैं, तो आप इसे लोड कर सकते हैं
टिम एस।

@svick वास्तव में, मैंने एक फाइल के साथ खेला है जो एक मान्य PNG और RAR दोनों थी। पीएनजी के बाद आरएआर हेडर शुरू हुआ और आरएआर एक्सट्रैक्टर्स ठीक थे। यह दूसरे तरीके से भी ठीक काम कर सकता है।
कोर्टिस

153

PNG प्रारूप अधिक या कम मनमाने ढंग से मेटाडाटा के लिए समर्थन हासिल है। पीएनजी मानक एक PNG फ़ाइल, अनिवार्य रूप से हिस्सा, जिनमें से कुछ की आवश्यकता होती है (और छवि डेटा होते हैं) की एक श्रृंखला को परिभाषित करता है। अन्य, हालांकि, वैकल्पिक हैं। उदाहरण के लिए, गामा सूचना या हिस्टोग्राम डेटा संग्रहीत करने के लिए एक हिस्सा है।

विशेष रूप से, एक tEXtचंक है जिसका उपयोग मनमाने ढंग से कुंजी / मान पाठ जोड़े को संग्रहीत करने के लिए किया जा सकता है। इसका उपयोग किसी भी प्रकार के मनमाने डेटा के आसपास करने के लिए किया जा सकता है, बशर्ते आप उस डेटा को पाठ के रूप में दर्शा सकते हैं (जो कि काफी संभावना है)।

आपको एक पीएनजी लाइब्रेरी की आवश्यकता होगी जो आपको इन अतिरिक्त विखंडू (जैसे संदर्भ पुस्तकालय ) तक पहुंचने और हेरफेर करने की अनुमति देती है , या आपको खुद को लिखने की आवश्यकता होगी। फिर यह चुनने की बात है कि कुंजी / मान जोड़े के रूप में इच्छित डेटा को कैसे एनकोड करें। मैं निम्नलिखित सुझाव दूंगा:

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

अधिक पूर्ण उत्तर देने के हितों में, मैं यह भी बताऊंगा कि एक और दृष्टिकोण है (पूर्व में @Vaughn और @ एलेक्सिस के उत्तरों द्वारा प्रलेखित): अपने डेटा पिक्सेल में सीधे आपके इच्छित डेटा को वितरित करते हुए अतिरिक्त डेटा को एनकोड करें रंग चैनलों के कम क्रम बिट्स। इस दृष्टिकोण को अतिरिक्त मेटाडेटा के उपयोग की आवश्यकता नहीं है, जिसका अर्थ है कि आप इसे पूरी तरह से इस पर निर्भर किए बिना लागू कर सकते हैं या बाहरी कार्यक्रमों के बारे में चिंता करने से गलत तरीके से उस मेटाडेटा को संभाल सकते हैं। यह एक बहुत ही उच्च "शांत" कारक भी है, और क्योंकि आप केवल कम-क्रम बिट्स का उपयोग करते हैं, छवि अभी भी मानव आंख को सही दिखेगी। हालांकि, इसका मतलब यह है कि आपके द्वारा संग्रहीत किए जा सकने वाले डेटा की मात्रा के लिए आपकी छवि का आकार एक प्राथमिक नियंत्रण कारक है; यदि आपको अधिक संग्रहण की आवश्यकता है, तो आपको छवि के लिए और अधिक पिक्सेल आवंटित करने की आवश्यकता होगी।

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


3
एक बस बेस 64 के माध्यम से डेटा भेज सकता है और इसे एक ही मूल्य के रूप में संग्रहीत कर सकता है
कोडइन्चोस

11
@ da4c30ff मेटाडेटा के रूप में व्यावहारिक है, स्टेग्नोग्राफ़ी में एक निश्चित जासूस-कल्पना शांत कारक है जो हमारी भीड़ का विरोध करने के लिए कठिन है। यदि मैं खुद ऐसा कर रहा था, तो मैं स्केलेबिलिटी के लिए जोश पेट्री की प्रस्तावित विधि का उपयोग करूंगा, लेकिन मैं छवि में एक चेकसम को छिपाने के लिए स्टेग्नोग्राफ़ी का उपयोग करने के लिए प्रलोभित होना चाहूंगा कि यह सत्यापित करने के लिए कि छवि और पाठ एक दूसरे के हैं - क्योंकि नहीं यह उपयोगी या सुरक्षित है, लेकिन सिर्फ इसलिए कि यह शांत है। ;)
DMGregory

वास्तव में "टेक्स्ट" का क्या मतलब है? केवल ASCII (चरित्र <= 127)? 0 को छोड़कर कोई भी बाइट? कोई भी बाइट? या कुछ और? (यह द्विआधारी डेटा लिखने के लिए आपके द्वारा उपयोग किए जाने वाले एन्कोडिंग को प्रभावित करेगा। जैसे कि आपको base64 की आवश्यकता है या नहीं।)
svick

1
मैंने टेक्स्ट चंक के मानक के लिंक के साथ उत्तर को अपडेट किया; लेकिन मूल रूप से, पाठ की व्याख्या आईएसओ 8859-1 (8-बिट, सिंगल-बाइट, लैटिन -1 वर्ण) के अनुसार की जाती है।
जोश

51

मोनाको के डेवलपर ने वास्तव में एक उत्कृष्ट लेख बनाया कि कैसे वे और बीजाणु दोनों ने इसे पूरा किया।

वे जो करते हैं उसका मूल सारांश काफी सरल है:

  • अपने डेटा को बाइनरी में बदलें
  • अपनी लक्षित छवि को एक कच्चे बिटमैप में परिवर्तित करें
  • कुछ अनुमानित पैटर्न में छवि के पिक्सेल के साथ चलो (वे बस ऊपरी-बाएँ कोने से बाएं-से-दाएं करते हैं)।
  • प्रत्येक पिक्सेल के प्रत्येक रंगीन चैनल के निम्नतम क्रम बिट में एक बिट लिखें
  • फिर से png करने के लिए संशोधित बिटमैप निर्यात करें

अपना डेटा पुनः प्राप्त करने के लिए बस इसे उल्टा करें।

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

लेख से:

अंतिम छवि में ध्यान दें कि कैसे शोर में एक मुश्किल से क्षैतिज क्षैतिज रेखा है। यह स्तर डेटा का अंत है। इसका मतलब यह है कि मैं वास्तव में सभी स्तर के डेटा को 265x120 पिक्सेल छवि में फिट कर सकता हूं, केवल कम से कम महत्वपूर्ण बिट का उपयोग करके।

एक जटिल विज्ञापन:

कुछ मैं कर सकता था, और मुझे विश्वास है कि बीजाणु लोगों ने भी किया था, वास्तव में पिक्सेल में सभी रंग बिट्स का उपयोग करते हैं जो 100% पारदर्शी होते हैं। चूंकि वे पिक्सेल पारदर्शी होते हैं, इससे कोई फर्क नहीं पड़ता कि आप उन्हें किस रंग में सेट करते हैं।

हालांकि, मैं ऐसा नहीं कर सकता, क्योंकि मैं पूरी छवि का उपयोग कर रहा हूं, जिसका मतलब है कि मेरे पास काम करने के लिए कोई पारदर्शी पिक्सेल नहीं है।

इस तकनीक को सिर्फ मेटाडेटा में संग्रहीत करने के पक्ष में क्यों है?

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

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


6
मोनाको विधि की तुलना में छवि स्केलिंग / रंग समायोजन के खिलाफ स्टेग्नोग्राफ़िक एल्गोरिदम अधिक मजबूत हैं। : (हालांकि वे आम तौर पर एक काफी कम घनत्व पर डेटा स्टोर) एक उदाहरण Warcraft स्क्रीनशॉट की दुनिया में इस्तेमाल किया वॉटरमार्किंग है ownedcore.com/forums/world-of-warcraft/...
DMGregory

@DMGregory अच्छा लगा! निश्चित रूप से आपके द्वारा चुना गया सटीक एल्गोरिदम आपके विशिष्ट usecase (स्थान, स्थायित्व, गोपनीयता, आदि) द्वारा तय किया जाना चाहिए।
एलेक्सिस बीग्नेसर

1
जैसे ही यह शांत हो सकता है, यह एक बुरा विचार है। पीएनजी छवियां दोषरहित छवि संपीड़न का उपयोग करती हैं ; छवि के कम बिट के साथ चारों ओर fiddling संभवतः यह (थोड़ा) छवि गुणवत्ता को कम कर देता है के रूप में एक ही समय में फ़ाइल बड़ा कर देगा। बिल्कुल किसी भी जानकारी को "पाठ" के रूप में एन्कोड किया जा सकता है, इसलिए मेटाडेटा चंक का उपयोग करना स्पष्ट रूप से ऐसा करने का सही तरीका है; किसी को वास्तव में स्टेग्नोग्राफ़ी की आवश्यकता के बिना छवि बिट्स fiddling बस चबूतरे popping है।
dfeuer

1
@dfeuer - जाहिर तौर पर स्पोर और मोनाको दोनों गेम फ्रेमवर्क का उपयोग कर रहे थे, जिसमें एक एसेट लोडिंग पाइपलाइन है, जो .PNG को एक नंगे बिटमैप के नीचे लाती है, इसलिए मेटाडेटा चंक्स इसके माध्यम से नहीं बना रहे थे।
रसेल बोरोगोव

1
@ मेरे पास कुछ भोले-भाले परीक्षण हुए। मेटाडेटा दृष्टिकोण स्टेनोग्राफिक दृष्टिकोण द्वारा जोड़े गए आकार के लगभग 80% को 1920x1080px छवि के यादृच्छिक बिट्स के 100kB को जोड़ने पर प्रकट होता है। एक रिक्त छवि और डेस्कटॉप स्क्रीनशॉट पर परीक्षण किया गया। यदि आप वास्तव में 40kB से अधिक चिंतित हैं तो वास्तव में एक भयावह अंतर नहीं है, लेकिन मीटडाटा निश्चित रूप से बेहतर (और अधिक सुसंगत) है। ध्यान दें कि मेटाडेटा अभी भी बहुत अक्षम था। मैंने 100kB डेटा लिखने के लिए 181kB प्राप्त किया! यह पता लगाने के लिए कमरा हो सकता है कि स्ट्रिंग कैसे एन्कोडेड है या कुछ और है।
एलेक्सिस बेसेनर

7

मैंने डाउनलोड किया और Sporepedia के कुछ बीजाणु प्राणियों की जांच की। उन लोगों से मैंने सीखा है कि:

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

यह ध्यान देने योग्य है कि यह सिर्फ स्पोर करता है, यह एक ऐसी विधि है जो अधिकांश अन्य चिंताओं से पहले सरलता रखती है।

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

मुझे लगता है कि सबसे प्रमुख विकल्प वास्तव में केवल छवि में एक आईडी को एनकोड करना है, और वास्तविक डेटा को एक केंद्रीय सर्वर पर संग्रहीत किया जाना चाहिए जहां इस आईडी का सटीक प्राणी डेटा के लिए आदान-प्रदान किया जा सकता है। ऐसी आईडी काफी कम होगी कि इसे स्केलिंग- और कंप्रेशन-टॉलरेंट स्टेनोग्राफी फॉर्मेट में एनकोड किया जा सके।

बीजाणु प्रारूप में संभावित सरल सुधार शामिल हैं:

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