[Gimp-developer] Po-files in SVN have a strange problem
Hello, As I was working on Esperanto translation for gimp, I noticed that it (eo.po).. and the following .po files (in /po/ directory), have a strange problem with a message. pl fr ru ja lt oc One or two messages (the english part) refer to 'Colorsize' where they should refer to 'Colorize' (as in 'save colorize settings' and 'export colorize settings'). I assume this was caused by typos in the source code, later corrected. However, when I ran an update, this message was not removed or replaced by a correct one.. or even left alone while the correct message was added. So, perhaps these files need to be manually changed to correct the message. That's what I did for eo.po (in my local copy) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Windows - Image display actions potential improvement
Hello, I just noticed a usability issue with the 'Windows' actions related to image displays in SVN... They seem to be attached to specific displays, rather than to the Nth display out of the current displays. Currently, we can switch quickly between some active images by using dynamic keyboard shortcuts and assigning keys (I like '234567' -- a number key for each of 6 open images) to them as we open them. We can also quickly switch between alternate views of an image (eg 100% with selection, layer borders, guides and rulers visible; or 'final rendering size' (50%) without anything but the image visible. This is quite powerful (try it out!). However.. any keyboard shortcuts assigned only last until you close that image -- because each display number only gets generated once each GIMP session (they are generated sequentially starting from 1). This is why the usage pattern above requires you to use Dynamic Keyboard Shortcuts and assign shortcuts as images are loaded. My proposal is to have these actions index the available image displays sorted by their display ID -- this amounts to, if you have keys 123456789 assigned as shortcuts for the 1st .. 9th display, and 9 displays open, pressing 1 will raise the oldest display, pressing 9 will raise the newest. If you close some, 8 or 7 could end up being the shortcut for the newest display I believe that both the current code and the proposed amendment are somewhat surprising : the former because shortcut assignments get 'lost', the latter because shortcuts become assigned to different images when an image is removed from the middle. I am sure that my proposed amendment is both less surprising, and a usability enhancement that anyone who works with more than a few images at once will appreciate. I plan to make a patch to try this within a week. As for why I sent this here, I'm interested to know: Is there a reason for the current behaviour? Are there better approaches? (i'm thinking here of GIMP-GAP .. when you're using it, display IDs get very high quickly, because each time you switch frames, the display number is incremented. Thus, my proposal could be a little more surprising to GAP users, because changing the frame you're editing will bump an animation so it becomes the 'newest' image.) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Po-files in SVN have a strange problem
Hi, On Tue, Aug 5, 2008 at 5:06 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Mon, 2008-08-04 at 23:25 +0930, David Gowers wrote: One or two messages (the english part) refer to 'Colorsize' where they should refer to 'Colorize' (as in 'save colorize settings' and 'export colorize settings'). I assume this was caused by typos in the source code, later corrected. That is correct. However, when I ran an update, this message was not removed or replaced by a correct one.. or even left alone while the correct message was added. How exactly do you update the po files? ../intltool-update eo However, when I run an update on any of the other .po's, it works fine (no 'Colorsize' message any more, 'Colorize'). Strange. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows - Image display actions potential improvement
The attached patch allows you to open several images, assign keyboard
shortcuts to them, and these shortcuts will persist, so that if you
assigned '1','2','3' to the first, second, and third image, you could
continue to switch between the first, second, and third opened image
with 1, 2, and 3.
Because of the caveat below, this is currently no better than
associating the actions directly with display IDs, rather than
associating the actions with indices into the list of displays.
Caveats :
*Currently implemented in a hackish way
*Does not cope properly with closing images -- it breaks all the
actions following and including the closed image.. So say you closed
image #3, and you had already opened a 4th and 5th, the actions for 3,
4, and 5 would break.
I'm unclear as to the exact cause of this. Does anyone here know?
Index: app/actions/windows-actions.c
===
--- app/actions/windows-actions.c (revision 26398)
+++ app/actions/windows-actions.c (working copy)
@@ -171,21 +171,114 @@
windows_actions_image_notify (display, NULL, group);
}
+static int windows_display_get_index (GimpDisplay *display)
+{
+ gint index = gimp_container_get_child_index (display-gimp-displays, GIMP_OBJECT (display));
+/* gint nchildren = gimp_container_num_children (display-gimp-displays);*/
+ return index;
+
+}
+
+static GimpDisplay *windows_display_get_nth (GimpContainer *displays, gint index)
+{
+ gint nchildren = gimp_container_num_children (displays);
+
+ if (index = nchildren)
+return NULL;
+
+ return GIMP_DISPLAY (gimp_container_get_child_by_index (displays, index));
+}
+
+static void windows_display_update_action (GimpActionGroup *group, GimpAction *action, GimpDisplay *display)
+{
+ const gchar *uri;
+ gchar *filename;
+ gchar *basename;
+ gchar *escaped;
+ gchar *title;
+
+ if (display == NULL)
+{
+ g_object_set (action,
+viewable, NULL);
+return;
+}
+
+ uri = gimp_image_get_uri (display-image);
+
+ filename = file_utils_uri_display_name (uri);
+ basename = file_utils_uri_display_basename (uri);
+
+ escaped = gimp_escape_uline (basename);
+ g_free (basename);
+
+ title = g_strdup_printf ([%d] %s-%d.%d, GPOINTER_TO_INT (g_object_get_data (G_OBJECT (action), index)),
+ escaped,
+ gimp_image_get_ID (display-image),
+ display-instance);
+ g_free (escaped);
+
+ g_object_set (action,
+label,title,
+tooltip, filename,
+viewable, display-image,
+context, gimp_get_user_context (group-gimp),
+NULL);
+
+ g_free (filename);
+ g_free (title);
+}
+
+
static void
windows_actions_display_remove (GimpContainer *container,
GimpDisplay *display,
GimpActionGroup *group)
{
GtkAction *action;
+ gint index = windows_display_get_index (display);
+ gint num_children = gimp_container_num_children (display-gimp-displays);
gchar *action_name = g_strdup_printf (windows-display-%04d,
-gimp_display_get_ID (display));
+num_children);
+ /* Step unu complete! (always remove the highest numbered action) */
+
+ /* find the relevant index by looping through the ActionGroup, finding the action with matching 'display' data-item */
+
+ if (index == -1)
+{
+ /* nun index will always be -1 when a display is being removed -- by the time this function is reached, it is no longer in the active displays list */
+ g_warning (index == -1!);
+ return;
+}
+ g_warning (WAdr:Index == %d Nch == %d, index, num_children);
action = gtk_action_group_get_action (GTK_ACTION_GROUP (group), action_name);
+ /* Step du: adjust all following actions when an action is removed. */
+
if (action)
-gtk_action_group_remove_action (GTK_ACTION_GROUP (group), action);
+{
+ gint i;
+ g_free (action_name);
+
+ for (i = index; i num_children-1; i++ )
+{
+ GimpAction *action2;
+ gintnextindex;
+ action_name = g_strdup_printf (windows-display-%04d, i + 1);
+ /* XXX move all index/display object_data back one slot */
+ action2 = (GimpAction *) gtk_action_group_get_action (GTK_ACTION_GROUP (group), action_name);
+ nextindex = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (action2), index));
- g_free (action_name);
+ action_name = g_strdup_printf (windows-display-%04d, i);
+ action2 = (GimpAction *) gtk_action_group_get_action (GTK_ACTION_GROUP (group), action_name);
+ g_object_set_data (G_OBJECT (action2), index, GINT_TO_POINTER (nextindex));
+ windows_display_update_action (group, action2,
+
Re: [Gimp-developer] bug #464466: lanczos corner artifacts
Hi, On Fri, Aug 8, 2008 at 7:30 AM, [EMAIL PROTECTED] wrote: On Thu, 07 Aug 2008 22:20:00 +0200, Nicolas Robidoux [EMAIL PROTECTED] wrote: A student of mine and I have put together a gimp plug-in which ENLARGES images using a method which is analogous to global cubic splines, that is, which gives results analogous to lanczos. Hi, in what way do you mean the results are analogous to lancsoz? Could you perhaps compare results of your plugin with the comparitive results on the kingfisher head shot? http://svenfoo.org/scaletest/133-9.html http://svenfoo.org/scaletest/133Z8g.png http://svenfoo.org/scaletest/133C8g.png and/or the pixel graphic: http://svenfoo.org/scaletest/133-8.html http://svenfoo.org/scaletest/133Z8g.png http://svenfoo.org/scaletest/133C8g.png these two images scaled to 133% seemed to be the best cases in that test 133.33% please. If you use just 133.00%, the result will be the wrong dimensions and so, uncomparable. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Po-files in SVN have a strange problem
Hello, On Sat, Aug 9, 2008 at 2:38 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Fri, 2008-08-08 at 19:55 +0400, Alexandre Prokoudine wrote: This is probably because there is bug in your version of intltools or that version is too old. For instance, the version from Ubuntu 8.04.1 doesn't deal with msgctxt reliably. It's very selective about which messages to put into a PO file and which not. For Hardy, you can download a newer version from http://svenfoo.org/hardy-backports/ Thank you Sven, I installed that. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tagging of Gimp Resources project status
Hi Aurimas, I've tried this out and read your PDF, this is what I think: The basic idea is good and neatly implemented. It needs more consistency upon integration with SVN HEAD. For example * 'Next Brush' / 'Previous Brush' actions don't move through the filtered view, they move through the entire set of brushes, including ones that aren't currently shown. Personally, most of the selection of resources I do occurs when no dialogs at all are visible, just the image window, so this makes tagging much more of a real benefit for me. * brush selector button and pattern selector button in tool options is unfiltered We would need a notion of 'current brush filter','current pattern filter', 'current gradient filter'... and it needs to apply globally, so that navigating to the next or previous item works, and filtering occurs for all brush/pattern/gradient selection popups. PDB-wise, plug-ins need to be able to filter resources by tags, and it should be easy to get the e.g. 'current brush filter' for use in filtering. As it is, this helps me a lot in organizing my palettes, and I hope to see it committed to SVN HEAD :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On-canvas text-editing GSoC project - report
Hello,
On Wed, Aug 20, 2008 at 5:27 AM, Daniel Eddeland [EMAIL PROTECTED] wrote:
Google Summer of Code Project: Improve the text-tool in GIMP
By Daniel Eddeland (Skalle)
In Gimp 2.4 and earlier versions, the text tool uses an external
editor window, which is inconvenient in several ways. The aim of my
project was to support on-canvas text editing, so that the user would
be able to act directly on the image, instead of using a separate
window. The code has been placed in a special SVN branch, called
soc-2008-text, which anybody who has SVN access can download and
build.
What have I done?
*The first thing I did was to port the text-core in gimp to use
PangoCairo functions instead of Freetype2. This port will be helpful
for some work in the future which will make the text-tool faster.
*After porting I started working on on-canvas text editing. That
means you'll be able to type, delete, copy and paste text on-canvas
instead of using the text-dialog. I have added settings to tools to
give them the ability to grab the keyboard input (which is obviously
needed if you want to type).
With these settings the tool can block
the input from the rest of the interface, so that typing a P will
add a P to the current text object instead of switching to GIMP's
pencil tool. Input is possible typing normally on a regular keyboard,
I am really impressed with that...
but also using alternate input methods like SCIM.
*I have added a text-cursor, mouse-actions and graphical feedback for
text-selections, so the text-tool would feel as ergonomic as possible
like other text applications.
*I have added a context-sensitive menu which appears when you
right-click on the text-area. It has options such as copy/cut/paste
and changing input methods.
And this.
GIMP really needs more time put into UI infrastructure such as this.
The UI team seem to think variation in right-click menu is confusing,
but IMO several tools would benefit from it (for example, when you're
painting fullscreen, you might want to change the FG color without
needing to exit fullscreen to use one of the dockables.) and we do not
have any alternatives currently -- some of the HUD-style propositions
on gimp-brainstorm.blogspot.com look good, but will require much more
extensive use of Cairo by GIMP than there currently is.
Skalle? Are you the same Skalle that I ('neota') once did a CPC
pixel art collab/exchange with ?
(ie. same person as
http://www.wayofthepixel.net/pixelation/index.php?PHPSESSID=7ab74a703bfc3ae3032d9d6d3f16e69ftopic=514.msg6714#msg6714?)
David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl babl trouble
Hello, On Sun, Aug 24, 2008 at 4:12 PM, [EMAIL PROTECTED] wrote: Hi, I just pulled a clean svn gimp and wanted to build with --prefix=/usr/local , I supplied this arguement to autogen.sh and it output both that prefix and --prefix=/opt/gimp , which I presume is the new default. ... No. Something is wrong. Gimp does not specify any such thing. In fact, I always had the impression that for SVN versions, prefix defaulted to /usr/local. This may actually be a problem with your autotools. I can verify that mine accept my chosen prefix (/usr) without saying anything more, I'm running autoconf (GNU Autoconf) 2.61 automake 1.10 or 1.7 (yes, both.. normally programs use 1.10, some need 1.7) on an installation of Ubuntu Hardy Heron. What versions are you running (automake --version / autoconf --version) on what distribution? I had the same behaviour from babl , although it did install where I requested bash-3.2#ls /usr/local/lib babl-0.0 libbabl-0.0.la libbabl-0.0.so.0 pkgconfig fpc libbabl-0.0.so libbabl-0.0.so.0.23.0 X11 However, now I try to build gegl it can't find babl: checking pkg-config is at least version 0.9.0... yes checking for BABL... configure: error: Package requirements (babl = 0.0.22) were not met: No package 'babl' found Why can't it see a correctly installed babl? /usr/local/bin is in $PATH. ... Does the binary directory have anything to do with it? After all, babl installs no binaries, only libraries (ie /usr/local/lib/) BTW INSTALL says to run ./configure which does not exist, should this be corrected to say autogen.sh ? configure exists for releases -- it's generated by autogen.sh. This is normal for autotools-based software building. Hope that helped, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Font are small of tool-box in gimp 2.5.4
On Thu, Sep 18, 2008 at 11:21 PM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 8:34 AM, Choi, JiHui wrote: Hi, Sven Now I know. But in some environments, it's not convenient. If your system supports cleartype fonts, it may be good, but if not and you use non-english, it'll be very bad. I think this matter is a big problem enough to give up to use GIMP. Hi, It's impossible to please everybody, and fonts antialiasing is mainstream these days, working fine on most systems. Font antialiasing is not sane in some circumstances -- it simply blurs the glyphs in these cases. For example, complex characters as shown in Choi's screenshot. if there is SIGNIFICANT detail in antialiasing, then the font is too small. if there is NOT significant detail in antialiasing, the font should also look ok without antialiasing. I would also argue that turning off antialiasing makes virtually everything more readable, even when the glyphs are simple. Anyway! The appropriate solution to this may be to package a simple alternate theme which makes the offending fonts larger, and install this theme if the language might require it (eg Japanese, Chinese, Korean) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] provide transparent color
Hi Maciej, On Wed, Sep 24, 2008 at 3:47 PM, Maciej Pilichowski [EMAIL PROTECTED] wrote: Hello, From: bgw [EMAIL PROTECTED] How does draw with transparency differ from using eraser tool with x% opacity? Pencil and eraser are counterparts of course, but I wished for transparent color, not just transparent pencil (yes, it exists, and it is eraser). From: Chris Moller [EMAIL PROTECTED] Doesn't the Eraser Tool do what you need? Yes and no, see above. (Though maybe some interesting effects could be gotten with an erasing airbrush that accumulated in the alpha channel. Exactly! Because once you have transparency as your color you could use any tool which works with colors. From: Simon Budig [EMAIL PROTECTED] Well, historically new stuff always had to proove that it is better than the old stuff and I personally don't think that is a bad thing. Of course. So how do you want to work with transparency? What should happen if you have a semi-transparent red and you paint on top of blue? Good example, because it shows how natural transparent color is. The answer: you should get exactly the same effect if you have blue color and paint on top of semi-transparent red. It depends on mode and used tool. Currently it gets blended on top of the blue resulting in some kind of violet and that is a widely used feature to do natural looking paintings. I understand your proposal, that you actually want to have a semi-transparent red in the image after painting? Both answers are really correct -- see above. How is your new feature supposed to interact with tablets with varying pressure devices like tablets? Right now you can map the pressure information pretty naturally to the opacity. Your replacement approach for alphacolors would directly influence the images alpha channel, making it pretty tricky to lift off the pen without leaving a transparent spot (tablets tend to add some events at the end et the stroke with very low pressure). I don't understand that paragraph: a) the transparent color is not a replacement, I clearly stated this in original post, it is addition to the color palette b) don't pick the transparent color if you don't need it How is your replacement approach supposed to work with multiple layers? Again, it is not a replacement. There is no way to achieve the effect you describe without it being a replacement effect. This is because it violates the normal behaviour of alpha, which is a specifier of opacity for a particular color; without a color, an alpha value is meaningless. Also, the 'semitransparent color' usage and the 'erasing' usage are directly contradictory. Semitransparent color could work in a fairly normal way, erasing would have to replace the underlying pixel values rather than blending them. If you want to develop this idea further -- personally I think it's an interesting idea -- I believe it will be necessary to discard the notion of a 'color' which is fully transparent, ie. the notion of being able to erase just by 'color' adjustment. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] /Filters/Render/Stroke to SVG...
Hi Paul, On Fri, Sep 26, 2008 at 2:19 AM, paul taney [EMAIL PROTECTED] wrote: When it doesn't register, is there any console output from GIMP? Chris Ive got things working now and use numpy to convert bluelines to SVG lines or a python tuple that gets written out. It could be of general interest for vectorizing if it treated a selection. But I am converting scanned stripcharts, and the ink is blue... One y per x is all I need, and there would be a slick way to do that with numpy; Im just using a stride for line thinning. The part I dont understand is this; I pass my bluemask to (Fremlins) write_out(drawable, image) as the image, it fails the assertion and does not post... numpy.array((image*256).round(0),B) Which assertion fails? def write_out(drawable, image): by John Fremlin byte_image = numpy.array((image*256).round(0),B) # B is a ubyte width = drawable.width height = drawable.height bpp = drawable.bpp sys.stderr.write(write_out::drawable.width=%i drawable.height=%i drawable.bpp=%i\n % (width, height, bpp)) pr = drawable.get_pixel_rgn(0, 0, width, height, True) assert(byte_image.size == width * height * bpp) pr[:,:] = byte_image.tostring() You are passing an RGB array to this function. Are you certain that your destination drawable does not have an alpha channel (thus requiring you to pass an RGBA array)? David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] /Filters/Render/Stroke to SVG...
Hi Paul. On Fri, Sep 26, 2008 at 8:56 AM, paul taney [EMAIL PROTECTED] wrote: Why does he multiply the image by 256 and elsewhere divide image/256? He's expecting an image with values ranging 0..1. If the values you are providing are 0..255, you'll need to remove both of those. Which assertion fails? Line 207: assert(byte_image.size == width * height * bpp) fails, right before the blit. def write_out(drawable, image): by John Fremlin byte_image = numpy.array((image*256).round(0),B) # B is a ubyte width = drawable.width height = drawable.height bpp = drawable.bpp sys.stderr.write(write_out::drawable.width=%i drawable.height=%i drawable.bpp=%i\n % (width, height, bpp)) pr = drawable.get_pixel_rgn(0, 0, width, height, True) assert(byte_image.size == width * height * bpp) pr[:,:] = byte_image.tostring() # blit You are passing an RGB array to this function. Are you certain that your destination drawable does not have an alpha channel (thus requiring you to pass an RGBA array)? I have added a test for that, as best I know how; but it still fails at 207. if drawable.has_alpha: img = gimp.Image(width, height, RGBA_IMAGE) new_layer = gimp.Layer(img, new_layer_name, width, height, RGBA_IMAGE, opacity, NORMAL_MODE) else: img = gimp.Image(width, height, RGB_IMAGE) new_layer = gimp.Layer(img, new_layer_name, width, height, RGB_IMAGE, opacity, NORMAL_MODE) This will not necessarily help, because your vanderwalt() routine is still producing an RGB image always. David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Transparency in transform tools
Hi Guillermo, On Fri, Sep 26, 2008 at 10:56 AM, Guillermo Espertino [EMAIL PROTECTED] wrote: I'm testing Gimp 2.5.4 and it's amazing. I know it's late for a feature request, but I think it's worth to discuss about the current behavior of the new feature present in the transform tools: the ability to set the transparency of the layer or selection being transformed. I think it would make more sense to apply that transparency to the original layer instead of the transformed instance. In most cases, the original occludes the background, and what the user usually wants is to see the transformed object on the final context. This situation becomes particularly annoying when scaling down images. The larger original doesn't let the user see the real background, where the transformed image will end up. So this new transparency function would be much more helpful (in my oppinion) for the original, not for the target. Somebody suggested in the IRC channel that the original should simply dissapear, because the user wants to see the result of the transformation, not the original. This has already been discussed, it is far from trivial to implement, mainly because the preview must be drawn directly on the canvas. When the display code is ported to GEGL, this may become practical. (hiding the original layer during the operation is possible, but because of the simplicity of the preview rendering, the preview may look much different that you'd expect.) I think that there are lots of situations where having a reference of the original, un-transformed image would be very useful, but not that useful if having it doesn't let me see the background. So, what do you think about applying the transparency to the original insteado of applying it to the transformed image? Gez. David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python
Hi Samuel, On Mon, Sep 29, 2008 at 7:40 PM, Samuel [EMAIL PROTECTED] wrote: I have been at the GIMP IRC channel and they told me that C is faster than Python if I want many pixel ops. I wrote a test plugin in Python which copies a layer pixel per pixel to another one and it needs several minutes for a vga picture. Sven has covered how to access tiles faster. There is also the following approach, which does not require any knowledge of tiles and is quite simple. If you are copying large areas (eg 1024x1024), a tile based approach may be more appropriate. # create a pixel region: pr = sourcelayer.get_pixel_rgn (0, 0, sourcelayer.width, sourcelayer.height, False, False) # then you read all pixels from that region pixels = pr[:,:] # create another region on the destination pr2 = destlayer.get_pixel_rgn (0, 0, destlayer.width, destlayer.height, True, False) # and write the stored pixels pr2[:,:] = pixels Every pixel has now been copied (on my machine, this takes less than a second for a VGA picture). Note that the above assumes certain similarities between the layers -- ie. they are of the same dimensions,and they either both have an alpha channel or they both lack an alpha channel. It also assumes they are of the same type (as in, both belonging to an RGB image, or both belonging to an Indexed image, or both belonging to a Greyscale image) HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Automatically save curves file
Hi Kent, On Sat, Oct 4, 2008 at 8:47 PM, Kent Tenney [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 7:01 PM, [EMAIL PROTECTED] wrote: Quoting Kent Tenney [EMAIL PROTECTED]: will there be provisions to apply a saved curve to an image without the gui? If you have the GIMP Animation Package installed, you will find a plug-in named 'plug-in-wr-curves' which permits application of a curves file. I don't have GAP installed. I've installed Gimp 2.6 on Ubuntu 8.04 using .deb's from http://www.getdeb.net/app/Gimp will apt-get install gimp-gap do what I want? AFAIK yes. or is there more to it? (I don't want to try and see for fear of breaking things) There should be nothing to break -- GIMP-GAP is only a suite of plugins, if you install it and find it doesn't work, it's easy enough to remove it using Synaptic. Thanks, Kent HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Automatically save curves file
On Sun, Oct 5, 2008 at 1:20 AM, Kent Tenney [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 7:01 PM, [EMAIL PROTECTED] wrote: Quoting Kent Tenney [EMAIL PROTECTED]: will there be provisions to apply a saved curve to an image without the gui? If you have the GIMP Animation Package installed, you will find a plug-in named 'plug-in-wr-curves' which permits application of a curves file. plug-in-wr-curves GIMP Plug-in Image/Video/Layer/Colors/ Wrapper for GIMP Curves Tool call based on Curves file Parameters run-mode INT32 Interactive, non-interactive image IMAGE Input image drawable DRAWABLE Input drawable (must be a layer) filename STRING Name of a GIMP curves file (saved by the Curves Tool) Return Values the-drawable DRAWABLE the processed layer Additional Information This Plugin loads a # GIMP Curves File, that was saved by the GIMP 2.0pre1 Curves Tool Darn, it seems this won't help, the format of the Gimp 2.6 autosaved curves file must be different than the one this plugin was written against. Yes, it certainly is. However, you can export curves in the same format as earlier GIMP versions, then you can easily apply them with wr_curves. HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, include filename with curves autosave
Hi, On Fri, Oct 10, 2008 at 5:17 AM, Kent Tenney [EMAIL PROTECTED] wrote: Howdy, I wish the gimp-curves-tool.settings file, which contains sections starting with: (GimpCurvesConfig 2008-10-03 14:34:26 (time 1223062466) (channel value) (curve ... also listed the name of the file (or 'unnamed') This is the name of the file: '' ie. no file (the only completely-accurate preservation of the curve is in the gimp-curves-tool.settings file, and unless you've explicitly exported it, no other file will contain data on that curve.) Or were you asking for a list of filenames that this curve has been exported as? fully qualified would be great, bare would be fine. Thanks, Kent HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A question about python gimpfu - home folder
Hi, On Fri, Oct 10, 2008 at 4:42 PM, Chris Mohler [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 12:24 AM, Chris Mohler [EMAIL PROTECTED] wrote: Hi list, I've been mucking around with a GIMP plugin a la python, and I have a question: Is there a method to discover the GIMP version and/or ~/.gimp folder that works across platform (from python)? gimp.directory And (in the interest of being a pest) a follow-up: Can I attach a plug-in to the Palettes sub-menu? Other python plugins, like the 'Sort palette' plugin, certainly do. HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new feature request - gimp
Hi, On Tue, Oct 21, 2008 at 3:05 PM, Jim Michaels [EMAIL PROTECTED] wrote: Please send only plain-text mail to this list. HTML mail annoys people here. Akima spline curves give drawing freedom, at least some kind of interpolating spline curve where you can just simply lay the points down and the curve follows along the points - I have a hard time getting bezier curves to do what I want. It's like Alice in wonderland using a flamingo for a mallet in a game of croquet. unweildly. Bezier Curves were introduced into Windows NT. It seems like a lot of paint programs began including Bezier Curves as a drawing method after that. They should have also introduced Akima spline curves into Windows. I am not saying take Bezier curves out - I am saying Add Akima Spline curves, or the bettered (modified) version of Akima Spline curves that doesn't react as much. At least some type of interpolating spline curve where you just lay the points down and the curve follows the points. Akima spline curves are cool. just put points along where you want the curve. simple. you just need more points around sharp edges, or you get a ringing effect around that area. (See discussion and visuals link). part of the challenge of using Akima spline curves is that the first 2 data points must be faked or dropped. same goes with the last data point. this can be taken care of with some simple engineering tricks. http://en.wikipedia.org/wiki/Spline_(mathematics) Wikipedia article on Spline curves (mathematics). This does not cover the Akima Spline, which keeps its curve along the data points rather than just near it like a B-spline curve does. http://www.cse.unsw.edu.au/~lambert/splines/ demonstration of the various curve types in action. (requires Java) play with the spline curve for a while (delete the existing points other than 0 first to get started) http://demonstrations.wolfram.com/BSplineCurveWithKnots/ B-Spline curve with Knots (can be active demo) GNU Scientific Library Reference Manual http://www.network-theory.co.uk/docs/gslref/InterpolationTypes.html book - has Akima Spline amp; Cubic Spline. See also http://www.gnu.org/software/gsl/manual/html_node/Interpolation-Types.html GNU Manual http://www.iop.org/EJ/abstract/0031-9155/18/4/306 PDF file from medical site on akima and spline methods and its associated errors. Recommendations for fixing the significant overshoot on abrupt changes, and suggestion to use more closely spaced points around those regions. must purchase. http://portal.acm.org/citation.cfm?id=116810 The Akima Univariate Interpolation Method (spline) article from the acm. by Hiroshi Akima. requires web account and probably money to buy the PDF article. http://www.iue.tuwien.ac.at/phd/rottinger/node60.html Equations for Akima Spline http://www.alglib.net/interpolation/spline3.phpdiscussion and visuals of Akima Spline and its drawbacks. also has source code in C++, C#, Delphi, VB6, Zonnon. http://www.sciencedirect.com/science?_ob=ArticleURL_udi=B6TYG-414N645- 2_user=10_rdoc=1_fmt=_orig=search_sort=dview=c_acct=C50221_version=1_urlVersion=0_us erid=10md5=17dccffcfa40e5b420c7c377fc24b5f7 pay-for article on some sort of improved-smoothness spline. Shape of data is preserved. http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=1814objectType=file MATLAB model. Jim Michaels [EMAIL PROTECTED] http://JesusnJim.com I looked through all your links, and while Akima splines seem interesting, I think we would need some visual demonstration of their performance in the way they'd be used in GIMP (most likely, contour tracing to 'cut out' objects), before we could agree that they were an appropriate thing to add. We would also need to be absolutely sure that they are unencumbered by patents. Personally, I think if we were to support a 'on-points-only' type of spline, Cornu (aka clothoid) splines would be a better choice, especially as they are already implemented in Inkscape and FontForge, and a free software affiliated person (Raph Levien) owns the patent (pending?) on it and has implemented a GPL library (libspiro) to assist in their usage. They also seem to be more predictable than Akima splines. However they do require you to mark corners explicitly. http://www.youtube.com/watch?v=3OaLZuFZxdk provides an example of how they work and look (video of manipulating Cornu splines in Inkscape) Their effectiveness can be checked by (with a development version of Inkscape) 1. Open inkscape and import a bitmap to trace 2. Roughly outline the object with a polygonal stroke 3. Using node editing, select all nodes and set them smooth. 4. Add the 'spiro' live effect to the path. 5. Add nodes or set segments linear, as needed, until you are satisfied. I've just done that, for cutting out pelicans from a photo. my initial polygonal sketch had 67 nodes. The final shape had 96 nodes, so I needed to add 29 nodes (43%).
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, On Wed, Oct 29, 2008 at 10:37 PM, Claus Berghammer (Bugzilla) [EMAIL PROTECTED] wrote: Hello Gimp Developers, Sven Neumann asked me to move this thread from the Users mailinglist, to developers. The original discussion can be found here: http://www.nabble.com/Scaling-in-Gimp-2.6-is-much-slower-than-in-Gimp-2.4-to20185528.html There is also a Bug in Bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=557950 I extended my benchmarks and visual comparisons I've made so far, to give an more detailed view on whats the problem. Short said, it is all about: Why is 2.6 so slow on scaling, compared to 2.4. ;-) See yourself: Benchmarking GIMP Scaledown Performance: Scale layer from 5000x5000px - 2500x2500px: Is this a representative usage? I did a comprehensive benchmark (http://svenfoo.org/scaletest/) which showed the new code produced markedly better defined results, on pictures ranging from 277x185 to 1600x1200. That comprehensive benchmark was one of the main reasons this patch ended up in 2.6. In particular, you can see that the new algorithym preserves detail more accurately (see the Circular Zone plate, test image #6) Conclusion: Since the difference in processing time shows up even with interpolation None, I think that the origin is not within the interpolation algorithms (or at least not only). Instead it seems to me (of course I'm just a user, not a developer), that there are some changes in the resize algorithm itself. If I understood the stuff in bug #464466 right, the scale routine is used several times in the interpolation routine. So, if the resize routine is slow, it accumulates in the interpolation routine. The speed penalty in 2.6 is more than just noticeable, and keeps some users away from 2.6. Also interesting is, the different alignment in 2.4 and 2.6. Why are layers that are processed with 2.4 always a bit left and above its 2.6 counterpart? 2.4 had some problematic behaviour on borders leading to the entire result often being wrongly offset. It isn't really a problem, but if this isn't technical necessary, the behavior should be identical, to maintain project compatibility between different users/gimp versions. As Sven Neumann already mentioned (see http://bugzilla.gnome.org/show_bug.cgi?id=557950), the upscaling could be made faster easily. But I think, that there is room for performance improvements in downscaling too... It is certainly possible. As Sven pointed out, we should probably first address the craziness of using interpolation routines (linear, cubic, lanczos) for downscaling. Do we even need to offer a choice of algorithym for downscaling (Box filter of appropriate size should be ok, except for None, which should be obvious.)? This is tricky because the user can downscale and upscale in one pass (eg. 150% scale on x axis, 80% on the y axis) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi Liam, On Fri, Oct 31, 2008 at 11:55 AM, Liam R E Quin [EMAIL PROTECTED] wrote: On Fri, 2008-10-31 at 01:44 +0100, Joern P. Meier wrote: [...] By the way, what kind of downscaling is used for the view zooming? GEGL is doing that. GEGL is not doing that. GEGL certainly has display-pyramid code, but GIMP does not currently use GEGL's implementation, it has it's own (app/base/tile-pyramid.c) As far as I understand it, each step of the image-pyramid is produced by averaging every 2x2 pixel square from the step above it. If the zoom matches exactly one of the stored pyramid levels, it is used directly in the display.. Otherwise, it interpolates between the next smaller step and the next bigger step to produce the display. HTH, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-fu primitive wishlist: islands, integrals/sums, and data files
Hi Adam, On Fri, Oct 31, 2008 at 9:51 PM, Adam C Powell IV [EMAIL PROTECTED] wrote: Greetings, I am working on an image processing plug-in (which I'll offer for upstream contribution BSD-licensed), and would really like to have a couple of primitives that I can't find. One is finding islands in an image: take a channel and create new layers each with one contiguous region in the channel. So if the channel has ten islands, create ten new layers, each with one of the islands. Since this could be unwieldy (too many new layers), one new layer with one island would suffice; one could then process that island layer, subtract it from the original, and move on. Another is integrals: zero, first and second moments, or alternatively, integrals/sums of channel intensity, x- and y-weighted intensity, and x^2, y^2 and xy-weighted intensity. This lets me fit an ellipse to an island, and then display major and minor axes. Finally, opening and storing data files. I'd like to be able to create a CSV file with statistics of the islands: size, centroid, aspect ratio (major/minor axis ratio), major axis orientation. One could then further process these statistics in a spreadsheet or other program. I can do the first two in scheme, though it would be slow, but tolerable for my needs. I don't see a script-fu primitive which would let me do the last. If there are other packages which can do this, that would be helpful. But having it in the same program/UI as GIMP, with all of its other image manipulation tools, and with its presence across platforms, would be even better. I'd love to have your ideas. It sounds like you might find working with the combination of Gimp-Python, NumPy and SciPy more effective. integration,definitely. Islands, possibly (a browse through http://scipy.org/scipy/scipy/browser/trunk might help you to find out. And Python has a CSV module as standard. I had the impression that writing external files was not supported by Script-Fu; I'm sure Kevin Cozens could tell you. Hope that helps, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi, On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts [EMAIL PROTECTED] wrote: peter sikking wrote: Martin wrote: The darker and lighter modes have been internally sorted based on how much they tend to affect the image, see end of mail. is it then a coincidence you got implicitly almost every of these groups labelled up by their first item (Lighten, Darken, Overlay, Difference)? it is a good thing this is happening. No it was not a coincidence, I deliberatly put Lighten, Darken and Overlay at the top of their groups to make them act like labels. Difference was more or less a coincidence though, but you're right in that it makes a nice label as well since you can end up with completely Different colors when using modes in that group. the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual. Good point, I will swap those. Actually, I didn't understand why you grouped them with Difference (even given your explanation of 'can produce completely different colors'); I would have grouped them with Overlay, since they both provide darkening ( on one side of 128) and lightening (on the other side of 128), In general I like these new groupings a lot, particularly the positional correlation (add/sub, dodge/burn) I'm a bit puzzled as to why Multiply is paired thusly with Screen -- Divide is closer to being the opposite of Multiply IMO (from a visual inspection div(mul(x)) and mul(div(x)) are closer to the original x than scr(mul(x)) or mul(scr(x)) ) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Snapping options should be remembered across sessions
Hi, On Sun, Nov 2, 2008 at 4:59 AM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: Hi, As requested to discuss it on list rather than on bgo... It would be quite useful to be able using same snapping options (snapping to guides, grid, canvas border, active path) across sessions, preferably by defining defaults via Edit - Preferences - Image Windows/Appearance like UI. What exactly are you trying to propose here that is not included in the functionality of Edit - Preferences - Image Windows/Appearance itself? Are you trying to say 'remember the options that a particular image has, across sessions'? I'm baffled. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
On Sun, Nov 2, 2008 at 12:02 AM, Martin Nordholts [EMAIL PROTECTED] wrote: David Gowers wrote: Hi, On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts [EMAIL PROTECTED] wrote: Actually, I didn't understand why you grouped them with Difference (even given your explanation of 'can produce completely different colors'); I would have grouped them with Overlay, since they both provide darkening ( on one side of 128) and lightening (on the other side of 128), I had them grouped with Overlay for a while but ended up putting them under Difference since Grain Extract can look very similar to Difference. And from an aesthetic point of view it looks better to have 3 and 3-groups than 5 and 1-groups. I'm a bit puzzled as to why Multiply is paired thusly with Screen -- Divide is closer to being the opposite of Multiply IMO (from a visual inspection div(mul(x)) and mul(div(x)) are closer to the original x than scr(mul(x)) or mul(scr(x)) ) One have to differentiate between mathematical similarities of the blending formulas and the effect the modes have on the colours we perceive. From this point of view Multiply pairs better when Screen than with Divide. No, that's what I was saying -- from VISUAL inspection.I didn'c check the numbers, just how it looked when I painted in div mode then multiply mode with same color, etc.. Actually from this point of view Divide and Subtract should probably be moved to the Difference category. They can produce completely new colours as well. Addition doesn't really have a counterpart (Addition is Linear Dodge in PS and GIMP has no Linear Burn counterpart). Linear Burn is exactly a reversed Subtract, yes? that is, result = dest - (1-src) rather than result = dest - src ? The problem with introducing Linear Burn to GIMP is the name; what should it be called? One alternative would of course be to call Addition Linear Dodge instead. I like that. For layer mode usage. (for painting, the current Subtract behaviour is more symmetric with Add than Linear Burn would be.) I think it would be wise to plan for eventually having the layer modes list something like the toolbox tools currently are: a large set, with each item individually hideable (and new ones installable -- though they would have to be visually differentiated so the user knew they might not load in a 'baseline' GIMP install). Perhaps the disabled ones could be left in an 'others' submenu to leave them accessible while reducing their interaction speed cost. So, we could consider which ones would be the least valuable, and let that inform the sorting. For example: * Color mode is markedly inferior to PS Color mode (because it uses HSL, rather than LAB colorspace, the transference is not only of color data but some intensity data.). It's important to include some Color mode, however if we can get Color mode working in LAB space, we should probably show that by default and hide old style Color mode. * Also consider doing the same with Hue and Saturation, using a polar transform of LAB (ie. LCH), hue transfers only the angle, saturation transfers only the radius. Personally, only about 7 of the layer modes have any use to me: normal dissolve difference multiply divide grainMerge grainExtract ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Snapping options should be remembered across sessions
Hi, On Sun, Nov 2, 2008 at 8:22 AM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Sun, Nov 2, 2008 at 12:36 AM, David Gowers wrote: It would be quite useful to be able using same snapping options (snapping to guides, grid, canvas border, active path) across sessions, preferably by defining defaults via Edit - Preferences - Image Windows/Appearance like UI. What exactly are you trying to propose here that is not included in the functionality of Edit - Preferences - Image Windows/Appearance itself? David, if you take time to actually read what is written above, you'll see that it says snapping options, not Show rulers or Show layer boundary. Believe me, there *is* a difference :) Oh, I thought we had that already. Apparently not. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi, On Sun, Nov 2, 2008 at 9:34 AM, Martin Nordholts [EMAIL PROTECTED] wrote: I understand what you mean now. We are not doing the same kind of paring though. You are pairing layer modes that are cancelling each other out while I am paring layer modes that give opposite effects on lightness. To convince yourself of that Multiply pairs with Screen in the latter case, create an image with two layers, one with a vertical black-to-white gradient and the other with a horizontal black-to-white gradient (so that all possible combinations of channel intensities are blended). Then examine the result of having the top layer first set to Multiply and then to Screen. Yes, I see what you mean. Overall effect rather than mathematical relation. Linear Burn is exactly a reversed Subtract, yes? that is, result = dest - (1-src) rather than result = dest - src ? Yes exactly, Linear Burn is result = dest - (1 - src) = dest + src - 1 * Color mode is markedly inferior to PS Color mode (because it uses HSL, rather than LAB colorspace, the transference is not only of color data but some intensity data.). It's important to include some Color mode, however if we can get Color mode working in LAB space, we should probably show that by default and hide old style Color mode. I agree, the current Color mode and friends can give pretty unexpected results. Personally I don't think I will put much effort in that in the near future though. I'm assuming that the separate layer modes will eventually separate into their own files for reasons of speed, in which case this is trivial to implement; request LAB color as the input format, apply normal blending to A and B channels, leave L channel unchanged from dest. I would certainly be willing to do that when the time comes. Personally, only about 7 of the layer modes have any use to me: normal dissolve difference multiply divide grainMerge grainExtract Interesting, what do you use Grain extract and Grain merge for? Colorized shading/lighting. The nice thing about grain merge and extract is they have a very regular effect on intensity, which means it is comfortable to eg. paint using Grain Merge on a Grain Merge-moded layer. If you start with a layer filled with color #808080 which is neutral: Say you have colors #606060 and #a0a0a0, painting with one of those will lighten the layer by 32; if you swap colors you will be darkening the image by 32. Providing layer opacity == 100%, that will result in a literal change of 32 to the underlying image. That predictable symmetry helps. Also, you may have noticed, Grain merge creates complimentary colorings; eg Grain merging bright yellow #90 makes the image brighter and yellower, Grain extracting the same bright yellow makes the image darker and more blue. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi, On Sun, Nov 2, 2008 at 6:46 PM, Martin Nordholts [EMAIL PROTECTED] wrote: David Gowers wrote: I'm assuming that the separate layer modes will eventually separate into their own files for reasons of speed, in which case this is I meant separate operations, here. trivial to implement; request LAB color as the input format, apply normal blending to A and B channels, leave L channel unchanged from dest. I would certainly be willing to do that when the time comes. I have ported almost all (only Soft light pending) layer modes to a GEGL operation. It is yet unclear if this will be eventually used or if it will more serve as a reference implementation, but in any case would improvements to how Color behaves best be written against this file: http://svn.gnome.org/viewvc/gimp/trunk/app/gegl/gimpoperationpointlayermode.c?view=markup Yes, I've looked at that. It might be possible to implement Color mode there... If prepare () is called at the time I hope it is, then I can set format to 'CIE Lab alpha double' (the only implemented LAB format in BABL) as needed when COLOR mode is in use. This would achieve a correct result. As you can see the whole thing is very readable and patchable. If you in GIMP trunk do View - Use GEGL then the above GEGL operation is used for compositing the projection. Once the port is complete I will write a mail to this list explaining some important differences between this op and the legacy layer mode compositing. BR, Oh, what does BR stand for? I've read that several times and still none the wiser :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Recording user actions
Hi Viktor, On Mon, Nov 3, 2008 at 7:43 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: This has been discussed somewhat in the very distant past. The last A lot, actually: http://bugzilla.gnome.org/show_bug.cgi?id=51937 discussion ended with the verdict that recording user actions (and playing then back later) would not be possible without rewriting the Gimp core. Specifically the PDB (procedural database)-- currently, only some things (like plugins) that show up in the UI are actually called through PDB.. Rockwalrus was working on a library 'libpdb' at some point, which was supposed to implement important functionality for PDB (default values; named parameters) to allow this to happen. However, he vanished from GIMP development some time ago, as you can see: http://freshmeat.net/projects/libpdb/ Something like libpdb would help; However the real issue is simply the size of the job, and how to present the implementation to the user when it is only partially complete. So now that things are moving to GEGL, I'd like to resurrect this feature request. From what I remember back in photoshop 6, one could pretty much push a button and record everything that is being done on an image. Then, when a new image is opened, those actions are played on it. With GEGL, would it be possible to do something like this (as easy as just pressing a button, instead of learning a scripting language)? GEGL has a little to do with this. It will effect how easy it is to record changes to the image structure. ... there are more actions than just image-structure modification. For example creating a new view, adding colors to a palette, or copying the selected region. It will have some effect, by itself it could not even come close to 'making it possible' though. Basically, it's a pretty big job, in which GEGL has relatively minor relevance. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi vabijou, On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 [EMAIL PROTECTED] wrote: peter sikking wrote: the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual. I would also like to see a dynamically updated list at the top of the list that shows the last 3-5 used blend modes under a heading of Recent:. This may be outside the scope of the OP's original suggestion, but for many users there are a select few modes that are used frequently, and having to dig through a long list slows things down. I am such a user, and I say: This is a change I do not want, it would reduce my working speed further. This is because of the way recently-accessed lists work -- the most recent is at the top. This means unless I am constantly selecting *the* most recent (instead of eg. 2nd most recent), where I have to click to achieve the same result changes, because my choice reorders the list. In conjunction with locking functionality (so that your later choices no longer change the order or content of the recent-list), this could be effective. I would honestly like similar locking functionality for the recent-filters-list .. the constant disordering is just so confusing and slow that I usually find it faster to select from the original menu path.. which defeats the purpose. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi Joao On Wed, Nov 5, 2008 at 12:15 PM, Joao S. O. Bueno [EMAIL PROTECTED] wrote: David, as far as filters are concerned, I'd strongly, and that means __strongly__, suggest you to use keyboard shrotcuts to get to your filters. This is definitely important. I'm working on it. It takes time to arrange keyboard shortcuts efficiently; I have a color-coded SVG of a keyboard with every important function arranged nearby. Mapping them to keys takes a lot of thought. Yes, stopping ytour work to configure keyboard shortcuts is a major pita, and that is why most people donṫ do it in any software, even knowing it is possible. However, GIMP has setup a unique feature that was once available to all GTK+ applications: dynamic keyboard shortcuts. I've tried dynamic keyboard shortcuts, and in my experience they result in the same effect as the filters recently-used menu. You assign them on one image, then go to another image and find they are wrong. Or you use the wrong one, or accidentally reassign a really important shortcut (like Undo.). IME, the limit of dynamic shortcuts is the ability of the user to remember them.. my limit seems to be about 1. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hello Martin, On Sun, Nov 9, 2008 at 4:36 AM, Martin Nordholts [EMAIL PROTECTED] wrote: 2. With a 100% opaque Addition mode layer put on top a completely transparent layer, the resulting composite becomes 100% opaque containing the unblended Addition mode layer pixels when using GEGL, but completely transparent when using legacy compositing. Ah, so if I want to make the result preserve the alpha of the underlying layer, I'll need to do that via layer mask? FWIW, since you changed the meaning of the layer modes, is this a good time to make compositing gamma-correct? Currently, GIMP blends pixels as if they had gamma == 1.0, whereas the typical is sRGB (approximation of gamma 2.2). I thought GIMP would do this as it was switched over to GEGL; it doesn't currently. Evidence: 1. Create a new square image (with sRGB profile or no color profile) 2. Fill with black 3. Add another layer 4. Draw a radial gradient white-transparent 5. Set layer mode to Addition 6. Toggle 'View-Use gegl' on and off. The result is identical; rather than showing a linear blend white - black, an exponential blend (ie sRGB) white-black is shown. Small example images attached, 'wrongblend.png' and 'rightblend.png'. IMO it is correct for GIMP to produce results similar to 'rightblend.png' when GEGL use is enabled. The current plan is to have add kind of compatibility rendering mode so that old .xcfs will render the same as in old versions of GIMP also when using GEGL. In this case, we should definitely aim to have gamma-correct blending. Legacy compatibility for gamma can be done by binding our current behaviour (pretend the data is gamma 1.0 while it really isn't) to the 'legacy rendering' option (presumably auto-triggered on detection of legacy XCFs) David attachment: wrongblend.pngattachment: rightblend.png___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hello Martin, On Mon, Nov 10, 2008 at 8:18 AM, Martin Nordholts [EMAIL PROTECTED] wrote: Hi David David Gowers wrote: Ah, so if I want to make the result preserve the alpha of the underlying layer, I'll need to do that via layer mask? Exactly, masking should generally be performed *after* blending with the new layer mode compositing model. Cool, I like this, it certainly is more consistent :) FWIW, since you changed the meaning of the layer modes, is this a good time to make compositing gamma-correct? Yes definitely. In fact, layer mode compositing with GEGL _does_ work on data with gamma = 1.0. That is, the layer mode blending occurs on color data in the babl format RaGaBaA float, i.e pre-multiplied, linear light 32 bit per channel RGBA. The reason you don't see a difference when toggling Use GEGL is that now during development the source data, namely the data from the tiles of the TileManagers of the GimpDrawables, are treated as if containing color data in the babl format RGBA u8, i.e. linear light 8 bit per channel RGBA. A more correct assumption would be R'G'B'A u8, i.e. Thank you for explaining that, it was just what I suspected :) I'll see what happens when I make that change :) (apparently just one line, app/core/gimpprojection.c:391, is needed to be changed to implement this now :D) gamma corrected RGBA. The long term goal is of course to make sure color space conversions are correct throughout the whole image processing pipeline, taking into account the current color profile of the image etc. So eventually we need to be able to construct on-demand babl_formats which utilize arbitrary profiles, and have babl depend on lcms to get a acceptably quick transform between those and the standard spaces? And recognize the use of standard colorspace profiles (eg sRGB, linear-light RGB) so we can get faster processing for them? David -- Reticience and self-censorship is a farce. The deceiver does not himself know the truth, anything that he holds back he holds back not only from others but from himself. Fuck censorship. I yam what I yam. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hi, On Mon, Nov 10, 2008 at 9:18 AM, David Gowers [EMAIL PROTECTED] wrote: I'll see what happens when I make that change :) (apparently just one line, app/core/gimpprojection.c:391, is needed to be changed to implement this now :D) This was slightly more complex than I said. Somewhat hackish diff attached. It effects color tools as well as compositing. (that may be controversial, since it changes the meaning of existing Levels, etc.. tool settings. It does mean you can do a proper linear inversion, and recoloring with the Curves tool is a good deal more intuitive than before. (recoloring with 'colorize' is VASTLY better than before -- the output actually is good quality :)) Easiest way to see the color-tool difference is to make a greyscale gradient and use the Levels tool (set output minimum to 255 and output maximum to 0, then toggle 'Colors-Use Gegl') It exposes a bug in either the 'threshold' op, or babl. Try it with default settings, on a greyscale B-W gradient, and notice #ff becomes black rather than white Of course, this does not fix the various places where we refer to values in range 0...255 (eg Threshold dialog) where really, we should use 0..1 or 0...100. IMO adjustment step-size needs to be carefully thought out -- 1/255. (0.0039215686274509803) is actually wrong (because the adjustment is done in linear space; the correct minimum step size is 0.00030352698354883752) Lastly! I don't know whether this merges shadow-tiles in linear-light RGB or not. It appears that it does, but I haven't run proper tests yet :) I am amazed and excited how easy this was :D David -- Reticience and self-censorship is a farce. The deceiver does not himself know the truth, anything that he holds back he holds back not only from others but from himself. Fuck censorship. I yam what I yam. Index: app/core/gimpimagemap.c === --- app/core/gimpimagemap.c (revision 27590) +++ app/core/gimpimagemap.c (working copy) @@ -536,7 +536,7 @@ gegl_node_set (image_map-input, tile-manager, image_map-undo_tiles, - linear, TRUE, + linear, FALSE, NULL); gegl_node_set (image_map-shift, @@ -544,9 +544,12 @@ y, (gdouble) rect.y, NULL); + + /* XXX it's not clear to me whether linear should be FALSE or TRUE here. + I just went with the nicer-looking output */ gegl_node_set (image_map-output, tile-manager, gimp_drawable_get_shadow_tiles (image_map-drawable), - linear, TRUE, + linear, FALSE, NULL); image_map-processor = gegl_node_new_processor (image_map-output, Index: app/core/gimpdrawable-operation.c === --- app/core/gimpdrawable-operation.c (revision 27590) +++ app/core/gimpdrawable-operation.c (working copy) @@ -76,12 +76,13 @@ input = gegl_node_new_child (gegl, operation,gimp:tilemanager-source, tile-manager, gimp_drawable_get_tiles (drawable), -linear, linear, +linear, !linear, NULL); + /* XXX is above correct? input and output are nonlin, op is lin */ output = gegl_node_new_child (gegl, operation,gimp:tilemanager-sink, tile-manager, gimp_drawable_get_shadow_tiles (drawable), -linear, linear, +linear, !linear, NULL); gegl_node_add_child (gegl, operation); Index: app/core/gimpprojection.c === --- app/core/gimpprojection.c (revision 27590) +++ app/core/gimpprojection.c (working copy) @@ -388,7 +388,7 @@ gegl_node_new_child (proj-graph, operation,gimp:tilemanager-sink, tile-manager, gimp_projection_get_tiles (GIMP_PICKABLE (proj)), - linear, TRUE, + linear, FALSE, NULL); gegl_node_connect_to (graph, output, Index: app/core/gimpdrawable.c === --- app/core/gimpdrawable.c (revision 27590) +++ app/core/gimpdrawable.c (working copy) @@ -1227,7 +1227,7 @@ NULL); gegl_node_set (drawable-source_node, tile-manager, drawable-tiles, - linear, TRUE, + linear, FALSE, NULL); return drawable-source_node
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hello, On Mon, Nov 10, 2008 at 12:50 PM, David Gowers [EMAIL PROTECTED] wrote: Lastly! I don't know whether this merges shadow-tiles in linear-light RGB or not. It appears that it does, but I haven't run proper tests yet :) No, it doesn't. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modifier key to create new layer from floating selection
Hi, On Thu, Nov 20, 2008 at 6:41 AM, Daniel Hornung [EMAIL PROTECTED] wrote: Hi, in case it's not too late (meaning a brand-new floating selection replacement is to be implemented soon), I have a small proposal to make the current behaviour a bit more user-friendly: While working on a floating selection, clicking outside the floating selection with a modifier key pressed (Alt seems to be free for that at the moment), a new layer should be created in the same way as pressing the new layer button in the layers dialog. Current status: When the mouse is outside the floating selection, a single click will anchor the floating selection to its current parent layer. This behaviour is also announced in the status bar. Rationale: Creating a new layer from a floating selection is needed about as often as anchoring it (if not more often). Thus a handy way to do this without moving the mouse across the desktop should be provided. There seems to be a default shortcut for this already (Ctrl+Shit+N), but esp. for tablet users a single click would be faster. Alt+click doesn't seem to be used for anything special at the moment yet. What do you think? This is usually effectively the same as pasting (ctrl+V for most people, Insert for me). Is creating a floating selection that does not match the clipboard contents a common use case, or do we just need to document this behaviour better? David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modifier key to create new layer from floating selection
Hi, On Fri, Nov 21, 2008 at 2:34 AM, Daniel Hornung [EMAIL PROTECTED] wrote: On Thursday 20 November 2008, David Gowers wrote: This is usually effectively the same as pasting (ctrl+V for most people, Insert for me). Is creating a floating selection that does not match the clipboard contents a common use case, or do we just need to document this behaviour better? Sorry, I think there's a misunderstanding here: I proposed a mouse-driven way to create a new layer from an existing floating selection. (And not to paste the current (floating) selection into the Okay then, 'New layer' button does this (unless you also want to keep the floating layer around -- that can be done too with a bit of scripting). There is also a 'new layer' action available that you can bind a key to, that does the same thing. Kind of hinted at here: http://docs.gimp.org/en/gimp-using-layers.html being more explicit is better though. (the above page may also be out of date -- GIMP now preserves the exact shape of the clipboard rather than autocropping to hold the content in a minimal rectangle) respective layer.) And yes, that Ctrl-V anchors a copy of the current floating selection was new to me and probably should be better documented. Plus the Edit menu entry To be exact, it anchors any current floating selection before creating a new floating selection. still says Paste Ctrl+V while Paste Into (which does the same) does not have a shortcut listed. Paste Into is markedly different from Paste. Try this: 1. Open an image. 2. Edit-Copy 3. Make a circular selection 4. Edit-Paste Into Essentially, 'Paste into' uses the selection mask to mask out parts of the selection, whereas 'Paste' clears the selection beforehand. http://docs.gimp.org/en/gimp-edit-paste-into.html With 'Paste into' it's possible to quickly paste one or more things into a limited area. (I personally favor layer masking for this; however for speed of use, Paste Into is superior.) Btw, http://docs.gimp.org/en/gimp-selection-float.html still seems to be from 2.4 times (or older), I'll crosspost this fact to the gimp-docs mailing list as well. Older for sure :) Just plain confusing. I think a crossreference to http://docs.gimp.org/en/gimp-using-selections.html#gimp-using-selections-moving is also a good thing to include in the floating-selections page. (I'm pretty sure we are trying to get rid of floating selections, but I suspect we will only be free to find an adequate alternative when the projection system is completely GEGLized. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Block user interaction while a plug-in is running?
Hello Lionel, On Fri, Nov 21, 2008 at 3:04 AM, Lionel Tarazón [EMAIL PROTECTED] wrote: Hi everyone, I am currently developing a Gimp plug-in with a GTK+ user interface. My plug-in is unstable if the user modifies the image or calls other plug-ins while it is running. What version of GIMP are you using? This situation has been improved in 2.6, though there is still plenty of scope for further improvement. Is there a way of blocking user interaction over the gimp window which called the plug-in? No (and we probably would never implement it; it is pretty rude behaviour.) In the future, a locking facility to simply prevent the user from modifying an image while a plugin is running on it (or only when the plugin is actually reading/writing from/to the image) could be desirable. It remains to be seen how useful this would be in light of GEGL integration (in future, most plugins should become little more than GEGL ops.) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modifier key to create new layer from floating selection
On Fri, Nov 21, 2008 at 6:35 AM, David Gowers [EMAIL PROTECTED] wrote: Hi, On Fri, Nov 21, 2008 at 2:34 AM, Daniel Hornung [EMAIL PROTECTED] wrote: On Thursday 20 November 2008, David Gowers wrote: This is usually effectively the same as pasting (ctrl+V for most people, Insert for me). Is creating a floating selection that does not match the clipboard contents a common use case, or do we just need to document this behaviour better? Sorry, I think there's a misunderstanding here: I proposed a mouse-driven way to create a new layer from an existing floating selection. (And not to paste the current (floating) selection into the Okay then, 'New layer' button does this (unless you also want to keep the floating layer around -- that can be done too with a bit of scripting). There is also a 'new layer' action available that you can bind a key to, that does the same thing. Oops, I see you originally suggested modifier-clicking to create a new layer. Sorry, I do not agree with that proposition, it seems too fiddly to me -- esp. because there is no reliably free modifier key. (Alt is only unused by paint, transform (and color?) tools; All selection tools use Alt.) Now if we could bind actions to mouse gestures, this kind of thing would come up less often I think. However, are you aware you could bind Alt+scrollwheel-up to new-layer to achieve a very similar result? This works properly with all tools, too, since it is genuinely non-conflicting. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Block user interaction while a plug-in is running?
Hi Lionel, On Fri, Nov 21, 2008 at 8:15 PM, Lionel Tarazón [EMAIL PROTECTED] wrote: Hi David I am currently developing a Gimp plug-in with a GTK+ user interface. My plug-in is unstable if the user modifies the image or calls other plug-ins while it is running. What version of GIMP are you using? This situation has been improved in 2.6, though there is still plenty of scope for further improvement. Actually 2.4, in which ways has it improved in 2.6? The NEWS file says: * allow plug-ins to work in parallel on different layers of the same image David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using GIMP from my own program
Hi, On Wed, Dec 17, 2008 at 6:15 AM, Pablo Yaggi pya...@alsurdelsur.com wrote: Now I have my script running, It's a simple script that produces the table-mirror effect apple does, but is it possible to check whether the interface is available or not, I mean if gimp is running with -i mode (no interface). No, there is no reliable way to do that AFAIK. Also, the script resizes the original image, is it possible to change the actual zoom from inside the script? how ? No. In python scripting this is possible using software like 'xdotool', but not in script-fu (because there is no command to shell out and run another command). After looking at your script, I suggest you also use '--no-data' commandline parameter to GIMP to cut down on memory usage and startup time, since you don't appear to use any brushes/gradients etc in your script. David -- I must create a system or be enslaved by another man's; I will not reason and compare: my business is to create -- William Blake ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Run-Mode Enums
On Fri, Dec 19, 2008 at 3:25 PM, Pablo Yaggi pya...@alsurdelsur.com wrote: So, there will be no case of somebody passing the RUN-(NON)INTERACTIVE parameter to my script, will be ? If that is the case, why the pdb browser is showing as the first parameter to my scrypt the run-mode, isn't it confusing ? Shouldn't the pdb browser hide that for scripts-fu ? Script-fu has no special status, it's just an extension to gimp In fact, Gimp-Python has been the standard recommended language interface for quite a while now. Python scripts or C plugins can call your script NONINTERACTIVE or INTERACTIVE It's simply that script-fu automatically fills in the run_mode, and provides no way for you to change it. in Python, you can call interactively like this pdb.script_fu_something (image, drawable, (more parameters...), run_mode = 0) for example. David. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Run-Mode Enums
On Fri, Dec 19, 2008 at 10:39 PM, Pablo Yaggi pya...@alsurdelsur.com wrote: Script-fu has no special status, it's just an extension to gimp In fact, Gimp-Python has been the standard recommended language interface for quite a while now. Will it be deprecated some time soon ? No, Script-Fu will not be deprecated soon. Though it's less powerful than Gimp-Python, it is more secure than Gimp-Python, and people have lots of Script-Fu scripts. Gimp-python is packed as an optional package in mi distro (mandriva) besides you need python installed, script-fu is supported in the gimp core, that sounds like python being the extension, don't you think ? No, extension is an actual idea GIMP recognises, you can find it in the plugin browser. 'Type' says 'extension' or 'plugin' or 'temp procedure' Script-fu is supported in the gimp core in the same way that Gimp-Python is: Not at all. They are both plugins. Script-fu is classified as an extension, Gimp-Python is classified as a plugin. Either can be removed from GIMP by deleting some files; I once removed script-fu because it filled my menus with items I did not have any use for. GIMP continued to work perfectly. so it will be no valid for python either, if the order of your example parameters is correct. Also the pdb-browser its a helper Speculating, and taking no action, only makes you look foolish. This has been working for a long time. The PDB is a standard mechanism that doesn't care at all about Script-fu or any other plugin. I have tried it myself. For example (commands that can be executed in Gimp-Python console): # this calls script_fu_sphere non-interactively pdb.script_fu_sphere (10, 180, 1, (1,1,1), (1,0,0)) # this calls script_fu_sphere interactively, a window will pop-up. pdb.script_fu_sphere (10, 180, 1, (1,1,1), (1,0,0), run_mode = 0) for the console (it launches from there) No, it is not a helper for the script-fu console. It's a helper for plugin programming, which means *any* plugin, whether written in C, C++, Python, Script-Fu, Ruby, Perl, or Lua. , but entering commands in the console prompt like it shows, in many cases (when calling other scripts) you get errors. That is because of the inflexible behaviour of script-fu, and the fact that GIMP doesn't care about what it's plugins do, script-fu is not special, it's just an extension to GIMP, not a vital part of it. The inability for script-fus to call other script-fus with control over run-mode is purely a design decision that the author of the Script-Fu extension made. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Guides in templates
Hi, On Mon, Dec 29, 2008 at 8:23 AM, Sven Neumann s...@gimp.org wrote: Hi, On Sun, 2008-12-28 at 19:25 +, Chris Mohler wrote: With a recent SVN I created a new image, added guides, and saved it as a template. However when I create a new image and select the template, the guides are no longer there. Is this intended behavior? I can't think of any reason not to keep the guides, but thought I'd ask... No good reason except that no one has implemented this yet. To clarify for Chris: No one has implemented [image-based templates] yet; 'Save as template' does not fully work in this sense, it doesn't save image content; It just saves all the properties that you can see in the 'New image' dialog, like size, units, dpi, and fill color. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is this option hidden somewhere, or it is not implemented ? (related to dock windows)
On Wed, Jan 7, 2009 at 4:23 AM, Cristian Secară or...@secarica.ro wrote: During the translation process I came across this tooltip: === When enabled, dock windows (the toolbox and palettes) are set to be transient to the active image window. Most window managers will keep the dock windows above the image window then, but it may also have other effects. === I wanted to check my translation on the real thing, but I also want to see this to see this option in action (sounds good to me). But I don't know where that option is. Is this implemented ? yes, it is not hidden and it is implemented. the option associated with that is 'transient docks' (in the 'interface section of the preferences IIRC) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is this option hidden somewhere, or it is not implemented ? (related to dock windows)
On Wed, Jan 7, 2009 at 8:01 PM, Cristian Secară or...@secarica.ro wrote: On Wed, 07 Jan 2009 08:15:23 +0100, Martin Nordholts wrote: Is this implemented ? yes, it is not hidden and it is implemented. the option associated with that is 'transient docks' (in the 'interface section of the preferences IIRC) and only in unstable/debug builds i.e. not in the 2.6 series. Aha, so that's the mystery. Strange, though, because I am working on the stable (2.6.x) gettext file from here http://l10n.gnome.org/POT/gimp.gimp-2-6/gimp.gimp-2-6.pot (i.e. not the HEAD version) That's probably because the disabling is done by an #ifdef GIMP_UNSTABLE, so intltools cannot detect that this string will not actually be used in the compiled binary. And of course, the option has been around since before 2.6; you should be able to find it in 2.5.x David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Artificial limitation to script fu ?
Hello, On Mon, Jan 12, 2009 at 11:22 PM, Alchemie fotografiche fotocom...@yahoo.it wrote: I believe there are some artificial limitation to the potential of script fu, derived by the exigence to categorize the scripts in 2 main categories: Previous toolbox-scripts that create a new imagine imagine script that should modify the active imagine I want to make this clear: In English language 'create a new imagine' is nonsense. imagine is a verb, as in 'I imagine I am eating a juicy watermelon'; it's an action, not a thing. 'image' is the noun, you can 'create a new image' or 'modify the active image'; All of the instances I have seen where you used the word 'imagine', 'image' was the appropriate word. Personally, I often find your use of 'imagine' confusing, so I think you could improve the readability of your posts and how many people respond by making this change. I suppose that division had some reasons to be with the old gimp layout. But now ,after Gimp 2.4 i cannot imagine any reason to maintain such artificial distinction. artificial because a script may do both and more Same script may work on the active layer,and/or create a new layer, and/or create a new imagine... Stressing the point , in general a good flexible script SHOULD do more, allowing to chose most logic input (except for render script )and the output options As now if a script is classified as image script users may overlook the fact that may also create a new imagine , because imagine scripts are not supposed to do that As now a good and flexible script that can output on a new imagine, Or/and in a new layer of the active imagine or/and on the active layer or drawable will be always erroneously classified since there is not yet in Gimp a script category as Good scripts without unneeded artificial limitations That is mostly evident with all the Logos and alpha to logo scripts 2 Groups of almost identical scripts with same names (I may assure here that most users will notice only 1 group, and ignore the other. or if by chance someone will notice the other group will believe that a different link for the same identical function since the names are identical) Solve that chaos of the Logos -Alpha to Logo script may be become much easier if there is a commune agreement that a LOGO_RELATED script should allow to output the result 1) as new imagine (with a option to have Transparency as background ... not only a solid color as now) 2) as new layer(s) pasted on the active imagine 3) as modification of the active layer 4) any combination of the options above This at least for the scripts to be bundled in Gimp, then the authors of extra scripts have obviously the freedom to offer less options if they wish, but they will get no more artificial limitation to the potential of their scripts..and no more the risk to have their script mis-categorized (again limitation are more for users then for the scripts...if a script is a Imagine-script is supposed no to to create a new imagine, so most users will not look for such option even if available) This is true. Personally I ignore script-fu.. There are some useful script-fu scripts, but most scripts seem to be about things like rendering logos, which is something I'll never use. please consider that i am not expert in script fu, i wrote only 2 scripts and that was possible only with a great help. But somehow i felt this a point to be discussed, if solved i believe also many usability issues of the Gimp Logos and Alpha to logo scripts may be solved much more easily (hopefully merging the 2 groups ) In theory, your idea sounds like a good improvement. As I said, I don't use this 'logo generating' type of script, so someone else who does might be able to offer you more useful feedback. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] trivial string bug
As I was working on i18n, I noticed the following string bug in
app/tools/gimpforegroundselecttool.c:
status = _(Rougly outline the object to extract);
So, here's a tiny patch that fixes it (attached).
David.
Index: app/tools/gimpforegroundselecttool.c
===
--- app/tools/gimpforegroundselecttool.c (revision 27899)
+++ app/tools/gimpforegroundselecttool.c (working copy)
@@ -325,7 +325,7 @@
switch (GIMP_SELECTION_TOOL (tool)-function)
{
case SELECTION_SELECT:
- status = _(Rougly outline the object to extract);
+ status = _(Roughly outline the object to extract);
break;
default:
break;
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quake/Half-Life texture wad support
On Wed, Jan 21, 2009 at 10:15 AM, Jonas Nicolaisen j.nicolai...@gmx.net wrote: Hi, I am a level designer creating Quake levels. This means I often have to work with textures. At the moment, I have to rely on obscure '90s software running via wine, which is suboptimal. There are more people like me. Quake 1/2 and Half-Life used their own formats to store data, while later games (Doom 3 etc) use zip files etc. How difficult would it be to add support for the Quake or Halflife texture wad formats to today's Gimp? I ask because there is an old discussion from 2001 on this list where Raphael Quinet was asking the same question. I don't know if anything came of that at the time. WAD2 (Quake) and WAD3 (HL) are container formats for textures. The textures themselves are bitmaps, the Quake format is sometimes simply called *.mip (mipmapped bitmap). Quake textures are typically 64x64 pixels using a single 256 color pallette across the board, unlike Half-Life, where each texture can use a different 256 colors. Background: Half-Life uses a variant of the Quake engine, Wad3 is simply the HL extension to Quake's Wad2. Wad1 was some Doom format (levels?). An open source wad extractor (command line) exists, written by Raphael Quinet and very well documented. The formats are fully known. The tool is QEU03, Quake Editing Utilities. http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qeu03.zip The user should be able to open the wad file and get a listing of all the bitmaps inside (they have simple names), then select one for editing. Afterwards, he should be able to save it directly back into the wad. For the curious, the Quake based modding scene is still very much alive, because engine and tools have been open sourced and the engine is simply brilliant. A look at http://www.quakeone.com or http://www.inside3d.com should speak volumes. A collection of texture wads is at http://www.quaddicted.com/wads/ Now about the wad support, I'd like to ask if this is now technically possible given that 8 years have passed since the last discussion, and if a developer would be willing to write a plugin? As far as I can see, it has always been technically possible; I would be surprised if any genuine and serious technical obstacles could have come up in previous discussion. The primary obstacle is simply the work involved in making a plugin to load and save these formats. I suggest you try to make one yourself. It is true that you will not be able to browse directly to the texture in the file selector, only to select the WAD file. However this is not a problem because you can immediately present the user with a listing of the WAD file and allow them to select a texture. One oddity is that the filename cannot be a 'real' filename, since it is pointing to a particular part of the WAD file. plug-ins/pygimp/plug-ins/colorxhtml.py in the GIMP source tree demonstrates how to write a I/O plugin using Python. Python is the easiest way to do this, if you find you need more speed it should be straightforward to convert it to a C-based plugin. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Advanced Interpolation
On Sat, Jan 24, 2009 at 2:48 PM, jungle agi...@cox.net wrote: Has anyone ever done any work implementing advanced interpolation schemes (NEDI or ICBI)? They provide much better results than the spatially invariant schemes present in GIMP. AFAIK no. I would probably be able to code up something, but I wouldn't be able to guarantee that it would be very efficient. Of course, these more complicated methods are much slower. ICBI matlab GPL source is available. I should be able to port it to c++. What do y'all think? NEDI looks amazing, and ICBI even more amazing; I could certainly put them to good use rather than my current rather slow/limited vectorization-based scaling system. Keep in mind: a) You should investigate implementing this interpolation method for GEGL rather than GIMP, as in the fairly near future these kinds of transformations in GIMP will be implemented through use of GEGL. b) If you want it included with the baseline GEGL distribution, it would need to be written not in C++ but in C. If you don't, then you can probably code it in C++ fine. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Advanced Interpolation
On Sat, Jan 24, 2009 at 11:47 PM, David Gowers 00a...@gmail.com wrote: On Sat, Jan 24, 2009 at 2:48 PM, jungle agi...@cox.net wrote: Has anyone ever done any work implementing advanced interpolation schemes (NEDI or ICBI)? They provide much better results than the spatially invariant schemes present in GIMP. AFAIK no. I would probably be able to code up something, but I wouldn't be able to guarantee that it would be very efficient. Of course, these more complicated methods are much slower. ICBI matlab GPL source is available. I should be able to port it to c++. What do y'all think? NEDI looks amazing, and ICBI even more amazing; I could certainly put them to good use rather than my current rather slow/limited vectorization-based scaling system. Keep in mind: a) You should investigate implementing this interpolation method for GEGL rather than GIMP, as in the fairly near future these kinds of transformations in GIMP will be implemented through use of GEGL. b) If you want it included with the baseline GEGL distribution, it would need to be written not in C++ but in C. If you don't, then you can probably code it in C++ fine. To clarify -- this is because both GEGL and GIMP are written in C. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] Opening, color correcting and saving 16-bits-per-channel PNGs
Hi, On Tue, Jan 27, 2009 at 7:35 PM, Hal V. Engel hven...@astound.net wrote: On Sunday 25 January 2009 21:53:54 Martin Nordholts wrote: Just curious. Since GEGL has support for more high bit depth formats than just 16 bit int/channel how much more work would be needed to support a wider For proper 16bit support, levels/colors/etc dialogs need to talk in terms of 0..65535 range rather than 0..255 when they are working on 16bit data, and so should then be able to talk in terms of 0..4294967295 for 32bit int. If I understand this patch correctly, once a system for working with 'native' ranges is implemented and the basic system implemented by the patch is proven, support for 32bit int/channel should be relatively simple. Whether floating point support would require more work, I do not know. There are also various rough spots to consider; we should be able to enter hex colors with 16bit or even 32bit per channel precision, if we can edit 16bit images. Sadly I haven't been able to try this patch yet -- my GIMP doesn't want to compile, due to babl/gegl synchronization issues. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GPS - Gimp Paint Studio
Hi! On Wed, Feb 4, 2009 at 7:42 AM, jEsuSdA 8) lis...@jesusda.com wrote: Hello! Ramón Miranda has published his nice Gimp Paint Studio for Gimp. GPS is a set of brushes, presets and color palettes specifically made for digital painters. You could see information and download the GPS and the GPS Manual from: http://www.jesusda.com/blog/index.php?id=314 I recomend you to see the Ramón Miranda artwork to view the GPS power: http://ramonmirandavisualart.blogspot.com/ This is really impressive! I'll try it out soon! One thing I noticed, is that presets for gimp-mixbrush-tool are included; these presets will only work if your GIMP has been patched with the patch available here: http://sourceforge.jp/projects/gimp-painter/ there is a quick howto here: http://klettersblog.blogspot.com/2008/10/gimp-painter.html I think it would help if the documentation mentioned that; while communicating clearly that it is optional (having presets for a tool your binary of GIMP doesn't support is harmless). David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Silent profile embedding.
Hi!! On Sat, Feb 7, 2009 at 6:27 AM, Guillermo Espertino gespert...@gmail.com wrote: Hi. I don't know if this can be considered as a bug, but I'd like to discuss some potential issues in the color profile embedding strategy. Currently (correct me if I'm wrong) the procedure for images without embedded profile is to silently embed the working RGB profile upon opening. This can be really problematic when the user has a sequence of images without profile (for instance a rendering from a 3D program) and want to retouch a couple of images. The result will be that the retouched images will have a profile and the others won't, and that can bring troubles when importing the image sequence into a color managed software. A simple way to avoid this would be to ask when an image without profile is opened, just like when an image with a different profile than the working profile is opened. A dialog could allow the user to choose wheter to keep the image unmanaged or embed the working profile. It's a good idea, however this particular way of doing it is not practical -- because in many cases, the majority of images opened do not have a profile. We need to find an approach that would not require vast amounts of dialog interaction. In any case, profiles are NOT automatically attached to images without profiles, in my tests with PNGs. The reason you might assume they are, is that GIMP automatically displays images which have no profile attached, as if they had the working profile attached. If your experiences don't match the above, perhaps the specific save plugin in question does (wrongly) attach the working profile when saving. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] bogus floating selection code?
I had just pasted a piece of image (copied from a layer without alpha, pasted back on to a layer without alpha) and, as I clicked to anchor it, GIMP crashed with this message: ERROR:gegl-node.c:1929:gegl_node_remove_child: assertion failed: (child_priv-parent == self || child_priv-parent == NULL) I'm guessing this is a fairly simple mistake, so I posted here (mainly for Mitch's benefit). It's difficult to reproduce, though. I had only used pencil (with 1px brush) and bucketfill (threshold = 0) before the crash occurred. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] efficient bilinear interpolation code
Hi! On Thu, Feb 26, 2009 at 8:40 AM, Tal ta...@inbox.com wrote: Hello, I'm very close to finishing code for efficient bilinear interpolation of transformed brushes (Bug 520078 – Rotate brushes http://bugzilla.gnome.org/show_bug.cgi?id=520078). I will post again soon when the code is ready. Excellent, I look forward to it. You should be aware there is an occasional bug that occurs with very small brushes, with the current code, where eg. a 1x1pixel brush becomes a 4x1 pixel brush like this: #..# It is usually triggered by adjusting the brush scale away from 1.0 and then back to 1.0. I'm happy to help with testing the interpolation, especially if the above bug also appears with your code. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Behavior when saving a selection to channel
Hi!!! On Sat, Mar 7, 2009 at 10:16 AM, Rob Antonishen rob.antonis...@gmail.com wrote: I posted this as a bug, and was told by Sven Neumann the behaviour was intentional and to raise it here. Currently, when saving a selection to a channel, either using the UI or via the PDB, the active drawable gets changed from the working layer to the new channel. I believe the active drawable should remain unchanged (i.e. where the selection was made). The current behaviour is confusing to a user because of the following fairly typical scenario: User wants to blur a portion of an image, but wants to save the selection for later use. 1) make selection 2) Select Save to Channel 3) Filter Blur Gaussian Blur Now the user is blurring the saved selection channel, not the layer they started on. I agree, something similar to the process you describe above is more like what I want to do, and because of this annoying behaviour I don't use 'save to channel' at all ever. It's actually easier to create a new layer and fill it with foreground color, and later transfer layer alpha to selection. While there definitely are some scenarios where I want to perform a filter on a selection, I will typically use QMask mode instead of filtering a saved selection, and IMO this is more intuitive than the workflow I see Sven has just posted about (mainly this is because QMask display is reliable, and channel display requires separate/repeated configuration to get consistent display results) David. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hello, On Mon, Mar 9, 2009 at 10:09 AM, gg g...@catking.net wrote: there is a problem with this new attitude. Why does GIMP try to impose this you will work with xcf or die dictate? Because it has always been an XCF editor, not an anything else editor. Being able to modify images loaded from PNG, JPEG etc is just because people have created loaders which effectively translate PNG - in-memory XCF. Everything else, including PSD, is too underspecified/basic to handle GIMP images accurately. Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not import) a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working. That's because you cannot simply open a png, only import. And this has always been the case; what you object to is merely: making an idea that has been implicit in GIMP so far, explicit. Here I want to do some simple editing and save. I do not want to export to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc. I believe you are protesting your sudden realization of the inaccurate way you were thinking of things, here. All I require is open: edit: save , in original format with original options. Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file. I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SVG brushes
Hello, On Fri, Mar 13, 2009 at 10:09 AM, Sven Neumann s...@gimp.org wrote: Hi, On Wed, 2009-03-11 at 22:22 +0530, sumith pandilwar wrote: by adding support for svg files i would like to add the feature to import svg file and modify its properties like colour, fade out etc and use it like a brush.This would be like totally creating a new brush of our own OK, let's have a look at using SVG for brushes in GIMP. With the current state of brush transformations in trunk, we are nicely prepared for vector brushes. Brush transformations currently are affine transformations and as such they can easily be applied on an SVG. So all that is needed is to create a new brush type GimpBrushVector similar to GimpBrushGenerated. This vector brush would load its data from an SVG file. If we accept linking the core against librsvg we can easily import any SVG file and render it using rsvg_handle_render_cairo(). Being able to render the brush to a Cairo surface is an extra plus as that will allow the paint tools to render a nice brush preview on the canvas as soon as we finally port tool drawing to Cairo. It's not clear though how exactly an SVG file that represents a brush should be interpreted. What I described above basically means we just treat it as a scalable image. Basically all SVG images could be used as brushes then and would behave like pixmap brushes except that they would look better when transformed. Probably not exactly what we want. We also need the notion of grayscale vector brushes that define a brush mask that is colored by the foreground color. We also need meta information such as the brush name and the default brush spacing. It's not entirely clear to me how such an SVG brush should look like. Do we expect GIMP-specific XML elements in the SVG ? I think we would have to. At least, in my vision, where we want GIH/GBR to be eventually deprecated in preference of SVG. This would require 2 things: a) support multiple brushes in a SVG brush file, ala GIH (presumably a group for each brush) b) support including ranks etc. information in the SVG brush file. IMO a GIMP-specific XML element is appropriate here, for that and brush rendering type information as you said. Probably require a specific naming scheme, to simplify implementation of ranks. For bitmap images in SVG brush files (eg. for patterning), we will probably want to use embedded images. Eventually for parametrizable brushes, we'll want to support external bitmap references (in which case we'll need to consider how to ensure that the user gets the right resources and that reference links are resolved correctly (probably relative to the .gimp-2.X/ toplevel directory)). Does inkscape do this kind of embedding? How is it accessed? Eventually, I would expect that we could have things like brushes with FGcolor on one side and BGcolor on the other by binding SVG object attributes to gimp context attributes. An initial SVG brush implementation IMO should be careful not to get in the way of this kind of binding (mainly by respecting the possibility that the 'pixels' of a brush may change, just like gradients with FG/BG embedded do.) Lastly (and more distantly): Deluxe paint had a 'Animbrush' feature which was extremely nice for animating moving objects (simple or complex). http://www.youtube.com/watch?v=5fF1OYaobPA demonstrates how it works. IMO this is a very helpful feature and we should accommodate the possibility of an eventual implementation. GIH's 'sequential' selection method comprises part of this. The other might be a method to hook frame-flipping (so GAP could implement it's own notion of frame flipping). Anyway, IMO a basic SVG brush implementation would be about as simple as you've said. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SVG brushes
Hello, On Fri, Mar 13, 2009 at 9:52 PM, Sven Neumann s...@gimp.org wrote: Hi, On Fri, 2009-03-13 at 15:50 +1030, David Gowers wrote: I think we would have to. At least, in my vision, where we want GIH/GBR to be eventually deprecated in preference of SVG. This would require 2 things: a) support multiple brushes in a SVG brush file, ala GIH (presumably a group for each brush) How useful are brush pipes (or image hoses) really? As far as I can see their primary use is for simulating brush transformations. We can already do that better on the fly. As Alexia said, animation; and irregular brushing, arbitrary/complex effects (eg making pressure correspond to darkening + gradient mapping (which is different from darkening a gradient mapped brush)); clever usage can make them quite effective for building textures, and the list goes on. Of course, we could also do that if the brush dynamics allowed us to select between multiple brushes according to input values. But that strikes me as demanding too much from the user. For bitmap images in SVG brush files (eg. for patterning), we will probably want to use embedded images. Eventually for parametrizable brushes, we'll want to support external bitmap references (in which case we'll need to consider how to ensure that the user gets the right resources and that reference links are resolved correctly (probably relative to the .gimp-2.X/ toplevel directory)). Why don't we just use PNG files for bitmap brushes? That's fine by me. However it doesn't relate to what I mentioned above - SVG brushes that use bitmaps as resources (patterns etc) - 'mainly-vector' brushes. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SVG brushes
Hello, On Fri, Mar 13, 2009 at 10:32 PM, Sven Neumann s...@gimp.org wrote: Hi, Do we need the full complexity of the current image hoses for this? Looks like a simple linear series of brushes could be sufficient. No and no respectively, IMO. Don't need full image-hose functionality for this; however IMO at least 2d sets of brushes are required for good flexibility (and then, lets say that we can map 'pressure' to 'brush dimension 1' and 'random' to 'brush direction 2' and this is a typical kind of user experience. IMO this is both a comfortable and flexible setup), and supporting 3d sets would reasonably cover the possibilities of 'unexpected utilizations'. I have been thinking about SVG as direct brush format and I think that using specifically named meta data fields for the SVG should be enough. I think its important to allow the use of stock inkscape to create such brushes. We can't depend on Inkscape to add the GIMP-specific data. So it looks like the main job of this project would be to add a user interface to GIMP that allows to import SVG files and saves them with additional data as GIMP vector brushes in the GIMP brush folder. It will also be tricky to read this data back when loading the SVG brush. As far as I can see, librsvg doesn't provide any hooks for application-specific data in the SVG file. We might have to parse the file twice, but I guess that's OK. We would just mmap the brush file and pass it through a GimpXmlParser for the metadata and to rsvg_handle_new_from_data() to get the SVG rendered. For multiple stamps in one file layers should be used just like for image hoses now in gimp. SVG doesn't have a concept of layers. It does support animation, but animation in SVG is rather complex and not well suited for our needs. Groups is fine for this IMO -- it's the same way that Inkscape stores all it's icons in one file; same principle (and, inkscape layers render down to SVG groups :) We would just need to ensure meaningful IDs for the group (eg brush_00_01 for the brush at coordinate 0,1 in brush dimensions) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Behavior when saving a selection to channel
Hello Rob, On Tue, Mar 17, 2009 at 11:25 AM, Rob Antonishen rob.antonis...@gmail.com wrote: I dug up a copy of this manula, and discovered a couple things after playing with channels in 2.6.4 and 2.6.1 on Ubuntu. In the instructions, it states: Open the Channels tab and create a new channel. In the New Channel Options dialog, set this channel to 100% Fill Opacity. Click the black color swatch to access the Color Selection dialog, and choose a nice color (this will be the first plate to be printed). Name the channel “navy blue” or the like, depending on what color you chose. Click on the OK button. Paste (right-click|Edit|Paste) the image into this channel. It seems you can no longer paste into a channel. In the latest SVN, you can. It is confusing that the floating layer shows up in the layers dialog rather than the channels dialog. otherwise, things are normal. Maybe 2.6 doesn't have these fixes. David. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Behavior when saving a selection to channel
On Tue, Mar 17, 2009 at 1:40 PM, Rob Antonishen rob.antonis...@gmail.com wrote: On Mon, Mar 16, 2009 at 10:15 PM, David Gowers wrote: Hello Rob, It seems you can no longer paste into a channel. In the latest SVN, you can. It is confusing that the floating layer shows up in the layers dialog rather than the channels dialog. otherwise, things are normal. Maybe 2.6 doesn't have these fixes. David. OK, I'm quite wrong. I was looking to be able to use Paste Into, and have it paste directly into the active channel. Ah, I see the problem now. There is not an 'active channel'. There is rather an 'active drawable' (and both layers and channels are classified as drawables). This has always been the case (but perhaps we can show this in a clearer way? I wonder what Peter thinks.) So to paste into a channel you have to... - select the channel (in the channel panel) - edit paste (or paste into) - select the layer panel - hit the anchor button - select the channel panel. Note this is less confusing and faster when you have Anchor bound to a keyboard shortcut. Select the channel, paste, anchor. (if you wanted to change opacity or layer mode, you still have to switch to Layers dialog though - ick!) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
gradation map - nearly the same: map image points to positions in the gradient Yahvuu, you probably need to clarify: how is this different from Colors-Map-Gradient Map? On Thu, Mar 26, 2009 at 8:02 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote: levels, curves - could support the user's intention more directly: - mark places in the image, which should be brighter/darker, or have more/less contrast or modified colors - the whitepoint, graypoint pickers could be adjustable markers on the image. Or a completely different method for whitebalance? - if tones are getting compressed, better control of where the clipping happens (separately for each of R,G,B, Value) Better? We already have exact control of clipping for each of R,G,B,Value , so do you mean a change in the quality of clipping control? I think this needs to be more specific Yup, on-canvas level/curves. Excellent point. Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape). If I had this, I'd probably delete all my gradients :) IMO this is a much more usable way in general, and premade gradients cover only a small subset of use cases. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Hello Nathael, On Sun, Mar 29, 2009 at 9:17 AM, Nathael Pajani g...@nathael.net wrote: Hi all, It appears that your only problem is that things are changing. Sorry, but you will have to get along with that. We are not going to stop ourselves from changing the GIMP user interface to the better. Changing to the better is good, but the better should not be the point of view of a few, neither intended to copy the behavior of commercial programs to gain new users (this is the feeling I had from lots of remarks here and on IRC) , and much less again, simplifying the interface and removing customizability because of a said difficulty to maintain or code the whole stuff (which, I say it once more, is insulting Gimp developers.) Removing customizability is best. I'm not kidding. Customizability is what happens when you can't figure out how to make the program behave sensibly in 99% of situations. Every point of customization is also a point of potential confusion, for both the coder and the user. Difficulty of maintenance as hard-coded options go up is a fact, it's not at all insulting. In order to achieve very reliable code, software must be tested with every combination of options available. This means to achieve moderate reliability, software must be tested with 50% or more of the combinations of options available... To show some perspective on this, you can regard each togglable option in the GIMP preferences as a bit in a binary number. In SVN head, this binary number is 43 bits long -- in my case, the number is 01110111000101110001011. 43 bits of options (not including the other, multiple choice or arbitrary options, which would inflate it by quite a lot of bits -- maybe about +224 bits) means that there are 8,796,093,022,208 combinations of options to test already. This illustrates amply the situation: GIMP, and many other applications, open-source and closed-source, have so many options that thorough testing is a virtual impossibility. Each single toggleable option that is added doubles the amount of testing needed to get a bug-free program. Togglable options are the simplest case. Customizable behaviour (eg. scriptable behaviour) increase the amount of testing required for a reliable program to nigh-infinity (which is not to say that we should not have them at all. Just that they're vastly more expensive to support than togglable options) Sorry, but the GIMP user interface sucks and that urgently needs to change. Has there been a survey about this ? Alexandre addressed this, but also : 95% of software UIs suck quite badly. This is because most often they are simply written as an afterthought to the backend: 'oh, we need to make this FOO capacity available to the user. What's the easiest way to do that?' rather than designing the frontend first and designing the backend so it fits well with the frontend. This leads to incoherent UI -- and customization of dubious value. The recent changes, OTOH, were based on real UI work with users to discover what things users most often had trouble with. And do not tell me (or others) it is not good because other programs have too much customization possibilities. It is not good, precisely because they have too much customization possibilities. We need a meaningful minimum of customization, the absolute least customization for the greatest potential effect; that is the ideal customization situation for any software. And we are going to make some much more drastic changes in the future. Please remember that user are working with The Gimp. Changing the user interface drastically because you do not feel like keeping the old one will discourage Feelings have nothing to do with this. Reasoned, rational, open review does. Anyway, changes discourage and encourage people all the time, but changes should be made due to their actual merit, not their secondary effects. So, one point I already brought to the discussion, here and on IRC: the possibility for the user to customize the interface, or in other words, Not ONE interface for everybody. When I said this on IRC (that the interface should be customizable, as it is for so many free softwares, mind, window managers for example) I was told that this is an ineptitude, because the most used user interface (M$ OS's one) is not configurable. I would be interested to read the appropriate section of the IRC log, if you have it. Personally, I think Apple is a better example. They don't actually have *stellar* UI, but they do have good UI, because they really work at it. We can see, through their UI designs, that carefully considered simplicity is something that works quite well. Then, another point: using configurations, as it is done for window managers, which users can share. I think this would be a good improvement. Thus, you can make things move as much as you want, as long as the user can come back to a configuration he nows and can use.
Re: [Gimp-developer] Gimp interface changes
On Mon, Mar 30, 2009 at 9:00 AM, Nathael Pajani g...@nathael.net wrote: David Gowers a écrit : Hello Nathael, Hi ! Nice to have a constructive answer from time to time :) Removing customizability is best. I'm not kidding. Customizability is what happens when you can't figure out how to make the program behave sensibly in 99% of situations. Every point of customization is also a point of potential confusion, for both the coder and the user. Hum, I think there is a misunderstanding here. So I'll use an example. First, what I call a tool menu is this: http://www.nathael.org/Data/tool_menu.jpg These are dockable. And we can create as many windows as we want, with groups of these tabbed inside. This is customization. The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable as well. You cannot think of creating one interface that will fit 99% of the current and future users, or you plan not to count current users that will have to switch to another program, or to create a fork (even their own one). And there is NO possible confusion, neither for the user, nor for the coder in this. Difficulty of maintenance as hard-coded options go up is a fact, it's not at all insulting. In order to achieve very reliable code, software must be tested with every combination of options available. This means to achieve moderate reliability, software must be tested with 50% or more of the combinations of options available... To show some perspective on this, you can regard each togglable option in the GIMP preferences as a bit in a binary number. In SVN head, this binary number is 43 bits long [...] means that there are 8,796,093,022,208 combinations of options to test already. [] I cannot agree with you here. Once again, I'll use the kernel as an example here: I won't bother counting the number of options and the possibilities resulting, I'll just state that it's the biggest piece of code I have ever seen, and still the most reliable. Are kernel programmers superhero ? genius ? The kernel is made up of modules, which are almost entirely independent. With this, the total amount of testing needed is much reduced, because any given module has only a few options and can be tested independently. GIMP, which is an application, has a UI, and all options effect the user's perception of that UI. For the core of the program, a simplification such as is applied to the Linux kernel, is impossible; the core behaviour of the program stands as one whole thing to the user, and we test it as one whole thing. This kernel comparison just does not work. Please stop using it. Tell me, I'm one of them, I'll appreciate :) Another example I'll use as some spoke about it previously: Gnome. I'll not bother counting the options you can find in gconf either. Still, gnome is stable (from my point of view at least, but most will agree) and even if it's not a perfect display manager, I think it's a very good one that manages to perform it's task. And the Gnome example is most accurate, don't try saying the contrary this time: it uses GTK, and it's also a GNU project. Gnome also is structured in many individually testable components, like the kernel, and unlike GIMP. I (and, I think, some of the core GIMP developers) would like GIMP to be structured like Linux or Gnome -- this has great advantages -- but it definitely is not where GIMP is at currently. Sorry, but the GIMP user interface sucks and that urgently needs to change. Has there been a survey about this ? Alexandre addressed this, but also : 95% of software UIs suck quite badly. This is because most often they are simply written as an afterthought to the backend: 'oh, we need to make this FOO capacity available to the user. What's the easiest way to do that?' rather than designing the frontend first and designing the backend so it fits well with the frontend. This leads to incoherent UI -- and customization of dubious value. Right and wrong. Right, the UI must not come as an afterthought. But the UI is not the main part of an Image manipulation program, it's here to give access to it's capabilities. So designing the UI first is just silly. Both have to be thought in parallel. But this is very hard for a project like Gimp, when programmers are more interested in the backend part and when this part is made up of small parts added one by one with no global initial view. But this is free software, and those not happy with this should rather go programming commercial software ... and discover that the grand discours about planning the design is just that. I don't know what to say to such a viewpoint. Of course you need to adjust your plans as you get feedback from actually implementing them -- this is what led to the current form of the free-select tool -- but the whole idea of an application is to provide capabilities to the user .. the interface should not be dependent in any way on how
Re: [Gimp-developer] A very simple feature that would be very nice...
Hi Hadrian! On Mon, Mar 30, 2009 at 4:06 PM, Hadrien G. guydeloinb...@yahoo.fr wrote: Hi ! Playing with gimp lately, I've been thinking that it would be nice to be able to save the toolbox state (and maybe other things related to dockable window placement) in profiles. As an example, when I make photo editing, I use different tools that when I draw. Thanks to gimp's system, I can make toolbox changes that reflect those needs. But it's pretty long to play with the toolbox, and as there's no save button available to save my changes, I don't do that that often. I think it's a bit sad. Saving windows state would have the same purpose : being able to quickly switch between different workspaces that are useful for different works, while keeping a clean UI for each work... Until that is implemented, you can do something like this by creating additional personal .gimp-2.x directories from copies of your base one, one for each UI configuration, and specifying which gimprc to use when running gimp (example commandline: gimp --gimprc ~/.gimp-2.7-photoedit/gimprc). Once you've done that, just customize the UI accordingly for each profile. Then everything is ready and you can just create shortcuts or menu items that run a command like gimp --gimprc ~/.gimp-2.7-photoedit. If you want your suggestion implemented, I suggest doing it yourself. AFAIK it's not too hard, and no developer currently has enough interest in it to implement it themselves. Hope that helps, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A very simple feature that would be very nice...
Hi Hadrien, On Tue, Mar 31, 2009 at 5:48 AM, Hadrien G. guydeloinb...@yahoo.fr wrote: = I'm currently using Microsoft Windows XP as my main OS. Would it help greatly to get some Linux distro back on my hard drive ? Yes, development is much easier on Linux. = How does one design the gimp UI ? Are there graphical tools/XML files/other high-level things to know about ? Or is this hard-coded in some unit (and, in that case, which unit) ? You can experiment with graphical designing using Glade. But you would need to finally code the GUI manually, since we don't use Glade in GIMP. http://zetcode.com/tutorials/gtktutorial/ might help. = By the way, could one show me an example of gimp config file saving code, to know which standard applies here ? = A proposal is to switch between whole different gimprcs. Is this really wise ? I mean, shouldn't some settings stay profile-independant, say, those about memory management, help system, display (especially DPI), color management, and folders ? That was my proposal for working with gimp as it currently is; of course this is not exactly what is wanted, just what could be done with the current gimp. I think that one should first plot some boundaries around the profile thing. What should be included in a profile, and what shouldn't ? Personnally, I would suggest : -Toolbox state -Dockable windows status -Keyboard shortcuts (maybe) -Tool options Does this include presets? (see tool-options directory in your personal gimp directory) -Image window appearance (maybe) Are you talking about whether rulers, menubar, selection, etc.. is shown in the default image window? If so, I think that's stored in gimprc. If you're rather talking about image window position and size, it's stored in sessionrc, along with the dockable windows state. -Extended input peripheral shortcuts (maybe) Although Photoshop supports switching between sets of keyboard shortcuts (and presumably between sets of peripheral shortcuts), it might be quite confusing to switch between them. I think if you asked Peter, he would say that's more trouble than it's worth. You might consider including this too: - Device status (found in devicerc) This would mean that when you switched between profiles, it could automatically switch to a sensible tool and sensible brush, colors, etc. = Should one new config file be created for each profile, and a profile subfolder be added to the .gimp-2.x directory ? In any case, which naming convention should I use ? I think .gimp-2.x/profiles is probably appropriate. Each profile would almost certainly need to be a subdirectory with multiple config files (eg toolrc, sessionrc, ..) . = Should this setting be called a profile or workspace ? Profile seems more accurate, to me. = Where should this be put in GUI to make people know about it ? The preference dialog is a pretty obvious location, but since this is more likely to be used as a tool than as a setting, shouldn't there be a specific dockable window about it ? And should this be added to the default UI or not ? A dockable would be good while you're developing it; We should probably try to get Peter's input on what a sensible way for it to end up might be. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
On Tue, Mar 31, 2009 at 8:25 AM, Nathael Pajani g...@nathael.net wrote: Hi all! The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? No, but this doesn't negate the idea that the UI is the most important part. If GIMP didn't have it's UI, it would instead be something like ImageMagick. Since people mainly use GIMP in a way that is incompatible with ImageMagick, it's reasonable to conclude that the most significant part of GIMP is it's UI. Right also. But once again what in here prevented the designers from creating two tools? They did. And then, they got feedback that said, these tools are too similar, I think they would work better merged. especially when selections can be summed up using different select tools? But maybe we should stop arguing on this point, as each argument you try to bring in is an argument for my point of view, or has no relation to the point you try to defend. Maybe I'm having you loosing too much time on these emails. I'm not losing any time, though you often don't seem to understand; whether this is because of a language barrier or simply your own insistence on having a different conversation from everyone else participating in this discussion, I don't know; but be assured that any time wasted, is not mine. I can quote Sven as saying that the majority of code in GIMP deals with UI, and my own investigation of GIMP code confirms this. I did not investigate, so I'll rely on you, and I can understand this very well. But it doesn't make the UI any more important. This is a good point. I addressed it earlier in this email. Nothing about pressing ENTER in the status bar. (in french at least) Not before you have clicked somewhere to try getting rid of this polygon behaviour. If you will not experiment, it hardly seems likely that you would discover anything. What have you tried to discover it? I was told in a previous mail. He is asking, 'When you were looking for this feature, what have you done to discover it?', AFAICS. OK I thought 2.2, 2.4, 2.6, were major releases. (They look like it from outside, with the new splash and so on). GIMP changes splashes quite frequently. For instance, in the 2.3 development cycle, we went through about 5 different splashes. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP performance
Hello Andrea! On Thu, Apr 2, 2009 at 1:57 AM, Andrea Olivotto and...@andreaolivotto.com wrote: Hi all, I'm a photo amateur, and I do like gimp. I posted some time ago some hints to make gimp more useful for photo retouch, and some have been done in 2.6. At this time, gimp seems to me that need speed. It is far away from Photoshop and other commercial softwares, and things are getting worse using GEGL (as I tried in 2.7 development program): I checked in Windows and in Ubuntu 8.10, AMD 3000+/64 plus 1GB RAM. GEGL *is* what we are doing to increase performance. It's true that currently GEGL is much slower, however, the previous GIMP architecture was incapable of the optimizations and storage strategies required for particularly large images, and also was very limited (no support for higher bit depths, no automatic colorspace conversion so that any image can be used as input to any operation). Chances are that GEGL is already better at managing graphics than GIMP ever was. It still needs quite a bit of work, but in my understanding, the slowness is caused by the way GEGL is being used by GIMP. It could be a lot better; and by the time GEGL is really well integrated, we could reasonably expect far better responsiveness and comparable real speed, with the possibility of vast speed increases for certain kinds of filter/plugin. When I use curves, preview is redrawed very slowly, I can see the blocks under updating. Things like Curves could certainly be done much quicker. A lot of conversion goes on during the calculation; but really, for applying to 8bit and 16-bit pictures, a lookup table should be all that is needed, with only a very little amount of conversion work that happens as soon as the curve is adjusted. This means that currently, GIMP is making GEGL do much more work than it needs to really do. These issues will be settled as GIMP developers learn more about using GEGL, GEGL matures, and as GEGL becomes better integrated in GIMP. I know that GIMP is open source, and developers don't want to compete with Photoshop (or Photoshop Express, or Paint Shop PRO, ...), but this is the real world in photo retouching. I just want to be honest, end to emphasize this issue. I hope I've addressed your concerns. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New User's opinion
On Sun, Apr 12, 2009 at 5:11 AM, Mirai Warren the.future.comes...@gmail.com wrote: Ach. Sorry, but my meaning was simply that an artist can create art with any tool. mspaint was only an example. Looks like you have to make a tough choice to stop contradicting yourself :) I wasn't contradicting myself. By was responsible for I meant was used to create. It is still the artist that creates. While it is technically possibly to create dither patterns like this using a tool like MS-Paint (which it wasn't in this case - it was Gimp), it is my opinion that an artist would have to either be masochistic, have way to much time on their hands, or just be stubbornly trying to make a point to use such a tool rather than a more suitable one... I can do those patterns with mspaint rather easily, and I am not a masochist. I can do them easily (in GIMP, and probably in mspaint). But it takes more time, and is meaningless grunt work -- I already know exactly what is wanted there, so the method I used was to generate a sample of the dithering and then clone it. With the advent of the 'clipboard pattern' feature in GIMP, this would be even easier -- I could draw the ditherpattern sample directly onto the image before copying that section and cloning from Clipboard Pattern. Tool use allows you to forget about the meaningless and spend more time on the meaningful. The time that you can choose to spend rendering such things manually, subtracts from the time you have to attend to other parts, and to the picture as a whole. As long as there is an efficiency gain, tools are worthwhile to use. I do not use a cloning method for small amounts of dithering, as it is more efficient to just render them with pencil tool. Yes, I'm the artist of that picture :) If you're not very practiced at dithering, it might be good to spend time doing it manually despite available tools to automate it. With the understanding of what you want that comes with experience, this is only rarely needed. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] About futures features
Hi, On Thu, Apr 16, 2009 at 8:07 PM, SHIRAKAWA Akira shirakawa.ak...@gmail.com wrote: On Wed, 15 Apr 2009 12:21:59 +0200, Eduardo Barijan eduwb.horizo...@gmail.com wrote: I was thinking this time about 3 new other features that Gimp could have: 1 - grouping layers by folder. This one should help artists who does their work in a lot of layers, as example, coloring characters. Then you have a folder for body, for example, with just the layers that you used to do lineart and color of body, etc. Yes, I too think it's a good idea that should be implemented! It would be even more useful if it was not only an aestethic/usability addition, but if expanded program functionality by providing group layer masks. These group layers masks would work like normal masks, but with group of layers instead of single layers. That's one of the layer features I need most, as I'm an artist (more like creative user, though) and I use many layers even with simple works, and I often need masks to affect multiple layers at once. 3 - Select layers and then apply Merge layers Instead of do it, for example, 5 times to merge 5 layers, it could be possible to select which layers are affected and then do the command. This too, I'm surprised it's not possible to do at the time, because it's a logical and intuitive way to combine multiple layers together. It is possible to do: 1. Shift-click on the visibility icon for one of the layers, to make it the only visible layer 2. Make the other layers that you want to include visible 3. Merge Visible Layers David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP development is now in GIT?
Hi, I was aware that migration of GNOME project version management to GIT was underway; however, I just noticed that the GIT version (@ git.gnome.org/cgit/gimp) was more up-to-date, having '* app/paint/gimppaintcore.[ch]: made GimpCoords* parameter of GimpPaintCore::start() const.' by Mitch as the first ChangeLog entry. Does this mean that GIMP migration is fairly complete and that development is proceeding now in GIT, with the SVN repository becoming obsolete and non-updated? Thanks for any light you can shed on this issue :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Reference on Opacity variations in merging modes
On Sat, Apr 25, 2009 at 12:05 AM, Alchemie foto\grafiche fotocom...@yahoo.it wrote: I found the algorithms of many merging mode BUT all the the formula there do not take opacity into account so as now the blending may be done only at 100% opacity (btw is for a blending filter , that allow to merge also in mode not available in Gimp obviously the result, the output is the visible from the the merging as new layer ) I'm sure somewhere in the Gimp code or documentation there is the answer: how ,mathematically variation of opacity are taken into account, but i am really lost in front of page of codes and doc You should understand, that the new GEGL-based layer modes are subtly different from the legacy GIMP code in how they treat alpha. That said, app/gegl/gimpoperationpointlayermode.c contains all code dealing with layer compositing modes, and that is as simple as it gets. Yes, I find it confusing too. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
Hi LIMN, On Sun, Apr 26, 2009 at 7:07 PM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, Gimp 2.6 allows to use brush dynamics to control opacity, size, hard and color. These features greatly increase the drawing capabilities of gimp, and many users find them very useful. However, we don't have any way to access these from inside the PDB... I think that it would be nice to be able to access these using the PDB, however I'm not sure about the right method: Do we want to allow the user to specify velocity, and pressure for each coord, or should we use the emulate brush dynamics feature (the same one we have in the libart stroking)? Personally, I believe that the emulate brush dynamics is the right method. We should definitely make dynamics available, but IMO both of these methods is quite unsuitable and would only add to the current inconsistencies of the pdb interface to paint tools. In my opinion this is what needs to happen: A) Migrate paint tools at least partially to GEGL (so that the actual rendering of strokes is done by evaluating a 1-node GEGL graph). This will help us define a consistent, expansion-compatible way of communicating and storing stroke information. B) Make a system for handling both full strokes (where each point specifies parameters such as brush scale, rotation, aspect ratio, spacing directly) and simple strokes (where each point only specifies the 'source' information -- pressure, velocity, angle, etc.), and converting simple to full strokes C) Work out a way to pass this information through the PDB, in a backwards + forwards-compatible way -- so that older scripts work in newer versions because their missing fields are automatically expanded and filled in with sensible default values, and that newer scripts work (in a limited sense) in older versions of GIMP. D) Provide a method of constructing and communicating GEGL graphs through the PDB. This can be used by scripts to actually do the required painting. E) Use it (and deprecate the current 'gimp-paintbrush' etc API) I also think we need to look harder at our current inability to communicate various tool options such as Jitter, Color from Gradient, and Incremental; possibly communicate these via a keyword-argument sort of interface (ala Python) I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc. Do you understand that you must not change the api of gimp-paintbrush, gimp-airbrush, etc? Because that would break a lot of scripts and plugins. This is part of the problem with the current PDB interface to tools; supporting new options must be done through additional PDB functions. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
Hi Theodore, On Sun, Apr 26, 2009 at 8:00 PM, Theodore Imre blurym...@gmail.com wrote: gimp is not a good choise for digital painting because it doesnt have a blending tool. Paint tool sai in the respect is far superior because its brush engine is much more advanced for smooth blending Please keep your replies on topic. This thread is about improving the plugin API to the painting system of GIMP (which is not, anyway, a program for digital painting, but a 'Image Manipulation Program'; naturally tools designed for digital painting, Like MyPaint or Krita, will be better for digital painting.) As Paint Tool Sai is also not open-source, it definitely has no relevance to this thread, unless it also possesses a programming API for plugins or scripts to non-interactively paint which solves this same problem, and which you will describe. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hello yahvuu, On Sun, Apr 26, 2009 at 9:31 PM, yahvuu yah...@gmail.com wrote: Hi all, peter sikking schrieb: I like the innovative nature of the idea. it would not be without a hint of irony if, after 40+ years of digital image processing, GIMP were the first to finally introduce the concept of a background color ;-) And i'm not aware of a raster file format which features that concept. Let's see if it's any good. Yes, this is certainly an interesting idea, worth trying, and I agree it has potential to address quite a few problems. the secondary workflow gets simplified: importing e.g. a JPG creates a GIMP document with one layer and the image background color set to opaque white. Any modification other than making the background color transparent preserves the image projection's property of being fully opaque. Thus on export, the projection can be converted to JPEG format without asking the flatten? question (which actually asks wether to fill transparency with a bg color). For file formats which support transparency, e.g. PNG, import initializes the image background color to neutral, say transparent white. For a cycle of import and export this doesn't introduce any change: - if the PNG was fully opaque before, the imported bottom layer will be fully opaque, thus covering the background color. - if the PNG has transparent pixels, the projection will have them, too. The image bg color does not introduce any change as it is fully transparent. In both cases the flatten or merge layers? question becomes obsolete. As a side-effect, the automatically chosen image bg color gives a non-intrusive hint about the imported file's transparency capabilities. (That's another reason why GIMP should not try to be smart in choosing the image bg color, e.g. from image content. The first reason beeing that this can't be done reliably, e.g. trying to recall the image bg color of an exported JPG on re-import) This all sounds pretty good to me - I would like to see some more thinking on how this is related to the background color in the color chooser. coupled/decoupled? in short: decoupled, definitely. An explicit image background color actually questions the very existence of a color named background as part of tool state. Having several colors available for instant access is undoubtedly very handy in the sense of a core mini-palette. See MyPaint -- it provides a 5-slot color history. You'll need to try it to see how it works. (the 'previous color' action swaps between the 2 most recent.. but it pops up all 5 visibly, and pressing it quickly multiple times moves further back. From my experience, this works much better than having FG and BG color and swapping them as needed. MyPaint is a dedicated painting app, I think we could really learn from it here; the way it handles color history is comfortable, discoverable, and non-intrusive. Labelling the second color staticly as background - although being a good mnemonic - is somehow a remainder of evolution from the days of non-alpha, single-layer images. Totally agree, it's always seemed a bit odd to me. This shows up in the case of the eraser tool. Cleary it should erase to background color. But what is the background color of a layer? Currently, the answer depends on layer state - wether it has an alpha channel or not. This can be unified according to the rationale that layers are just transparent sheets in order to prevent mode errors. Then the answer is to erase to transparency, on the alpha channel. Consequently, the eraser doesn't require a background color as part of tool state anymore (and which other tool does?). I see where you're going with this. One bump I see is things like Cut and Float -- quite often I want them to fill the source area with a solid color rather than with transparency. When this doesn't happen, it's awkward (as the layer) The benefit of an image bg color in that context is that the bottom layer doesn't need to be special-cased: a newly created GIMP image consists of a transparent layer and an opaque white bg color by default. The other important tool which utilizes the toolbox bg color is the fill tool. From my experience here, the tool box's bg color serves more as a lay-by for smooth interplay of multiple tools than actually as a background color. Even when working on a single layer, i tend to change the bg color quite often; YMMV. Anyway, binding the 'CTRL+.' shortcut to the image bg color will limit it's usefulness. Another tool which accesses the tool box's background color is export. The cases where the export process needs to eliminate transparency will probably still arise, though much less often - e.g. exporting an XCF with transparent bg color to JPEG. This could just utilize the RGB part of the image bg color. Might not be very intuitive, though, as it's difficult to visualize the difference between transparent white and, say, transparent
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
On Mon, Apr 27, 2009 at 4:42 AM, Rob Antonishen rob.antonis...@gmail.com wrote: Here is another question... Should the basic paint calls (I.e. Those with the description using current brush) that have no parameters just be changed to paint respecting all the current brush options, like scaling, jitter, etc. ? We cannot do that, unfortunately, as it would substantially change the meaning and effect of some existing scripts and plug-ins. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP - Request for a feature - Animated GIF from a Video File.
Hello, On Mon, Apr 27, 2009 at 12:23 AM, Krishna Revuru krev...@hotmail.com wrote: GIMP-Dev-team, I was trying to create an animated GIF on a Linux-machine and after quite some google-ing I came across the below site http://nativeraving.blogspot.com/2007/11/creating-animated-gif-files-with-ubuntu.html The summary of steps described in this site to create an animated GIF from a video file are: First you need a program called Avidemux Once you have that installed you need to launch it and open the video that you want to chop. Select the part of the video that you want to use as an animation using the A/ and /B buttons. A/ = Beginning /B = End Now you need to save your selection as JPEG files. In Avidemux go to FileSaveSave Selection as JPEG images... Save the project to a new folder, then view the files in their folder and delete any unwanted frames. Next, fire up F-Spot photo manager, import the folder: FileImport To resize the frames we will need to export them. In F-Spot you will need to click on browse and then hit CTRL+A to choose the frames Then export them: FileExportExport to folder... Then reduce the amount of pixels to resize the frames. Next you need to fire up the GIMP and open the first frame. Next we need to open all the frames as layers. To do this we need to go to our first frame and go to the menu: FileOpen as layers Browse to the folder with all the frames in it and hit CTRL+A Then hold CTRL and click on your first frame to deselect it and then open the files. Hit CTRL+L, that will bring up the layers. To preview your animated image simply go to the picture window then: FiltersAnimationPlayback and hit play. To help reduce the file size go to: FiltersAnimationOptimize (for GIF) All you have to do now is save the image as a GIF and choose to save it as an animation. Given this scenario, I wanted to request a feature that I believe will be handy for a lot of users with similar requirements. Is there any way we can add a feature that takes in a pre-cut image and makes an animated GIF out of it? I understand GIMP is more for Image-editing and not Video-editing, but if there is a provision from within GIMP to cut specific section from a video file and convert to an animated GIF then it will be a superlative feature. Use GIMP-GAP. This makes such a task very simple AFAIK: 1. Load (part of) a video file as a GAP animation, using the Video-Split video into Frames submenu 2. Convert it to a conventional GIMP animation using Video-Frames to Image 3. Save the resulting image as a GIF. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Mon, Apr 27, 2009 at 2:20 AM, yahvuu yah...@gmail.com wrote: Hi all, David Gowers schrieb: One bump I see is things like Cut and Float -- quite often I want them to fill the source area with a solid color rather than with transparency. When this doesn't happen, it's awkward (as the layer) Did I really write that (as the layer)? I meant (as fuzzy/foreground-selection then stops working 'correctly' on that part of the layer) in terms of the model under discussion, this is a shortcut for cut fill. I wonder, doesn't CTRL+C.V do the trick? No, think about it, once you have 'Cut' something the selection is gone. All that would achieve is to fill the entire layer with a color ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi saulgoode, On Tue, Apr 28, 2009 at 12:29 PM, saulgo...@flashingtwelve.brickfilms.com wrote: Perhaps I am misunderstanding this proposal, but the ramifications seem to be more confusing than the present method. And while I realize that GIMP does not make any guarantees about retaining the colors of transparent pixels, its current behavior is quite useful for editing files destined for applications which employ the alpha channel in unconventional ways. It also offers a few other atypical benefits, but mainly it is consistent and easy to comprehend what is happening. Some questions: I don't understand some of your following objections (or I think they are based on false premises) The eraser currently does change color values, in the case of layers without alpha (it's like using paintbrush or pencil with the background color). Yahvuu's proposition would make sure it never changed color values because there would be no layers without alpha. Thus, several of the things you brought up have no relation to the proposition (because they could not possibly occur through implementing this proposition) If a PNG is loaded as a layer, should the image background color be updated to the PNG file's background color? or should it remain what it was originally? If a JPEG is loaded as a layer, should the image background color be set to white? Good questions! It's pretty clear to me, that if the PNG provided a background color, we should keep it; otherwise, we should assign our own. It looks like my proposed 'image has an alpha-channel' flag is needed here to avoid occasionally changing the meaning of pictures. There is no right or wrong behaviour for JPEGs imo, since they are completely opaque and predicting a good BG color automatically would be more troublesome than it is worth. I think 50% grey (#bababa) is a better default BG color for when a default is needed. Should gradients be using the image background color or the second color in a color slot history? I think, given a slot history such as I described, it would be helpful to provide the ability to 'virtually point at' any of the 5 slots (considering 1 = current, 5 = oldest) and deprecate the notion of 'background color' (or even precisely 'foreground color') from gradients; automatically convert references to BGcolor into slot #2, yes. The 'slots-based' history would serve the same purpose in terms of gradients -- allow quick building of gradients -- just that it would be even more flexible and quite often more quick :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi saulgoode, On Tue, Apr 28, 2009 at 7:00 PM, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting David Gowers 00a...@gmail.com: The eraser currently does change color values, in the case of layers without alpha (it's like using paintbrush or pencil with the background color). Yahvuu's proposition would make sure it never changed color values because there would be no layers without alpha. I don't understand the last sentence (perhaps I don't understand Yahvuu's proposition correctly). If color values are never changed, the only place that erasures would result in an image background color (being revealed) is on the bottommost layer. Is that what is being proposed? No, because your reasoning is oversimplified. The above situation could occur, but it depends on the image content. Some images would have transparent areas even on the bottom layer (this is common in web graphics and icons) If so, then I would consider the lack of consistency in the tool's behavior across layers to be a problem. Is there an inconsistency to be had? It will behave just the same as before, really. Only it will never ever change the colors on any layer, because it will never encounter a layer without alpha that requires it to paint with BG color instead. If it is not so, what determines whether or not erasure results in the RGB part of the image background color being blended with the layer contents? The alpha channel of the respective layers. Erasure never results in the image background color being blended with the layer contents. The effect on the layer contents is only a change in alpha channel, just like it currently is provided your layer has an alpha channel. Yahvuu's proposition is essentially a) have a 'virtual layer' always at the bottom of the stack, filled with a color and b) make all layers have an alpha channel Nothing more. It does have some ramifications to certain functions (like Cut and Float) but none really to Eraser (just that the eraser code can be simplified. most likely) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The old bugs in merging modes are fixed now?
On Wed, Apr 29, 2009 at 4:10 AM, Martin Nordholts ense...@gmail.com wrote: yahvuu wrote: Hi all, Alchemie foto\grafiche schrieb: The possibility to add CUSTOM layer modes [..] that sounds interesting. Just curious: i wonder how custom layer modes differ from filters that take a second layer as input (e.g. LIC)? i mean, other than that filters currently work destructively. Hi, A layer mode is a formula for blending two pixels together, producing a result pixel. That is, the set of all layer modes is a subset of the set of all filters that blends two layers together, producing a result layer. There is one exception to this nice classification of layer modes; an output pixel when using the Dissolve layer mode does not only depend on two pixels, also on the position of these pixels. Spontaneously I don't think custom layer modes is a good idea. Might be fun for programmers to play with, but graphic professionals? While this is generally true... when switching apps, with a strongly established workflow including an app-specific layer mode, I can see this being quite useful. OTOH, this could also be implemented by a drop-in replacement for layer merging that supports additional modes (ranging 0x80...0xfe in ID, perhaps), providing that contributing a new mode to such a GEGL op could be as painless and simple as writing the formula. And that method would be faster. Alternatively If you really need 'custom' layer modes, I see no reason why it cannot be applied as a layer effect, building a bit of GEGL graph from the existing layer modes and ops. So now that I've thought that out loud, My conclusion is: Could be quite helpful, we don't need full custom layer modes, If we support them in one way through layer effects, someone else could write a GEGL Op that implements formulaic customization separate to GIMP's codebase. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hello, On Wed, Apr 29, 2009 at 11:17 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote: guys, here is sort of a review of what has been discussed here: To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch. How is one supposed to paint on mask without bg/fg color swatch? That's not included in yahvuu's proposal, but I proposed something that could neatly solve that, and address gradient issues: replace the FG/BG color concept with FG + cycleable 4-long color history. In this situation, you could still press a single key to swap between two colors (you would be swapping the previous color with the current color). Pressing it multiple times could cycle further back (in both cases you could get a simple OSD -- see MyPaint for example.). 'previous color in the color history' still can have roughly the same usage, we would just not be giving that color special treatment by labelling it 'BG'. The 'FG to BG' gradients still make sense in this context, they could just become 'Current to old color' (and usage patterns should be virtually identical.) Peter's done a good job synthesizing the 'BGcolor' with the requirement to specify whether alpha channel is desired in any exported/flattened image, and also notices similar problems to you. The problems brought up by both of you, Alexandre and Peter, are addressed neatly by my proposal above. Perhaps it needs a mockup.. I feel it fits very well into yahvuu's proposition, turning its weakpoints into strong points. Something that hasn't been brought up, BTW: Flatten Image vs Merge Visible layers. Not exactly the same, but would become closer to each other if Peter's description was implemented. Maybe we need to attempt to rationalize that. The behaviour of Sample Merged seems fairly obvious here, but I'm bringing it up also, just in case. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com wrote: 2009/4/29 peter sikking pe...@mmiworks.net but some crucial things depend on the bg color. the gradient tool being the big show-stopper for me. the tool needs a redesign, but up to then the fg-bg type of interaction looks to be the most (universally) usable to me. Unless you make a ease and nice way of swathing (or alternating) colors, I'm against it. When you are painting (making a digital painting or painting on a mask...) in the current version you just hit X to alternate between bg / fg colors. Its just ease that way. I've already made a proposal that thoroughly addresses this twice in this thread. It is based on a system MyPaint (http://mypaint.intilinux.com) uses, so I've already tried a very similar system and found it very effective. It's simply a 5-slot color history, with X selecting from it (when a color is 'chosen', it goes into slot #1 in the history (slot #1 == FG/ actual painting color), the old color moves into slot #2, and the rest of the items are moved back if needed. Just standard history operation.) X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors) So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone. In case people have read it and simply not understood what I meant, I'll provide an animated GIF, and perhaps submit a derivation of the GIF to gimp-brainstorm.blogspot.com http://img.photobucket.com/albums/v449/neota/alphazero/animation.gif I'm not sure whether or not Yahvuu was alluding to my proposal when he says i think the gradient tool would work equally well if the swatches were named left - right. If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' - 'previous' David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi Jon! On Thu, Apr 30, 2009 at 4:35 PM, Jon Senior j...@restlesslemon.co.uk wrote: On Thu, 30 Apr 2009 11:01:08 +0930 David Gowers 00a...@gmail.com wrote: X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors) So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone. I didn't understand it at first, and believed that the idea was that 'x' would cycle through the colours in a palette. Meaning that the user would press 'x' once to change to a new colour and another four times to go back to the original. Looking at your animated gif it all makes a lot more sense, although I suspect that the timings will be critical. I would also (as a user) want some method of adjusting or loading those five colours, either via 5 swatches in the tool box, or a single choose colours dialog. Thanks for the feedback ! :) I envision that you would just choose colors whenever you want, and that new color would enter slot #1, and push back the other items (knocking the item in the old slot #5 out). This is how it works in MyPaint, and it's pretty effective. However, this may take some consideration as to when to adjust the color history, as the color selection dialog of GIMP allows you to tweak colors continuously, with no clear indication of when you're 'done' selecting a color. I guess we'd store a copy of the color which was in slot #1 before changing it, and then adjust the history (slots 2,3,4 - slots 3,4,5; stored color - slot 2; new color = slot 1) after a certain time delay(1.5 seconds?). In this way slot 1 would always be current, while avoiding overpopulating the history with minor tweaks of a single color. In the case of clicking to sample colors from gradients, the history ought to update each time the user releases the left mouse button. (Note: my understanding is that there is a distinct lack of users who are aware they can left-click to sample colors from gradients, sadly.) In the case where the popup dialog, or palettes, or eyedropping, or drag-n-dropping colors, is used, no delay is necessary (because the user is explicitly specifying when the color is 'ready'; the meaning of their actions is entirely unambiguous.) If you wanted to fill all 5 slots with 5 specific colors from the image, you'd just ctrl+click 5 times (assuming you're currently using a paint tool), or click one after another on 5 colors in your palette, or one of the other methods I mention above (that currently only effect the FG color). Simple. With that, I believe there is no need to edit anything other than a single color (slot #1, the current color) On a related note: The popup color editing dialogs have color history (A ColorNotebook?) (for example, doubleclick on a palette color) This is slightly different in nature to the kind of history I'm suggesting -- the popup history list is like a list of 'colors I like' (10 long; colors are only added explicitly with the '' button), whereas my history list of course is of 'colors I'm using right now (or recently)'. These two lists would not interact in any way, due to their fundamentally different application. It's important to depict these two color histories in a differing way, so that there is no confusion between the two types of history (semi-permanent vs transient) If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' - 'previous' It does also resolve a question that was floating around in my head as to what the new non-background colour would be called. The gradient tool is an obvious example of one where the foreground/background naming convention is strong, and easy to understand. This might require that the choose colours dialog allows a method for swapping the colour order, because having to do it using only 'x' could get annoying when arranging two colours for use in a gradient. Again, a maximum of two eyedroppings/ your method of choice should easily arrange the color history appropriately. Also, my experience with MyPaint is that needed keypresses are few -- remember, you would only have to press X a maximum of 8 times to get any two colors to the front. The '8' example comes from if you want slots #5, #4 transferred to #2, #1. You press X four times to select #5, and wait a short time (1.5s?); then press X another four times to select #4 (which became #5 after your previous selection). the history looked like this (letters represent colors rather than slots) ABCDE and after the first step it looks
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 9:13 PM, yahvuu yah...@gmail.com wrote: Hi David, here's a mockup idea on your proposal; might or might not help to identify the current-previous color pair... just brainstorming. I hope you're not bothered i'm sending private mail - it's just i can't contribute anything generally useful on the topic, much along the lines of what Martin said. When Martin said that, I thought that just means it's inappropriate for us to make the decisions. It doesn't mean we shouldn't do research -- in fact, I'm sure Peter Sikking would appreciate it. Hence, I've CCed this to the list. All i know (or imagine to know ;) is that the only tool which requires the background metaphor is the eraser, including the 'selection erasers' delete and cut. I don't even see a conflict with bg-color-layer, despite that's where i started to question the bg color swatch.. So from my point of view, everything is open for the tool box, be it mypaint style, or even mypaint+bg color, color swatch plugins, left-right+bg color, you name it. I've looked at your image, and I'm not sure what it's supposed to be. A layout for the OSD? or a toolbox status display? Or something else? When you say 'toolbox' I'm also not sure whether you mean the optional colors display at the top of the toolbox, or the 'Colors' dockable (or both) Have you looked at MyPaint? It doesn't *have* a status display :) It allows you to edit the current color (via a shortcuttable menu item) and move through the color history; that's the only time you see the color history, via the Onscreen Display. The OSD I mocked up before is pretty close to what MyPaint's OSD looks like, though. I've created a mockup of my own idea of a toolbox status display. It's based on the old color display (I think we should try to take the same amount of space as before).. It's attached. I believe it makes the current + immediately previous color obvious, while clearly prioritizing the current color, and showing the other indication. I left the 'reset' and 'swap' icons there, because they still make some sense. In the OSD I mocked up, the current + previous color are always the rightmost color , and the color immediately next to it. So IMO no further indication is needed in the OSD. many thanks for taking the time for discussion and all the great work on GIMP, Thanks for starting this thread that so much interesting discussion has come out of :) David attachment: toolbox-color-mockup.png___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 10:36 PM, Rob Antonishen
rob.antonis...@gmail.com wrote:
I just ran through my scripts.
In the .scm files distributed with gimp, there were:
38 files containing gimp-context-set-foreground
65 files containing gimp-context-set-background
The ones I have looked at, mainly set background and then do a
edit-fill with BG or a drawable-fill.
looking at the scripts I have installed in my home directory, there were:
49 files containing gimp-context-set-foreground
29 files containing gimp-context-set-background
This is my no means a thorough assessment. Perhaps the individual
operating the gimp plugin registry could grep all the plugin files and
give a better count of the third party scripts using these calls.
There is no question of removing either of the above PDB functions,
AFAICS. It's just a matter of what to do to emulate the old FG / BG
behaviour. In the case of my proposition, FG would remain (as slot #1
-- 'current') and BG would map to slot #2 ('immediately previous').
However, one side effect is that setting FG could change BG (through
the normal history cycling mechanism). Erk.
David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Thu, May 7, 2009 at 7:54 AM, Martin Nordholts ense...@gmail.com wrote: Hi I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize, merge and push to GNOME master. The patches are attached to the bug report http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and test: cd ~/source/gimp tar -zxvf save-plus-export-2009-05-06.tar.gz git checkout -b save-plus-export-2009-05-06 master git am save-plus-export-2009-05-06/* this will create and switch to a new branch based on top of your local master branch, and apply the patches to that branch. Then you build and install as usual. This doesn't seem to work -- patch #0010 fails: Applying app: Add an 'export' mode to the file save dialog error: patch failed: app/dialogs/file-save-dialog.c:138 error: app/dialogs/file-save-dialog.c: patch does not apply Patch failed at 0010. The patch appears to be offset by about 10 lines. I applied it manually, and then ran git-am --skip Patch 0011 applied ok, Patch 0012 had problems: Applying app: Improve save and export error messages error: app/dialogs/file-save-dialog.c: does not match index Patch failed at 0012. Applied that manually, Patches 013..017 applied OK. 018 says : Applying app: Remember last export URI for each image error: app/dialogs/file-save-dialog.c: does not match index error: patch failed: app/file/gimp-file.h:27 error: app/file/gimp-file.h: patch does not apply Patch failed at 0018. Done manually, 019 fails similarly, done manually, same for 020, 021 022 applied ok. It's possible that I didn't understand how to 'resolve' a problem ( now I think it is, apply the patch manually, 'git add' the relevant files, and 'git am --resolved') I'm now trying to build it.. Trying it out.. This works REALLY well! I 3 it! It behaves much more comfortably than the old setup, I anticipate no longer needing to awkwardly 'save copy' so frequently simply to get a web-usable version of the image. I like how, if I hit 'revert', it properly reverts to the source image (eg 12.gif rather than the working document 12.xcf) I was confused by how 'export to foo.png' was only usable once the image became dirty (ie. I changed it ). If that is considered appropriate behaviour, then your ability to 'save' should also depend on the dirtiness of the image David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au wrote: I can find the functions in the pdb to manipulate the undo stack - is there a function call that just does an undo? No. Although this might conceivably change in the future as GIMP integrates GEGL. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi David, On Sun, May 10, 2009 at 10:34 PM, David Hodson hods...@ozemail.com.au wrote: On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote: On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au wrote: I can find the functions in the pdb to manipulate the undo stack - is there a function call that just does an undo? No. Although this might conceivably change in the future as GIMP integrates GEGL. What does it have to do with GEGL? There's already an undo button there, it just needs to be connected to the API. No it doesn't (in fact, I'm sure a few GIMP developers might argue that it definitely needs to NOT be connected to the API (ie. stay as it currently is)). This has come up before, to the response essentially 'why would we court trouble by implementing such a thing?' While it *could* be connected to the API, that would introduce various logical inconsistencies (for example, plugins could not rely on having a sensible image state because other plugins (running concurrently, or called by the plugin itself) might roll back the image state. Then the user can still make sense of the image state, but the plugin has no idea what it is, it could be anything. This is particularly bad if a crash is happening, as it also reduces your ability to correctly deduce the cause of the crash.) GEGL would allow a graph-based image structure, in which conventional plugins might not be needed (rather, new GEGL Operations could be implemented via a much simpler type of plugin.) This might help address the above concerns, as well as helping to support more sophisticated undo/versioning structures than our current 'piece of string' model, like trees. Hmm, I take it back, GEGL would not help the likelihood of such a thing being implemented.. it's just a Bad Idea. For just the same reasons that Global Variables are a bad idea. As the Zen of Python says: Explicit is better than implicit. Complex is better than complicated. In the face of ambiguity, refuse the temptation to guess. If the implementation is hard to explain, it's a bad idea. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi, On Tue, May 12, 2009 at 6:48 PM, David Hodson hods...@ozemail.com.au wrote: On Mon, 2009-05-11 at 12:57 -0700, Stuart Axon wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. Exactly. A more accurate description of what I was looking for would be mark this point in the undo stack and revert to the marked undo point. (With an error code if the undo point no longer exists.) This approach seems more reasonable -- if the point to undo to must be explicitly identified (in the same manner that each version of a GIT repository has a unique id), there is no ambiguity involved; you are undoing a specific known part, and if that was already undone, a clear error can be raised. In order to do this, each undo step should have a unique ID. Currently, the GimpUndo structure includes a 'time' field; This might be sufficient as a unique ID if it is precise enough (eg. measured in microseconds) Photoshop has a similar feature called 'snapshots' which is user-accessible. I'm not sure whether that kind of thing is a wise thing to implement. Providing an API to programmatically do such things seems fairly uncontroversial to me, though. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please, Please Bring Back Old GIMP.
On Tue, May 26, 2009 at 9:00 AM, Sue for...@gimpusers.com wrote: Hi GIMP Developers, I am a longtime GIMP fan, and I am highly disappointed with the Version 6.6 UI. One thing I have always enjoyed about this program is the fact it was not like Photoshop, because I could multitask with other programs (I could be searching for other pictures in the background in the Windoze file explorer), minimize what I wanted, detach windows whenever I wanted (veery nice), and resize the brush in the Brush Editor on will, and minimize it when I needed. Now I can't do those things, and it looks like Photoshop. I find it irritating now that I've got keep the Brush Editor open all the time and it If you just use the Brush editor to resize the brush, I suggest you begin using the Brush Scale slider in the tool options instead; It's probably faster. resets its size whenever I re-open it. I find the new Navigator tool disorienting to use, and I can't be as precise either when I need to go to the exact pixel on the corner because the thing moves. I also don't like not having control over my windows anymore. Not having control over your windows is not caused by GIMP. I certainly have all the control over GIMP windows I need, and individual dockable windows keep their size and position as you seem to desire. Of course, if you close a dockable, you are saying 'throw away all information about this dockable', so in that case, naturally when you open a dockable of the same kind, it is simply put in a default position and size. However, with the various systems (which have been there before 2.0 even), like TAB and F11, you should usually not ever need to close a dockable. Especially if you dock them together to form a joined window or a set of tabs. Also, you might be thinking of the change of a default preference, which effects whether dockables are shown on top of all other windows. This change occurred somewhere after 2.4, I think. Anyway it does not impede you -- just change the preference back. GIMP 2.6 is also not single-window. It's a minimum of two windows (image window + toolbox), and can be much more according to how many images you open at once or dockables you open. There are plans to allow a full single-window interface, however this behaviour is a) not implemented yet... at all, really b) intended to be completely optional, allowing you to use either a single or multi-window setup according to your preference. c) not ever going to be Window-inside-Window as some people claim to want. Some people even perceive 2.6 to be Window-inside-Window, but it's not (as demonstrated eg. when you move the toolbox) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please, Please Bring Back Old GIMP.
On Tue, May 26, 2009 at 9:41 AM, Sparr spa...@gmail.com wrote: I disagree with of course and naturally. When I close [child/sub] windows[/tabs] in most applications, then reopen the [functionally] same window, I expect it to come back in the same state it was in when I closed it. I regularly open and close the dockable windows, and add/remove things to them, and the amnesiac nature of all apsects of this process is very annoying. This issue was actually discussed before -- IIRC it was decided that implementing this behaviour would cause even more confusion (essentially because the 'functionally' same dockable is not actually the same dockable. The other technical problem is that there can be more than one instance of some dockables instantiated, in which case there is no clear way to decide which 'old' positioning and parameters to use.. this would certainly be very confusing.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement for eraser/brush tools: resurrect erased/cleared
On Tue, May 26, 2009 at 4:52 PM, Alchemie foto\grafiche fotocom...@yahoo.it wrote: How does this differ from the current anti erase tool option (quickly enabled also by holding Alt key)? Maybe does not differ BUT there is a Problem there is not any documentation in the help on a anti-erase option or tool so i believe almost only who contribute to implement it know about it This is simply not true. http://docs.gimp.org/2.6/en/gimp-tool-eraser.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH 1/4] Tile caching performance patches
I'd like to mention also that there are also some minor problems with whitespace i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0002*.patch Applying Add additional profiling to tile usage in order to analyze efficiency and behavior of the tile cache. Profiling includes run-time indication of idle swapper activity. .dotest/patch:193: trailing whitespace. guint zorched : 1;/* was the tile flushed due to cache pressure .dotest/patch:255: trailing whitespace. #endif .dotest/patch:304: trailing whitespace. #ifdef TILE_PROFILING .dotest/patch:318: trailing whitespace. .dotest/patch:319: trailing whitespace. #ifdef TILE_PROFILING warning: squelched 12 whitespace errors warning: 17 lines add whitespace errors. i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0003*.patch Applying Replace two list 'flush clean first' cache strategy with an LRu strategy. Although the clean-first strategy gives fast light-load performance, it also degrades catastrophically under moderate cache pressure. LRU is not as efficient under light load, but degrades more gracefully under moderate and heavy load. .dotest/patch:148: trailing whitespace. .dotest/patch:191: trailing whitespace. .dotest/patch:196: trailing whitespace. .dotest/patch:202: trailing whitespace. .dotest/patch:205: trailing whitespace. warning: squelched 8 whitespace errors warning: 13 lines add whitespace errors. i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0004*.patch Applying Correct startup flaw in idle swapper start: Don't watch only UI idling, but also watch that the cache itself is idle. Previously it would start during transforms and long pyramid rendering ops and toss writes and large seeks into the tile cache while it was potentially under heavy pressure. .dotest/patch:149: trailing whitespace. .dotest/patch:157: trailing whitespace. .dotest/patch:158: trailing whitespace. if(count=IDLE_SWAPPER_TILES_PER) .dotest/patch:186: trailing whitespace. .dotest/patch:194: trailing whitespace. warning: squelched 1 whitespace error warning: 6 lines add whitespace errors. (patch 0001 applies with no problems.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hacking GIMP - Gimp top level menu
toolrc On Wed, Jun 17, 2009 at 11:00 AM, Jordan Stinsonjordan.stinso...@gmail.com wrote: Thanks for the quick response. It looks like this will get me closer to what i'm actually after. When I use this method to add the hue saturation tool to the toolbox, it persists after I close gimp and reopen it. Could anyone tell me what file it's saved to? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New color mode
I'm pretty sure Emil refers to the Color drawing /layer mode and the way that it tends to 'burn out' colors -- the result of applying a colorization is often far more vivid than could reasonably be expected; Basically the same as the bug regarding improvement of Color mode cf. Photoshop. A few theories have been advanced on how Photoshop does it; they both agree that an RGB-based application such as the current HSL application is incorrect, and IIRC argue for either LAB or YIQ/YCbCr based color application. In my opinion LAB is higher quality, however YIQ/YCbCr get the job done with acceptable quality and higher speed. I can do some visual comparisons sometime soon if needed. Exactly what do you mean by color mode here? Do you mean that the default RGB - CMYK conversion produces too saturated colors? Best regards, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
2009/7/22 Fredrik Alströmer r...@excu.se On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudinealexandre.prokoud...@gmail.com wrote: On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote: Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user. So far I only heard from users thanks, but why is it not by default? :) I guess you wouldn't hear from people who like it the way the default is set, would you? :) Well you can hear from me: I like the global-brush setting; if it is accidentally turned off I find it very annoying, having to reselect brush between tools... usually I *do* want to keep just the same brush between tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off, there is an unavoidable mental 'thunk' to accommodate for the possible change of brush as you change tool; global-brush == off seems in this way to inherently slow the user's workflow (regardless of what workflow they use -- having to think 'oh, what is the brush of this tool' == slowdown.) A related issue is the difficulty of reliable brush selection. ideally I would hit a shortcut (say CTRL+B) and then type part of a brush name and hit enter to select it. The current brush selection methods either require direct pointing, are inaccurate, or only allow relative selection (ie. next brush, prev brush) (note: you can do absolute brush selection by this method IIRC: make sure your brushes dialog is set to List, then when you want to select a brush by name, hit [the shortcut for the brushes dialog], then CTRL+F and type the name fragment. This has two downsides - a) it's too much keyboard work for a common operation, b) it changes the focus, which means I have to mouse back to the image window or ALT-TAB before I can continue as before (say, adjusting the drawing opacity before I start painting)) Also, Alexandre says: Clear separation of default settings for different tools is such an obvious thing... I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow (and everyday workflow takes priority IMO.. A person remains a newbie for only so long, but the general consistency of workflow is something they will need to deal with as long as they use GIMP -- including any bureaucratic lumps such as (global-brush == off)) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
