डेटा कॉम्प्रेशन (अच्युत गोडबोले)

आज इंटरनेटवरून अक्षरशः लाखो टेक्‍स्ट फाईल्स, फोटोग्राफ्स, ऑडिओ किंवा व्हिडिओ क्‍लिप्स या वेगवेगळ्या माध्यमातल्या (मीडिया) क्‍लिप्स किंवा फाइल्स एका ठिकाणाहून दुसरीकडं पाठवल्या जातात. त्या तितक्‍याच वेळा लाखो, कोट्यवधी लोकांना फॉर्वर्डही केल्या जातात. या 0 आणि 1 च्याच रूपात असतात. आता इतके सगळे कोट्यवधी बिट्‌स सतत इंटरनेटवरून लाखो ठिकाणी पाठवायचे म्हटलं, की त्यात इंटरनेटची बॅंडविड्‌थ खर्च होईलच; पण त्यात वेळही खूप जाईल. त्यामुळं प्रत्येक फोटो किंवा व्हिडिओ क्‍लिप डाऊनलोड करायला प्रचंड वेळही लागेल. मग हे टाळण्यासाठी किंवा निदान कमी करण्यासाठी "डेटा कॉम्प्रेशन'ची कल्पना निघाली.

आज इंटरनेटवरून अक्षरशः लाखो टेक्‍स्ट फाईल्स, फोटोग्राफ्स, ऑडिओ किंवा व्हिडिओ क्‍लिप्स या वेगवेगळ्या माध्यमातल्या (मीडिया) क्‍लिप्स किंवा फाइल्स एका ठिकाणाहून दुसरीकडं पाठवल्या जातात. अगदी पंढरपूरपासून सॅनफ्रान्सिस्कोलाही! आणि तितक्‍याच वेळा लाखो, कोट्यवधी लोकांना फॉर्वर्डही केल्या जातात. या शेवटी 0 आणि 1 च्याच रूपात असतात. आता इतके सगळे कोट्यवधी बिट्‌स सतत इंटरनेटवरून लाखो ठिकाणी पाठवायचे म्हटलं, की त्यात इंटरनेटची बॅंडविड्‌थ (म्हणजे काय ते आपण नंतर बघूच) तर खर्च होईलच; पण त्यात वेळही खूप जाईल. त्यामुळं प्रत्येक फोटो किंवा व्हिडिओ क्‍लिप डाऊनलोड करायला प्रचंड वेळही लागेल. मग हे टाळण्यासाठी किंवा निदान कमी करण्यासाठी "डेटा कॉम्प्रेशन'ची कल्पना निघाली. आज इंटरनेटची बॅंडविड्‌थ आणि म्हणून त्याचा वेग वाढला आहे, त्यामुळं आपल्याला हा प्रश्न चटकन्‌ लक्षात येत नाही. पण काही वर्षांपूर्वी जेव्हा इंटरनेटचा वेग खूपच कमी होता, तेव्हा कॉम्प्रेशनशिवाय तर गत्यंतरच नव्हतं. कारण नाही तर मोठा व्हिडिओ डाऊनलोड व्हायला कित्येक तास/दिवस लागले असते.

