नया PNG स्पेक जारी

(programmax.net)

9 पॉइंट द्वारा GN⁺ 2025-06-26 | 2 टिप्पणियां | WhatsApp पर शेयर करें

PNG फ़ाइल फ़ॉर्मैट को 20 साल बाद नए रूप में संशोधित किया गया है और इसने अपनी पुरानी अहमियत फिर हासिल की है
इस स्पेक में HDR सपोर्ट, APNG (एनीमेशन), Exif डेटा के आधिकारिक सपोर्ट सहित कई आधुनिक तकनीकों को शामिल किया गया है
Adobe, Apple, Google जैसी प्रमुख IT कंपनियों और ब्रॉडकास्ट कंपनियों ने मिलकर इसके विकास में भाग लिया
नवीनतम स्पेक को Chrome, Safari, Photoshop जैसे कई प्रोग्राम पहले से ही सपोर्ट कर रहे हैं
आगे बेहतर कंप्रेशन तकनीक और parallel encoding/decoding जैसी अतिरिक्त अपडेट की योजना है

परिचय: PNG की वापसी और महत्व

हाल ही में PNG फ़ाइल फ़ॉर्मैट को लगभग 20 साल की ठहराव अवधि के बाद नए स्पेक के साथ अपडेट किया गया है
Library of Congress, Library and Archives Canada, National Archives of Australia जैसी प्रमुख संस्थाओं ने PNG को आधिकारिक रूप से अनुशंसित फ़ॉर्मैट के रूप में अपनाया है
नए स्पेक के जरिए PNG ने बाज़ार में अपनी प्रतिस्पर्धात्मकता फिर हासिल की है और अपनी नवाचार क्षमता दिखाई है

नई सुविधाएँ और विशेषताएँ

उचित HDR सपोर्ट और भविष्य की संगतता

नया PNG HDR (High Dynamic Range) सपोर्ट प्रदान करता है
Rec. 2020 और Rec. 709 color gamut की तुलना वाली इमेज में बड़ा क्षेत्रफल वाला बाहरी त्रिकोण उन रंगों को दिखाता है जिन्हें HDR इमेज व्यक्त कर सकती है
इस HDR जानकारी के लिए केवल 4 bytes (और मौजूदा PNG chunk overhead) अतिरिक्त चाहिए
Chris Lilley जैसे शुरुआती लेखक और प्रमुख तकनीकी विशेषज्ञों ने भाग लेकर नई तकनीकों को स्पष्ट रूप से समझाया है

APNG (Animated PNG) की आधिकारिक मान्यता

Mozilla द्वारा पहली बार प्रस्तावित और Firefox द्वारा सपोर्ट की गई Animated PNG (APNG) को भी आधिकारिक स्पेक में शामिल किया गया है
पहले इसे केवल कुछ सॉफ़्टवेयर ही सपोर्ट करते थे, लेकिन अब इसे कई प्रोग्राम व्यापक रूप से अपना रहे हैं

Exif डेटा का आधिकारिक सपोर्ट

Exif के जरिए कॉपीराइट, कैमरा जानकारी, GPS जानकारी जैसे metadata को स्टोर किया जा सकता है
इमेज निर्माण, संग्रहण और कॉपीराइट प्रबंधन जैसे कार्यों में इसकी उपयोगिता बहुत अधिक है

समग्र सुधार और त्रुटि सुधार

मौजूदा स्पेक की त्रुटियों (Errata) के सुधार और स्पष्टीकरण भी साथ में किए गए हैं

पृष्ठभूमि और विकास प्रक्रिया

पिछला PNG स्पेक लगभग 20 साल पहले जारी हुआ था (iPhone के लॉन्च से साढ़े 3 साल पहले)
W3C Timed Text Working Group (subtitle technology standardization) ने PNG में HDR सपोर्ट की ज़रूरत उठाई, जिसके बाद विकास फिर शुरू हुआ
प्रस्ताव आते ही Adobe, Apple, BBC, Google, MovieLabs, W3C जैसी प्रमुख तकनीकी संस्थाएँ संयुक्त रूप से इसमें शामिल हुईं
एक मज़बूत consortium बना और PNG अगली पीढ़ी के इमेज फ़ॉर्मैट के रूप में फिर उभरा
फिलहाल दो अनुवर्ती अपडेट भी पहले से तैयार किए जा रहे हैं

