Here is my contribution to the GIMP 2.6 roadmap: a description of the remaining tasks related to the metadata viewer/editor and some enhancements for the jpeg plug-in (and other plug-ins).

In the following list, the tasks marked with a "+" are the ones that I would like to include in 2.6, while the tasks marked with a "-" will be postponed until after 2.6. These optional tasks are listed here for completeness and they could still be included in case there is a sudden rush of volunteers willing to contribute to these improvements. ;-)

* metadata core (stuff that does not need a user interface): + migrate some parts of the metadata core to a library that can be used by the main app. as well as some plug-ins + clean up the PDB interface
+ convert EXIF to XMP
+ convert XMP to EXIF
- convert IPTC to XMP (IPTC Core for XMP) - convert XMP to IPTC
- rewrite the XMP parser and the internal data model

* metadata viewer/editor (user interface) + implement the "user-friendly" tabs in the metadata editor - make the tabs configurable, similar to Adobe's XMP panels - easy merging of XMP presets from a drop-down list or something similar (e.g. to apply a Creative Commons license or to set a group of properties such as creator, publisher, etc.) - allow the creation of such XMP presets - warn the user if the metadata states that editing the image is not allowed (XMP Rights Management)
- implement history tracking for XMP Media Management - allow creative editing of the embedded thumbnail

* jpeg plug-in + simplify the user interface: the default view should show only a selection between a few options (e.g, "high/medium/low" or 0-12 like in Photoshop) combining both quality and subsampling; move the old 0-100 "quality" slider inside the advanced options + remove the prompt for EXIF orientation: it should always be done - allow lossless or nearly lossless saves if only a few changes have been applied to the original image (e.g. 90 degrees rotation or minor edits in a limited area)

* all file plug-ins + handle metadata correctly (at least for jpeg, tiff, png) + make sure that the last used settings are saved in a parasite attached to the image instead of using global "save_vals", etc. - make it easy to save and restore settings (more than one set) in case the user wants to apply the same settings to several images

In case the description or purpose of some of these items is not clear, here are some additional comments:

The metadata editor uses XMP internally, because XMP is a superset of EXIF, IPTC and other metadata standards (or de facto standards). The XMP parser and generator are already included in GIMP 2.4. I also wrote some code to convert from/to EXIF, but I did not finish it and I think that it is better to rewrite it from scratch anyway. The problem with EXIF is that although the basic features are easy to parse, there are dozens of special cases and broken implementations to take care of, especially for the handling of MakerNotes.

As we discussed already several months ago, it would be useful to move some parts of the metadata handling code into a library that can be used directly by other plug-ins or by the gimp core, instead of invoking the metadata plug-in as in 2.4. It should be possible for the user to keep the "Image Properties" window open at all times and to see the changes in real-time (resolution, size, comment, etc.). In order to allow these real-time updates, the code displaying this part of the image metadata should be part of the gimp core. This does not mean that all metadata handling should be done in the core: it would also be possible to have only the "viewer" part and the basic metadata handling in the core but keep the "editor" part as an external plug-in. Another option would be to keep all that out of the core but change the plug-in API so that it allows a plug-in to remain attached to an image while other plug-ins are running, and change the protocol so that it allows a plug-in to get real-time updates about what happens to the image.

Regarding the user interface and the options (probably post-2.6) to make tabs configurable or to choose XMP presets from a list, I think that it is easier to understand if you look at these images: http://www.creativecommons.org/images/metadata/xmp-adobe-panel.png http://www.creativecommons.org/images/metadata/xmp-cc-panel.png http://www.creativecommons.org/images/metadata/xmp-multiple.jpg Note that in these images, the "Creative Commons" panel is an extension that can be downloaded from the CC site (it's a simple XML file) and it shows up among the other XMP panels, with the appropriate widgets for editing specific parts of the XMP metadata. See also: http://wiki.creativecommons.org/XMP_Help

There are also some improvements for the JPEG plug-in. As I mentioned some time ago, I would like to hide the current "quality" slider among the advanced options, and replace it by a smaller selection of pre-defined quality levels. I have also thought about some nice tricks that would allow almost lossless re-saving of JPEG images, but I am not sure that I would have time to work on that in the 2.6 timeframe.

-Raphaël

On Sat, 3 Nov 2007 00:06:18 +0100, Karl Günter Wünsch wrote:

On Friday 02 November 2007, Raphaël Quinet wrote:

There are also some improvements for the JPEG plug-in. As I mentioned some time ago, I would like to hide the current "quality" slider among the advanced options, and replace it by a smaller selection of pre-defined quality levels.

[...] every site I post my images to has stringent restrictions on file size [...] Having preset quality settings really is no option, it is a major annoyance in Photoshop new users I spoke to always are struggling with!

It looks like what you want is a "Save for Web" feature (especially because you mention posting images to some sites). Photoshop offers two different ways to save a JPEG image:

1) The normal Save assumes that you use JPEG like most other (lossless) image formats. Professional users expect that the image will be saved with a rather high quality, will contain the appropriate color profiles and other metadata related to the image so that it can be integrated in a publishing process and eventually printed. Photoshop allows the user to select quality levels between 0 and 12 (but each of them sets more than just the "quality" because the subsampling parameters are also affected). The lowest level (0) is equivalent to quality 85 in GIMP, and the highest level (12) is somewhere between 97 and 98 in GIMP. But using levels 11 and 12 is not recommended, so the recommended "High quality" level is 10, which is equivalent to quality 93 in GIMP.

2) The Save for Web feature assumes that you will put the image on some web site instead of printing it, so you care more about the size of the file than about its faithful rendering on a printer. Save for Web allows you to remove most metadata from your image and gives you more control over some JPEG parameters that can help you to reduce the size of the file. Among others, it has a slider that goes from 1 to 100 so that you can fine-tune the size/quality and it also has an option that lets you enter the target file size so that Photoshop can select the compression level that brings you as close as possible to this target value. Note that the 1-100 slider in Photoshop is not the same as in GIMP: the corresponding range in GIMP would be 55-98 (approximately).

Experienced Photoshop users will select "Save" or "Save for Web" depending on what they intend to do with the image. The goals are different and almost mutually exclusive:
1) Save: high fidelity for printing, include all metadata, no need for a preview of the JPEG compression quality, no need to estimate the size of the file before saving
2) Save for web: focus on the size/quality trade-off, it is important to have a preview and to predict the size of the file, no need for metadata, assume sRGB color profile.

Currently, GIMP tries to do a bit of both in the same jpeg plug-in and does not do either of them correctly: - For a normal Save, it is a bit stupid to have a quality slider that goes from 0 to 100 if the useful range is only between 85 and 95. - Showing only the quality slider in the default view misleads users into thinking that they only have to play with that value in order to reach a target size for the file. Changing the subsampling parameters can be as important in order to reach the best size/quality ratio. - It is necessary to check or uncheck several checkboxes in order to select if metatada and image thumbnails should be included or not. - Several other checkboxes that are rarely used clutter the list of options. The choice of DCT method and the inclusion of restart markers are special features that are almost never used (or used wrongly).

Considering all that, I think that it would be much better to provide a simplified set of choices. Each of them would combine several parameters such as quality and subsampling. This would streamline the interface for the common case for our target users (cfr. GIMP vision). Of course, the advanced settings would still be available and this would include the old quality slider if you think that it is useful. But for the kind of use case that you described, the ability to enter a target size for the file would be more useful. We could also change the jpeg plug-in so that it remembers if the advanced options are expanded or not, and maybe make it remember that across sessions. So if you insist on using the old quality slider for each image, you could still do that easily.

-Raphaël

P.S.: For more information about the mapping between Photoshop and GIMP quality levels, see:
http://blogs.gnome.org/raphael/2007/10/23/mapping-jpeg-compression-levels-between-adobe-photoshop-and-gimp-24/

