FROM : Heinrich Giesen
DATE : Tue Jun 03 23:11:08 2008
On 03.06.2008, at 21:00, Randall Meadows wrote:
>
>
>> I'm about to resort to using a third-part solution (jpegtran and
>> jpegexiforient) that I've found, but
>>
>
> Except that I'm not going to be able to use jpegexiforient, because
> the image file apparently isn't in the correct form it wants. This
> test fails:
>
> /* Read File head, check for JPEG SOI + Exif APP1 */
> for (i = 0; i < 4; i++)
> exif_data[i] = (unsigned char) read_1_byte();
> if (exif_data[0] != 0xFF ||
> exif_data[1] != 0xD8 ||
> exif_data[2] != 0xFF ||
> exif_data[3] != 0xE1)
> return 0;
>
> since the 4th byte (exif_data[3]) is 0xE0. I don't really know what
> that means, other than I guess I'm back to square one trying to rotate
> an image, and update and preserve all the meta-data.
That means that jpegexiforient expects an APP1 marker (Exif marker) as
first jpg marker behind the SOI (0xffd8) marker. But this is not
always the case.
Very often jpg data start with an APP0 (JFIF or JFXX) marker or they
may have none
of them. Some start with an APP0 marker followed by an APP1 (Exif)
marker, which is
not allowed, but who cares; Adobe doesn't care and writes both
markers in the
same file.
Bill Bumgarner wrote:
> According to...
>
> http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
>
> ... the fourth byte should be 0xE0 in a JPEG. A bit of googling
> reveals that the first four bytes might be either FFD8FFE0 or
> FFD8FFE1.
>
Forget that link, it is a bad second hand literature. The given magic
number for
jpg file (and also that for PNG files) is wrong. According to the
original text
(starting at http://www.w3.org/Graphics/JPEG/ and
http://www.w3.org/Graphics/JPEG/itu-t81.pdf)
a jpg file is identified by the first 3 (three) digits 0xFFD8FF,
which means:
the data have to start with the SOI marker followed by the next
marker. Only these
three bytes make the magic number. There is no rule which marker has
to follow.
(I wrote my own jpg scanner and experienced a lot of surprices! )
> I'm about to resort to using a third-part solution
This is a good idea! My favourite program is exiftool by Phil Harvey:
http://www.sno.phy.queensu.ca/~phil/exiftool/
exiftool -Orientation=8 -n a.jpg
will do the job.
Good luck
Heinrich
--
Heinrich Giesen
<email_removed>
DATE : Tue Jun 03 23:11:08 2008
On 03.06.2008, at 21:00, Randall Meadows wrote:
>
>
>> I'm about to resort to using a third-part solution (jpegtran and
>> jpegexiforient) that I've found, but
>>
>
> Except that I'm not going to be able to use jpegexiforient, because
> the image file apparently isn't in the correct form it wants. This
> test fails:
>
> /* Read File head, check for JPEG SOI + Exif APP1 */
> for (i = 0; i < 4; i++)
> exif_data[i] = (unsigned char) read_1_byte();
> if (exif_data[0] != 0xFF ||
> exif_data[1] != 0xD8 ||
> exif_data[2] != 0xFF ||
> exif_data[3] != 0xE1)
> return 0;
>
> since the 4th byte (exif_data[3]) is 0xE0. I don't really know what
> that means, other than I guess I'm back to square one trying to rotate
> an image, and update and preserve all the meta-data.
That means that jpegexiforient expects an APP1 marker (Exif marker) as
first jpg marker behind the SOI (0xffd8) marker. But this is not
always the case.
Very often jpg data start with an APP0 (JFIF or JFXX) marker or they
may have none
of them. Some start with an APP0 marker followed by an APP1 (Exif)
marker, which is
not allowed, but who cares; Adobe doesn't care and writes both
markers in the
same file.
Bill Bumgarner wrote:
> According to...
>
> http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
>
> ... the fourth byte should be 0xE0 in a JPEG. A bit of googling
> reveals that the first four bytes might be either FFD8FFE0 or
> FFD8FFE1.
>
Forget that link, it is a bad second hand literature. The given magic
number for
jpg file (and also that for PNG files) is wrong. According to the
original text
(starting at http://www.w3.org/Graphics/JPEG/ and
http://www.w3.org/Graphics/JPEG/itu-t81.pdf)
a jpg file is identified by the first 3 (three) digits 0xFFD8FF,
which means:
the data have to start with the SOI marker followed by the next
marker. Only these
three bytes make the magic number. There is no rule which marker has
to follow.
(I wrote my own jpg scanner and experienced a lot of surprices! )
> I'm about to resort to using a third-part solution
This is a good idea! My favourite program is exiftool by Phil Harvey:
http://www.sno.phy.queensu.ca/~phil/exiftool/
exiftool -Orientation=8 -n a.jpg
will do the job.
Good luck
Heinrich
--
Heinrich Giesen
<email_removed>
| Related mails | Author | Date |
|---|---|---|
| Randall Meadows | Jun 3, 19:14 | |
| Randall Meadows | Jun 3, 20:03 | |
| Bill Bumgarner | Jun 3, 20:10 | |
| Heinrich Giesen | Jun 3, 23:11 | |
| Ken Thomases | Jun 4, 03:42 | |
| Ken Ferry | Jun 4, 05:53 | |
| Randall Meadows | Jun 5, 01:38 | |
| Ken Ferry | Jun 5, 20:33 |






Cocoa mail archive

