Von: Sven Neumann

I get the impression that some people on this list are not really interested in getting 2.4 out. Otherwise we wouldn't be discussing so many things that are unrelated to the 2.4 release. Can we perhaps try to concentrate everyone's efforts on the next release? I would really like to iron out the remaining bits and get it out.

There are a few patches attached to 2.4 bugs. Some of them have "needs-work" comments, some don't apply anymore, some have a "what's left to do?" comment. Would be nice if the authors could have a look at them.

Michael

On Thu, 18 Jan 2007 08:32:05 +0100, Sven Neumann wrote:

Raphael, what about your status bar message changes that are supposed to go in under the string freeze?

I got sidetracked by some issues with the intelligent scissors tool. I have just committed a first patch that improves the tool a bit (bug #398309) and includes some new status bar messages. I also prepared some code to fix bug #345541 (usage of modifiers in the scissors tool) and I will commit it soon. I still have to commit a slightly larger patch dealing with the status bar messages for the transform tools. I will try to commit that tonight.

And what are the plans for the metadata editor?

As I mentioned on IRC a couple of times and probably here as well, it would be better to schedule it for 2.6 and disable it in 2.4.

I do not want to delay 2.4 because of this feature and it is unlikely that I could finish the editor in the next couple of weeks or even that someone could help me to bring it to a reasonably stable state. I will get back to the metadata editor as soon as I am done with some of the 2.4 bugs, but I think that it will take too much time to implement the missing features: finish the conversion from and to EXIF, add the conversion from and to IPTC, finish the widget re-organization, add descriptions and help messages for all XMP/EXIF/IPTC values that can be set from the GUI. Also, adding/replacing the support for metadata in all file plug-ins will require some changes in the GUI of these plug-ins.

It is probably not a good idea to do that under time pressure and under a string freeze, that's why I think that postponing this to 2.6 would be the better choice... unless we do not plan for 2.4 before the summer, but I hope that we will manage to release it sooner.

-Raphaël

On 1/19/07, Raphaël Quinet wrote:

I am done with some of the 2.4 bugs, but I think that it will take too much time to implement the missing features: finish the conversion from and to EXIF, add the conversion from and to IPTC, finish the widget re-organization, add descriptions and help messages for all XMP/EXIF/IPTC values that can be set from the GUI. Also, adding/replacing the support for metadata in all file plug-ins will require some changes in the GUI of these plug-ins.

Out of curiosity, are you planning to use Exiv2 for that? Exiv2 seems to slowly obsolete libexif these days, because it reads/writes both EXIF and IPTC (IIM). It's already used by UFRaw, digiKam and Rawstudio.

The next version will most likely feature i18n support, and since support for XMP/EXIF/IPTC in GIMP means showing all those variables translated, reducing overhead for translators would be awesome. Exiv2.pot has over 1000 messages, so you might guess how much work it would be for GIMP translators, if they did it alone... ;-)

Alexandre

On Fri, 19 Jan 2007 14:10:44 +0300, "Alexandre Prokoudine" wrote: [...]

Out of curiosity, are you planning to use Exiv2 for that? Exiv2 seems to slowly obsolete libexif these days, because it reads/writes both EXIF and IPTC (IIM). It's already used by UFRaw, digiKam and Rawstudio.

The code that I started writing two years ago includes a (very limited) EXIF parser and does not use libexif nor exiv2. There were several reasons for that:

- The metadata editor works with XMP, which is a superset of the other metadata formats and can be extended easily. So instead of keeping the EXIF block in memory and fetching values from it on request (as done by libexif and most other libraries), the tags in the EXIF block are read one by one and converted immediately to XMP.

- Libexif was very EXIF-centric (of course). The same applies to exiv2, although I did not consider it at that time. It contains lots of nice descriptions and help strings for the various EXIF tags, but many of them are not appropriate after the data is converted to XMP. For example, some separate EXIF tags are merged into a single XMP property, some others are orgnized differently and accept a different range of values, etc.

- There was an explicit wish to avoid depending on libexif. Its API has changed a couple of times and broke the GIMP plug-ins. It contained several bugs that caused many bug reports to be reported against GIMP while the bugs were in the library. And the libexif code was not very clean nor easy to follow.

In retrospect, given the time that has passed since then and the lack of progress on my part, maybe I should have used some library anyway. I am not sure...

I did not evaluate exiv2 at that time. It shares some of the problems described above for libexif, but it seems to be structured and maintained in a better way. On the other hand, it is written in C++ instead of C and it is licensed under the GPL only. I would like to use a rather permissive license for the metadata editor so that it could be re-used in other applications. That's why I picked the LGPL for the moment, although I could even use a more permissive license as long as I am the main author of the code. Using exiv2 would introduce a dependency on GPL-only code and limit the opportunities for re-use of the metadata editor.

The next version will most likely feature i18n support, and since support for XMP/EXIF/IPTC in GIMP means showing all those variables translated, reducing overhead for translators would be awesome. Exiv2.pot has over 1000 messages, so you might guess how much work it would be for GIMP translators, if they did it alone... ;-)

Sure. But as mentioned above, many of these messages are specific to EXIF and may be irrelevant or inappropriate when the metadata is converted to XMP. The messages that refer to the specific encodings used by EXIF (rational numbers, date formates, etc.) would have to be replaced by different messages in the metadata editor. Besides, there are many other properties in XMP that are not part of EXIF and would have to be described, translated, etc. This includes the Dublin Core properties, the license-related stuff (Creative Commons, etc.)... Although it would be possible to fetch some of the tag descriptions from the library and have all other descriptions in the editor itself, I am not sure about how much work would be saved by that.

I haven't really made up my mind yet. Maybe I should just get rid of the code that I started writing a long time ago and use some EXIF library instead. Maybe this would save some development time. Maybe not.

-Raphaël

On 1/19/07, Raphaël Quinet wrote:

- The metadata editor works with XMP, which is a superset of the other metadata formats and can be extended easily. So instead of keeping the EXIF block in memory and fetching values from it on request (as done by libexif and most other libraries), the tags in the EXIF block are read one by one and converted immediately to XMP.

Does it mean that tags will be written back to EXIF when saving to JPEG/TIFF/PNG?

On the other hand, it is written in C++ instead of C and it is licensed under the GPL only.

This is not 100% correct.

http://www.exiv2.org/whatsnew.html#item4

Sure. But as mentioned above, many of these messages are specific to EXIF and may be irrelevant or inappropriate when the metadata is converted to XMP. The messages that refer to the specific encodings used by EXIF (rational numbers, date formates, etc.) would have to be replaced by different messages in the metadata editor. Besides, there are many other properties in XMP that are not part of EXIF and would have to be described, translated, etc. This includes the Dublin Core properties, the license-related stuff (Creative Commons, etc.)... Although it would be possible to fetch some of the tag descriptions from the library and have all other descriptions in the editor itself, I am not sure about how much work would be saved by that.

I see. Thank you for the explanation.

Alexandre