libexif-devel

[Libexif-devel] file size decreases after exif --set-value?

[Gerald O. <ge...@im...>]

Hi,

Thanks for writing libexif, gexif, exif, etc; fantastic stuff!

I am trying to use 'exif' to reset the orientation value in a jpeg
file after rotating it with jpegtran, and it seems to work well
but the file size decreases by 400 bytes during the exif step.

    $ exif --ifd=0 -tag=0x0112 --set-value=1 11-23-06.jpg 
    Wrote file '11-23-06.jpg.modified.jpeg'.

    $ ls -l 11-23-06*
    -rw-r--r--    1 gerald   1249462 Jul 10 18:27 11-23-06.jpg
    -rw-r--r--    1 gerald   1249066 Jul 10 18:28 11-23-06.jpg.modified.jpeg

This makes me a little nervous because I don't know what was lost.
It may be that libexif's canonical exif output is just a bit less
verbose than that used by Canon, but it would be nice to know I'm
not losing anything important.

I checked for a few obvious things that might have gone missing
(exif data, image thumbnail), but they're still there.

my test file came from a Canon G2:
http://impressive.net/people/gerald/2002/09/29/11-23-06.jpg

and I am using the latest released exif (0.6) and related libraries.

Does anyone know what those ~400 bytes might be?

Thanks,

-- 
Gerald Oskoboiny <ge...@im...>
http://impressive.net/people/gerald/

Re: [Libexif-devel] file size decreases after exif --set-value?

[Lutz <lu...@us...>]

On Fri, 2003-07-11 at 01:15, Gerald Oskoboiny wrote:
> Hi,
>=20
> Thanks for writing libexif, gexif, exif, etc; fantastic stuff!
>=20
> I am trying to use 'exif' to reset the orientation value in a jpeg
> file after rotating it with jpegtran, and it seems to work well
> but the file size decreases by 400 bytes during the exif step.

libexif constructs EXIF data from scratch, without any unnecessary
padding. Read the EXIF spec: The pointers to the EXIF data items are
stored in one block, and the data items itself somewhere after the
block. But the data items don't need to start right after the block of
pointers, nor do they need to be packed one after another. =20

This could be the 400 bytes. But it would still be interesting what is
hidden in the 400 bytes...

Regards
--=20
Lutz M=FCller <lu...@us...>