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

Re: [Libexif-devel] Mingw32 compile on Windows

[Gary L. <li...@lu...>]

Thanks, I've managed to get a library and test program as follows to 
compile. Two questions:

   1. I can see which tags exist in my test image, but how do I get at
      their values
   2. Is it straight-foward to build a DLL for this or am I better
      sticking with the library? If so how do I go about this?

(cc'd to the list as reference for others)

Gary

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

#include <libexif/exif-data.h>
#include <libexif/exif-loader.h>
#include <libexif/exif-log.h>
#include <libexif/exif-ifd.h>

#define ENTRY_FOUND     "   *   "
#define ENTRY_NOT_FOUND "   -   "

void action_tag_table (const char *filename, ExifData *ed)
{
    unsigned int tag;
    const char *name;
    char txt[1024];
    unsigned int i;

    memset (txt, 0, sizeof (txt));
    sprintf (txt, "EXIF tags in '%s':", filename);
    fprintf (stdout, "%-38.38s", txt);
    for (i = 0; i < EXIF_IFD_COUNT; i++)
        fprintf (stdout, "%-7.7s", exif_ifd_get_name (i));
    fputc ('\n', stdout);
    for (tag = 0; tag < 0xffff; tag++) {
        name = exif_tag_get_title (tag);
        if (!name)
            continue;
        fprintf (stdout, "  0x%04x %-29.29s", tag, name);
        for (i = 0; i < EXIF_IFD_COUNT; i++)
            if (exif_content_get_entry (ed->ifd[i], tag))
                printf (ENTRY_FOUND);
            else
                printf (ENTRY_NOT_FOUND);
        fputc ('\n', stdout);
    }
}

int main(int argc, char *argv[])
{
            ExifLoader *l;
            ExifData *ed;

            char fname[] = "c:\\temp\\test.jpg";

            l = exif_loader_new ();
            exif_loader_write_file (l, fname);
            ed = exif_loader_get_data (l);
            exif_loader_unref (l);
            action_tag_table (fname, ed);

  system("PAUSE");   
  return 0;
}

Gary Lawton
http://www.garylawton.com



Antonio Scuri wrote:

>
>   I'm sending two files. I do not remember if the second one is 
> distributed with the sources or not.
>
>   The makefile is quite simple, using Dev-C++ just create an empty 
> project and add all the sources. I do not have a simple one because I 
> merged some libs together to build my own lib:
>
>      http://www.tecgraf.puc-rio.br/im
>
> Best,
> scuri
>
> At 05:23 10/03/04, you wrote:
>
>> Do you also have a suitable makefile (or how can I generate this)
>>
>> Thanks
>> Gary
>>
>> Gary Lawton
>> http://www.garylawton.com
>>
>>
>>
>> Antonio Scuri wrote:
>>
>>>
>>>   Hi,
>>>
>>>   I compile libexif in several platforms (including mingw) just 
>>> writing a proper "config.h" file. If you want I can send it to you.
>>>
>>> scuri
>>
>------------------------------------------------------------------------
>
>
>#ifndef __STDINT_H
>#define __STDINT_H
>
>#ifndef __int8_t_defined
>#define __int8_t_defined
>typedef signed char int8_t;
>typedef short int16_t;
>typedef long int32_t;
>#endif
>
>typedef unsigned char uint8_t;
>typedef unsigned short uint16_t;
>#ifndef __uint32_t_defined
>#define __uint32_t_defined
>typedef unsigned long uint32_t;
>#endif
>
>#endif 
>  
>
>------------------------------------------------------------------------
>
>
>/* Define to 1 if translation of program messages to the user's native
>   language is requested. */
>/* #undef ENABLE_NLS */
>
>/* The gettext domain we're using */
>#define GETTEXT_PACKAGE "libexif-9"
>
>#ifdef WIN32
>#define snprintf _snprintf
>#endif
>
>  
>

[Libexif-devel] Mingw32 compile on Windows

[Gary L. <ga...@lu...>]

I'm trying to compile a Win32 for libEXIF using DevC++ and the mingw32 
compiler, but am really struggling. Looking through the archives, there 
have been a number of requests for win32 support, but no answers posted.

Has anyone been successful and can they post a working solution - I 
don't currently have cygwin installed (but could if that's the only option!)

Thanks
Gary

-- 

Gary Lawton
http://www.garylawton.com

Re: [Libexif-devel] libexif API changes

[Christopher A. <ca...@re...>]

Lutz M=FCller wrote:

>>Other=20
>>applications should be reluctant to require libexif if that is the case.
>>   =20
>>
>
>In the MS-Windows world, people copy & paste the code into their
>projects. That's always an option to avoid every problem. The small size
>allows for that. In gphoto2 I have used AC_CHECK_LIB and
>AC_CHECK_HEADER. In addition, we provide pkg-config --modversion.=20
>
>If you give me the names of projects that do not use those methods for
>avoiding troubles compiling with libexif, I will look into fixing them.
> =20
>
The problem is not that you don't provide the means to check the version=20
at compile time, but the fact that you have to, really.  Thankfully the=20
soname changed....

