بخشی از مقاله

فرمت های مختلف تصاویر

مقدمه:
مزيت JPEG پيشرفته اينست كه اگر يك تصوير ضمن اينكه منتقل مي شود، بلافاصله نمايش داده شود، شما مي توانيد خيلي بسرعت كل تصوير را بطور تقريب با اصلاح تدريجي كيفيت ببيند تا كسي كه مدت طولاني تري منتظر مي ماند و اين خيلي مجهتر از يك نمايش كند ازبالا تا پايين تصوير مي باشد. صغفش اينست كه هر اسكني حدوداًبه ميزان يكساني محاسبه براي نمايش، متوسل مي شود همانطور كه كل فايل JPEG خط مبنا بايد باشد. بنابراين JPEG پيشرفته فقط وقتي حساس مي شود كه فردي كُدبرداري داشته باشد كه در مقايسه با اتصال ارتباطي سريع


است. (اگرداده ها بسرعت برسد، يك كُدبرداري // پيشرفته مي تواند بوسيله جهش بعضي گذرهاي نمايشي، وفق يابد. از اينرو كُد برداري شما به قدر كافي فرمت دارد تا TI داشته باشد يا اتصالات شبكه اي سريعتر ممكن است هيچ تفاوتي رابين JPEG پيشرفته، و با قاعده نبيند، اما بر روي يك اتصال سرعت مودم، JPEG پيشرفته، وسيع مي باشد.)
تا همين اواخر، كاربردهاي زيادي در JPEG پيشرفته كه جذاب بنظر مي رسيد، وجود نداشت، بنابر اين آن بطور وسيعي اجرا نمي گشت. اما با شهرت جستجو گرهاي شبكه جهاني وب در اجراي اتصالات كند مودم و با اسب بخار در حال افزايش كامپيوترهاي شخصي، JPEG پيشرفته برنده كاربرد شبكه جهاني وب شده است

، نرم افزار JPEG آزاد JJG اكنون از JPEG پيشرفته حمايت مي كند وتوانايي جستجو گرها و ديگر برنامه هاي شبكه جهاني وب بسرعت گسترده مي گردد. به استثناي توانايي فراهم كردن نمايش پيشرفته، // JPEG پيشرفته و JPEG خط مبنا اساساً يكسان هستند و آنها بخوبي بر روي انواع تصوير هاي مشابه كار مي كنند. ممكن است بين نمايش هاي خط مبنا و پيشرفته يك تصويررا بدون لطمه به كيفيت تبديل مي كند (اما براي انجام اين مورد نرم افزارخاصي نياز مي باشد،

تبديل بوسيله خروج از فشردگي و دوباره فشرده كردن به دليل خطاهاي گردكردن برشي بدون خسارت نمي باشد.) يك فايل JPEG پيشرفته به هيچ وجه فقط بوسيله يك كُد برداري JPEG خط مبنا، قابل خواندن نيست، بنابر اين نرم افزار موجود بايد قبل از اينكه JPEG پيشرفته را بتوان بطور گسترده اي استفاده كرد، ارتقاء يابد. موضوع 16 در بخش 2 را براي آخرين اخبار در مورد برنامه هايي كه از آن پشتيباني مي كنند، ببينيد. مي توانم من يك JPEG شفاف بسازم؟


نه. JPEG از شفافيت پشتيباني نمي كند و احتمالاً آنرا به سرعت انجام نمي دهد. آن آشكار مي كند كه اضافه شدن شفافيت به JPEG نبايد كار ساده اي باشد. اگر جزئيات كاملي مي خواهيد تا پايان بخوانيد و كسب اطلاع كنيد. شيوة قديمي براي شفافيت كُد در GIF ديگر الگوهاي فايلي يافت شده، يك مقدار رنگي كه از جهات ديگر استفاده نشده براي كه نشانگر يك سلول تصويري شفاف مي باشد،

