gexiv2 issueshttps://gitlab.gnome.org/GNOME/gexiv2/-/issues2018-05-22T12:32:51Zhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/12Bind IptcData::detectCharset2018-05-22T12:32:51ZBugzillaBind IptcData::detectCharset## Submitted by Jim Nelson
**[Link to original bug (#712484)](https://bugzilla.gnome.org/show_bug.cgi?id=712484)**
## Description
---- Reported by jim@yorba.org 2010-12-07 16:46:00 -0800 ----
Original Redmine bug id: 2928
Orig...## Submitted by Jim Nelson
**[Link to original bug (#712484)](https://bugzilla.gnome.org/show_bug.cgi?id=712484)**
## Description
---- Reported by jim@yorba.org 2010-12-07 16:46:00 -0800 ----
Original Redmine bug id: 2928
Original URL: http://redmine.yorba.org/issues/2928
Searchable id: yorba-bug-2928
Original author: Jim Nelson
Original description:
The IPTC interface offers a handy detectCharset() method to determine which
encoding should be used for all strings.
---- Additional Comments From valencia-maint@gnome.bugs 2013-01-02 14:28:00 -0800 ----
### History
---
Comment 1
Updated by Jim Nelson 11 months ago
* **Category** set to _implementation_
--- Bug imported by chaz@yorba.org 2013-11-16 14:45 UTC ---
This bug was previously known as _bug_ 2928 at http://redmine.yorba.org/show_bug.cgi?id=2928
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/11add alt lang interface to gexiv22023-12-07T23:37:32ZBugzillaadd alt lang interface to gexiv2## Submitted by Adam Dingle
**[Link to original bug (#712483)](https://bugzilla.gnome.org/show_bug.cgi?id=712483)**
## Description
---- Reported by adam@yorba.org 2010-12-14 17:23:00 -0800 ----
Original Redmine bug id: 2964
Or...## Submitted by Adam Dingle
**[Link to original bug (#712483)](https://bugzilla.gnome.org/show_bug.cgi?id=712483)**
## Description
---- Reported by adam@yorba.org 2010-12-14 17:23:00 -0800 ----
Original Redmine bug id: 2964
Original URL: http://redmine.yorba.org/issues/2964
Searchable id: yorba-bug-2964
Original author: Adam Dingle
Original description:
add alt lang interface to gexiv2
---- Additional Comments From valencia-maint@gnome.bugs 2013-01-02 14:28:00 -0800 ----
### History
---
Comment 1
Updated by Jim Nelson almost 3 years ago
* **Priority** deleted (`<strike>`__`</strike>`)
The need for this function in Shotwell has been averted (#2773). Reducing to
medium, as it might someday be handy to be able to retrieve a string by its
language code.
---
Comment 2
Updated by Adam Dingle over 2 years ago
* **Status** changed from _Open_ to _Review_
* **Assignee** changed from _Jim Nelson_ to _Anonymous_
---
Comment 3
Updated by Jim Nelson 11 months ago
* **Category** set to _implementation_
--- Bug imported by chaz@yorba.org 2013-11-16 14:45 UTC ---
This bug was previously known as _bug_ 2964 at http://redmine.yorba.org/show_bug.cgi?id=2964
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/10gexiv2 should return single-length list for EXIF tag in gexiv2_get_tag_multip...2020-11-17T22:20:00ZBugzillagexiv2 should return single-length list for EXIF tag in gexiv2_get_tag_multiple()## Submitted by Jim Nelson
**[Link to original bug (#712482)](https://bugzilla.gnome.org/show_bug.cgi?id=712482)**
## Description
---- Reported by jim@yorba.org 2010-12-14 21:15:00 -0800 ----
Original Redmine bug id: 2966
Orig...## Submitted by Jim Nelson
**[Link to original bug (#712482)](https://bugzilla.gnome.org/show_bug.cgi?id=712482)**
## Description
---- Reported by jim@yorba.org 2010-12-14 21:15:00 -0800 ----
Original Redmine bug id: 2966
Original URL: http://redmine.yorba.org/issues/2966
Searchable id: yorba-bug-2966
Original author: Jim Nelson
Original description:
Because only IPTC and XMP can return multiple strings for a single value,
gexiv2_get_tag_multiple() will only return an array of strings for those
domains. It returns NULL otherwise.
A more lenient solution would be to generate a 1-length array for EXIF data,
so all domains can be accessed through this call universally.
---- Additional Comments From valencia-maint@gnome.bugs 2013-10-03 18:20:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson 11 months ago
* **Category** set to _implementation_
---
Comment 2
Updated by Jim Nelson 11 months ago
* **Description** updated (diff)
* **Category** changed from _implementation_ to _24_
* **Priority** changed from _Low_ to _High_
* **Target version** set to _0.6_
---
Comment 3
Updated by Jim Nelson 10 months ago
* **Category** changed from _24_ to _implementation_
* **Keywords** set to _bite-sized_
---
Comment 4
Updated by Jim Nelson 10 months ago
* **Tracker** changed from _Feature_ to _Bite-sized_
---
Comment 5
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.6_ to _0.7.0_
---
Comment 6
Updated by Jim Nelson about 1 month ago
* **Target version** deleted (`<strike>`_0.7.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-16 14:45 UTC ---
This bug was previously known as _bug_ 2966 at http://redmine.yorba.org/show_bug.cgi?id=2966
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/9Some date formats in the wild do not conform to EXIF standard.2018-05-22T12:32:17ZBugzillaSome date formats in the wild do not conform to EXIF standard.## Submitted by Valencia Maintainers
**[Link to original bug (#712463)](https://bugzilla.gnome.org/show_bug.cgi?id=712463)**
## Description
---- Reported by valencia-maint@gnome.bugs 2012-07-09 17:14:00 -0700 ----
Original Redmi...## Submitted by Valencia Maintainers
**[Link to original bug (#712463)](https://bugzilla.gnome.org/show_bug.cgi?id=712463)**
## Description
---- Reported by valencia-maint@gnome.bugs 2012-07-09 17:14:00 -0700 ----
Original Redmine bug id: 5524
Original URL: http://redmine.yorba.org/issues/5524
Searchable id: yorba-bug-5524
Original author: Robert Park
Original description:
The attached patch makes the date parsing more robust in Python, adding
support for non-standard but apparently common EXIF date strings.
Related issues:
* related to shotwell - http://redmine.yorba.org/show_bug.cgi?id=5560: Move EXIF date handling logic into gexiv2 (Open)
related to gexiv2 - Feature #6170: Solidify gexiv2 API (Fixed)
related to gexiv2 - http://redmine.yorba.org/show_bug.cgi?id=6741: python {g,s}et_date_time() bindings do not work
anymore (Fixed)
---- Additional Comments From valencia-maint@gnome.bugs 2013-10-03 18:20:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson over 1 year ago
* **Status** changed from _Open_ to _Review_
---
Comment 2
Updated by Robert Park over 1 year ago
I say 'apparently' because I've never seen these formats myself, but these are
the formats supported by pyexiv2, so consider this a case of learning from
pyexiv2's experience.
---
Comment 3
Updated by Jim Nelson over 1 year ago
* **Status** changed from _Review_ to _Open_
* **Assignee** changed from _Jim Nelson_ to _Robert Park_
We've seen plenty of bogus EXIF date/times in the wild. However, we fixed
these in Shotwell rather than gexiv2. (We were fixing them up in Shotwell
before we migrated to gexiv2, and the fixup code remained there.)
So, one way to approach this would be to combine the formats there with the
formats you have here, so the Python code gets all those as well.
Another approach would be to move this fixup handling into gexiv2 itself, so
all callers get the benefit. I'm personally more inclined toward that,
although we would need to rope the Shotwell team into the picture to make sure
this is done correctly.
---
Comment 4
Updated by Robert Park over 1 year ago
You're right, having gexiv2 handle it internally so that all callers benefit
from it would be the superior solution. Who from the Shotwell team would be
best suited to this task? (I have no experience with Shotwell's code).
---
Comment 5
Updated by Jim Nelson over 1 year ago
I've linked this ticket to a new ticket, #5560, which is to remove the
date/time handling logic from Shotwell. This ticket is for adding it into
gexiv2.
I've thought about this over weekend and have mixed feelings about how to
proceed. gexiv2 is primarily glue logic, designed to make Exiv2 available to
GObject-based applications. I don't think gexiv2 should be adding too much
fanciness. At the same time, it already has a handful of convenience methods
(such as the GPS stuff) which is potentially valuable to a lot of
applications. So I think adding this feature is not out of the question.
My other thought is that I don't want gexiv2 to make these bogus dates
completely unavailable to the caller. The basic calls (such as
gexiv2_metadata_get_exif_tag_string()) should return exactly what Exiv2
reports.
My suggestion is to do something that Shotwell does internally: offer
gexiv2_metadata_get_datetime() (as well as EXIF, IPTC, and XMP variants) that
returns a GDate object. This method can also do the formatting fix-ups to
avoid bogus EXIF date/times.
---
Comment 6
Updated by Robert Park over 1 year ago
I agree, `gexiv2_metadata_get_exif_tag_string` should always return the "raw"
(unaltered) string as it appears in the EXIF. Python syntax like
`metadata[tagname]` gets mapped to call `get_exif_tag_string`, and I like how
that consistently gives you the raw value, regardless of the chosen tag. So
it's just a matter of making `gexiv2_metadata_get_date_time` parse the string
loosely, and then report the string in the canonical EXIF standard format, so
that the Python binding code will understand it without requiring any
modifications (eg, without needing to apply the above patch).
---
Comment 7
Updated by Robert Park over 1 year ago
Been thinking about this for a bit... since the date handling doesn't seem to
be a priority for the Shotwell team, can you just release 0.5 as-is? This
issue is relatively minor as far as I'm concerned, and the introspection
support is **very** usable at this point. If you could release 0.5, then my
application can finally complete it's Python3 port (waiting for 0.5 is
literally the only thing holding me back).
Once 0.5 is out and gets picked up by the distros, then I can start using it,
and perhaps other people will start using it too, and once we start getting
feedback from other users, that's when we can worry about unifying
shotwell/gexiv2's date handling for the benefit of all.
Pretty please? ;-)
---
Comment 8
Updated by Jim Nelson over 1 year ago
Yorba releases its software on roughly the same cycle as GNOME, i.e. every six
months. We plan on releasing 0.5 along with Shotwell 0.13 later this fall. It
should be picked up by all the major distros.
---
Comment 9
Updated by Jim Nelson 11 months ago
* **Target version** changed from _0.5_ to _0.6_
---
Comment 10
Updated by Jim Nelson 11 months ago
* **Category** set to _implementation_
---
Comment 11
Updated by Jim Nelson 8 months ago
* **Target version** changed from _0.6_ to _0.7.0_
---
Comment 12
Updated by Jim Nelson 8 months ago
See #6741 for my thoughts on where this logic could live.
---
Comment 13
Updated by Jim Nelson about 1 month ago
* **Target version** deleted (`<strike>`_0.7.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 5524 at http://redmine.yorba.org/show_bug.cgi?id=5524
Imported an attachment (id=259984)
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/8win32 binaries2018-05-22T12:32:10ZBugzillawin32 binaries## Submitted by Valencia Maintainers
**[Link to original bug (#712441)](https://bugzilla.gnome.org/show_bug.cgi?id=712441)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-04-29 05:19:00 -0700 ----
Original Redmi...## Submitted by Valencia Maintainers
**[Link to original bug (#712441)](https://bugzilla.gnome.org/show_bug.cgi?id=712441)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-04-29 05:19:00 -0700 ----
Original Redmine bug id: 6877
Original URL: http://redmine.yorba.org/issues/6877
Searchable id: yorba-bug-6877
Original author: Alexandre Rossi
Original description:
Please provide instructions to produce win32 binaries of a working GExiv2
library with python bindings or even better binaries with each release.
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 6877 at http://redmine.yorba.org/show_bug.cgi?id=6877
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/7Provide accessors for obtaining tag TypeID and storage size2020-11-24T11:44:15ZBugzillaProvide accessors for obtaining tag TypeID and storage size## Submitted by Jim Nelson
**[Link to original bug (#712439)](https://bugzilla.gnome.org/show_bug.cgi?id=712439)**
## Description
---- Reported by jim@yorba.org 2013-05-06 15:28:00 -0700 ----
Original Redmine bug id: 6906
Orig...## Submitted by Jim Nelson
**[Link to original bug (#712439)](https://bugzilla.gnome.org/show_bug.cgi?id=712439)**
## Description
---- Reported by jim@yorba.org 2013-05-06 15:28:00 -0700 ----
Original Redmine bug id: 6906
Original URL: http://redmine.yorba.org/issues/6906
Searchable id: yorba-bug-6906
Original author: Jim Nelson
Original description:
Exiv2 provides static methods for getting a tag's TypeID (an enum) and its
storage size. gexiv2 should provide accessors for both of these.
See:
http://www.exiv2.org/doc/namespaceExiv2.html#5153319711f35fe81cbc13f4b852450c
http://www.exiv2.org/doc/classExiv2_1_1TypeInfo.html#51746fbabad74fbc06765dd53
0444c16
Related issues:
related to gexiv2 - Feature #6900: Support for getting underlying tag types (Fixed)
---- Additional Comments From valencia-maint@gnome.bugs 2013-10-03 18:20:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson 6 months ago
* **Description** updated (diff)
---
Comment 2
Updated by Jim Nelson about 1 month ago
* **Target version** deleted (`<strike>`_0.7.0_`</strike>`)
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 6906 at http://redmine.yorba.org/show_bug.cgi?id=6906
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/6Building and using on OS X (Lion)2018-05-23T08:27:51ZBugzillaBuilding and using on OS X (Lion)## Submitted by Valencia Maintainers
**[Link to original bug (#712438)](https://bugzilla.gnome.org/show_bug.cgi?id=712438)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-05-08 09:32:00 -0700 ----
Original Redmi...## Submitted by Valencia Maintainers
**[Link to original bug (#712438)](https://bugzilla.gnome.org/show_bug.cgi?id=712438)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-05-08 09:32:00 -0700 ----
Original Redmine bug id: 6925
Original URL: http://redmine.yorba.org/issues/6925
Searchable id: yorba-bug-6925
Original author: Benjamin Henne
Original description:
Building on OS X (testing on Lion) currently does not work
* Need to install prerequisites, I had to
brew install glib gobject-introspection
* Need to replace libtool by glibtool in Makefile to allow correct use of glibtool. Replacing by $(LIBTOOL) does not work in current Makefile, because shell then executes LIBTOOL=glibtool --mode ...
I suggest removing LIBTOOL= in configure script and adding it in Makefile once
where needed, finally replacing libtool by $(LIBTOOL) in Makefile. Then
./configure --enable-introspection --with-libtool=glibtool
* Now, gexiv2 builds using _make_.
make
* $ make install
glibtool --mode=install install libgexiv2.la /usr/local/lib
glibtool: install: install .libs/libgexiv2.2.dylib /usr/local/lib/libgexiv2.2.dylib
glibtool: install: (cd /usr/local/lib && { ln -s -f libgexiv2.2.dylib libgexiv2.dylib || { rm -f libgexiv2.dylib && ln -s libgexiv2.2.dylib libgexiv2.dylib; }; })
glibtool: install: install .libs/libgexiv2.lai /usr/local/lib/libgexiv2.la
install -m 644 gexiv2/gexiv2.h gexiv2/gexiv2-metadata.h gexiv2/gexiv2-managed-stream.h gexiv2/gexiv2-preview-properties.h gexiv2/gexiv2-preview-image.h gexiv2/gexiv2-log.h gexiv2/gexiv2-startup.h /usr/local/include/gexiv2
install -m 644 gexiv2.pc /usr/local/lib/pkgconfig
install -m 644 gexiv2.vapi /usr/local/share/vala/vapi
install -m 644 GExiv2-0.4.gir /usr/local/share/gir-1.0
install -m 644 GExiv2-0.4.typelib `pkg-config gobject-introspection-no-export-1.0 --variable typelibdir`
**How moving on?**
* This may be needed
export PYTHONPATH=\"$(brew --prefix)/lib/python2.7/site-packages:\$PYTHONPATH\"
* I also installed pygobject, executed _make install_ again
pygobject: stable 2.28.6
* but still even _gi.repository_ is not found by python
There is no python-gi on OS X?
---- Additional Comments From valencia-maint@gnome.bugs 2013-08-29 15:17:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson 6 months ago
* **Category** set to _build_
---
Comment 2
Updated by Robert Park 3 months ago
GI is a GNOME technology; I've heard that in theory it should not be difficult
to port it to OSX or Windows, but that so far nobody has really bothered. I'm
afraid I can't help with this.
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 6925 at http://redmine.yorba.org/show_bug.cgi?id=6925
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/5Convert Exiv2 exceptions to GError2019-07-09T08:32:27ZBugzillaConvert Exiv2 exceptions to GError## Submitted by Valencia Maintainers
**[Link to original bug (#712432)](https://bugzilla.gnome.org/show_bug.cgi?id=712432)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-08-03 04:23:00 -0700 ----
Original Redmi...## Submitted by Valencia Maintainers
**[Link to original bug (#712432)](https://bugzilla.gnome.org/show_bug.cgi?id=712432)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-08-03 04:23:00 -0700 ----
Original Redmine bug id: 7297
Original URL: http://redmine.yorba.org/issues/7297
Searchable id: yorba-bug-7297
Original author: Alessandro Tanasi
Original description:
I am using gevix2 0.4.90-0ubuntu1 and when procesing a bunch of images inside
a python script i got errors directly printed to stderr in this format:
** (process:27945): WARNING **: error message
Why they aren't handled via exceptions but silently printed to screen?
Related issues:
related to gexiv2 - Feature #7318: GDateTime accessor (Open)
---- Additional Comments From valencia-maint@gnome.bugs 2013-09-19 11:24:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson 3 months ago
* **Status** changed from _Open_ to _Need Information_
Can you tell us what messages you're seeing printed to the console?
---
Comment 2
Updated by Alessandro Tanasi 3 months ago
Example:
** (process:4772): CRITICAL **: Offset of directory Image, entry 0x9c9d is out of bounds: Offset = 0x00000000; truncating the entry
** (process:4772): CRITICAL **: Offset of directory Image, entry 0xea1c is out of bounds: Offset = 0x00000000; truncating the entry
** (process:4772): CRITICAL **: Offset of directory Photo, entry 0xea1c is out of bounds: Offset = 0x00000000; truncating the entry
** (process:4772): WARNING **: Invalid key `Iptc.Application2.Caption'
---
Comment 3
Updated by Jim Nelson 3 months ago
* **Subject** changed from _Errors printedd to stderr_ to _Convert Exiv2 exceptions to GError_
* **Category** set to _interface_
* **Status** changed from _Need Information_ to _Open_
The first three errors are emitted by Exiv2, the library gexiv2 wraps. They
are never presented to gexiv2 to be thrown as exceptions. The last error
message is, I believe, an exception from Exiv2 being logged.
If you want to control whether or not those first three messages are displayed
(and others like them), gexiv2 has an interface for that:
gexiv2_log_set_handler() allows for you to install a callback and determine
what, if anything, to print.
I've updated the ticket title to reflect what's being asked here. This would
be an interface change, which I don't believe we'll be doing in the next
release.
---
Comment 4
Updated by Alessandro Tanasi about 1 month ago
I am migrating an application from pyexiv and this never happened, errors was
handled.
I see the interface you are talking but it's for C, and I am using Gexiv via
python code, or is there a way to silent ti from python code?
---
Comment 5
Updated by Jim Nelson about 1 month ago
Because gexiv2 is written in C, the errors should be generated there. I
suppose the Python bindings could convert result codes into GErrors and throw
them (I don't know much Python), but ultimately we'd like for this to happen
in the library itself.
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 7297 at http://redmine.yorba.org/show_bug.cgi?id=7297
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/3GDateTime accessor2018-05-22T12:31:21ZBugzillaGDateTime accessor## Submitted by Jim Nelson
**[Link to original bug (#712430)](https://bugzilla.gnome.org/show_bug.cgi?id=712430)**
## Description
---- Reported by jim@yorba.org 2013-08-08 13:15:00 -0700 ----
Original Redmine bug id: 7318
Orig...## Submitted by Jim Nelson
**[Link to original bug (#712430)](https://bugzilla.gnome.org/show_bug.cgi?id=712430)**
## Description
---- Reported by jim@yorba.org 2013-08-08 13:15:00 -0700 ----
Original Redmine bug id: 7318
Original URL: http://redmine.yorba.org/issues/7318
Searchable id: yorba-bug-7318
Original author: Jim Nelson
Original description:
A number of Exiv2 tags represent date, time-of-day, or date/times. Currently
the caller must extract these as a string and convert them manually to a GLib
or Posix time structure. Some times there are multiple fields in the metadata
that must be combined to form these values.
I think gexiv2 should offer one or more new accessors. In the least, it should
offer:
GDateTime* gexiv2_get_date_time(GExiv2Metadata* self, const gchar* tag);
Additionally, we could consider offering:
GDate* gexiv2_get_date(GExiv2Metadata* self, const gchar *tag);
TimeOfDay* gexiv2_get_time_of_day(GExiv2* self, const gchar* tag);
TimeOfDay would need to be created for gexiv2; I can find no such object in
GLib. (Perhaps there's a Posix struct I'm not thinking of?)
My suggestion is that this method converts the supplied tag into a
GDateTime/GDate/TimeOfDay if possible. If not, it returns NULL. GError might
be thrown instead (#7297).
This would provide a basic interface for converting Exiv2 tags into usable
objects. Another possibility to consider is to add "composite" accessors which
know all the Exiv2 tags it takes to combine into a single data representation
of commonly-used metadata (i.e. time created, time digitized, etc.) That
should be a different ticket, however.
Related issues:
related to gexiv2 - http://redmine.yorba.org/show_bug.cgi?id=7297: Convert Exiv2 exceptions to GError (Open)
related to gexiv2 - Feature #7316: Add milliseconds to get_date_time() in
GExiv2.py (Open)
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 7318 at http://redmine.yorba.org/show_bug.cgi?id=7318
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/2Offer composite accessors for commonly-needed information2018-05-22T12:30:51ZBugzillaOffer composite accessors for commonly-needed information## Submitted by Jim Nelson
**[Link to original bug (#712429)](https://bugzilla.gnome.org/show_bug.cgi?id=712429)**
## Description
---- Reported by jim@yorba.org 2013-08-08 13:30:00 -0700 ----
Original Redmine bug id: 7319
Orig...## Submitted by Jim Nelson
**[Link to original bug (#712429)](https://bugzilla.gnome.org/show_bug.cgi?id=712429)**
## Description
---- Reported by jim@yorba.org 2013-08-08 13:30:00 -0700 ----
Original Redmine bug id: 7319
Original URL: http://redmine.yorba.org/issues/7319
Searchable id: yorba-bug-7319
Original author: Jim Nelson
Original description:
gexiv2's interface is primarily designed as a GObject wrapper around Exiv2. It
does that today reasonably well.
The interface also offers conversion functions which can take the metadata and
return it not as a string but as an appropriate data type. For example,
`gexiv2_metadata_get_tag_long()`.
It also offers specialized conversion functions for well-known Exiv2 tags. For
example, @gexiv2_metadata_get_fnumber(), which converts the string into a
rational then does the math to convert the rational into a double.
The further down the above list you go, the further gexiv2 veers from its
intended purpose. There is some value in all of the above.
It's worth considering adding a final set of functions to this list, something
called "composite" metadata in ExifTool. Composite accessors take metadata
from a number of locations and puts it together to form a single data object
representing some aspect of the photo. A good example would be
GDateTime* gexiv2_metadata_get_creation_time(GExiv2Metadata* self);
Which could then assemble the best answer for this question from the available
metadata and return a single GDateTime as an answer. In EXIF, that would mean
including subsecond precision (#7316). For IPTC, that means taking the created
date and created time and putting them together. And so on.
The difference between these composite accessors and the above are that (a)
the user doesn't get to pick the Exiv2 tags used for the determination, (b)
they may use multiple tags as sources of information, and (c) the function
searches through all domains (EXIF, IPTC, XMP) for available information.
It might be worth considering performing this work in Vala, as this layer of
abstraction should have no need to touch Exiv2's C++ interface. In essence,
these calls use the basic library calls to assemble this information.
Related issues:
related to gexiv2 - Feature #7644: Offer previews/thumbnails as GdkPixbuf (Open)
related to gexiv2 - Feature #7316: Add milliseconds to get_date_time() in
GExiv2.py (Open)
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 7319 at http://redmine.yorba.org/show_bug.cgi?id=7319
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/4Add milliseconds to get_date_time() in GExiv2.py2018-05-22T12:31:33ZBugzillaAdd milliseconds to get_date_time() in GExiv2.py## Submitted by Valencia Maintainers
**[Link to original bug (#712431)](https://bugzilla.gnome.org/show_bug.cgi?id=712431)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-08-08 03:08:00 -0700 ----
Original Redmi...## Submitted by Valencia Maintainers
**[Link to original bug (#712431)](https://bugzilla.gnome.org/show_bug.cgi?id=712431)**
## Description
---- Reported by valencia-maint@gnome.bugs 2013-08-08 03:08:00 -0700 ----
Original Redmine bug id: 7316
Original URL: http://redmine.yorba.org/issues/7316
Searchable id: yorba-bug-7316
Original author: Pascal Rapaz
Original description:
Adding milliseconds would be convenient to (re)order images taken in a very
short time interval
Related issues:
related to gexiv2 - http://redmine.yorba.org/show_bug.cgi?id=7319: Offer composite accessors for commonly-needed
information (Open)
related to gexiv2 - Feature #7318: GDateTime accessor (Open)
---- Additional Comments From valencia-maint@gnome.bugs 2013-08-29 15:13:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson 3 months ago
* **Status** changed from _Open_ to _Invalid_
This is Invalid because almost all the date/time fields in common photographic
metadata formats don't support precision below one second. EXIF and IPTC do
not support millisecond precision at all. XMP does (see
http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf re:
date/time format) with ISO8601, but only in one particular format that I
suspect is rarely used by cameras.
---
Comment 2
Updated by Pascal Rapaz 3 months ago
* **File** Selection_001.png added
* **File** DSC_3786.JPG added
You are certainly right, most "small" cameras probably do not have
milliseconds. However, I think a little more professional cameras save
milliseconds. I have to show my old Nikon D70 (2004) already recorded this
information (see example attached).
For this reason I find it unfortunate that we can not recover the full
information as it is stored in the picture
---
Comment 3
Updated by Jim Nelson 3 months ago
* **Status** changed from _Invalid_ to _Open_
Ok -- I've learned something new here.
The EXIF format does support millisecond precision, but as separate fields in
the EXIF table. That is, the Exif.Photo.DateTimeOriginal is 2012:07:10
12:39:21 (second precision) but also offers Exif.Photo.SubSecTimeOriginal of
80. Between these two fields, you can glean the date/time taken down to the
millisecond. (ExifTool puts this all together as its "composite" metadata;
Exiv2 doesn't offer such a facility.)
I guess the question is, should gexiv2 make this available automatically. My
answer is a hearty maybe. In essence, the question is asking if gexiv2 should
offer "composite" metadata like ExifTool does. The intention of gexiv2 is not
to make Exiv2 easy-to-use, but rather to provide a GObject binding for Exiv2,
a passthrough so to speak. However, there are things that gexiv2 can assist
in, such as making GPS coordinates easier to get and decode, so I could see
adding millisecond parsing (especially since this is such a commonly-used
purpose of photo metadata libraries). In addition, I want gexiv2 to offer
returning data as a GDateTime, not just a string. (I've now ticketed that:
#7318.)
In the short term, however, this data is available to you via gexiv2's
interface. You could extract the SubSec fields and add them to the date/time
object you get from the bindings already.
I'm reopening this ticket since it's a valid question and, if we did offer
composite accessors, then this would be one to consider for that.
---
Comment 4
Updated by Pascal Rapaz 3 months ago
Thank you for your answer and all the details !
As you suggest I will get the SubSec value until a compisite accessor will be
available.
Best Regards
---
Comment 5
Updated by Robert Park 3 months ago
I'm ok with seeing gexiv2 provide a method that calculates this data from the
fields, in the same way that get_gps_info calculates gps data from several
different EXIF fields, however my only request is that this is implemented as
a new method, and existing methods are left alone. Altering the behavior of
existing methods just results in migration headaches for all users of gexiv2,
which i'd like to avoid.
Thanks.
---
Comment 6
Updated by Jim Nelson 3 months ago
We're on the same page, Robert. We would add new methods to return this
composite information.
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 7316 at http://redmine.yorba.org/show_bug.cgi?id=7316
Imported an attachment (id=259972)
Imported an attachment (id=259973)
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/1Offer previews/thumbnails as GdkPixbuf2018-05-22T12:30:44ZBugzillaOffer previews/thumbnails as GdkPixbuf## Submitted by Jim Nelson
**[Link to original bug (#712425)](https://bugzilla.gnome.org/show_bug.cgi?id=712425)**
## Description
---- Reported by jim@yorba.org 2013-10-23 15:50:00 -0700 ----
Original Redmine bug id: 7644
Orig...## Submitted by Jim Nelson
**[Link to original bug (#712425)](https://bugzilla.gnome.org/show_bug.cgi?id=712425)**
## Description
---- Reported by jim@yorba.org 2013-10-23 15:50:00 -0700 ----
Original Redmine bug id: 7644
Original URL: http://redmine.yorba.org/issues/7644
Searchable id: yorba-bug-7644
Original author: Jim Nelson
Original description:
Suggested by mitch on IRC: offer gexiv2 previews as GdkPixbuf instead of raw
bytes. This would save a step or two for library callers.
Related issues:
related to gexiv2 - http://redmine.yorba.org/show_bug.cgi?id=7319: Offer composite accessors for commonly-needed
information (Open)
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as _bug_ 7644 at http://redmine.yorba.org/show_bug.cgi?id=7644
Unknown version " in product gexiv2.
Setting version to "!unspecified".
Unknown milestone "unknown in product gexiv2.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.
Dropping resolutionhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/13"Unsupported time format" error when loading image w/ Darwin Core metadata2020-12-07T22:57:13ZBugzilla"Unsupported time format" error when loading image w/ Darwin Core metadata## Submitted by Jim Nelson
**[Link to original bug (#723794)](https://bugzilla.gnome.org/show_bug.cgi?id=723794)**
## Description
(Related to bug #719522):
When loading an image with the Darwin Core metadata (DwC), this message is ...## Submitted by Jim Nelson
**[Link to original bug (#723794)](https://bugzilla.gnome.org/show_bug.cgi?id=723794)**
## Description
(Related to bug #719522):
When loading an image with the Darwin Core metadata (DwC), this message is displayed on the console:
** (process:330): WARNING **: Unsupported time format
This can be reproduced using test/gexiv2-dump and the attached sample image.
Note that the Darwin Core metadata does appear to be available, so it's possible this is benign.
Version: 0.9.x
### See also
* [Bug 719522](https://bugzilla.gnome.org/show_bug.cgi?id=719522)https://gitlab.gnome.org/GNOME/gexiv2/-/issues/14make gexiv2 pip installable2018-05-22T12:33:16ZBugzillamake gexiv2 pip installable## Submitted by GoMo
**[Link to original bug (#731468)](https://bugzilla.gnome.org/show_bug.cgi?id=731468)**
## Description
gexiv2 is not currently pip installable. If it's possible to do so without installing huge amounts of depend...## Submitted by GoMo
**[Link to original bug (#731468)](https://bugzilla.gnome.org/show_bug.cgi?id=731468)**
## Description
gexiv2 is not currently pip installable. If it's possible to do so without installing huge amounts of dependency overhead (I don't know, I'm not a GNOME developer), it would be nice to be able to 'pip install gexiv2'. As it exists now, this is a non-starter for small projects.https://gitlab.gnome.org/GNOME/gexiv2/-/issues/15Need GIO based stream API2021-07-13T08:58:38ZBugzillaNeed GIO based stream API## Submitted by Michael Natterer `@mitch`
**[Link to original bug (#732748)](https://bugzilla.gnome.org/show_bug.cgi?id=732748)**
## Description
There is currently no way to access "remote" files, as in whatever
is behind an URI and...## Submitted by Michael Natterer `@mitch`
**[Link to original bug (#732748)](https://bugzilla.gnome.org/show_bug.cgi?id=732748)**
## Description
There is currently no way to access "remote" files, as in whatever
is behind an URI and accessible by a GIO stream.
There should be API to read/write these based on GInputStream/GOutputStream.https://gitlab.gnome.org/GNOME/gexiv2/-/issues/16[Patch] gexiv2.pc Requires: exiv2 ... overlinking2018-05-23T07:32:46ZBugzilla[Patch] gexiv2.pc Requires: exiv2 ... overlinking## Submitted by Ankur Sinha `@sanjayankur31`
**[Link to original bug (#736789)](https://bugzilla.gnome.org/show_bug.cgi?id=736789)**
## Description
Created attachment 286354
Pkgconfig patch
From downstream bug: https://bugzilla.red...## Submitted by Ankur Sinha `@sanjayankur31`
**[Link to original bug (#736789)](https://bugzilla.gnome.org/show_bug.cgi?id=736789)**
## Description
Created attachment 286354
Pkgconfig patch
From downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=818587
Patch attached.
~~**Patch 286354**~~, "Pkgconfig patch":
[libgexiv2-pkgconf.patch](/uploads/64e2a99fb67673826eb9905ab07bd98e/libgexiv2-pkgconf.patch)
Version: 0.10.xhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/17Add support for Exif.GPSInfo.GPSTimeStamp / Rational [3]2018-05-22T12:34:13ZBugzillaAdd support for Exif.GPSInfo.GPSTimeStamp / Rational [3]## Submitted by Chris Mayo `@chrism`
**[Link to original bug (#737495)](https://bugzilla.gnome.org/show_bug.cgi?id=737495)**
## Description
Exif.GPSInfo.GPSTimeStamp is a set of three rational numbers (like GPSLatitude, GPSLongitude...## Submitted by Chris Mayo `@chrism`
**[Link to original bug (#737495)](https://bugzilla.gnome.org/show_bug.cgi?id=737495)**
## Description
Exif.GPSInfo.GPSTimeStamp is a set of three rational numbers (like GPSLatitude, GPSLongitude and others). Couldn't see a current gexiv2 method to use. My Python quick hack uses get_tag_string:
datetime.datetime.strptime(
metadata.get_tag_string("Exif.GPSInfo.GPSDateStamp") + " " +
metadata.get_tag_string("Exif.GPSInfo.GPSTimeStamp"),
'%Y:%m:%d %H/1 %M/1 %S/1')
(I guess I shouldn't rely on the denominator being 1, but it works with the photos I have been using)
Maybe something generic for getting 3 rational numbers?
Version: 0.10.xhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/18setitem append string to existing tag instead of replacing it.2018-05-22T12:34:25ZBugzillasetitem append string to existing tag instead of replacing it.## Submitted by matclab `@matclab`
**[Link to original bug (#752887)](https://bugzilla.gnome.org/show_bug.cgi?id=752887)**
## Description
Using python3 and libgexiv2 0.10.3 under arch linux :
>>> i=GExiv2.Metadata('/tmp/a.jpg')
>>>...## Submitted by matclab `@matclab`
**[Link to original bug (#752887)](https://bugzilla.gnome.org/show_bug.cgi?id=752887)**
## Description
Using python3 and libgexiv2 0.10.3 under arch linux :
>>> i=GExiv2.Metadata('/tmp/a.jpg')
>>> i['Xmp.digiKam.TagsList']
'aaa, bbb'
>>> i['Xmp.digiKam.TagsList'] = 'ccc'
>>> i['Xmp.digiKam.TagsList']
'aaa, bbb, ccc'
##### 'ccc' was expected !
Version: 0.10.xhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/19hierarchicalSubject (python 3.4.3)2020-12-15T13:19:16ZBugzillahierarchicalSubject (python 3.4.3)## Submitted by Victor
**[Link to original bug (#757965)](https://bugzilla.gnome.org/show_bug.cgi?id=757965)**
## Description
Files that haven't been opened in lightroom give the error 'No namespace'. This is a bit strange since Exi...## Submitted by Victor
**[Link to original bug (#757965)](https://bugzilla.gnome.org/show_bug.cgi?id=757965)**
## Description
Files that haven't been opened in lightroom give the error 'No namespace'. This is a bit strange since Exiv2 0.25 namspaces are automatically registered when you try to add values.
Example:
picture['Xmp.lr.hierarchicalSubject'] = 'name'
Result: 'WARNING **: No namespace info available for XMP prefix `lr''
I tried to solve this by using:
picture.register_xmp_namespace('http://ns.adobe.com/lightroom/1.0/', 'lr')
But the problem is that it's only possible to add/change 'one value'. So let's say we add 'name' and then 'name2', this wont work. It will only replace 'name' with 'name2'. So I'm asuming that the value type is set to "Text" instead of "bag Text" by default.
I've been trying to solve this with:
picture.set_xmp_tag_struct()
Result: 'AttributeError: 'Metadata' object has no attribute 'set_xmp_tag_struct'
This feels a bit strange, I'm honestly unsure how to use 'set_xmp_tag_struct()' correctly but I can't figure it out since it doesn't seem to work at all.
How I've been trying to use it:
picture.set_xmp_tag_struct('Xmp.lr.hierarchicalSubject', BAG=21)
picture.set_xmp_tag_struct('Xmp.lr.hierarchicalSubject', BAG)
Feels like a bug, let me know, thanks.
Version: 0.10.xhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/20Undocumented get_date_time()2018-05-23T07:41:53ZBugzillaUndocumented get_date_time()## Submitted by Damon Lynch
**[Link to original bug (#758449)](https://bugzilla.gnome.org/show_bug.cgi?id=758449)**
## Description
This works:
metadata = GExiv2.Metadata(file_name)
datetime = metadata.get_date_time()
But it's undo...## Submitted by Damon Lynch
**[Link to original bug (#758449)](https://bugzilla.gnome.org/show_bug.cgi?id=758449)**
## Description
This works:
metadata = GExiv2.Metadata(file_name)
datetime = metadata.get_date_time()
But it's undocumented here:
https://lazka.github.io/pgi-docs/GExiv2-0.10/classes/Metadata.html
Version: 0.10.x