थोडक्‍यात सांगायचं म्हणजे कुठल्याही फाईलचा आकार कमी करणं म्हणजे "डेटा कॉम्प्रेशन.' त्या फाईलमधले बिट्‌स कमी केल्याशिवाय ते कॉम्प्रेशन होऊ शकत नाही. हे कॉम्प्रेशन दोन प्रकारचं असतं. एक म्हणजे "लॉसलेस' आणि दुसरं म्हणजे "लॉसी.' "लॉसलेस कॉम्प्रेशनमध्ये कुठल्या तरी युक्तीनं बिट्‌स कमी होतात; पण ती कॉम्प्रेस केलेली कमी बिट्‌सची फाईल पाहिजे त्या ठिकाणी पाठवली, की तशीच युक्ती उलट्या तऱ्हेनं वापरून आपल्याला ती फाईल "डी-कॉम्प्रेस' करता येते. तसं केल्यावर त्या फाईलमधलं बिट्‌स पुन्हा जसेच्या तसे मिळतात. यात कुठलेच बिट्‌स गायब होत नाहीत. म्हणूनच याला "लॉसलेस' म्हणतात. बऱ्याच वेळा टेक्‍स्ट फाईलमध्ये हे वापरतात. उदाहणार्थ, समजा कंपनीच्या चेअरमननं जे भाषण करायचंय ते मला माझ्या पीसीवरून चेअरमनच्या पीसीवर पाठवायचंय. आता जर ते पाठवताना कॉम्प्रेस करण्याच्या नादात त्यातला मजकूर बदलला, तर गडबडच व्हायची आणि तो चेअरमन भलतंच काहीतरी बोलायला लागायचा. त्या "थ्री इडियटस्‌'मधल्या चतुर रामलिंगमचं भाषण बदलल्यावर केवढा गोंधळ माजतो हे आपण सिनेमात बघितलंच आहे. तसंच आपला बॅंक-बॅलन्स बॅंकेला आपल्याला कळवायचा असेल, किंवा कुठल्याही कंपनीला आपला ऍन्युअल रिपोर्ट शेअरहोल्डर्सना पाठवायचा असेल, तर तो जसाच्या तसा मिळावा अशी अपेक्षा असते. म्हणूनच यात कुठलाही बदल किंवा "लॉस' होऊन चालत नाही; पण याचा अर्थ कॉम्प्रेशन करता येत नाही असं मुळीच नाही. ते करता येतंच आणि करतातही.

मजकुरावर सगळ्यांत सोपी कॉम्प्रेशनची पद्धत म्हणजे रन लेंग्थ एनकोडिंग. उदाहरणार्थ, एखाद्या मजकुरात AAAABBCCCCC म्हणजेच चार वेळा A, दोन वेळा B आणि पाच वेळा C अशी अक्षरं असतील, तर त्या ऐवजी 4A2B5C असं पाठवता येतं. दुसऱ्या बाजूला हे आकडे आणि अक्षरं वाचून उलट पद्धत वापरून मूळ अक्षरं ओळखता येतात.

मात्र, अशा तऱ्हेनं एकापाठोपाठ रिपीट होणारी अक्षरं किंवा आकडे मजकुरात (टेक्‍स्ट) सतत असतीलच असं नाही. मग त्यासाठी आणखी एक युक्ती वापरतात. त्यासाठी आपण एक उदाहरण घेऊ. सन 1961 मध्ये जॉन एफ. केनेडींनी एक भाषण केलं होतं. त्यात ते म्हणाले होते ः "Ask not what your country can do for you; ask what you can do for your country.'' ही सगळी अक्षरं आणि दोन शब्दांमधल्या स्पेसेस धरून यात कॅरेक्‍टर्स होतात. आता हा मजकूर कॉम्प्रेस करताना ठराविक शब्दांसाठी काही कोडनंबर ठरवतात. उदाहरणार्थ, 1 म्हणजे ask, 2 म्हणजे what, 3 म्हणजे your, 4 म्हणजे country, 5 म्हणजे can, 6 म्हणजे do, 7 म्हणजे for आणि 8 म्हणजे you. आता आपला मजकूर "1 not 2 3 4 5 6 7 8 ; 1 2 8 5 6 7 3 4' असा होईल आणि दोन्ही कोडनंबरमधल्या (म्हणजेच शब्दांमधल्या) स्पेसेस धरल्या, तर त्यात फक्त 37 कॅरेक्‍टर्स होतात. म्हणजे 79 ऐवजी फक्त 37 कॅरेक्‍टर्सच पाठवावी लागतात. दुसऱ्या बाजूलाही ही कोडभाषा माहीत असल्यामुळे तो डीकॉम्प्रेशनचा प्रोग्रॅम तो तो नंबर बघून त्या त्या जागी योग्य तो शब्द घालून पुन्हा मूळचं वाक्‍य निर्माण करू शकतो. म्हणजे यात 79-37 म्हणजे 42 कॅरेक्‍टर्स किंवा कमीत कमी 42 X 8 म्हणजेच 336 बिट्‌स पाठवायचे वाचले. कॉम्प्रेशन रेशो म्हणजे कॉम्प्रेशनपूर्वीचे बिट्‌स/कॉम्प्रेशननंतरचे बिट्‌स म्हणजेच (79 X8 )/(37 X 8) = 79/37 म्हणजेच 2.14.
मात्र, या स्कीममध्ये आणखी सुधारणा करणं शक्‍य आहे. या स्कीममध्ये कुठल्याही शब्दासाठी एक नंबर किंवा कॅरेक्‍टर म्हणजेच 8 बिट्‌स योजले आहेत. कुठल्याही मोठ्या मजकुरात इतके शब्द असतात, की त्या सगळ्यांसाठी कोड बनवताना प्रत्येक शब्दासाठी एक कॅरेक्‍टर पुरणार नाही. त्यामुळं प्रत्येक शब्दासाठी दोन, तीन किंवा चार कॅरेक्‍टर्ससुद्धा वापरावी लागतील. मग यासाठी संशोधकांच्या डोक्‍यात एक युक्ती आली. जे शब्द वारंवार येतात, त्यांच्यासाठी कमी बिट्‌सचं लहान कोड आणि जे शब्द फार वेळा येत नाहीत त्यांच्यासाठी जास्त बिट्‌सचं कोड असं केलं तर पाठवायचे बिट्‌स कमी होतील अशी ती युक्ती होती.