انتخاب مي شود كه نمي تواند در JPEG كار كند. زيرا JPEG پراتلاف مي باشد. يك سلول تصويري ضرورتاً با همان رنگي كه با آن شروع شده، آشكار نمي شود. بطور معمول يك خطاي جزئي در مقدار سلول تصويري عيبي ندارد. زيرا بطور جزئي تصوير را تحت تأثير قرار مي دهد. اما اگر آن سلول تصويري را از شفاف به نرمال يابد. عكس تغيير دهد، اين خطا كاملاً آشكار و مزاحم مي باشد، بخصوص اگر زمينة اصلي كاملاً متفاوت از رنگ شفاف باشد. يك شيوة معقولانه تر ذخيره كردن كانال آنها (درصد شفافيت) همانند يك عنصر جداگانة رنگ در يك تصوير JPEG مي باشد.


آن مي تواند كار كند زيرا يك خطاي كوچك در آلفا فقط تفاوتي جزئي در نتيجة كار ايجاد مي كند. مشكل اينست كه كانال آلفاي معمولي دقيقاً نوعي از تصوير باشد كه بطوري بدي بر روي JPEG انجام مي شود. مقدار زيادي نواحي مسطح بزرگ و پرشهاي ناگهاني. شما بايد از يك مجموعه با كيفيت بسيار بالا براي كانال آلفا استفاده كنيد. اين كار را مي توان انجام داد، اما اين پنالتي براي اندازة فايل بزرگ مي باشد. يك JPEG شفاف اين شيوه را كه مي تواند به آساني اندازة يك JPEG غيرشفاف را دوبرابر كند، انجام مي دهد. قيمت پرداختي بيشترين كاربردهاي شفافيت بسيار بالا مي باشد.

تنها راه حل واقعي اينست كه ذخيره سازي پراتلاف تصوير JPEG را با ذخيره سازي بدون اتلاف يك الگوي (پوشش) شفافيت با استفاده از تعدادي الگوريتم ديگر تركيب كنيد. توسعه، استانداردسازي، و ترويج توانايي يك قالب فايل براي كاركردن، كار كوچكي نيست. تا آنجايي كه من مي دانم هيچ كار جدي بر روي آن انجام نشده و بنظر نمي رسد كه شفافيت ارزش تلاش و كار بيشتري داشته باشد.

 

يك JPEG بدون اتلاف وجود ندارند؟
آشفتگي زيادي در مورد اين موضوع وجود دارد كه تعجب برانگيز نيست. زيرا چندين شيوة مقايسه اي مختلف وجود دارد كه همگي بعنوان JPEG شناخته شده مي باشد. شيوه اي كه معمولاً استفاده مي شود، JPEG خط مبنا مي باشد. (يا نوع ديگرش JPEG پيشرفته مي باشد.) همچنين استاندارد ايزو (JSO) مشابهي يك شيوة بسيار متفاوت بنام JPEG بدون اتلاف را تعريف مي كند.

اگر خيلي آشفته نباشد، يك استاندارد جديد بدون اتلاف بنام «JPEG LS» تقريباً سر از خيابانها درمي آورد. وقتي مي گويم «بدون اتلاف» منظورم از بي اتلاف از نظر رياضياتي اين مي باشد كه: يك الگوريتم مقايسه اي بدون اتلاف، الگوريتمي است كه خروجي (برونداد) از فشردگي خارج شده اش را كه بيت به بيت با ورود (درونداد) اصلي يكسان مي باشد، ضمانت مي كند. اين يك ادعاي قوي تر از «غيرقابل تفكيك شدن تصويري از اصل» مي باشد.


JPEG خط مبنا مي تواند به تصويري با قابليت تفكيك پذيري براي تصاويري كه بيشترين شباهت را به عكس دانرد، دست يابد، اما آن نمي تواند هرگز كاملاً بدون اتلاف باشد. JPEG بدون اتلاف يك شيوة كاملاً متفاوت است كه واقعاً بدون اتلاف مي باشد. با اين وجود آن كمابيش همانند JPEG خط مبنا فشرده نمي شود، آن بطور معمولي مي تواند داده هاي تمام رنگي را تا حدود 2:1 فشرده كند و JPEG بدون اتلاف بخوبي فقط بر روي تصاوير آهنگ پيوسته كار مي كند.


