gimp 1.1.31-32 BUG
I have just downloaded 1.1.31 and 1.1.32 patches from ftp.gimp.org I notice that 'TODO' file has been updated to show some things that will happen with Gimp. However, I don't see any mention of "improved keyboard operation", i.e. the stuff that generated quite a bit of hate mail on this exact list a few weeks ago. I have to admit though, as soon as the discussion shifted into intelligent suggestions, everyone dropped out real quick. Still, I think being able to operate a program from keyboard is very important even if this program is a mouse-oriented graphics tool. Especially since it has been mentioned in the last few posts on this subject that this would affect things like shortcuts, and cause them to be reassigned using common sense, and not first-come-first-serve method that has been used up until now. I hope this bug gets fixed as soon as possible! :> tc -- $B!&!E!D(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!D!E!&(B timecop at japan.co.jp | $B#O#ADL?.%5%S!<%93t<02q
Re: divide by 255
On Wed, Dec 20, 2000 at 02:34:19AM -0600, Federico Mena Quintero wrote: > You have to make sure that the code that uses such techniques indeed > has 255*255 as an upper bound. A long time ago the GIMP was full of > inconsistencies where some parts assumed 256*256, others 255*255, yet > buggier ones 256*255. Eeek! We really need to buy some people a "CG for newbies" book, this mistake is why I got mixed up in the Mozilla compositor in the first place - it was producing incorrect results making stuff look awful. > In the border cases (alpha = 0, alpha = 255) this produces exact > results. In the intermediate ones, the maximum difference between > doing a "slow but accurate" division and all this bit twiddling is at > most 1. So it is just what you want. This would probably be OK for display, but it's not acceptable in the Gimp's internals where errors might propagate. > I think the bigger problem is auditing the GIMP to make sure that > there are no inconsistencies in the valid ranges for color values when > compositing stuff together. If there are parts written by people who didn't know this stuff very well then yes, I guess it would need auditing. As I said, this would be a target for 1.2.x x>0 or 1.3. > What code does Mozilla use? If it is different, could we run some > benchmarks for speed and accuracy? #define FAST_DIVIDE_BY_255(v) v) << 8) + (v) + 255) >> 16) Eerily similar to your hack and to the one from Marc. For me (PII 300, AMD Duron 700) and for the other hackers on that Moz bug who checked it _was_ faster than the GCC emitted alternate, but Marc's numbers suggest otherwise. The above hack was tested to work 0 ... 65025, I'm happy to run speed trials or repeat accuracy checks on Sun and Intel hardware in our lab if someone wants to suggest a reasonable "benchmark" code fragment. Nick.
Re: GIMP-1.1.31: Where is gone spheredesigner?
vidar took sphere designer out because he said it wasn't ready for release yet. he needs to redo some stuff and it is complicated so he said he'd pull it for now and put it in again later. and when it goes back in it will be with a kick-ass help file he is writing for it.
Re: GIMP-1.1.31: Where is gone spheredesigner?
Marco Lamberto <[EMAIL PROTECTED]> writes: > The Makefile in po-plug-ins requires the missing spheredesigner.c source in > plug-ins/common. Hi Marco, this is fixed in CVS. thanks, --Mitch
GIMP-1.1.31: Where is gone spheredesigner?
The Makefile in po-plug-ins requires the missing spheredesigner.c source in plug-ins/common. Happy GIMPing, Marco -- //\/\ Marco (LM) Lamberto e-mail:lm(.)sunnyspot.org (replace '(.)' -> '@') The Sunny Spot - http://the.sunnyspot.org/
Re: divide by 255
On Wed, Dec 20, 2000 at 02:34:19AM -0600, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > Anyways, in libart and gdk-pixbuf we have code like this to composite > an RGBA image over an RGB pixel: > > dest[0] = r2 + ((tmp + (tmp >> 8) + 0x80) >> 8); Warning! Here is a formula I just came up with (about the same as above, actually, but without rounding errors): x = ((n<<8) + n + 257)>>16; It works over the full range (n = 0..65535; x = 0..256) and is always exact. However, this optimization is not as important as you might think, as gcc already uses exactly this technique, however, gcc uses a multiplication since gcc's formula has to work over the full unsigned int range ;) For n/255, gcc does this on x86; movl %ebx,%eax mull .LC0 ; = 0x80808081 movl %ebx,%eax sall $8,%eax While my formula boils down to: shrl $7,%edx leal 257(%ebx,%eax),%eax shrl $16,%eax In practise, gcc's code is faster if enough registers are available (p-ii/iii), and usually not slower. It is also correct over the full range. So think twice before starting to "optimize" this division. (And always remember to use UNSIGNED variables where applicable, since these are much faster). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Getting off the list ...
Hi all, How on earth do we get off this list. I have used the "unsubscribe" method, but this just says it does not have my email registered (but of course, it does coz I keep getting messages ... including this one! And YES, I have checked the address details stamped by my mailer etc etc and the address to which gimpdev is mailing !!!) Garry O tried to 3rd party unsubscribe me ... this failed ... I tried to 3rd party unsubscribe me too ... this also failed ... So, please, anyone out there know how to unsubscribe? Of course, those that have sucessfully done this cannot answer for the obvious reason ... My mailbox canna cope ... Thanks, Rob.
Re: divide by 255
Nick Lamb <[EMAIL PROTECTED]> writes:
> General purpose compose operations usually include a division by 255 of
> a number in the range 0 ... 65025. While fixing up Mozilla's alpha
> compositor I disturbed a sleeping hacker who has provided a (tested and
> working) macro which computes this operation much more quickly than
> any other solution tested, including GCC -On speed-ups using similar
> but different tricks.
>
> Of course, GCC cannot use this FAST_DIVIDE_BY_255 because it is safe
> only for 0 ... 65025, but I think it might be useful to Gimp, both in
> the core (which I presume has several alpha compositors) and in
> plug-ins, where alpha composition is also a popular operation.
>
> So, does Gimp already have something like this in core? Or should we
> consider borrowing this macro from wherever it originated and using
> it throughout Gimp (after 1.2, naturally) ?
You have to make sure that the code that uses such techniques indeed
has 255*255 as an upper bound. A long time ago the GIMP was full of
inconsistencies where some parts assumed 256*256, others 255*255, yet
buggier ones 256*255.
Anyways, in libart and gdk-pixbuf we have code like this to composite
an RGBA image over an RGB pixel:
a0 = p[3];
if (a0 == 255) {
dest[0] = p[0];
dest[1] = p[1];
dest[2] = p[2];
} else {
int tmp;
tmp = ((int) p[0] - r2) * a0;
dest[0] = r2 + ((tmp + (tmp >> 8) + 0x80) >> 8);
tmp = ((int) p[1] - g2) * a0;
dest[1] = g2 + ((tmp + (tmp >> 8) + 0x80) >> 8);
tmp = ((int) p[2] - b2) * a0;
dest[2] = b2 + ((tmp + (tmp >> 8) + 0x80) >> 8);
}
Here, dest points to the position of the destination pixel in a guchar
array, and p points to the source pixel. r2/g2/b2 are the background
color (here it is from a checkerboard, but it could be the background
RGB pixel). a0 is p[3], which is the alpha value for the source
pixel.
In the border cases (alpha = 0, alpha = 255) this produces exact
results. In the intermediate ones, the maximum difference between
doing a "slow but accurate" division and all this bit twiddling is at
most 1. So it is just what you want.
For compositing RGBA over RGBA, you could pull similar tricks.
I think the bigger problem is auditing the GIMP to make sure that
there are no inconsistencies in the valid ranges for color values when
compositing stuff together.
What code does Mozilla use? If it is different, could we run some
benchmarks for speed and accuracy?
Federico
