03-04-2019, 09:32 PM
(This post was last modified: 03-04-2019, 10:18 PM by Jack Parker.)
I am trying to add a "border" to my images, to bring then to a common, standard size.
(the "border" being a solid COLOR)
The images are RGBA in PNG;
With some image pixels and thin surround of transparent pixels
(the result of cleaning away various scanner artifacts)
The good bits of these base images have irregular perimeter, so:
Plan-A: resize image to new size; insert-layer below, select-all, edit-fill-selection with FG/COLOR in the new/background layer
(all that works)
And then merge-down the top/original layer to the background.
And the resulting layer is all TRANSPARENT!?
Note: If I step through the undo stack, and get to the point where the merge happens,
and do it "manually" with the menu: Layer -> Merge Down it works as expected.
Note: I have tried several variants, with gimp-layer-new and gimp-copy-layer,
and have logged/verified the gimp-layer-get-mode of all concerned.
Note: I also tried with merge-visible-layers
read all the docs on layers and merge, saw the sample code
In all cases, the "merge" removes the layers, and produces a blank/transparent layer.
Plan-B: keep it simple, just the single, original layer, resize and fill:
select the contents of the [original/only] layer, fuzzy-select the picture, flood, sharpen (all good)
Then resize the image, resize-layer-to-image; selection-invert; edit-fill-selection with FG/COLOR
(gimp-context-set-foreground fill-color)
(gimp-drawable-edit-fill drawa FILL-FOREGROUND)
Because *that* should just-work nothing interesting or new, right?
Note: I have a shared routine for this, to save context/undo, it works as expected in other cases;
but using the procedure, or the simple/direct code as show, the effect is the same
but for this use-case it does the unimaginable:
To my shock and dismay, edit-fill-selection
(with Selection being the NEW/Transparent bits, outside the original pixels)
(and with FG = COLOR)
Sets the non-selected pixels to TRANSPARENT!
(unless I step in with the Undo; and "manually" Fill-Selection with FG; *then* it works as expected)
So now I appeal to greater wisdom.
Is this a known failure mode?
Some limit to scripting?
How can this be scripted?
(I'll even do python... )
Reduced to a simpler script, I can make the basic methods work.
So the question is: are there known things to look for that would cause fill selection and/or merge-down to go TRANSPARENT?
(the "border" being a solid COLOR)
The images are RGBA in PNG;
With some image pixels and thin surround of transparent pixels
(the result of cleaning away various scanner artifacts)
The good bits of these base images have irregular perimeter, so:
Plan-A: resize image to new size; insert-layer below, select-all, edit-fill-selection with FG/COLOR in the new/background layer
(all that works)
And then merge-down the top/original layer to the background.
And the resulting layer is all TRANSPARENT!?
Note: If I step through the undo stack, and get to the point where the merge happens,
and do it "manually" with the menu: Layer -> Merge Down it works as expected.
Note: I have tried several variants, with gimp-layer-new and gimp-copy-layer,
and have logged/verified the gimp-layer-get-mode of all concerned.
Note: I also tried with merge-visible-layers
read all the docs on layers and merge, saw the sample code
In all cases, the "merge" removes the layers, and produces a blank/transparent layer.
Plan-B: keep it simple, just the single, original layer, resize and fill:
select the contents of the [original/only] layer, fuzzy-select the picture, flood, sharpen (all good)
Then resize the image, resize-layer-to-image; selection-invert; edit-fill-selection with FG/COLOR
(gimp-context-set-foreground fill-color)
(gimp-drawable-edit-fill drawa FILL-FOREGROUND)
Because *that* should just-work nothing interesting or new, right?
Note: I have a shared routine for this, to save context/undo, it works as expected in other cases;
but using the procedure, or the simple/direct code as show, the effect is the same
but for this use-case it does the unimaginable:
To my shock and dismay, edit-fill-selection
(with Selection being the NEW/Transparent bits, outside the original pixels)
(and with FG = COLOR)
Sets the non-selected pixels to TRANSPARENT!
(unless I step in with the Undo; and "manually" Fill-Selection with FG; *then* it works as expected)
So now I appeal to greater wisdom.
Is this a known failure mode?
Some limit to scripting?
How can this be scripted?
(I'll even do python... )
Reduced to a simpler script, I can make the basic methods work.
So the question is: are there known things to look for that would cause fill selection and/or merge-down to go TRANSPARENT?
