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

Re: [Libexif-devel] markernote update

[Hubert F. <hfi...@te...>]

Lutz M=FCller wrote:
> On Fri, 2005-06-17 at 22:34 +0200, matthieu castet wrote:
>=20
>>With this doc, it is possible to improve libexif makernote parsing.
>=20
>=20
> Hello Matthieu!
>=20
> I've added the link to the README file. Feel free to submit patches
> (even if only small ones). It is not difficult, you just need some spar=
e
> time.
>=20
Actually perl Image::ExifTool module has lot of things that might be=20
worth to port over.

Hub

Re: [Libexif-devel] libexif for raw images

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

On Fri, 2005-06-17 at 12:02 +0200, Udi Fuchs wrote:
> The patch is already Incorporated in UFRaw's CVS. I'm attaching
> ufraw_exif.c, so you won't need to check out ufraw from the cvs.

I'd like to move that code into libexif. However, I'd like to avoid a
dependency on libtiff. Do you know the TIFF file format? How do I
navigate through the start of the file

4D 4D 00 2A 00 00 00 08 00 18 00 FE 00 04 00 00 00 01 00 00 00 01 00 ...

in order to find the EXIF information?

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

Re: [Libexif-devel] markernote update

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

On Fri, 2005-06-17 at 22:34 +0200, matthieu castet wrote:
> With this doc, it is possible to improve libexif makernote parsing.

Hello Matthieu!

I've added the link to the README file. Feel free to submit patches
(even if only small ones). It is not difficult, you just need some spare
time.

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

Re: [Libexif-devel] Re: ICC profile API?

[Hubert F. <hfi...@te...>]

Ross Burton wrote:

> I'd really like to see gdk-pixbuf expose the ICC profile for any image
> file directly, so that applications can access it easily and calibrate
> it.  I'd also like to see the ICC profile setter integrated into
> gnome-settings-daemon, but this would probably require the forever put
> off rewrite of the Resolution capplet.

I'd really love to have some standard to have this managed in a 
cross-desktop way. Since xicc seems to do stuff on top of X, we can 
juste try to establish a standard so that whatever the user use, KDE or 
GNOME, it will be able to have an ICC profile for it.

Beside that, extracting ICC profiles with libexif seems to be doable.

> The specification for embedding ICC in JPEGs (etc) is in section B5 of
> http://www.color.org/ICC1V42.pdf.  Basically its in an APP2 section,
> with the string "ICC_PROFILE\0" and a sequence byte attached.

Thanks. Reading that too.

I think we are slipping out of topic for libexif :-)

Hub

[Libexif-devel] Re: ICC profile API?

[Ross B. <ro...@bu...>]

Hubert wrote:
> Ross Burton wrote:
> > I"m trying to build the pieces required so that a normal X desktop can
> > display colour-calibrated images [1].  So far I"ve got a tool which sets
> > a property on the root window containing the ICC profile for the screen,
> > and a growing patch to Eye Of Gnome which extracts any ICC profile or
> > calibration data and uses Little CMS to correct the image before
> > display.
>
> Really interesting. Any plan integrating that in GNOME ? :-)

Funny you should ask that, Hub. ;)

I'd really like to see gdk-pixbuf expose the ICC profile for any image
file directly, so that applications can access it easily and calibrate
it.  I'd also like to see the ICC profile setter integrated into
gnome-settings-daemon, but this would probably require the forever put
off rewrite of the Resolution capplet.

> > As EoG is using libexif to read the EXIF file, and reading ICC profiles
> > is very similar to reading EXIF chunks, I was wondering if the libexif
> > developers would consider adding support for ICC profiles to the API?
> > An ICC profile is stored in JPEG files as a set of APP2 chunks, which
> > start with "ICC_PROFILE\0" followed by a sequence number.
> > 
> > If you think this is a good idea I"ll happily try and come up with an
> > API design and then a patch, but I wanted to have your feedback before
> > starting.
> 
> Shoudln"t be a problem. Where is that documented ? I missed something.

The specification for embedding ICC in JPEGs (etc) is in section B5 of
http://www.color.org/ICC1V42.pdf.  Basically its in an APP2 section,
with the string "ICC_PROFILE\0" and a sequence byte attached.

