Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

JPEG image compression FAQ, part 1/2
Section - [15] How do I recognize which file format I have, and what do I do about it?

( Part1 - Part2 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Counties ]

Top Document: JPEG image compression FAQ, part 1/2
Previous Document: [14] Why all the argument about file formats?
Next Document: [16] What other common compatibility problems are there?
See reader questions & answers on this topic! - Help others by sharing your knowledge

If you have an alleged JPEG file that your software won't read, it's likely
to be some proprietary JPEG-based format.  You can tell what you have by
inspecting the first few bytes of the file:

1.  A JFIF-standard file will start with the four bytes (hex) FF D8 FF E0,
    followed by two variable bytes (often hex 00 10), followed by 'JFIF'.

2.  If you see FF D8 FF at the start, but not the 'JFIF' marker, you
    probably have a not-quite-JFIF JPEG file.  Most JFIF software should
    read it without complaint.  If you are using something that is picky
    enough to complain about the lack of a JFIF marker, try another decoder.
    (Both very old JPEG files and very new ones may lack JFIF markers ---
    the new SPIFF standard mentioned above doesn't use a JFIF marker.
    So gripe to your software vendor if you find this to be the problem.)

3.  A Macintosh PICT file, if JPEG-compressed, will have several hundred
    bytes of header (often 726 bytes, but not always) followed by JPEG data.
    Look for the 3-byte sequence (hex) FF D8 FF.  The text 'Photo - JPEG'
    will usually appear shortly before this header, and 'AppleMark' or
    'JFIF' will usually appear shortly after it.  Strip off everything
    before the FF D8 FF and you will usually be able to decode the file.
    (This will fail if the PICT image is divided into multiple "bands";
    fortunately banded PICTs aren't very common.  A banded PICT contains
    multiple JPEG datastreams whose heights add up to the total image
    height.  These need to be stitched back together into one image.
    Bailey Brown has some simple tools for this purpose on a Web page at

4.  If the file came from a Macintosh, it could also be a standard JFIF
    file with a MacBinary header attached.  In this case, the JFIF header
    will appear 128 bytes into the file.  Get rid of the first 128 bytes
    and you're set.

5.  Anything else: it's a proprietary format, or not JPEG at all.  If you
    are lucky, the file may consist of a header and a raw JPEG data stream.
    If you can identify the start of the JPEG data stream (look for FF D8),
    try stripping off everything before that.

At least one release of HiJaak Pro writes JFIF files that claim to be
revision 2.01.  There is no such spec; the latest JFIF revision is 1.02.
It looks like HiJaak got the high and low bytes backwards.  Unfortunately,
most JFIF readers will give up on encountering these files, because the JFIF
spec defines a major version number change to mean an incompatible format
change.  If there ever *were* a version 2.01, it would be so numbered
because current software could not read it and should not try.  (One wonders
if HiJaak has ever heard of cross-testing with other people's software.)
If you run into one of these misnumbered files, you can fix it with a
binary-file editor, by changing the twelfth byte of the file from 2 to 1.

User Contributions:

Report this comment as inappropriate
Nov 11, 2018 @ 11:11 am
Artikel ini menjawab Pertanyaan yang Sering Diajukan tentang kompresi gambar JPEG.
Ini adalah bagian 1, yang meliputi pertanyaan umum dan jawaban tentang JPEG. Bagian 2
memberikan petunjuk khusus sistem dan rekomendasi program. Seperti biasa,
saran untuk peningkatan FAQ ini disambut baik.

Baru sejak versi 14 Maret 1999:
* Memperluas item 10 untuk mendiskusikan rotasi tanpa loss dan pemangkasan JPEG.

Artikel ini mencakup bagian-bagian berikut:

Pertanyaan dasar:

[1] Apa itu JPEG?
[2] Mengapa menggunakan JPEG?
[3] Kapan saya harus menggunakan JPEG, dan kapan saya harus tetap menggunakan GIF?
[4] Seberapa baik gambar kompresi JPEG?
[5] Pengaturan "kualitas" apa yang bagus untuk JPEG?
[6] Di mana saya bisa mendapatkan perangkat lunak JPEG?
[7] Bagaimana cara melihat gambar JPEG yang diposkan di Usenet?

Pertanyaan lanjutan lainnya:

[8] Apa itu kuantisasi warna?
[9] Apa beberapa aturan praktis untuk mengkonversi gambar GIF ke JPEG?
[10] Apakah kehilangan terakumulasi dengan kompresi / dekompresi berulang?
[11] Apa itu JPEG progresif?
[12] Dapatkah saya membuat JPEG transparan?
[13] Apakah tidak ada JPEG lossless?
[14] Mengapa semua argumen tentang format file?
[15] Bagaimana saya mengenali format file yang saya miliki, dan apa yang harus saya lakukan?
[16] Masalah kompatibilitas umum apa saja yang ada di sana?
[17] Bagaimana cara kerja JPEG?
[18] Bagaimana dengan pengkodean aritmatika?
[19] Mungkinkah FPU mempercepat JPEG? Bagaimana dengan chip DSP?
[20] Apakah tidak ada standar M-JPEG untuk film?
[21] Bagaimana jika saya membutuhkan lebih dari 8-bit presisi?
[22] Bagaimana program saya mengekstrak dimensi gambar dari file JPEG?


[23] Di mana saya bisa belajar tentang menggunakan gambar di World Wide Web?
[24] Di mana daftar FAQ diarsipkan?

Artikel ini dan rekannya diposting setiap 2 minggu. Jika Anda tidak dapat menemukannya
Bagian 2, Anda bisa mendapatkannya dari arsip di
(lihat "[24] Di mana daftar FAQ diarsipkan?"). Bagian 2 sangat sering berubah;
dapatkan salinan baru jika yang Anda baca berusia lebih dari beberapa bulan.

Comment about this article, ask questions, or add new information about this topic:


Top Document: JPEG image compression FAQ, part 1/2
Previous Document: [14] Why all the argument about file formats?
Next Document: [16] What other common compatibility problems are there?

Part1 - Part2 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:

Last Update March 27 2014 @ 02:11 PM