libexif-devel — This is the place where your questions about libexif will be answered.

[Libexif-devel] Python binding and Watcom contribs

[Dan F. <da...@co...>]

There are two entries in the libexif/contribs directory: a Python wrapper
and a Watcom makefile. Both no longer work due to changes to libexif. 
Neither of them were in the 0.6.16 release, so I guess it's not a big deal
if they're not in the imminent release, but is someone willing to fix them
up for next time?

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Time for a libexif release

[Dan F. <da...@co...>]

On Tue, Nov 04, 2008 at 08:59:16PM +0100, Lutz Müller wrote:
> On Mon, 2008-11-03 at 14:48 -0800, Dan Fandrich wrote:
> > Much as I'd like to help, of the two of us, you're the only project
> > admin :->
> 
> No longer.

That's what you get when you open your mouth :-}

I think I can figure out what to do in SF, so I'll create some candidate
tar balls for libexif & exif shortly and let everybody here take a look
before making them official.  Since this is really just a point release,
I'll call it 0.6.17.

I haven't looked at libexif-gtk and gexif yet, but since they're not 
tied tightly to a new libexif release, I think they can wait until
afterward.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Time for a libexif release

[Marcus M. <ma...@je...>]

On Tue, Nov 04, 2008 at 05:29:31PM +0100, Marcus Meissner wrote:
> On Mon, Nov 03, 2008 at 07:20:57PM -0800, Dan Fandrich wrote:
> > On Mon, Nov 03, 2008 at 09:52:16PM +0100, Marcus Meissner wrote:
> > > Only if you changed an exported interface. I think there wasn't one.
> > 
> > That makes it much easier.  The "REVISION" field should be bumped, though.
> > 
> > > Sync from the translation project before releasing:
> > > 
> > > 	rsync -Lrtvz  translationproject.org::tp/latest/libexif/  po
> > 
> > I took a look at the translations and it looks like they're all up to date.
> > However, a number of the translations are not in sync with 
> > translationproject.org because they were edited in the libexif CVS!  This
> > is a big no-no now (as described in the README file).  Any local changes
> > will be overwritten the next time a Translation Project volunteer updates
> > a libexif translation.  All changes must now be made through TP, except for
> > the ru and en_CA domains, which are the only ones handled exclusively through
> > libexif's CVS.
> > 
> > These PO files all have local changes:
> > 
> > cs.po
> > de.po

I now submitted de.po to translation project. There were around 4 strings or
so changed judging from the diff I have.

> > es.po
> > fr.po
> > ru.po
> > sv.po

Ciao, Marcus

Re: [Libexif-devel] Time for a libexif release

[Marcus M. <ma...@je...>]

On Mon, Nov 03, 2008 at 07:20:57PM -0800, Dan Fandrich wrote:
> On Mon, Nov 03, 2008 at 09:52:16PM +0100, Marcus Meissner wrote:
> > Only if you changed an exported interface. I think there wasn't one.
> 
> That makes it much easier.  The "REVISION" field should be bumped, though.
> 
> > Sync from the translation project before releasing:
> > 
> > 	rsync -Lrtvz  translationproject.org::tp/latest/libexif/  po
> 
> I took a look at the translations and it looks like they're all up to date.
> However, a number of the translations are not in sync with 
> translationproject.org because they were edited in the libexif CVS!  This
> is a big no-no now (as described in the README file).  Any local changes
> will be overwritten the next time a Translation Project volunteer updates
> a libexif translation.  All changes must now be made through TP, except for
> the ru and en_CA domains, which are the only ones handled exclusively through
> libexif's CVS.
> 
> These PO files all have local changes:
> 
> cs.po
> de.po
> es.po
> fr.po
> ru.po
> sv.po

Ok, what I found out during libgphoto2 <-> translation project communication:

- NEVER EVER RUN "make update-po".
	(I think for local translations this can be done, but not for externals.)