The package I am talking about specifically is nautilus.  The patch for=20
it is easily done; in fact I have one for alexl, and I believe debian=20
merged one into their tree as well.  The issue that alexl is a bit=20
concerned with is if the interfaces will be frequently changing, causing=20
much more headache down the line.  Why shouldn't nautilus be able to be=20
compiled and run against whatever version of libexif the user has=20
installed?  Changing the interfaces makes that harder.  Not impossible. =20
But harder.

> =20
>
>>Additionally, I will note that it would probably be nice to expose=20
>>LIBEXIF_CURRENT or similar in a .h file which things can #include to=20
>>support building against multiple versions of libexif.
>>   =20
>>
>
>This is easily done in the individual project using above outlined
>methods (isn't this what configure.in files are for?).
> =20
>
Sure, it can be done in configure.in, but it is much easier to write:

#if LIBEXIF_CURRENT >=3D 10
  /* new api */
#else
  /* old api */
#endif

than to do configure checking, and more robust than having the package=20
assume knowledge about which API versions correspond to which libexif=20
releases.

Re: [Libexif-devel] libexif API changes

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

On Mon, 2004-07-12 at 18:24, Christopher Aillon wrote:
> I am the package maintainer of libexif for Red Hat and the Fedora 
> Project.  I am trying to keep up with the latest release of libexif, but 
> I just noticed the the API changed in 0.5.13, which will require some 
> work for other applications.  We are currently using 0.5.12.  Does the 
> libexif team anticipate many more API changes in future releases?

We thought this change is worth the hassle. If someone has a good idea,
we'll put it into libexif. Otherwise, things won't improve.

> Other 
> applications should be reluctant to require libexif if that is the case.

In the MS-Windows world, people copy & paste the code into their
projects. That's always an option to avoid every problem. The small size
allows for that. In gphoto2 I have used AC_CHECK_LIB and
AC_CHECK_HEADER. In addition, we provide pkg-config --modversion. 

If you give me the names of projects that do not use those methods for
avoiding troubles compiling with libexif, I will look into fixing them.

> Additionally, I will note that it would probably be nice to expose 
> LIBEXIF_CURRENT or similar in a .h file which things can #include to 
> support building against multiple versions of libexif.

This is easily done in the individual project using above outlined
methods (isn't this what configure.in files are for?).

If you still think we should expose a LIBEXIF_CURRENT definition, can
you point me to a project where this method is used successfully so that
I can code along that?

Regards

Lutz

[Libexif-devel] libexif API changes

[Christopher A. <ca...@re...>]

Hello,

I am the package maintainer of libexif for Red Hat and the Fedora 
Project.  I am trying to keep up with the latest release of libexif, but 
I just noticed the the API changed in 0.5.13, which will require some 
work for other applications.  We are currently using 0.5.12.  Does the 
libexif team anticipate many more API changes in future releases?  Other 
applications should be reluctant to require libexif if that is the case.

Additionally, I will note that it would probably be nice to expose 
LIBEXIF_CURRENT or similar in a .h file which things can #include to 
support building against multiple versions of libexif.


Christopher

[Libexif-devel] Reusing code from libexif in PEL

[Martin G. <gim...@gi...>]

Hi!

I've been working on a port of libexif to PHP for some time now and
the result is a working EXIF read/write library for PHP, written in
PHP5.  Once I got used to the PHP <-> C mapping, it was very easy to
port the library because of the nice, clean C code.  The project has
it's homepage here:

  http://pel.sourceforge.net/

The last thing I've been working on is internationalization, and for
that I would like to reuse the translations provided with libexif,
since most of the strings used in PEL will match the strings from
libexif.

My project, PEL, is licensed under the GPL so as far as I understand
things, it should be allright redistribute the translations from
libexif, but I just wanted to let you guys know anyway.

I've included references to libexif in the README file and the project
homepage to give credits, but let me know if I should do this
differently.

-- 
Martin Geisler                                  My GnuPG Key: 0xF7F6B57B

PHP EXIF Library      |  PhpWeather              |  PhpShell
http://pel.sf.net/    |  http://phpweather.net/  |  http://gimpster.com/
Read/write EXIF data  |  Show current weather    |  A shell in a browser

[Libexif-devel] RE: libexif for win32

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

Roberto,

if you are not interested in using NLS (localized strings),
do the following:
1) rename config.h.in to config.h (note: this file will not
 get exported from CVS, unless you remove it from .cvsignore
 (not tested), but it is in the official downloadable tgz package)
2) append the following lines to config.h (without ====)
=======================================================
// dummy object to make compiler happy
#define GETTEXT_PACKAGE "Patera"

#define strdup _strdup
#define strncasecmp _strnicmp
#define snprintf _snprintf
=======================================================
3) compile & link.

I never tried to use NLS, so I don't know how to use it (on Windows).

 --- Jan

> Great, thanks. Is there anywhere a build file, workspace or at least 
> some instuctions how to compile it on win32 ?  My attempt to use some 
> project-file from an outdated libexif-win32-patch  for the current 
> release ended up in a mess and errors like:
> 
> exif-format.c(53) : error C2065: 'GETTEXT_PACKAGE' : undeclared identifier
> 
> Are there any dependencies on other projects, I need to consider ?
> 
> regards
> Roberto