Ross
-- 
Ross Burton                                 mail: ro...@bu...
                                          jabber: ro...@bu...
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Re: [Libexif-devel] ICC profile API?

[Hubert F. <hfi...@te...>]

Ross Burton wrote:

> I'm trying to build the pieces required so that a normal X desktop can
> display colour-calibrated images [1].  So far I've got a tool which sets
> a property on the root window containing the ICC profile for the screen,
> and a growing patch to Eye Of Gnome which extracts any ICC profile or
> calibration data and uses Little CMS to correct the image before
> display.

Really interesting. Any plan integrating that in GNOME ? :-)

> As EoG is using libexif to read the EXIF file, and reading ICC profiles
> is very similar to reading EXIF chunks, I was wondering if the libexif
> developers would consider adding support for ICC profiles to the API?
> An ICC profile is stored in JPEG files as a set of APP2 chunks, which
> start with "ICC_PROFILE\0" followed by a sequence number.
> 
> If you think this is a good idea I'll happily try and come up with an
> API design and then a patch, but I wanted to have your feedback before
> starting.

Shoudln't be a problem. Where is that documented ? I missed something.


Hub

[Libexif-devel] ICC profile API?

[Ross B. <ro...@bu...>]

Hi,

I'm trying to build the pieces required so that a normal X desktop can
display colour-calibrated images [1].  So far I've got a tool which sets
a property on the root window containing the ICC profile for the screen,
and a growing patch to Eye Of Gnome which extracts any ICC profile or
calibration data and uses Little CMS to correct the image before
display.

As EoG is using libexif to read the EXIF file, and reading ICC profiles
is very similar to reading EXIF chunks, I was wondering if the libexif
developers would consider adding support for ICC profiles to the API?
An ICC profile is stored in JPEG files as a set of APP2 chunks, which
start with "ICC_PROFILE\0" followed by a sequence number.

If you think this is a good idea I'll happily try and come up with an
API design and then a patch, but I wanted to have your feedback before
starting.

Thanks,
Ross

[1] http://www.burtonini.com/blog//computers/eog-icc-2005-06-16-09-57
-- 
Ross Burton                                 mail: ro...@bu...
                                          jabber: ro...@bu...
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

[Libexif-devel] markernote update

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

Hi,

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html have 
lot's of tag that not supported by libexif.

With this doc, it is possible to improve libexif makernote parsing.


Matthieu

Re: [Libexif-devel] libexif for raw images

[Udi F. <udi...@gm...>]

> Could you post the patch on this list?
The patch is already Incorporated in UFRaw's CVS. I'm attaching
ufraw_exif.c, so you won't need to check out ufraw from the cvs. You
can compile it with the command:

cc -D_STAND_ALONE_ -DHAVE_LIBEXIF -o ufraw-exif ufraw_exif.c -lexif
-ljpeg -ltiff -lz

> Could you make available some test images?

You can download (notice that it is 6MB big):

http://ufraw.sourceforge.net/dsc_0113.nef

Then 'ufraw-exif dsc_0113.nef' will show you the exif data and mnotes
that libexif recognized in this file.

You can also 'ufraw-exif dsc_0113.nef a.jpg', where a.jpg is any jpg
file you have. Then you can see with 'exif a.jpg' that the basic
exif-data was saved correctly, but not the maker-notes.

Udi

Re: [Libexif-devel] libexif for raw images

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

On Thu, 2005-06-16 at 16:33 +0200, Udi Fuchs wrote:
> I got a patch for reading the EXIF data from some raw format. It uses
> libtiff and libexif and it is base on the fact that some raw file are
> actually TIFF files (Nikon NEF, Canon CR2, Pentax PEF).

Could you post the patch on this list?

> 2. I can read the MakerNotes, but if I try "exif --show-mnote" on the
> generated JPG file, it seems that it contains no information.

Could you make available some test images?

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

[Libexif-devel] libexif for raw images

[Udi F. <udi...@gm...>]

Hi,

I'm the author of UFRaw (http://ufraw.sourceforge.net/), which is a
tool for converting raw images from digital camera, based on DCRaw.

