कुछ मुझे परेशान कर रहा है - this image क्यों हर ब्राउज़र में अलग दिखाई देता है? IE9 (और Windows फ़ोटो दर्शक) मेंजेपीईजी फ़ाइलों को डीकोड करने में क्रॉस-ब्राउज़र असंगतताएं?
छवि: फ़ायरफ़ॉक्स (और फ़ोटोशॉप) में
छवि: क्रोम (और Irfanview) में
छवि:
अंतिम आउटपुट को इतना अलग करने के लिए जेपीईजी की अपनी डीकोडिंग प्रक्रियाओं में क्या चल रहा है?
(देखने के लिए मैं क्या मतलब है आईई, फ़ायरफ़ॉक्स, क्रोम, आदि में यह देखें।)
जेपीईजी आरजीबी या CMYK में इनकोडिंग जा सकता है। ये नैतिकता आमतौर पर तब होती है जब यह सीएमवाईके है। फ़ाइल को एक संपादन संपादन प्रोग्राम में खोलें और इसे आरजीबी जेपीईजी के रूप में सहेजें, और सीएमवाईके प्रिंटर को सलाम करें, जो आपके पास पहले ब्राउज़र में अलग-अलग परिणाम होंगे।
यह एक प्रकट होता है कम से कम फ़ोटोशॉप के अनुसार, आरजीबी के रूप में एन्कोड किया जाना है। –
वैसे भी, इसे एक नई छवि में कॉपी-पेस्ट करें और उसे सहेजें। यह शायद आपकी समस्या हल करता है। यदि नहीं, तो एक और ग्राफिक्स प्रोग्राम आज़माएं। –
यह ठीक है कि यह कोई समस्या नहीं है, बस एक जिज्ञासा :) हालांकि आपके उत्तर के लिए धन्यवाद! –
मैं केवल अनुमान लगा रहा हूं।
यदि छवि इन मतभेदों को दिखाने के लिए बनाई गई थी, तो शायद यह एक सामान्य छवि नहीं है जो एन्कोड किया गया था, लेकिन एक अमान्य एक जहां गणना किए गए रंग 0 से 255 रेंज के बाहर हैं और अलग-अलग डिकोडर्स इन्हें अलग-अलग संभालते हैं।
यह समझ में आता है, यह देखते हुए कि यह रंगों की एक सीमित सीमा प्रदर्शित करता है, और 8x8 ब्लॉक में व्यक्तिगत पिक्सल को अलग करता है। –
यदि आप उस विशेष छवि का रंग प्रोफ़ाइल फ़ोटोशॉप में सीएमवायके से एसआरबीबी में बदलते हैं, उदाहरण के लिए, यह सभी ब्राउज़रों में समान रूप से समान रूप से दिखाई देगा।
दिलचस्प, मुझे नहीं पता था कि इससे कोई फर्क पड़ता है। हालांकि, फ़ोटोशॉप रिपोर्ट करता है कि यह छवि आरजीबी रंग की जगह है जो सीएमवाईके नहीं है। –
जब मैंने पहली बार अपनी छवि (http://imgur.com/UNZTe.jpg) डाउनलोड की, तो मैंने कसम खाता हूं कि यह मेरे फ़ोटोशॉप में सीएमवाईके था :-)। यदि आप इसे सहेजते हैं और फिर ब्राउज़र के साथ परीक्षण करते हैं, तो यह फिर से सामान्य दिखाई देगा। पीएस: मेरा जवाब क्वांडरीज़ के समान प्रतीत होता है, जो मेरे पहले 5 मिनट था। – bogatyrjov
JPEGSnoop (स्रोत अब उपलब्ध @ स्रोतफोर्ज) बड़ी लुमा ओवरफ्लो की रिपोर्ट करता है इससे पहले कि हम वाईबीसीआरआर से आरजीबी रूपांतरण तक पहुंच जाएं। मुझे कुछ अन्य फाइलों पर ये त्रुटियां मिलती हैं, लेकिन अतिप्रवाह आमतौर पर 256 या 257 बनाम अधिकतम 255 है। यहां दी गई लूमा 729 है!
YCC अतिप्रवाह पर JPEGSnoop के लेखक की टिप्पणी: डीसी में
YCC कतरन - हर एमसीयू कहते हैं या पिछले एमसीयू में डीसी (औसत) मूल्य से घटा देती है। इन सभी 8-बिट रेंज के भीतर रहना चाहिए, लेकिन डीसी गुणांक में भ्रष्टाचार हो सकता है क्योंकि यह मान सीमा से बाहर निकलने का कारण बनता है। इस प्रकार की त्रुटि रंग में अचानक बड़े पैमाने पर परिवर्तन या आपकी छवि में चमक का कारण बन जाएगी। चूंकि त्रुटि का सामान्य रूप से पुनर्प्राप्त नहीं होगा, JPEGsnoop केवल लॉग फ़ाइल में इनमें से पहले 10 की रिपोर्ट करेगा।
मैं अंतर-एमसीयू डीसी से परिचित नहीं था, लेकिन Pennebaker & मिशेल concur।
*** Decoding SCAN Data ***
OFFSET: 0x00000160
Scan Decode Mode: Full IDCT (AC + DC)
Scan Data encountered marker 0xFFD9 @ 0x00027CA9.0
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 729, 109, 171) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 682, 109, 172) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 741, 109, 173) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 629, 109, 174) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 841, 109, 175) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 319, 109, 176) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 928, 109, 177) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 0, 0) YCC=( 624, 109, 177) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 1, 0) YCC=( 785, 107, 171) Y Overflow @ Offset 0x00027CA8.2
*** NOTE: YCC Clipped. MCU=( 1, 0) YCC=( 559, 107, 171) Y Overflow @ Offset 0x00027CA8.2
Only reported first 10 instances of this message...
अब यह क्रोम में अलग दिखता है;) – Joey