खरं तर सन 1838मध्ये तारायंत्र शोधून काढणारा अमेरिकन संशोधक सॅम्युएल मॉर्स यानं मॉर्स कोडची याच तत्त्वावर रचना केली होती. त्याची कोडभाषा डॉटस्‌ किंवा टिंब ( . ) आणि डॅश किंवा रेघ ( - ) यांनी बनली होती. आपल्या संदेशात इंग्रजी E आणि T ही अक्षरं सतत येतात हे त्यांच्या लक्षात आलं होतं. त्यामुळे त्यानं E म्हणजे फक्त एक टिंब ( . ) आणि T म्हणजे फक्त एक रेघ ( - ) असं लहानसं कोड ठरवलं. त्याखालोखाल A हे अक्षर येतं. म्हणून त्यासाठी त्यानं टिंब आणि रेघ ( . - ) असं कोड ठरवलं. त्यांतर मग D साठी रेघ, टिंब, टिंब ( - . . ) आणि मग F म्हणजे टिंब, टिंब, रेघ आणि टिंब ( . . - . ) अशी सगळ्यांसाठी कोड ठरली. हा कॉम्प्रेशनचाच प्रकार होता.

याच धर्तीवर 1940 च्या दशकात कुठले शब्द किंवा वाक्‍यं किती वारंवारितेनं (फ्रीक्वेन्सी) संवादात किंवा टेक्‍स्टमध्ये येतात याचा अभ्यास करून त्यावर प्रसिद्ध कॉम्प्युटर सायंटिस्ट क्‍लॉड शॅनन आणि रॉबर्ट फॅनो यांनी एक कोडिंग सिस्टिम बनवली. सन 1951मध्ये डेव्हिड हफमन यानं यात सुधारणा करून हफमन कोडिंगची पद्धत काढली. यातही वारंवार वापरल्या जाणाऱ्या शब्दांना लहान कोड आणि कमी वापरल्या जाणाऱ्या शब्दांना मोठं कोड अशी योजना होती. ही पद्धती 1970 च्या दशकात कॉम्प्युटर फाईल्सवर वापरायला सुरवात झाली. त्यानंतर 1980 च्या दशकात एलझेडडब्ल्यू (LZW) नावाची एक पद्धत निघाली.