Re: [Libexif-devel] RE: libexif for win32

[Roberto S. <ro...@sa...>]

Great, thanks. Is there anywhere a build file, workspace or at least 
some instuctions how to compile it on win32 ?  My attempt to use some 
project-file from an outdated libexif-win32-patch  for the current 
release ended up in a mess and errors like:

exif-format.c(53) : error C2065: 'GETTEXT_PACKAGE' : undeclared identifier

Are there any dependencies on other projects, I need to consider ?

regards
Roberto


Jan Patera wrote:

>Yews, I do. In fact, it's the only platform I am using libexif on.
>
> -- Jan
>
>  
>
>>Hi all
>>
>>Has anybody experince with libexif and compiling on win32 MSVC ?
>>
>>regards
>>Roberto
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
>installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Libexif-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libexif-devel
>
>  
>

[Libexif-devel] RE: libexif for win32

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

Yews, I do. In fact, it's the only platform I am using libexif on.

 -- Jan

> Hi all
> 
> Has anybody experince with libexif and compiling on win32 MSVC ?
> 
> regards
> Roberto

[Libexif-devel] libexif for win32

[Roberto S. <ro...@sa...>]

Hi all

Has anybody experince with libexif and compiling on win32 MSVC ?

regards
Roberto

Re: [Libexif-devel] Error handling

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

On Tue, 2004-05-18 at 13:51, Joerg Hoh wrote:
> I think at this moment it would be easier to
> work with return values. The errors I want to catch with this approach are
> relativly "simple" errors like error return values of libc-calls (malloc,
> realloc) and possibly invalid (NULL) arguments. Look at the points in
> functions where at this moment we just do a simple "return". Most times
> it's enough to distinct between "error occured" and "no error".

I had an hour to play with libexif and came up with a proposal for
debugging messages (exif-log.[c,h], try exif --debug
non_existing_file.jpg).

API didn't change. But now you have the possibility to watch what is
going on internally using a callback-function.

While thinking about how that could be used to satisfy your needs, I ran
out of ideas regarding the following question:

At which point does an invalid argument or a failed malloc become fatal?
At libexif level? At the maker note level? I don't think a bug in the
maker note code should let the loading of the ExifData fail. There seems
to never be a 1/0-decision.

Regards

Lutz

Re: [Libexif-devel] Error handling

[Joerg H. <jo...@de...>]

On Tue, May 18, 2004 at 07:20:07AM +0200, Lutz Müller wrote:

> 
> > Why do I have to return a struct when no error occurred?
> 
> I thought about something like that:
> 
> int
> main (...) {
>     int i1, i2;
>     ExifError e = {0, ""};
> 
>     /* Calling a function without error checking */
>     exif_function (i1, i2, NULL);
> 
>     /* Calling a function with error checking */
>     exif_function (i1, i2, &e);
>     if (e.id != 0) 
>         printf ("Error %i occurred: %s.\n", e.id, e.msg);
> }

That would be much work to do; I think at this moment it would be easier to
work with return values. The errors I want to catch with this approach are
relativly "simple" errors like error return values of libc-calls (malloc,
realloc) and possibly invalid (NULL) arguments. Look at the points in
functions where at this moment we just do a simple "return". Most times
it's enough to distinct between "error occured" and "no error".

There we don't need a highly-sophisticated concept how we want to do our
error handling. We just need to detect them. On higher levels a solution
like your proposal would be ok, but on the bottom level it's kind of overkill.

Joerg

-- 
Fachbegriffe der Informatik (Nr 68): WWW
- World Wide Waiting 

Re: [Libexif-devel] Error handling

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

On Mon, 2004-05-17 at 22:39, Joerg Hoh wrote:
> Nope. I don't talk about any kind of interaction with the user on
> application side. I talk about how errors in functions can be detected from
> a calling one.

What does the calling function do with the information 'error occurred'?

> Why do I have to return a struct when no error occurred?

I thought about something like that:

int
main (...) {
    int i1, i2;
    ExifError e = {0, ""};

    /* Calling a function without error checking */
    exif_function (i1, i2, NULL);

    /* Calling a function with error checking */
    exif_function (i1, i2, &e);
    if (e.id != 0) 
        printf ("Error %i occurred: %s.\n", e.id, e.msg);
}

> On high-level
> functions (which will be be called from application side) we can think
> about such a solution, but not on low-level.

As long as the low-level part of the library returns enough information
to enable the user (or the one to whom the user complains) to understand
the problem, I agree with you. Note that at the end of the chain of
calling functions, there is always a user.

Lutz

Re: [Libexif-devel] Error handling

[Joerg H. <jo...@de...>]

On Mon, May 17, 2004 at 08:18:56PM +0200, Lutz Müller wrote:
> On Sun, 2004-05-16 at 16:17, Joerg Hoh wrote:
> > I prefer a to replace at least some void-functions with (signed) int with a
> > standard return value of 1; if an error happens, they will return something
> > != 1 (normally < 1).
> 
> (1) User clicks and empty information shows up.
>     This is the case now.
> 
> (2) User clicks and gets message: "An error occurred."
>     This is your proposal.