I got a patch for reading the EXIF data from some raw format. It uses
libtiff and libexif and it is base on the fact that some raw file are
actually TIFF files (Nikon NEF, Canon CR2, Pentax PEF).

I merged this code into the development version of UFRaw, which can be
checked-out from the CVS. I have the following issues with this patch:

1. The code looks like a hack to make libexif read the TIFF file.
Isn't there a more natural way for libexif to read TIFF files?

2. I can read the MakerNotes, but if I try "exif --show-mnote" on the
generated JPG file, it seems that it contains no information. The
output is:
MakerNote contains 43 values:
Firmware Version: Firmware Version
ISO Setting: ISO Setting
Quality: Quality
Whitebalance: Whitebalance
...
The problem is in the generated JPG and not in the original raw file,
since using 'ufraw-exif' (see later on) I get these fields correctly.

3. Other raw format are not TIFF files, but have somewhat similar
format. Could there be a "simple" way to generalize this code for
these files?

Could you look at the code, and tell me what you think of it? To
simplify your lives I created also a small stand-alone version. After
the cvs checkout you need to:
./autogen.sh
./configure --enable-extras
make
This will create an extra executable 'ufraw-exif' which is based only
on ufraw_exif.c, so you don't need to look at any of the other ufraw
source files. It's usage is very simple:

usage: ufraw-exif input-file.raw [output-file.jpg]
ufraw-exif dumps the EXIF data from the RAW file to stdout.
If a JPEG file is specified, the EXIF data is copied to it.
This overwrites the original JPEG, so make sure you have a backup for it.

I can also send people some sample RAW files on demand.

Udi

Re: [Libexif-devel] Character sets in libexif, exif, GTK and otherapplications

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

> Lutz M=C3=BCller <lu...@us...> writes:
>> What about creating a
>> libexif/exif-config.h file with those variables?
>>
>> /*
>>  * You need to call bindtextdomain & friends first
>>  * with those variables if you would like to
>>  * get proper translations.
>>  */
>> #define EXIF_GETTEXT_PACKAGE "libexif-12"
>> #define EXIF_GETTEXT_LOCALEDIR "/some/path"
>>
>> /* Name, version... */
>> #define EXIF_PACKAGE_NAME "..."
>> #define EXIF_PACKAGE_VERSION "..."
>
> Bad idea. What if any of these values changes from one library version
> to another? You would have to recompile (relink doesn't help here) all
> applications.

Ok. Then what about:

const char *exif_gettext_package (void);
const char *exif_gettext_localedir (void);

const char *exif_package_name (void);
const char *exif_package_version (void);

?

Lutz

Re: [Libexif-devel] Character sets in libexif, exif, GTK and other applications

[Hans U. N. <gp...@n-...>]

Lutz M=C3=BCller <lu...@us...> writes:

> On Tue, 2005-05-03 at 13:03 +0200, Hans Ulrich Niedermann wrote:
>> > I don't like the static variable in exif_init_gettext at all. Is
>>=20
>> (Note for reference: "static" means "global" here.)
>>=20
>> Why don't you like it?
>
> They are evil in combination with threads. glibc does proper locking, so
> let's glibc take care of that.

Sounds good :-)

>> > "bindtextdomain" that expensive that we can't call it in every function
>> > that returns strings?
>>=20
>> IMHO, yes. It has to search the filesystem for files.
>
> As far as I can see in glibc/intl/bindtextdom.c, it first checks if the
> value changed.

Then a simple wrapper function without any variable checks will do.

> Anyways, everything the frontend needs to know in order to get proper
> translation is GETTEXT_PACKAGE and LOCALEDIR. What about creating a
> libexif/exif-config.h file with those variables?
>
> /*=20
>  * You need to call bindtextdomain & friends first=20
>  * with those variables if you would like to=20
>  * get proper translations.
>  */=20
> #define EXIF_GETTEXT_PACKAGE "libexif-12"
> #define EXIF_GETTEXT_LOCALEDIR "/some/path"
>
> /* Name, version... */
> #define EXIF_PACKAGE_NAME "..."
> #define EXIF_PACKAGE_VERSION "..."

