Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Wed, 7 Nov 2007 04:03:51 +, Karl Günter Wünsch [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Von: Raphaël Quinet [EMAIL PROTECTED] This is mandatory according to the EXIF specification. Just as a side note: it's Exif, not EXIF. http://en.wikipedia.org/wiki/Exchangeable_image_file_format Not really important for the discussion, but I do suggest that we do it right from the beginning. SCNR, Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Friday 09 November 2007, Raphaël Quinet wrote: 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. If the current version behaves correctly in this regard (which I gather it is from your comments) then I am all in favour of dropping the dialog and always rotate the image accordingly. 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. That would be very nice and is important for me and probably a whole host of people out there that rely on the IPTC tags. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Thursday 08 November 2007, Raphaël Quinet wrote: 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 you suggest that the GIMP is changing the orientation tag when it is loading the image. 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. 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... 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. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Hi, 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 only problem is that it is rather difficult to discover how to change that decision later. Currently you need to edit parasiterc. We might want to find a solution for these Don't ask me again questions that can be used from all over the place. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Sunday, November 4, 2007, 11:09:22, Sven Neumann wrote: The only problem is that it is rather difficult to discover how to change that decision later. Currently you need to edit parasiterc. We might want to find a solution for these Don't ask me again questions that can be used from all over the place. Many programs have this implemented in Preferences, either as a simple Reset all 'Don't ask me again' questions button, or even as a list which allows you to set the response for each of these questions individually. -- Jernej Simončič http://deepthought.ena.si/ The more food you prepare, the less your guests eat. -- The Party Law ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Sven Neumann writes: 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 I like being asked. My Canon A540 quite often rotates when it shouldn't (pointing the camera down, as I often do when shooting flowers or lizards, confuses its orientation sensor). The current dialog, with its thumbnail preview and its option of don't ask me again, works very well (though as Sven says, it would be nice to have an easier way of un-doing the don't ask). -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Currently, GIMP tries to do a bit of both in the same jpeg plug-in and does not do either of them correctly: Raphael: These subjects were discussed before in the list when I ranted about almost the same. Since that some changes were made in the jpeg plug-in for GIMP 2.4.0 and imo they covered the real issues very well (now the plugin uses the existing quality instead of hopelessly destroying the original file changing its quality to 85). Anyway, I agree that the default quality for new images (85) is kinda low. Something between 90/93 should be better for the default value. The plugin already offers the possibility to change that setting in the first save (and better, the plugin lets you set a new default clicking a single button). So it's not a big deal. Another aspect I would suggest to change is the default subsampling. 1x1,1x1,1x1 (the best quality) is imo the better choice, because it gives a larger file, but much better quality. As this setting is hide under the advanced options tag, for the regular user it would be better if the best quality is provided, instead of the the best compression. Best compressions is an optimization. If you need a smaller file, it's a nice option. But regular users (user case: Jane wants to make minor adjustments of brightness and contrast images and remove red eyes on her birthday party) will expect the best quality by default. That's why I think the default values should be changed. About the rest of the current plugin interface, it looks just fine for me. You just mentioned PS. They chose these settings by default (higher quality and better subsampling). People (like myself the first time) tend to believe that PS offers better quality because of that. That's not true and simply changing the default values should help to destroy that false claiming. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
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
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
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. Sorry to disagree, the precise selection of quality really is one of the many areas where I would not like any dumbing down of the interface. This would mean that each and every time I have to save an image as JPEG I would have to switch to the advanced options as every site I post my images to has stringent restrictions on file size - which are enforced by an automatic resampling (which is to be avoided at all cost due to a severe loss in quality) if I don't adhere to these limits! Having preset quality settings really is no option, it is a major annoyance in Photoshop new users I spoke to always are struggling with! regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Sat, 03 Nov 2007 00:06:18 +0100, Karl Günter Wünsch [EMAIL PROTECTED] 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. Sorry to disagree, the precise selection of quality really is one of the many areas where I would not like any dumbing down of the interface. This would mean that each and every time I have to save an image as JPEG I would have to switch to the advanced options as every site I post my images to has stringent restrictions on file size - which are enforced by an automatic resampling (which is to be avoided at all cost due to a severe loss in quality) if I don't adhere to these limits! Having preset quality settings really is no option, it is a major annoyance in Photoshop new users I spoke to always are struggling with! regards Karl Günter Wünsch _ Hi, I would tend to agree with Karl. The quality is the only setting that _really_ makes a difference in jpeg and small changes are quite noticable. Changing this would also break the idea of keeping settings as they were defined when the file was open. Neither do I see a real advantage in replacing a fine grain control with an imprecise one. It's still there but less good. The advanced settings covers the rest very nicely anyway. If this is one area where Gimp has the edge of PS I'd like to see it stay. (Or rather I'd like to see it stay for it's merits). The achille's heal of jpeg has always been the lossy format degradation. If you have some improvements there I think it would be a major asset. best regards, gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
From: Raphaël Quinet [EMAIL PROTECTED] + remove the prompt for EXIF orientation: it should always be done I agree with this idea now. The problem I had with it before is that it would do bad things to people whose EXIF images had incorrect rotation information, and that would have included everybody who had used GIMP to edit a rotated image and then saved the result as a JPEG. But GIMP has been handling this correctly for a oouple of years now, so the number of cases where people get annoyed should be reasonably small, or at least if they do, it will mostly be blameable on other misbehaving programs. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Sat, 3 Nov 2007 00:06:18 +0100, Karl Günter Wünsch [EMAIL PROTECTED] 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/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