آن فشردگي مُفيدي از تصاوير صفحه رنگ يا تصاويري با بيت عمق كم تهيه نمي كند. JPEG بدون اتلاف در حقيقت هرگز به شهرت نرسيده و هيچ كاربرد معمولي آنرا پشتيباني نمي كند و آن اكنون كاملاً غيرقابل استفاده مي باشد. (براي مثال استاندارد جديد PNG ، JPEG بدون اتلاف را بر روي بيشترين تصاوير فشرده مي سازد.) با درك اين مطلب كميتة ISO JPEG اخيراً يك استاندارد فشردگي بدون اتلاف كاملاً جديد بنام JPEG-LS را تكميل كرده است. (شما همچنين ممكن است از آن تحت نام LOCO مي شنويد.) JPEG-LS ، فشردگي بهتري از JPEG اصلي بدون اتلاف ارائه مي دهد، اما هنوز نزديك به آن چيزي كه شما مي توانيد با يك شيوة پُراتلاف بدست آوريد، نمي شود.


هر كسي حدس مي زد كه آيا اين استاندارد جديد به شهرت مي رسد يا نه. آن تكرار باارزشي مي باشد كه يك اجراي منظم JPEG را با حداكثر حالت كيفيتش آغاز مي كند كه به شما ذخيره سازي بدون اتلاف نمي دهد، حتي در بالاترين حالت كيفيت ممكن. JPEG خط مبنا پراتلاف مي باشد. زيرا آن به خطاهاي گِرد كردن برشي در محاسبات مختلف منوط مي شود. خطاهاي گِرد كردن برشي به تنهايي تقريباً هميشه خيلي كوچكتر از آني است كه ديده شود. اما اگر شما تصوير را از طريق چرخه هاي چندگانه فشردگي مرتبط كنيد، آنها انباشته مي شوند

خيلي از اجراها حتي به شما اجازه نمي دهند كه به حداكثر محيط ممكن دست يابيد، زيرا آن همانند يك شيوة كم بازده براي استفادة JPEG منظم مي باشد. براي مثال با نرم افزار JJG JPEG شما مجبور نيستيد فقط «كيفيت 100» را انتخاب كنيد. همچنين نمونه برداري از كارافتادة كروما (رنگ) را براي به حداقل رساندن اتلاف اطلاعات، خاموش كنيد. فايل هاي نتيجه خيلي بزرگتر مي باشند و فقط از نظر كسري كيفيت بهتري از فايل هاي توليد شده در محيطهاي معقولانه تري دارد. آنها هنوز كمي پراتلاف مي باشند. اگر شما واقعاً به ذخيره سازي بدون اتلاف نياز داريد، تلاش نكنيد با JPEG منظم به آن نزديك شويد.


چرا تمام مدارك در مورد قالبهاي فايل مي باشد؟
JPEG فقط به خانوادة الگوريتم هاي فشردگي اشاره مي كند نه به يك قالب فايل تصوير ويژه. كميتة JPEG از تعريف قالب فايل توسط جنگهاي قلمروي در داخل سازمانهاي بين المللي استانداردها جلوگيري مي كند. از آنجايي كه ما نمي توانيم عملاً تصاوير را هر شخص ديگري تعويض كنيم مگر اينكه بر روي يك قالب فايل مشترك توافق كنيم. اين مورد براي ما يك مشكل بوجود مي آورد.

در غياب استانداردهاي رسمي، تعدادي از نويسندگان برنامة JPEG فقط براي انجام كارهاي خودشان آنرا ترك مي كنند و در نتيجه برنامه هايشان با هر شخص ديگري قابل وفق نيست. نزديكترين چيزي كه ما با يك قالب JPEG استاندارد داريم، تعدادي كار است كه بوسيلة مردم در ميكروسيستم هاي C-Cube هماهنگ مي شود. آنها دو قالب فايل بر مبناي JPEG را تعريف مي كنند.