- If you did "make dist", the POT file was regenerated and included into the
  tarball.
  You should commit the POT file at this time, but the update language.po files
  should probably be reverted.

- Once the translation project has synced the release:
	-> fetch the language.po files from the translation project
	-> commit them.

This way you will get only diffs from the translation project.

Local translated languages can of course run make update-po , but should just
commit their PO file, nothing else.

Ciao, Marcus

Re: [Libexif-devel] Time for a libexif release

[Stanislav B. <sb...@su...>]

Dan Fandrich wrote:
> It's been almost a year and a half since the last libexif release.  In that
> time there have been lots of bug fixes, more tag support, more translations
> added, some serious security fixes and even a showstopper bug that causes
> the GIMP to crash.  I can't think of any reason not to make a new release
> now.  The SONAME hasn't even been bumped (should it be?) so the new
> version should be a drop-in replacement for people.
> 
> Is there anything holding back a release now?

It would be nice to release libexif-gtk and gexif compatible with the
current version of libexif and gtk+. Patches are pending in the bug
tracker.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sb...@su...
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

Re: [Libexif-devel] Time for a libexif release

[Dan F. <da...@co...>]

On Mon, Nov 03, 2008 at 09:52:16PM +0100, Marcus Meissner wrote:
> Only if you changed an exported interface. I think there wasn't one.

That makes it much easier.  The "REVISION" field should be bumped, though.

> Sync from the translation project before releasing:
> 
> 	rsync -Lrtvz  translationproject.org::tp/latest/libexif/  po

I took a look at the translations and it looks like they're all up to date.
However, a number of the translations are not in sync with 
translationproject.org because they were edited in the libexif CVS!  This
is a big no-no now (as described in the README file).  Any local changes
will be overwritten the next time a Translation Project volunteer updates
a libexif translation.  All changes must now be made through TP, except for
the ru and en_CA domains, which are the only ones handled exclusively through
libexif's CVS.

These PO files all have local changes:

cs.po
de.po
es.po
fr.po
ru.po
sv.po

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Time for a libexif release

[Dan F. <da...@co...>]

On Mon, Nov 03, 2008 at 11:03:42PM +0100, Lutz Müller wrote:
> I know just one reason: We are missing someone to do it :-) Go ahead.

Much as I'd like to help, of the two of us, you're the only project
admin :->

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Time for a libexif release

[Marcus M. <ma...@je...>]

On Mon, Nov 03, 2008 at 12:10:40PM -0800, Dan Fandrich wrote:
> It's been almost a year and a half since the last libexif release.  In that
> time there have been lots of bug fixes, more tag support, more translations
> added, some serious security fixes and even a showstopper bug that causes
> the GIMP to crash.  I can't think of any reason not to make a new release
> now.  The SONAME hasn't even been bumped (should it be?) so the new
> version should be a drop-in replacement for people.

Only if you changed an exported interface. I think there wasn't one.
 
> Is there anything holding back a release now?

Sync from the translation project before releasing:

	rsync -Lrtvz  translationproject.org::tp/latest/libexif/  po

Ciao, Marcus

[Libexif-devel] Time for a libexif release

[Dan F. <da...@co...>]

It's been almost a year and a half since the last libexif release.  In that
time there have been lots of bug fixes, more tag support, more translations
added, some serious security fixes and even a showstopper bug that causes
the GIMP to crash.  I can't think of any reason not to make a new release
now.  The SONAME hasn't even been bumped (should it be?) so the new
version should be a drop-in replacement for people.

Is there anything holding back a release now?

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Marcus M. <ma...@je...>]

On Sun, Oct 05, 2008 at 09:54:30AM +0200, Jan Patera wrote:
> > On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote:
> >> Please find a patch attached to this mail that solves a couple of
> >> memory-corruption issues, and a couple of 64-bit mode options.
> >
> > Would you mind resending the patch in unified diff format (-u)?  It's
> > more reliable to apply and to review that way.
> >
> >>>> Dan
> 
> Dan, It has been resent and then applied by Marcus. I have done few changes
> since then. I don't know why, but I didn't receive any CVS
> mails for Marcus' and my changes. Did anybody receive them?