पहले से व्यापक रूप से लागू स्थिति

Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer सहित कई प्रोग्राम नवीनतम PNG स्पेक को सपोर्ट करते हैं
ब्रॉडकास्ट कंपनियों तथा संबंधित हार्डवेयर और tooling में भी इसका सपोर्ट बढ़ रहा है
न्यूज़ स्क्रॉल, स्पोर्ट्स स्कोर बैनर जैसी प्रसारण इमेजें नए HDR PNG के उपयोग के उदाहरण हैं

आगे की योजना

अगले संस्करण में HDR & SDR compatibility को और बेहतर बनाने की योजना है
इसके अलावा और उन्नत कंप्रेशन तरीके, parallel encoding/decoding पर भी काम चल रहा है
चौथा edition अपेक्षाकृत छोटा अपडेट होगा, और उसके बाद कंप्रेशन तकनीक के शोध के आधार पर पाँचवें edition का विकास किया जाएगा

2 टिप्पणियां

carnoxen 2025-06-26

शुरुआत में APNG को संगठन ने इमेज के लिए standard नहीं मानकर ठुकरा दिया था, और अब जाकर उसे मान्यता दी है।

GN⁺ 2025-06-26

Hacker News टिप्पणियाँ

लेखक होने की बात बताते हुए कहा कि सवाल हों तो कभी भी स्वागत है
- यह ज़ोर दिया कि यह PNG पूरी तरह नया फ़ॉर्मैट नहीं, बल्कि मौजूदा फ़ॉर्मैट का अपडेटेड संस्करण है
- बताया कि यह बहुत उच्च स्तर की backward compatibility देता है
- समझाया कि पुराने प्रोग्राम भी नई PNG फ़ाइलों को जहाँ तक संभव हो, अच्छी तरह पढ़ सकते हैं, और उदाहरण के लिए यह पहचान सकते हैं कि यह लाल सेब की तस्वीर है
- PNG के अंदरूनी काम करने के तरीके को लेकर भ्रम हो सकता है, इसलिए मुख्य बातें संक्षेप में रखीं
  - PNG फ़ाइल कई डेटा chunks से बनी होती है
  - हर chunk का एक नाम होता है, इसलिए प्रोग्राम जिन chunks को नहीं जानते या जिनकी ज़रूरत नहीं होती, उन्हें बस skip कर सकते हैं
  - image stream केवल एक ही होता है
- इच्छा जताई कि नए PNG spec की क्षमताओं का उपयोग करने वाली example files हों, खासकर ऐसी demo page जहाँ animation या HDR images सीधे डाउनलोड करके program compatibility टेस्ट की जा सके
- कहा कि मैं meta-format और general-purpose tooling का समर्थक हूँ
  - Office Open XML या ePub की तरह, जहाँ सिर्फ zip और XML libraries हों तो parsing हो जाती है, ऐसे ढाँचे का उदाहरण दिया
  - बताया कि PNG की संरचना भी लगभग Interchange File Format(आगे IFF) जैसी है, लेकिन पहले spec में हल्के फर्क होने के कारण पूरी तरह generic IFF parser से PNG और IFF परिवार की फ़ाइलें एक साथ parse करना संभव नहीं था
  - IFF को implement करना आसान है और data compression में इसकी ताकत है, लेकिन अब तक यह पुराना game data, AIFF·RIFF audio जैसे सीमित उपयोगों तक ही रहा, और generic tooling न बन पाने के कारणों में PNG और IFF की अधूरी compatibility का भी ज़िक्र किया
  - आशा जताई कि अगर PNGv3 से PNG files आधिकारिक रूप से IFF files बन जाएँ, तो PNG की लोकप्रियता के आधार पर generic IFF ecosystem, जैसे libiff, बढ़ सकेगा और नए formats define करने में भी काम आएगा
  - यह भी कहा कि खुद PNG/IFF parser बनाया है, और सिर्फ PNG में थोड़ा बदलाव करके IFF compatibility लाना आसान नहीं है, साथ ही backward compatibility, खासकर hardware parsers के लिए, बनाए रखना भी ज़रूरी है
  - प्रस्ताव रखा कि PNG में इस्तेमाल हो रही modified IFF structure को एक नए meta-format, यानी IFF 2.0 standard, के रूप में अलग से document किया जाए
  - चाहा कि IFF 2.0 में PNGv2-compatible profile और AIFF/RIFF जैसे IFFv1 को cover करने वाले profiles आधिकारिक किए जाएँ ताकि generic IFF tooling को बढ़ावा मिले
  - आगे कहा कि नए greenfield profile, यानी आधुनिक माहौल के लिए बने नए format में, उदाहरण के लिए CRC की जगह modern hash से integrity check, chunk name character set का विस्तार, और हर chunk की property information को कुशलता से रखने वाली संरचना लाई जा सकती है
  - माना कि ऐसी संरचनाएँ IFFv1 और PNGv2 दोनों के लिए transcodeable होनी चाहिएँ, और HTML5 में HTML4 तथा XHTML को मिलाकर compatibility रखने जैसी रणनीतिक profile declaration उपयोगी होगी
  - निष्कर्ष में ज़ोर दिया कि बारीकियों से ज़्यादा design goals पर ध्यान है, यानी पुराने और नए formats के बीच विषमता कम करना और tooling ecosystem बढ़ाना
