Re: [Gimp-developer] 2.6 roadmap: my summary.
It did kindof look that way. And I wasn't meaning to be offensive (certainly I don't support the kind of public attack that other guy is doing) so I guess I was giving unwanted advice; sorry about that. Good luck on the task list and getting things done for 2.6. Joe Sven Neumann wrote: Hi, On Mon, 2007-11-26 at 22:35 -0700, Joe Eagar wrote: You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea, We have this and other mailing-list where developers and artists can exchange their ideas. I am reading through lots of mails and forums each day to find out what GIMP users are saying and so do other GIMP developers. We are receiving a large amount of bug reports and enhancement requests through Bugzilla and we listen to them. We organize events where developers and users meet to evaluate the user requests and to plan the future of GIMP. What's the point of claiming that we would dismiss the suggestions of professional users? I am seriously offended by this accusation. 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: my summary.
You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea, imho. Saying we cannot accept any new ideas until the existing ones are done is ok, but just dismissing them out of hand might deny you future access to their expertise (which can be fairly valuable). Raphaël Quinet wrote: snip - We have far more ideas than developers. We even have far more *good* ideas than developers. One way to reduce idea overload is to have some professional artists who really know how things work and can give really good feedback. This way you're not having a flood from all users. Though in gimp's place it sounds like such people would be more useful for evaluating planned features/improvements then actually coming up with new ones. Joe - The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later. - The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6. So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface. Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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: my summary.
On Thu, 22 Nov 2007 08:47:40 +0100, [EMAIL PROTECTED] wrote: I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation. You are distorting what Sven said, but this seems to be a rather common perception and complaint so maybe this deserves some clarifications: Yes, the development of GIMP 2.6 will be mostly developer driven and there will not be much room left for additional suggestions and other stuff that is not already in the list of tasks that we are discussing here. I am not saying that to disappoint you. I am saying that because we have to cope with reality. Here are some reasons: - We have far more ideas than developers. We even have far more *good* ideas than developers. - The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later. - The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6. So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface. Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer). -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: my summary.
Hi, On Thu, 2007-11-22 at 08:47 +0100, [EMAIL PROTECTED] wrote: I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation. I have never presumed that and I think that this should be very clear from the discussions on this list. You completely ripped my argument out of context and a public apology for this accusation would be proper. Most of your input lately is rather destructive and it certainly not helpful in the process of improving GIMP and its development process. 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: my summary.
On Wed, 07 Nov 2007 15:37:05 +0100, Guillermo Espertino [EMAIL PROTECTED] wrote: Sven Nwumann wrote: Nice to remind us of some issues but we are not going to put user wishes on our roadmap. It is rather distracting to post user wishes to the developer list. People here should be aware of the shortcomings and Should be maybe but apparently aren't otherwise they would never have been designed in in the first place. This is the problem with a code centred definition of development. without being a developer, your opinion is just one of many users. But let's look at some of your suggestions nevertheless... Dear Sven: What I suggested are not my wishes. I'm a professional designer and GIMP is a tool for my work. The things that I wrote are issues that make my work more difficult, while they shouldn't. I tried to describe problems in a common workflow that need to be solved, not specific requests of my preference. I'm not asking for a save for web plugin, a slicer tool, or a plugin for a specific application. They're simple annoyances that make using gimp less effective for common tasks of image manipulation I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation. One of the main reasons for the poor state of gimp UI and many of it's other short-comings is this blinkered idea that unless you can code and are familiar with GTK+ Glib et al you cannot contribute. Codeing is clearly the core activity, it is necessary but NOT sufficient. It is just this kind of input that has been lacking (or systematically rejected) in the design process. Thanks for your contribution. /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 items
On Nov 13, 2007 6:16 AM, Henk Boom [EMAIL PROTECTED] wrote: On 12/11/2007, peter sikking [EMAIL PROTECTED] wrote: - GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable? I'm not sure what the question here is, wouldn't vector layers only help this philosophy? As far as I understand their purpose is to avoid having to do permanent stroke path operations, instead making the shape easily modifiable and impermanent. Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture. I see vector layers as being a replacement for most uses of the current stroke/fill path. It accomplishes the same thing, but has the advantage that you don't have to keep re-doing it when the path is changed, as it updates automatically. When it comes to SVG integration with other applications, a layer tree or similar based on GEGL would probably automatically support this not much differently from how text layers would be supported, and the SVG-loading operation for doing so is already in place. I plan to make an experimental stroke-history based paint engine on top of GEGL. Doing experiments with this is soon becoming possible since the caching infrastructure I've been adding to GEGL in the last half year seems to be getting solid enough. This would work by storing stroke path, pressure, tilt etc information along with the brush settings for every stroke in a sequence of operations that apply paint/dabs to the underlying drawable. Each ops would contain it's own cache to speed up the application of another stroke on top (this per-node/op caching infrastructure is getting it's final polish for the next GEGL release). This will allow editing the properties of the strokes of a regular paint tool, and even removing an individual stroke after it has been made. The interesting question to be answered when a prototype is mocked up is whether it will be responsive enough for interactive painting. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ 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
On 10/11/2007, William Skaggs [EMAIL PROTECTED] wrote: One of the things that GIMP badly needs is a vectorial tool for drawing lines and arrows. This also would make sense as a first usable implementation of vector layers. Here is how I think it could be structured: Have you taken a look at the existing vector layer implementation in the soc-2006-vector-layers branch of svn? It will handle and automatically update lines if you give it an open path. The big missing feature in vector layers right now is a proper stroke and fill dialog, as the current one is neither ideal nor stable. Henk Boom ___ 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 items
On 09/11/2007, Alexandre Prokoudine [EMAIL PROTECTED] wrote: Layers - vector layers (Henk Boom?) I would be glad to continue work on this if there are possibilities of it getting into the main branch in the near future. The only issue is that I would only be available to develop this starting either mid-December or January, as for the next month I'm quite busy with the end-of-semester rush of exams, projects, etc. Is there room for this in the 2.6 timeframe? Henk Boom ___ 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 items
Hi, On Mon, 2007-11-12 at 08:29 -0500, Henk Boom wrote: - vector layers (Henk Boom?) I would be glad to continue work on this if there are possibilities of it getting into the main branch in the near future. The only issue is that I would only be available to develop this starting either mid-December or January, as for the next month I'm quite busy with the end-of-semester rush of exams, projects, etc. Is there room for this in the 2.6 timeframe? Before we add this, we should get some feedback from the UI team. I wouldn't want to add vector layers without a good specification of the user interaction and user interfaces involved. You can't start before this has happened and I am not sure if we have the resources to get this done in time for 2.6. 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 items
Sven Neumann wrote: On Mon, 2007-11-12 at 08:29 -0500, Henk Boom wrote: - vector layers (Henk Boom?) I would be glad to continue work on this Before we add this, we should get some feedback from the UI team. Well, this topic is not so clear cut. There are many factors: - the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two. - yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes. - GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable? Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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 items
From: peter sikking [EMAIL PROTECTED] Well, this topic is not so clear cut. There are many factors: - the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two. - yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes. I agree with this completely. The obvious things that GIMP should be able to support are lines, rectangles, and ellipses. The UI for manipulating rectangles and ellipses already exists in GimpRectangleTool, which was created partly with that thought in mind. The UI for handling lines should be much simpler -- as I said earlier, it should be possible to derive this straightforwardly from GimpRectangleTool. The remainder of the UI would consist of edge/fill options, which would presumably go into the tool options. A full-fledged vector layers capability introduces a lot of UI questions, which, as you say, might not even be desirable to support, but for the most basic things, it should all be reasonably straightforward. I can't tell you how many times I've needed to create a simple arrow pointing to something, and been annoyed to have to hack around to do it. The idea of invoking Inkscape to edit SVG layers makes a lot of sense, and in fact I have suggested this myself in the past -- but, as Sven pointed out, it is very tricky to pull off such an interaction without it feeling awkward and creating a large potential for breakage. This is certainly nothing that could be done in the hoped-for 2.6 time frame. Best wishes, -- 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 items
On 12/11/2007, peter sikking [EMAIL PROTECTED] wrote: Well, this topic is not so clear cut. There are many factors: - the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two. This use doesn't sound like it even requires vector layers to work. The only advantage of vector layers is that it is easy to edit them from within GIMP, which isn't so important if you are editing them only in Inkscape. I agree that this would indeed be a very cool feature =). - yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes. Right now the layers operate on arbitrary paths, so any shape which you can make a path out of can be made into a vector layer. This makes them very powerful, but I can see that you would want special cases for a couple of simple shapes. You can get a rectangle using the rectangular select tool, then converting the selection to a path, but when you go to edit the path afterwards it won't be constrained to a rectangular shape anymore. Also, going through selections isn't very intuitive. - GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable? I'm not sure what the question here is, wouldn't vector layers only help this philosophy? As far as I understand their purpose is to avoid having to do permanent stroke path operations, instead making the shape easily modifiable and impermanent. Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture. I see vector layers as being a replacement for most uses of the current stroke/fill path. It accomplishes the same thing, but has the advantage that you don't have to keep re-doing it when the path is changed, as it updates automatically. I agree with what Sven said about waiting for UI design though, as to develop without waiting for specs nearly always leads to wasted effort. Henk Boom ___ 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 items
Alexandre Prokoudine wrote: Here is the list of proposed changes in 2.6 that Sven asked for: Tools - full use of cairo for the select/crop tools (?) - color-neutral toolbox icons that are quick to recognise and work with (?) The ? character after a name means that exact intentions of that person are unknown. why are there question marks after these two items? Let me know if I missed something. compiled from my own summaries: * next generation size entries * finishing of: Heal Tool, Sample Points, Foreground Select Tool * Floating Selections * Alpha Channel * Layer boundaries * skipping annoying dialogs by default (individual assessment first) * solve user request #1, part 1: one menu bar, keep window with menu bar open when no image is open, try floating inspectors --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 Roadmap
One of the things that GIMP badly needs is a vectorial tool for drawing lines and arrows. This also would make sense as a first usable implementation of vector layers. Here is how I think it could be structured: 1) For UI, there should be a GimpLineTool interface, modeled after GimpRectangleTool, but much simpler because it only needs to be able to move the two ends, rather than any of 8 possible corners or edges. This could be created by cloning GimpRectangleTool and then simplifying, or from scratch. It would only be an interface, not a tool in itself. 2) The interface would then be used in a GimpLineShapeTool (GimpArrowTool?), which would create a vector layer containing a single line segment, allowing options to be specified for rendering style and arrows on the ends. This would be an actual tool, accessible from the toolbox. I mention this not because I want to do it myself (I don't particularly), but because I think it makes a good roadmap target, and one that might be interesting to active developers. Martin, I think, would be capable of setting up GimpLineTool, and it would give him something more creative to do in addition to fixing bugs in GimpRectangleTool (which is also important, of course, but not so exciting). For Henk, setting up GimpLineShapeTool (or whatever it is called) might give a target that is both extremely useful and an excellent start toward a full-fledged vector layer capability, without getting into all the complexities of arbitrary shapes. -- 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
[Gimp-developer] 2.6 Roadmap
As GIMP moves toward vector layers and layer groups, it will more and more need a capability for vector selection -- that is, for the kind of selection capability found in vector graphics programs like Inkscape, whose target is a set of objects rather than a spatial region -- a vector selection as opposed to the raster selection that GIMP currently uses. Actually, GIMP already has such a capability to some degree, in the linking mechanism, but it is too hard to use. I have some suggestions for improvement, which I would like to work on for GIMP 2.6 if it is okay. Here are my thoughts: 1) With two kinds of selection, there is no way to completely avoid confusing users. Probably the best thing to do is to keep calling the vector selection linking. The only real problem with this is that the same thing is always called selection in vector graphics programs, but I think it is better to face this than to use the same word for two quite different things. 2) We need a linking tool: a tool to allow objects/layers to be linked by mouse-clicking or rubber-banding. The UI for this already exists, in the Alignment Tool. In fact, that's actually all that the UI for the Alignment Tool does; the only change needed would be that, instead of the tool maintaining an internal list of the items that are selected, it would link them. 3) If the Alignment Tool is converted to a Linking Tool (with toolbox symbol an arrow pointing to the upper left), then no Alignment Tool is needed -- the functionality can be moved into a dialog, or pair of dialogs, accessible as Edit-Align or Edit-Distribute. The dialogs would operate on the set of objects that are linked. 4) Linked objects should be marked when the canvas is drawn, by putting small filled-rectangles at their corners, as is done in other vector-graphics programs. 5) Possibly the chain symbol in the Layers/Paths dialogs should be replaced by an arrow symbol. 6) The dialog in the Alignment Tool is modeled after the one in Inkscape, but has some differences. It could in principle be made virtually identical, even to the extent of using the same icons. There are a couple of things that Inkscape allows that GIMP wouldn't currently support, including (a) aligning the baselines of text layers, and (b) aligning anchor points of vector objects. I would welcome discussion of the pros and cons with somebody who is familiar with the Inkscape functionality. 7) There is a problem with paths (i.e., Vectors) as currently implemented: the offsets and dimensions obtained using the gimp_item_get_foo() calls are not meaningful. This needs to be fixed to make a linking tool work properly, and really ought to be fixed in any case. This is a sketch: I can spell out all the details in a more appropriate place. Although this may look like a long list of objectives, everything in it is actually simple to do (all the hard work was done in creating the alignment tool); and none of it creates much risk of breaking things that are deep and critical, as far as I can see. -- 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
Hi, I am afraid it is a little late to still suggest features to be put on the roadmap. There was a deadline for the submission process last week already and we only stretched it a little because we were waiting for Mitch to submit the GEGL proposal. We want to get 2.6 done in about six months, which means that we will have to feature freeze in a few months already. So I think we really need to finish the planning process by the end of this week and we already have way too many items on our tentative roadmap. 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
Hi, On Sat, 2007-11-10 at 10:34 -0800, William Skaggs wrote: As GIMP moves toward vector layers and layer groups I don't see GIMP moving towards vector layers, at least not for 2.6. Layer groups are also not on the near-term roadmap. Perhaps we can target them for 2.8 but that remains to be seen. 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
From: Sven Neumann [EMAIL PROTECTED] I don't see GIMP moving towards vector layers, at least not for 2.6. Layer groups are also not on the near-term roadmap. Perhaps we can target them for 2.8 but that remains to be seen. Oh well, consider my suggestions as early contributions to the 2.8 roadmapping process, then. -- 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 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
[Gimp-developer] 2.6 Roadmap: GEGL integration
Hey all, GIMP 2.6 will include some bits of GEGL, not the full-blown package with GEGL everywhere, but some selected spots that are easy to handle and unlikely to break anything in the planned short development cycle. The tentative plan is pretty simple: * write adapter/proxy functions/objects which enable a GEGL graphs to read/write from/to GIMP PixelRegions. This should be fairly easy to do. * remove all color correction code from app/base and use GEGL operators instead. This involves changes to GimpImageMapTool and all its subclasses, including making all their dialogs views on the properties of the resp. GEGL operators. * if feasible in the time frame, abstract some common color correction base API out of the above step and implement a simple color correction paint tool (something like dodge/burn, but with the choice of all the color correction power we have). * if the above goes well and integrates nicely, look for more isolated spots that would allos us to get rid of legacy code in favor of GEGL operators. That's basically it. Please comment or correct me if i missed something in these first basic steps. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 roadmap items
Hi, Here is the list of proposed changes in 2.6 that Sven asked for: Tools - IWarp as tool (Tor) - finishing rectangle tools (Enselic) - full use of cairo for the select/crop tools (?) - add support for color jitter in the paint tools (Adrian Likins) - paint tools should support smudging as they paint (Adrian Likins) - brush stroke panel for stroking with curves (Joao) - color-neutral toolbox icons that are quick to recognise and work with (?) GUI - arbitrary angle guidelines (Joao) - Cairo rendering (Sven) Metadata - migrate some parts of the metadata core to a library for the whole app (raphael) - convert EXIF to XMP, XMP to EXIF, IPTC to XMP, XMP to IPTC (raphael) - rewrite the XMP parser and the internal data model (raphael) - implement the user-friendly tabs in the metadata editor (raphael) - easy merging of XMP presets from a drop-down list or something similar (raphael) - implement history tracking for XMP Media Management (raphael) - allow creative editing of the embedded thumbnail (raphael) Plug-ins - simplify the user interface of jpeg plug-in (raphael) - all file plug-ins handle metadata correctly (raphael) - make sure that the last used settings are saved in a parasite attached to the image instead of using global save_vals, etc (raphael) GEGL integration - write adapter/proxy functions/objects which enable a GEGL graphs to read/write from/to GIMP PixelRegions (?) - remove all color correction code from app/base and use GEGL operators instead (?) - if feasible in the time frame, abstract some common color correction base API out of the above step and implement a simple color correction paint tool (?) Layers - vector layers (Henk Boom?) PDB - new text tool API (Marcus Heese?) - cleaning up metadata related part of PDB (raphael) The ? character after a name means that exact intentions of that person are unknown. Let me know if I missed something. Alexandre ___ 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-inenhancements
From: Karl Günter Wünsch [EMAIL PROTECTED] 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. No! EXIF in an edited image is still highly relevant, but it should not merely be copied from the original, as GIMP used to do. The EXIF specification gives precise instructions about how the EXIF data should be altered when an image is edited and saved, and to the best of my knowledge -- I just looked at the code again -- GIMP now follows the specification pretty closely, and has done so for almost three years. The file exif-handling.txt in devel-docs summarizes my understanding of what the specification requires us to do. You can look at the function jpeg_setup_exif_for_save() in plug-ins/jpeg/jpeg-exif.c to see what GIMP currently does to the EXIF. As an example, the specification says that the orientation should *always* be set to top-left when an image is saved after editing, regardless of what it was when loaded. People may argue about whether that is always the best thing to do, but it is what the specification requires, so it is what GIMP does. To the best of my knowledge, it does this regardless of what decision the user makes about rotating when loading. -- 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: my summary.
Hi, On Tue, 2007-11-06 at 12:42 -0300, Guillermo Espertino wrote: Roadmap will be closed by the end of this week, so I'd like to make a summary of the main issues I'd like to see fixed for 2.6 Nice to remind us of some issues but we are not going to put user wishes on our roadmap. It is rather distracting to post user wishes to the developer list. People here should be aware of the shortcomings and without being a developer, your opinion is just one of many users. But let's look at some of your suggestions nevertheless... 1) Semi transparent overlay of the original layer when transforming (scale or rotate). (It seems pretty obvious with the planned Cairo support) This is not obvious, nor trivial, to solve with Cairo. Perhaps we can solve it for 2.6, perhaps not. I expect that this will be an issue until we have fully switched to GEGL. That means for a few more years. 2) Redrawing speed at 100% zoom Redrawing when a large image is zoomed out is still slow. the quality of the display is excelent, but just turning on or off a layer (for instance) is slow. I wouldn't say it's slow and I am surprised that you are saying that it is. There are however some optimizations to the display and preview code that I am planning to do for 2.6. 3) Axis Constrain for move tool. This is very, very useful. Sure. But it has been on our roadmap for years and no one seems interesting in fixing it. So unless a developers feels like working on this one, it will stay unimplemented. 4) Angle constrain for path tool. Afaics in the documentation, this feature existed in previous versions. Was it removed? As far as I know this never existed. 7) I left this for the end because I don't know if it will be possible at this stage: The text tool needs improvements. I don't know if they can be made before GEGL or it should be bumped to a future version. - Text edition on canvas. - modify text properties inline (selecting a part of the text and changing the options doesn't change the whole paragraph). - Don't destroy transformations when editing text properties. Same answer here. This is on our roadmap for years already and it is very well possible. There is even code for some of this that just needs to be finished. But without someone working on it, this is not going to happen ever. 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: my summary.
Sven Nwumann wrote: Nice to remind us of some issues but we are not going to put user wishes on our roadmap. It is rather distracting to post user wishes to the developer list. People here should be aware of the shortcomings and without being a developer, your opinion is just one of many users. But let's look at some of your suggestions nevertheless... Dear Sven: What I suggested are not my wishes. I'm a professional designer and GIMP is a tool for my work. The things that I wrote are issues that make my work more difficult, while they shouldn't. I tried to describe problems in a common workflow that need to be solved, not specific requests of my preference. I'm not asking for a save for web plugin, a slicer tool, or a plugin for a specific application. They're simple annoyances that make using gimp less effective for common tasks of image manipulation For instance, the first request. An opaque original when you're transforming loses its purpose. If it obstructs the context it has no use. Being semi-transparent would be a great help, because that way it gives a visual track of the original dimensions/shape. But if it cannot be made semi-transparent for a couple of years, maybe the best solution is hiding the original and work directly on the transformed. This isn't a wish. Nobody can scale down an image to place it in a certain place when a big original doesn't let see the context. I know that I can low the layer opacity to 50% manually before transforming it, but it is tedious and reduces the productivity. I wonder if it is impossible to automate that manual procedure meanwhile. When I wrote the word obvious (I guess it was a bad word choice) I was thinking in what it was proposed for the image navigator (changing simple booleans to semi-transparent objects) and in my head made sense that this issue could be covered. I never wanted to suggest that it's trivial to implement it. 2) Bad words choice again. Redrawing is not slow. I can drag the view and it's very fast. The problem is turning on/off or moving a layer. I work with large images and blending modes. Just open three images in a A4 artwork, 300 dpi, put normal the firs, multiplied the second and screen the third and switch on and off one of the top layers. It is slow. It's just the visibility of a layer and it doesn't give inmediate feedback. I don't want to start comparing applications, but among the tools that I've used, Gimp is the only program where turning layers on/off them doesn't give inmediate feedback. The problem extends to color adjustments as well. I can wait for a filter, but when you're tweaking colors a realtime or near realtime feedback is important. The improvements you planned for this area will be welcome. 4) Ouch! :) I read something about angle constraints using shift in the old documentation, but I tried to find it again and I couldn't. I guess I'm wrong then. Anyway, not having angle constraints in the path tool kills a big part of its functionality. Right now it's impossible to make vertical or horizontal segments, and needing them is not rare at all. Beyond that, the bézier tool of Gimp is awesome. About the other things, I can't make patches, but believe me that I'm trying to convince people with the proper abilities to join to the development team and provide solutions for commonly asked requests. It's not an easy task though. Thanks anyway for your detailed reply. I appreciate you took the time for it. Cheers, Gez. ___ 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: my summary.
Hi, On Wed, 2007-11-07 at 11:37 -0300, Guillermo Espertino wrote: What I suggested are not my wishes. I'm a professional designer and GIMP is a tool for my work. The things that I wrote are issues that make my work more difficult, while they shouldn't. We are way past this point. The problem and shortcomings of GIMP are clear. What we need now is a roadmap for fixing them and we need developers who are willing and capable to work on this. Going back to step one is not helpful. 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: my summary.
Roadmap will be closed by the end of this week, so I'd like to make a summary of the main issues I'd like to see fixed for 2.6 Since I'm not a coder, I just can give my user pov, so I'll try to be realistic and don't ask for too radical things, just changes to improve the existing tools. Please consider this list just as mere suggestions. Of course, maybe some of these things need full GEGL support and are impossible at this stage, so please ignore them if that's the case. 1) Semi transparent overlay of the original layer when transforming (scale or rotate). (It seems pretty obvious with the planned Cairo support) 2) Redrawing speed at 100% zoom Redrawing when a large image is zoomed out is still slow. the quality of the display is excelent, but just turning on or off a layer (for instance) is slow. I guess that using a low resolution proxy of the actual image for this operation and processing the actual pixels in the background would make the process of displaying layers and applying filters / color adjustments more agile. But again, I'm just guessing, and the roadmap isn't the place to say how it shoul/could be done :) 3) Axis Constrain for move tool. This is very, very useful. 4) Angle constrain for path tool. Afaics in the documentation, this feature existed in previous versions. Was it removed? 5) Fade Tool should work for all the filters and color adjustment tools. Currently it doesn't work for curves or levels, and that would be very useful. 6) Better screen space usage by default. I'd really like to see as an intermediate solution (until the UI team brings a more complete solution) a minor panels re-arrangement to get more screen space (two-column narrow toolbox and tool properties moved to the main docker). An introductory window with the current toolbox menu when no image is open (as I proposed a couple of days ago) would be nice too. Also, the size of the widgets and input boxes in the dialogs is quite big. Everything is spaced, which is pleasant to the eyes, but frequently eats too much screen space. I don't really know if this has to do with the GTK theme or it can be adjusted in GIMP, but just watching the UI I can see that reducing the padding and spacing just a couple of pixels could reduce the size of the dialogs and panels without sacrificing the visual goodness. 7) I left this for the end because I don't know if it will be possible at this stage: The text tool needs improvements. I don't know if they can be made before GEGL or it should be bumped to a future version. - Text edition on canvas. - modify text properties inline (selecting a part of the text and changing the options doesn't change the whole paragraph). - Don't destroy transformations when editing text properties. ___ 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 plu g-in enhancements
On Sunday 04 November 2007, Sven Neumann wrote: 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. Yes, I like that as well. As there is no easy way to get back those question dialogs though, I refrained from making that automatic as sometimes the orientation sensor in my DSLR is fooled... 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. How about adding some preference setting for this kind of decision. That would be my first instinct if I were to look for a way to change my previous decision (that the dialog decsion has been transformed into a preference which I can find again in there somehow)... regards 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 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
Re: [Gimp-developer] 2.6 roadmap
Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. This makes sense. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases. It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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
On 10/27/07, Valerie VK [EMAIL PROTECTED] wrote: Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. This makes sense. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases. Yes, that would be a good idea. It's easy to get lost in the GIMP code, so a way to limit what developers need to look at would probably attract more developers. It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;) Actually I think I didn't explain the difference between adjustment layers and layer effects. Adjustment layer: a layer that modifies the layers below it, without actually contributing pixel data. An adjustment layer as used in Photoshop, has a mask, but no pixel data. http://www.phong.com/tutorials/adjust/ provides some examples, including eg. Curves adjustment. Layer effect: an effect attached to a layer -- for example, Drop shadow is a layer effect provided by Photoshop. Takes the layer pixel data and applies some effect to it. May have a mask, and does not have its own pixel data, so the only difference is the way it's attached to a specific layer. Peter suggested here: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html that layer effects could be thought of (and displayed as) a stack per-layer, sitting underneath the layer. ___ 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
Hi, On Sat, 2007-10-27 at 01:32 -0700, Valerie VK wrote: Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? We have already developed this roadmap for GEGL integration. For the last years this has been the major topic whenever GIMP developers met. Just calm down a little and give Mitch and Pippin some time to present their plans. GEGL integration is going to take a while. But it is a migration process and it will certainly span several release cycles. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 roadmap
Hi, so it looks like we should toss some ideas around here on the mailing-list to get an idea what could be our goals for 2.6. Let me just propose a few things for discussion: - Port internals to GEGL We are pretty sure that we want to do this but we need a more thorough proposal of what exactly should be done for 2.6 and how we want to proceed beyond that. As far as I know Mitch has some plans made for this, so I will let him lay out the details. - Port display drawing to Cairo We could have done this in the last development cycle already but postponed it in order to get 2.4 out of the door. This should be pretty much straightforward. The idea is to get away from using the GDK drawing routines to Cairo. This should allow us to get away from XOR drawing and it will open a lot of possibilities for tool improvements (half-transparent overlays for example). Again, this needs to be fleshed out in more details. - Add named parameters and default values to the PDB The idea is to introduce an alternative PDB API that has named parameters and default values. That would make scripting a lot easier and it would allow us to add parameters w/o breaking the API. Since we would have to maintain the old API as well, we wouldn't have to implement this all the way for 2.4. I am sure that we can also do a lot of user-visible changes and add smaller features here and there. Those do not absolutely need to be on the roadmap though. 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
Hi, I'ts been a while since I've last written here. First of all congrats for getting 2.4 out the door. I'm not a developer, just a humble graphic artist semi-professional UI designer. I think making a roadmap is a very important step in the development of Gimp. But I suggest before that, Gimp needs a mission statement. If you've happened to read the talkback on /. to the release announcement, you may have noticed most people compared Gimp to Photoshop and complaining on its shortcomings. I think a clear message as to the direction Gimp development will take in the future is important. The choice is simple: Professional tool for the Graphic artist, or image editor for the home user and amateur photographer. Mozilla suite - or Firefox. I believe Gimp's target audience should be the home user and amateur photographer, and future development in this direction should take precedence over features for the professional artist. Gimp is already a default install in many distros. Many more people will benefit from a simple, easy to use tool that will enable them to create web art and modify pictures than they will from a complex app crammed full of incomprehensible functions. But this must be written down and displayed on the website so everyone can see and understand just what is Gimp and where it is going. Back to the subject of the roadmap. As well as a guide for future development, a roadmap can be used to recruit potential developers by creating a vision for the future of Gimp which will inspire them to join the effort. I believe the internals work is important and necessary, but it does not inspire. Perhaps a roadmap should be drawn for the next two or three releases, leading up to Gimp 3. If the vision is attractive enough (and accompanied by detailed mockups and design documents), more people will want to join in and will agree to do some grunt work, knowing what all the hard work will eventually lead to. As for user-visible changes in version 2.6, I think an important goal should be to get Gimp to work well with the desktop environment. I'm talking about the multiple taskbar buttons and related subjects. I'm writing this on Ubuntu 7.10 and Gimp is showing some strange window behaviours here. I know similar thigs are happening in the Windows port. If there's anything most users will appreciate it's this. Michael - Original Message From: Sven Neumann [EMAIL PROTECTED] To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Friday, October 26, 2007 9:25:46 AM Subject: [Gimp-developer] 2.6 roadmap Hi, so it looks like we should toss some ideas around here on the mailing-list to get an idea what could be our goals for 2.6. Let me just propose a few things for discussion: snipped ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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
On 10/26/07, Micahel Grosberg wrote: I think making a roadmap is a very important step in the development of Gimp. But I suggest before that, Gimp needs a mission statement. It already has one http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision Alexandre ___ 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
Micahel Grosberg wrote: I believe Gimp's target audience should be the home user and amateur photographer, and future development in this direction should take precedence over features for the professional artist. Could I object? Currently GIMP is one and the only potential free OS tool for real graphic amateurs and professionals. As more and more people buys DSLRs the amount of users who need high quality tool for photo retouching increases. That can be added by the people who leaves Windows for Linux. And the others who can, but do not want to use this particular tool can use _many_ other simplier solutions. Dis I say Krita or F-Spot or..? -- With respect Alexander Rabtchevich ___ 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
Micahel Grosberg wrote: I believe Gimp's target audience should be the home user and amateur photographer, and future development in this direction should take precedence over features for the professional artist. First of all, sorry by the caveman's english. I'm a professional artist and I change from Photoshop to Gimp just because it contains the best tool kit to make my work each time better and efficient, so in the mission statement, i think it must include guys like me. About the road map: I've entered in the developers mailing list just about now and my intent is help like a Beta tester and help with videos and tutorials. I'm very interested in the Gimp Gap tools. Improve the Onionskin and the main interface of Gap (wich are the most important things to the traditional animator and they doesn't actually works). Other thing, the pop ups in the transform tools some times are very annoying, i think must be another solution for them. congratulations for this great software! Daniel 2007/10/26, Alexander Rabtchevich [EMAIL PROTECTED]: Micahel Grosberg wrote: I believe Gimp's target audience should be the home user and amateur photographer, and future development in this direction should take precedence over features for the professional artist. Could I object? Currently GIMP is one and the only potential free OS tool for real graphic amateurs and professionals. As more and more people buys DSLRs the amount of users who need high quality tool for photo retouching increases. That can be added by the people who leaves Windows for Linux. And the others who can, but do not want to use this particular tool can use _many_ other simplier solutions. Dis I say Krita or F-Spot or..? -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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
So... Gimp currently has 4 major goals? - Cairo - GEGL - Add named parameters and default values to the PDB - 6 months development cycle. Wouldn't it be easier to treat them as Separate goals for separate releases? Once Cairo and GEGL (I have no idea for the Parameters feature, so apologies for not being able to say more about it) have been properly implemented, Gimp should have the foundations for rolling out features more quickly. Wanting two at the same time though seems to be asking too much, and proper implementation of GEGL in my opinion justifies one final long development cycle. Maybe something like this can be considered: Gimp 2.6: - implementation of Cairo (get this out of the way) - start background work on GEGL, by dedicating more developer resources (if possible) to actually coding GEGL without necessarily implementing it yet - bunch of other easier features to keep people happy - development cycle: 6 months to a year. Gimp 2.8: - GEGL integration - the background GEGL work that started with Gimp 2.6 should have paved the foundations for slightly faster integration - the development cycle will probably still be long, but this will be the last long release cycle. Gimp 3.0+: - with GEGL properly implemented, from now on, development cycles will be 6 months. Once GEGL has been implemented, the following features seem to be the most demanded ones: - CMYK - 16 bit - layer effects - layer groups Any one of the above could justify a minor release. Having the first GEGL-version of Gimp ship with one of the above features would justify the time spent on it, especially if the developers explain that the other features will follow fast. Having said first GEGL-version of Gimp ship with Two of the above would be fantastic. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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
On 10/27/07, Valerie VK [EMAIL PROTECTED] wrote: So... Gimp currently has 4 major goals? - Cairo - GEGL - Add named parameters and default values to the PDB - 6 months development cycle. Wouldn't it be easier to treat them as Separate goals for separate releases? Once Cairo and GEGL (I have no idea for the Parameters feature, so apologies for not being able to say more about it) have been properly implemented, Gimp should have the foundations for rolling out features more quickly. Wanting two at the same time though seems to be asking too much, and proper implementation of GEGL in my opinion justifies one final long development cycle. Maybe something like this can be considered: Gimp 2.6: - implementation of Cairo (get this out of the way) - start background work on GEGL, by dedicating more developer resources (if possible) to actually coding GEGL without necessarily implementing it yet Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. The only major point for GEGL that is currently known that would make integration with GIMP difficult, is 8bit-specific code; GEGL Ops that accept and output 8bit integral RGBA instead of 32bit float RGBA. I believe many of these can be created automatically by modifying the current code, which already handles generating float versions of porter-duff ops and blending ops. In the mean time, a single conversion op (float - 8bit int) could be made. - bunch of other easier features to keep people happy - development cycle: 6 months to a year. Gimp 2.8: - GEGL integration - the background GEGL work that started with Gimp 2.6 should have paved the foundations for slightly faster integration - the development cycle will probably still be long, but this will be the last long release cycle. Gimp 3.0+: - with GEGL properly implemented, from now on, development cycles will be 6 months. Once GEGL has been implemented, the following features seem to be the most demanded ones: - CMYK - 16 bit - layer effects - layer groups It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. (for the reference of anyone who was considering bringing this topic up ;) Any one of the above could justify a minor release. Having the first GEGL-version of Gimp ship with one of the above features would justify the time spent on it, especially if the developers explain that the other features will follow fast. Having said first GEGL-version of Gimp ship with Two of the above would be fantastic. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