I got some python errors on commit. I think the CVS move might have broken
the mail script :/

Ciao, Marcus

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Jan P. <pa...@pi...>]

Niek,

> The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not
> using these, one gets offsets in the > 2^31 range at times.
...
> An additional set of changes within the maker-note files are to
> prevent crashing on sizes > 64kb; It seems that the maker-notes, at
> times, return sizes that are huge (as in: way beyond 2^31 bytes).

Doesn't sound possible, unless there is a bug somewhere or the JPEG
file is corrupted. Can you please send me some JPEG file where you
get sizes over 2^31? Thanks.

  -- Jan

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Jan P. <pa...@pi...>]

> On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote:
>> Please find a patch attached to this mail that solves a couple of
>> memory-corruption issues, and a couple of 64-bit mode options.
>
> Would you mind resending the patch in unified diff format (-u)?  It's
> more reliable to apply and to review that way.
>
>>>> Dan

Dan, It has been resent and then applied by Marcus. I have done few changes
since then. I don't know why, but I didn't receive any CVS
mails for Marcus' and my changes. Did anybody receive them?

 -- Jan

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Marcus M. <ma...@je...>]

On Fri, Sep 26, 2008 at 03:54:59PM +0200, Niek Bergboer wrote:
> Hi Marcus,
> 
> Sure thing. Here is the new version of the patch.

I have applied it as-is, but changed // to regular C comments
before to be consistent with the rest of the codebase.

Thanks!

Ciao, Marcus

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Niek B. <ni...@go...>]

Hi Marcus,

Sure thing. Here is the new version of the patch.

Regards,

Niek Bergboer
Google Switzerland GmbH

Identifikationsnummer:
CH-020.4.028.116-1

On Fri, Sep 26, 2008 at 3:18 PM, Marcus Meissner <ma...@je...> wrote:
> On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote:
>> Hi developers,
>>
>> Please find a patch attached to this mail that solves a couple of
>> memory-corruption issues, and a couple of 64-bit mode options.
>>
>> The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not
>> using these, one gets offsets in the > 2^31 range at times.
>>
>> The changes to exif-data.c prevent reading from e->data when e->data
>> is NULL, and to prevent calling exif_data_save_data_entry if
>> ifd->entries[j] is NULL.
>>
>> An additional set of changes within the maker-note files are to
>> prevent crashing on sizes > 64kb; It seems that the maker-notes, at
>> times, return sizes that are huge (as in: way beyond 2^31 bytes).
>> According to the documentation, though, the full size of the EXIF data
>> should fit within a JPEG section, thus intrinsically limiting it to 64
>> kb. I.e.: any s that is > 64 kb indicates a problem within the data.
>
> Is this diff the right way round? It seems you diffed new -> old
> instead of old -> new
>
> Also please use diff -u
>
> Ciao, Marcus
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> libexif-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel
>

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Marcus M. <ma...@je...>]

On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote:
> Hi developers,
> 
> Please find a patch attached to this mail that solves a couple of
> memory-corruption issues, and a couple of 64-bit mode options.
> 
> The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not
> using these, one gets offsets in the > 2^31 range at times.
> 
> The changes to exif-data.c prevent reading from e->data when e->data
> is NULL, and to prevent calling exif_data_save_data_entry if
> ifd->entries[j] is NULL.
> 
> An additional set of changes within the maker-note files are to
> prevent crashing on sizes > 64kb; It seems that the maker-notes, at
> times, return sizes that are huge (as in: way beyond 2^31 bytes).
> According to the documentation, though, the full size of the EXIF data
> should fit within a JPEG section, thus intrinsically limiting it to 64
> kb. I.e.: any s that is > 64 kb indicates a problem within the data.

Is this diff the right way round? It seems you diffed new -> old
instead of old -> new

Also please use diff -u

Ciao, Marcus