मेरे web-based drawing tool में मैं document की JSON representation को PNG के comment field में store करने वाली तरकीब इस्तेमाल करता हूँ
- इससे saved file सीधे image की तरह भी काम करती है और उसे editor में फिर से खोला भी जा सकता है
- इसका फायदा यह है कि download folder में पहचान में न आने वाली JSON files इकट्ठी नहीं होतीं
- यह दिलचस्प तो है, लेकिन users को समझाना मुश्किल होता है कि file .png के रूप में क्यों save हो रही है, या Paint जैसे tool में खोलकर save करने पर data क्यों गायब हो जाता है
- Krita भी brush settings को ऐसे ही save करता है, लेकिन data बहुत ज़्यादा हो तो अनपेक्षित समस्याएँ आ सकती हैं
  - संबंधित issues: Krita-Brushes issue #4, Memileo Impasto Brushes discussion
- Macromedia Fireworks 20 साल पहले से PNG को default save format की तरह इस्तेमाल करता था
  - बेशक उस समय उसमें JSON नहीं डाला जाता था
- कई AI image generation frontends भी इसी तरह इस्तेमाल करते हैं
  - image comment में prompt या settings store करके, सिर्फ image खोलने पर configuration वापस लाना या ComfyUI की तरह पूरा workflow load करना संभव होता है
  - सच कहूँ तो image handling tools में इस तरह का उपयोग काफी आम है
- Macromedia Fireworks PNG में Fireworks file save करता था,
  - Adobe Illustrator(AI) files असल में PDF होती हैं,
  - Photoshop की PSD files TIFF के अंदर भी store की जा सकती हैं
  - इसी वजह से Photoshop में कई layers दिख सकती हैं, लेकिन दूसरे software में सिर्फ एक layer दिखाई देती है
यह spec पहले से व्यापक रूप से implemented चीज़ों को औपचारिक रूप देने के काफ़ी करीब है
- अगर अगली पीढ़ी के PNG के लिए नया decoder चाहिए होता, तो इसे PNG2 कहना भी ठीक रहता
- JPEG-XL पहले से ही उस lossless codec की ज़्यादातर शर्तें पूरी करता है जो लोग चाहते हैं
  - समस्या encoding/decoding speed और resource usage की है
- मौजूदा समय का सबसे अच्छा lossless image codec HALIC है
  - विस्तृत चर्चा: HN HALIC discussion
- HALIC discussion thread देखने पर लगता है कि वास्तव में LEA 0.5 बेहतर है
  - Image lossless compression benchmark में HALIC top tier में नहीं है
- सच कहूँ तो मैंने कुछ समय तक JPEG XL को सिर्फ "बहुत बड़ी images" के लिए समझकर नज़रअंदाज़ किया था
- मैं computer vision image annotation tool (XLabel) में png इस्तेमाल करता हूँ
  - class labels को सीधे image metadata में store किया जा सकता है, इसलिए अलग text files रखने की ज़रूरत नहीं पड़ती
  - आगे चलकर मैं ऐसे उपयोग के लिए उपयुक्त extension format बनाना चाहता हूँ
- WebP की lossless compression उद्योग में शीर्ष स्तर की है, फिर भी इसका व्यापक उपयोग नहीं है
  - इससे पता चलता है कि lossless compression में सर्वोच्च प्रदर्शन ही असली मुद्दा नहीं, बल्कि ecosystem adoption उससे बड़ा प्रश्न है
- encoding/decoding speed की समस्या समय के साथ सुधर सकती है
  - अतीत के jpg ecosystem में यह बदलाव वास्तव में हुआ है
