GNOME Bugzilla – Bug 9156
bug in ifscompose
Last modified: 2009-08-15 18:40:50 UTC
Package: gimp 500x500 transparent image first element: X 0.29, Y 0.35, Scale 0.50, Angle 0, Asym 0, Shear 0 second element: X 0.68, Y 0.35, Scale 0.50, Angle 0, Asym 0, Shear 0 third element: X 0.54, Y 0.58, Scale 0.49, Angle -5.59, Asym 0.49, Shear 1.66 color transforms left alone relative probability 1.32 render options defaulted there are some odd blocks of white on the last row of the generate image also, on rerunning ifs-compose, all of my elements have the same label (0) and the relative probability is set back to 1.00 Kelly ------- Additional Comments From Austin.Donnelly@cl.cam.ac.uk 2000-11-27 05:40:01 ---- Subject: Re: Bug #9156: bug in ifscompose From: Austin Donnelly <Austin.Donnelly@cl.cam.ac.uk> To: 9156@bugs.gnome.org Cc: David Hodson <hodsond@ozemail.com.au> Message-Id: <14882.14849.548236.221358@hornet.cl.cam.ac.uk> Date: Mon, 27 Nov 2000 10:40:01 +0000 [ David Hodson <hodsond@ozemail.com.au> has done some digging on this bug, and come up with the following conclusions: ] On Monday, 27 Nov 2000, David Hodson wrote: > "there are some odd blocks of white on the last row of the generate > image" > > [David] Couldn't reproduce this. Ok, so this one is still outstanding. Kelly - do you still see this? > "on rerunning ifs-compose, all of my elements have the same label (0)" > > Fixed a bunch of labelling problems. Now much better. Ok, applied to CVS in checkin of 2000-11-27 Austin Donnelly <austin@gimp.org> > "and the relative probability is set back to 1.00" > > Probabilities saved and loaded OK. > Suspect this is operator error - it is not immediately obvious from > the gui that there is one probablity value for each component, so > if you adjust one value, when it reloads it may still be showing the > default value from a different component. Kelly - do you still see this? > Also allowed "run with same values". And put into CVS now. Although technically this is a feature, the code is simple enough and I would argue that it makes the "Repeat with last vals" menu item work more consistently. Austin ------- Additional Comments From gosgood@idt.net 2000-11-29 21:47:33 ---- Subject: Re: bugs in ifscompose From: "Garry R. Osgood" <gosgood@idt.net> To: 9156@bugs.gnome.org Message-Id: <3A25BFC3.F1E29B28@idt.net> Date: Wed, 29 Nov 2000 21:47:33 -0500 Hi, David, David Hodson wrote: > > (Although 2048 x 2048 will kill my poor little machine... 166MHz, 32 > MB.) > If you set "Iterations" to 1 (under render options) it makes for a rather faint iterated function system that can be computed very quickly, and, conveniently, the row of strangely rendered pixels are still in full force at the bottom of the image. A pleasant epiphany this afternoon, followed by a few confirmation experiments on the lap top, has led me to conclude that the strangely rendered pixels at the southern edge stem from the shadow tiles. At this juncture, I find myself leaning toward the notions that the IfsCompose plug-in is either (1) cropping, or (2) scaling incorrectly along the vertical axis. I think that (2) is the faster horse; that the effect is clearly manifest in large images, but not small, suggest to me that when IfsCompose is transforming from its computational space to the image, it is scaling the y dimension not quite sufficiently. As you (likely) know, the Gimp places intermediary results from plug-ins in the shadow tile set. When the plug-in completes, the Gimp composites the shadow tile set with the selection mask, and the currently active layer gets the resultant. That is not the only way the Gimp employs the shadow tile set. A family of seven interactive tools (Color Balance, Hue-Saturation, Brightness-Contrast, Threshold, Levels, Curves, and Posterize), all orchestrated by app/image_map.c idle rendering code, also employ the shadow tiles to hold intermediary results. Whenever the user alters an image through these tools, they render first to the shadow tiles, then composite with the selection mask to the currently active layer. The intermediary image remains on the shadow tile set. When IfsCompose renders to the shadow tile set, it leaves the last few rows of pixels unaltered, so a small strip of whatever left-over image is on the shadow tile set gets transferred to the layer. To test this idea, try this simple experiment: 0. New (monstrous image) -- I think you can get away with 1024 X 1024. 1. <Image>->Filter->Render->Pattern->Checkerboard (Just to have an image recognizably patterned to work with: At factory settings, this will be a black-and-white checkerboard). 2. <Image>->Image->Colors->Curves. Select, say, the Green curve and invert the slope so that it runs northwest to southeast; the formerly black-and-white checkerboard becomes green-and-magenta (this also leaves the shadow tiles impressed with green-and-magenta checks). Select "OK". 3. Clear the image. (to absolve any layer or projection tile imagery). 4. <Image>->Filter->Render->Nature->IfsCompose. Set "Render Options:: Iterations to "1" so you can complete this little exercise sometime before Christmas. Select "OK" for a (very sparsely populated!) Sierpinski Gasket. Wait for the progress bar to stop progressing. 5. Inspect the southern edge. You should see, reemerging, the once cleared green-and-magenta checks. They were still inhabiting the shadow mask (I kindly suggest) and the somewhat squashed image from IfsCompose did not obliterate them. As the image grows larger, the mis-scaling appears to be non-linear. The image appears to be four pixels short at 1024 X 1024, 24 pixels short at 2048 X 2048, and 136 pixels at 4096 X 4096. So my first line of inquiry is to determine why IfsCompose rather flattens the image along the y axis. I'll CC all this to the bug report, and eventually one of us, if not somebody else, can have a go at it. Be good, be well Garry Osgood ------- Additional Comments From austin@gimp.org 2000-12-18 13:21:57 ---- Subject: Re: Bug#9156: bugs in ifscompose From: Austin Donnelly <austin@gimp.org> To: 9156-done@bugs.gnome.org Message-Id: <14910.21957.67691.471274@hornet.cl.cam.ac.uk> Date: Mon, 18 Dec 2000 18:21:57 +0000 Ok, thanks to a bunch of separate fixes from a number of people, I believe all parts of this bug have now been fixed in CVS. If anything is still broken with ifscompose, you'll need to report it as a fresh bug; I'm closing this bug report. Austin ------- Additional Comments From sven@gimp.org 2000-12-18 16:03:37 ---- Subject: [David Neary <dneary@informix.com>] Re: Submitting a fix From: Sven Neumann <sven@gimp.org> To: 9156-done@bugs.gnome.org Message-Id: <87snnl787q.fsf@gimp.org> Date: 18 Dec 2000 22:03:37 +0100 > ------------------------------------------------------------------------ > Index: ifscompose.c > =================================================================== > RCS file: /cvs/gnome/gimp/plug-ins/ifscompose/ifscompose.c,v > retrieving revision 1.36 > diff -u -r1.36 ifscompose.c > --- ifscompose.c 2000/11/27 10:35:23 1.36 > +++ ifscompose.c 2000/12/18 18:14:53 > @@ -1354,7 +1354,11 @@ > > num_bands = ceil((gdouble)(width*height*SQR(ifsvals.subdivide)*5) > / (1024 * ifsvals.max_memory)); > - band_height = height / num_bands; > + band_height = (height + num_bands - 1)/ num_bands) ; > + /* For bug #9156 - adding 1 guarantees that > + * band_height*num_bands >= height > (band_height-1)*num_bands > + * band_height automatically got rounded down, resulting in a diff > + * of a few pixels when num_bands didn't divide evenly */ > if (band_height > height) > band_height = height; > -- Dave Neary, Software engineer, Informix Dublin. Ireland. Phone: +353-1-409-1357 ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:50 ------- This bug was previously known as bug 9156 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=9156 Originally filed under the gimp product and general component. The original reporter (kelly@poverty.bloomington.in.us) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, egger@suse.de.