Menu
▾
▴
libexif-devel — This is the place where your questions about libexif will be answered.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
(5) |
Jul
(17) |
Aug
(4) |
Sep
(5) |
Oct
(5) |
Nov
(26) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(8) |
Feb
|
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(18) |
Sep
(9) |
Oct
(8) |
Nov
(5) |
Dec
(4) |
| 2004 |
Jan
(10) |
Feb
(1) |
Mar
(7) |
Apr
(11) |
May
(13) |
Jun
(5) |
Jul
(3) |
Aug
|
Sep
|
Oct
(15) |
Nov
(6) |
Dec
(10) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(25) |
Apr
(24) |
May
(9) |
Jun
(20) |
Jul
(13) |
Aug
(4) |
Sep
(17) |
Oct
(7) |
Nov
(2) |
Dec
(11) |
| 2006 |
Jan
(30) |
Feb
(12) |
Mar
(12) |
Apr
(12) |
May
(7) |
Jun
(12) |
Jul
(14) |
Aug
(16) |
Sep
(20) |
Oct
(16) |
Nov
(35) |
Dec
(42) |
| 2007 |
Jan
(34) |
Feb
(34) |
Mar
(29) |
Apr
(116) |
May
(42) |
Jun
(25) |
Jul
(4) |
Aug
(9) |
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(10) |
| 2008 |
Jan
(9) |
Feb
(7) |
Mar
(2) |
Apr
(5) |
May
(2) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(4) |
Nov
(42) |
Dec
(20) |
| 2009 |
Jan
(12) |
Feb
(12) |
Mar
(1) |
Apr
(4) |
May
(2) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(23) |
Oct
(34) |
Nov
(16) |
Dec
(8) |
| 2010 |
Jan
(5) |
Feb
(9) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(14) |
| 2011 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(6) |
Dec
(4) |
| 2012 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(10) |
May
(11) |
Jun
|
Jul
(21) |
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2013 |
Jan
(1) |
Feb
(6) |
Mar
(11) |
Apr
(2) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
(3) |
Dec
(7) |
| 2014 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(8) |
May
(1) |
Jun
(6) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(14) |
Jun
(8) |
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(5) |
Dec
(5) |
| 2022 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-18 06:22:18
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
http://translationproject.org/latest/exif/zh_CN.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 18:32:20
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'libexif' has been submitted
by the Polish team of translators. The file is available at:
http://translationproject.org/latest/libexif/pl.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/libexif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/libexif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 17:02:19
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Polish team of translators. The file is available at:
http://translationproject.org/latest/exif/pl.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 16:32:26
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Indonesian team of translators. The file is available at:
http://translationproject.org/latest/exif/id.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 16:12:18
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/exif/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 06:52:16
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Dutch team of translators. The file is available at:
http://translationproject.org/latest/exif/nl.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 06:44:41
|
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to <coo...@tr...>.)
A new POT file for textual domain 'libexif' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/libexif-0.6.18-pre1.pot
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
Below is the URL which has been provided to the translators of your
package. Please inform the translation coordinator, at the address
at the bottom, if this information is not current:
http://garr.dl.sourceforge.net/sourceforge/libexif/libexif-0.6.17.tar.bz2
We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive. Ask at the address below if you want this.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-17 06:42:15
|
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to <coo...@tr...>.)
A new POT file for textual domain 'exif' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/exif-0.6.18-pre1.pot
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
Below is the URL which has been provided to the translators of your
package. Please inform the translation coordinator, at the address
at the bottom, if this information is not current:
http://garr.dl.sourceforge.net/sourceforge/libexif/exif-0.6.17.tar.bz2
We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive. Ask at the address below if you want this.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-09-03 15:32:16
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Icelandic team of translators. The file is available at:
http://translationproject.org/latest/exif/is.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Dan F. <da...@co...> - 2009-08-13 08:12:16
|
On Thu, Aug 13, 2009 at 07:27:06AM +0200, Jan Patera wrote: > the addition of EXIF_TAG_ISO_SPEED_RATINGS to exif_entry_get_value() > in this way is wrong, as long as this tag is not in the array list. > Until now, the returned value for the tag was IMHO the correct "100" or > "400". Now it is "Internal error (unknown value 100)". > I suggest partial undo of the change. I agree. EXIF_TAG_ISO_SPEED_RATINGS should be decoded as a short, not as an enumerated type. I've removed that line of the patch. >>> 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-08-13 05:54:19
|
Vladimir & Lutz,
the addition of EXIF_TAG_ISO_SPEED_RATINGS to exif_entry_get_value()
in this way is wrong, as long as this tag is not in the array list.
Until now, the returned value for the tag was IMHO the correct "100" or
"400". Now it is "Internal error (unknown value 100)".
I suggest partial undo of the change.
-- Jan
> 2009-08-12 Lutz Mueller <lu...@us...>
>
> Patch by Vladimir Petrov <vpp...@mm...> plus some whitespace
> fixes by myself:
>
> * libexif/exif-entry.c: (exif_entry_[fix,get_value,initialize]):
> Support EXIF_TAG_ISO_SPEED_RATINGS.
>
>
> Index: exif-entry.c
> =================================================================== RCS
> file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
> retrieving revision 1.130
> retrieving revision 1.131
> diff -u -p -d -r1.130 -r1.131
> --- exif-entry.c 2 May 2009 06:28:20 -0000 1.130
> +++ exif-entry.c 12 Aug 2009 21:38:33 -0000 1.131
> @@ -217,6 +217,7 @@ exif_entry_fix (ExifEntry *e)
> case EXIF_TAG_SATURATION:
> case EXIF_TAG_CONTRAST:
> case EXIF_TAG_SHARPNESS:
> + case EXIF_TAG_ISO_SPEED_RATINGS:
> switch (e->format) {
> case EXIF_FORMAT_LONG:
> case EXIF_FORMAT_SLONG:
> @@ -1310,6 +1311,7 @@ exif_entry_get_value (ExifEntry *e, char
> case EXIF_TAG_SATURATION:
> case EXIF_TAG_CONTRAST:
> case EXIF_TAG_SHARPNESS:
> + case EXIF_TAG_ISO_SPEED_RATINGS:
> CF (e, EXIF_FORMAT_SHORT, val, maxlen);
> CC (e, 1, val, maxlen);
> v_short = exif_get_short (e->data, o);
> @@ -1394,6 +1396,7 @@ exif_entry_initialize (ExifEntry *e, Exi
> case EXIF_TAG_GAIN_CONTROL:
> case EXIF_TAG_SUBJECT_DISTANCE_RANGE:
> case EXIF_TAG_FLASH:
> + case EXIF_TAG_ISO_SPEED_RATINGS:
>
> /* SHORT, 1 component, default 0 */
> case EXIF_TAG_IMAGE_WIDTH:
> @@ -1415,9 +1418,9 @@ exif_entry_initialize (ExifEntry *e, Exi
> break;
>
> /* SHORT, 1 component, default 1 */
> - case EXIF_TAG_ORIENTATION:
> - case EXIF_TAG_PLANAR_CONFIGURATION:
> - case EXIF_TAG_YCBCR_POSITIONING:
> + case EXIF_TAG_ORIENTATION:
> + case EXIF_TAG_PLANAR_CONFIGURATION:
> + case EXIF_TAG_YCBCR_POSITIONING:
> e->components = 1;
> e->format = EXIF_FORMAT_SHORT;
> e->size = exif_format_get_size (e->format) * e->components;
> @@ -1427,7 +1430,7 @@ exif_entry_initialize (ExifEntry *e, Exi
> break;
>
> /* SHORT, 1 component, default 2 */
> - case EXIF_TAG_RESOLUTION_UNIT:
> + case EXIF_TAG_RESOLUTION_UNIT:
> case EXIF_TAG_FOCAL_PLANE_RESOLUTION_UNIT:
> e->components = 1;
> e->format = EXIF_FORMAT_SHORT;
> @@ -1438,7 +1441,7 @@ exif_entry_initialize (ExifEntry *e, Exi
> break;
>
> /* SHORT, 1 component, default 3 */
> - case EXIF_TAG_SAMPLES_PER_PIXEL:
> + case EXIF_TAG_SAMPLES_PER_PIXEL:
> e->components = 1;
> e->format = EXIF_FORMAT_SHORT;
> e->size = exif_format_get_size (e->format) * e->components;
> @@ -1457,7 +1460,6 @@ exif_entry_initialize (ExifEntry *e, Exi
> exif_set_short (e->data, o, 0xffff);
> break;
>
> -
> case EXIF_TAG_BITS_PER_SAMPLE:
> e->components = 3;
> e->format = EXIF_FORMAT_SHORT;
> @@ -1472,6 +1474,7 @@ exif_entry_initialize (ExifEntry *e, Exi
> e->data + 2 * exif_format_get_size (e->format),
> o, 8);
> break;
> +
> case EXIF_TAG_YCBCR_SUB_SAMPLING:
> e->components = 2;
> e->format = EXIF_FORMAT_SHORT;
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment -
> and focus on what you do best, core application coding. Discover what's
> new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> libexif-cvs mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-cvs
|
|
From: Vladimir P. <vpp...@mm...> - 2009-08-12 16:31:00
|
There isn't support for ISO speed ratings in exif_entry_fix(), exif_entry_get_value() and exif_entry_initialize(). If using it, the library always produces broken tag. I attach the patch that fixes the issue. |
|
From: Translation P. R. <ro...@tr...> - 2009-06-17 18:53:47
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'libexif' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/libexif/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/libexif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/libexif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-06-15 21:07:15
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'libexif' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/libexif/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/libexif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/libexif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-06-03 16:52:16
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'libexif' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/libexif/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/libexif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/libexif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Jean-Philippe F. <jp....@cy...> - 2009-06-03 07:09:41
|
Hi,
The libexif API seems to be mainly oriented toward reading exif data.
For example :
There is a :
exif_entry_get_value() function,
but no
exif_entry_set_value() function
I am using this library to build an exif section "from scratch" and o
I find it quite helpful, but I am missing some functions, and I don't
know if I am doing things correctly.
Anyway, to write data to an ascii tag, I have to mess with the content
of the ExifEntry struct like this :
exif_entry_initialize(MyEntry, EXIF_TAG_IMAGE_DESCRIPTION);
MyEntry->data = realloc(MyEntry->data, ASCII_TAG_DEFAULT_SIZE);
MyEntry->size = ASCII_TAG_DEFAULT_SIZE;
MyEntry->components = ASCII_TAG_DEFAULT_SIZE;
snprintf(MyEntry->data, MyEntry->size, "JPEG Image");
Did I miss something ?
|
|
From: Dan F. <da...@co...> - 2009-05-26 22:11:06
|
On Tue, May 26, 2009 at 10:16:24AM -0700, Jeff Breidenbach wrote: > I'm submitting this patch on behalf of Lance Huang. It adds two > functions to access the entries in maker notes. Patch is against the > current CVS tree; please consider integrating. Thanks! Giving access to makernote tags is problematic to do consistently for all current and potential future makernote formats. The biggest problem is that they can take on absolutely any format--by definition, it's up to the manufacturer. So, assuming the same format as the regular EXIF tags isn't sufficient. Even those manufacturers that do use notes that look just like EXIF tags could create a camera in the future that expands the range of standardized fields like ExifFormat, for example. And how to give access to tags from cameras that don't use a TLV scheme? How about cameras (like Olympus) that can have sub-IFDs within their MakerNotes? libexif right now takes advantage of this inconsistency by doing extra parsing on some tags (e.g. for Canon) to make them easier to handle by the user, although that destroys the ability to access the unadulterated tags. Also, the gaping hole in the API whereby libexif doesn't say which kind of makernote format is being returned needs to be addressed. These issues all should be addressed before giving access to raw makernote tags. The approach in the patch is also inconsistent with the way libexif gives access to normaltags right now. Better would be to use an approach like that around the ExifEntry structure. Adding this kind of access to makernotes is useful so I hope someone manages to resolve all these issues. >>> Dan -- http://www.MoveAnnouncer.com The web change of address service Let webmasters know that your web site has moved |
|
From: Jeff B. <jbr...@go...> - 2009-05-26 17:38:39
|
I'm submitting this patch on behalf of Lance Huang. It adds two functions to access the entries in maker notes. Patch is against the current CVS tree; please consider integrating. Thanks! Jeff |
|
From: Translation P. R. <ro...@tr...> - 2009-04-13 19:22:17
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/exif/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2009-04-12 16:47:06
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'exif' has been submitted
by the Latvian team of translators. The file is available at:
http://translationproject.org/latest/exif/lv.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/exif/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/exif.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Dan F. <da...@co...> - 2009-04-04 01:29:54
|
On Fri, Apr 03, 2009 at 01:32:19PM -0700, Jim Nelson wrote: > I'm trying to write EXIF data back to the JPEG file it came from. This appears > to be a problem for a number of people. If there's a general practice for this > -- or available code! -- I'd love to know where to find it. There used to be a little library called libjpeg that was a part of libexif, but it has since been moved to the exif command-line tool source package. You can easily copy that out and use it in your package, being mindful of the license, of course. > My own experiments show that libexif is, for at least the photos I'm using, > reducing the size of the EXIF data by approx. 1800 - 2000 bytes, even before my > modifications. I assume this is due to padding in the original JPEG file that > libexif bit-buckets at load time. That's likely. In some cases libexif will remove malformed tags that it runs into, which may be another reason for a size decrease. > Here's a general strategy I'm considering: > > 1. Read EXIF from the JPEG. Modify. > 2. Flatten into buffer with exif_data_save_data(). > 3. Examine JPEG file's APP1 segment. If APP1 length <= buffer length, write > buffer directly into the APP1 segment in the file *without* modifying APP1's > length field. Zero out remaining bytes in file. Done. > 4. Otherwise, write out temporary file with SOI, APP1 with new EXIF and proper > EXIF length, then copy remaining original file over. Move temporary file on > top of original. Done. > > Step #3 is kind of dodgy ... will this work? I don't know enough about the > EXIF or JPEG spec to understand if this is a problem (especially using zeroes > as padding). I'm not worried about wasting 2000 bytes in a 1MB file. libjpeg should do what you need in this area. >>> Dan -- http://www.MoveAnnouncer.com The web change of address service Let webmasters know that your web site has moved |
|
From: Jim N. <ji...@yo...> - 2009-04-03 21:00:00
|
I'm trying to write EXIF data back to the JPEG file it came from. This appears to be a problem for a number of people. If there's a general practice for this -- or available code! -- I'd love to know where to find it. My own experiments show that libexif is, for at least the photos I'm using, reducing the size of the EXIF data by approx. 1800 - 2000 bytes, even before my modifications. I assume this is due to padding in the original JPEG file that libexif bit-buckets at load time. Here's a general strategy I'm considering: 1. Read EXIF from the JPEG. Modify. 2. Flatten into buffer with exif_data_save_data(). 3. Examine JPEG file's APP1 segment. If APP1 length <= buffer length, write buffer directly into the APP1 segment in the file *without* modifying APP1's length field. Zero out remaining bytes in file. Done. 4. Otherwise, write out temporary file with SOI, APP1 with new EXIF and proper EXIF length, then copy remaining original file over. Move temporary file on top of original. Done. Step #3 is kind of dodgy ... will this work? I don't know enough about the EXIF or JPEG spec to understand if this is a problem (especially using zeroes as padding). I'm not worried about wasting 2000 bytes in a 1MB file. Thanks, -- Jim Nelson Yorba |
|
From: Dan F. <da...@co...> - 2009-03-04 08:20:53
|
On Wed, Feb 25, 2009 at 10:08:26PM -0800, Benny Smith wrote: > Can you send me a copy of an example config.h file? Perhaps I can use it as > a template to create one for my application that can be #included in the > libexif files where necessary. Here's one generated for libexif on Linux. Naturally, you'll have to add/remove the #defines/#undefs to match your platform. libexif's is pretty simple compared to the config.h files generated for many other projects. > Since Dev-C++ and GCC (Gnu C) are apparently closely related, any config.h > file that I create should work with either. It's not just the compiler but the standard C library that define many of the entries in the file. >>> 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-02-26 06:22:17
|
Dan, Can you send me a copy of an example config.h file? Perhaps I can use it as a template to create one for my application that can be #included in the libexif files where necessary. I am using Dev-C++ on my PC to get libjpeg and libexif working for me. When I am satisfied that my program works with Dev-C++, I will move the code over to an ATMEL AVR32 controller, which uses the GCC c-compiler via ATMEL's AVR32 Studio. Since Dev-C++ and GCC (Gnu C) are apparently closely related, any config.h file that I create should work with either. Thanks for the help! Benny -----Original Message----- From: Dan Fandrich [mailto:da...@co...] Sent: Wednesday, February 25, 2009 8:36 PM To: lib...@li... Subject: Re: [Libexif-devel] config.h file 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 ---------------------------------------------------------------------------- -- 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 |
|
From: Dan F. <da...@co...> - 2009-02-26 05:17:18
|
On Wed, Feb 25, 2009 at 04:02:06PM -0800, Benny Smith wrote: > 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). This isn't actually required--libexif contains enough of a parser to extract EXIF data from a .jpg file. It just can't write that data back without help. > 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. This would work if the new EXIF block was exactly the same as the old EXIF block. In practise, this is seldom the case because EXIF files often contain dummy data bytes that libexif eliminates, and libexif will also fix malformed data fields which often increases the size (the latter can be disabled). You could probably get this working some of the time, but you'll need to decide if that is acceptable for your application or not. >>> Dan -- http://www.MoveAnnouncer.com The web change of address service Let webmasters know that your web site has moved |
258 messages has been excluded from this view by a project administrator.
