Talk:JPEG File Interchange Format

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Photography Low‑importance

	This article is within the scope of WikiProject Photography, a collaborative effort to improve the coverage of photography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.PhotographyWikipedia:WikiProject PhotographyTemplate:WikiProject PhotographyPhotography articles
Low	This article has been rated as Low-importance on the project's importance scale.

Describing the JFIF ID string

I changed the JFIF ID string from 'Always equals "JFIF\x00" (0x4A46494600)' to "JFIF (followed by a zero)", because that's what really appears. The \x0 prefix for a zero doesn't belong inside the quotes, if it's not really there in the ASCII. -SandyJax 20:26, 5 November 2007 (UTC)[reply]

JFIF vs. JPEG Interchange format - which one extends what?

The JPEG page states "The file format is known as 'JPEG Interchange Format', as specified in Annex B of the standard. This is often confused with the JPEG File Interchange Format (JFIF), a minimal version of the JPEG Interchange Format that was deliberately simplified so that it could be widely implemented and thus become the de-facto standard.", while the JFIF page states that JFIF is an extension of JPEG Interchange Format. So, what is it? Stolsvik (talk) 14:25, 11 January 2008 (UTC)[reply]

Depends on how you look at it. JFIF excludes certain options allowed in the formal JPEG standard (such as lossless JPEG, CMYK JPEG, etc.), but also packages JPEG data into a concrete file format (something which was not done in the formal JPEG standard itself), and makes provision for the inclusion of certain types of metadata (including a thumbnail)... AnonMoos (talk) 14:35, 11 January 2008 (UTC)[reply]

I regard the JPEG page to be correct. I tried to fix this page, using similar wording the the JFIF standard document. Stolsvik (talk) 15:13, 11 January 2008 (UTC)[reply]

The phrase 'minimal format for exchanging JPEG files' is not accurate - Firstly many programs will happily read a JIF file which has no JFIF segment whatsoever - Secondly JFIF is not a complete format for exchanging JPEG files since it doesn't define an absolute colour space.

Perhaps we could say that JFIF both extends and restricts the JPEG standard - It restricts use of things like CMYK and lossless images, but extends the standard by providing definitiions of relative color space, resolution/aspect ratio and component sample registration. --Ozhiker (talk) 15:55, 11 January 2008 (UTC)[reply]

You're right in saying that a JFIF file can have the JFIF (APP0) segment removed and still be readable by many programs. However, that's actually a shortcoming of those programs. Technically, a file without a JFIF segment should NOT be assumed to be in JFIF format. This will become apparent if you try giving a JPEG file in CMYK color format to that same image viewer. If the viewer doesn't find a JFIF segment and makes the assumption that the data is nonetheless in JFIF format (whose color format is YCbCr), it will almost certainly fail to display that image (whose color format is CMYK).

It's also not safe to assume that simply because a JFIF file without a JFIF segment works today that it will continue to work in future. If, at some stage, those badly written programs are re-written to correctly check for the presence of a JFIF segment, then those images without a JFIF segment will no longer display correctly.

In a similar vein, a JFIF file does not necessarily need to finish with an EOI marker, as almost all programs will still consider the image to be complete without it. Nonetheless, it's simply good practice to include it and thus correctly terminate the file. Ian Fieggen (talk) 00:37, 25 June 2008 (UTC)[reply]

Indeed, life with JPEG is messy. Last time I worked on this, I decided it was impossible to create a JPEG file that would conform to both JFIF and Exif standards. That meant that one could not have both an ICC color profile and Exif metadata. Yet, we routinely work with such files. It would be nice if one or more of these standards could be revised to make the files officially supported, but that doesn't look likely to happen. Dicklyon (talk) 01:27, 25 June 2008 (UTC)[reply]

File format structure

Following the provided link (JPEG File Interchange Format Specification v1.02), I'm not sure if APP0 really includes 'FF', as document states: X’FF’, SOI, X’FF’, APP0 ...

--idleloop (talk) 10:14, 24 June 2008 (UTC)[reply]

Resolution is also found in JPEG bitstream

I think the statement "The JPEG standard does not include any method of coding the resolution" is inaccurate. The JPEG standard defines how resolution is encoded into the JPEG header on page 35-36 of the JPEG standard (follow link): http://www.w3.org/Graphics/JPEG/itu-t81.pdf

However, pixel density (e.g. pixels-per-inch), is not encoded in the JPEG bitstream. Janpeder (talk) 11:19, 11 August 2009 (UTC)[reply]

What does header with resolution and aspect ratio is good for?

What does header with resolution and aspect ratio is good for? —Preceding unsigned comment added by 217.132.29.42 (talk) 18:54, 12 May 2010 (UTC)[reply]

Image Resolution is used by publishing software to scale an image to an appropriate size when placing it on a page. For example, if a 600dpi image is placed into a document formatted for 300dpi, the image will be scaled to 50% smaller.

Aspect Ratio is useful if an image is from an older device that didn't have "square" pixels (1:1 ratio). For example, suppose I capture an image from an older computer with an EGA screen resolution of 640 x 350 pixels. The aspect ratio of those pixels is actually 480:350. If this image is diplayed on a newer screen with 1:1 ratio, the image will appear a little squashed vertically. However, if the displaying software knows the aspect ratio of the pixels in the image and is able to adjust for the aspect ratio of the display, the image will not look squashed. Ian Fieggen (talk) 00:55, 13 May 2010 (UTC)[reply]

FF E0

The article claims "The JFIF standard requires that the JFIF APP0 marker segment immediately follows the SOI marker" but this is not present in my Canon files and I've seen other files with it missing as well. It's not mandatory. Andrew (talk) 20:44, 17 June 2023 (UTC)[reply]

Apparently the JFIF specification conflicts with the later EXIF specification, which is probably the reason for what you've observed. I'm looking at the "JPEG File Interchange Format Version 1.02" and right on the first page after the title page it says: "The JPEG File Interchange Format is entirely compatible with the standard JPEG interchange format; the only additional requirement is the mandatory presence of the APP0 marker right after the SOI marker." So that was what was intended in 1992... AnonMoos (talk) 21:05, 19 June 2023 (UTC)[reply]

Basically, older (early 90s) cameras used JFIF, and by 1999 most were using EXIF instead; they're the same except for the marker with the metadata. Here's a 1999 doc that says "The marker 0xFFE0~0xFFEF is named "Application Marker", not necessary for decoding JPEG image. They are used by user application. For example, older olympus/canon/casio/agfa digicams use JFIF(JPEG File Interchange Format) for storing images. JFIF uses APP0(0xFFE0) Marker for inserting digicam configuration data and thumbnail image. Also Exif uses an Application Marker for inserting data, but Exif uses APP1(0xFFE1) Marker to avoid a conflict with JFIF format. Every Exif file formats starts from this format; ..." -- 22:06, 19 June 2023 Dicklyon