Re: [Libexif-devel] A few memory-corruption and 64-bit fixes

[Dan F. <da...@co...>]

On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote:
> Please find a patch attached to this mail that solves a couple of
> memory-corruption issues, and a couple of 64-bit mode options.

Would you mind resending the patch in unified diff format (-u)?  It's
more reliable to apply and to review that way.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

[Libexif-devel] A few memory-corruption and 64-bit fixes

[Niek B. <ni...@go...>]

Hi developers,

Please find a patch attached to this mail that solves a couple of
memory-corruption issues, and a couple of 64-bit mode options.

The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not
using these, one gets offsets in the > 2^31 range at times.

The changes to exif-data.c prevent reading from e->data when e->data
is NULL, and to prevent calling exif_data_save_data_entry if
ifd->entries[j] is NULL.

An additional set of changes within the maker-note files are to
prevent crashing on sizes > 64kb; It seems that the maker-notes, at
times, return sizes that are huge (as in: way beyond 2^31 bytes).
According to the documentation, though, the full size of the EXIF data
should fit within a JPEG section, thus intrinsically limiting it to 64
kb. I.e.: any s that is > 64 kb indicates a problem within the data.

Regards,

Niek Bergboer
Google Switzerland GmbH

Identifikationsnummer:
CH-020.4.028.116-1

