[Gimp-developer] why is the Toolbox not an ordinary dockable dialog?
The subject says it all: in the present situation (especially in the current git version), the Toolbox is definitely not an ordinary dockable dialog, but much less than before. In previous versions, closing it terminated GIMP, and it was the main support of the menu bar, which probably explained its special status. Now, the Toolbox remains special, but I don't know why. In single-window mode, it cannot be moved, nor closed. A dockable placed in the same dock behaves differently, especially it cannot show the image selection, not automatically follow it. Are there serious reasons for this special behavior? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] behavior of Shift+digit
In the Image - View menu, the Zoom sub-menu contains entries for 1:2, 1:4, 1:8, and 1:16 zooming factors. They are supposed to be associated with shortcuts Shift+2, Shift+3, Shift+4, and Shift+5. With the current git version and Ubuntu 10.04, I get a different behavior: - Shift+ a digit on the main keyboard does not have any effect. - If the auxiliary keyboard is num unlocked, no effect at all, with or without Shift. - If it is num locked, Shift+2 divides by two the current zooming factor, Shift+8 doubles it, Shift+3 sets the zooming factor to 1:8, and Shift+9 to 8:1. Other digits are inoperant, as well as all digits when they are typed without Shift. If this is what is intended, it does not work as documented in the Zoom menu. At least the auxiliary keyboard should be mentioned. In the documentation, there is nothing about this. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
Just discovered that the clipping in the new layer modes needs more work. It's not a problem with colors that originated in sRGB, but the layer modes can easily construct colors outside sRGB, or even invisible/virtual colors. The current behavior is different from floating point/GEGL implementation. Especially when composing e.g. in Color mode onto a white layer, results differ. A red onto white will become yellow (which isn't necessarily worse than the red from floating point, as it seems to be closer to correct lightness -- but it's different.) The problem is that I have to clip twice in integer mode: once from Lab to XYZ, then again from XYZ to RGB. Widening the lab-to-xyz LUT solved the problem for red, but created strange color bandings for blue, so it probably leads to integer overflow somewhere. In other words: I'll have to work on the lab-to-rgb conversions... Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Drawing per Script
Hello, I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? When using the circle drawing with vectors I would expect that this technique can do it's work fast. But it's very slow (using a loop to set paths in those vectors). (In OpenGL for example there are Vertex Arrays that can be used to speed up drawing. Something like that in GIMP, and available for scripting would be nice.) (I also saw, that what on the GUI are Paths internally are called vectors. To make things better undesrstandable, it would make sense to give things the same name... but maybe there is more to vectors and I don't see it so far. Why are there different names?) How can I speed up my drawings without switching to C? With my Python script I need about 3 or 4 seconds just for drawing 2072 circles. This seems very slow to me. If I also would need to write pixels of a line pixel-wise, I would also await to have very slow scripts. Special functions for drawing lines from within Python-plugins, that use C-speed would be fine. Gruß, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Tool options dialog
In the current git version, the Tool options dialog no longer tells the user what tool is directed by the corresponding options. If it i a Toolbox tool, we see the corresponding icon emphasized. If it is, for example, the Levels tool and we did not place its icon in the Toolbox, there is no way to know what is the current tool. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool options dialog
On 09/12/2010 05:55 PM, Olivier wrote: In the current git version, the Tool options dialog no longer tells the user what tool is directed by the corresponding options. If it i a Toolbox tool, we see the corresponding icon emphasized. If it is, for example, the Levels tool and we did not place its icon in the Toolbox, there is no way to know what is the current tool. We should fix this before we release 2.8, could you add a bug report to bugs.gimp.org so we don't forget it please? Thanks in advance / Martin -- My GIMP Blog: http://www.chromecode.com/ Automatic tab style and removed tab title bar ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. This is just quick and dirty solution which I hacked this afternoon. But it works very well. I opened bug report yesterday concerning GIMP's invalid path-line drawing ( https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that things will change really slow:-). I was quite depressed yesterday, but in the middle of night I got an idea :-) If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!? If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. Here is a SVG file for testing: http://www.qsoftz.com/mirza/wp-content/data/gekkoman_unwrapp.svg Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop: http://www.qsoftz.com/mirza/wp-content/data/Screenshot.png Here is a patch: http://www.qsoftz.com/mirza/wp-content/data/0001-cleared-duplicate-lines.patch btw. I used slower variant 'g_hash_table_find' instead of 'g_hash_table_lookup'. I know that this is a flaw. I will try to fix it. And yes, rendering of this kind of optimized path is much better than without optimization. I'm able to work and paint (realtime) over this path. I'm very happy! :-) About patch: The code affects processing only if paths are merged while importing (checked Merge imported path). I'm not sure that I placed code at right place. I'm not sure how it will affect importing of other entities from SVG file (curves, ellipses etc.). But, I'm pretty sure that this is a good way in direction of merging paths. It is useless if they are not flattened into only one path, without duplicated points. The algorithm: As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke). That's it. This method can be applied even if paths are merged from GUI. I will further test this approach with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too. But, I'm not sure about this. I didn't tested it. I would like to hear you opinions. Cheers, Mirza. www.qsoftz.com www.qsoftz.com/mirza ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
On 09/12/2010 11:37 AM, Rupert Weber wrote: Just discovered that the clipping in the new layer modes needs more work. Problem solved. Not reposting the patch for now to keep the noise down, as I'm sure there will be other small issues. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
Am Sonntag, 12. September 2010 schrub Mirza Husadzic: [...] The algorithm: As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke). That's it. This method can be applied even if paths are merged from GUI. I will further test this approach with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too. But, I'm not sure about this. I didn't tested it. I would like to hear you opinions. I haven't looked into your patch nor do I know how GIMP actually draws the paths. So if I'm writing nonsense – just ignore me. ;-) As I understand the previous mails the problem is that each path is painted using XOR so an even number of paths over a single pixel will be invisible. What about not drawing on the canvas using XOR but maintaining an extra 1-bit- buffer on which the paths are painted and which in the end is XORed to the image? I don't know if that's too much overhead or if it doesn't make any sense at all. It just came to my mind … Cheers, Mirza. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a slight problem that has existed for some time
On Fri, 2010-09-10 at 15:28 +0200, Olivier wrote: the new dialog is open under the current window In Edit-Preferences-Window Management, try changing the option, Hint for Docks and Toolbox, to Utility Window or Keep Above. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