पुढं 1980 च्या दशकाच्या शेवटी छायाचित्रं आणि चित्रं एका ठिकाणाहून दुसरीकडे पाठवणं सुरू झालं. पण एक फोटो एका ठिकाणाहून दुसरीकडे पाठवायचा म्हणजे त्यातले बिट्‌स पाठवावे लागतात. रेझोल्युशन जास्त असेल आणि फोटो रंगीत असेल, तर खूपच बिट्‌स पाठवावे लागतात. त्यामुळं इथं कॉम्प्रेशन करणं अतिशय आवश्‍यक ठरतं. एक महत्त्वाचं. फोटो, ऑडिओ किंवा व्हिडिओ यांचं कॉम्प्रेशन लॉसी असलं तरी चालतं. म्हणजे त्यातले काही बिट्‌स नष्ट झाले तरी चालतं. म्हणजे दुसऱ्या टोकाला जरी डीकॉम्प्रेस करून मिळवलेला फोटो हुबेहूब पहिल्या फोटोसारखा दिसला नाही, तरी जोपर्यंत तो जवळजवळ तसाच दिसतोय, तोपर्यंत फारसं बिघडत नाही.

उदाहरणार्थ, समजा छापलेल्या एका पानाचा आपण कॅमेऱ्यानं फोटो काढून पाठवतोय. आता त्यात मजकूर सोडून बाजूला एकसारखा पांढरा किंवा तत्सम काहीतरी रंग असतो. तो आपल्याला कॉम्प्रेस करता येतो. याचं कारण त्या पांढऱ्या भागासाठी जेवढ्या ओळी (रोज) असतात, त्यातले सगळेच बिट्‌स पांढराच रंग दाखवतात. त्यामुळं फक्त एकदाच कुठला रंग आहे आणि तो किती वेळा रिपीट करायचा आहे हे पाठवलं, की दुसऱ्या बाजूला तो रंग पुन्हा तितक्‍या वेळा किंवा तितक्‍या ओळींसाठी रिपीट करून निर्माण करतात येतो. पण यामध्ये तो मजकूर सोडून उरलेला भाग पूर्णपणे पांढरा नसला आणि तरीही आपण तो पूर्ण रंग पांढराच दाखवला, तर फोटो जसाच्या तसा राहत नाही; पण त्यानं फारसं बिघडत नाही. याचप्रमाणं कुठल्याही फोटोमध्ये काय साम्य दिसतंय हे बघून ते एकदाच पाठवून रिपीट करता येईल का हे शोधता येतं. व्हिडिओचं तसंच असतं. व्हिडिओमध्ये थोड्या थोड्या फरकानं दर सेंकदाला 10 पेक्षा जास्त दरानं फोटोज दाखवावे लागतात. तरंच ते सलग वाटतात. मात्र, यामध्ये एकापाठोपाठच्या दोन फोटोंमध्ये खूपच कमी फरक असतो. त्यामुळे व्हिडिओ कॉम्प्रेस करणारं सॉफ्टवेअर पहिला फोटो संपूर्णपणे पाठवतं; पण त्यापुढच्या फोटोमध्ये पहिल्या फोटोपेक्षा काय वेगळं आहे तेवढंच पाठवतं. आणि मग असंच त्यापुढच्या फोटोंमध्येही करतात. अशा तऱ्हेनं पाठवायचे बिट्‌स खूप कमी होतात. यात काही बिट्‌स गाळल्यामुळे हे कॉम्प्रेशन लॉसी असतं; पण त्यामुळे फोटो किंवा व्हिडिओ पाठवायचा वेग वाढतो. HDTV हा व्हिडिओ कॉम्प्रेशन करण्यासाठी MPEG-2 अल्गॉरिदम किंवा फॉर्मेट वापरतो. लॉसलेस कॉम्प्रेशनमध्ये सर्वसाधारणपणे 3:1 असा कॉम्प्रेशन रेशो मिळतो, तर लॉसी कॉम्प्रेशन वापरलं, तर त्यात 20:1 असा कॉम्प्रेशन रेश्‍यो मिळतो.