JFIF (قالب تغيير فايل JPEG) يك قالب ارزان قيمت كه سلولهاي تصويري را انتقال مي دهد نه چيز ديگري را. TIFF/JPEG ، TIFF 6/0 aka ، توسعة قالب Aldus TIFF . TIFF يك قالب گران قيمت مي باشد كه به شما اجازة ثبت فقط در مورد چيزي را مي دهد كه شما هميشه مي خواستيد در مورد يك يك تصوير و اطلاعات جانبي تر بدانيد. JFIF بعنوان يك استاندارد غيررسمي بر روي اينترنت ظاهر مي شود و چيزي است كه بطور معمول بوسيلة يك «فايل PEG » معني مي شود. بيشترين خوانندگان JFIF همچنين توانايي دستكاري تعدادي قالبهاي مختلف نه كاملاً قانوني JFIF را دارند.

خصوصيت TIFF 6/0 براي يكپارچه كردن JPEG بطور وسيعي اجرا نمي شود، زيرا تا اندازه اي آن تعدادي نقص جدي طرحي دارد. طرح بازبيني شده TIFF/TPEG اكنون بوسيلة يادداشت # 2 تكنيكي TIFF توصيف مي شود، اين طرح موردي بود كه در 0/7 TIFF استفاده شد. اجراهاي جديد TIFF بايد از طرح يادداشت تكنيكي براي توكاري كردن TIFF 6/0 استفاده كند نه از طرح. (تا جايي كه من مي دانم، سيستم هاي Next Step (قدم بعدي) تنها سيستم هايي هستند كه هرگونة كاربرد قابل توجهي از نوع TIFF/JPEG,TIFF 6/0 بوجود مي آورند.) حتي وقتي كه TIFF/JPEG ثابت است، آن هرگز بطور گسترده اي استفاده نخواهد شد.


TIFF خيلي پيچيده تر از JFIF مي باشد و بطور كلي خيلي قابل انتقال نمي باشد، زيرا عرضه كننده هاي مختلف اغلب با اختلاف كمي اجرا مي شود نه با همگامي دو يا چند عملكرد زيرمجموعه هاي TIFF. و اضافه كردن JPEG به اين تركيب هيچ كمك نكرده است. نرم افزار Quick Time مگينتاش از جريان داده هاي سازگار با JFIF بسته بندي شده داخل قالب DICT مخصوص Macاستفاده مي كند. تبديل بين JFIF و DICT/JPEG كاملاً مستقيم مي باشد. و چندين برنامة Max (ميگنتاش) براي انجام آن قابل دسترس مي باشد. اگر شما ويراستاري داريد كه فايل هاي دودويي را دستكاري مي كند، شما مي توانيد يك فايل DICT/JPEG را با JFIF بوسيلة دست تغيير دهيد. براي جزئيات فصل بعد را ببينيد.


فلاش خبر: كميتة SO JPEG بنظر مي رسد در جنگهاي قلمروي شان برنده شده اند. آنها ويژگي كامل قابل فايل را كه در پسوندهاي «بخش 3» جديد با استاندارد SPIFF,JPEG ، ناميده مي شود، تعريف مي كنند. اگرچه آن تا اندازه اي در بازي تازه است بنابراين آيا اين تأثير زيادي بر روي فايلهاي دنياي واقعي خواهد داشت تا ديده شوند. SPIFF با JFIF سازگاري رو به پيشرفت مي باشد، بنابراين اگر آن بطور گسترده اي پذيرفته شود، احتمالاً بيشتر كاربران حتي توجه هم نمي كنند.
چگونه بفهمم كه من قالب فايل دارم و چه چيزي در مورد آن انجام دهم؟


