From: Benny S. <ich...@pa...> - 2008-12-30 20:51:47
|
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. 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). I would appreciate any help you can give me. Benny Smith Santa Rosa, CA |
From: Dan F. <da...@co...> - 2008-12-30 22:06:11
|
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 |
From: Benny S. <ich...@pa...> - 2008-12-31 05:45:46
|
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 |
From: Dan F. <da...@co...> - 2008-12-31 07:03:57
|
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 |
From: Jan P. <pa...@pi...> - 2009-01-02 11:18:22
|
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 |
From: Dan F. <da...@co...> - 2009-01-02 16:32:14
|
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 |
From: Benny S. <ich...@pa...> - 2009-01-02 17:16:38
|
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 |
From: Dan F. <da...@co...> - 2009-01-03 09:26:28
|
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 |
From: Benny S. <ich...@pa...> - 2009-01-04 02:14:40
|
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 |
From: Dan F. <da...@co...> - 2009-01-04 05:10:18
|
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 |
From: Hubert F. <hfi...@te...> - 2009-01-04 00:16:46
|
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 |
From: Benny S. <ich...@pa...> - 2009-01-04 02:12:01
|
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 |