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

Re: [Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

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

On Mon, 2003-09-01 at 07:57, Ben Hartshorne wrote:
> ben@ibook-laptop ~$ PKG_CONFIG_PATH=3D/usr/local/lib

You're new to linux, ain't you? Try=20

'export PKG_CONFIG_PATH=3D/usr/local/lib/pkgconfig'

If you use bash, you can add that to your $HOME/.bashrc in order to make
that persistent.

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

[Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Ben H. <tr...@gr...>]

Hi,

Please forgive the out-of-order reply, I'm not actually on the mailing
list but just reading it through the archives.

On Sun, Aug 31 at 13:28, Lutz <lutz@us...> wrote:
>  On Sun, 2003-08-31 at 19:41, Ben Hartshorne wrote:
>  > I also tried it with PKG_CONFIG_PATH set to /usr/local/lib/pkgconfig,
>  > but to no avail.
> =20
>  This should work. What does "pkg-config --modversion libexif" say?

ben@ibook-laptop ~$ pkg-config --modversion libexif
Package libexif was not found in the pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found
ben@ibook-laptop ~$ PKG_CONFIG_PATH=3D/usr/local/lib
ben@ibook-laptop ~$ pkg-config --modversion libexif
Package libexif was not found in the pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found
ben@ibook-laptop ~$ PKG_CONFIG_PATH=3D/usr/local/lib/pkgconfig
ben@ibook-laptop ~$ pkg-config --modversion libexif
Package libexif was not found in the pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found
ben@ibook-laptop ~$ echo $PKG_CONFIG_PATH
/usr/local/lib/pkgconfig


In other words, nothing useful.  :(

-ben
=20

--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

Re: [Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

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

On Sun, 2003-08-31 at 19:41, Ben Hartshorne wrote:
> I also tried it with PKG_CONFIG_PATH set to /usr/local/lib/pkgconfig,
> but to no avail.

This should work. What does "pkg-config --modversion libexif" say?

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

[Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Ben H. <tr...@gr...>]

Two things I forgot to mention:
the pkg-config file for libexif gets installed correctly:
ben@ibook-laptop ~/tmp/libexif-0.5.12$ ls /usr/local/lib/pkgconfig/
libexif.pc
ben@ibook-laptop ~/tmp/libexif-0.5.12$ cat !$*
cat /usr/local/lib/pkgconfig/*
prefix=3D/usr/local
exec_prefix=3D${prefix}
libdir=3D${exec_prefix}/lib
includedir=3D${prefix}/include

Name: libexif
Description: Library for easy access to EXIF data
Requires:
Version: 0.5.12
Libs: -L${libdir} -lexif -lm
Cflags: -I${includedir}/libexif -I${includedir}


Second thing - following the suggestion of the ./configure script and
adding the path to 	PKG_CONFIG_PATH doesn't seem to help
checking for libexif >=3D 0.5.9... Package libexif was not found in the
pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found

configure: error: Library requirements (libexif >=3D 0.5.9) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.
ben@ibook-laptop ~/tmp/exif-0.6$ echo $PKG_CONFIG_PATH=20
/usr/local/lib

I also tried it with PKG_CONFIG_PATH set to /usr/local/lib/pkgconfig,
but to no avail.

-ben


On Sun, Aug 31, 2003 at 10:28:56AM -0700, Ben Hartshorne wrote:
> Hi,
>=20
> My installation of libexif seemed to go alright.  After './configure',
> 'make', and 'make install', these are the contents of my /usr/local/lib
> dir:
> ben@ibook-laptop ~/tmp/libexif-0.5.12$ ls /usr/local/lib
> charset.alias             libexif.a                 pkgconfig/
> libexif.9.1.2.dylib*      libexif.dylib@
> libexif.9.dylib@          libexif.la*
>=20
> I merrily went on my way to ../exif-0.6/, where ./configure fails:
> checking for libexif >=3D 0.5.9... Package libexif was not found in the
> pkg-config search path.
> Perhaps you should add the directory containing `libexif.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libexif' found
>=20
> configure: error: Library requirements (libexif >=3D 0.5.9) not met;
> consider adjusting the PKG_CONFIG_PATH environment variable if your
> libraries are in a nonstandard prefix so pkg-config can find them.
>=20
>=20
> Sure enough, if I ask pkg-config what packages it knows about, it does
> not list libexif.
> ben@ibook-laptop ~/tmp/exif-0.6$ pkg-config --list-all
> gdk       GDK - GIMP Drawing Kit
> gmodule   GModule - Dynamic module loader for GLib
> glib      GLib - C Utility Library
> esound    esound - esound
> gthread   GThread - Thread support for GLib
> libIDL    libIDL - IDL parsing library
> libpng    libpng12 - Loads and saves PNG files
> libpng12  libpng12 - Loads and saves PNG files
> imlib     Imlib - An image loading and rendering library for X11R6
> audiofile audiofile - audiofile
> gtk+      GTK+ - GIMP Tool Kit
> ORBit     ORBit - High-performance CORBA Object Request Broker.
> imlibgdk  ImlibGdk - GDK support libraries for Imlib
>=20
>=20
> I'm not sure what to do next.  I can't find any command line argumets to
> pkg-config to tell it to search particular directories or add new
> packages, but shouldn't the install for libexif have done that? =20
>=20
> Thanks,
>=20
> -ben
>=20
> --=20
> Ben Hartshorne
> email: be...@ha...
> http://ben.hartshorne.net



--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

[Libexif-devel] difficulty installing exif on MacOSX - pkg-config

[Ben H. <tr...@gr...>]

Hi,

My installation of libexif seemed to go alright.  After './configure',
'make', and 'make install', these are the contents of my /usr/local/lib
dir:
ben@ibook-laptop ~/tmp/libexif-0.5.12$ ls /usr/local/lib
charset.alias             libexif.a                 pkgconfig/
libexif.9.1.2.dylib*      libexif.dylib@
libexif.9.dylib@          libexif.la*

I merrily went on my way to ../exif-0.6/, where ./configure fails:
checking for libexif >=3D 0.5.9... Package libexif was not found in the
pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found

configure: error: Library requirements (libexif >=3D 0.5.9) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.


Sure enough, if I ask pkg-config what packages it knows about, it does
not list libexif.
ben@ibook-laptop ~/tmp/exif-0.6$ pkg-config --list-all
gdk       GDK - GIMP Drawing Kit
gmodule   GModule - Dynamic module loader for GLib
glib      GLib - C Utility Library
esound    esound - esound
gthread   GThread - Thread support for GLib
libIDL    libIDL - IDL parsing library
libpng    libpng12 - Loads and saves PNG files
libpng12  libpng12 - Loads and saves PNG files
imlib     Imlib - An image loading and rendering library for X11R6
audiofile audiofile - audiofile
gtk+      GTK+ - GIMP Tool Kit
ORBit     ORBit - High-performance CORBA Object Request Broker.
imlibgdk  ImlibGdk - GDK support libraries for Imlib


I'm not sure what to do next.  I can't find any command line argumets to
pkg-config to tell it to search particular directories or add new
packages, but shouldn't the install for libexif have done that? =20

Thanks,

-ben

--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

[Libexif-devel] Re: MakerNote corrupted... and output file smaller than the input

[Roberto C. <rob...@en...>]

Lutz wrote:
>
> [...]
> 
> (1) (drop): Not very nice.
> (2) (keeping memory regions): This could work. You would save an array
> of buffers together with the original offsets in the ExifData and try to
> rearrange those buffers on exif_data_save_to_data at their original
> offsets.

Exactly.
This should always be possible, because even the offset of IFD0 within
exif information can be arbitrarily specified. It's usually 0x8, I just
hope no camera assumes it is 0x8 without reading the value...

> I have just (seconds before receiving your e-mail) committed some
> changes to libmnote to make it possible to pass EXIF data (instead of
> only MakerNote data) to mnote_data_new_from_data. I had in mind that
> 
>  - mnote_data_new_from_data reads all interesting bytes into 
>    memory (like libexif does with EXIF data)
>  - mnote_data_save_to_data writes all MakerNote data into one ExifEntry.
> 
> That is, if you 
>  - read the EXIF data, 
>  - then the MakerNote data, 
>  - save the MakerNote data and 
>  - store the buffer in the corresponding entry in the EXIF data and
>  - finally save the EXIF data, 
> this would be like a defragmentation.
> 
> But we can do both: Adding an array of memory regions and (optionally)
> giving the user the possibility of defragmentation through libmnote.

Yes, I agree.
When libmnote provides libexif with the knowledge about the maker notes,
libexif can safely modify a file and compact/defragment it at the same
time.
Otherwise (libexif compiled without libmnote support, or libmnote that
doesn't recognize the maker notes of some manifacturer... or is just not
installed) it's necessary to follow the much more conservative behavior
we discussed.

> How about that? Do you have time to work on implementing the detection
> of unused buffers?

I'm happy to work on it, I will probably have little time before Friday,
but I should be able to produce something by Monday.

Cheers,
Roberto

[Libexif-devel] libmnote canon support

[matthieu <ma...@if...>]

I don't know if you recieve my previous patch, but i send yo=
u another
that use the exif data.

becarefull, it seem the sourceforge cvs server don't work ve=
ry well, and
the add in the diff the change you made today

Matthieu


____________________________________________________________=
_________
MSN Messenger, nouvelle version ! Personnalisez vos messages=
, jouez en
ligne et communiquez en temps r=E9el par vid=E9o! http://ifr=
ance.com/_reloc/m

[Libexif-devel] Re: MakerNote corrupted... and output file smaller than the input

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

On Mon, 2003-08-25 at 21:57, Roberto Costa wrote:
> Only two behaviors are acceptable to my eyes for files written by
> libexif:
> a) libexif drops the entire MakerNote entry and warns the user that it
>    has done so;
> b) libexif successfully reproduces MakerNote entry, even without knowin=
g
>    what its contents means.
> I don't like the first, so I'm trying to come out with an idea to get
> the second. I already have something in mind.
>=20
> Suppose that libexif:
> -) builds a sort of map of the apparently unused regions of the exif
>    section of the original file;
> -) keeps all those regions unchanged in the output file (for unchanged =
I
>    mean same values at the same offsets).
> Shouldn't this work out?

(1) (drop): Not very nice.
(2) (keeping memory regions): This could work. You would save an array
of buffers together with the original offsets in the ExifData and try to
rearrange those buffers on exif_data_save_to_data at their original
offsets.=20

I have just (seconds before receiving your e-mail) committed some
changes to libmnote to make it possible to pass EXIF data (instead of
only MakerNote data) to mnote_data_new_from_data. I had in mind that

 - mnote_data_new_from_data reads all interesting bytes into=20
   memory (like libexif does with EXIF data)
 - mnote_data_save_to_data writes all MakerNote data into one ExifEntry.

That is, if you=20
 - read the EXIF data,=20
 - then the MakerNote data,=20
 - save the MakerNote data and=20
 - store the buffer in the corresponding entry in the EXIF data and
 - finally save the EXIF data,=20
this would be like a defragmentation.

But we can do both: Adding an array of memory regions and (optionally)
giving the user the possibility of defragmentation through libmnote.

How about that? Do you have time to work on implementing the detection
of unused buffers?

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

[Libexif-devel] MakerNote corrupted... and output file smaller than the input

[Roberto C. <rob...@en...>]

Hello,
I read a message posted in this mailing list, in which a Canon user
claims that files processed by libexif shrink.
I notice the same behavior with the files produced by my camera (a
Canon, but I think what I'm going to say is more general), so I
investigated in order to understand what libexif leaves behind.

Padding bytes, which are not reproduced by libexif, may be an
explanation, but only a partial one. The real and most serious reason
why a file shrinks is that maker note data that is referenced within
MakerNote entry but is allocated outside is lost whenever libexif tries
to write the file!
Think about the format of an IFD: each entry whose data size is bigger
than 4 bytes is listed indeed within the IFD, but its contents is stored
outside!
Several camera manifacturers organize the MakerNote entry like a IFD,
sad but true.

What currently happens is that, at least for some cameras, libexif
silently corrupts MakerNote entry.
This unfortunately isn't libexif's fault (unfortunately, because
eventual libexif's faults can be corrected!), I see it as a flaw in
exif's specs: since nobody else is supposed to know what the maker note
means, it should have been enforced that its data do not spread beyond
its "visible" borders.

However, I think this can't be an excuse.
Only two behaviors are acceptable to my eyes for files written by
libexif:
a) libexif drops the entire MakerNote entry and warns the user that it
   has done so;
b) libexif successfully reproduces MakerNote entry, even without knowing
   what its contents means.
I don't like the first, so I'm trying to come out with an idea to get
the second. I already have something in mind.

Suppose that libexif:
-) builds a sort of map of the apparently unused regions of the exif
   section of the original file;
-) keeps all those regions unchanged in the output file (for unchanged I
   mean same values at the same offsets).
Shouldn't this work out?
Of course it does not if a maker note references datas external to
itself with relative offsets, but we must make some common-sense
assumptions. In order to preserve maker notes that use relative offsets
to external datas, we would need to make sure that the output-file
offset of the maker note itself is the same of the input file, which I
see it as a much harder constraint.

What do you think about it? Does it make sense?
I'm looking forward to hear your opinions about all that, mine are just
a bunch of ideas from someone who is relatively new with exif
information.

Cheers,
Roberto

[Libexif-devel] Extra data bytes in exif entries smaller than 4 bytes

[Roberto C. <rob...@en...>]

Hello,
I notice that files modified by libexif contain apparently random values
in the extra bytes of exif entries that are smaller than 4 bytes.
For instance, if an entry is composed of one component of type short,
libexif writes the value of the short into the first two bytes of the
entry data, while the last two are left undefined (memory is allocated
without being initialized).

I understand this probably doesn't violate exif's specs, however it
would make more sense to me if those useless bytes were set in a
predictable way (for instance now libexif, if run on two different
machines, is likely to produce slightly different output files).
The easiest solution is to fill them with zeroes, which is
straightforward to be implemented: it's sufficient to add a couple of
lines in fuction exif_data_save_data_entry(...). Attached you can find a
3-line patch for libexif/exif-data.c

An alternative solution that makes sense to me as well is to fill the
eventual extra bytes with the value they have in the input file
(provided that the entry was already present!). The purpose is that of
changing the input file as less as possible.
This solution would require a bit more hacking, since a 4-byte value
would have to be read and stored even for entries whose size is smaller.
I don't know whether this is worthwhile, probably not.
Do you have any experience about what cameras do with such extra bytes?
Mine (a Canon) always fills them with zeroes, if this were the most
typical case, I wouldn't hesitate to recommend the first solution (and
my patch).

Cheers,
Roberto

[Libexif-devel] Re: Extra data bytes in exif entries smaller than 4 bytes

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

On Sun, 2003-08-24 at 23:06, Roberto Costa wrote:
> Attached you can find a
> 3-line patch for libexif/exif-data.c

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

Re: [Libexif-devel] libmnote canon support

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

On Fri, 2003-08-22 at 10:47, matthieu wrote:
> another thing is in specific camera code there is generic code that is
> only copy and paste and only few code have to be modified for it work :=
=20
> the begining of mnote_*_data_load_data, the value in offset of
> mnote_*_data_load_data_entry (yes i don't know why but i need to do dof=
f
> =3D exif_get_long (d + offset + 8, order)-0x3B0; for having the correct
> offset) and the value of tag, and their description (
> mnote_*_entry_get_value, _MNote*Tag, ...)

Could you send us your modifications? Use 'cvs diff -u3 -p', please.

Thank you!
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] libmnote canon support

[matthieu <ma...@if...>]

hello,
i am trying to add support for my canon (G3) in libmnote.
But i have find some small problem :
the maker note data start directly with the data, and the pr=
obing that
was made in mnote_data_new_from_data ("(size > 1) && (data[0=
] =3D=3D 0x00)
&& (data[1] =3D=3D 0x00)") doesn't work, and i have to force=
 canon maker
note for it works. Why not use the exif tag 0x010f for doing=
 this
probing ?

Also i have another problem with the endianess : libmnote do=
esn't seem
to detect the order and mnote_data_get_byte_order return alw=
ays 0
whereas my data are intel type. So i have to set this flag i=
n
libmnote-canon...

another thing is in specific camera code there is generic co=
de that is
only copy and paste and only few code have to be modified fo=
r it work :=20
the begining of mnote_*_data_load_data, the value in offset =
of
mnote_*_data_load_data_entry (yes i don't know why but i nee=
d to do doff
=3D exif_get_long (d + offset + 8, order)-0x3B0; for having =
the correct
offset) and the value of tag, and their description (
mnote_*_entry_get_value, _MNote*Tag, ...)

Also the canon maker note use sort of subtag(45 entry in tag=
 0x1... but
only 15 are know), and get_value have to return big chain of=
 settings...

here an example of what i have done :

Dumping MakerNote content (14 entries)...
Tag: 0x1 ('Settings1')
  Value: Macro mode : Normal
Flash mode : auto + red eyes reduction
Continuous drive mode : single or timer
Focus mode : Single
ISO : auto
Exposure mode : Easy shooting
long focal length of lens (in focal units) : 922
short focal length of lens (in focal units) : 230
focal units per mm : 32
Focus mode : Single
Tag: 0x4 ('Settings2')
  Value:=20
Subject Distance (mm) : 158
Tag: 0x6 ('ImageType')
  Value: IMG:PowerShot G3 JPEG
Tag: 0x7 ('FirmwareVersion')
  Value: Firmware Version 1.02
Tag: 0x8 ('ImageNumber')
  Value: 107-0710
Tag: 0x9 ('OwnerName')
  Value: Matthieu

____________________________________________________________=
_________
MSN Messenger, nouvelle version ! Personnalisez vos messages=
, jouez en
ligne et communiquez en temps r=E9el par vid=E9o! http://ifr=
ance.com/_reloc/m

[Libexif-devel] Re: exif tool: argument of --set-value truncated to the 1st blankcharacter

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

On Wed, 2003-08-20 at 23:14, Roberto Costa wrote:
> > On Sat, 2003-08-16 at 14:21, Roberto Costa wrote:
> > > I attach two modified versions of main.c to this message
> > > (main.patched1.c and main.patched2.c).
> >=20
> > Could you supply diffs against CVS? Use 'cvs diff -u3 -p'.
> >=20
> > Thank you!
>=20
> Sure, here attached are the two patches.

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

[Libexif-devel] Re: exif tool: argument of --set-value truncated to the 1st blankcharacter

[Roberto C. <rob...@en...>]

> On Sat, 2003-08-16 at 14:21, Roberto Costa wrote:
> > I attach two modified versions of main.c to this message
> > (main.patched1.c and main.patched2.c).
> 
> Could you supply diffs against CVS? Use 'cvs diff -u3 -p'.
> 
> Thank you!

Sure, here attached are the two patches.

Roberto

Re: [Libexif-devel] Re: exif tool: argument of --set-value truncated to the 1st blankcharacter

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

On Sat, 2003-08-16 at 14:21, Roberto Costa wrote:
> I attach two modified versions of main.c to this message
> (main.patched1.c and main.patched2.c).

Could you supply diffs against CVS? Use 'cvs diff -u3 -p'.

Thank you!
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Re: exif tool: argument of --set-value truncated to the 1st blankcharacter

[Roberto C. <rob...@en...>]

Lutz Müller wrote:
> 
> On Wed, 2003-08-13 at 22:13, Roberto Costa wrote:
> > The quickest patch I can think of is to comment lines 539 and 540 of
> > exif/main.c (the one released with exif 0.6).
> > I only wonder why they have been put there... is there any kind of value
> > set through "--set-value" that needs to be similarly truncated?
> 
> I guess it has been done to separate values like "1 2 3 4" for entries
> that have 4 components (like coordinates). If this is the case, we need
> proper escaping. For example
> 
> "1|2|3|4" would result in "1", "2", "3", "4"
> 
> "(\|\\)" would result in "(|\)"
> 
> If I am right, could you supply a patch?

Hello,
ok, now that I understand the concept of "component", I see why a
command-line argument provided for --set-value might be divided in
sub-strings.
In this respect, I think that an ascii string substantially differs from
the other formats, because its value can be directly expressed on
the command line (an integer for instance is represented as a string
which is then converted into an int) and its components don't need to
be separated by any special character.
This is why in my opinion the best solution is to handle ascii strings
differently than any other format.

I attach two modified versions of main.c to this message
(main.patched1.c and main.patched2.c). The second patch contains all the
changes included in the first, the reason why I'm providing two patches
is that those added by the second go beyond the problem we're discussing
and hence I thought might be accepted after some discussions.
Of course I definitely recommend the second patch!

Here is a summary of the changes of main.patched1.c:
-) The conversion of the cmd-line argument of --set-value into the exif
   entry is moved into a separate static function (it was already in a
   new scope, indented like a function!).
-) ASCII strings are handled separately, in a way that is faster and
   straightforward.

In addition, main.patched2.c also includes:
-) The handler of the other formats is cleaner and shorter, string.h
   provides a lot of useful functions, why not to use them?
   By the way, this handler no longer does stuff that is a duty of the
   shell and absolutely not of the other applications...
-) Added check that the right number of components are specified.
-) buf no longer statically allocated, in order to prevent buffer
   overflow.
-) The component separator is now ',', this can be easily changed (by
   modifying the assignment of comp_separ).

Cheers,
Roberto

[Libexif-devel] Re: exif tool: argument of --set-value truncated to the 1st blank character

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

On Wed, 2003-08-13 at 22:13, Roberto Costa wrote:
> The quickest patch I can think of is to comment lines 539 and 540 of
> exif/main.c (the one released with exif 0.6).
> I only wonder why they have been put there... is there any kind of valu=
e
> set through "--set-value" that needs to be similarly truncated?

I guess it has been done to separate values like "1 2 3 4" for entries
that have 4 components (like coordinates). If this is the case, we need
proper escaping. For example

"1|2|3|4" would result in "1", "2", "3", "4"

"(\|\\)" would result in "(|\)"

If I am right, could you supply a patch?

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

[Libexif-devel] exif tool: argument of --set-value truncated to the 1st blank character

[Roberto C. <rob...@en...>]

Hello,
yesterday I was performing some experiments about putting image
descriptions to jpg pictures with exif tool, when I found out that they
are truncated to the first blank character (ascii 32).
For instance, if I type:
exif --tag='ImageDescription' --set-value="This is a test" --ifd=0
img.jpg
the image description written into the output file will be "This"
instead of "This is a test".
I see that gexif allows blank characters within image descriptions, I
believe exif's behavior is wrong in this.

The quickest patch I can think of is to comment lines 539 and 540 of
exif/main.c (the one released with exif 0.6).
I only wonder why they have been put there... is there any kind of value
set through "--set-value" that needs to be similarly truncated?

Cheers,
Roberto

[Libexif-devel] Re: libexif ChangeLog,1.69,1.70 Makefile.am,1.18,1.19 configure.in,1.52,1.53

[Arnaud L. <as...@la...>]

Le Mon, Aug 04, 2003 at 07:51:55PM +0000, Lutz M?ller a =E9crit:
> 2003-08-04  Lutz Mueller <lu...@us...>
> 	* po/*.po: Updated.
> 	* Makefile.am: Add m4 and intl to SUBDIRS. automake complains
> 	  otherwise.
> 	* configure.in: Add m4/Makefile. make distcheck complains otherwise.
> 	  Version 0.5.12

This entirely breaks the compilation here.

Running autoheader-2.57
configure.in:66: error: `intl/Makefile' is already registered with AC_CON=
FIG_FILES.
autoconf/status.m4:844: AC_CONFIG_FILES is expanded from...
configure.in:66: the top level
autom4te-2.57: /usr/bin/m4 failed with exit status: 1
autoheader-2.57: /usr/bin/autom4te failed with exit status: 1
Last command failed with status 1 in directory /home/asl/cvs/photo/coin/l=
ibexif.
Aborting.
Last command failed with status 1 in directory /home/asl/cvs/photo/coin/l=
ibexif.
Aborting.

More, we don't need those for neither of the other projects. Why
adding this here and breaking everything ?

Effectively, distcheck doesn't work right...

make[1]: Entering directory `/home/asl/cvs/photo/bouh/po'
make[1]: *** Pas de r=E8gle pour fabriquer la cible =AB @POMAKEFILEDEPS@ =
=BB, n=E9cessaire pour =AB Makefile =BB. Arr=EAt.
make[1]: Leaving directory `/home/asl/cvs/photo/bouh/po'
make: *** [distdir] Erreur 1

Ah ! Seems it's a bug with automake 1.6, as it works fine with automake 1=
.7.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
libexif-0.5.12.tar.gz is ready for distribution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Lutz, I urge you to revert your change, and upgrade your automake to 1.7;
1.7.5 seems to work like a charm.

	Arnaud.
--=20
Q:      What do you call a boomerang that doesn't come back?
A:      A stick.

[Libexif-devel] Re: [Fwd: Re: file size decreases after exif --set-value? (relly)]

[Al E. <al...@tb...>]

At 1:02 AM +0200 8/1/03, Lutz M=FCller wrote:
>Hi!
>
>The problem has already been discovered by Al Evans. There is no fix yet
>with regard to saving the modified exif data without loosing the
>information accessible through the MakerNote.
>
>One solution could be to move (on saving) all data associated with the
>MakerNote into the MakerNote entry itself. I haven't verified if this is
>possible. But this would mean to drop the strict separation of libexif
>and libmnote.
>
>I am not sure yet.
>--
>Lutz M=FCller <lu...@us...>
>
>>----------------------------------
>>Duane H. Hesser <dh...@mo...>
>>----------------------------------
>>BTW, the size change that you observed has nothing to do with the
>>"problem" mentioned above.  Most of the size change is due to a
>>"hole" in the original image after IFD1, before the primary JPEG
>>data starts.
>>
>>--

According to my results, this is not really a "hole". The MakerNote, 
in all cases that I know of, has a similar structure to an EXIF IFD. 
That is to say, when the data doesn't fit into the last four bytes of 
an entry, those bytes contain a pointer. For the Olympus E20 
MakerNote (at least), the pointers point into this "hole". Here's 
part of an email I sent Lutz this afternoon:

-----
>Do you tell me that your camera writes EXIF data with pointers in the
>tag MakerNote to regions outside the MakerNote tag? So, if the MakerNote
>tag has a size of 600 bytes, it has in reality a size of more than that?

Precisely. If you think about it, there is no other option. If the 
data is > 4 bytes, it CAN'T put it within the MakerNote tag, since 
that tag consists of 12-byte fields. The Olympus E10 and E20 are the 
only current cameras I know that record such data in the MakerNotes, 
but any camera that did so, would have to use bytes outside the 
MakerNote tag. For example, though I have no idea what it means, 
Olympus E20 tag 0x1033 is an array of 720 shorts, with an offset of 
0x0f34 (the MakerNote is under 900 bytes):

00002d0: 0003 0000 0001 ffff 0000 1033 0004 0000  ...........3....
                                   ----
00002e0: 02d0 0000 0f34 1034 0005 0000 0001 0000  .....4.4........
          ----      ----
-----

					--Al Evans--

[Libexif-devel] [Fwd: Re: file size decreases after exif --set-value? (relly)]

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

Hi!

The problem has already been discovered by Al Evans. There is no fix yet
with regard to saving the modified exif data without loosing the
information accessible through the MakerNote.=20

One solution could be to move (on saving) all data associated with the
MakerNote into the MakerNote entry itself. I haven't verified if this is
possible. But this would mean to drop the strict separation of libexif
and libmnote.

I am not sure yet.
--=20
Lutz M=FCller <lu...@us...>

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...>

[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] Re: docs

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

On Sat, 2003-04-19 at 15:32, Arnaud Launay wrote:
> There is. If you want to write any, you're damn welcome !

Indeed. I couldn't have said this better :-)

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