Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Image goes transparent
#1
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?
Reply
#2
Well, let that be a lesson to new Gimpers:

A) There was a typo, so for a *later* selection, and *later* fill:
   (gimp-drawable-edit-fill layer TRANSPARENT)
   was (gimp-drawable-fill layer TRANSPARENT)
   Which explains the end result being TRANSPARENT.

B) The UNDO stack does not record all this correctly (IMHO)
    Backing up, and then stepping forward through the changes,
    The application of the FIRST drawable-edit-fill shows the result as TRANSPARENT
    Even though in actuality, that transparent fill comes way later...

    So: perhaps the code for gimp-drawable-fill is not protecting the UNDO records?

C) script-fu does not have single-step forward tools, which would have found this immediately..
    If python-fu has built-in stepping, that might sway me...
Reply
#3
To quote the doc on gimp-drawable-fill:

Quote:This procedure is unlike 'gimp-edit-fill' or the bucket fill tool because it fills regardless of a selection. Its main purpose is to fill a newly created drawable before adding it to the image. This operation cannot be undone.
For the rest, hard to tell without your source code... there is also the possibility that some tool option is set, or the color has an alpha component (Edit>Preferences>Tool options>Reset to default values`).
Python is easier to debug, because you can easily add print statements to get the value of variables...
Reply


Forum Jump: