After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748270 - ripply-anim.scm does not handle transparent backgrounds
ripply-anim.scm does not handle transparent backgrounds
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Script-Fu
2.8.14
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2015-04-22 02:00 UTC by Jonathan Tait
Modified: 2018-01-01 12:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Modified version of ripply-anim.scm (5.22 KB, text/plain)
2015-04-22 02:00 UTC, Jonathan Tait
  Details
Patch for ripply-anim.scm (2.02 KB, patch)
2015-04-22 09:52 UTC, Jonathan Tait
none Details | Review
Re-write of the script (3.58 KB, text/plain)
2015-04-22 12:04 UTC, saulgoode
  Details

Description Jonathan Tait 2015-04-22 02:00:28 UTC
Created attachment 302117 [details]
Modified version of ripply-anim.scm

Steps to reproduce:
- open/create a layer with a transparent background
- Filters>Animation>Rippling...

Result:
all frames in output image have a medium-grey opaque background

Cause:
The frame layers are created by calling (gimp-layer-new ) with a hard-coded layer-mode of "RGB" (which is the wrong sort of identifier anyway!)

Really, the script should set the output image/layers to the same image/layer modes as the input image and drawable, rather than hard-coding values.

This can be easily achieved by changing the line:
 (let* ((out-imagestack (car (gimp-image-new width height RGB))))
to:
 (let* ((out-imagestack (car (gimp-image-new width height (car (gimp-image-base-type img))))))

and changing the line: 
 (set! this-layer (car (gimp-layer-new out-imagestack
                             width height RGB
                             layer-name 100 NORMAL-MODE)))
to:
 (set! this-layer (car (gimp-layer-new out-imagestack
                             width height (car (gimp-drawable-type drawable))
                             layer-name 100 NORMAL-MODE)))

Also, the script allows 3 types of "Edge behavior" (which are in fact provided by the displace plugin); the last of those options is currently labelled "Black" but with an RGBA layer, the in-fill is (happily) transparent; so with the above mods, this option may be more properly labelled "Black/transparent".

Modified script is attached for your perusal/usage as you wish.

I have tested these mods in all 4 color modes allowed (ie GRAY* and RGB*) and it seems to work okay.

BTW this script does not allow INDEXED mode images, probably because the displace plugin itself does not do so and seems to generate solid black output if you do try to run it on an INDEXED image (non-interactively). I cannot see any obvious reason why the displace plugin should not operate upon INDEXED images - if it works okay on a grayscale image with/without alpha then why not INDEXED too? If the plugin is ever amended to handle INDEXED, then this script can also be amended to allow INDEXED*.
Comment 1 Michael Schumacher 2015-04-22 08:02:58 UTC
Hi,

thanks for the modification. 
Would be nice if you could attach the changes in diff -u format.
Comment 2 Jonathan Tait 2015-04-22 09:52:55 UTC
Created attachment 302135 [details] [review]
Patch for ripply-anim.scm
Comment 3 saulgoode 2015-04-22 12:04:38 UTC
Created attachment 302144 [details]
Re-write of the script

Though it may not be considered that critical, it should be noted that the current version of the script will work with masks or channels that are part of an RGB image, and that this patch as it stands would throw an error in such scenarios (because the script would attempt to add a grayscale layer to an RGB image). 

One possible solution would be to use "(quotient (car (gimp-drawable-type drawable)) 2)" to determine the image type for the output image.


Also, while not part of this bug report, there are a few additional problems with this script. I'm not keen on generating a half-dozen reports for a single script, so I will just briefly mention them here.

* There is no license text in the .scm file. Perhaps this acceptable but convention is to include the licensing info.

* The script trashes the global edit buffer. At a minimum, the script should use temporary, named buffers.

* The script clears the selection in the original image. 

Finally, not to disparage the original author -- the script was written 18 years ago when GIMP's scripting suppport was not as capable as it is now -- the coding of the script is somewhat convoluted, creating an extra, unnecessary image, multiple superfluous layers, and generally being hard to read (at least for me it is).

With this in mind, I have attached a re-write of the script that functions as the original except that it doesn't trash the edit buffer or original selection mask, it addresses this bug, and it is easier to understand/maintain. I did not include a licensing declaration as I am not certain what that should be.

I also did not use diff -u because the only two lines of code that were not modified are the ones containing gimp-context-* operations (not counting comments and the PDB registration stuff).
Comment 4 Michael Natterer 2015-04-27 02:23:57 UTC
Pushed Saul's rewrite to master:

commit cc042b35d2844675152cda3512283c2d22dff199
Author: Saul Goode <saul@crazyauntgail.com>
Date:   Sun Apr 26 22:19:38 2015 -0400

    Bug 748270 - ripply-anim.scm does not handle transparent backgrounds
    
    Replace the script by a modernized re-write, which also handles layers
    with alpha.

 plug-ins/script-fu/scripts/ripply-anim.scm | 168 ++++++++++-------------------
 1 file changed, 58 insertions(+), 110 deletions(-)
Comment 5 arnost.pacicka 2018-01-01 09:38:38 UTC
I have the exact same problem as OP on 2.8.22 Windows, so I am not sure why is this marked as fixed. Ripple effect on RGB image with alpha channel results in frames with gray background. I came from http://gimpchat.com/viewtopic.php?f=8&t=12353, tried the script there and it works. If you are not going to fix this, maybe you should give that script as alternative, since producing gray background frames from transparent background original is really not expected.
Comment 6 Michael Natterer 2018-01-01 12:52:34 UTC
It is fixed in 2.9, which will become the next stable 2.10.