Re: [Gimp-developer] Solaris 64bit compile
Sven Neumann [EMAIL PROTECTED] wrote:
The code is combining the multiplications done on 2 channels of the
same pixel into one. Also it is also meant as an example of what can
be done without using CPU-specific instructions.
here's another example (4 x 8bit saturated addition):
uint32 padd_sat_4x8(uint32 a, uint32 b)
{
uint32 ta, tb, tm, q, u, m;
/* save overflow-causing bits in ta, tb */
ta = a 0x80808080;
tb = b 0x80808080;
q = a + b - (ta + tb);
/* determine overflow conditions */
tm = ta | tb;
u = (ta tb) | (q tm);
/* u now contains overflow bits, propagate them over fields */
m = (u 1) - (u 7);
return (q + tm - u) | m;
}
This is completely portable, and should be a good deal faster than
conditionally adding each component separately, at least on modern
superscalar machines with expensive unpredicted branches. And benchmarks
confirm this
Extending the above to 8 x 8bit (using 64-bit integers) is trivial of course
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] suggestion for color to alpha
Hi, Daniel Egger [EMAIL PROTECTED] writes: Am 06 Sep 2001 12:56:46 +0200 schrieb Sven Neumann: I think Branko is right here. Color-To-Alpha is not suited for chroma-keying since it will remove all shades of blue from all colors in the image. Classic blue-boxing requires to clear only exactly the color defined as the blue-box background. This can easily be achieved using Select-By-Color with a small threshold followed by Clear. I believe a good chroma keying algorithm would have to work a bit differently because in real life one has the problem that the blue of bluebox might vary slightly because of lighting conditions. So maybe the best would be to go over the HSV colorspace to allow a choosable variance in the keycolor? Select_By_Color takes care of that but operates only in the RGB domain. It might be a good idea to add an option that allows to apply the threshold to the HSV colorspace. If someone wants to hack this simple function, please port by_color_select to libgimpcolor and add generic color_distance functions to libgimpcolor. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Solaris 64bit compile
Am 06 Sep 2001 10:19:28 +0200 schrieb =?ISO-8859-1?Q?Mattias
Engdeg=E5rd?=:
This is completely portable, and should be a good deal faster than
conditionally adding each component separately, at least on modern
superscalar machines with expensive unpredicted branches. And benchmarks
confirm this
I like it. I did some benchmarking with a few routines with different
compilers on ppc and i686 and here are the results:
egger@sonja:~/test time ./testmat
Time needed for padd_sat_4x8 in clocks: 555
Time needed for padd_sat_4x8_and in clocks: 664
Time needed for padd_sat_4x8_norm in clocks: 709
real0m21.046s
user0m18.680s
sys 0m0.650s
Options to compile:
/opt/experimental/bin/gcc -O3 -fssa -save-temps test.c -o testmat
egger@sonja:~/test time ./testmat
Time needed for padd_sat_4x8 in clocks: 555
Time needed for padd_sat_4x8_and in clocks: 584
Time needed for padd_sat_4x8_norm in clocks: 784
Time needed for padd_sat_4x8_vec in clocks: 178
real0m21.477s
user0m20.520s
sys 0m0.530s
Same machine but gcc-2.95.3 with Altivec support.
Options to compile:
/opt/gcc-altivec/bin/gcc -O3 -mcpu=7400 -fvec -save-temps test.c -o
testmat
egger@alex:~ time ./testmat
Time needed for padd_sat_4x8 in clocks: 883
Time needed for padd_sat_4x8_and in clocks: 1073
Time needed for padd_sat_4x8_norm in clocks: 1101
real0m30.614s
user0m30.370s
sys 0m0.210s
This machine is a Duron-800 with 1GB RAM. I've no idea why it performs
so poorly compared to the G4.
The compile was gcc 2.95.3 with -march=i686 and -mcpu=i686 however the
compiler didn't use the conditional move instructions from the higher
Pentium CPUs which should have sped up the _norm case considerable as it
is possible to do the same without branches.
The source is attached, feel free to study it and provide faster code.
At the moment it is pretty clear that Mattias code is pretty efficent
and compiler equally well with several compilers on several
architectures.
Servus,
Daniel
#include glib-1.2/glib.h
#include time.h
static guint32 dest[2000] __attribute__ ((aligned (16)));
static guint32 source1[2000] __attribute__ ((aligned (16)));
static guint32 source2[2000] __attribute__ ((aligned (16)));
inline void
padd_sat_4x8(guint32 *dest, guint32 *pa, guint32 *pb)
{
guint32 a = *pa, b = *pb;
guint32 ta, tb, tm, q, u, m;
/* save overflow-causing bits in ta, tb */
ta = a 0x80808080;
tb = b 0x80808080;
q = a + b - (ta + tb);
/* determine overflow conditions */
tm = ta | tb;
u = (ta tb) | (q tm);
/* u now contains overflow bits, propagate them over fields */
m = (u 1) - (u 7);
*dest = ((q + tm - u) | m);
}
inline void
padd_sat_4x8_norm (guint32 *dest, guint32 *pa, guint32 *pb)
{
guint8 *newdest = (guint8 *) dest;
guint16 dr, dg, db, da;
guint8 r1 = *((guint8 *) (pa) + 0);
guint8 g1 = *((guint8 *) (pa) + 1);
guint8 b1 = *((guint8 *) (pa) + 2);
guint8 a1 = *((guint8 *) (pa) + 3);
guint8 r2 = *((guint8 *) (pb) + 0);
guint8 g2 = *((guint8 *) (pb) + 1);
guint8 b2 = *((guint8 *) (pb) + 2);
guint8 a2 = *((guint8 *) (pb) + 3);
dr = r1 + r2;
dg = g1 + g2;
db = b1 + b2;
da = a1 + a2;
newdest[0] = dr 255 ? 255 : dr;
newdest[1] = dg 255 ? 255 : dg;
newdest[2] = db 255 ? 255 : db;
newdest[3] = da 255 ? 255 : da;
}
inline void
padd_sat_4x8_and (guint32 *dest, guint32 *pa, guint32 *pb)
{
guint32 s1 = *pa, s2 = *pb;
guint16 dr, dg, db, da;
guint8 *newdest = (guint8 *) dest;
guint8 scratch;
dr = (s1 24 ) 0xff + (s2 24) 0xff;
dg = (s1 16) 0xff + (s2 16) 0xff;
db = (s1 8) 0xff + (s2 8) 0xff;
da = s1 0xff + s2 0xff;
newdest[0] = (guint8) (~((dr 8) - 1)) | dr;
newdest[1] = (guint8) (~((dg 8) - 1)) | dg;
newdest[2] = (guint8) (~((db 8) - 1)) | db;
newdest[3] = (guint8) (~((da 8) - 1)) | da;
}
#ifdef __VEC__
inline void
padd_sat_4x8_vec (guint32 *dest, guint32 *pa, guint32 *pb)
{
vector unsigned char vdest, source1, source2;
source1 = vec_ld (0, (unsigned char *) pa);
source2 = vec_ld (0, (unsigned char *) pb);
vdest = vec_adds (source1, source2);
vec_st (vdest, 0, (unsigned char *) dest);
}
#endif
int
main (void)
{
int i, current, iter;
current = clock ();
for (iter = 0; iter 10; iter++)
{
for (i = 0; i 2000; i++)
{
padd_sat_4x8 (dest + i, source1 + i, source2 + i);
}
}
current = clock () - current;
printf(Time needed for padd_sat_4x8 in clocks: %i\n, current);
current = clock ();
for (iter = 0; iter 10; iter++)
{
for (i = 0; i 2000; i++)
{
padd_sat_4x8_and (dest + i, source1 + i, source2 + i);
}
}
current = clock () - current;
printf(Time needed for padd_sat_4x8_and in clocks: %i\n, current);
current = clock ();
for (iter = 0; iter 10; iter++)
{
for (i = 0; i 2000; i++)
{
padd_sat_4x8_norm (dest + i, source1 + i, source2 +
[Gimp-developer] Re: [Gimp-print-devel] Gimp-Print 4.2 hit list
Robert L Krawitz wrote: ... 4) Complete the I18n on the CUPS (Mike, Roger?). I'm working this right now; the only changes I've made to Roger's stuff so far is to translate the words English and ISOLatin1 instead of LanguageLevel and LanguageVersion, since that will work best when gettext is disabled. ... 6) Test and tune some of the large format (Stylus Pro series) Epson printers. This one's a bit borderline, since there probably Right now I can test the 5500 and 7500 driver. My 9000 is busted, and we haven't ordered out 1 yet (will be soon, tho!) ... 7) Determine that the Stylus Color, Stylus Color 1520, and other very old printers do the right thing with the default resolution in both color and black white. Mike, can you test this? This would represent a regression if it's broken. I will *try* to do this, however there is a lot of other (paying :) stuff I have to work before this... Testing is a big time vacuum. ... 1) Tune the Stylus Photo 2000P. Nothing at all has happened here since 4.0. We haven't received any complaints about it, and I don't think that this printer sells all that well. This one's not a stopper by any stretch of the imagination since it's simply a matter of tuning the inkset. If it turns out to be more involved (which I think is unlikely) we can decide what to do then. I haven't done anything on this since I added support for the printer before; what we do here directly applies to the 5500 and 1, since they share the same (2-level) support and inks. -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 3D painting.
Hi! I asked this question about a year ago - and the answer then was Not Yet...so I'm back again! I'm working with the PrettyPoly team on building a GPL'ed 3D modeller for Linux (and others OS's) - and one thing we are frequently asked is to implement a facility to paint onto texture maps as they are applied to a 3D model. Since we are basically lazy people and *know* how much work it is to write a halfway decent paint program, we'd like to avoid that and build a 'bridge' between GIMP and PrettyPoly so GIMP gets to do all the hard work. I use GIMP a lot bit I have very little knowledge of it's internals - and I've never even written a plugin - so please forgive my ignorance. What I want to do is to write some kind of a plugin for GIMP that interfaces to a PrettyPoly plugin via a shared memory buffer. The idea would be to have the GIMP plugin write the current image into a shared memory area that PrettyPoly reads and downloads into the texture memory of our 3D graphics card...then as the mouse is moved around the 3D image in PrettyPoly, to convert that 3D position into a coordinate relative to the texture map and send that back to the GIMP plugin (also via shared memory). The plugin would then either apply paint at that location - or (preferably) simply convey the image coordinate to GIMP and let it do the painting using whatever tool is currently selected. Hence, as you drag the mouse over the 3D model, you'd cause GIMP to apply paint at the appropriate location in the 2D image - which would then appear a little later on the 3D viewer. You'd also be able to do the simpler thing of painting conventionally onto the GIMP image window and seeing the 3D effect immediately in the PrettyPoly window. Better still would be if ALL mouse input from the 3D tool were to appear to GIMP as non-GUI-directed mouse input - so we could even rubberband selection areas and such in 3D. The latency through that process is of course a concern - but the benefits of 3D painting to our users is large and we can perhaps work to at least minimise the delay. I know GIMP uses small image 'tiles' - so probably only the changed tiles need to be passed from GIMP to PrettyPoly. It seems to me that *if* this is possible, it shouldn't actually be too hard to implement. What I don't know is: * In what form can a plugin access the GIMP image? (eg Are layers pre-composited?) * Can we really drive the mouse coordinate within the GIMP core from inside a plugin? * If not, how hard would it be to make a plugin do basic airbrush/clone/pencil/brush functionality from coordinates stored in shared memory? What is your expert take on this? Is it possible? Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-print-devel] Gimp-Print 4.2 hit list
Robert L Krawitz wrote: ... Hmm. I thought the 1 was 3-level and the 5500 was 1-level??? Maybe not. Nope, I have the 5500 and it is definitely only 2-level (although some of the early docs indicated 3 levels, testing proved it was still only 2 levels (the third level produces no dot, which makes for interesting output...) I'm pretty sure the 1 is also 2-level, but I'll know for sure in another month or so. -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] suggestion for color to alpha
Sven Neumann [EMAIL PROTECTED] writes: Hi, Branko Collin [EMAIL PROTECTED] writes: Does image/Select/By Color what you want? I think Branko is right here. Color-To-Alpha is not suited for chroma-keying since it will remove all shades of blue from all colors in the image. Classic blue-boxing requires to clear only exactly the color defined as the blue-box background. This can easily be achieved using Select-By-Color with a small threshold followed by Clear. That works fine for opaque objects, but not for translucent ones. For example, when you have someone with long hair you can see some of the blue background through the hair, so the colour in those pixels is a mixture of the hair colour and and the blue background. Even with opaque objects you still have pixels along the edge of the object where you get blue mixed in. Using Select-by-Colour to remove the blue leaves a blue fringe around the object. Select-by-Colour, Grow, Feather, Clear works better, but you still have blue around the object that should not be there. Tim ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
