आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप ICO को AVIF में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
ICO से AVIF



AVIF महज़ अच्छे संपीड़न वाला इमेज फ़ॉर्मेट नहीं — यह AV1 वीडियो कोडेक के भीतरी-फ़्रेम रास्ते का एक डिब्बे में बंद रूप है। AV1 को किसी ब्लॉक की सामग्री उसके पड़ोसियों से अनुमानित करने और वह बारीक ब्योरा फेंकने के लिए बनाया गया जो चलती नज़र नहीं पकड़ती — फ़ोटो और फ़िल्म ग्रेन पर यह हैरान करने वाला कारगर तरीक़ा है।
किसी आइकन में इनमें से कुछ नहीं। यह कड़ी सीमाओं वाले चंद सपाट क्षेत्र और किनारों पर मुट्ठी भर धुँधले पिक्सेल भर है। न कोई बनावट अनुमानित करने को, न ढाल, न फेंकने लायक़ बचा हुआ ब्योरा — तो जो मशीनरी AVIF को फ़ोटो पर जिताती है, उसके पास आइकन पर करने को लगभग कुछ नहीं, जबकि उसका तयशुदा ख़र्च वहीं का वहीं रहता है।
चार प्रविष्टियों वाली 8,471 बाइट की टेस्ट आइकन पर, तयशुदा गुणवत्ता 82 पर बदलने के बाद: PNG 1,737 बाइट, GIF 1,894, WebP 3,054, AVIF 3,624 और JPEG 4,005। यह क्रम लगभग वही है जो किसी फ़ोटो पर उल्टा होगा।
यह मामूली फ़र्क़ नहीं। AVIF, PNG से दोगुने से भी ज़्यादा है, और वह भी वह जो नुक़सान वाला है। दो सौ आइकन वाली किसी निर्देशिका को AVIF में बदलने से साइट के भेजे जाने वाले आँकड़ों में लगभग 380 किलोबाइट जुड़ता है, घटता नहीं। आइकन को माइग्रेशन से अलग रखिए और PNG में रहने दीजिए।
पारदर्शिता बची रहती है: टेस्ट आइकन पर नतीजे के कोने का पिक्सेल 0,0,0,0 पढ़ता है। हर कुशल फ़ॉर्मेट में यह तयशुदा नहीं — इसी साइट पर GIF रास्ता उसी कोने को ठोस काले में बदल देता है — तो अगर निशान कोई कटआउट है और फ़ॉर्मेट AVIF ही होना है, कम से कम यह हिस्सा काम करता है।
यह अल्फ़ा को रंग के साथ दूसरे तल के रूप में एनकोड करके होता है — भीतर एक और छोटी तस्वीर जैसा। फ़ोटो पर यह ख़र्च शोर में खो जाता है। 256-पिक्सेल आइकन पर, जहाँ पूरी फ़ाइल कुछ किलोबाइट की है, यह कुल का दिखने लायक़ हिस्सा है।
AVIF एनकोडर इस साइट का सबसे बड़ा WebAssembly मॉड्यूल है और चलने में सबसे धीमा, क्योंकि स्थिर AVIF एनकोड करना AV1 की भीतरी-फ़्रेम खोज चलाने जैसा है। एक फ़ाइल के लिए यह एक ठहराव है। दो सौ आइकन वाले फ़ोल्डर के लिए यह असली इंतज़ार है, और यह आपके अपने प्रोसेसर पर हो रहा है, किसी सर्वर पर नहीं।
इसे बाइट नतीजे के साथ मिलाकर तौलना ज़रूरी है, अलग से नहीं। हर बिल्ड पर असली एनकोड समय ख़र्च करके हर आइकन को दोगुना बड़ा बनाना, दोनों दिशाओं में ख़राब सौदा है।
ICO एक ही निशान को कई आकारों में रखता है और AVIF एक ही तस्वीर रखता है, तो कुछ न कुछ चुनना पड़ता है। आपके ब्राउज़र का आइकन डिकोडर यह चुनाव करता है और सबसे बड़ी प्रविष्टि लौटाता है — यह चार अलग रंगों में 16, 32, 48 और 256 पिक्सेल की ड्रॉइंग वाली फ़ाइल बनाकर और डायरेक्टरी को तीन अलग क्रमों में लिखकर परखा गया है।
ऊँची सीमा 256 पिक्सेल है, जो AVIF की नहीं बल्कि ICO फ़ॉर्मेट की तय की हुई है — AVIF 65,536 तक जा सकता है। तो एनकोडर को हमेशा एक छोटी तस्वीर मिलती है, ठीक वही हालत जिसमें हर कुशल फ़ॉर्मेट PNG के मुक़ाबले सबसे बुरा प्रदर्शन करता है।
AVIF हर चैनल में बारह बिट और चौड़ा रंग-दायरा रख सकता है, जो फ़ोटोग्राफ़ी और उच्च-गतिकीय-सीमा सामग्री के लिए WebP और JPEG पर इसकी असली बढ़त है। कोई आइकन फ़ाइल हमेशा हर चैनल में आठ बिट और मानक रंग-दायरे में रहती है।
तो यह क्षमता मौजूद है और बेकार पड़ी है। सीधे कुछ ख़र्च नहीं करती, पर यह पूरे मामले का सही सार है: लगभग हर वह चीज़ जिसमें AVIF बेहतर है, वह किसी आइकन के पास होती ही नहीं। जो एक गुण यहाँ मायने रखता है — अल्फ़ा — वह PNG के पास पहले से ही था।
हर आधुनिक बड़ा ब्राउज़र AVIF डिकोड करता है, और कई सालों से करता आ रहा है। ज़्यादातर साइटों के लिए यह इसे सीधे परोसने के लिए काफ़ी है। यह WebP से नई है, तो जो ब्राउज़र इसे नहीं पढ़ सकते उनकी पूँछ लंबी है, और आम जवाब picture तत्व में एक फ़ॉलबैक स्रोत रखना है, सीधे बदल देना नहीं।
आइकन के लिए इसका मतलब देख लीजिए: अब आप एक की जगह दो फ़ाइलें भेज रहे हैं, और फ़ॉलबैक वही PNG है जो पहले से छोटी थी। जटिलता असली है और बचत नकारात्मक।
एक ही नियम हर जगह लगाना आकर्षक है क्योंकि यह हर भविष्य के बिल्ड से एक फ़ैसला हटा देता है, और इमेज फ़ॉर्मेट पर आमतौर पर ऐसे नियम सही ठहरते हैं। यह वह मामला है जहाँ नहीं ठहरता। नियम को फ़ोल्डर के बजाय सामग्री के हिसाब से बाँटिए — फ़ोटो और स्क्रीनशॉट AVIF में, सपाट कला और आइकन PNG में।
अगर पाइपलाइन वाक़ई दो नियम नहीं संभाल सकती — कुछ CDN ट्रांसफ़ॉर्म नहीं कर पाते — तो आइकन को भी बदलना एकरूपता की एक जायज़ क़ीमत है। बस इतना जान लीजिए कि यह क़ीमत है, और मोटे तौर पर कितनी बड़ी: प्रति आइकन कुछ किलोबाइट, ग़लत दिशा में।
फ़ोल्डर छोड़ दीजिए। हर फ़ाइल अपने-आप डिकोड और एनकोड होती है और नतीजे एक ZIP बनकर लौटते हैं, पूरे बैच पर एक ही गुणवत्ता सेटिंग के साथ। PNG या WebP के मुक़ाबले इसमें काफ़ी ज़्यादा समय लगने की उम्मीद रखिए।
आयाम एक-जैसे नहीं होंगे जब तक स्रोत का सेट भी वैसा न हो। आइकन संग्रह अक्सर 256-पिक्सेल प्रविष्टि वाली फ़ाइलों और सिर्फ़ 32 पर रुकने वाली फ़ाइलों का मिश्रण होते हैं, और चूँकि एनकोडर का तयशुदा ख़र्च जितनी छोटी तस्वीर उतना ज़्यादा असर डालता है, सेट के 32-पिक्सेल सदस्य ही सबसे बुरा नतीजा देंगे।
दो चीज़ें देखने लायक़ हैं और दोनों में ज़्यादा समय नहीं लगता। पहली, दोनों फ़ाइलों की बाइट-गिनती साथ रखकर, क्योंकि यही वह संख्या है जिसके लिए माइग्रेशन शुरू हुआ था। दूसरी, निशान को उतने ही आकार में देखिए जितने में वह असल में दिखेगा — बहुत ज़ूम करके नहीं, जहाँ नुक़सान वाले धब्बे डरावने लगते हैं पर कोई उन्हें कभी उतना नहीं देखेगा।
मूल आइकन फ़ाइल हर हाल में रखिए। यही वह इकलौती चीज़ है जिसमें छोटी हाथ से बनी प्रविष्टियाँ अब भी हैं, यह कुछ किलोबाइट की है, और यही वह फ़ाइल है जिसे ब्राउज़र साइट की जड़ से माँगता रहेगा।
| ICO | AVIF | |
|---|---|---|
| पूरा नाम | Windows आइकॉन | AV1 Image File Format |
| फ़ाइल एक्सटेंशन | .ico | .avif |
| मीडिया टाइप | image/x-icon | image/avif |
| कंप्रेशन | बिना नुक़सान — कुछ छोड़ा नहीं जाता | सेटिंग के हिसाब से दोनों में से कोई भी |
| पहली बार प्रकाशित | 1985 | 2019 |
| प्रकाशक | Microsoft | Alliance for Open Media |
| विनिर्देश | — | AV1 Image File Format |
| लाइसेंस | प्रकाशित, मानकीकृत नहीं | खुला मानक |
| आज की स्थिति | सीमित उपयोग | मौजूदा |
| बिट डेप्थ | 8 | 12 |
| रंग जो यह दर्ज कर सकता है | RGB, इंडेक्स्ड पैलेट | RGB, YCbCr, वाइड गैमट |
| सबसे बड़ी इमेज | हर तरफ़ 256 px | हर तरफ़ 65,536 px |
| ब्राउज़र में खुलता है | हर ब्राउज़र | मौजूदा ब्राउज़र |
| इसकी जगह विचारणीय | PNG, SVG | WebP, JXL, JPG |
पारदर्शिता बनी रहती है। ICO और AVIF — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
AVIF को मौजूदा ब्राउज़र पढ़ लेते हैं, पुराने नहीं। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
AVIF एक कंटेनर है, कोई इकहरा फ़ॉर्मेट नहीं। जो चलता है वह उसके भीतर बैठा कोडेक है — आम तौर पर AV1 — और इसीलिए एक ही एक्सटेंशन वाली दो फ़ाइलें एक ही उपकरण पर अलग-अलग बर्ताव कर सकती हैं।
GIMP ICO और AVIF — दोनों पढ़ लेता है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।
ICO Microsoft का फ़ॉर्मेट है, जो 1985 में आया। यह हर चैनल पर 8 बिट में दर्ज करता है।
AVIF Alliance for Open Media का है और 2019 से चला आ रहा है, और AV1 Image File Format में तय किया गया है। GIMP, Squoosh और ImageMagick इस फ़ॉर्मेट को पढ़ लेते है।
ICO 1985 में आया और AVIF 2019 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे jSquash है, तस्वीरों के संदर्भ कोडेक के WebAssembly संस्करण; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100। jSquash आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।
AVIF कंप्रेस करता है, इसलिए कुछ डेटा जाता है। तयशुदा सेटिंग पर यह पकड़ में नहीं आता; पक्का करना हो तो गुणवत्ता बढ़ा दीजिए।
AVIF को मौजूदा ब्राउज़र पढ़ लेते हैं, पुराने नहीं। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
AVIF एक कंटेनर है, कोई इकहरा फ़ॉर्मेट नहीं। जो चलता है वह उसके भीतर बैठा कोडेक है — आम तौर पर AV1 — और इसीलिए एक ही एक्सटेंशन वाली दो फ़ाइलें एक ही उपकरण पर अलग-अलग बर्ताव कर सकती हैं।
पारदर्शिता बनी रहती है। ICO और AVIF — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
इस पेज पर ICO और AVIF के बारे में जो कहा गया है, वह जाँचा जा सकता है, और ये रहे वे दस्तावेज़ जो उसे तय करते हैं।