Bad idea. What if any of these values changes from one library version
to another? You would have to recompile (relink doesn't help here) all
applications.

Uli

Re: [Libexif-devel] Character sets in libexif, exif, GTK and other applications

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

On Tue, 2005-05-03 at 13:03 +0200, Hans Ulrich Niedermann wrote:
> > I don't like the static variable in exif_init_gettext at all. Is
>=20
> (Note for reference: "static" means "global" here.)
>=20
> Why don't you like it?

They are evil in combination with threads. glibc does proper locking, so
let's glibc take care of that.
=20
> > "bindtextdomain" that expensive that we can't call it in every functi=
on
> > that returns strings?
>=20
> IMHO, yes. It has to search the filesystem for files.

As far as I can see in glibc/intl/bindtextdom.c, it first checks if the
value changed.

Anyways, everything the frontend needs to know in order to get proper
translation is GETTEXT_PACKAGE and LOCALEDIR. What about creating a
libexif/exif-config.h file with those variables?

/*=20
 * You need to call bindtextdomain & friends first=20
 * with those variables if you would like to=20
 * get proper translations.
 */=20
#define EXIF_GETTEXT_PACKAGE "libexif-12"
#define EXIF_GETTEXT_LOCALEDIR "/some/path"

/* Name, version... */
#define EXIF_PACKAGE_NAME "..."
#define EXIF_PACKAGE_VERSION "..."


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

[Libexif-devel] Strange C syntax

[Hans U. N. <gp...@n-...>]

I removed the functions containing this code because
 a) some C compilers do not understand it
 b) it is code duplication

But I'd still like to know where this kind of syntax is defined?
Originally C++ and now C99?

I've never seen something like this before:

	return
		exif_tag_get_name_in_ifd (tag, EXIF_IFD_0) ? :
		exif_tag_get_name_in_ifd (tag, EXIF_IFD_1) ? :
		exif_tag_get_name_in_ifd (tag, EXIF_IFD_EXIF) ? :
		exif_tag_get_name_in_ifd (tag, EXIF_IFD_INTEROPERABILITY) ? :
		exif_tag_get_name_in_ifd (tag, EXIF_IFD_GPS);

Re: [Libexif-devel] Character sets in libexif, exif, GTK and other applications

[Hans U. N. <gp...@n-...>]

Lutz M=C3=BCller <lu...@us...> writes:

> On Mon, 2005-05-02 at 20:33 +0200, Hans Ulrich Niedermann wrote:
>> Then libexif must tell the frontend the gettext domain libexif uses,
>> which IMHO isn't the frontend's business.
>> const char *exif_set_message_codeset(const char *codeset)
>> const char *exif_init_gettext(void)
>
> I don't like the static variable in exif_init_gettext at all. Is

(Note for reference: "static" means "global" here.)

Why don't you like it?

bindtextdomain() itself affects global settings by definition.

So having a global flag saying whether we initialized all that global
stuff yet or not makes sense, IMHO.

> "bindtextdomain" that expensive that we can't call it in every function
> that returns strings?

IMHO, yes. It has to search the filesystem for files.

> If people would like to optimize libexif for
> speed, they'd compile libexif without NLS anyways.=20

Or do things which need to be done once only once instead of dozens of
times. Apart from that, some of those i18n functions are a little
picky when being called multiple times in the same program.

Uli

Re: [Libexif-devel] Character sets in libexif, exif, GTK and other applications

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

On Mon, 2005-05-02 at 20:33 +0200, Hans Ulrich Niedermann wrote:
> Then libexif must tell the frontend the gettext domain libexif uses,
> which IMHO isn't the frontend's business.
> const char *exif_set_message_codeset(const char *codeset)
> const char *exif_init_gettext(void)

I don't like the static variable in exif_init_gettext at all. Is
"bindtextdomain" that expensive that we can't call it in every function
that returns strings? If people would like to optimize libexif for
speed, they'd compile libexif without NLS anyways.=20

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

Re: [Libexif-devel] Character sets in libexif, exif, GTK and other applications

[Hans U. N. <gp...@n-...>]

Lutz M=C3=BCller <lu...@us...> writes:

> On Mon, 2005-05-02 at 13:37 +0200, Hans Ulrich Niedermann wrote:
>> This will make libexif return all strings in UTF-8 regardless of the
>> current locale.
>> This would mean that we should add an additional function to libexif
>> which allows such libexif users (libexif-gtk, gexif, or any other
>> software which requires UTF-8) to explicitly request UTF-8.
>> Is this correct?
>
> There are lots of functions that return translated strings. Wouldn't it
> be easier to remove the calls to "bind_textdomain_codeset" and leave the
> task of calling this function to the frontends?

Then libexif must tell the frontend the gettext domain libexif uses,
which IMHO isn't the frontend's business.

I'd like to propose this (if it makes sense):

/**(exported function)
 * Explicitly set the codeset for translated libexif messages.
 *
 * @codeset The character set to use. "UTF-8" is guaranteed to work.
 * @returns The return value of bind_textdomain_codeset(3)
 *
 * Constraints:
 * - Requires a gettext supporting bind_textdomain_codeset()
 * - Must be called before all other libexif functions
 **/
=20
const char *exif_set_message_codeset(const char *codeset) {
	const char *result =3D
#ifdef HAVE_BIND_TEXTDOMAIN_CODESET
        	bind_textdomain_codeset(GETTEXT_DOMAIN, codeset);
#else
                (const char *) NULL;
#endif
        exif_init_gettext();
        return result;
}

/**(libexif internal function)
 * Initialize the message translation system.
 *
 * @returns The return value of bindtextdomain(3)
 *
 * This function must be called by an exported libexif function
 * before any libexif function translates any messages.
 **/

const char *exif_init_gettext(void) {
        static char *basedir =3D NULL;
	if (basedir =3D=3D NULL) {
        	initialized =3D 1;
                basedir =3D bindtextdomain(GETTEXT_DOMAIN, LOCALEDIR);
        }
        return basedir;
}

Re: [Libexif-devel] Character sets in libexif, exif, GTK and other applications

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

On Mon, 2005-05-02 at 13:37 +0200, Hans Ulrich Niedermann wrote:
> This will make libexif return all strings in UTF-8 regardless of the
> current locale.
> This would mean that we should add an additional function to libexif
> which allows such libexif users (libexif-gtk, gexif, or any other
> software which requires UTF-8) to explicitly request UTF-8.
> Is this correct?

There are lots of functions that return translated strings. Wouldn't it
be easier to remove the calls to "bind_textdomain_codeset" and leave the
task of calling this function to the frontends?

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

[Libexif-devel] Character sets in libexif, exif, GTK and other applications

[Hans U. N. <gp...@n-...>]

Hi,

in CVS, libexif calls

   bind_textdomain_codeset(GETTEXT_DOMAIN, "UTF-8")

every time before it calls

   bindtextdomain (GETTEXT_PACKAGE, LOCALEDIR);

This will make libexif return all strings in UTF-8 regardless of the
current locale.

This, in turn, will break all libexif message output on non-UTF-8
output media, such as iso-8859-1 terminals running exif, which is not
good.

As the default output character set is the one the locale specifies,
if we don't call bind_textdomain_codeset() in libexif at all, exif
will always produce proper output for the respective locale.

However, I think I remember that GTK (and pango or whatever the one of
100 GTK sub libraries in question is called) requires all strings it
is to print to be UTF-8.

This would mean that we should add an additional function to libexif
which allows such libexif users (libexif-gtk, gexif, or any other
software which requires UTF-8) to explicitly request UTF-8.

Is this correct?

Uli

Re: [Libexif-devel] Re: [libexif-cvs] libexif/libexifexif-data.c, 1.77,1.78 exif-tag.c,1.24,1.25 exif-tag.h,1.12,1.13

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

> I suppose then there is no specific reason to use 1,2,3,5,6, leaving
> out the 4, either.

Right.

Lutz

