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

Re: [Libexif-devel] config.h file

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

On Wed, Feb 25, 2009 at 06:00:13PM -0800, Benny Smith wrote:
> In several of the files in libexif, an include statement is made:  #include
> <config.h>
> 
> What does this file accomplish?

It holds configuration information about the compiler, library and
architecture that you're building for.

> I cannot find it in the libexif package? libexif -0.6.17?.
> 
> I see a file labeled ?config.h.in?.  Is that related?

It is one of the inputs used by autoconf to generate the config.h file.
The file is created as part of the process of running ./configure before
you compile the library.  If you're not compiling on a POSIX system that
can run ./configure, you'll have to create your own config.h file manually.

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

[Libexif-devel] config.h file

[Benny S. <ich...@pa...>]

In several of the files in libexif, an include statement is made:  #include
<config.h>

 

What does this file accomplish?

 

I cannot find it in the libexif package" libexif -0.6.17".

 

I see a file labeled "config.h.in".  Is that related?

 

Benny Smith

Re: [Libexif-devel] Understanding libjpeg and libexif

[Benny S. <ich...@pa...>]

Dan,

Would the following approach work for writing new data to the Exif header of
a JPG file:

Open the JPG file and copy the top 64 KB to RAM. (According to the Exif
Standard, this should capture all of the Exif header).

Apply the appropriate libexif functions to parse and alter the pertinent
data in the Exif header.

Write the revised Exif header back into the JPG file starting at the correct
memory address so that the header fits the exact space from which it was
copied earlier.

Close the JPG file and read it with a commercial Exif header reader.

This approach would bypass the libjpeg library functions.

Eh?

Benny Smith

-----Original Message-----
From: Dan Fandrich [mailto:da...@co...] 
Sent: Tuesday, February 24, 2009 9:44 PM
To: lib...@li...
Subject: Re: [Libexif-devel] Understanding libjpeg and libexif

On Tue, Feb 24, 2009 at 05:27:02PM -0800, Benny Smith wrote:
> I am still trying to understand how to open a JPEG file, extract the Exif
> header, add data to or change data in the Exif header, and then write the
> header back to the JPEG file so that it can be read by ExifPilot or some
other
> PC application to confirm that the data was written as intended.
> 
> The documentation at http://libexif.sourceforge.net/api/ is good and I
have

I'm glad you're finding it useful.

> studied some of the sample programs.  I have not figured out how to
structure
> data that I want to store in the Exif header into the correct format for
one of
> the libexif functions to accept it.

As you've discovered, there aren't any sample programs to show how to write
EXIF data to an image--it's on my list of things to do.  Creating EXIF data
to add to an image is easy--it's a matter of calling exif_data_new(),
exif_data_set_data_type() and exif_data_fix()-- writing it into the
proper place in a JPEG file isn't. libjpeg used to be a part of libexif,
but it got moved out into the exif front-end, presumably because it
wasn't strictly necessary for EXIF parsing.

> Can anyone tell me where I can learn to do that?
>
> I cannot find the equivalent API documentation for the libjpeg file
> jpeg-data.c and all of the functions therein.  Can you tell me where
> to find it?

Nobody has gotten around yet to documenting the libjpeg functions as the
libexif ones are.  Until that happens, you're on your own!  Take a look
at the exif front-end code, though. As long as you trace through
the code for a single option (like create_exif) it's reasonably
straightforward to see what's going on.

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

----------------------------------------------------------------------------
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Understanding libjpeg and libexif

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

On Tue, Feb 24, 2009 at 05:27:02PM -0800, Benny Smith wrote:
> I am still trying to understand how to open a JPEG file, extract the Exif
> header, add data to or change data in the Exif header, and then write the
> header back to the JPEG file so that it can be read by ExifPilot or some other
> PC application to confirm that the data was written as intended.
> 
> The documentation at http://libexif.sourceforge.net/api/ is good and I have

I'm glad you're finding it useful.

