HOWTO: stroke a path with the current tool?

[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?

(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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Chris Mohler]

On Fri, Sep 11, 2009 at 3:39 AM, Ilya Zakharevich
<nospam-abuse@...> 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=("<Vectors>"),
    domain=("gimp20-python", gimp.locale_directory)
    )

main()
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Jason van Gumster]

Ilya Zakharevich <nospam-abuse@...> 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
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Sven Neumann]

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


_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Jason van Gumster]

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 <jason@...> wrote:

>
> Ilya Zakharevich <nospam-abuse@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

On 2009-09-13, Sven Neumann <sven@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Batangisip]

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.

--
jolie (via www.gimpusers.com)
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Sven Neumann]

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


_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

On 2009-09-14, Jolie S <forums@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Batangisip]

>
>???  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

--
jolie S (via www.gimpusers.com)
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

On 2009-09-15, jolie S <forums@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[saulgoode]

Quoting Ilya Zakharevich <nospam-abuse@...>:

> 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.



_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Alec Burgess]

saulgoode@... 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.



_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Jason van Gumster]

Alec Burgess <buralex@...> 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
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

             [Repost after a list resurrection]

On 2009-09-15, saulgoode@... <saulgoode@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

     [Repost after a list resurrection]

On 2009-09-19, Jason van Gumster <jason@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[saulgoode]

Quoting Ilya Zakharevich <nospam-abuse@...>:

> 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.

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

On 2009-09-30, saulgoode@... <saulgoode@...> 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?

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[saulgoode]

Quoting Ilya Zakharevich <nospam-abuse@...>:

> 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.

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Ilya Zakharevich]

On 2009-10-01, saulgoode@... <saulgoode@...> 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

_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user