اگر شما يك به اصطلاح فايل JPEG داشته باشيد كه نرم افزارتان آنرا نمي خواند، آن احتمالاً تعدادي قالب اختصاصي بر مبناي JPEG مي باشد. شما مي توانيد با بررسي اولين چند بايت فايل بگوئيد چه چيزي دارد:
1ـ فايل استاندارد JFIF با چهار بايت (hen) FF D8 FF EO شروع مي شود و با دو بايت متغير (اغلب hex oo) و سپس با JFIF دنبال مي شود.
2ـ اگر شما FF D8 FF را در آغاز ببينيد، اما نشانگر JFIF را نبينيد، احتمالاً يك فايل ناقص JFIF JPEG داريد. بيشتر نرم افزارهاي JFIF بايد آنرا بدون شكايت بخوانند. اگر شما از چيزي استفاده مي كنيد كه به اندازه كافي براي شكايت در مورد فقدان يك نشانگر JFIF سختگير مي باشد، كُدبردار ديگري را امتحان كنيد.


(هم فايل هاي خيلي قديمي JPEG و هم فايل هاي خيلي جديد JDEG ممكن است فاقد نشانگرهاي JFIF باشد، استاندارد جديد SPIFF در بالا اشاره كرد كه از نشانگر JFIF استفاده نمي كند. بنابراين فروشندة نرم افزارتان را بيابيد اگر شما گمان مي كنيد اين مشكل ساز شود.)
3ـ فايل DICT مگينتاش در صورتيكه JPEG فشرده شده باشد، چند صد بايت سرانداز (عنوان) خواهد داشت. (اغلب 726 بايت، اما نه هميشه) كه به وسيلة داده هاي JPEG دنبال مي شود.


رشتة 3 بايتي FF D8 FF را جستجو كنيد. Pkoto - JPEG متن معمولاً قبل از اين عنوان بطور ناگهاني ظاهر مي شود، و Apple Mark يا JFIF معمولاً ناگهان بعد از آن ظاهر مي شود. هر چيزي را قبل از FF D8 FF دور كنيد و شما قادر خواهيد بود از فايل كُدبرداري كنيد. (اگر تصوير PICT به دو باند چندگانه تقسيم شود، اين عمل شكست مي خورد.) PLCT همدسته شده خوشبختانه خيلي معمول نيستند. يك PICT همدسته شده، شامل جريانات داده هايي است كه ارتفاعاتش به كل ارتفاع تصوير اضافه مي شود. اينها بايد با همديگر به پشت و در داخل يك تصوير دوخته شوند. بِيلي براون براي اين هدف بر روي صفحة وب، تعدادي ابزار ساده در http://www.isomedia (Com/homes/baily/photo-jpey/photo-jpeg.html) دارد.


4ـ اگر اين فايل از مگينتاش سرچشمه بگيرد، آن مي تواند يك فايل استاندارد JFIF همراه با يك عنوان Mac.Binan/ پيوست شده باشد. در اين مورد، عنوان JFIF بايت را در اين فايل ظاهر مي كند. از اولين 128 بايت صرفنظر كنيد و شما آماده هستيد.
5ـ هر چيزي ديگري: آن يك قالب اختصاصي است يا اصلاً JPEG نمي باشد، اگر خوش شانس باشيد، ممكن است اين فايل شامل يك عنوان و يك جريان داده هاي خام JPEG باشد.


حداقل يك نشر (عرضه) HiJaak pro ، فايلهاي JFIF را كه ادعاي بازبيني بيشتر 2.ol دارد، مي نويسد. هيچ چنين خصوصيتي وجود ندارد، آخرين بازبيني JFIF 1/02 مي باشد. بنظر مي رسد HiJaak موجب بايت ها بالا و پايين رو به عقب مي شود. متأسفانه بيشترين خوانندگان JFIF از مواجه با اين فايل ها صرفنظر مي كنند، زيرا اين ويژگي JFIF ، تغيير مهم شمارة نگارش را با ميانگين يك تغيير سازگار قالب تعريف مي كند. اگر نسخة (نگارش) 2.ol وجود داشت. بنابراين بايد شماره دار مي بود. زيرا نرم افزار جاري نمي توانست آنرا بخواند و نبايد تلاش كرد. (كسي نمي داند كه آيا HiJaak تا به حال در مورد آزمايش متقابل با نرم افزار افراد ديگر شنيده است.) اگر شما يكي از اين فايلهايي را كه بَد شماره دار شده، اجرا كنيد، مي توانيد آنرا با ويراستار فايل بدون دودويي و بوسيلة تغيير دوازدهمين بايت فايل از 2 تا 1، ثابت كنيد.
چه مشكلات مشترك سازگار ديگري وجود دارد؟


