Talk:JPEG File Interchange Format

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Describing the JFIF ID string[edit]

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)

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

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)

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)
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)
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)
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)
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)

File format structure[edit]

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)

Resolution is also found in JPEG bitstream[edit]

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):

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

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

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

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)