वर्ल्ड वाईड वेब लोकप्रिय झाल्यावर लोक अनेक फाईल्स आणि फोटोज, व्हिडिओज शेअर आणि डाऊनलोड करायला लागले. त्यामुळे मोठ्या प्रमाणावर कॉम्प्रेशन करायची गरज निर्माण झाली.

सन 1987 मध्ये निघालेल्या GIF या लॉसलेस पद्धतीमध्ये फोटो किंवा ऍनिमेशन कॉम्प्रेस करता येतं. सन 1889 मध्ये फिल कॅटझ्‌नं "झिप (ZIP)' हा लॉसलेस फाईल फॉर्मेट काढला. आजही आपण अनेक फाईल्स ZIP फॉर्मेटमध्ये पाठवतो. त्याच वर्षी फ्रॉनहॉफर जेसेलशॅफ्ट या जर्मन कंपनीनं MP3 फॉर्मेटसाठी जर्मन पेटंट मिळवलं. सन 1992 मध्ये जॉइंट फोटोग्राफिक एक्‍स्पर्टस्‌ ग्रुप (JPEG) यांनी JPEG हा लॉसी अल्गॉरिदम काढला. त्यामध्ये आपल्याला पर्याय दिलेला असतो. जर कॉम्प्रेशन रेशो फार जास्त ठेवला नाही, तर इमेजचा दर्जा वाढतो. सन 1993 मध्ये यूजीन रोशल या रशियन सॉफ्टवेअर इंजिनिअरनं RAR हा अल्गॉरिदम तयार केला, तर 1996 मध्ये इमेजसाठी "पोर्टेबल नेटवर्क, ग्राफिक्‍स (PNG)' हा एक लॉसलेस फॉर्मेट निघाला.
MP3 कसं कॉम्प्रेशन करतं ते समजून घेणं मजेदार आहे. आपण साधी गाण्याची सीडी जेव्हा तयार करतो, तेव्हा त्यातल्या संगीताचे ऍनेलॉग सिग्नल्स दर सेंकदामध्ये 44,100 वेळा मोजले जातात. प्रत्येक मोजमापासाठी (रीडिंग) जो आकडा मिळेल, तो साठवून ठेवण्यासाठी 2 बाइट्‌स किंवा 16 बिट्‌स राखून ठेवलेले असतात. शिवाय जर स्टिरिओ सिस्टिम असेल, तर प्रत्येक स्पीकरमधून ऐकू येणाऱ्या संगीतासाठी तेवढेच वेगळे बिट्‌स साठवावे लागतात. थोडक्‍यात हे बिट्‌स म्हणजे दर सेकंदाला 2 X 16 X 44100 इतके म्हणजे दर सेंकदाला 14,11,200 बिट्‌स किंवा त्याला 8 नं भागलं, तर दर सेकंदाला 1,76,000 बाइट्‌स होतात. जर गाणं 3 मिनिटांचं म्हणजे 180 सेंकदाचं असेल, तर त्यासाठी 180 X 176000 म्हणजेच जवळजवळ 32 मिलियन बाइट्‌स म्हणजेच 32 मेगाबाइट्‌स (MB) इतकी जागा सीडीवर, डिस्कवर किंवा पेन ड्राईव्हवर लागेल. एवढं मोठं गाणं डाऊनलोड करून ऐकण्यात मग खूपच वेळ जाईल.
पण अशा वेळी MP3 फॉर्मेट उपयोगी पडतो. तो 10 ते 14 पट बिट्‌स कमी करतो. आणि त्यामुळे 32 MBचं गाणं 3 MB मध्ये बसू शकतं. यामुळे आपल्याला ते गाणं चटकन्‌ डाऊनलोड करून ऐकता येतं. शिवाय याचमुळे मग एका 750 MB च्या CD cध्ये शेकडो गाणी मावू शकतात.