GNOME Bugzilla – Bug 50911
Sparkle plugin within rectangular selection
Last modified: 2003-09-17 23:11:01 UTC
I noticed a bug in the Filter->Light Effects->Sparkle plugin when used within a rectangular selection. This bug exists in both versions 1.2 and 1.2.1 Steps to reproduce the bug : 1) Open a 100 x 100 RGB small new file with black background. (sparkle plugin is compute-intensive !) 2) Use a small paint brush to paint two small white spots in the center of the black image. 3) Filters->Light Effects->Sparkle, accept default values, (Preserve Luminosity unchecked, Inverse unchecked) Notice at this stage, Sparkle works correctly, choosing the two small high intensity white spots to make nice sparkle effect. 4) Now open a new layer and fill with black. 5) Use paint brush to paint two small white spots somewhere in the center of the image again. 6) Now use the rectangular marquee tool from the tool box to make a small rectangle selection which contain the two white spots inside. 7) Filters->Light Effects->Sparkle, default values again. Now notice the Sparkle effect, instead of creating sparks centered around the two white spots... it create sparks anywhere else within the rectangular selection. This is a bug. This bug could be related to Bug #15084 since the sparkle plugin is also used in the Frosty Text script-fu.
It looks like the size of the selection matters. At first, I tried to reproduce this bug with a 256x256 image, but nothing strange happened: I got the exact same results with or without the selection. But then I tried with a 100x100 image and when using the selection, the lower of the two dots was almost correctly surrounded by sparks while the other had no decoration at all. Instead, some bits of the sparkle effect appeared at a random location within the selection. The preview in the L&C&P dialog was apparently corrupted by random dots in vertical stripes (totally unrelated to the contents of the layer). I tried again with a 256x256 image, but this time with a rather small selection (approx. 40x40) around the two dots, and the same bug appeared. Note that starting from a 40x40 image without a selection reveals no problem, so a selection is required in order to see the bug. The selection can have any shape: rectangular, round, or free select. In all cases, some sparks or some randomly colored dots appeared in incorrect locations. This may be related to bug #15084 and bug #51010 (duplicate of the first one). Both of them are about the Frosty logo, which does not behave as in gimp-1.0.x because of some changes in the Sparkle plug-in. But the script frosty-logo.scm calls gimp-selection-none before calling plug-in-sparkle, so this is not the same effect as the one described here, although it could be a different consequence of the same bug.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Changed target milestone of several bugs to 2.0 - these are not features, and don't look to me like blockers for a pre-release, but they have to be addressed before 2.0. Dave.
Not sure its _the_ bug, but _a_ bug comes from overwriting stack memory fairly freely. Its amazing this works at all. See code fragment here: gint values[256]; ... for (pr = gimp_pixel_rgns_register (1, &src_rgn); pr != NULL; pr = gimp_pixel_rgns_process (pr)) { data = src_rgn.data; size = src_rgn.w * src_rgn.h; while (size--) { values [compute_luminosity (data, gray, has_alpha)]++; 'size' here can _easily_ be greater than 255, in which case we just overran our array bounds. Now I just need to figure out what this computation was trying to do in the first place to fix it... Seth
Doh, I'm an idiot. Not incrementing a counter, just incrementing a value in the array. Ignore previous rant. Seth
The plug-in made frequently ignored the fact that pixel regions may contain data other than that in the bounds of the rgn.w x rgn.h. You need to use the rgn.rowstride to handle this case (which shows up with selections). What was happening in ascii art: AAAAABBBBB AAAAABBBBB AAAAABBBBB Where B is the selection, and the A U B is the pixel region. If you just march through the data, you'll end up reading/writing stuff in the AAAAA section which is masked off; you'll end up with some mighty messed up stuff. On complete images, there is no difference between seletion and image so it just happened to work. So the solution use the rowstride (how big a row is) to increment back to the selection at the end of every row. I'm still a bit concerned about what happens for non-rectangular selections, but as far as I can tell this is pretty much universally ignored (I think another incident is open on that issue). I'm commiting the fix for this. Seth
Plug-ins don't need to care about the selection mask. It is handled transparently when the dirty tiles are merged. Plug-in can (and should) choose to work on the bounding box of the selection only but this is solely an optimization.
Fixed in CVS: 2003-09-17 Seth Burgess <sjburges@gimp.org> * plug-ins/common/sparkle.c: use the rowstride of a pixel region because you never know when you're starting on a selection. Fixes bug #50911.