SDL_Image: IMG_isJPG() fails on pictures with IPTC information

SDL Development
1

I found that SDL_Image fails to load JPEG files to
which I have added a caption using Picasa (a free as
in beer picture organization tool;
http://www.picasa.com). Picasa claims to store its
captions in IPTC format. Photoshop apparently uses
this format too, but I don’t have that program so I
can’t verify that.

The problem is that the IPTC information block is
stored between the SOI (FF D8) and APP1 (FF E1)
markers in the JPEG file, so that the “JFIF” or "Exif"
constant is not stored at offset 6. Instead, the two
bytes at offset 2 store FF ED and the next two bytes
store the size of the block as a big endian word
(including the size field). The APP1 (FF E1) marker
will immediately follow.

A simple fix could be inserted just after the second
SDL_RWread() in IMG_isJPG(). Instead of throwing
these four bytes away, we can check for the IPTC
header and skip over it. The following code does the
trick for me.

IMG_jpg.c

49c49,52
< SDL_RWread(src, magic, 4, 1);—

  	SDL_RWread(src, magic, 4, 1);
  	if ( (magic[0] == 0xFF) && (magic[1] == 0xED) ) {
  		SDL_RWseek(src, (((Uint16)magic[2] << 8) |

magic[3]) + 2, SEEK_CUR);

  	}

Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

2

Here’s a proper unified diff from CVS for this patch.

— Jeremy Stanley <@Jeremy_Stanley> wrote:> I found that SDL_Image fails to load JPEG files to

which I have added a caption using Picasa (a free as
in beer picture organization tool;
http://www.picasa.com). Picasa claims to store its
captions in IPTC format. Photoshop apparently uses
this format too, but I don’t have that program so I
can’t verify that.

The problem is that the IPTC information block is
stored between the SOI (FF D8) and APP1 (FF E1)
markers in the JPEG file, so that the “JFIF” or
"Exif"
constant is not stored at offset 6. Instead, the
two
bytes at offset 2 store FF ED and the next two bytes
store the size of the block as a big endian word
(including the size field). The APP1 (FF E1) marker
will immediately follow.

A simple fix could be inserted just after the second
SDL_RWread() in IMG_isJPG(). Instead of throwing
these four bytes away, we can check for the IPTC
header and skip over it. The following code does
the
trick for me.

IMG_jpg.c

49c49,52
< SDL_RWread(src, magic, 4, 1);

  	SDL_RWread(src, magic, 4, 1);
  	if ( (magic[0] == 0xFF) && (magic[1] == 0xED) )

{

  		SDL_RWseek(src, (((Uint16)magic[2] << 8) |

magic[3]) + 2, SEEK_CUR);

  	}

Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.

http://promotions.yahoo.com/new_mail

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_image-IPTC-patch
Type: application/octet-stream
Size: 768 bytes
Desc: 117615756-SDL_image-IPTC-patch
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050816/d677d60f/attachment.obj