[Libexif-devel] New Danish PO file for 'exif' (version 0.6.16-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/exif/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Dutch PO file for 'libexif' (version 0.6.17-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Dutch team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/nl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Dutch PO file for 'libexif' (version 0.6.17-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Dutch team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/nl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Indonesian PO file for 'exif' (version 0.6.16-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Indonesian team of translators.  The file is available at:

    http://translationproject.org/latest/exif/id.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-content.c, 1.28, 1.29

[Marcus M. <ma...@je...>]

On Sat, Jul 26, 2008 at 04:06:53PM +0000, Jan Patera wrote:
> Update of /cvsroot/libexif/libexif/libexif
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11556
> 
> Modified Files:
> 	exif-content.c 
> Log Message:
> Hopefully finally correct ;-)

Looks good now, eog nor gimp dont crash.

Ciao, Marcus
 
> 
> Index: exif-content.c
> ===================================================================
> RCS file: /cvsroot/libexif/libexif/libexif/exif-content.c,v
> retrieving revision 1.28
> retrieving revision 1.29
> diff -u -p -d -r1.28 -r1.29
> --- exif-content.c	26 Jul 2008 14:26:43 -0000	1.28
> +++ exif-content.c	26 Jul 2008 16:06:49 -0000	1.29
> @@ -175,9 +175,10 @@ exif_content_remove_entry (ExifContent *
>  		}
>  		c->entries = t;
>  		c->count--;
> -		if (i!=c->count) /* we deallocated the last slot already */ 
> +		if (i != c->count) { /* we deallocated the last slot already */ 
>  			memmove (&t[i], &t[i + 1], sizeof (ExifEntry*) * (c->count - i - 1));
> -		t[c->count-1] = temp;
> +			t[c->count-1] = temp;
> +		} 
>  	} else {
>  		exif_mem_free (c->priv->mem, c->entries);
>  		c->entries = NULL;
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> libexif-cvs mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-cvs
> 

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-tag.c, 1.40, 1.41

[Jan P. <pa...@pi...>]

Hi,

> Modified Files:
> 	exif-tag.c
> Log Message:
> gracefully return 0 when the name has not been found

.....
>  exif_tag_from_name (const char *name)
>  {
>  	unsigned int i;
> +	unsigned int result=0;
>
>  	if (!name) return 0;
>
>  	for (i = 0; ExifTagTable[i].name; i++)
> -		if (!strcmp (ExifTagTable[i].name, name)) break;
> -	return ExifTagTable[i].tag;

I am curious - did the old code really behave differently than the new one?
If the name is not found, at the end ExifTagTable[i].name is NULL
and therefore also ExifTagTable[i].tag is NULL.
Or am I overlooking something?

 -- Jan

> +		if (!strcmp (ExifTagTable[i].name, name))  {
> +		  	result = ExifTagTable[i].tag;
> +		  	break;
> +		}
> +	return result;
>  }

[Libexif-devel] Patch for memory leak in exif-loader.c if using a logger for a loader

[Mika R. <mi...@go...>]

Attached.

The bug was what if you set a logger with exif_loader_log(), it would
increment the refcount on the logger, but exif_loader_free would not
decrement it, leaking the logger.

Regards,
   Mika Raento

Re: [Libexif-devel] [PATCH] usercomment modification in exif utils

[matthieu c. <cas...@fr...>]

Lutz Müller wrote:
> On Sat, 2008-06-14 at 19:58 +0200, matthieu castet wrote:
>> I need to change exif usercomment. I update the exif tools to do that.
>> See the attached patch for cvs.
> 
> I checked in a slightly modified version (for exemple: avoid checking
> for e->data 2 times).
Ok, thanks. But now it always resize the user comment tag and my patch 
avoid that by using 0 padding.
> 
>> I don't manage to build cvs
> 
> Have you tried autoreconf -vis?
No, will try.
> 
>> all the exif data are rewritten and are different from
>> the original picture.
>> This shouldn't happen because I only update usercomment without changing
>> the tag size.
> 
> libexif doesn't modify in place. It loads/saves all EXIF data. By
> default, after loading the EXIF data, libexif makes sure that the EXIF
> data follows the specification (EXIF_DATA_OPTION_FOLLOW_SPECIFICATION).
> If the EXIF data you get is different from the EXIF data you supplied
> (with regard to the content), check if the EXIF data supplied follows
> the specification. Have a look at the debug messages using the -d
> command line option.
Using my patch (usercomment tag size not changed),
the difference with -d is [1].
exiv2 also report difference for ExifTag(0x8769) and 
InteroperabilityTag(0xa005).

May be libexif when rewriting the tags remove some padding ?



[1]
--- /tmp/1      2008-06-15 18:32:44.000000000 +0200
+++ /tmp/2      2008-06-15 18:32:40.000000000 +0200
@@ -1,5 +1,5 @@
  ExifLoader: Scanning 1024 byte(s) of data...
-ExifData: Parsing 11262 byte(s) EXIF data...
+ExifData: Parsing 8931 byte(s) EXIF data...

  ExifData: Found EXIF header.
  ExifData: Found EXIF header.
@@ -50,13 +50,13 @@
  ExifData: Loading entry 0xa403 ('WhiteBalance')...
  ExifData: Loading entry 0xa404 ('DigitalZoomRatio')...
  ExifData: Loading entry 0xa406 ('SceneCaptureType')...
-ExifData: IFD 1 at 3158.
+ExifData: IFD 1 at 3136.
  ExifData: Loading 6 entries...
  ExifData: Loading entry 0x103 ('Compression')...
  ExifData: Loading entry 0x11a ('XResolution')...
  ExifData: Loading entry 0x11b ('YResolution')...
  ExifData: Loading entry 0x128 ('ResolutionUnit')...
-EXIF tags in '/tmp/IMG_0872.JPG' ('Intel' byte order):
+EXIF tags in '/tmp/IMG_0872.JPG.modified.jpeg' ('Intel' byte order):
 
--------------------+----------------------------------------------------------
  Tag                 |Value 

 
--------------------+----------------------------------------------------------
@@ -86,8 +86,8 @@
  Metering Mode       |Pattern 

  Flash               |Flash did not fire, compulsory flash mode. 

  Focal Length        |8.3 mm 

-Maker Note          |2138 bytes unknown data 

-User Comment        |Marseille : Cath 

+Maker Note          |2124 bytes unknown data 

+User Comment        |mct 

  FlashPixVersion     |FlashPix Version 1.0 

  Color Space         |sRGB 

  PixelXDimension     |2592