RSS/Atom feed Twitter
Site is read-only, email is disabled

pdb.gimp_by_color_select malfunction .. workaround

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.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

pdb.gimp_by_color_select malfunction .. workaround Stephen Moss 30 Aug 03:24
  pdb.gimp_by_color_select malfunction .. workaround David Gowers 30 Aug 04:59
   pdb.gimp_by_color_select malfunction .. workaround Stephen Moss 30 Aug 22:48
    pdb.gimp_by_color_select malfunction .. workaround saulgoode@flashingtwelve.brickfilms.com 31 Aug 02:10
Stephen Moss
2007-08-30 03:24:31 UTC (over 17 years ago)

pdb.gimp_by_color_select malfunction .. workaround

Fellow python users,

After some more work on the problem....

I discovered that:

- small files opened in the GUI are "select" -> "none" but

- larger files are opened "select" -> "all" !!!!

Workaround:

Put a "pdb.gimp_selection_none(image)"
before the
"pdb.gimp_by_color_select_full(drawable,...."

Stephen

David Gowers
2007-08-30 04:59:57 UTC (over 17 years ago)

pdb.gimp_by_color_select malfunction .. workaround

On 8/30/07, Stephen Moss wrote:

Fellow python users,

After some more work on the problem....

I discovered that:

- small files opened in the GUI are "select" -> "none" but

- larger files are opened "select" -> "all" !!!!

I find this extremely difficult to believe. I think it's more likely something about the image that causes gimp_by_color_select to behave in a way you don't expect. For example, if your huge image is indexed, that might cause this effect you mention; the threshold selection options (eg, in 'magic wand' and 'select by color' tools) do work in indexed mode, but the result often isn't meaningful (since the threshold is applied to the colormap indices of the pixels, rather than the actual colors they point to.)

Does toggling 'sample merged' effect the result? I have done my tests with:

Antialiasing ON (does nothing anyway, AFAIK) Feather OFF
Select transparent areas ON
Sample Merged OFF
Select by: COMPOSITE (if you had been using the wrong value here, it could have tripped you up too.)

On a 8000x6000 PNG image (on an AMD Duron, Ubuntu 6.06, GIMP [latest from SVN] ), I have tried to reproduce your problem with both an indexed and a grey image, and neither display the behaviour you mention. The select menu always shows 'None' as disabled and 'All' as normal after the image is opened, indicating that the selection is currently empty (None). In fact, the menus do not indicate whether all pixels are selected -- you can see that the 'All' menu entry is never disabled, so even when the selection already covers everything, you can still Select->All.

If you want to check the state of the selection, there is a 'Selection Editor' dockable you can access which provides a clear display of the current selection mask.

Lastly, it's possible that the file plugin for whatever format your image is in is interpreting some data wrongly and so mistakenly resetting the selection mask to this confusing state. What format is your input file(s)?

Stephen Moss
2007-08-30 22:48:53 UTC (over 17 years ago)

pdb.gimp_by_color_select malfunction .. workaround

Thanks David,

I have to eat crow on this one... I plead fatigue ;-)

Choosing the correct option does help a whole bunch: CHANNEL-OP-REPLACE (2)
already set from some previous operations. Another script to debug.

Thanks Stephen

saulgoode@flashingtwelve.brickfilms.com
2007-08-31 02:10:37 UTC (over 17 years ago)

pdb.gimp_by_color_select malfunction .. workaround

Quoting Stephen Moss :

Thanks David,

I have to eat crow on this one... I plead fatigue ;-)

Choosing the correct option does help a whole bunch: CHANNEL-OP-REPLACE (2)
already set from some previous operations. Another script to debug.

Perhaps your difficulty stems from a problem with the 'gimp_channel_combine_masks' PDB function. If executed with replace for the op then the result is actually the sum of the two channels. In Script-fu:

(gimp-channel-combine-masks dest-channel source-channel CHANNEL-OP-REPLACE 0 0)

has the same result as with CHANNEL-OP-ADD. Personally, I would expect the dest-channel to be replaced with the source channel, but perhaps I am missing something. Regardless, it is an easy work-around.