[Gimp-developer] Feedback on new rect select tool
Hi, Just tried out the new rect select tool and I have a few comments which I thought might be appreciated. First off, thanks to Bill for the work - this is already an improvement over the old rect select tool, IMHO, apart from one thing (which I'll get to later). First, Show dialog must go. I'm sure that there are people who use this dialog, both in the crop tool and here, but it's a nightmare. Second, Adjustable should be the default. It was very confusing to me that I saw the shading + handles à la crop tool, and then as soon as I released, just had a rectangular selection. The big lacking functionality is the aspect ratio/fixed size functionality from rect select. Being able to constrain the ratio of selections during their creation, and also while editing them, is very useful. One usability change which would be great, but I know that it is a lot trickier, is to have the selection be both a selection and adjustable at the same time. It would be great to be able to drag the corners (or even, why not, the edges) of a selection to move it around resize it dynamically, but have it actually be a selection if I do something like apply a filter. The question is whether the adjustableness would only apply to the last element added to the selection (ellipse, rectangle, or why not, freehand?) or to the bounding box of the entire active selection. I haven't thought a whole lot about it. In short, I think it's good, and if the tool can pick up the last remaining bits of functionality from the rect select tool, and the other selection tools behaved similarly (at least the ellipse tool), I'd be in favour of it being the 2.4 rect select tool. Of course, if something better comes along in the meantime... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Some questions
You can embed ICC profiles in JPEG files. The lcms distribution contains code to insert and extract profiles: check the sources for jpegicc and friends. Thank you John, I have hust checked that code and compared it to the actual GIMP jpeg part. As I can see, actually Gimp does not support the embedding of ICC profiles in JPEG files. Is there any official mantainer of this part?. I can try to modify this part myself and submit a patch, but I don't want to interfere with anyone's work. Jordi ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
Am Samstag 12 Februar 2005 13:54 schrieb Sven Neumann: Hello Sven, it's fine to getting aware of the beginning of the cms development in the Gimp! We'll need this stuff :-) Color management on Windows would ideally be implemented using the color management capabilities of the operating system. Same on Mac OS X where ColorSync should be used. For now we will however concentrate on the LCMS based implementation and of course we will make sure that it works on all supported platforms. Hello Sven, like you mentioned before in other cms related threads, it is an good idea to make it possible to choose the CMM the user prefer. And also I thing it would be the best choice to use for default the OS specific build-in CMM, as you said above. Users will be able to load color profiles from whatever location they wish. I don't think we need to provide a way to specify profile directories. GIMP will remember the last location you loaded profiles from and if you need to use multiple profile directories, it's easy to add bookmarks for them. That's a very good point, and it comes with the behavior we should keep in touch with: A very flexible implementation of cms into the gimp. I like this idea. This goes however way too much into details yet. We can figure out such usability concerns as soon as the basic framework has been put in place. When do you expect the basic framework will be up for discussions regarding the usability? ICC profiles can be stored in TIFF files. The parasite is just the way that GIMP deals with this information. I don't know off the top of my head if JPEG allows to embed ICC profiles. Since I would rather get back to work on the color management implementation, I kindly ask you to look that up in the JPEG spec yourself. Yes, JPEG (JFIF) allows to embed ICC profiles. Also it's possible to choose CMYK as colormodel. At least JPEG2000 support this, and Photoshop is able to save normal jpeg files with an icc profile and in CMYK. It support's also clipping paths.[1] http://developer.gimp.org/standards.html has some links that you might find useful. If you know of any URLs that should be added there, let me know. It may would be useful to make a special section colormanagement, and point for example to color.org fogra.org eci.org http://www.swop.org/specifications.html etc. Kind regards Gerhard [1] http://www.jpeg.org/apps/prepress.html?langsel=en http://www.wotsit.org/search.asp?page=5s=graphics http://www.boscarol.com/pages/cms_eng/065-icc.html http://www.google.de/search?hl=deie=ISO-8859-1q=jfif+cmyk+icc+site%3Acolor.orgbtnG=Suchemeta= ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] plugin defaults - where to put them?
My plugin have various user selectable configuration settings. Right now, I use ~/.gimp-2.2/gimprc to store the defaults. I am not sure if it is correct to fill up gimprc in this way, and no setting is saved between sessions. So, Is there a better/recommended way for plugins to store such data in the gimp? Is there a recommended practice for saving loading such settings? Thanks, Joseph ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feedback on new rect select tool
On Sunday 13 February 2005 08:25, David Neary wrote: Hi, Ok... I say I agree fully with Dave's comments. I'd have something to add here: One usability change which would be great, but I know that it is a lot trickier, is to have the selection be both a selection and adjustable at the same time. It would be great to be able to drag the corners (or even, why not, the edges) of a selection to move it around resize it dynamically, but have it actually be a selection if I do something like apply a filter. The question is whether the adjustableness would only apply to the last element added to the selection (ellipse, rectangle, or why not, freehand?) or to the bounding box of the entire active selection. I haven't thought a whole lot about it. Great - I think that if the selection was not replaced by the rectangle, the adjustment could be - for the time being - on the boundng box of the selection. I say for the time being - because the olny satisfactory UI I can perceive for this is to have each element on the selection adjustable - that means that sucessive erctangle selects, ellipse, free hands, select by colors, use of quickmask, etc, should be individually pickable and re-edited. The only way this functionality might be implemented is if - or rather - when - Pippin's suggestions for what could be called an 'action' model for the drawables is implemented. That is - the GIMP would record not only the actuall raster data, but each action performed on a drawable as a data independent model. That would also allow for a great macro recorder, out of order undo/redo, per drawable undo/redo - and this - a fully readjustable selection. Maybe we could put some more thinking in how this proposed model would be achievable. Cheers, Dave. Regards, JS -- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin defaults - where to put them?
Pepster wrote: My plugin have various user selectable configuration settings. Right now, I use ~/.gimp-2.2/gimprc to store the defaults. I am not sure if it is correct to fill up gimprc in this way, and no setting is saved between sessions. So, Is there a better/recommended way for plugins to store such data in the gimp? Is there a recommended practice for saving loading such settings? We are developing a mechanism for plug-ins to save settings and configuration information for GIMP 2.4, but there isn't one in 2.2. Using gimprc will certainly not work. Right now if you need to do this, the only approach is for the plug-in to create and read its own files, and there is nothing that would prevent this. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Some questions
Quoting Jordi Canton [EMAIL PROTECTED]: Thank you John, I have hust checked that code and compared it to the actual GIMP jpeg part. As I can see, actually Gimp does not support the embedding of ICC profiles in JPEG files. Hi. I'm actually working on getting such things into Inkscape now, and have been looking into details on things. Just to let you know... there are a few different ways things might be embedded. In general they can get three different types of metadata: EXIF, XMP and IPTC. (I'm just getting up to speed on EXIF and IPTC and with jpeg, since my initial focus was with SVG and XMP). XMP is Adobe's new way to embed metadata in files. They've based it on standards, and seem to be trying to play nice with everyone. It uses RDF for the how to store data, and then gets into details of what to store. Additionally, even IPTC data is getting into XMP. http://www.adobe.com/products/xmp/main.html The spec itself is at http://partners.adobe.com/public/developer/en/xmp/sdk/xmpspecification.pdf Currently page 75 covers embedding XMP in Jpeg. And this might lend a little insight http://support.adobe.com/devsup/devsup.nsf/docs/53348.htm I'm not sure how much current tools are using those, but its adoption is speeding up. Oh, and I know I've seen the image thumbnail show up in XMP for a while now. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Some questions
Jon Cruz wrote: Just to let you know... there are a few different ways things might be embedded. In general they can get three different types of metadata: EXIF, XMP and IPTC. (I'm just getting up to speed on EXIF and IPTC and with jpeg, since my initial focus was with SVG and XMP). GIMP is actually pretty far along toward dealing with this: see http://wilber.gimp.org/~raphael/metadata/ and a lot of related discussion in the archives of the list. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin defaults - where to put them?
Hi, Pepster [EMAIL PROTECTED] writes: My plugin have various user selectable configuration settings. Right now, I use ~/.gimp-2.2/gimprc to store the defaults. I am not sure if it is correct to fill up gimprc in this way, and no setting is saved between sessions. So, Is there a better/recommended way for plugins to store such data in the gimp? Is there a recommended practice for saving loading such settings? GIMP 2.4 will provide a framework that allows plug-ins to store their settings. For now you will have to either implement it yourself, use gimp_gimprc_set() or a global persistent parasite. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Some questions
On Sun, 13 Feb 2005 [EMAIL PROTECTED] wrote: Quoting Jordi Canton [EMAIL PROTECTED]: Thank you John, I have hust checked that code and compared it to the actual GIMP jpeg part. As I can see, actually Gimp does not support the embedding of ICC profiles in JPEG files. Hi. I'm actually working on getting such things into Inkscape now, and have been looking into details on things. Just to let you know... there are a few different ways things might be embedded. In general they can get three different types of metadata: EXIF, XMP and IPTC. (I'm just getting up to speed on EXIF and IPTC and with jpeg, since my initial focus was with SVG and XMP). None of these metadata types has anything to do with embedding ICC profiles in JFIF JPEG files. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin defaults - where to put them?
Thanks for takng care of this issue in 2.4. BTW, how far is it to 2.4? (approx) -Joseph Sven Neumann wrote: Hi, Pepster [EMAIL PROTECTED] writes: My plugin have various user selectable configuration settings. Right now, I use ~/.gimp-2.2/gimprc to store the defaults. I am not sure if it is correct to fill up gimprc in this way, and no setting is saved between sessions. So, Is there a better/recommended way for plugins to store such data in the gimp? Is there a recommended practice for saving loading such settings? GIMP 2.4 will provide a framework that allows plug-ins to store their settings. For now you will have to either implement it yourself, use gimp_gimprc_set() or a global persistent parasite. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Hi, a quick followup to myself... I couldn't resist and spent some time on the threaded pixel-processor code . The first part of the TODO I posted yesterday is done, the code has been ported to gthread. This makes the thread functionality available on all platforms supported by gthread-2.0. I have also cleaned up the code further while porting it to gthread. It seems to be working rather well now, but I haven't done any benchmarking so far. There's now a #define to control the ratio between created threads and tiles that are to be processed. This parameter definitely needs tuning. Also tried to port the code to GThreadPool but it turned out to be not as trivial as I expected. The current code blocks until all threads are returned and it is not trivial to implement this behaviour with GThreadPool. So this part, the more interesting part of the TODO, is still open. I don't want to put more time into this, but I think it would definitely make sense to introduce a thread pool to cut down the number of thread creations. Any volunteers? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 13.02.2005, at 22:10, Sven Neumann wrote: I couldn't resist and spent some time on the threaded pixel-processor code . The first part of the TODO I posted yesterday is done, the code has been ported to gthread. This makes the thread functionality available on all platforms supported by gthread-2.0. If you need someone to run benchmark tests, let me know. I've a dual-Opteron under my desk, a dual-G4 and a dual-G5 at my disposal, a HT P4 machine in my near, and can easily fetch a dual-SPARC workstation oder some bigger irons if needed. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
On 13.02.2005, at 22:43, Sven Neumann wrote: Doing benchmarks is exactly what would have to be done at this point. The main problem is probably what to use as a benchmark. One could write a script-fu and run that using batch-mode. I've been using the coffee stain effect fu in the past but this is *way* to random to deliver sensible results for timing tests; it is somewhat useful for profiling though which is not what we would want to do in this case, though. It would be interesting to have numbers that show the effect of the num-processors gimprc option and it would be interesting to see how the value of the TILES_PER_THREAD #define influences the performance. So far I can only guess that the cost of thread creation is perhaps a problem. If anyone can deliver some good benchmark I'd be happy to run it on a few machines with the CVS version Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Re: Some questions
Am Sonntag 13 Februar 2005 21:27 schrieb Bob Friesenhahn: None of these metadata types has anything to do with embedding ICC profiles in JFIF JPEG files. Hello Bob, that's true, but the icc profiles are may be stored in a similar way, at least icc is listed here: http://www.ozhiker.com/electronics/pjmt/jpeg_info/acronyms.html It's also a good recource of image file specs (jpeg tiff metadata and Adobe PS related stuff): http://www.ozhiker.com/electronics/pjmt/jpeg_info/index.html Kind regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sun, Feb 13, 2005 at 02:19:52AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: people in the past, too. I would call this hidden, yes, and I still think it's a usability problem, because 1.2 clearly worked better. Marc, I shouldn't argue with you Maybe, but I think sensible arguments are in the best interests of everybody. but I have to disagree with you here. I don't think you need to, I completely agree with you on this: Behaviour of keybindings was dependant on the window that has the focus. I don't know if this has ever been a problem to you but have you ever seen a new GIMP user struggling with this? Keybindings are vital in an application like GIMP. If Ctrl-Z for Undo doesn't work in the Layers dialog because it's only bound to the image window, then you end up moving focus between windows only to make keybindings work. This is how GIMP 1.2 worked. For a newbie it takes a long time to [it hasn't been a problem to me because I use focus-follows-mouse, but the current focus behaviour is not a problem to me either, so I agree that this change is a good one] I do not agree with that, though: The GIMP 1.2 behaviour was a major pain in the ass. Parts of it were, others weren't. Dynamic keybindings worked much better. Also, this does not mean that all the other changes were good, certainly the file chooser was step backwards (it has good features, but all in all it's a step backwards, I guess just temporarily until the gtk+ filechooser gets fixed, but still, right now, it is, and it's not clear how this will be fixed, or wether it will be fixed at all). get used to this behaviour. Sorry, but 1.2 didn't clearly work better. It did work better at least with respect to keybindings in the layers dialog. Right now, changing keybindings needs to be done in a very awkward way - first search what you want in another menu, with different menu ordering and contents, and then the keybinding isn't even reflected in the layers dialog menu. Yes, I think 1.2 worked clearly better in the layers dialog, and what you say doesn't really invalidate the arguments in favour of that view. With GIMP 2.2 you can finally concentrate on your work instead of tracking what window your keypress might go to and what action it will cause there. I never had that problem with 1.2, but with 2.2, I have the problem of having to go to different places to change keybindings, and not having reminders where I need them. To users like me, this is an absolute step backwards. I don't think it's right to penalize the workflow of some users to improve it for others, just because their style is differently, unless you absolutely must choose between options that cross each other out. For example, you can switch between dynamic keybindigs and mnemonic use via preferences, but the 2.x dynamic keybindings are not as useful as the 1.2 DKB were, and I do not think that penalizing people who prefer that way (remember, it once was a killer feature of the gimp, just as shell-like tab completion in the file dialog was) is reasonable. I don't understand you. I described various problems. You claim they are simply not there. Why? You may have not realized, but I didn't ignore your problems at all. Well... so far... you... did... mostly... but that's ok if you forget them or I was unclear, as long as I have the chance of explaining it, which is difficult if you get insulted for trying... but... well... your choice. There's a new thread I opened to discuss file-chooser performance and I I thought the file-chooser performance was gtk+ related and off-topic here? At least that was my original impression :) The real problems is unintituive behaviour, for example having to press a hidden key combination to get a text entry, or the fact that the file-chooser doesn't display the results of the (lengthy) file scan. If I have to wait for it, it should at least display the results, or do the file scan only when I want it displayed. That *seem* to be gimp-specific problems, at least nobody claimed something different. If these are gtk+-dependent, too, then I'd be glad to know about it, but other apps, such as gedit, which use the filechooser have different behaviour, so I guess it *is* customizable and gimp-specific. realized that we should have more pre-defined shortcuts in the Layers dialog. So I added shortcuts for New Layer and Duplicate Layer actions last night. Cool! That is something that I would have liked to have, too, but it's not as important to _me_, as I can define my own shortcuts. However, defining them has become awkward in 2.2, and this is still an open issue, I think. Having more predefined bindings is nice, but not a solution. Also, please see that my problem was not that you ignored problems per-se, but that instead of arguing logically (even socially) over problems you start insulting people, which usually results in the thread ending prematurely, which IMHO really lokks like ignoring, worse,
Re: [Gimp-developer] plugin defaults - where to put them?
On Sun, Feb 13, 2005 at 11:35:05AM -0800, William Skaggs [EMAIL PROTECTED] wrote: My plugin have various user selectable configuration settings. Right now, I use ~/.gimp-2.2/gimprc to store the defaults. I am not sure if it is correct to fill up gimprc in this way, and no setting is saved between sessions. So, Is there a better/recommended way for plugins to store such data in the gimp? Is there a recommended practice for saving loading such settings? We are developing a mechanism for plug-ins to save settings and configuration information for GIMP 2.4, but there isn't one in 2.2. Using gimprc will Actually, gimp-perl does that (or at least did that) since the 1.x days, by either using gimp_set_data (obsolete) or global persistent parasites, which has the desired effect. Gimp::Fu uses that mechanism, so all perl plug-ins using Gimp::Fu als their UI have persistency for their settings. That has worked without problems so far. (Actually both global and per-image defaults, so when opening the same plug-in on an image it will use the values used before, if possible, or the global last-recently-used ones). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Also, this does not mean that all the other changes were good, certainly the file chooser was step backwards (it has good features, but all in all it's a step backwards, I guess just temporarily until the gtk+ filechooser gets fixed, but still, right now, it is, and it's not clear how this will be fixed, or wether it will be fixed at all). We agree to disagree here then. IMO, with GTK+-2.6 the file-chooser is a lot better than what we used to have in GIMP 1.2. There are still a few issues like the lack of bookmark naming (which is being fixed in GTK+ HEAD) and I'm not satisfied with the behaviour of completion in the Ctrl-L popup. But then, thanks to typeahead, I hardly use the popup any longer. The file-chooser did indeed have a lot of problems in the GTK+-2.4 versions. By now though it has reached the point where it is superiour to the 1.2 version. To users like me, this is an absolute step backwards. I don't think it's right to penalize the workflow of some users to improve it for others, just because their style is differently, unless you absolutely must choose between options that cross each other out. Well, we had to choose between using the deprecated GtkItemFactory which is not any longer maintained or using GtkUIManager. GtkUIManager finally allowed us to introduce global shortcuts and it is the base for the much extended set of actions that you can bind keyboard shortcuts to in GIMP 2.2. Or other input events, say your mouse wheel or a MIDI controller... There's a new thread I opened to discuss file-chooser performance and I I thought the file-chooser performance was gtk+ related and off-topic here? At least that was my original impression :) The discussion about the design of the file-chooser widget is off-topic since we are not in the position to change it. Performance problems in the GIMP filechooser however are of course a GIMP problem until we have clearly figured out that it is not a GIMP problem but a GTK+ one. I do however believe that the problem you are reporting has already been fixed in GTK+ version 2.4.14. But there's another thread to discuss this. Please use it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