Nope. I don't talk about any kind of interaction with the user on
application side. I talk about how errors in functions can be detected from
a calling one.

> (3) User clicks and gets message: "Error xy occurred."
>     Like EXIF_ERROR_CORRUPT_DATA, 
>          EXIF_ERROR_UNKNOWN_FORMAT
> 
> (4) User clicks and gets message: 
>     "Error xy occurred at byte 4711 in EXIF data. 
>      The EXIF data in your image is broken. 
>      Please contact mailing list xyz."
>     Implemented i.e. like
>     void exif_data_load_data (..., ExifResult *result);
>     where 
>     typedef struct {
>         char *msg;
>         ExifError err;
>     } ExifResult;

I don't want to bloat the library. And yes, such a solution would be bloat.
Why do I have to return a struct when no error occurred? How do I allocate
a structure when a malloc(10) failed? Then we should have an error handling
for the error handling...

Returning a simple int in some functions is just enough. On high-level
functions (which will be be called from application side) we can think
about such a solution, but not on low-level.

Joerg

-- 
Fachbegriffe der Informatik (Nr 275): Luster-Format
- Positiv gemeint: Eßfreudig Negativ gemeint: Das Äquivalent von zwei Öltanks

	Alexander Stielau

Re: [Libexif-devel] Error handling

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

On Sun, 2004-05-16 at 16:17, Joerg Hoh wrote:
> I prefer a to replace at least some void-functions with (signed) int with a
> standard return value of 1; if an error happens, they will return something
> != 1 (normally < 1).

(1) User clicks and empty information shows up.
    This is the case now.

(2) User clicks and gets message: "An error occurred."
    This is your proposal.

(3) User clicks and gets message: "Error xy occurred."
    Like EXIF_ERROR_CORRUPT_DATA, 
         EXIF_ERROR_UNKNOWN_FORMAT

(4) User clicks and gets message: 
    "Error xy occurred at byte 4711 in EXIF data. 
     The EXIF data in your image is broken. 
     Please contact mailing list xyz."
    Implemented i.e. like
    void exif_data_load_data (..., ExifResult *result);
    where 
    typedef struct {
        char *msg;
        ExifError err;
    } ExifResult;

When doing error reporting, I'd like to do it in a userfriendly way,
i.e. solution (4) or something better.

Lutz

Re: [Libexif-devel] RE: Error handling

[Joerg H. <jo...@de...>]

On Mon, May 17, 2004 at 10:59:27AM +0200, Jan Patera wrote:
> Hi,
> 
> I strongly agree with this your proposal. I also wanted to do it when
> I was playing with saving last week (I did it just for one function).
> BTW, your following code introduces memory leak:
> 
> > -           *d = realloc (*d, sizeof (char) * *ds);
> > +           *d = realloc (*d, *ds);
> > +           if (!*d)
> > +               return;
> 
> If realloc fails, the pointer originally stored in *d is lost.

Yes, you're right. But since the error handling is broken on this function,
it doesn't make a difference ... :-|

I'll fix it

Joerg

-- 
Fachbegriffe der Informatik (Nr 230): Deadlock
- Einsperren des Admins im Serverraum. 
	Manfred Worm Schäfer

[Libexif-devel] RE: Error handling

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

Hi,

I strongly agree with this your proposal. I also wanted to do it when
I was playing with saving last week (I did it just for one function).
BTW, your following code introduces memory leak:

> -           *d = realloc (*d, sizeof (char) * *ds);
> +           *d = realloc (*d, *ds);
> +           if (!*d)
> +               return;

If realloc fails, the pointer originally stored in *d is lost.

 -- Jan

> I've just doing some review especially on error handling when doing malloc
> and realloc. I think it's not good to declare lot of functions as "void"
> and in case of an error just do a "return;" in that case you canot detect
> errors and behave respectivly.
>
> I prefer a to replace at least some void-functions with (signed) int with
> a standard return value of 1; if an error happens, they will return
> something != 1 (normally < 1).
>
> This will probably produce at lot more if(function()) constructs, but I
> think it's worth.

[Libexif-devel] Error handling

[Joerg H. <jo...@de...>]

Hi

I've just doing some review especially on error handling when doing malloc
and realloc. I think it's not good to declare lot of functions as "void"
and in case of an error just do a "return;" in that case you canot detect
errors and behave respectivly.

I prefer a to replace at least some void-functions with (signed) int with a
standard return value of 1; if an error happens, they will return something
!= 1 (normally < 1).

This will probably produce at lot more if(function()) constructs, but I
think it's worth.

What do you think about that?


Joerg
-- 
Fachbegriffe der Informatik (Nr 78): Kinderpornographie im Internet
- Schwarzer Peter für den nächsten Wahlkampf 
	Florian Kuehnert

Re: [Libexif-devel] Nikon maker note

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

On Mon, 2004-05-10 at 14:32, Jan Patera wrote:
> I've extended support of Nikon maker note in the "Olympus" part,
> where Lutz originally put the first code.

