So, I've been thinking about all of the apps I use on a daily basis,
and decided I should go out and send 'thank you's to the developers. :^)
So, thanks, everyone, for The Gimp! My wife and I use it at home, and
I use it at work. :^)
--
-bill!
[EMAIL PROTECTED] "I'm anticipating an al
hi all,
I am a newbie.
Q.1)
I am writing a plugin which requires comparing one row of pixels with the one following it. Here is what I could think of,
iterate over pixel regions (width = image width, height = tile height):
iterate over rows in current pixel region:
do com
On 27.02.2005, at 02:55, Manish Singh wrote:
Only to those containing sources which refer to automatically
generated headers, about 3 or 4.
No, we should add it to all of them.
Agreed. Consistency is good.
In fact, it already *is* in some of them.
So here's what I'm currently doing. I took the 4 l
On 27.02.2005, at 03:09, Manish Singh wrote:
But that's still not the cure for all possible problems that
may arise by moving the header (e.g. from app to libfoo).
Anyway, that's better than nothing...
There's no getting around updating the Makefile.am for that. With your
naive solution, it *adds*
Hi,
"balachandran c" <[EMAIL PROTECTED]> writes:
>Q.1)
>I am writing a plugin which requires comparing one row of pixels with
>the one following it. Here is what I could think of,
>iterate over pixel regions (width = image width, height = tile
>height):
> iterate over
On 27.02.2005, at 01:04, Sven Neumann wrote:
I have eliminated last_visited from the gradient struct. Instead the
caller of gimp_gradient_get_color_at() may now do the same
optimization without any caching in the gradient itself. I very much
doubt that this makes any difference though. Perhaps if y
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> Your change dramatically changed the picture.
That surprises me, but there is obviously a lot I have to learn about
threads. Thanks for testing my changes.
> However dithering on is still loosing quite a bit on this SMP
> machine
Dithering mak
On 27.02.2005, at 14:31, Sven Neumann wrote:
Dithering makes heavy use of GRand and as long as the random number
generator is shared between the threads... I wonder if it actually
makes sense to add the overhead of per-thread data initialization or
if we should rather replace the use of a random nu
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> Since the randomness doesn't play a big role here (like in a
> security environment) I wonder if it wouldn't be easiest to
> employ a per-thread pseudo-RNG seeded with a different
> "random" number. One global RNG would be nice for this...
GRand is
On 27.02.2005, at 15:19, Sven Neumann wrote:
It is called once per tile. Your approach probably makes sense as long
as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new()
initializes the random number generator from /dev/urandom which is
probably too expensive to be done once per tile.
On 27.02.2005, at 15:19, Sven Neumann wrote:
It is called once per tile. Your approach probably makes sense as long
as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new()
initializes the random number generator from /dev/urandom which is
probably too expensive to be done once per tile.
Hija,
this is my suggested patch for getting the speeds improvements
as mentioned in the other thread by having a thread-local PRNG
initialized with a seed from the still existing blend tool local
RNG.
It looks bigger than it is because I took the liberty to remove
the nasty special casing on the e
From: Daniel Egger <[EMAIL PROTECTED]>
Date: Sun, 27 Feb 2005 16:03:14 +0100
this is my suggested patch for getting the speeds improvements
as mentioned in the other thread by having a thread-local PRNG
initialized with a seed from the still existing blend tool local
RNG.
It
On 27.02.2005, at 16:42, Robert L Krawitz wrote:
In addition to being very slow, this will also yield noisy results.
There are a lot of dither algorithms that are both much faster and
yield better results. While you may not need full-blown
Floyd-Steinberg or EvenTone dithering for this purpose (an
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
>> It is called once per tile. Your approach probably makes sense as long
>> as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new()
>> initializes the random number generator from /dev/urandom which is
>> probably too expensive to be done
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
> There seems to be more room for obvious optimisations in the
> loops. Also I would recommend splitting the two cases into
> two separate functions to make the code easier to read, and
> remove more conditionals.
All done already. I also got a nice i
Hi,
Robert L Krawitz <[EMAIL PROTECTED]> writes:
> We use the same matrix for all color channels, but offset the starting
> address for each channel to decorrelate the channels.
>
> Let me know if you're interested.
Yes, we are interested. I'd really like to get rid of the random
number generato
On 27.02.2005, at 17:24, Sven Neumann wrote:
Incidentally this is exactly what I'm testing right now. ;=)
Incidentally that is what the code in CVS is doing. Looks like we were
working on the same code. We should perhaps start using mutexes on the
source code ;)
Heh, you did not only do the same b
On 27.02.2005, at 17:19, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote:
As for your claim, dithering is completely invisible, try this image,
which
is done with gimp's blend and no dithering:
http://data.plan9.de/d0.png
That image features quite visible banding effects - you will have
bandi
Just to add a bit to Sven's response:
"balachandran c" <[EMAIL PROTECTED]> writes:
>I am writing a plugin which requires comparing one row of pixels with
>the one following it. . . . how should it be done?
There are lots of examples in the GIMP source that you can look at.
Among the s
Hi,
[EMAIL PROTECTED] (2005-02-27 at 1708.40 +0100):
> Honestly I've no idea why the blending code does dithering at all;
> the dithering is completely invisible in 24bit RGB colorspace
> anyway.
Do some blends with similar colours and long distance. They look ugly
without dither, they are too reg
From: Sven Neumann <[EMAIL PROTECTED]>
Date: Sun, 27 Feb 2005 17:29:52 +0100
Robert L Krawitz <[EMAIL PROTECTED]> writes:
> We use the same matrix for all color channels, but offset the starting
> address for each channel to decorrelate the channels.
>
> Let me know if you're
On 27.02.2005, at 20:01, Robert L Krawitz wrote:
OK. The code Daniel posted shouldn't be too hard to convert. The
only thing it needs is to have the absolute row and column, to index
into the matrix.
That hasn't made it into CVS because Sven was faster...
Here's the current code:
static void
grad
Hi,
Daniel Egger <[EMAIL PROTECTED]> writes:
>for (y = PR->y; y < endy; y++)
> for (x = PR->x; x < endx; x++)
>{
> GimpRGB color;
>
> gradient_render_pixel (x, y, &color, rbd);
>
> gradient_dither (dest, dither_rand, color.r);
> gradient_dithe
In regard to: Re: [Gimp-developer] GIMP fails to compile without C++...:
Daniel Egger <[EMAIL PROTECTED]> writes:
just curious, is it expected that configuration of a GIMP
build will fail if configure cannot find a C++ compiler?
That question would better be asked on the autoconf list. While you
ar
On Sun, 2005-02-27 at 01:04 +0100, Sven Neumann wrote:
> Hi again,
>
> Jay Cox <[EMAIL PROTECTED]> writes:
>
> > Clearly the gradient code could use some tuning. A linear blend
> > shouldn't take much more than 1/2 a second even with dithering.
>
> Could we improve this by preparing a reasonabl
Hi,
Jay Cox <[EMAIL PROTECTED]> writes:
>> Now that this race condition is eliminated I might look into adding
>> hooks to the pixel-processor to allow initialisation of per-thread
>> data, like for example a GRand.
>
> I think that is the correct way to do it. It should be done generaly
> enoug
On 28.02.2005, at 00:25, Sven Neumann wrote:
The histogram code does already use the threaded pixel-processor. You
think we could simplify the code? IMO the current solution isn't all
that bad. But I haven't benchmarked it so I don't really know...
I tried to introduce the per-thread initializatio
28 matches
Mail list logo
