Re: [Gimp-developer] Drawing zones
On Wed, Jan 17, 2007 at 08:52:48AM +0100, Sven Neumann wrote: I start to realize what you are asking for now. But, instead of suggesting a solution, could you perhaps try to explain where the problems are when you try to use the currently available features to implement your workflow? You should be able to do this with layers or selections. If that doesn't work for you, then perhaps there's something that we need to change about how layers and/or selections are handled. I don't think that we need to introduce a completely new feature. # The goal: Draw on several areas of an image while maintaining sharp edges around each of them (in many cases they will touch, so before I talked about edges between them). With the least amount of interruption! # Motivation You often have parts of an image that need the same treatment, but are clearly divided (like hand and body on my example image). You draw with the same base colour, draw light and shadow, texturing ... all best done in one go. [Drawing from scratch might not be seen as typical use of GIMP, but I know I'm not the only one and the closest commercial counterpart, Photoshop is used for this alot, even though there's Painter. Check for example http://forums.cgsociety.org/forumdisplay.php?s=f49edc03bcbdb53f623009e1366edda9f=133] # Layers Using layers, you will likely end up with one layer per area. You need to switch between them. Just today I took notice it can be done with Page Up/Down, layer name appears in status bar. If you don't use the shortcuts, you need the layers dialog, taking away space from the drawing area. If you use them, it's just a keypress, but you have to take care in which layer you end up (drawing something on the wrong layer is a mistake i make often enough, even usuing the layers dialog). # Selections Loading selections to me means having to change between layer and channel tabs and a lot of mouse movement away from the canvas. This already makes me use layers with locked alpha everywhere I can. Only with exactly 2 areas, one could use inverse selection. # Drawing zones I think drawing zones would have to be organised in sets. The zones of a set would always cover a full rectangle like layers do. Inside a set you would add/delete zones and select the zone you want to edit. Editing could then happen with the current selection tools. Masking would require 1 colour for each zone. I admit this sounds a bit complicated. Now for the nice part: once setup, you just draw! If you move the pointer outside the zone you started drawing in, nothing happens (just like painting outside a selection). You don't have to hit a single button, but get to focus on drawing completely. # Stop lines My initial idea was to have just lines (non-closed paths), which you can't draw past. So they act like a selection boundary, but are not closed. You could even draw all around them, something that might be helpful on drawing armpits. I then thought it might be hard to check for this, so closed regions/zones might be easier. The management of stop lines might be more simple, though. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Wed, Jan 17, 2007 at 01:18:35AM -0800, Saul Goode wrote: If I am understanding you correctly, these scripts should be helpful to you in your workflow. You would still have to manually invert the selection; but I would point out that the Select menu can torn off so that Select-Invert is just a mouse-click away. Sorry, no. I don't see the benefit over switching between layers. Lets try another description: Drawing zones would be like 2 or more non-overlapping selections that are active at the same time. Which one is applied to a drawing operation is determined by where the mouse/pen-down happens. Implicit area selection (to not say Selection selection) :) -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
Sorry, no. I don't see the benefit over switching between layers. #1: A selection does not overlap its inverse. #2: There is no need to keep track of which layers are associated with each other (and for switching between layers, presumably they would need to be adjacent in the layerstack). #3: Switching between drawing zones (i.e., inverting the selection) uses the same keystroke/action regardless of which zone is active. (For layers, the user would have to remember whether to activate the layer above or below.) #4: The Layers window is not cluttered with zone layers. Lets try another description: Drawing zones would be like 2 or more non-overlapping selections that are active at the same time. Which one is applied to a drawing operation is determined by where the mouse/pen-down happens. If the only difference is whether a mouse-click is used on the canvas or a keystroke/menu/widget action is used to invert the selection, I suspect you shall have a difficult time convincing the GIMP developers to add your concept of a drawing zone to the core and have it honored by all the paint tools. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Wed, 17 Jan 2007 16:00:00 +0100, Thorsten Wilms [EMAIL PROTECTED] wrote: On Wed, Jan 17, 2007 at 06:36:27AM -0800, Saul Goode wrote: If the only difference is whether a mouse-click is used on the canvas or a keystroke/menu/widget action is used to invert the selection, I suspect you shall have a difficult time convincing the GIMP developers to add your concept of a drawing zone to the core and have it honored by all the paint tools. No. First it's important that it's not an additional mouse-click. Not even a click, just where the button/pen-down happens if you start to draw. Keep in mind that what you are suggesting is a rather specialized use case. Even if the concept is interesting and would save you some time, it has a cost for all other GIMP users: menu clutter, additional stuff in the UI, etc. And of course there is also a cost for the developers, not only in implementing the feature but also in maintaining it and fixing bug reports releated to this new feature and its interaction with other current or future GIMP features. So unless you can convince the developers that the concept of Drawing Zones would be useful for a significant percentage of GIMP users, you have to balance the advantages of that new feature with the (minor) disadvantages that it would cause to all other users. It looks like the best solution in your case would be to use some keyboard shortcuts for switching quickly between layers: this would have a small cost for you without costing anything to anybody else. If you work 10 hours + on an image, every click more or less counts. Especialy not having to think about any other operation but drawing is a big one. On the other hand, if you work 10+ hours on an image and if you do that on a regular basis, then you could consider using some additional input device (e.g. MIDI controller) so that you can bind some of its controls to GIMP actions. I haven't checked what is really possible with cheap MIDI controllers, but you might be able to use a pedal or something like that and switch layers with your feet. :-) -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On 1/18/07, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Ok - I've read the request and got the idea. I have the followwing proposal: what if one had a set of pre-loaded selections, and could switch back and forth among then with a single keystroke - Do you (and others) think it could be as usefull/more usefull/just the same as these proposed drawing zones? Why do I ask this? Because implementing what you are asking requires some fiddling in the core, and will complicate the interface with another kind of object, besides selections, channels, layers, masks, guides, sample points and the grid... Ok, you can imagine that what it brings of convenience for some it brings of complication to certain user groups. The idea I propose, instead, would use already existing objects, like this: one would store his drawing zones as a set of selections, each in a separate image channel, and a simple script, with no imput parameters, would replace the current selection with a selection in the channel stack. Todo this manually, one would have to: 1) select the channel tab in the layers/channels dock 2) select the apropriate channel 3) click on channel to selection 4) change back to the layers tab on the dock 5) select the actyual layer where one is drawing back 6) start painting. Looking at this, it si a lot of work, and the drawing zones seems a better idea. However, a script fu can perform steps 1-5 with a single keystroke (if one will select the next/same/previous channel on the stack that has been previusly used). so it becomes: 1) hit key that changes teh selection until the desired selection is set 2) start painting Which seems as practical as the drawing zones proposal. There is a final advantage in this proposal: it is ready for serving _now_,a s writing such a script would take less than 30min. What do you say? js -- That sounds good. It allows some sort of status display (make the active zone the only visible channel) and is flexible. It misses one of the values of binary, mutually-exclusive selections, though -- they can all be stored in one channel, and if you decide a certain area should belong to a different zone, you only have to fill that area on one channel. In Python, this is fairly simple to implement: * Name the channel like 10-Zonemap; Current: AA (layertattoo-Zonemap; current: XX) * The cycle op extracts the 'current' specifier (ranging 00-ff -- ie a pixel intensity in hex) and chooses the next unique value found in the channel. It loads the zonemap into the selection and thresholds it accordingly. Then it updates the channel name: 10-Zonemap; Current: CC I want this, so I'll implement it today. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On 1/18/07, Manuel Quiñones [EMAIL PROTECTED] wrote:
I've had a similar idea than yours, and implemented it right away. But
instead of changing zones with keystrokes, the zone can be selected
using the crosspoint of two perpendicular guides. I know this is ugly,
and maybe your idea about changing to next/previous zone is better.
Here it is:
http://www.box.net/public/arhs7a3h9m
I'm sorry but not direct link. I cannot register it to the gimp
registry, because of http errors. And a fine tutorial:
http://wiki.gimp.org/gimp/DrawingZones
Regards,
Manuel
That gives me an idea: Sample points are probably quite appropriate to use
here. We just need a PDB interface to access them.
My implementation of my idea is attached. It ISN'T a plugin, it's just a
module that can be copy+pasted into a plugin.
(or in my case, imported. I have written 360k of libraries for pygimp so I
set up PyGimp to be able to find them)
def zonemapInfo(drawable):
Return a (maybe newly created) zone map and the currently selected area number
import gimp
tattoo = drawable.tattoo
channels = drawable.image.channels
searchstring = '%d-Zonemap;' % tattoo
# if there isn't one, just create one.
channels = filter(lambda v: v.name.startswith (searchstring), channels)
if len (channels) == 0:
# create a new zonemap
image = drawable.image
zonemap = gimp.Channel (image, '%d-Zonemap; Current: 00' % drawable.tattoo, image.width, image.height, 100.0, gimp.get_foreground())
from gimpenums import FOREGROUND_FILL
zonemap.fill (FOREGROUND_FILL)
image.add_channel(zonemap)
return zonemap, 0
zonemap = channels[0]
import re
current = re.findall([0-9]+-Zonemap; Current: ([0-9a-fA-F]{2,2}),zonemap.name)[0]
current = int (current, 16)
return zonemap, current
def nextZonemapValue (zm, thisv):
Return the next area number used in the zonemap
import gimp
pr = zm.get_pixel_rgn(0,0, zm.width, zm.height, True, False)
data = pr[:,:]
r = range((thisv+1) % 256, 256)
if r[0] 0:
# wraparound
r.extend (range (0, thisv + 1))
for v in r:
if chr(v) in data:
return v
return 0
def cycleZonemap(drawable):
Cycle to the next area defined in the zonemap
zonemap,activepoint = zonemapInfo (drawable)
nextv = nextZonemapValue (zonemap, activepoint)
drawable.image.undo_group_start()
from gimp import pdb
pdb.gimp_selection_load(zonemap)
from ai.gimp.pibgimp.tools import threshold
threshold(drawable.image.selection, nextv, nextv)
zonemap.name = '%d-Zonemap; Current: %02x' % (drawable.tattoo, nextv)
drawable.image.undo_group_end()
def enforceZonemap(drawable):
Limit the selection to the currently selected zonemap area
zonemap,activepoint = zonemapInfo (drawable)
# intersect the thresholded zonemap with the selection.
drawable.image.undo_group_start()
tmp = zonemap.copy()
zonemap.image.add_channel (tmp)
from ai.gimp.pibgimp.tools import threshold
saved = drawable.image.selection.copy()
drawable.image.add_channel(saved)
# channel apply
import gimp
gimp.pdb.gimp_selection_none (drawable.image)
threshold(tmp, activepoint, activepoint)
gimp.pdb.gimp_selection_load (saved)
drawable.image.remove_channel (saved)
gimp.delete (saved)
from gimpenums import CHANNEL_OP_INTERSECT, CHANNEL_OP_REPLACE
op = CHANNEL_OP_INTERSECT
if gimp.pdb.gimp_selection_is_empty (drawable.image):
op = CHANNEL_OP_REPLACE
gimp.pdb.gimp_channel_combine_masks (drawable.image.selection, tmp, op, 0, 0)
#gimp.pdb.gimp_selection_sharpen(drawable.image)
zonemap.image.remove_channel (tmp)
gimp.delete(tmp)
drawable.image.undo_group_end()
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
Hi, On Wed, 2007-01-17 at 18:03 +0100, Thorsten Wilms wrote: Thinking some more about this, a switch to highest in the stack layer with non-zero alpha at pointer location, option, triggered on button/pen-down before drawing is actually executed could do the trick while been least intrusive in GIMP. This is to some extent already handled in http://bugzilla.gnome.org/show_bug.cgi?id=86274 Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enabling plugins to get the user to click a point on the image.
Manuel pointed out, The gimp currently lacks any way for a plugin to get a coordinate from the image (eg. click on the 'seed' pixel). I've often wanted to do this, and it is a bit awkward without it. Has implementing this been avoided, or is it just an oversight? Some example usages: * Color mixer: click on any number of pixels then press ENTER to set FGcolor to a mix of all those colors. * Zone selector: click on a zone to select it * Word balloon creation (see a recent post on gimp-user) -- click a series of 5 points to draw a word balloon (size, point shape and location) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
Hi, On Wed, 2007-01-17 at 09:45 -0500, Christopher Curtis wrote: Something to consider, I think, is momentum. I think that people want to be part of a vibrant developer community. If a project does not have this, it may be beneficial to create an artificial one by increasing the number of releases. To this end, it may be wise to make future releases more bite-sized: 2.6 implements CMS workflow and fixes 2.4 problems. 2.8 introduces Cairo rendering. And then 3.0 can integrate GEGL. That's what we are targeting for with 2.6. It will be a short development cycle with only very few changes. But there are people waiting to be able to commit GEGL code into the GIMP tree. So we will definitely not wait with that. The transition to GEGL will take a while anyway and the user won't notice in the beginning anyway. Now, I'm not trying to be so bold as to propose a schedule, but it seems that if there were three or four releases this year - 2.4 now, then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per release. Asking people to wait for the next release to include your plugin doesn't sound so severe then. The biggest burden I think would fall to the translators, which is something that developers just need to be sensitive to. Four releases per year is impractical. We wouldn't get anything done because we would be busy preparing releases all the time. Even the two releases per year schedule that GNOME is running is considered to be too short by most developers. And we can't release 2.4 now. It may even take another four months before we are there. Have a look at the bug reports on milestone 2.4. A few of them can be postponed but there are still some major ones that absolutely have to be addressed. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling plugins to get the user to click a point on the image.
Hi, On Thu, 2007-01-18 at 17:28 +1030, David Gowers wrote: Manuel pointed out, The gimp currently lacks any way for a plugin to get a coordinate from the image (eg. click on the 'seed' pixel). I've often wanted to do this, and it is a bit awkward without it. Has implementing this been avoided, or is it just an oversight? It doesn't seem to fit into the current architecture. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] getting 2.4 out of the door
Hi, I get the impression that some people on this list are not really interested in getting 2.4 out. Otherwise we wouldn't be discussing so many things that are unrelated to the 2.4 release. Can we perhaps try to concentrate everyone's efforts on the next release? I would really like to iron out the remaining bits and get it out. That said, Adrian, you volunteered to coordinate the effort of looking over the brushes to ship with 2.4. I haven't heard anything about that since then. Can we at least get the proposed VBR brushes in, please? Raphael, what about your status bar message changes that are supposed to go in under the string freeze? And what are the plans for the metadata editor? I will try to prepare a 2.3.14 release over the next days. But that shouldn't keep anyone from working on the tree and committing fixes. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
