HOWTO: stroke a path with the current tool?
This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
HOWTO: stroke a path with the current tool?
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
(What I see are only choices of "Paint" tools. What I want is "Select tools", like color select and/or magic wand.)
=======================================================
An alternative would be to use Script-Fu API to "walk along a path"; but I would need to "invoke the current tool at the specified point" from Script-Fu, and I can't guess how to find this with the Script-Fu procedure browser...
Any help would be appreciated, Ilya
HOWTO: stroke a path with the current tool?
On Fri, Sep 11, 2009 at 3:39 AM, Ilya Zakharevich wrote:
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
(What I see are only choices of "Paint" tools. What I want is "Select tools", like color select and/or magic wand.)
=======================================================
An alternative would be to use Script-Fu API to "walk along a path"; but I would need to "invoke the current tool at the specified point" from Script-Fu, and I can't guess how to find this with the Script-Fu procedure browser...
Any help would be appreciated, Ilya
Hmm - I can't find a way to access the current tool through the PDB. Am I mistaken?
I was playing with this idea a bit (in Python), and vector.stroke.interpolate will give a list of points along a path - I assume this function is also available in script-fu. I've pasted what I was messing around with below, but w/o access to the current tool, it's a bit useless as a plug-in ;)
Chris
#!/usr/bin/env python
# Author: Chris Mohler
# Copyright 2009 Chris Mohler
# License: GPL v3
# Version 0.1
# GIMP plugin to use arbitrary tool along a path
from gimpfu import *
gettext.install("gimp20-python", gimp.locale_directory, unicode=True)
def tool_on_path(img, paths):
try:
# get active path
path = pdb.gimp_image_get_active_vectors(img)
# get points on the path points = path.strokes[0].interpolate(0.1)[0]
# empty return message ret = ""
# process points
for i in range(len(points)/2):
x = points.pop(0) y = points.pop(0)
# collect points for message ret = ret + str(i) + ": " + str(x) + "," + str(y) + "\n"
# don't see any way to grab the active tool, so...
# just do a ellipse select, 20 px wide
pdb.gimp_ellipse_select(img, x-10.0, y-10.0, 20, 20, 0, 1, 0, 0)
# output message to error console
# gimp.message(ret)
except:
pass
register(
proc_name=("python-fu-tool-on-path"),
blurb=("Tool on Path"),
help=("Use arbitrary tool along a path."),
author=("Chris Mohler"),
copyright=("Chris Mohler"),
date=("2009"),
label=("Tool on Path"),
imagetypes=("*"),
params=[
(PF_IMAGE, "img", "Image", None),
(PF_VECTORS, "paths", "Paths", None)
],
results=[],
function=(tool_on_path),
menu=(""),
domain=("gimp20-python", gimp.locale_directory)
)
main()
HOWTO: stroke a path with the current tool?
Ilya Zakharevich wrote:
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
You can. If you choose Stroke Path from the Paths right-click menu, the bottom of the dialog has a radio button that says Stroke with a Paint Tool. Click that radio button and select the paint tool you want to use from the dropdown. It will use your last set of tool options for that tool. Alternatively, while the dialog is still up, you can switch to that tool and quickly tweak the tool settings there prior to clicking the Stroke button.
Is that what you were looking for?
-Jason
HOWTO: stroke a path with the current tool?
On Fri, 2009-09-11 at 08:39 +0000, Ilya Zakharevich wrote:
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
(What I see are only choices of "Paint" tools. What I want is "Select tools", like color select and/or magic wand.)
You can't do that.
=======================================================
An alternative would be to use Script-Fu API to "walk along a path"; but I would need to "invoke the current tool at the specified point" from Script-Fu, and I can't guess how to find this with the Script-Fu procedure browser...
I am afraid there is no way to do this for tools like 'color select' or 'magic wand'. Tools are a user interface thing and the PDB explicitly doesn't give access to the user interface parts of GIMP.
Sven
HOWTO: stroke a path with the current tool?
Gah... This is what I get for sending emails prior to drinking coffee. I just now noticed that you posted this:
(What I see are only choices of "Paint" tools. What I want is "Select tools", like color select and/or magic wand.)
Obviously my answer isn't gonna cut it then. Sorry about that.
-Jason
Jason van Gumster wrote:
Ilya Zakharevich wrote:
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
You can. If you choose Stroke Path from the Paths right-click menu, the bottom of the dialog has a radio button that says Stroke with a Paint Tool. Click that radio button and select the paint tool you want to use from the dropdown. It will use your last set of tool options for that tool. Alternatively, while the dialog is still up, you can switch to that tool and quickly tweak the tool settings there prior to clicking the Stroke button.
Is that what you were looking for?
-Jason
Script-Fu vs GIMP UI
On 2009-09-13, Sven Neumann wrote:
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
(What I see are only choices of "Paint" tools. What I want is "Select tools", like color select and/or magic wand.)
You can't do that.
Is it a defect, or an intentional decision?
An alternative would be to use Script-Fu API to "walk along a path"; but I would need to "invoke the current tool at the specified point" from Script-Fu, and I can't guess how to find this with the Script-Fu procedure browser...
I am afraid there is no way to do this for tools like 'color select' or 'magic wand'. Tools are a user interface thing and the PDB explicitly doesn't give access to the user interface parts of GIMP.
This sentence does not make any sense to me. To make sense, one should have a PRIOR definition of "the user interface parts of GIMP". E.g., from what you write, It looks like foreground color is not in "the user interface parts of GIMP".
So. is there such a definition? Is it defined as "any setting outside those related to save/restore-state Script-Fu API", or is there anything else accessible from Script-Fu?
Thanks, Ilya
- postings
- 22
Script-Fu vs GIMP UI
What kind of outcome are you expecting to get when stroking a path with a
selection tool?
I can't think of why you want to do this? Maybe someone can help you if we
know what it is that you are trying to accomplish.
Script-Fu vs GIMP UI
Hi,
On Sun, 2009-09-13 at 23:42 +0000, Ilya Zakharevich wrote:
I am afraid there is no way to do this for tools like 'color select' or 'magic wand'. Tools are a user interface thing and the PDB explicitly doesn't give access to the user interface parts of GIMP.
This sentence does not make any sense to me. To make sense, one should have a PRIOR definition of "the user interface parts of GIMP". E.g., from what you write, It looks like foreground color is not in "the user interface parts of GIMP".
The foreground color is part of the context, which is not part of the user interface. The user interface just controls the user context. The fact that script-fu, or rather the PDB, allows to change things in the user context, such as the foreground or background color, is actually a misconception that was made early in the GIMP development. We tried later to correct this by introducing script-specific contexts. But since we didn't want to break existing scripts, we had to introduce 'gimp-context-push' and 'gimp-context-pop'. All scripts that wish to change the context are supposed to use these, so that they get their own context. This way the user context (which is what the GIMP user interface uses), is not affected by scripts.
So. is there such a definition? Is it defined as "any setting outside those related to save/restore-state Script-Fu API", or is there anything else accessible from Script-Fu?
The code in app makes a very clear distinction between the core and the user interface. If you want to understand the details, please have a look at the code.
Sven
Script-Fu vs GIMP UI
On 2009-09-14, Jolie S wrote:
What kind of outcome are you expecting to get when stroking a path with a selection tool?
??? Obviously, the same as when I click repeatedly along the path... Imagine "select color" with "add to selection" and small threshold...
I can't think of why you want to do this? Maybe someone can help you if we know what it is that you are trying to accomplish.
E.g., select colors close to any one in the path.
Thanks, Ilya
- postings
- 22
Script-Fu vs GIMP UI
??? Obviously, the same as when I click repeatedly along the path... Imagine "select color" with "add to selection" and small threshold...
if we
know what it is that you are trying to accomplish.
E.g., select colors close to any one in the path.
Thanks, Ilya
I'm equally confused as you are, but that's probably me, I'm not a GIMP expert (yet).
You say you want to select a color close to any one in the path, but a path
isn't a color. ???
All I can think of is if when you stroke a path with say the foreground
colour you get a line of that color where the path is.
So if you would stroke the path with a selection tool you would just select
the path, so why not just use path to selection.
My apologies if I get it all wrong, like I said, still working on becoming an expert. ;-)
jolie
Script-Fu vs GIMP UI
On 2009-09-15, jolie S wrote:
??? Obviously, the same as when I click repeatedly along the path... Imagine "select color" with "add to selection" and small threshold...
E.g., select colors close to any one in the path.
You say you want to select a color close to any one in the path, but a path isn't a color. ???
Still, points on path have colors. (Was it "in" vs "on" which made this so hard to understand?)
All I can think of is if when you stroke a path with say the foreground colour you get a line of that color where the path is.
Wrong. Try it with different brushes...
So if you would stroke the path with a selection tool you would just select the path, so why not just use path to selection.
??? Are you under impression that a selection tool selects the point you click on? Or what?
[I specially mentioned "color selection" tool.]
Yours,
Ilya
HOWTO: stroke a path with the current tool?
Quoting Ilya Zakharevich :
I want to stroke the path with the current tool, with all the parameters as selected in the tool options. I do not think I can do it with the PATHs right-mouse-click menu, can I?
As has been stated, this is not possible.
An alternative would be to use Script-Fu API to "walk along a path"; but I would need to "invoke the current tool at the specified point" from Script-Fu, and I can't guess how to find this with the Script-Fu procedure browser...
Your script would have to manually traverse the paths. I have written a Script-fu which does this for Fuzzy selections; the command is added to the context menu raised by right-clicking on a path in the Paths Dialog. The script can be retrieved from http://flashingtwelve.brickfilms.com/GIMP/Scripts/Temp/sg-fuzzy-select-along-path.scm
Doing similarly for the Select By Color tool is possible, but would require a more complicated script owing to the fact that 'gimp-drawable-get-pixel' can not directly fetch from the projection, and that working with channels or masks would require some massaging of the colors retrieved with 'gimp-drawable-get-pixel' so that it can be used by 'gimp-by-color-select'. The best approach to this would likely be to create a new image from the drawable or projection, copy the path to the new image, perform the walking selection along the path, and then move the resulting selection back to the original image.
HOWTO: stroke a path with the current tool?
saulgoode@flashingtwelve.brickfilms.com wrote (in part) (on 2009-09-15 at 10:57):
Your script would have to manually traverse the paths. I have written
a Script-fu which does this for Fuzzy selections; the command is
added to the context menu raised by right-clicking on a path in the
Paths Dialog. The script can be retrieved from
http://flashingtwelve.brickfilms.com/GIMP/Scripts/Temp/sg-fuzzy-select-along-path.scm
Saul - interesting script but it seems to take a very long time. Just to see what the difference it would make, I drew an arbitrary path through an image and ran your script against it, copied the selected region and pasted it to a new layer ... then on the same path, using fuzzy select tool (with same parameters) with Shift key down (additive select) clicked manually along the path where by eye I detected changing colors and again copied resulting selection to a new layer ... then set difference mode to compare what had been selected by your script vs what I had selected "manually".
two layers were almost identical but "manual" took a fraction of the time. Next tried a complex path (the result of a Fuzzy Select Tool followed by selection to path). This took a **very** long time and eventually stalled - per Process Explorer GIMP was consuming 1.25 GB of memory :-(
Suggestion: Would it be possible as you "walk" the path, to compare each pixel to prior and if they are the "same" to within the threshold tolerance skip that pixel and proceed to next? My theory being that if two adjacent pixels on a path are within "threshold tolerance" of each other then fuzzy select on either is the same as fuzzy select on both.
HOWTO: stroke a path with the current tool?
Alec Burgess wrote:
Suggestion: Would it be possible as you "walk" the path, to compare each pixel to prior and if they are the "same" to within the threshold tolerance skip that pixel and proceed to next? My theory being that if two adjacent pixels on a path are within "threshold tolerance" of each other then fuzzy select on either is the same as fuzzy select on both.
Even more simple: Couldn't you use gimp-selection-value to test whether the specified pixel is already in the current selection as you walk the path? If it is, then you can skip that pixel and move on to the next one. It's basically the same idea Alec posted, but rather than using a threshold value in the script, just use the existing selection (and therefore the current Threshold value for the Fuzzy Select tool) as your threshold.
Dunno... just an idea.
-Jason
HOWTO: stroke a path with the current tool?
[Repost after a list resurrection]
On 2009-09-15, saulgoode@flashingtwelve.brickfilms.com wrote:
a Script-fu which does this for Fuzzy selections; the command is added to the context menu raised by right-clicking on a path in the Paths Dialog. The script can be retrieved from http://flashingtwelve.brickfilms.com/GIMP/Scripts/Temp/sg-fuzzy-select-along-path.scm
I'm confused on why gimp-vectors-set-visible() is used. Any hint?
And I can't guess reasons why you first do gimp-selection-none(), then combine the orig-sel back?
And why do you need to set the drawable (which was initially active) "active again" at end of operation?
Doing similarly for the Select By Color tool is possible, but would require a more complicated script owing to the fact that 'gimp-drawable-get-pixel' can not directly fetch from the projection, and that working with channels or masks would require some massaging of the colors retrieved with 'gimp-drawable-get-pixel' so that it can be used by 'gimp-by-color-select'.
Is there no way to get-pixel() meaning "visible pixel"? I understand that this might be problematic when started from context menu of "Paths" (may there be multiple "views" of an image with different visiblity flags of masks/layers?), but if started from menu of Image window", GIMP knows which "view" (is it what you call "projection"? I found no definition in the docs) the user means...
The best approach to this would likely be to create a new image from the drawable or projection, copy the path to the new image, perform the walking selection along the path, and then move the resulting selection back to the original image.
I would very much prefer to avoid this. The image is about 0.1GPix already with a few layers, and the hardware is close to 10years old...
And: if I want to operate "on one layer only", would cadr of the result of gimp-drawable-get-pixel() suitable as argument to gimp-by-color-select()?
Thanks, Ilya
HOWTO: stroke a path with the current tool?
[Repost after a list resurrection]
On 2009-09-19, Jason van Gumster wrote:
Suggestion: Would it be possible as you "walk" the path, to compare each pixel to prior and if they are the "same" to within the threshold tolerance skip that pixel and proceed to next? My theory being that if two adjacent pixels on a path are within "threshold tolerance" of each other then fuzzy select on either is the same as fuzzy select on both.
Even more simple: Couldn't you use gimp-selection-value to test whether the specified pixel is already in the current selection as you walk the path? If it is, then you can skip that pixel and move on to the next one.
If you do not mind that the result is going to be majorly different - maybe.
*I* think that for best result, one needs an additional *relative* threshold. E.g., if main threshold is 12, and relative is 30%, then one would skip pixels which differ from a preceeding one by less than about 4.
If this relative threshold is close to 100% (which is essentially what you recommend), then the result will be quite different comparing to one with low threshold.
Yours, Ilya
HOWTO: stroke a path with the current tool?
Quoting Ilya Zakharevich :
I'm confused on why gimp-vectors-set-visible() is used. Any hint?
I did that merely so I could watch how the process progressed along the path. It is not functionally necessary.
And I can't guess reasons why you first do gimp-selection-none(), then combine the orig-sel back?
I assumed that you wanted to add together all of the fuzzy selections made along the path, and then combine that result with the original selection using the operation mode. To not do so would lead to some rather useless results.
For example, if the operation mode were CHANNEL-OP-REPLACE and this was passed to 'gimp-fuzzy-select-full' then despite making fuzzy selections all along the path, the only thing that would matter would be the fuzzy select performed on the path's last point.
Also consider what happens if the 'operation' mode were CHANNEL-OP-INTERSECT and the original selection was the entire image (if there were no selection originally then the final result would be no selection). If I merely passed the INTERSECT mode to Fuzzy Select then after the first x,y point on the path was "fuzzy selected", the resulting intersection would be only that fuzzy selection. Moving to the next x,y point and the resulting selection would only be the intersection of the two Fuzzy Selects. At any point along the path -- including the last point on the path -- the resulting selection will be no larger than the intersection of that point's fuzzy selection and the one before it.
And why do you need to set the drawable (which was initially active) "active again" at end of operation?
A script not leaving any drawable active after execution would be very "impolite"; however, you are correct that this particular script would not do that even if the original drawable wasn't re-activated (the original drawable is never made inactive in this script).
The re-activation was a remnant of alternate version of the script which also handled By Color Select. In order to perform By Color Select in "sample merged" mode, it was necessary to create a temporary layer that contained the merged image ('gimp-drawable-get-pixel' only works with a drawable). After the By Color Select was processed, the script deleted the temporary layer -- leaving no drawable active -- and then needed to re-activate the original active drawable.
Is there no way to get-pixel() meaning "visible pixel"? I understand that this might be problematic when started from context menu of "Paths" (may there be multiple "views" of an image with different visiblity flags of masks/layers?), but if started from menu of Image window", GIMP knows which "view" (is it what you call "projection"? I found no definition in the docs) the user means...
The "projection" is the composited result of all of the layers, employing all settings for the specified blend modes, opacities, masks, and visibilities -- it is what you see in the image window. There is no direct access to the projection contents from the PDB and since 'gimp-drawable-get-pixel' does not provide a "sample merged" mode, it would be necessary create a new layer that contains the projection contents (in other words, do the equivalent of "Layer->New from visible").
The best approach to this would
likely be to create a new image from the drawable or projection, copy the path to the new image, perform the walking selection along the path, and then move the resulting selection back to the original image.I would very much prefer to avoid this. The image is about 0.1GPix already with a few layers, and the hardware is close to 10years old...
And: if I want to operate "on one layer only", would cadr of the result of gimp-drawable-get-pixel() suitable as argument to gimp-by-color-select()?
I basically gave up on my attempt to create a By Color Select version because of all of the edge cases that needed to be handled: layer offsets and dimensions (path coordinates are relative to the image, 'get-pixel' uses the drawable coordinates), changing colorspaces (mask and channels are grayscale, while a layer may or may not be), and image/drawable boundaries (paths are not constrained to the image). All of these distinctions are dependent upon whether the colors are being "sample merged", thus further complicating things.
If you wanted just a simple version which handled only a single layer (not its mask, nor a channel) which had the same dimensions as the image (and no offsets), and did not need to provide a "sample merged" option, I could write one sometime later this evening.
HOWTO: stroke a path with the current tool?
On 2009-09-30, saulgoode@flashingtwelve.brickfilms.com wrote:
A lot of thanks for helping me understand this problem.
And I can't guess reasons why you first do gimp-selection-none(), then combine the orig-sel back?
I assumed that you wanted to add together all of the fuzzy selections made along the path, and then combine that result with the original selection using the operation mode. To not do so would lead to some rather useless results.
For example, if the operation mode were CHANNEL-OP-REPLACE and this was passed to 'gimp-fuzzy-select-full' then despite making fuzzy selections all along the path, the only thing that would matter would be the fuzzy select performed on the path's last point.
Also consider what happens if the 'operation' mode were CHANNEL-OP-INTERSECT and the original selection was the entire image (if there were no selection originally then the final result would be no selection). If I merely passed the INTERSECT mode to Fuzzy Select then after the first x,y point on the path was "fuzzy selected", the resulting intersection would be only that fuzzy selection. Moving to the next x,y point and the resulting selection would only be the intersection of the two Fuzzy Selects. At any point along the path -- including the last point on the path -- the resulting selection will be no larger than the intersection of that point's fuzzy selection and the one before it.
I read all this, and STILL have the same question...
Let me try to rephrase it... Consider two scenarios (with a particular OP of CHANNEL-OP-*), left one and right one:
save-selection + delete-selection do few FuzzySelects with OP do few FuzzySelects with OP combine with saved-selection with OP load saved-selection
Is there a case when these two scenarios are going to give different results? My logic is: there is no difference since
a) it is enough to consider the case of one FuzzySelect; b) for one FuzzySelect there is no difference.
On which step do you think my logic breaks?
The "projection" is the composited result of all of the layers, employing all settings for the specified blend modes, opacities, masks, and visibilities -- it is what you see in the image window. There is no direct access to the projection contents from the PDB and since 'gimp-drawable-get-pixel' does not provide a "sample merged" mode
Well, since an INDIRECT access to the projection contents IS POSSIBLE, why not allow a direct one?!
I basically gave up on my attempt to create a By Color Select version because of all of the edge cases that needed to be handled: layer offsets and dimensions (path coordinates are relative to the image, 'get-pixel' uses the drawable coordinates), changing colorspaces (mask and channels are grayscale, while a layer may or may not be), and image/drawable boundaries (paths are not constrained to the image).
Could you still provide your version (non-working OK), since I *need* to implement this anyway, and having some starting place would be a great help.
I'm going to create a temporary small layer for each point on the path (reuse it if the next point still fits). (I already have code which does projection-copying.)
If you wanted just a simple version which handled only a single layer (not its mask, nor a channel) which had the same dimensions as the image (and no offsets), and did not need to provide a "sample merged" option, I could write one sometime later this evening.
If you would: first, let me try to write my own version based on your old attempt. And if I fail, I might try to use your offer as a rain ticket. ;-)
A lot of thanks again, Ilya
P.S. Unrelated:
I'm trying to post to the devel list, both from GMANE, and directly. Nothing passes through. Do I need to subscribe first before posting is possible?
HOWTO: stroke a path with the current tool?
Quoting Ilya Zakharevich :
Let me try to rephrase it... Consider two scenarios (with a particular OP of CHANNEL-OP-*), left one and right one:
save-selection + delete-selection do few FuzzySelects with OP do few FuzzySelects with OP combine with saved-selection with OP load saved-selection
Is there a case when these two scenarios are going to give different results?
Your scenarios are identical, however, it is my opinion that more useful results are produced by treating all of the Fuzzy Selects as "one selection" and then combining that one selection with the original selection using the OP specified (which is distinct from your approach in the cases where the OP is "replace" or "intersect").
Well, since an INDIRECT access to the projection contents IS POSSIBLE, why not allow a direct one?!
Rendering of the projection is performed as a separate process asynchronous from operations that access/manipulate the image data. The projection may not even be rendered (if there is no display associated with the image). It would be necessary for the (hypothetical) procedure which accesses the projection to trigger a re-rendering (if a "valid" one is not available) and wait for that rendered projection to become valid. Once the projection becomes valid, it would need to be "locked" so that other GIMP processes do not modify it while the data is being retrieved -- if more than one access to the projection is to be executed then the projection would need to remain "locked" (effectively hanging GIMP while the script is executed).
It just makes much more sense to take a "snapshot" of the projection at a certain point and then access that "snapshot" thereby permitting other process -- including the projection rendering background process -- to do their thing. For this reason (though I've explained it poorly), I serious doubt you will ever see a 'gimp-projection-get-pixel' type function.
Could you still provide your version (non-working OK), since I *need* to implement this anyway, and having some starting place would be a great help.
I'm going to create a temporary small layer for each point on the path (reuse it if the next point still fits). (I already have code which does projection-copying.)
http://flashingtwelve.brickfilms.com/GIMP/Scripts/Alpha/sg-select-along-path.wrk
I'm not sure what shape it's in. I believe I had it working except for handling of layermasks and channels. It was at that point that I ran into problems with the drawable's mode (grayscale versus RGB...) and gave up. You also will probably want to use the fuzzy select function from my other script (the one included in this one is not the latest version).
I'm trying to post to the devel list, both from GMANE, and directly. Nothing passes through. Do I need to subscribe first before posting is possible?
Posts by unregistered people get moderated and can take a day or two before they appear. Subscribing to the list will eliminate this delay.
HOWTO: stroke a path with the current tool?
On 2009-10-01, saulgoode@flashingtwelve.brickfilms.com wrote:
Let me try to rephrase it... Consider two scenarios (with a particular OP of CHANNEL-OP-*), left one and right one:
save-selection + delete-selection do few FuzzySelects with OP do few FuzzySelects with OP combine with saved-selection with OP load saved-selection
Is there a case when these two scenarios are going to give different results?
Your scenarios are identical, however, it is my opinion that more useful results are produced by treating all of the Fuzzy Selects as "one selection" and then combining that one selection with the original selection using the OP specified (which is distinct from your approach in the cases where the OP is "replace" or "intersect").
Sorry for being so obtuse, but I STILL do not see in WHAT WAY are they "distinct" from the left scenario?
Rendering of the projection is performed as a separate process asynchronous from operations that access/manipulate the image data. The projection may not even be rendered (if there is no display associated with the image). It would be necessary for the (hypothetical) procedure which accesses the projection to trigger a re-rendering (if a "valid" one is not available) and wait for that rendered projection to become valid. Once the projection becomes valid, it would need to be "locked" so that other GIMP processes do not modify it while the data is being retrieved -- if more than one access to the projection is to be executed then the projection would need to remain "locked" (effectively hanging GIMP while the script is executed).
It just makes much more sense to take a "snapshot" of the projection at a certain point and then access that "snapshot" thereby permitting other process -- including the projection rendering background process -- to do their thing. For this reason (though I've explained it poorly), I serious doubt you will ever see a 'gimp-projection-get-pixel' type function.
Thanks a lot. I'm sure that if such implementation details were more documented, people would bother developers with much less questions... :-(
http://flashingtwelve.brickfilms.com/GIMP/Scripts/Alpha/sg-select-along-path.wrk
Thanks!
Ilya
HOWTO: stroke a path with the current tool?
[Looks like every time I post, I kill the list. My apologies; reposting]
On 2009-10-01, saulgoode@flashingtwelve.brickfilms.com wrote:
Let me try to rephrase it... Consider two scenarios (with a particular OP of CHANNEL-OP-*), left one and right one:
save-selection + delete-selection do few FuzzySelects with OP do few FuzzySelects with OP combine with saved-selection with OP load saved-selection
Is there a case when these two scenarios are going to give different results?
Your scenarios are identical, however, it is my opinion that more useful results are produced by treating all of the Fuzzy Selects as "one selection" and then combining that one selection with the original selection using the OP specified (which is distinct from your approach in the cases where the OP is "replace" or "intersect").
Sorry for being so obtuse, but I STILL do not see in WHAT WAY are they "distinct" from the left scenario?
Rendering of the projection is performed as a separate process asynchronous from operations that access/manipulate the image data. The projection may not even be rendered (if there is no display associated with the image). It would be necessary for the (hypothetical) procedure which accesses the projection to trigger a re-rendering (if a "valid" one is not available) and wait for that rendered projection to become valid. Once the projection becomes valid, it would need to be "locked" so that other GIMP processes do not modify it while the data is being retrieved -- if more than one access to the projection is to be executed then the projection would need to remain "locked" (effectively hanging GIMP while the script is executed).
It just makes much more sense to take a "snapshot" of the projection at a certain point and then access that "snapshot" thereby permitting other process -- including the projection rendering background process -- to do their thing. For this reason (though I've explained it poorly), I serious doubt you will ever see a 'gimp-projection-get-pixel' type function.
Thanks a lot. I'm sure that if such implementation details were more documented, people would bother developers with much less questions... :-(
http://flashingtwelve.brickfilms.com/GIMP/Scripts/Alpha/sg-select-along-path.wrk
Thanks!
Ilya