Thank you!

Lutz

[Libexif-devel] Nikon maker note

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

Hi folks,

I've extended support of Nikon maker note in the "Olympus" part,
where Lutz originally put the first code.
It appears there are at least 3 versions of Nikon mnote:
1) IFD with 0x1B items - was confused w/ Pentax-made mnote
2) 'Nikon',0,1,0,IFD
3) 'Nikon',0,2,0,0,0, 8-byte TIFF header, IFD

In addition to that, there are 2 sets of tags:
a) 'Version 1' is used by cases 1)+2)
b) 'Version 2' is used by case 3)
A bad thing is that both sets use the same ids.
Furthermore, while v1 uses SHORT values, v2 uses ASCII values
containing the actual string representations of the numeric values.
To distinguish v1 & v2 tags, MNOTE_NIKON1_TAG_BASE (0x8000)
is added to every tag if reading a v1 file - this is done in
exif_mnote_data_olympus_load().
Some of the tags are explained here:
http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html
most of other tags are work (?) of Serge Droz <ser...@ps...>
who submitted the original code enhancing now obsolete libmnote.
Meaning of many tags remains unknown.
Serge actually implemented case 3) assuming that the mnote IFD uses
the same byte order (MM or II) as the primary exif IFD.
As some examples that I have show, this assumption was not correct.
The patch commited to CVS by Lutz last week was actually a mixture
of cases 2) and 3).

 --- Jan

Re: [Libexif-devel] Compiling from CVS

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

On Mon, 2004-05-03 at 01:11, Antonio Scuri wrote:
> Because this is very inefficient. The function exif_tag_get_name has a 
> loop looking for tag "i" every time is called.
> 

Understood. You are perhaps looking for something like this:

Index: exif-tag.c
===================================================================
RCS file: /cvsroot/libexif/libexif/libexif/exif-tag.c,v
retrieving revision 1.14
diff -u -3 -p -r1.14 exif-tag.c
--- exif-tag.c  6 Aug 2003 19:47:53 -0000       1.14
+++ exif-tag.c  3 May 2004 19:00:58 -0000
@@ -571,6 +571,29 @@ static struct {
        {0, NULL, NULL, NULL}
 };
  
+/* For now, do not use these functions. */
+ExifTag      exif_tag_table_get_tag  (unsigned int n);
+const char  *exif_tag_table_get_name (unsigned int n);
+unsigned int exif_tag_table_count    (void);
+
+ExifTag
+exif_tag_table_get_tag (unsigned int n)
+{
+       return (n < exif_tag_table_count ()) ? ExifTagTable[n].tag : 0;
+}
+
+const char *
+exif_tag_table_get_name (unsigned int n)
+{
+       return (n < exif_tag_table_count ()) ? ExifTagTable[n].name :
NULL;
+}
+
+unsigned int
+exif_tag_table_count (void)
+{
+       return sizeof (ExifTagTable) / sizeof (ExifTagTable[0]);
+}
+
 const char *
 exif_tag_get_name (ExifTag tag)
 {


> > > 5) I have to edit the function exif_entry_initialize from "exif-entry.c".
> > > There are lots of uninitialized tags. I simply replace the function 
> > with my
> > > version. Then saving exif tags in jpeg came back to normal.
> >
> >What is your version? Could you produce a patch against CVS?
> 
>    I checkout from CVS before making those changes. I'm sending the 
> function attached. Just cut and paste.

I don't see where your version differs from the one in CVS.

Regards

Lutz

Re: [Libexif-devel] Compiling from CVS

[Antonio S. <sc...@te...>]

At 17:47 2/5/2004, Lutz M=FCller wrote:
>On Thu, 2004-04-22 at 22:30, Antonio Scuri wrote:
> > 1) Would be very nice to have a function like:
> >
> > const char *
> > exif_tag_get_name_index (unsigned int i, ExifTag *tag)
>
>Why don't you scan like this:
>
>for (i =3D 0; i < 0xffff; i++)
>         if (exif_tag_get_name (i) !=3D NULL)
>                 (...)

   Because this is very inefficient. The function exif_tag_get_name has a=20
loop looking for tag "i" every time is called.

> > 5) I have to edit the function exif_entry_initialize from=
 "exif-entry.c".
> > There are lots of uninitialized tags. I simply replace the function=20
> with my
> > version. Then saving exif tags in jpeg came back to normal.
>
>What is your version? Could you produce a patch against CVS?

   I checkout from CVS before making those changes. I'm sending the=20
function attached. Just cut and paste.

Regards,
scuri