> studied some of the sample programs.  I have not figured out how to structure
> data that I want to store in the Exif header into the correct format for one of
> the libexif functions to accept it.

As you've discovered, there aren't any sample programs to show how to write
EXIF data to an image--it's on my list of things to do.  Creating EXIF data
to add to an image is easy--it's a matter of calling exif_data_new(),
exif_data_set_data_type() and exif_data_fix()-- writing it into the
proper place in a JPEG file isn't. libjpeg used to be a part of libexif,
but it got moved out into the exif front-end, presumably because it
wasn't strictly necessary for EXIF parsing.

> Can anyone tell me where I can learn to do that?
>
> I cannot find the equivalent API documentation for the libjpeg file
> jpeg-data.c and all of the functions therein.  Can you tell me where
> to find it?

Nobody has gotten around yet to documenting the libjpeg functions as the
libexif ones are.  Until that happens, you're on your own!  Take a look
at the exif front-end code, though. As long as you trace through
the code for a single option (like create_exif) it's reasonably
straightforward to see what's going on.

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

[Libexif-devel] Understanding libjpeg and libexif

[Benny S. <ich...@pa...>]

I am still trying to understand how to open a JPEG file, extract the Exif
header, add data to or change data in the Exif header, and then write the
header back to the JPEG file so that it can be read by ExifPilot or some
other PC application to confirm that the data was written as intended.

 

The documentation at http://libexif.sourceforge.net/api/ is good and I have
studied some of the sample programs.  I have not figured out how to
structure data that I want to store in the Exif header into the correct
format for one of the libexif functions to accept it.

Can anyone tell me where I can learn to do that?

 

I cannot find the equivalent API documentation for the libjpeg file
jpeg-data.c and all of the functions therein.   Can you tell me where to
find it?

 

Benny Smith

 

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.128, 1.129 exif-entry.h, 1.21, 1.22

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

