مزیت 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 یک نقطه شروع خوب برای اطلاعات بر روی دیگر شیوه های تکنولوژی جدید فشرده سازی تصویر می باشد همانند فراکتال (کسرینه) و موجهای کوچک.
یک فشرده سازی سریع: موجهای کوچک احتمالاً براساس نسل بعد استانداردهای پراتلاف فشرده سازی تصویر می باشند.
اما شاید آنها 10 سال عقب تر از JPEG در استاندارد کردن خطوط موازی باشند.
فراکتال ها (کسرینه ها) بوسیله مبلغان تجاری مهم شان بیش از حد تحریک شدند و بنظر می رسید که اشتیاق را از دست داده اند که مردم بیشتر در مورد توانایی ها و محدودیتهای حقیقی شان یاد بگیرند.
کُدنویسی محاسباتی (حسابی) چگونه کار می کند؟
ویژگی JPEG دوماژول (واحد) کمکی مختلف را برای خروجی نهایی داده های فشرده شده، تعریف می کند: امکان یا کُدنویسی (برنامه نویسی) Huffman یا برنامه نویسی محاسباتی می باشد.
این انتخاب هیچ تأثیری بر روی کیفیت تصویر ندارد، اما برنامه نویسی محاسباتی معمولاً یک فایل فشرده شده کوچکتری ایجاد می کند.
بر روی تصاویر معمولی، برنامه نویسی محاسباتی یک فایل 5 تا 10 درصدی کوچکتر از برنامه نویسی Huffmen (هافمن) تولید می کند.
تمام شماره اندازه های فایل که قبلاً ذکر شده برای برنامه نویسی هافمن می باشد.
متأسفانه، نوع خاصی از برنامه نویسی محاسباتی بوسیله استاندارد TPEG مشخص می شود، منوط به پروانه های ساخت توسط JBM ، AT8T و میتسوبیشی می باشد.
بنابراین شما نمی توانید بطور قانونی از برنامه نویسی محاسباتی JPEG استفاده کنید مگر اینکه شما مجوزهای این شرکت ها را بدست آورید.
(مورد استثناء «کاربرد آزمایشی» قانونی پروانه ساخت به مردم امکان می دهد تا یک شیوه قابل ثبت را در متن تحقیقات علمی آزمایش کنند، اما هیچ کاربرد شخصی تجاری یا روال (زیربرنامه)، قانون شکنی نیست.) من پیشنهاد کردم که مردم از برنامه نویسی محاسباتی JPEG استفاده نکنند، ذخیره سازی های فضایی آنقدر زیاد نیست که مجادلات بالقوه قانونی را توجیه کند.
بخصوص برنامه نویسی محاسباتی نباید بر روی تصاویری که بر روی اینترنت تبدیل شده اند، استفاده شود.
حتی اگر شما قانون روانه ساخت US را مراعات نکنید دیگر گروه ها آنرا انجام می دهند.
یک FPU می تواند JPEG را تسریع کند؟
یک تراشه DSP چطور؟
از آنجایی که JPEG بطور فزونگری محاسبه می شود، خیلی از مردم پیشنهاد می کنند که از تراشه FDU که آنرا تسریع می کند استفاده کنند.
بیشترین برنامه های JPEG با کیفیت تولید فقط از حساب عدد صحیح استفاده می کنند و بنابراین آنها توسط حضور یا غیاب سخت افزار ممیز شناور تحت تأثیر قرار نمی گیرند.
ذخیره سازی چند عملیات ریاضی با انجام دادن مرحله DeT در ممیز شناور، ممکن می باشد.
بر روی بیشترین ماشین های نوع PC ، عملیات FP کُندتر از عملیات صحیحی می باشد که بطور کلی سرعت همیشه همراه با FP خیلی بدتر می باشد.
بعضی جایگاه های کاری با قیمت بالا و کامپیوترهای عظیم سخت افزار JFP سرعت کاخی دارند تا یک شیوه FPDCT بسازند.
تراشه های DSP (پردازش دیجیتالی سیگنال) بطور مطلوبی با حساب سریع عدد صحیح تکراری هماهنگ می شود، بنابراین برنامه ریزی یکDSP برای انجام JPEG می تواند موجب سرعتهای قابل توجهی شود.
DSPs بعنوان افزایش دهنده ها برای تعدادی PCs و جایگاه های کاری قابل دسترس می باشد.
اگر شما چنین سخت افزاری دارید، یک برنامه JPEG راکد می تواند از آن بهره برداری کند، جستجو کنید.
برای تصاویر حرکتی، استاندارد M - JPEG وجود ندارد؟
همانطور که در بخش 1 ذکر شده، JPEG فقط برای تصاویر بی حرکت می باشد.
با این وجود شما غالباً مرجع هایی با JPEG حرکتی یا M – JPEG برای ویدئو می بینید.
«هیچ استانداردی وجود ندارد.» عرضه کننده های مختلف JPEG را با چهارچوب های انفرادی از یک رشته ویدئویی (تصویری) بکار می برند و این نتیجه M – JPEG نامیده شده است.
متأسفانه در غیاب هر استاندارد شناسایی شده، آنها بطور متفاوتی عمل کرده اند.
نتیجه فایل ها معمولاً با عرضه کننده های مختلف سازگار نمی باشند.
MPEG ، استاندارد شناسایی شده برای فشرده سازی تصویر حرکتی می باشد.
آن از تکنیک های مشابه زیادی همانند JPEG استفاده می کند.
از سوی دیگر به فشرده سازی بین چهارچوبی برای بهره برداری از شباهت هایی که معمولاً بین چهارچوب های متوالی وجود دارد، اضافه می شود.
به همین دلیل، MPEG معمولاً یک رشته ویدئویی را بوسیله ورود یک عامل از سه مورد، بیشتر از شیوه های M - JPEG فشرده می سازد.
نقطه ضعفهای MPEG عبارتند از: 1ـ آن برای تولید رشته فشرده شده به محاسبات بیشتری نیاز دارد (زیرا شناسایی شباهت های تصویری برای یک کامپیوتر سخت می باشد) 2ـ ویرایش یک رشته MPEG بر روی یک پایه چهارچوب به چهارچوب مشکل می باشد.
(زیرا هر چهارچوب به یکی از آنهای اطراف پایه بسته می شود.) مشکل دوم نسبت به مورد رایج برای فرآورده های ویرایش ویدئویی (تصویری) شیوه های M - JPEG ساخته است.
باعث شرم است که هیچ استاندارد تصدیق شده M - JPEG وجود ندارد.
بنابراین اگر شما یک فرآورده شناسایی شده همانند M-JPEG بخرید، مواظب باشید که احتمالاً خودتان را محدود می کنید همانطور که یک فروشنده این کار را می کند.
اخیراً اَبِل و مایکر و ساخت شروع به فشار دادن قالب های JPEG کرده اند.
آنچه که باقی می ماند مورد بررسی قرار می گیرد که آیا این تلاشها تأثیر زیادی بر روی آشفتگی دارد یا نه.
هر دو شرکت بطور چشمگیری در جذب افراد برای تصویب عقایدشان در مورد قالب های فایل JPEG دارای تصویر ثابت موفق بودند، بنابراین من فرض نمی کنم که در این زمان چیز خوبی اتفاق می افتد.
MPEG FAQ را برای اطلاعات بیشتر در مورد MPEG ببینید.
چه می شود اگر من بیشتر از دقت 8 بیتی نیاز داشته باشم؟
JPEG خط مبنا تصاویر 8 بیتی را به ازای هر نمونه رنگی ذخیره می کند.
در دیگر لغات 24 بیتی به ازای هر سلول تصویری برای تصاویرRGB ، 8 بیتی / سلول تصویری برای مقیاس سایه زنی (خاکستری)، 32 بیتی / سلول تصویری برایCMYK ذخیره می گردد.
پسوندی وجود دارد که 12 بیت/ نمونه ها را برای کاربردهایی که به دقت بالاتری نیاز دارند، ذخیره می کند.
برای مثال تصاویر پزشکی، اغلب میزان سایه زنی 12 بیتی می باشند.
با این وجود پسوند 12 بیتی خیلی بطور گسترده ای پشتیبانی نمی شود.
یک بسته که پشتیبانی نمی شود.
آن که مبنای آزاد Jje می باشد.
برای JPEG بدون اتلاف، این استاندارد هیچ داده دقیقی بین بیت های 2 و 16 به ازای هر نمونه نمی پذیرد.
اما JPEG بدون اتلاف بسیار دقیق نسبت به JPEG پراتلاف بسیار دقیق بطور خیلی وسیعی پشتیبانی نمی شود.
از قرار معلوم کودک DVRG استاندفورد با بیشتر از 16 بیت/ نمونه برای JPEG بدون اتلاف پشتیبانی می شود.
برنامه من چگونه می تواند اندازه های تصویر را از فایل JPEG استخراج کنم؟
عنوان فایل JPEG شامل یک سری بلوک ها می باشد، که نشانگر نامیده می شود.
ارتفاع و عرض تصویر در یک نشانگر نوع SOSF ذخیره می گردد (آغاز قالب، نوع N).
برای پیدا کردن SOFn باید نشانگرهای قبلی را مرور کنید، شما نمی دانید چه چیزی در انواع دیگر نشانگرهای وجود دارد.
فقط از طول کلمات برای مرور دوباره آنها استفاده کنید.
حداقل منطق موردنیاز احتمالاً یک صفحه از کُد C می باشد (به بعضی افراد توصیه شده که فقط جفت بابت نشان دهنده SOFn را بدون توجه به ساختار بلوک نشانگر بررسی کنند).
این خطرناک می باشد زیرا نشانگر قبلی ممکن است شامل الگوی SOFn باشد، یا اتفاقی باشد زیرا شامل یک تصویر کوچک شده JPEG فشرده شده باشد.
اگر شما ساختار نشانگر را دنبال نکنید، اندازه تصویر کوچک شده را در عوض اندازه تصویر اصلی بازیابی می کنید.
یک نمونه بیش از حد توضیح داده شده در C می تواند در rdjpg com در توزیع JJG یافت.
(بخش 2 را ببینید).
کُد زبان پرل را می توان در www از http:// www.tardis.ed.ac.uk/ark/www is یافت.
JPEG چیست؟
JPEG که (جی ـ پک تلفظ می شود.) یک مکانیزم استاندارد، مقایسه تصاویراست .
JPEG مخفف شده گروه الحاقی کارشناس وگرافیکی است.
نام اصلی کمیته ای است که استاندارد رامی نویسد JPEG برای مقایسه تصاویرتمام رنگی یابیرنگ طبیعی یامناظرواقعی جهان، اختصاص یافته است.
این برنامه ، به خوبی برای عکاسی، کارهای هنری طبیعی وموارد مشابه کارمی کند .
ولی برای نامه نگاری کارتون های ساده یا ترسم های چندان خوب نیست .
JPEG هنوزهم فقط برای تصاویربه کارمی رود ولی یک استاندارد مربوطه وجود دارد که MPEG است و برای حرکت تصاویرخواهد بود.
JPEG « lossy یا ضرری» است به این معنی که: تصویر غیرفشرده کاملاً شبثیه آن چیزی که شما ثبت کرده اید، نیست.
(الگوریتم های فشرده ولی ضرر تصاویر وجود دارد ولی JPEG به فشردگی بیشتری دست یافته که این فشردگی با روشهای بی ضرری امکان پذیر است.) JPEG به کشف محدودیتهای مشخص چشم انسان اختصاص یافته و این حقیقت را ابزار می کند که تغییرات اندک رنگ، با دقت کمتری نسبت به تغییرات اندک در درخشش و شفافیت، مشاهده می شود.
بنابراین JPEG متمایل به فشردگی تصاویر است که توسط انسانها دیده می شود.
اگر شما طرحی برای آنالیز ماشینی تصاویر خود دارد، خطاهای کوچکی به وسیله JPEG ارائه می شود که ممکن است برای شما یک مشکل باشد.
حتی اگر آنها با چشم، غیرقابل مشاهده باشند.
یک خصوصیت مفید JPEG این است که درجه ضرر و گیج کنندگی یا lossy می تواند با تنظیم پارامترهای فشردگی، تغییر کند.
به این معنی که، تصویرسازی می تواند اندازه فایل را در مقابل کیفیت تصویر خروجی trade off کند.
اگر کیفیت نامرغوبی نداشتید، می توانید فایلهای کوچک «اضافی» بسازید.
این برای کاربردهایی نظیر فهرست بندی بایگانی تصویر مفید است.
برعکس آن، اگر شما از کیفیت خروجی در وضعیت فشردگی راضی نیستید می توانید تا زمانیکه راضی شوید، این کیفیت را بالا ببرید و فشردگی کمتری را انتخاب کنید.
جنبه مهم دیگر JPEG این است که رمزگشاها می توانند سرعت رمزگشایی در مقابل کیفیت تصاویر را افزایش دهند که این کار با استفاده سریع اما با تقریب نادرست، برای محاسبات موردنیاز، انجام می شود.
بعضی از بیننده ها در این روش سرعت قابل توجهی بدست می آورند.
(همچنین رمزگشاها می توانند، برای سرعت، درستی و دقت بیشتری به کار ببرند، ولی معمولاً هنگام نوشتن یک فایل دلیل کمتری برای چنین فداکاری وجود دارد.) چرا از JPEG استفاده می شود؟
دو دلیل خوب وجود دارد.
برای کوچکتر کردن فایلهای تصویری و ذخیره 24 بایت/ پیکسل اطلاعات رنگی به جای 8 بایت / پیکسل است.
کوچکتر کردن فایلهای تصویری یک پیروزی برای انتقال در طول شبکه و دستیابی به کتابخانه تصاویر است.
باید گفت: توانایی در فشردن فایل 2 مگابایت تمام رنگی به 100 کیلوبایت تفاوت بزرگی در فضای دیسک و زمان انتقال به وجود می آورد و JPEG می تواند به راحتی فشردگی 20:1 اطلاعات تمام رنگی را فراهم کند.
اگر شما GIF و JPEG را مقایسه کنید، نسبت این اندازه معمولاً شبیه 1=4 است (قسمت 4: چقدر JPEG می تواند تصاویر را به خوبی فشرده کند را ملاحظه کنید.) هم اکنون، رمزگشایی و نگاه به تصاویر JPEG نسبت به منظره تصاویری با ساختار ساده تر، نظیر GIF ، زمان کمتری طول می کشد.
بنابراین استفاده از JPEG یک معامله زمان / فضای ضروری است.
شما به منظور ذخیره یا انتقال یک تصویری، کم ارزش تر، زمان را کوتاه می کنید.
ولی ارزش آن را زمانی درمی یابید که انتقال در شبکه مبهم و پیچیده باشد.
ذخیره زمانی، در انتقال یک فایل کوتاهتر می تواند بیشتر از زمان موردنیاز برای فشردن این فایل باشد.
دومین مزیت اصلی JPEG این است که اطلاعات تمام رنگی را ذخیره می کند.
24 بایت / پیکسل (16 میلیون رنگ).
GIF ساختار تصویری دیگری که در شبکه بسیار استفاده می شود، فقط می تواند 8 بایت / پیکسل ذخیره کند (25 رنگ یا کمتر).
GIF از نظر استدلالی با نمایشگرهای گرانقیمت کامپیوتر به خوبی جور شده است.
اغلب کامپیوترهای معمولی خانگی نمی توانند بیش از 265 رنگ مجزا را یکباره نشان دهند.
ولی سخت افزارهای تمام رنگی اغلب اوقات ارزان تر بدست می آیند و تصاویر JPEG نسبت به تصاویر GIF در همان سخت افزار، بسیار بهتر نشان داده می شوند.
احتمالاً در طول 2 سال، GIF ، کاملترین ساختار تصویری Mac ، سیاه و سفید تا امروز بوده است.
علاوه بر این JPEG برای مبادله تصاویر در میان افراد که دارای سخت افزار نمایش دهنده گوناگون هستند، بسیار مفیدتر بوده است.
زیرا این سخت افزار از پیش داوری درباره اینکه، چه تعداد رنگ استفاده شود، جلوگیری می کند (فصل 8، کیفیت دهی رنگ کدام است را ملاحظه کنید.) به راستی JPEG برای کاربرد به عنوان یک شبکه کاربری و ساختار استاندارد تصاویر «گسترده وب جهانی» بسیار مناسب تر از GIF است.
بسیاری از مردم از بخش «فشردگی lossy »، ترس دارند ولی وقتی این بخش برای نشان دادن مناظر دنیای واقعی به کار می رود «هیچ» ساختار تصویری دیجیتال نمی تواند تمام اطلاعاتی را که به مردمک چشم شما هجوم می آورند، حفظ کنند.
با مقایسه تصاویر با دنیای واقعی.
JPEG اطلاعات بسیار کمتری را از دست می دهد تا GIF .
ضرر اصلی «فشردگی lossy» این است که اگر شما مکرراً تصویر را فشرده کرده و از حالت فشردگی خارج کنید هر بار مقدار زیادی از کیفیت خود را از دست می دهد.
(قسمت 10، آیا با جمع شدن مکرر فشردگی / غیرفشردگی، ضرری به وجود می آید را ملاحظه کنید.) مخالفتهای زیادی برای بعضی از کاربردها وجود دارد ولی برای بسیاری دیگر ایرادی وجود ندارد.