----------------------------------------------------------------
void
exif_entry_initialize (ExifEntry *e, ExifTag tag)
{
         time_t t;
         struct tm *tm;
         ExifRational r;
         ExifByteOrder o;

         /* We need the byte order */
         if (!e || !e->parent || e->data || !e->parent->parent)
                 return;
         o =3D exif_data_get_byte_order (e->parent->parent);

         e->tag =3D tag;
         switch (tag) {

         /* LONG, 1 component, no default */
         case EXIF_TAG_PIXEL_X_DIMENSION:
         case EXIF_TAG_PIXEL_Y_DIMENSION:
         case EXIF_TAG_EXIF_IFD_POINTER:
         case EXIF_TAG_GPS_INFO_IFD_POINTER:
         case EXIF_TAG_INTEROPERABILITY_IFD_POINTER:
         case EXIF_TAG_JPEG_INTERCHANGE_FORMAT_LENGTH:
         case EXIF_TAG_JPEG_INTERCHANGE_FORMAT:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_LONG;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 memset (e->data, 0, e->size);
                 break;

         /* SHORT, 1 component, no default */
         case EXIF_TAG_SUBJECT_LOCATION:
         case EXIF_TAG_SENSING_METHOD:
         case EXIF_TAG_PHOTOMETRIC_INTERPRETATION:
         case EXIF_TAG_COMPRESSION:
         case EXIF_TAG_EXPOSURE_MODE:
         case EXIF_TAG_WHITE_BALANCE:
         case EXIF_TAG_FOCAL_LENGTH_IN_35MM_FILM:
         case EXIF_TAG_GAIN_CONTROL:
         case EXIF_TAG_SUBJECT_DISTANCE_RANGE:
         case EXIF_TAG_FLASH:
         case EXIF_TAG_COLOR_SPACE:


         /* SHORT, 1 component, default 0 */
         case EXIF_TAG_IMAGE_WIDTH:
         case EXIF_TAG_IMAGE_LENGTH:
         case EXIF_TAG_EXPOSURE_PROGRAM:
         case EXIF_TAG_LIGHT_SOURCE:
         case EXIF_TAG_METERING_MODE:
         case EXIF_TAG_CUSTOM_RENDERED:
         case EXIF_TAG_SCENE_CAPTURE_TYPE:
         case EXIF_TAG_CONTRAST:
         case EXIF_TAG_SATURATION:
         case EXIF_TAG_SHARPNESS:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 exif_set_short (e->data, o, 0);
                 break;

         /* SHORT, 1 component, default 1 */
         case EXIF_TAG_ORIENTATION:
         case EXIF_TAG_PLANAR_CONFIGURATION:
         case EXIF_TAG_YCBCR_POSITIONING:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 exif_set_short (e->data, o, 1);
                 break;

         /* SHORT, 1 component, default 2 */
         case EXIF_TAG_RESOLUTION_UNIT:
         case EXIF_TAG_FOCAL_PLANE_RESOLUTION_UNIT:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 exif_set_short (e->data, o, 2);
                 break;

         /* SHORT, 1 component, default 3 */
         case EXIF_TAG_SAMPLES_PER_PIXEL:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 exif_set_short (e->data, o, 3);
                 break;

         case EXIF_TAG_BITS_PER_SAMPLE:
                 e->components =3D 3;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 exif_set_short (e->data, o, 8);
                 exif_set_short (
                         e->data + exif_format_get_size (e->format),
                         o, 8);
                 exif_set_short (
                         e->data + 2 * exif_format_get_size (e->format),
                         o, 8);
                 break;
         case EXIF_TAG_YCBCR_SUB_SAMPLING:
                 e->components =3D 2;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 exif_set_short (e->data, o, 2);
                 exif_set_short (
                         e->data + exif_format_get_size (e->format),
                         o, 1);
                 break;

         /* SHORT, any component, no default */
         case EXIF_TAG_SUBJECT_AREA:
         case EXIF_TAG_ISO_SPEED_RATINGS:
                 e->components =3D 0;
                 e->format =3D EXIF_FORMAT_SHORT;
                 e->size =3D 0;
                 e->data =3D 0;
                 break;

         /* SRATIONAL, 1 component, no default */
         case EXIF_TAG_EXPOSURE_BIAS_VALUE:
         case EXIF_TAG_BRIGHTNESS_VALUE:
         case EXIF_TAG_SHUTTER_SPEED_VALUE:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_SRATIONAL;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 memset (e->data, 0, e->size);
                 break;

         /* RATIONAL, 1 component, no default */
         case EXIF_TAG_EXPOSURE_TIME:
         case EXIF_TAG_FOCAL_PLANE_X_RESOLUTION:
         case EXIF_TAG_FOCAL_PLANE_Y_RESOLUTION:
         case EXIF_TAG_EXPOSURE_INDEX:
         case EXIF_TAG_FLASH_ENERGY:
         case EXIF_TAG_FNUMBER:
         case EXIF_TAG_FOCAL_LENGTH:
         case EXIF_TAG_SUBJECT_DISTANCE:
         case EXIF_TAG_MAX_APERTURE_VALUE:
         case EXIF_TAG_APERTURE_VALUE:
         case EXIF_TAG_COMPRESSED_BITS_PER_PIXEL:
         case EXIF_TAG_PRIMARY_CHROMATICITIES:
         case EXIF_TAG_DIGITAL_ZOOM_RATIO:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_RATIONAL;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 memset (e->data, 0, e->size);
                 break;

         /* RATIONAL, 1 component, default 72/1 */
         case EXIF_TAG_X_RESOLUTION:
         case EXIF_TAG_Y_RESOLUTION:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_RATIONAL;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 r.numerator =3D 72;
                 r.denominator =3D 1;
                 exif_set_rational (e->data, o, r);
                 break;

         /* RATIONAL, 2 components, no default */
         case EXIF_TAG_WHITE_POINT:
                 e->components =3D 2;
                 e->format =3D EXIF_FORMAT_RATIONAL;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 memset (e->data, 0, e->size);
                 break;

         /* RATIONAL, 6 components */
         case EXIF_TAG_REFERENCE_BLACK_WHITE:
                 e->components =3D 6;
                 e->format =3D EXIF_FORMAT_RATIONAL;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 r.denominator =3D 1;
                 r.numerator =3D 0;
                 exif_set_rational (e->data, o, r);
                 r.numerator =3D 255;
                 exif_set_rational (
                         e->data + exif_format_get_size (e->format), o, r);
                 r.numerator =3D 0;
                 exif_set_rational (
                         e->data + 2 * exif_format_get_size (e->format), o,=
 r);
                 r.numerator =3D 255;
                 exif_set_rational (
                         e->data + 3 * exif_format_get_size (e->format), o,=
 r);
                 r.numerator =3D 0;
                 exif_set_rational (
                         e->data + 4 * exif_format_get_size (e->format), o,=
 r);
                 r.numerator =3D 255;
                 exif_set_rational (
                         e->data + 5 * exif_format_get_size (e->format), o,=
 r);
                 break;

         /* EXIF_FORMAT_ASCII, 20 components, default current time */
         case EXIF_TAG_DATE_TIME:
         case EXIF_TAG_DATE_TIME_ORIGINAL:
         case EXIF_TAG_DATE_TIME_DIGITIZED:
                 t =3D time (NULL);
                 tm =3D localtime (&t);
                 e->components =3D 20;
                 e->format =3D EXIF_FORMAT_ASCII;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 snprintf ((char *) e->data, e->size,
                                 "%04i:%02i:%02i %02i:%02i:%02i",
                                 tm->tm_year + 1900, tm->tm_mon,=
 tm->tm_mday,
                                 tm->tm_hour, tm->tm_min, tm->tm_sec);
                 break;

         /* EXIF_FORMAT_ASCII, 13 components */
         case EXIF_TAG_RELATED_SOUND_FILE:
                 e->components =3D 13;
                 e->format =3D EXIF_FORMAT_ASCII;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 break;

         case EXIF_TAG_IMAGE_UNIQUE_ID:
                 e->components =3D 33;
                 e->format =3D EXIF_FORMAT_ASCII;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 break;

         /* EXIF_FORMAT_ASCII, any components, no default */
         case EXIF_TAG_SPECTRAL_SENSITIVITY:
         case EXIF_TAG_SUB_SEC_TIME:
         case EXIF_TAG_SUB_SEC_TIME_ORIGINAL:
         case EXIF_TAG_SUB_SEC_TIME_DIGITIZED:
         case EXIF_TAG_IMAGE_DESCRIPTION:
         case EXIF_TAG_MAKE:
         case EXIF_TAG_MODEL:
         case EXIF_TAG_SOFTWARE:
         case EXIF_TAG_ARTIST:
         case EXIF_TAG_COPYRIGHT:
                 e->components =3D 0;
                 e->format =3D EXIF_FORMAT_ASCII;
                 e->size =3D 0;
                 e->data =3D 0;
                 break;

         /* UNDEFINED, any components, no default */
         case=20
EXIF_TAG_OECF:=20

         case EXIF_TAG_SPATIAL_FREQUENCY_RESPONSE:
         case EXIF_TAG_NEW_CFA_PATTERN:
         case EXIF_TAG_DEVICE_SETTING_DESCRIPTION:
         case EXIF_TAG_MAKER_NOTE:
         case EXIF_TAG_USER_COMMENT:
                 e->components =3D 0;
                 e->format =3D EXIF_FORMAT_UNDEFINED;
                 e->size =3D 0;
                 e->data =3D 0;
                 break;

         /* UNDEFINED, 1 component, default 1 */
         case EXIF_TAG_SCENE_TYPE:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_UNDEFINED;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 e->data[0] =3D 0x01;
                 break;

         /* UNDEFINED, 1 component, default 3 */
         case EXIF_TAG_FILE_SOURCE:
                 e->components =3D 1;
                 e->format =3D EXIF_FORMAT_UNDEFINED;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 e->data[0] =3D 0x03;
                 break;

         /* UNDEFINED, 4 components, default 0 1 0 0 */
         case EXIF_TAG_FLASH_PIX_VERSION:
                 e->components =3D 4;
                 e->format =3D EXIF_FORMAT_UNDEFINED;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 memcpy (e->data, "0100", 4);
                 break;

         /* UNDEFINED, 4 components, default 0 2 1 0 */
         case EXIF_TAG_EXIF_VERSION:
                 e->components =3D 4;
                 e->format =3D EXIF_FORMAT_UNDEFINED;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 memcpy (e->data, "0210", 4);
                 break;

         /* UNDEFINED, 4 components, no default */
         case EXIF_TAG_COMPONENTS_CONFIGURATION:
                 e->components =3D 4;
                 e->format =3D EXIF_FORMAT_UNDEFINED;
                 e->size =3D exif_format_get_size (e->format) *=
 e->components;
                 e->data =3D malloc (e->size);
                 break;

         default:
                 break;
         }
}
----------------------------------------------------------------