आधिकारिक Exif data support शामिल होना सबसे अच्छी खबर है
- पहले भी header में custom data लिखा जा सकता था, लेकिन Exif support का स्वागत है
- वैसे जिज्ञासा है कि क्या Exif में gyroscope(घुमाव) या accelerometer(गुरुत्व) से जुड़े fields हैं
  - Google Camera app से ली गई तस्वीरों में यह जानकारी नहीं होती, इसलिए बाद में auto-correction या panorama stitching में कमी महसूस होती है
- accelerometer field(Exif.Photo.Acceleration) और altitude के लिए field(Exif.Photo.CameraElevationAngle) तो हैं,
  - लेकिन यह पूरे 3-axis को support नहीं करता
  - environmental sensors यानी आसपास की स्थिति के लिए कुछ fields हैं, लेकिन सिर्फ spec writers द्वारा तय कुछ खास मदों के लिए
  - Exif.Photo.MakerNote एक खुला क्षेत्र है जहाँ निर्माता अपनी मनचाही जानकारी रख सकते हैं, और इसकी size limit इतनी बड़ी है कि 9-axis data भी आराम से दर्ज किया जा सकता है
- Exif image rendering में rotation handling को लेकर भ्रम पैदा कर सकता है
  - पुराने और नए decoders Exif rotation के आधार पर image को अलग-अलग तरह से दिखा सकते हैं
  - Exif rotation पर decoder के लिए स्पष्ट recommendations न होने से double rotation जैसे bugs भी अक्सर होते हैं, जैसे desktop environment और library दोनों अलग-अलग rotation लागू कर दें
  - सिर्फ इतना अस्पष्ट सुझाव है कि "अगर decoder अलग से यह तय नहीं कर सकता कि Exif data भरोसेमंद है या नहीं, तो Exif data को केवल archival value वाला माना जाए"
  - मुझे लगता है कि पूरी backward compatibility के लिए "कभी rotate मत करो" जैसे स्पष्ट निर्देश ज़रूरी हैं
- camera के accelerometer या inertial navigation data को record करने के लिए कोई standard field नहीं है
  - Exif field list: exiv2 official tag description
- वास्तव में कई websites upload के समय अधिकांश Exif data हटा देती हैं
  - क्योंकि कुछ fields privacy या location tracking के लिए दुरुपयोग हो सकते हैं
- व्यक्तिगत रूप से मैं चाहूँगा कि लोग Exif की जगह XMP इस्तेमाल करें
  - Exif की संरचना अजीब है और मूल रूप से यह TIFF image को PNG के अंदर ठूँसने जैसा है
यह PNG spec पहले से प्रचलित तरीकों को औपचारिक रूप से standardize करता है
- सबसे अच्छा codec वह होना चाहिए जो हर जगह, किसी भी app में, OS shell या API, Linux आदि में भी काम करे
- HEIC या AV1 जैसे formats में अगर OS स्तर पर support न हो, तो file preview करना भी मुश्किल हो जाता है
- जो format ठीक से प्रचलन में न हो, उसे platform default नहीं बनना चाहिए
- मेरा काम कई image formats, यहाँ तक कि सिर्फ खास क्षेत्रों में इस्तेमाल होने वाले rare formats, से जुड़ा है
  - कई formats को सच में support करना बहुत बड़ी चुनौती है
  - libraries ऊपर से jpg/tif/heic support लिखती हैं, लेकिन क्या वे 30GB jpeg या पूरा metadata बिना समस्या support करती हैं, यह अलग सवाल है
- यह नया spec HEIC या AV1 से भी ज़्यादा उलझन पैदा कर सकता है
  - PNG के अंदर कौन-सा codec है, यह file खोलने से पहले बिल्कुल पता नहीं चलता
अब तक पहली बार देखा कि HDR का इस्तेमाल स्पष्ट रूप से brightness/contrast ratio विस्तार के बजाय "wide color space" के अर्थ में किया गया
लगता है शायद बहुत देर हो चुकी है
- और JPEG XL पहले से सभी features देता है: lossy/lossless compression, animation, HDR, Exif आदि, साथ ही advanced compression techniques जैसे finite-state entropy और ZStandard भी
- मुझे लगता है अलग PNG update की ज़रूरत नहीं, बस JPEG XL इस्तेमाल करना चाहिए
- लेकिन "बस adopt कर लो" वास्तविकता में काम नहीं करता
  - JPEG XL browser support status: 5 साल बाद भी सिर्फ एक browser support करता है
  - अगर browser vendors implement न करें, तो developers और users नए formats का उपयोग नहीं कर सकते
