AVIF, PNG को file size पर इतनी निर्णायक रूप से क्यों हराता है
AVIF आधुनिक छवि प्रारूप पर बना है, जो lossless निष्ठा के बजाय perceptual दक्षता के लिए बनाया गया है. PNG raw विवरण data पर DEFLATE का उपयोग करता है, जो lossless है पर photographic content में भारी redundancy छोड़ देता है. AVIF उस redundancy को video से ली block prediction से बदल देता है, वह जानकारी हटाते हुए जिसे मानव दृष्टि तंत्र नहीं भाँपता. नतीजा नाटकीय है. quality 85 पर एक 116 किलोबाइट photo घटकर करीब 16 किलोबाइट AVIF होती है, और एक transparent PNG आमतौर पर समान WebP के मुकाबले 30 से 50 percent सिकुड़ती है. यह अंतर high-resolution photos के साथ बढ़ता है और सरल graphics पर घटता है. modern audience को transparent images परोसने वाली किसी भी site के लिए, यह bandwidth बचत सीधे तेज loads और कम egress cost में बदलती है.
alpha channel की पूरी कहानी
PNG और AVIF दोनों transparency को color data के साथ एक अलग alpha plane में रखते हैं. जब यह pair आपकी PNG process करता है, decoder color pixels और alpha mask को अलग-अलग निकालता है. फिर AVIF का साधन अपने alpha track के साथ नई file लिखता है, दोनों planes को quality 85 पर compress करने के लिए आधुनिक प्रारूप intra-frame coding का उपयोग करते हुए. alpha न color में मिलाई जाती है और न किसी background fill से बदली जाती है. soft shadows, feathered edges, और आंशिक रूप से transparent gradients सब निष्ठा से encode होते हैं. AVIF जो एक degradation जोड़ता है वह alpha plane पर ही lossy compression है, जो बहुत कठोर किनारों के आसपास अत्यधिक zoom पर मुश्किल से दिखने वाली fringing बना सकता है. सामान्य display sizes और quality 85 पर अंतर दिखता नहीं. छोटे आकार के विवरण-perfect icon काम के लिए, PNG रखें.
व्यवहार में बदलाव की गति, browser दर browser
AVIF का साधन प्रति browser session एक बार load होता है, fetch के लिए करीब 800 millisecond और initialize के लिए 300, इसलिए पहला बदलाव करीब एक second का warm-up उठाता है. warm बदलाव उसे पूरी तरह छोड़ देते हैं. Chrome desktop पर, 0.12 megapixel करीब 40 millisecond, 1 megapixel करीब 250 millisecond, और 8 megapixel करीब 2.8 second लेता है. Firefox अपवाद है, वही काम करीब चार गुना धीमे चलाता है, इसलिए एक 4K photo वहाँ 30 second या अधिक ले सकती है. Safari पर WebKit दोनों के बीच, Chrome के करीब बैठता है. mid-range mobile hardware पर ये आँकड़े desktop Chrome से तीन से पाँच गुना खराब चलते हैं. अगर आप बड़ी files अक्सर बदलते हैं, desktop या laptop पर Chrome सबसे अच्छी throughput देता है.
बदलने के बजाय PNG कब रखें
file size मायने रखने पर भी कई मामलों में PNG सही चुनाव रहता है. पहला, छोटे आकार पर तीखे text वाले graphics, जैसे labels, badges, या favicon-scale icons, AVIF में ऐसे artifacts दिखा सकते हैं जो सामान्य देखने की दूरी पर अस्वीकार्य हैं. दूसरा, आगे editing के लिए उपयोग होने वाली source-of-truth files PNG रहनी चाहिए, क्योंकि lossy format से हर बार गुजरने पर quality loss जुड़ता जाता है. तीसरा, AVIF अस्वीकार करने वाले environments, जिनमें कुछ document editors, पुराने design tools, और email clients शामिल हैं, interoperability के लिए PNG चाहते हैं. आखिर में, पहले frame से आगे की animation नहीं रखी जाती, क्योंकि यह pair एक frame संभालता है. बाकी सब के लिए, modern web delivery को जा रही transparent photos और graphic assets के लिए, PNG to AVIF सही सौदा है.
Core Web Vitals और bandwidth का तर्क
Largest Contentful Paint, मुख्य loading metric, page की सबसे बड़ी image के size से सीधे प्रभावित होता है. उस image को 116 किलोबाइट से 16 किलोबाइट तक घटाना, जैसा development में एक 4K photo पर नापा गया, उसी element के लिए 10 Mbps connection पर transfer time करीब 93 millisecond से करीब 13 तक काटता है. इसे एक product grid, एक hero carousel, या transparent icons से भरे UI पर गुणा करें और संचयी बचत LCP को Google द्वारा अच्छा माने जाने वाले 2.5 second की सीमा से अच्छी तरह नीचे धकेलती है. AVIF अपनाना ठीक इसलिए तेज हुआ क्योंकि यह तर्क ठोस आँकड़ों में रखा जा सकता है. करीब 94.3 percent browser coverage पर, fallback मामला इतना छोटा है कि bandwidth जीत अतिरिक्त picture element markup से भारी पड़ती है.
यह आम online converter से कैसे अलग है
ज्यादातर online AVIF converter आपका PNG उन machines पर upload करते हैं जिन पर आपका नियंत्रण नहीं, वहीं उसे process करते हैं और उस provider की तय retention policy के तहत रखते हैं, जो अक्सर अस्पष्ट होती है। RoundCut अपने flow के बारे में सीधा है। चूंकि AVIF भारी है, बेहतरीन नतीजे के लिए conversion हमारे server पर चलता है, और server उपलब्ध न होने पर browser का encoder अपने आप backup के रूप में काम करता है। जब आपकी फाइल हमें भेजी जाती है, वह convert होती है और फिर करीब 2 घंटे में हटा दी जाती है, बिना account और मांगे गए conversion से आगे किसी उपयोग के बिना। न स्थायी भंडारण है, न आपकी image का साझा किया जाना। client documents, अपनी product photography या user content के साथ काम करने वालों के लिए इस सौदे का ईमानदार रूप यही है: फाइल हमारे server से गुजर सकती है, उसे सिर्फ आपका AVIF बनाने के लिए संभाला जाता है, और वह वहां नहीं ठहरती।