صرفنظر از مشكلات قال فايل كه در فصل قبل به آن اشاره شد، دلايل دردسر مشترك ديگري با انتقال JPEG ها وجود دارد. كُدبردارهاي قديمي كه JPEG پيشرشفته را دستكاري (كنترل) نمي كنند، اغلب وقتي يك JPEG پيشرفته را تغذيه مي كنند، پيغام هاي خطاي نسبتاً مبهمي را ارائه مي دهند. اگر شما يك شكايت شبيه «نشانگر پشتيباني نشدة نوع OxC2» دريافت كنيد، پس شما بطور يقين يك فايل JPEG پيشرفته و يك كُد بردار غيرپيشرفته داريد (بخش 2 از FAQ را براي اطلاعاتي در مورد برنامه هاي به روز شده، ببينيد.)

شما ممكن است يك پيغام خطاي عمومي (ژنريك) دريافت كنيد كه ادعا مي كند اين فايل خراب شده يا اصلاً JPEG نيست. فتوشاپ آدوبي و تعداد ديگري از كاربردهاي متمايل به پيش فشردگي، فايل هاي چهار كانالي JPEG CMYK را وقتي درخواست ذخيره سازي يك JPEG از حالت تصوير CMYK مي شود، توليد مي كنند. غيرمحتمل است هر چيزي كه درايت از پيش فشردگي ندارد، جوابگوي JPEG CMYK باشد. (يا هر قالب CMYK ديگري براي آن موضوع).

وقتي كه JPEG ها براي استفادة وب ساخته مي شوند، مطمئن شويد آنرا از RGB يا حالت مقياس سايه زني (خاكستري) ذخيره كرده ايد. فتوشاپ همچنين عادت بستن يك تصوير نسبتاً بزرگ پيش نمايش / تصوير كوچك شده را داخل يك بخش كاربردي خصوصي از فايل هاي JPEG دارد. تعدادي از كاربردهاي ديگر (بطور چشمگيري عرضه هاي اوليه از كتابخانة Suns Java) براي مسدود شدن بر روي اين داده ها شناخته شده است.

اين مسلماً يك خطا در ديگر كاربردهاي آنها مي باشد. اما قابل دسترس ترين پيرامون كاري مي گويد: فتوشاپ يك تصوير كوچك شده را ذخيره نمي كند. اگر شما در حل قرار دادن يك تصوير بر روي وب هستيد. تعبيه كردن تصوير كوچك شده در آن، به هر صورت اتلاف زمان انتقال است. وقتي انتقال تصاوير بين ماشين هايي كه سيستم هاي عملياتي مختلف را اجرا مي كنند براي كسب يك انتقال مستقيم «دودويي» بسيار با دقت باشد، هر نوع تبديل فرمت (قالب) متن، فايل JPEG را خراب مي كند. عملاً آن براي تمام قالب هاي تصاويري كه فقط JPEG نيستند، درست مي باشد.


چگونه JPEG كار مي كند؟
جزئيات تكنيكي خارج از بحث FAQ مي باشد اما شما مي توانيد يك مقدمه و مرجعي براي مطالب بعدي در Comp.Compress – in FAQ پيدا كنيد كه در اين سايت قابل دسترس مي FAQ باشد. http://www.faqs.org/fuqs/CompressiOn-faq (همچنين ببينيد «كجا ليست هاي بايگاني مي شود؟»). تركيب فشرده سازي FAQ يك نقطة شروع خوب براي اطلاعات بر روي ديگر شيوه هاي تكنولوژي جديد فشرده سازي تصوير مي باشد همانند فراكتال (كسرينه) و موجهاي كوچك.

در متن اصلی مقاله به هم ریختگی وجود ندارد. برای مطالعه بیشتر مقاله آن را خریداری کنید