- "advanced compression techniques(ZStandard आदि)" के उल्लेख पर
  - ZStandard निश्चित परिवर्तन-दूरी वाले numbers, जैसे gradient, को compress करने में उल्टा अच्छा नहीं भी हो सकता
  - Bzip2 इस तरह के मामले में बेहतर हो सकता है, और उदाहरण की तरह जब दो variables, inner और outer repetition, color channels से मेल खाते हों, तब यह अधिक उपयुक्त है
  - वास्तविक data noise की वजह से इतना सरल नहीं होता, लेकिन इस तरह की algorithm तुलना फिर भी वास्तविकता से कुछ दूर हो सकती है
    - संदर्भ: related Mastodon discussion
- "PNG update की ज़रूरत नहीं, बस JPEG XL अपना लो"
  - तो यह बात Google से कहनी चाहिए
  - वास्तव में Google ने Chrome में JPEG XL support छोड़ दिया(related issue), और इससे ecosystem expansion रुक गया
- समझ नहीं आता कि फिर एक और standard(derived variant) क्यों बनाया जा रहा है
  - पहले ही काफ़ी confusion है, और बिना किसी खास selling point के नए standards लगातार बढ़ते जा रहे हैं
अब GIF को APNG(alpha blending + transparent background + lossless compression) से replace किया जा सकता है, तो 2000s के web का एहसास फिर लौट सकता है
- जिज्ञासा है कि क्या Animated SVG का भी कोई standard है
  - पहले JavaScript-based SVG animation, जैसे chatbot avatar, देखे हैं, लेकिन पता नहीं कोई standard framework है या नहीं
- Animated SVG मौजूद है
  - मुख्य SVG animation elements: set, animate, animateTransform, animateMotion
  - विस्तार से: SVG animation related material
- मेरी जानकारी में आजकल GIF की जगह बिना audio वाले videos, जैसे mp4, ज़्यादा अच्छी compression देते हैं और इसलिए ज़्यादा उपयोग होते हैं
  - जानना चाहूँगा कि animated PNG, AV1 जैसे video formats की तुलना में कितना प्रतिस्पर्धी है
- ज़्यादातर services जो GIF upload support करती हैं, उनमें APNG या animated WEBP support लगभग नहीं के बराबर है
  - backend support व्यावहारिक रूप से शून्य के करीब होने से बहुत निराशा होती है
- छोटे videos को animated graphics में बदलने पर WEBP मूल रूप से APNG से बेहतर रहा है
  - अगर GIF को intermediate format बनाया जाए तो APNG कुछ हद तक प्रतिस्पर्धी हो सकता है
  - आजकल AVIF सबसे अच्छा विकल्प है
- कुछ साल पहले Lottie(Bodymovin) library इस्तेमाल करने का अनुभव रहा है
  - Adobe After Effects में animation बनाकर, उसे svg और json में export किया, फिर lottie JS से web पर आसानी से animation लागू किया
  - लगा कि vector web animation के लिए अच्छे tools या DX(developer experience) की कमी है
  - animated PNG के tools और DX के बारे में भी जानना चाहूँगा
PR में यह दावा था कि "कई programs पहले से नए PNG spec को support करते हैं"
- Photoshop के APNG support का उल्लेख गलत है
  - APNG recognition, What's new की दूसरी item होने के बावजूद, वास्तव में Photoshop में support नहीं है, यह देखकर निराशा हुई
- Photoshop HDR हिस्सा support करता है, लेकिन APNG हिस्सा support नहीं करता
किसी ने कहा कि लोगों को समय/तारीख की अनिश्चितता को software में एकसमान तरीके से manage करने की ज़रूरत है
- जैसे "photo 2025 में scan हुई, सामग्री Easter के आसपास की है, 1920~1940 के बीच की" जैसी अस्पष्ट समय जानकारी संभालने की ज़रूरत
- EXIF में DateTimeDigitized field मौजूद है
  - अस्पष्ट तारीख़ अभिव्यक्ति के लिए EDTF spec भी है
    - संदर्भ: EXIF field description, EDTF spec official document
- Google Photos और Apple Photos में तारीख़ सीधे सेट की जा सकती है, लेकिन वे उसे वास्तव में EXIF में save नहीं करते
  - platform बदलने पर EXIF न होने वाली images की date information भी साथ में खो जाने की समस्या होती है