आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप ICO को TIFF में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
ICO से TIFF
ICO 139 KB → TIFF 601 KB 4.3× बड़ी
ICO 7 KB → TIFF 601 KB 86.0× बड़ी
ICO 3 KB → TIFF 601 KB 234.0× बड़ी
यही वह स्थिति है जिसके लिए यह पेज है, और पहली उपयोगी बात यह है कि दोनों माँगें तनाव में हैं। TIFF उन workflow से माँगी जाती है जो resolution की परवाह करते हैं — prepress, scanning, archives। आइकन इसके उलट सबसे छोटी जान-बूझकर बनाई image है।
रूपांतरण काम करता है और वैध फ़ाइल देता है। क्या वह फ़ाइल काम की है यह एक अलग सवाल है जिसका संख्यात्मक जवाब है, जो अगले सेक्शन में दिया गया है। यह पहले पूछ लीजिए, इससे पहले फ़ाइल आगे बढ़े।
ICO entry अपने आयाम एक बाइट में रखती है, शून्य 256 के लिए, इसलिए 256 पिक्सेल किसी भी आइकन फ़ाइल की absolute अधिकतम है। Print सामान्यतः 300 dots per inch पर specify होता है, और 256 को 300 से भाग दें तो 0.85 इंच — 21.7 मिलीमीटर मिलता है।
तो printed आइकन की ईमानदार अधिकतम सीमा एक postage stamp जितनी है, और कई आइकन फ़ाइलें 32 या 48 पिक्सेल से आगे कुछ नहीं रखतीं। अगर mark को cover पर 40 mm पर दिखना है, आइकन यह नहीं दे सकता।
TIFF फ़ॉर्मेट से ज़्यादा एक फ़ाइलिंग सिस्टम है, और इसके readers उम्मीद से कम एकमत हैं। LZW patent-free और universally supported है; Deflate universally supported नहीं है। Baseline असम्पीड़ित रूप वही है जिसे हर reader स्वीकारता है।
TIFF में बदलने वाला कोई लगभग हमेशा कुछ ख़ास feed कर रहा है — press, scanner का सॉफ़्टवेयर। जो link एक फ़ाइल ठुकराता है उसकी क़ीमत disk space से कहीं ज़्यादा है।
गणित यह बताता है फ़ाइल में क्या है। 256-पिक्सेल वर्ग चार samples प्रति पिक्सेल पर 262,144 बाइट्स है; मापा नतीजा 263,144 था। चार samples मतलब red, green, blue और alpha, इसलिए आइकन की transparency लिखी जाती है।
लिखा जाना उसे मानना नहीं है। TIFF readers चौथे sample को अलग-अलग तरह सँभालते हैं — कुछ इसे सफ़ेद पर composite करते हैं, कुछ नज़रअंदाज़ करते हैं। जिस application को यह फ़ाइल मिलेगी उसमें नतीजा खोलकर देख लीजिए।
सबसे बड़ी। ब्राउज़र container को डिकोड करता है और उसकी सबसे बड़ी तस्वीर लौटाता है, जो 16, 32, 48 और 256 पिक्सेल की चार अलग drawing वाली test icon पर जाँचा गया।
यह इस लक्ष्य के लिए सबसे अच्छा उपलब्ध नतीजा है, क्योंकि resolution ही वह है जो TIFF workflow चाहता है। यह भी मतलब है कि नतीजा उतना ही अच्छा है जितना आइकन खुद है — कोई setting बड़ा नहीं करती।
इस जोड़ी में एक विडंबना है। दोनों फ़ॉर्मेट कई तस्वीरें रखने के लिए बने हैं — ICO कई आकार पर एक mark रखता है, TIFF कई पेज रख सकता है।
ऐसा नहीं होता। Decoder एक तस्वीर लौटाता है और writer एक पेज लिखता है, इसलिए चार-entry वाला आइकन एक-पेज वाली TIFF बनता है और बाक़ी तीन drawing चले जाते हैं।
कोई TIFF दो अक्षरों से शुरू होती है जो बताते हैं उसके नंबर किस तरफ़ से स्टोर हैं — II little-endian के लिए, MM big-endian के लिए, फिर 42। यहाँ लिखी फ़ाइलें MM से शुरू होती हैं।
बाक़ी header एक pointer है image file directory की ओर, जहाँ width, height, samples per pixel और strip offsets रहते हैं। यही indirection TIFF को कई तस्वीरें रखने देता है।
अगर यह फ़ाइल किसी असली आकार में print होने वाली है, सही कदम है वापस जाकर वह आर्टवर्क माँगना जिससे आइकन बनी। Icon derived assets हैं; कहीं एक SVG, AI फ़ाइल या बड़ी PNG है जिससे 256-पिक्सेल entry render की गई।
जहाँ आइकन ही असल में बचा है — कोई पुराना product, defunct vendor — यहाँ का रूपांतरण वह सबसे अच्छा देता है जो मौजूद है, और सीमा layout तय करने वाले को proof stage पर नहीं, पहले ही बता देनी चाहिए।
पूरा सेट छोड़िए, हर फ़ाइल अलग decode और लिखी जाती है, सब कुछ ZIP के रूप में लौटता है। ZIP को स्रोत फ़ोल्डर से बड़ा होने की उम्मीद रखिए — आठ किलोबाइट की icon एक चौथाई-मेगाबाइट की TIFF बन जाती है।
Archival record के लिए यह अक्सर स्वीकार्य और कभी-कभी मक़सद है, क्योंकि असम्पीड़ित फ़ाइल का कोई decoder पुराना नहीं हो सकता। किसी working set के लिए पूछना सार्थक है कि क्या PNG वही काम सौवें हिस्से के आकार पर कर सकता।
| ICO | TIFF | |
|---|---|---|
| पूरा नाम | Windows आइकॉन | Tagged Image File Format |
| फ़ाइल एक्सटेंशन | .ico | .tif, .tiff |
| मीडिया टाइप | image/x-icon | image/tiff |
| कंप्रेशन | बिना नुक़सान — कुछ छोड़ा नहीं जाता | बिना नुक़सान — कुछ छोड़ा नहीं जाता |
| पहली बार प्रकाशित | 1985 | 1986 |
| प्रकाशक | Microsoft | Adobe |
| विनिर्देश | — | TIFF 6.0 |
| लाइसेंस | प्रकाशित, मानकीकृत नहीं | प्रकाशित, मानकीकृत नहीं |
| आज की स्थिति | सीमित उपयोग | मौजूदा |
| बिट डेप्थ | 8 | 32 |
| रंग जो यह दर्ज कर सकता है | RGB, इंडेक्स्ड पैलेट | RGB, CMYK, ग्रेस्केल, Lab |
| सबसे बड़ी इमेज | हर तरफ़ 256 px | — |
| ब्राउज़र में खुलता है | हर ब्राउज़र | कुछ ब्राउज़र |
| इसकी जगह विचारणीय | PNG, SVG | PNG, PDF, DNG |
TIFF में एक पन्ना होता है। कई पन्नों वाली ICO फ़ाइल पन्ना-दर-पन्ना बदली जाती है, एक ही फ़ाइल में नहीं।
कुछ नहीं खोता। ICO और TIFF — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।
पारदर्शिता बनी रहती है। ICO और TIFF — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
TIFF काम करने का फ़ॉर्मेट है और ICO बनकर तैयार फ़ॉर्मेट। जो लौटता है वह पन्ने की तस्वीर नहीं बल्कि बदली जा सकने वाली लिखावट है — आम तौर पर यही इस कन्वर्ज़न की वजह होती है, और यही इसकी सीमा भी।
TIFF को कुछ ही ब्राउज़र पढ़ पाते हैं। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
दोनों तरफ़ के प्रोग्राम अलग हैं: ICO फ़ाइल GIMP और IcoFX में खुलती है और TIFF फ़ाइल Adobe Photoshop, Affinity Photo और ImageMagick में — यानी नतीजा जिसके पास जाएगा, उसे दूसरी सूची में से कोई प्रोग्राम चाहिए होगा।
दोनों का निशाना अलग काम है: ICO का वेब पर, TIFF का छपाई, स्कैनिंग और सहेजना पर। इस पर सोचना बनता है, क्योंकि जिस वजह से एक मौजूद है, आम तौर पर उसी वजह से दूसरा असुविधाजनक होता है।
ICO Microsoft का फ़ॉर्मेट है, जो 1985 में आया। यह हर चैनल पर 8 बिट में दर्ज करता है।
TIFF Adobe का है और 1986 से चला आ रहा है, और TIFF 6.0 में तय किया गया है। Adobe Photoshop, Affinity Photo और ImageMagick इस फ़ॉर्मेट को पढ़ लेते है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे jSquash है, तस्वीरों के संदर्भ कोडेक के WebAssembly संस्करण; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100। jSquash आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।
नहीं। TIFF वही सामग्री बिना कुछ फेंके सँभालता है: नतीजा गुणवत्ता में असली फ़ाइल जैसा ही होता है।
TIFF में एक पन्ना होता है। कई पन्नों वाली ICO फ़ाइल पन्ना-दर-पन्ना बदली जाती है, एक ही फ़ाइल में नहीं।
TIFF को कुछ ही ब्राउज़र पढ़ पाते हैं। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
कुछ नहीं खोता। ICO और TIFF — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।
इस पेज पर ICO और TIFF के बारे में जो कहा गया है, वह जाँचा जा सकता है, और ये रहे वे दस्तावेज़ जो उसे तय करते हैं।