Re: [Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-data.c,1.77,1.78 exif-tag.c,1.24,1.25 exif-tag.h,1.12,1.13

[Hans U. N. <gp...@n-...>]

Lutz M=C3=BCller <lu...@us...> writes:

> On Wed, 2005-04-27 at 17:09 +0200, Hans Ulrich Niedermann wrote:
>> > Who defines these constants?
>>=20
>> That is meant as in "us or the EXIF specs?"
>
> EXIF spec. Some tags must/can be present in EXIF data, others must not
> be present in some IFDs, others must/can be present if certain
> conditions are met.

OK, of course the EXIF specs define what tags are optional, but it is
*us* who defines the values of the ESL_* constants.

>> > I'm just asking because this breaks
>> > binary compatibility. (ESL_NOT_RECORDED now 6 instead of 4, and 4 is
>> > not used any more).
>
> Why does the change break binary compatibility? The values are defined
> and used only inside exif-tag.c.

I guess then it is not a problem.

I suppose then there is no specific reason to use 1,2,3,5,6, leaving
out the 4, either.

Uli

Re: [Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-data.c,1.77,1.78 exif-tag.c,1.24,1.25 exif-tag.h,1.12,1.13

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

On Wed, 2005-04-27 at 17:09 +0200, Hans Ulrich Niedermann wrote:
> > Who defines these constants?
>=20
> That is meant as in "us or the EXIF specs?"

EXIF spec. Some tags must/can be present in EXIF data, others must not
be present in some IFDs, others must/can be present if certain
conditions are met.

> > I'm just asking because this breaks
> > binary compatibility. (ESL_NOT_RECORDED now 6 instead of 4, and 4 is
> > not used any more).

Why does the change break binary compatibility? The values are defined
and used only inside exif-tag.c.
--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-data.c,1.77,1.78 exif-tag.c,1.24,1.25 exif-tag.h,1.12,1.13

[Hans U. N. <gp...@n-...>]

Hans Ulrich Niedermann <gp...@n-...> writes:

> Lutz M=C3=BCller <lu...@us...> writes:
>
>> Index: exif-tag.c
>> =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=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> RCS file: /cvsroot/libexif/libexif/libexif/exif-tag.c,v
>> retrieving revision 1.24
>> retrieving revision 1.25
>> diff -u -p -d -r1.24 -r1.25
>> --- exif-tag.c	24 Apr 2005 19:01:12 -0000	1.24
>> +++ exif-tag.c	26 Apr 2005 20:17:46 -0000	1.25
>> @@ -30,7 +30,8 @@ typedef enum {
>>  	ESL_MANDATORY    =3D 1, /* Mandatory               */
>>  	ESL_CMANDATORY   =3D 2, /* Conditionally mandatory */
>>  	ESL_OPTIONAL     =3D 3, /* Optional                */
>> -	ESL_NOT_RECORDED =3D 4  /* Not recorded            */
>> +	ESL_COPTIONAL    =3D 5, /* Conditionally optional  */
>> +	ESL_NOT_RECORDED =3D 6  /* Not recorded            */
>>  } ExifSL;                     /* Exif Support Level      */
>
> Who defines these constants?

That is meant as in "us or the EXIF specs?"

> I'm just asking because this breaks
> binary compatibility. (ESL_NOT_RECORDED now 6 instead of 4, and 4 is
> not used any more).

[Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-data.c,1.77,1.78 exif-tag.c,1.24,1.25 exif-tag.h,1.12,1.13

[Hans U. N. <gp...@n-...>]

Lutz M=C3=BCller <lu...@us...> writes:

> Index: exif-tag.c
> =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=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/libexif/libexif/libexif/exif-tag.c,v
> retrieving revision 1.24
> retrieving revision 1.25
> diff -u -p -d -r1.24 -r1.25
> --- exif-tag.c	24 Apr 2005 19:01:12 -0000	1.24
> +++ exif-tag.c	26 Apr 2005 20:17:46 -0000	1.25
> @@ -30,7 +30,8 @@ typedef enum {
>  	ESL_MANDATORY    =3D 1, /* Mandatory               */
>  	ESL_CMANDATORY   =3D 2, /* Conditionally mandatory */
>  	ESL_OPTIONAL     =3D 3, /* Optional                */
> -	ESL_NOT_RECORDED =3D 4  /* Not recorded            */
> +	ESL_COPTIONAL    =3D 5, /* Conditionally optional  */
> +	ESL_NOT_RECORDED =3D 6  /* Not recorded            */
>  } ExifSL;                     /* Exif Support Level      */

Who defines these constants? I'm just asking because this breaks
binary compatibility. (ESL_NOT_RECORDED now 6 instead of 4, and 4 is
not used any more).

Uli