On Sun, 04 Nov 2007 11:09:22 +0100, Sven Neumann wrote:

On Fri, 2007-11-02 at 23:55 +0100, Raphaël Quinet wrote:

* jpeg plug-in
+ remove the prompt for EXIF orientation: it should always be done

IMO the current solution of asking and allowing the user to skip this question is preferred. It requires a user decision once, but at least it doesn't force something on the user that he might not want to be done.

The problem is that the question is not interpreted correctly by most users, as can be seen by the other replies mentioning camera sensors that sometimes report the wrong orientation. It does NOT mean: "allow me to decide if each image should be rotated". If you do not let GIMP display the image according to its EXIF orientation tag, then the image will not be rotated by GIMP but its orientation tag will not be modified either, so if you save it after making changes and then re-open it later in GIMP or in any other program that follows the EXIF specs, then it will be rotated and this is probably not what you want. So you are just delaying the inevitable: you will not see the problem in GIMP, but you will see it later until you fix it by manually rotating the image or clearing the EXIF orientation tag.

In other words, the question could also be rephrased like this: "Do you want GIMP to display the image correctly, or do you want to temporarily ignore the standards so that you can work on an image that will be displayed incorrectly by all other programs?" Such a question does not make sense. GIMP should just display the image as it is meant to be displayed (according to the EXIF orientation tag). If the orientation was not detected correctly by the camera or if it was incorrectly modified by some other program, then the user should be encouraged to fix it instead of temporarily hiding the problem.

-Raphaël

On Wed, 7 Nov 2007 04:03:51 +0000, Karl Günter Wünsch wrote:

So you suggest that the GIMP is changing the orientation tag when it is loading the image.

This is mandatory according to the EXIF specification. A program that supports EXIF and wants to display the image correctly must load the image according to the orientation specified in the EXIF Orientation tag (this may involve rotation and/or mirroring) and must then clear the tag to indicate that pixel data is now having the same orientation as the image that it represents.

Section 7.4 "Application Software Guidelines" of the EXIF specification explains that several tags must be updated by any software that saves an image containing EXIF information: "Orientation" must be set to 1 (the default top-left orientation) after rotating or mirroring the pixel data as appropriate, "Software" must be set to the name of the program that saves the image, "DateTime" must be set to the current date and time, "YCbCrPositioning" must be set according to how the data is saved, etc. If the resolution of the image has changed, then tags like "XResolution", "YResolution" and "ResolutionUnit" may also have to be updated.

What then happens if later I decide to rotate the image again manually? If you want to go there, you are opening up a whole new set of possible scenarios which will end up confusing users and other programs.

This is not confusing at all. This is how all programs should behave. If the Orientation tag is set to any value other than 1 (top-left), then it means that the pixel data is not in the same orientation as the image that it represents, and any EXIF-compatible software that loads the image must rotate it.

To simplify things a bit, the Orientation tag is just a way for a camera to say: "hey, I'm a camera with limited memory buffers and I could not save the pixel data correctly, so please rotate the pixel data as appropriate when you load it so that you can display the image as intended".

I always understood the question so that I either want to ignore the rotation flag or not but that the EXIF would stay untouched, no matter what I decide there...

No, that's wrong. And that's one of the reasons why I want to remove this confusing question. The EXIF standard defines precisely the list of tags that must be updated and the list of tags that must be copied unchanged. Unfortunately, older GIMP versions were violating that standard by copying the whole EXIF block unmodified and this caused many problems, including images having the wrong orientation.

EXIF in an edited image has little resemblance with the original anyway, so I would suggest stripping that except for the IPTC tags. I would also be happy if the IPTC tags were settable in the GIMP, instead of having to resort to other programs.

IPTC tags are not part of EXIF. They are a different set of tags that are stored in another JPEG APP marker. The ability to edit and save them may be included in GIMP 2.6.

-Raphaël