gexiv2 issueshttps://gitlab.gnome.org/GNOME/gexiv2/-/issues2024-02-14T14:09:43Zhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/80Ignoring the optional character set definition results in incorrect display o...2024-02-14T14:09:43ZRoland EisnerIgnoring the optional character set definition results in incorrect display of the user comment valueShotwell version: 0.32.2
exiftool version: 12.74
exiv2 version: 0.27.5
### The expected behaviour:
The handling of the metadata field _Exif.Photo.UserComment_ should be compatible with other tools like the popular _exiftool_. The vis...Shotwell version: 0.32.2
exiftool version: 12.74
exiv2 version: 0.27.5
### The expected behaviour:
The handling of the metadata field _Exif.Photo.UserComment_ should be compatible with other tools like the popular _exiftool_. The visible user comment in the images overview grid or in the image detail view should not have a leading information of the character set, eg.:
**charset=Ascii Beautiful sunset sky**
but the user comment only like:
**Beautiful sunset sky**
### What was actually happening:
I'm adding values into _Exif.Photo.UserComment_ with _exiftool_ with a perl script before importing the photos into Shotwell for many years now. For some time the user comment values displayed in Shotwell in the grid view and in the edit comment window suddenly started with a _'charset=Unicode'_ string. Unfortunately i can not remember the versions of Shotwell and exiftool i used before or which of them has been updated on my computer since this behavior.
### Steps to reproduce the issue:
1. Add a user comment to a photo with _exiftool_.
2. Import the photo into Shotwell.
3. Enable the display of user comments in the grid view or watch the photo in detail view and check the user comment output in the right meta data column.
Maybe this has something to do with some changes in the exiv2 library, as already discussed here: https://github.com/Exiv2/exiv2/issues/1258https://gitlab.gnome.org/GNOME/gexiv2/-/issues/79Exception thrown when invalid path convertion2023-11-25T19:20:37ZRémi BERTHOException thrown when invalid path convertion**Describe the bug**
The function `convert_path` in `gexiv2-metadata.cpp` throw an exception (which is not catched) when it cannot convert a path to the local encoding.
Indeed the function return FALSE (line 479) in case of error instea...**Describe the bug**
The function `convert_path` in `gexiv2-metadata.cpp` throw an exception (which is not catched) when it cannot convert a path to the local encoding.
Indeed the function return FALSE (line 479) in case of error instead of an empty string.
**To Reproduce**
Steps to reproduce the behavior:
1. Call `gexiv2_metadata_open_path` with a path which contain UTF-8 characters that cannot be represented in the current locale.
**Expected behaviour**
The function should only return an error.
**Desktop**
- OS: Windows
- Compiler & version: gcc on msys2-ucrt64
**Additional context**
The error occurred because exiv2 remove the wstring support in version 0.28.0 (seed this [exiv2 issue](https://github.com/Exiv2/exiv2/issues/2637)).
Instead we should set the locale to UTF-8 on windows.https://gitlab.gnome.org/GNOME/gexiv2/-/issues/78Sort out a new logo, perhaps.2023-09-23T16:27:57ZJens GeorgSort out a new logo, perhaps.Looks like the old logo was just some random typography art which is used all over the interweb, with no proper reference, so I pulled it.
Having a new one would be nice, thoughLooks like the old logo was just some random typography art which is used all over the interweb, with no proper reference, so I pulled it.
Having a new one would be nice, thoughhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/77Update latest release 0.14.2 on https://wiki.gnome.org/Projects/gexiv22023-08-17T09:54:43ZchenruiUpdate latest release 0.14.2 on https://wiki.gnome.org/Projects/gexiv2:wave: it looks like the website still points to 0.14.1 as latest release, raise this issue to confirm if that is intentional, thanks!
relates to https://github.com/Homebrew/homebrew-core/pull/137465:wave: it looks like the website still points to 0.14.1 as latest release, raise this issue to confirm if that is intentional, thanks!
relates to https://github.com/Homebrew/homebrew-core/pull/137465https://gitlab.gnome.org/GNOME/gexiv2/-/issues/76Maintenance of GExiv22023-07-15T15:23:25ZJehanMaintenance of GExiv2@jensgeorg 2 years ago, you wanted to give up GExiv2 maintainership and thankfully you reverted this decision 3 months ago (per git log). What is the actual status? GIMP being one of the big users of GExiv2, I would not be against help y...@jensgeorg 2 years ago, you wanted to give up GExiv2 maintainership and thankfully you reverted this decision 3 months ago (per git log). What is the actual status? GIMP being one of the big users of GExiv2, I would not be against help you co-maintain it if you need.
I won't have all the time in the world as I already maintain a few software (GIMP being the biggest of these, of course), but at least I could help unload some of the work and go for the day-to-day maintenance.
Thanks for all the work, by the way! 👍https://gitlab.gnome.org/GNOME/gexiv2/-/issues/67Modernize GObject2021-05-28T06:47:51ZJens GeorgModernize GObjectUse G_DECLARE_DERIVABLE_TYPE / G_DECLARE_FINAL_TYPE instead of the old macros for shorter headers and automatic g_autoptr support
This will break ABI so that needs to be take care of as wellUse G_DECLARE_DERIVABLE_TYPE / G_DECLARE_FINAL_TYPE instead of the old macros for shorter headers and automatic g_autoptr support
This will break ABI so that needs to be take care of as wellhttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/65Add gi-docgen support in addtion (or instead of) gtk-doc support2021-05-26T13:27:19ZJens GeorgAdd gi-docgen support in addtion (or instead of) gtk-doc supportThe new kid in town for GTK-style documentation generation:
https://gitlab.gnome.org/GNOME/gi-docgen
It's much easier to set up and produces quite nice HTML on topThe new kid in town for GTK-style documentation generation:
https://gitlab.gnome.org/GNOME/gi-docgen
It's much easier to set up and produces quite nice HTML on tophttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/64Incorrect GIR version numbers in generated files2021-03-27T21:32:52Zpostscript-devpostscript-dev@outlook.comIncorrect GIR version numbers in generated files**Describe the bug**
For a project version number `MAJOR.MINOR.MICRO`, the corresponding API version number is `MAJOR.MINOR`.
When building, gexiv2 is incorrectly labelling the GIR files with an out-of-date API version number - hard-co...**Describe the bug**
For a project version number `MAJOR.MINOR.MICRO`, the corresponding API version number is `MAJOR.MINOR`.
When building, gexiv2 is incorrectly labelling the GIR files with an out-of-date API version number - hard-coded to `0.10`. The API version is used in identification of the filenames (i.e. `GExiv2-0.10.typelib` and `GExiv2-0.10.gir`), and within the files themselves .
The naming situation causes problems when the public API changes, as one version cannot be differentiated from another. This can be seen in the project testing, where [test/python/gexiv2.py](https://gitlab.gnome.org/GNOME/gexiv2/-/blob/master/test/python/gexiv2.py) and [test/python/test_metadata.py](https://gitlab.gnome.org/GNOME/gexiv2/-/blob/master/test/python/test_metadata.py) cannot choose which version they are using - even thought both call `gi.require_version()`.
The Debian build files have the same problem, as the packages are hard-coded with `0.10` and explicitly copy the `GExiv2-0.10.typelib` file. Other parts of the debian build files also need modernising.
**To Reproduce**
For the general build issue, build gexiv2 with the `introspection` flag set (it is by default).
For Debian, follow the [debian instructions](https://www.debian.org/doc/manuals/maint-guide/index.en.html) on building.
The general build problem goes back 3 years to commit a18c17896b2e860d23274a5135e740bf3195d447 and has been in place since version `0.10.6`, up until the last release of `0.12.1`.
The Debian problem goes back 4 years to commit 17f6276eb946d8978b90b7d47cd186ad8280f0dd and has been in place since version `0.10.4`, up until the last release of `0.12.1`
**Expected behaviour**
Generate the GIR files with the correct API version number.
Generate the correct packages for Debian.
**Desktop (please complete the following information):**
- OS: Windows, MinGW64
- Compiler & version: gcc.exe (Rev9, Built by MSYS2 project) 10.2.0
The bug is expected on all setups.
**Additional context**
While experimenting with the version number during building, I found that the GIR seems to correctly create the files using the full version number. The `GExiv2-0.12.typelib` and `GExiv2-0.12.2.typelib` files were exactly the same size, with the `GExiv2-0.12.typelib` file padded with 2 extra bytes where the `MICRO` component would be.
`PyGObject` (used in the project testing) however, would not use the files and only worked when an API version number was used.https://gitlab.gnome.org/GNOME/gexiv2/-/issues/56Building gexiv2-0.12.1 on macOS with Exiv2 v0.27.2 RC22021-02-03T15:44:09ZRobin MillsBuilding gexiv2-0.12.1 on macOS with Exiv2 v0.27.2 RC2Gentlemen:
This is a courtesy/update discussion. I think things are working. Your email today caused me to try to build your latest on macOS with Exiv2 v0.27.3 RC2 which will be released this week.
I did have trouble building because...Gentlemen:
This is a courtesy/update discussion. I think things are working. Your email today caused me to try to build your latest on macOS with Exiv2 v0.27.3 RC2 which will be released this week.
I did have trouble building because I don't have pkg-config on my laptop. The build reported "Cannot find Exiv2. And another panic when it didn't find the vala compiler. Both were fixed with:
```
$ sudo port install pkgconfig
$ sudo port install vala
```
Followed by happiness:
```
721 rmills@rmillsmbp:~/gnu/gexiv2/gexiv2-0.12.1 $ sudo ninja -C build test
ninja: Entering directory `build'
[0/1] Running all tests.
1/1 regression OK 0.13s
Ok: 1
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /Users/rmills/gnu/gexiv2/gexiv2-0.12.1/build/meson-logs/testlog.txt
722 rmills@rmillsmbp:~/gnu/gexiv2/gexiv2-0.12.1 $
```
I'm interested in using gexiv2 as a substitute for pyexiv2. The code on this page doesn't work on the current project. I guess the page is stale (there's a link that does a 404). Do you have any documentation about using gexiv2 from python?https://gitlab.gnome.org/GNOME/gexiv2/-/issues/50Issue when setting an empty title ...2021-03-29T13:13:22ZJerome KiefferIssue when setting an empty title ...Dear Geviv2 developers,
Python2 is getting to an end and I decided to migrate my code which was heavily using pyexiv2 to Python3 and gexiv2:
https://github.com/kif/imagizer/tree/gexiv2
I noticed an annoying bug and spent almost a week ...Dear Geviv2 developers,
Python2 is getting to an end and I decided to migrate my code which was heavily using pyexiv2 to Python3 and gexiv2:
https://github.com/kif/imagizer/tree/gexiv2
I noticed an annoying bug and spent almost a week to figure out that when one sets a comment to an empty string `exiv_object.set_comment("")`, gexiv2 stores that there is no comment in one of those keys:
* Exif.Image.ImageDescription
* Exif.Image.XPComment
(3 others are possible according to the documentation, but I did not encounter them in my tests)
Here is the dump of "exiv2 -pa" of such file, only the interesting part:
```
Exif.Image.XPComment Byte 0
Exif.Thumbnail.Compression Short 1 JPEG (old-style)
```
When reading this back metadata, one ends with the title being set to the *subsequent* tag, here `JPEG (old style)`. In other example I had `Exif.Image.ImageDescription` which was set empty
and reporting the camera manufacturer.
I also noticed it was not possible to delete directly the faulty tag using the `clear_tag` method. I had to assign this tag to non empty comment and subsequently delete it to work-around this bug.
I am using the gexiv2 version available in Debian10, i.e. gexiv2 0.10.9-1
Thanks for your help,
Jeromehttps://gitlab.gnome.org/GNOME/gexiv2/-/issues/47Please clarify the license for the project2019-10-06T10:23:24ZMichał GórnyPlease clarify the license for the projectWhat is the intended actual license for the project?
`debian/copyright` claims it's 'GPL-2 or later'. However, I can't find any real grounds for the 'or later' there.
All C sources reference `COPYING` which in turn is verbatim copy of ...What is the intended actual license for the project?
`debian/copyright` claims it's 'GPL-2 or later'. However, I can't find any real grounds for the 'or later' there.
All C sources reference `COPYING` which in turn is verbatim copy of GPL-2. It contains the 'or later' clause only as an example of copyright notice, so that can't really be taken as clear allowance to use later version.
`GExiv2.py` indicates 'LGPL-2.1 or later'. I'm not convinced it's allowed to combine it (even indirectly via introspection) to a library that's using more restrictive GPL license. However, IANAL, so I'm not going to argue about that.
`test_metadata.py` indicates 'GPL-3 or later'. Again, it is unclear whether it is valid to combine it with 'GPL-2' sources.https://gitlab.gnome.org/GNOME/gexiv2/-/issues/29critical errors while previewing from MTP phone2019-10-12T01:17:21Zjimiscritical errors while previewing from MTP phoneUsing shotwell-0.28.3-1.fc27.x86_64
After I connect the phone, previewing starts automatically. In the console I get plenty of critical errors, that are mostly of 2 kinds:
```
L 9070 2018-05-26 03:01:18 [CRT] Upper boundary of data for...Using shotwell-0.28.3-1.fc27.x86_64
After I connect the phone, previewing starts automatically. In the console I get plenty of critical errors, that are mostly of 2 kinds:
```
L 9070 2018-05-26 03:01:18 [CRT] Upper boundary of data for directory Photo, entry 0xa420 is out of bounds: Offset = 0x0000028e, size = 25, exceeds buffer size by 1 Bytes; truncating the entry
```
and
```
L 9070 2018-05-26 03:01:39 [CRT] Upper boundary of data for directory GPSInfo, entry 0x0004 is out of bounds: Offset = 0x00000302, size = 24, exceeds buffer size by 2 Bytes; truncating the entry
```
I can't see anything going wrong though. What do these errors mean and why are they critical?
Thank you in advance!
EDIT: Same issue with the following message printed by shotwell, moved from issue shotwell#2:
```
L 9070 2018-05-26 03:04:02 [WRN] Directory Thumbnail, entry 0x0201: Data area exceeds data buffer, ignoring it.
```
https://gitlab.gnome.org/GNOME/gexiv2/-/issues/24Unable to register 'Iptc4xmpExt' XMP namespace2021-03-16T17:27:50ZBugzillaUnable to register 'Iptc4xmpExt' XMP namespace## Submitted by Jim Easterbrook
**[Link to original bug (#782208)](https://bugzilla.gnome.org/show_bug.cgi?id=782208)**
## Description
I think my problem is caused by Exiv2 abbreviating Iptc4xmpExt to iptcExt.
I'm trying to add loc...## Submitted by Jim Easterbrook
**[Link to original bug (#782208)](https://bugzilla.gnome.org/show_bug.cgi?id=782208)**
## Description
I think my problem is caused by Exiv2 abbreviating Iptc4xmpExt to iptcExt.
I'm trying to add location metadata such as Xmp.iptcExt.LocationShown[1]/Iptc4xmpExt:City. I get "Unknown namespace prefix for qualified name" errors unless the XMP file already has the Iptc4xmpExt namespace registered. If I try to register it with register_xmp_namespace('http://iptc.org/std/Iptc4xmpExt/2008-02-29/', 'Iptc4xmpExt') the call return false. I assume this is because Exiv2 already has the iptcExt namespace predefined and thinks they're equivalent.
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/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/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/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/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/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 resolution