Re: [Libexif-devel] Compiling from CVS

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

On Thu, 2004-04-22 at 22:30, Antonio Scuri wrote:
> 1) Would be very nice to have a function like:
>=20
> const char *
> exif_tag_get_name_index (unsigned int i, ExifTag *tag)

Why don't you scan like this:=20

for (i =3D 0; i < 0xffff; i++)
	if (exif_tag_get_name (i) !=3D NULL)
		(...)

> 2) The file "exif-data.c" depends on the header file "jpeg-marker.h" th=
at=20
> it is in the pack, but outside the library folder. Why not to move this=
=20
> header to the libexif folder?

Actually, the include statement can be replaced by 2 defines
(JPEG_MARKER_*). Patches are welcome.

>=20
>   Also Open Watcom complained about it:
>=20
> libjpeg/jpeg-marker.h(27): Error! E1115: Incomplete enum declaration
>=20
>    I change to the old version.

Fixed.

> 3) I created a simple "_stdint.h" by hand from Cygwin "stdint.h", all t=
he=20
> platforms I use the types used have fixed sizes. The "_stdint.h" is a g=
ood=20
> solution for the library users.

I am not sure but I think people are currently trying to fix that (or
have already been done it).

> 4) I still use the same "config.h" that I mention before:
>=20
> #define GETTEXT_PACKAGE "libexif-9"
>=20
> #ifdef WIN32
> #define snprintf _snprintf
> #endif