On Tue, 2009-02-03 at 10:14 +0100, Jan Patera wrote:
> 
> hmmm, I am not happy with this. Not everybody uses GNU and not
> everybody
> uses (can use) autoconf :-(
> 

The write you own config.h with the right option. That should be all you
need. Since you don't need autoconf then I guess you build for on single
platform. So it shouldn't be a problem.


Hub

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.128, 1.129 exif-entry.h, 1.21, 1.22

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

On Tue, Feb 03, 2009 at 10:14:24AM +0100, Jan Patera wrote:
> hmmm, I am not happy with this. Not everybody uses GNU and not everybody
> uses (can use) autoconf :-(

Anyone not using autoconf already has to do a lot of manual work creating
a build system and replicating the steps that autoconf does automatically.
Adding another autoconf macro doesn't change that (there's nothing GNU-
dependent in there that I'm aware of).  What do you suggest instead?

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

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.128, 1.129 exif-entry.h, 1.21, 1.22

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

hmmm, I am not happy with this. Not everybody uses GNU and not everybody
uses (can use) autoconf :-(

 -- Jan

> On Sun, Feb 01, 2009 at 03:49:44PM +0100, Marcus Meissner wrote:
>> Run AC_C_INLINE() in the autoconf script, it will define "inline" to
>> empty on compilers that dont know it.
>
> I assumed autoconf did that automatically.
>
>> > > file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
>> > > +static inline ExifShort
>> > > +exif_get_short_convert (const unsigned char *buf, ExifFormat
>> format, +			ExifByteOrder order)
>>
>> And inline is not really necessary, gcc will just decide on its own
>> whether to inline or not.
>
> Not everyone uses a compiler that is as smart about inlining as gcc.
> Inlining the code in this particular case is only going to save a
> handful of bytes and hardly any execution time, but being able to use
> the inline keyword could be valuable elsewhere. I'll add that autoconf
> macro to allow it.
>
>>>> Dan
> --
> http://www.MoveAnnouncer.com              The web change of address
> service
>           Let webmasters know that your web site has moved
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use
> existing skills and code to build responsive, highly engaging
> applications that combine the power of local resources and data with the
> reach of the web. Download the Adobe AIR SDK and Ajax docs to start
> building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> libexif-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.128, 1.129 exif-entry.h, 1.21, 1.22

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

On Sun, Feb 01, 2009 at 03:49:44PM +0100, Marcus Meissner wrote:
> Run AC_C_INLINE() in the autoconf script, it will define "inline"
> to empty on compilers that dont know it.

I assumed autoconf did that automatically.

> > > file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
> > > +static inline ExifShort
> > > +exif_get_short_convert (const unsigned char *buf, ExifFormat format,
> > > +			ExifByteOrder order)
> 
> And inline is not really necessary, gcc will just decide on its own
> whether to inline or not.

Not everyone uses a compiler that is as smart about inlining as gcc. Inlining
the code in this particular case is only going to save a handful of bytes
and hardly any execution time, but being able to use the inline keyword
could be valuable elsewhere. I'll add that autoconf macro to allow it.

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

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.128, 1.129 exif-entry.h, 1.21, 1.22

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

On Sun, Feb 01, 2009 at 03:05:13PM +0100, Jan Patera wrote:
> Dan,
> 
> unfortunately this doesn't compile with every compiler.
> For example MSVC at least versions 6 through 8 don't support this way of
> inlining in C (it is OK in C++).
> For 'C', the right syntax there is
> 
> static __declspec(inline) ExifShort
> 
> My suggestion is to create a macro INLINE and use it instead.
> FYI: when MSVC is used, macro _MSC_VER is defined.

Run AC_C_INLINE() in the autoconf script, it will define "inline"
to empty on compilers that dont know it.
 
> > file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
> > +static inline ExifShort
> > +exif_get_short_convert (const unsigned char *buf, ExifFormat format,
> > +			ExifByteOrder order)

And inline is not really necessary, gcc will just decide on its own
whether to inline or not.

Ciao, Marcus

Re: [Libexif-devel] [libexif-cvs] libexif/libexif/olympus mnote-olympus-entry.c, 1.45, 1.46

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

On Fri, Jan 16, 2009 at 09:19:00AM +0100, Jan Patera wrote:
> Do we actually need this someone's (yours?) old private debug code?

Whoever's code it is, it can always be retrieved from CVS.  I'll remove it.

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

Re: [Libexif-devel] [libexif-cvs] libexif/libexif/olympus mnote-olympus-entry.c, 1.45, 1.46

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

Dan,

> Replaced all C99-style // comments with ANSI C comments.
>
>
> Index: mnote-olympus-entry.c
> +                /*CC (entry->components, 8, v, maxlen);
> +                vl = exif_get_long (entry->data, entry->order);
> +                printf("-> 0x%04x\n",entry->data);
> +                printf("-> 0x%s<\n",entry->data - 0);*/

Do we actually need this someone's (yours?) old private debug code?

 -- Jan

Re: [Libexif-devel] Using MakerNote tags

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

> There doesn't seem to be any way for the application to
> know the type (manufacturer) of the MakerNote it's dealing with using
> the > exif_mnote_* functions.  That means that it's difficult to reliably
> extract information for a known type of MakerNote.
>
> For example, if an app wants the contents of the Canon "Owner name"
> MakerNote tag (9), there's no way of knowing if a "9" returned from
> exif_mnote_data_get_id() is the Canon "Owner name" or some other
> MakerNote tag, such as the Nikon "Flash Mode".
>
> I think what needs to be done is to make the enum ExifDataTypeMakerNote
> public and add a exif_mnote_data_type() function that just internally
> calls exif_data_get_type_maker_note(). That will provide the MakerNote
> tag namespace information to the caller and provide context for the
> exif_mnote_* functions.

I agree with making them public.

 -- Jan

Re: [Libexif-devel] Question about JPG file accessand ExifHeaderaccess

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

On Sat, Jan 03, 2009 at 06:14:38PM -0800, Benny Smith wrote:
> What does CVS mean?
> 
> Can you send me a link to the CVS source for the API comments and code
> examples?

CVS is the source code control system we use for libexif. There's information
on the SourceForge site as well as lots of other places about using it,
but you can just browse the sample code without knowing about it at
http://libexif.cvs.sourceforge.net/viewvc/libexif/libexif/contrib/examples/
The API docs and all the other docs are linked on the page I just sent.

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

Re: [Libexif-devel] Question about JPG file accessand ExifHeaderaccess

[Benny S. <ich...@pa...>]

Dan,

What does CVS mean?

Can you send me a link to the CVS source for the API comments and code
examples?

Thanks,

Benny

-----Original Message-----
From: Dan Fandrich [mailto:da...@co...] 
Sent: Saturday, January 03, 2009 1:26 AM
To: lib...@li...
Subject: Re: [Libexif-devel] Question about JPG file accessand
ExifHeaderaccess

On Fri, Jan 02, 2009 at 09:16:36AM -0800, Benny Smith wrote:
> However, I am still not clear on which libexif functions to utilize.
> 
> I am searching the libexif documentation for a tutorial or README file or
> something that tells how the overall library actually functions and
explains
> which library files contain the necessary functions for each operation.  I

Everything available right now is the documentation at
http://libexif.sourceforge.net/docs.html  You won't find anything about
which
library files contain the necessary functions for each operation because
it's completely irrelevant to anybody who uses libexif. Everyone else
(those who need to modify the library instead of just use it) can just
use "tags" to find the relevant source.

> have been able to figure some of that out from the names of the functions
> and from the occasional comments in the code.  But I still do not
understand
> exactly what I am doing.

I suggest using the CVS source instead of the 0.6.17 source if you aren't
already. The API comments are much richer now in CVS.  Also, there are now
three example programs in contrib/examples/ plus the original exif source
code, making four examples of how to use the library.  If you have specific
questions or suggestions on how to improve the documentation situation, feel
free to bring them up here.

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

----------------------------------------------------------------------------
--
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Question about JPG file access and ExifHeader access

[Benny S. <ich...@pa...>]

Hubert,

I have capitulated and abandoned the 8-bit microcontroller I had selected.

I have settled on a new, 32-bit controller from ATMEL that has plenty of
memory and peripheral capability to cope with libexif and my sensors.  It
will even accommodate a Linux layer, if need be.

Benny

-----Original Message-----
From: Hubert Figuiere [mailto:hfi...@te...] 
Sent: Saturday, January 03, 2009 4:17 PM
To: lib...@li...
Subject: Re: [Libexif-devel] Question about JPG file access and ExifHeader
access

On Tue, 2008-12-30 at 21:45 -0800, Benny Smith wrote:
> I keep dreaming of finding someone who has done all this before in an
> embedded environment and can just hand me the keys.

As said previously you just don't have enough memory to do something
useful. 

For most people an embedded platform is more in the neighbourhood of 8MB
and a 200MHz ARM CPU (at least) as found in a PDA, phone or router.


Hub


----------------------------------------------------------------------------
--
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Question about JPG file access and ExifHeader access

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

On Tue, 2008-12-30 at 21:45 -0800, Benny Smith wrote:
> I keep dreaming of finding someone who has done all this before in an
> embedded environment and can just hand me the keys.

As said previously you just don't have enough memory to do something
useful. 

For most people an embedded platform is more in the neighbourhood of 8MB
and a 200MHz ARM CPU (at least) as found in a PDA, phone or router.


Hub

Re: [Libexif-devel] Question about JPG file access and ExifHeaderaccess

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

On Fri, Jan 02, 2009 at 09:16:36AM -0800, Benny Smith wrote:
> However, I am still not clear on which libexif functions to utilize.
> 
> I am searching the libexif documentation for a tutorial or README file or
> something that tells how the overall library actually functions and explains
> which library files contain the necessary functions for each operation.  I

Everything available right now is the documentation at
http://libexif.sourceforge.net/docs.html  You won't find anything about which
library files contain the necessary functions for each operation because
it's completely irrelevant to anybody who uses libexif. Everyone else
(those who need to modify the library instead of just use it) can just
use "tags" to find the relevant source.

> have been able to figure some of that out from the names of the functions
> and from the occasional comments in the code.  But I still do not understand
> exactly what I am doing.

I suggest using the CVS source instead of the 0.6.17 source if you aren't
already. The API comments are much richer now in CVS.  Also, there are now
three example programs in contrib/examples/ plus the original exif source
code, making four examples of how to use the library.  If you have specific
questions or suggestions on how to improve the documentation situation, feel
free to bring them up here.

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

[Libexif-devel] Using MakerNote tags

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

I think I've spotted a hole in the libexif API when it comes to MakerNote
tags. There doesn't seem to be any way for the application to know the
type (manufacturer) of the MakerNote it's dealing with using the
exif_mnote_* functions.  That means that it's difficult to reliably
extract information for a known type of MakerNote.

For example, if an app wants the contents of the Canon "Owner name" MakerNote
tag (9), there's no way of knowing if a "9" returned from
exif_mnote_data_get_id() is the Canon "Owner name" or some other MakerNote
tag, such as the Nikon "Flash Mode".

I think what needs to be done is to make the enum ExifDataTypeMakerNote
public and add a exif_mnote_data_type() function that just internally calls
exif_data_get_type_maker_note(). That will provide the MakerNote tag
namespace information to the caller and provide context for the exif_mnote_*
functions.

One could argue that an app should be looking at the EXIF "Manufacturer" tag
to determine this. That's a reasonable request, but many manufacturers use
the same MakerNote style (e.g. Olympus, Sanyo, Nikon) and it would be neat
if apps would automatically obtain support for a new manufacturer's
MakerNotes. Hard-coding "Olympus", "Sanyo", "Nikon" in the app means that
when some future "Xyzzy" manufacturer starts using that style of tag, the app
must be modified.  But maybe this is low-level and nonstandardized enough
to force apps to do just that.

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

Re: [Libexif-devel] Question about JPG file access and ExifHeaderaccess

[Benny S. <ich...@pa...>]

Jan and Dan,

Thanks for your replies.

Since I do NOT need to copy the entire JPG file in order to change the Exif
header, I will not do so.

Once the compact flash card is initialized and a JPG file is opened, I will
use libexif to copy the entire Exif header, add the GPS information, and
then re-write the Exif header back to the JPG file.  Obviously, libexif can
handle all of that.

However, I am still not clear on which libexif functions to utilize.

I am searching the libexif documentation for a tutorial or README file or
something that tells how the overall library actually functions and explains
which library files contain the necessary functions for each operation.  I
have been able to figure some of that out from the names of the functions
and from the occasional comments in the code.  But I still do not understand
exactly what I am doing.

Thanks,

Benny


-----Original Message-----
From: Jan Patera [mailto:pa...@pi...] 
Sent: Friday, January 02, 2009 3:18 AM
To: lib...@li...
Cc: ich...@pa...
Subject: Re: [Libexif-devel] Question about JPG file access and
ExifHeaderaccess

Benny,

> Back to the memory issue (not an issue in high-level applications on a
> PC, etc.), are the libjpeg library functions reading/writing an entire
> JPG file?

yes, libjpeg indeed reads and decompresses entire JPEG into memory.
But to parse (and change) the EXIF data you do not need libjpeg at all!!!

The folder libexif/libexif/libjpeg is now empty. I don't know why but
Lutz (the principal author of libexif) removed 4 files .C/.H from there on
2005.03.30. These files were enough to parse EXIF data. These files were
jpeg-data.c
jpeg-data.h
jpeg-marker.c
jpeg-marker.h

I have been successfuly using these files for years and I didn't notice
their removal from libexif till now.

My suggestion for your is to dig for these file here:

http://libexif.cvs.sourceforge.net/viewvc/libexif/libexif/libjpeg/?hideattic
=0&pathrev=MAIN

 --- Jan



----------------------------------------------------------------------------
--
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Question about JPG file access and ExifHeader access

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

On Fri, Jan 02, 2009 at 12:18:13PM +0100, Jan Patera wrote:
> yes, libjpeg indeed reads and decompresses entire JPEG into memory.
> But to parse (and change) the EXIF data you do not need libjpeg at all!!!

It's a bit annoying that libexif's internal JPEG processor has the same name
as another well-known library.

> The folder libexif/libexif/libjpeg is now empty. I don't know why but
> Lutz (the principal author of libexif) removed 4 files .C/.H from there on
> 2005.03.30. These files were enough to parse EXIF data. These files were
> jpeg-data.c
> jpeg-data.h
> jpeg-marker.c
> jpeg-marker.h
> 
> I have been successfuly using these files for years and I didn't notice
> their removal from libexif till now.

They're still there, just moved out of libexif into the exif/libjpeg/
directory. I can only assume that was because they weren't strictly necessary
for using the rest of libexif, although they sure can be handy.

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

Re: [Libexif-devel] Question about JPG file access and ExifHeader access

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

Benny,

> Back to the memory issue (not an issue in high-level applications on a
> PC, etc.), are the libjpeg library functions reading/writing an entire
> JPG file?

yes, libjpeg indeed reads and decompresses entire JPEG into memory.
But to parse (and change) the EXIF data you do not need libjpeg at all!!!

The folder libexif/libexif/libjpeg is now empty. I don't know why but
Lutz (the principal author of libexif) removed 4 files .C/.H from there on
2005.03.30. These files were enough to parse EXIF data. These files were
jpeg-data.c
jpeg-data.h
jpeg-marker.c
jpeg-marker.h

I have been successfuly using these files for years and I didn't notice
their removal from libexif till now.

My suggestion for your is to dig for these file here:

http://libexif.cvs.sourceforge.net/viewvc/libexif/libexif/libjpeg/?hideattic=0&pathrev=MAIN

 --- Jan

Re: [Libexif-devel] Question about JPG file access and ExifHeader access

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

On Tue, Dec 30, 2008 at 09:45:33PM -0800, Benny Smith wrote:
> I looked at the example "cam_features.c" and realized that there is another
> library "libjpeg" with files that contain the file-access functions.
> 
> This is tricky for me because I am not using libexif on a high-level system
> and so I cannot do an install of the whole exif functionality, as the
> library assumes.

libjpeg is a part of the exif front-end that should be able to be used
on its own.  It shouldn't be hard to include its source code along with the
libexif source code.

> Since the compact flash card I am using is full of digital-camera JPG files,
> it is formatted and partitioned with FAT16.  Rabbit Dynamic C has a whole
> set of file access functions dedicated to FAT file systems.  So, I must
> convert all of the fwrite), fread(), fopen(), etc. calls in the libjpeg
> files over to Dynamic C FAT-file parlance.  I assume that such concerns are
> transparent in a high-level application of libexif since the operating
> system would know that the CF card is FAT-enabled and take care of such
> things, right?

The library doesn't care about the type of filesystem, but just assumes that
the ANSI C stdio semantics hold.  You might find it just as easy to write
fopen/fread/fclose wrappers around the Rabbit functions than modify the
libexif source code.  I'd actually be surprised if the Rabbit FAT library
didn't supply those wrappers already since they are so simple and standard.

> Back to the memory issue (not an issue in high-level applications on a PC,
> etc.), are the libjpeg library functions reading/writing an entire JPG file?
> This matters because the Rabbit core module I selected only has 128K of RAM.
> I figured that would be enough for a complete Exif header (64K bytes), but
> JPG files are bigger than 128K.  This could be a deal-breaker for the Rabbit
> module I have chosen.  Maybe for the entire Rabbit platform.

I'm not very familiar with libjpeg so I can't say for certain, but it does
appear that it assumes the entire JPEG data is available on the heap. But
you could probably modify jpeg_data_save_data to replace the code that writes
the main image data with a routine that copies it straight from the
original file on CF instead.

> I keep dreaming of finding someone who has done all this before in an
> embedded environment and can just hand me the keys.

You're trying something ambitious, doing image processing on such a tiny
processor. There are so many tradeoffs when trying to do that that I'd be
surprised if you find something off the shelf.

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

Re: [Libexif-devel] Question about JPG file access and ExifHeader access

[Benny S. <ich...@pa...>]

Dan,

I looked at the example "cam_features.c" and realized that there is another
library "libjpeg" with files that contain the file-access functions.

This is tricky for me because I am not using libexif on a high-level system
and so I cannot do an install of the whole exif functionality, as the
library assumes.

I have to tailor the libraries to fit the embedded platform on which I am
working (Rabbit Semiconductor core modules).

I have finally converted all of the libexif library files over to Rabbit's
Dynamic C environment.  Now, I will need to convert the libjpeg library as
well.

Since the compact flash card I am using is full of digital-camera JPG files,
it is formatted and partitioned with FAT16.  Rabbit Dynamic C has a whole
set of file access functions dedicated to FAT file systems.  So, I must
convert all of the fwrite), fread(), fopen(), etc. calls in the libjpeg
files over to Dynamic C FAT-file parlance.  I assume that such concerns are
transparent in a high-level application of libexif since the operating
system would know that the CF card is FAT-enabled and take care of such
things, right?

Back to the memory issue (not an issue in high-level applications on a PC,
etc.), are the libjpeg library functions reading/writing an entire JPG file?
This matters because the Rabbit core module I selected only has 128K of RAM.
I figured that would be enough for a complete Exif header (64K bytes), but
JPG files are bigger than 128K.  This could be a deal-breaker for the Rabbit
module I have chosen.  Maybe for the entire Rabbit platform.

I keep dreaming of finding someone who has done all this before in an
embedded environment and can just hand me the keys.

Whew!

Benny

-----Original Message-----
From: Dan Fandrich [mailto:da...@co...] 
Sent: Tuesday, December 30, 2008 2:06 PM
To: lib...@li...
Subject: Re: [Libexif-devel] Question about JPG file access and ExifHeader
access

> Also, I am trying to understand how libexif will know about and be able to
> write to/read from the memory on my microcontroller module ((I have 128K
of
> RAM available).

Did you want more specific information than you got a few weeks ago?
libexif
uses memory on both the stack and heap, using the standard C allocation
methods..

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

----------------------------------------------------------------------------
--
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Question about JPG file access and Exif Header access

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

On Tue, Dec 30, 2008 at 12:51:42PM -0800, Benny Smith wrote:
> I am trying to use libexif for the first time.
> 
> I am working in an embedded environment and I want to read from and write to
> Exif headers in JPG files stored on a compact flash card.
> 
> I have not done any of this before.
> 
> I have looked at the test programs (test-mem.c , test-value.c, etc.)
> included with the libexif package.
> 
> I do not see any file access commands in these programs, wherein a JPG file
> is opened or closed.

A couple of example programs were checked in to contrib/examples/ after the
last release. You can take a look at them at
http://libexif.cvs.sourceforge.net/viewvc/libexif/libexif/contrib/examples/
The exif front-end is pretty readable as well, so you can just trace through
that code to see how it works.  The API documentation at
http://libexif.sourceforge.net/api/ has been greatly expanded since the last
release as well.

> Also, I am trying to understand how libexif will know about and be able to
> write to/read from the memory on my microcontroller module ((I have 128K of
> RAM available).

Did you want more specific information than you got a few weeks ago?  libexif
uses memory on both the stack and heap, using the standard C allocation
methods..

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