JPEG profiles

[Boo_Radley]

Is there anyone here who's a technical guru? I'm curious about JPEG profile information, what's in it, what's worth keeping.

My website was tragically slow. While some of that can be laid on my lack of bandwidth (I did double that), I also noticed that my thumbnails were 40 to 50 K each, which is pretty big for a thumbnail. I looked into it, and decided to try using imagemagick to reduce them, since I was getting nowhere with PhotoShop. I ran the following command on the whole directory (it's unix stuff)

$ for foo in $(ls); do convert -strip $foo $foo; done

That ran the convert program with the strip option on each thumbnail image. That strips "profile information and comments" from them. THey went from between 40 and 50 K per thumbnail to about 5 to 10 K per thumbnail, and look the same. Compared to the way it loaded before, it's lighting fast now. Does anyone know what all that extra information is, what it's good for, why it's there, if it should be kept?

I'm kind of pissed that I let so many people view my site when it was slow as malaria when there was no need for it to be.

[ET Awful]

1. If you're referring to the EXIF information, it has a lot of useful info.

This would include, camera used, focal length, f-stop, shutter speed, for many cameras it includes the total number of shutter releases for the camera, etc.

Of course that only applies to photos shot digitally to begin with.

[GOPFighter]

2. I'm not familiar with unix commands so...

...could you explain what your command is supposed to do? I've never looked at a jpeg file with a text editor. Is there an obvious beginning and end to the image itself? If so, did you strip everything else away using the command? Probably not because there must be some descriptive information a graphics viewer needs that process the image. If your command stripped away only the EXIF file, I'm not surprised the files are 35 to 40 K smaller, but I'm surprised it affected the time it takes for the image to appear. One would think that the EXIF portion of the file would follow the image bits, so the image would appear quickly and the EXIF files would load after the image appeared.

If I'm rambling, it's because I haven't had my coffee yet! x(

[Boo_Radley]

3. I think I got an answer

The unix command is actually extraneous information. I put it in there incase anyone uses unix and wanted the information.

This is what I was told.

Don't quote me on this, but I think it has to do with different operating systems and monitors and whatnot displaying the same RGB hex color differently. Extra information about the device that created the image is needed to reproduce the colors correctly on other machines.

Quote:

For the purposes of this paper, the most important thing to remember about the GIF format is that all the pixels in images are described as red, green, and blue values. This is called an RGB color space. However, the meanings of "red," "green," and "blue" are not well defined. Most software treats it as the RGB space of the display monitor. This may or may not resemble the RGB space of the monitor on which the image was created, depending on the color characteristics of the phosphors on the two different monitors. Often images are acquired on desktop scanners. While these are RGB devices, the spectral response of the red, green, and blue primaries, the white point, and the tone response curves are often very different from that of a computer monitor. Whatever the source of the image, any resemblance between the display device's color space and the source's is purely fortuitous.

(from http://www.color.org/wpaper2.html)

From the same site:

Quote:

An ICC device profile can be as small as 500 bytes for a minimal monitor profile. But it is not uncommon for the profile for a scanner to exceed 20000 bytes. While this is only 2 percent of a one megabyte file, which is not uncommon on Unix workstations, and still only 6 percent of a 640 by 480 full screen PC file, it could be a significant factor in small image files.

If they are only thumbnails, it probably isn't that important to keep that data. Worst case, the color in the thumbnails is slightly off on other people's computers, while the full images are still fine.

It seems there's a lot of extera information in JPEGS. They might be useful for a full sized image, but for a thumbnail, they're just extera data that does no real good. And if you have a lot of thumbs, it adds up.

I also found out that you can do more-or-less the same thing in Photo Shop if you use the "save for web" option, instead of "save as" or "save", but it's kind of a pain in the butt, and it produces a somewhat larger file.

[priller]

4. Oh, you're talking about the color profile, not EXIF

I think the regular Photoshop save also has the option to "Embed Adobe RGB color profile" or something like that. You can turn off that option, it will do the same thing.

[GOPFighter]

5. I think I understand now

...and I can see why that kind of information would be a lot of overhead for a thumbnail. I'm getting the unsettled feeling that digital photography and it's graphic formats are a lot more complicated that I thought.

[Boo_Radley]

6. Also

I think there are also thumbnails embedded in some JPEGs, depending on the software/device that created the JPEG. Having a thumbnail embedded in a thumbnail is kind of silly. So there's the color profile, possibly a thumbnail, and also the EXIF info, all packed in there. If you're talking about a 200k file, it's not going to be a significant difference, but for a thumbnail, the extera info seems to be bigger than the actual thumbnail, itself. In my case, it looks like it was several times bigger on the disk.

[TahitiNut]

7. Understanding begins with rigorous use of terminology.

(I apologize if this post is obscure. It's more of a "meta-answer" than an answer.)

The term 'JPEG' (Joint Photographic Experts Group) refers to the 'lossy' algorithm with which the image is compressed. Embedding this data within a file, one must consider whether it's a JFIF (JPEG File Interchange Format) or SPIFF (Still Picture Interchange File Format) formatted file, where SPIFF is an extension of JFIF.

What we're dealing with here is data, file formats, and software ... NOT photography.

TASI has a decent summary-level tutorial at http://www.tasi.ac.uk/advice/creating/fformat.html

An off-the-cuff description of the layout of a JFIF or SPIFF file is beyond my expertise. As a (former?) software engineer, I always rely on published standards and specifications for such technical issues, and even for those I've worked with, I'd be incapable of describing them without making use of the reference resources. (The web isn't really enough for this.) I always relied on reference resources (IEEE, ANSI, ISO, etc.). The standards and specification for JFIF and SPIFF would fall under the category of "Data Interchange Standards", the text of which typically employs "C" language snippets to describe data layout. Relevant standards for this would include "ISO/IEC 10918-4:1999---Joint Photographic Experts Group (JPEG)".

I again apologize for the 'smoke'n'mirrors' language, but if I were even beginning to work with such file formats, I'd be assembling a virtual bookshelf of relevant texts. I can easily imagine the minimum number of 500-page texts needed to work with just the 'JPEG' formats to be around 8-10, dense with code snippets and block diagrams.

[RagingInMiami]

8. This reminds me of today's Doonesbury comic

TH, you are "the professor" of the Photo Group.

[GOPFighter]

9. 10-4

I've been involved with desigining a portion of an international data transfer standard (hydrographic data) for about 5 years. I would hate to have to describe the standard at this point to a non-hydrographer. However, like jpeg our standard has become more than a data transfer standard it has become the favored format for storing and manipulating data. So while jpeg isn't about photography, per se, any serious photographer who wants to use a common format (a data transfer standard) to display their digital images on a monitor, or print them, should have a working knowledge of the color profiles that can be imbedded in a graphic format to be used to adjust the receiving monitor or printer to fit the profile the photographer used when taking or adjusting the picture. I find this both exciting and intimidating.

Just as an aside, I wonder how much variation there is in DUer's monitors when they view our contest pictures. The photo submitted might have a brilliant yellows in the photo which might show up on my monitor as slightly orange or green.

[TahitiNut]

10. The whole area of color matching is beyond me, I'm afraid.

As anyone who's looked at an array of televisions in a store can attest, the variances between each if only due to differences in adjustments/settings, let alone brand/technology details is far more than the subtleties we (at least I) sometimes nit-pick. When it comes to then "matching" that emission spectrum to an adsorption spectrum on a printed surface which has even greater variance, it just plain hurts my brain. I think its impressive that the normal variances I notice have gotten quite a bit narrower over the years despite the explosion in such devices. (It really used to be a lot more of a crap shoot, I think.)

[Boo_Radley]

11. Thanks for the info

I'm strill trying to find out what's stored in the extera data, though. In another thread, people were asking about EXIF information gathering, and I found a cool command line utility called jhead if anyone's interested in that. Also, a reference for EXIF info from different camera makers, if anyone is going to write their own (which I did before I saw that jhead thing).

I htink I have a better understanding of the metadata in the JPEG format, though. And, for thumbnails, it seems like stripping the embedded thumbnail and the color profile is a smart move.