On my system, config.h gets created by autoheader. I am not sure what
the official (GNU whatever) way is for handling this on WIN32.

> 5) I have to edit the function exif_entry_initialize from "exif-entry.c=
".=20
> There are lots of uninitialized tags. I simply replace the function wit=
h my=20
> version. Then saving exif tags in jpeg came back to normal.

What is your version? Could you produce a patch against CVS?

Regards

Lutz M=FCller

[Libexif-devel] Compiling from CVS

[Antonio S. <sc...@te...>]

   Hi,

   Since I did not find the 0.6.9 tar I updated from CVS to compile it and=
=20
here are some comments:

1) Would be very nice to have a function like:

const char *
exif_tag_get_name_index (unsigned int i, ExifTag *tag)
{
   if (!ExifTagTable[i].name)
     return NULL;

   *tag =3D ExifTagTable[i].tag;

	return (ExifTagTable[i].name);
}

   in "exif-tag.c". It allows me to scan over all the defined tags.

2) The file "exif-data.c" depends on the header file "jpeg-marker.h" that=20
it is in the pack, but outside the library folder. Why not to move this=20
header to the libexif folder?

  Also Open Watcom complained about it:

libjpeg/jpeg-marker.h(27): Error! E1115: Incomplete enum declaration

   I change to the old version.

3) I created a simple "_stdint.h" by hand from Cygwin "stdint.h", all the=20
platforms I use the types used have fixed sizes. The "_stdint.h" is a good=
=20
solution for the library users.

4) I still use the same "config.h" that I mention before:

#define GETTEXT_PACKAGE "libexif-9"

#ifdef WIN32
#define snprintf _snprintf
#endif

5) I have to edit the function exif_entry_initialize from "exif-entry.c".=20
There are lots of uninitialized tags. I simply replace the function with my=
=20
version. Then saving exif tags in jpeg came back to normal.

   That=B4s it. This is working in Windows (gcc3, Mingw3, OpenWatcom, VC6=
 and=20
VC7) and in UNIX (Linux, IRIX, AIX and SunOS).  libexif is used internally=
=20
by an also free library called IM. I updated the library this month. You=20
may find it at:

       http://www.tecgraf.puc-rio.br/im

   Issues 1 and 2 are not a big deal, but I would appreciate if you guys=20
can think about issue 5. I can send you my version of the function attached.

Best,
scuri

[Libexif-devel] Re: MSVC

[Antonio S. <sc...@te...>]

At 19:08 6/4/2004, Hans Ulrich Niedermann wrote:
>BTW, how are you compiling libexif with MSVC? On unixoid systems, you
>run
>        ./configure
>         make
>         make install
>
>On Windows, you don't have a shell to execute configure, so how do you
>do that?

   In my case, I have Cygwin installed. I ran "bash" then "./configure" 
just to get a "config.h" file. Then I cleaned and adjusted the "config.h" 
to meet my needs.

   In fact it is really simple:

#define GETTEXT_PACKAGE "libexif-9"

#ifdef WIN32
#define snprintf _snprintf
#endif

   Then I use it to compile the libexif in Visual C++ with a standard 
project, and I also use it in many Unices: Linux, IRIX, SunOS and AIX.

   I tested my application only in Windows up to now. But soon I will test 
it in UNIX to check the exif tags with libjpeg. With version 0.7 I will try 
to extract tags together with libTIFF.

Best,
Antonio Scuri