Hi,
I and I wrote:
(2) The text tool is under heavy development and is not advertised and
being fully functional. Use GIMP-1.2 if you need a working text tool.
this should have read ... is not advertised as being fully functional ...
Salut, Sven
On Tue, 11 Mar 2003 09:46:49 +, Adam D. Moss [EMAIL PROTECTED] wrote:
[...] The idea
of rehash-on-dirty would be to catch identical tiles, even
accidentally-identical tiles (like great masses of transparent
tiles, presuming that you scrub the RGB data of a transparent
pixel; the
On Tue, Mar 11, 2003 at 01:07:21PM +0100, Raphal Quinet wrote:
On Tue, 11 Mar 2003 09:46:49 +, Adam D. Moss [EMAIL PROTECTED] wrote:
[...] The idea
of rehash-on-dirty would be to catch identical tiles, even
accidentally-identical tiles (like great masses of transparent
tiles,
Hi,
Adam D. Moss [EMAIL PROTECTED] writes:
If there is a bug then it is in the remaining tools and plugins that
1) Use the RGB value of an utterly transparent RGBA (or indeed GREYA)
pixel (try to tell me that this is a desirable feature in the
blur plugins, for example), or
2) Try to
Ernst Lippe wrote:
On Tue, 11 Mar 2003 17:12:14 +0100
Raphaël Quinet [EMAIL PROTECTED] wrote:
On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe [EMAIL PROTECTED] wrote:
On Tue, 11 Mar 2003 09:46:49 +
Adam D. Moss [EMAIL PROTECTED] wrote:
I think that the user should be able to edit the alpha
Sven Neumann wrote:
are you saying that we'd best remove the Anti-Erase feature from the
current development version because it is broken by design and only
works by accident (often but not reliably)? That's how I interpret
your words but I want to be sure...
I think that's the case. From a
Sven Neumann wrote:
which operation (besides the evil anti-erase) wouldn't have such a
color information?
IIRC the only other tool I found that can be made to resurrect
colour information is the Levels tool operating on the Alpha
channel (I think that the current selected BG colour is a good
On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe [EMAIL PROTECTED] wrote:
On Tue, 11 Mar 2003 17:12:14 +0100
Raphaël Quinet [EMAIL PROTECTED] wrote:
I think that it _is_ unreasonable to expect this to work.
Why? Normally operations on the alpha don't influence the state
of the other color
Steinar H. Gunderson wrote:
On Tue, Mar 11, 2003 at 06:36:47PM +0100, Sven Neumann wrote:
which operation (besides the evil anti-erase) wouldn't have such a
color information? The only operation I can think of that makes a
transparent pixel non-transparent is some sort of painting with one of
the
On Tue, 11 Mar 2003 18:55:33 +0100, David Necas (Yeti) [EMAIL PROTECTED] wrote:
On Tue, Mar 11, 2003 at 05:13:43PM +, Adam D. Moss wrote:
If there is a bug then it is in the remaining tools and plugins that
1) Use the RGB value of an utterly transparent RGBA (or indeed GREYA)
pixel
On Tue, Mar 11, 2003 at 07:23:03PM +0100, Sven Neumann wrote:
I don't agree. The obvious solution whenever manipulation of the alpha
channel is desired is to use a layer mask.
For people on this list.
But most people I know would be able to find the solution
I described -- purely
On Tue, Mar 11, 2003 at 10:15:51AM -0800, Daniel Rogers wrote:
Alpha is a measure of the amount of coverage of the pixel. (e.g. an
alpha of .5 means half the pixel is covered). In particular, 0 alpha
means that the pixel is not covered at all. This means that the pixel
contributes NO
Hi,
David Necas (Yeti) [EMAIL PROTECTED] writes:
On Tue, Mar 11, 2003 at 07:23:03PM +0100, Sven Neumann wrote:
I don't agree. The obvious solution whenever manipulation of the
alpha channel is desired is to use a layer mask.
For people on this list.
But most people I know would be
Raphaël Quinet ([EMAIL PROTECTED]) wrote:
Your example is fine, except for the last step using Noisify on the
alpha channel. As Adam pointed out in his previous messages, the
correct way to acheive the same effect would be to use Noisify on a
layer mask, not on the alpha channel.
Be careful:
[EMAIL PROTECTED] (2003-03-11 at 1828.24 +0100):
are you saying that we'd best remove the Anti-Erase feature from the
current development version because it is broken by design and only
works by accident (often but not reliably)? That's how I interpret
your words but I want to be sure...
Daniel Rogers wrote:
I am missing some context here. Why does a tile get dirty?
In gimp parlance, a tile is 'dirtied' whenever its pixel data
gets written to (okay, that's a bit ambiguous with the tile ref
system -- that could mean either when a write-able reference is
added to it or when that
Steinar H. Gunderson wrote:
On Tue, Mar 11, 2003 at 10:15:51AM -0800, Daniel Rogers wrote:
Alpha is a measure of the amount of coverage of the pixel. (e.g. an
alpha of .5 means half the pixel is covered). In particular, 0 alpha
means that the pixel is not covered at all. This means that the
Hi. Are there any plans to eventually include Gimp-python in the GIMP package?
I would like to be able to do automation without having to learn Perl or
Scheme.
Thank you.
-Greg Yasko
___
Gimp-developer mailing list
[EMAIL PROTECTED]
David Necas (Yeti) wrote:
I want a yellow opaque circle, with edges blurred to
transparent and some fine yellow pixelish haze around.
The transition I also don't like continuous, but spotty with
varying opacity, so one can see the background better or
worse through individual pixels.
Layer mask!
Daniel Rogers ([EMAIL PROTECTED]) wrote:
[maybe increasing the opacity]
If you were to do something like this, where you wanted to have control
of the full range of opacity in a layer mask, then the first mistake you
made was to add alpha to the image when you should have added a layer mask.
Would just antierase users be happy with layers masks? This feature is
ignored a lot, and I think it does the same, you hide and unhide areas
as you want, keeping the colour info. If yes, get rid of antierase.
GSR
Or, as I suggested in an earlier email, but I don't think was stated
very
Daniel Rogers wrote:
There may be some worth in considering including other kinds of
information in a pixel besides alpha.
In addition to alpha (the measure of coverage) you could also include
transparency (which is something a measure of how much light passes
through, i.e. the actual
[EMAIL PROTECTED] (2003-03-11 at 1233.14 -0800):
Would just antierase users be happy with layers masks? This feature is
ignored a lot, and I think it does the same, you hide and unhide areas
as you want, keeping the colour info. If yes, get rid of antierase.
Or, as I suggested in an earlier
On Tue, Mar 11, 2003 at 11:41:30AM -0800, Daniel Rogers wrote:
Weight the pixel value by the alpha value, just like you do with any
other operation on pixels. This makes sense when alpha is defined to be
the coverage. If a pixel is only really half covered, their should half
the impulse
On Tue, Mar 11, 2003 at 12:33:14PM -0800, Daniel Rogers wrote:
Or, as I suggested in an earlier email, but I don't think was stated
very clearly, implement anti-erase as a layer mask (whether or not the
user can actually see the extra layer).
If you want to implement anti-erase as a layer
Steinar H. Gunderson wrote:
On Tue, Mar 11, 2003 at 11:41:30AM -0800, Daniel Rogers wrote:
Weight the pixel value by the alpha value, just like you do with any
other operation on pixels. This makes sense when alpha is defined to be
the coverage. If a pixel is only really half covered, their
Adam D. Moss wrote:
In addition to alpha (the measure of coverage) you could also
include transparency (which is something a measure of how much
light passes through, i.e. the actual transparency of glass, as
opposed the the coverage of a screen, this is equivilent to
insisting on a layer mask to
Simon Budig wrote:
Sorry, this is a step back towards Gimp 0.54 where you had no embedded
alpha channel in the images and compositing of two images (that had to
have the same size) was done via a third grayscale image (that also had
to have the same size).
I am not suggesting that alpha is gotten
Simon Budig wrote:
Sorry, this is a step back towards Gimp 0.54 where you had no embedded
alpha channel in the images and compositing of two images (that had to
have the same size) was done via a third grayscale image (that also had
to have the same size).
Incidentally, this is precisely what
David Necas (Yeti) wrote:
If you want to implement anti-erase as a layer mask, then
for antierase to be available, this layer mask (not shown to
user) has to be present all the time (if not, the
information needed for anti-erase would be lost).
But how this situation differs from separate alpha
On Tue, Mar 11, 2003 at 02:53:45PM -0800, Daniel Rogers wrote:
Although back on the topic of anti-erase, I think that the only way to
do anti-erase correctly is with another layer. Once alpha goes to zero,
the pixel no larger part of the sampled image.
OK, I could use alpha in a wrong
* Adam D. Moss [EMAIL PROTECTED] [030311 23:38]:
Guillermo S. Romero / Familia Romero wrote:
Would just antierase users be happy with layers masks? This feature is
ignored a lot, and I think it does the same, you hide and unhide areas
as you want, keeping the colour info. If yes, get rid of
Daniel Rogers ([EMAIL PROTECTED]) wrote:
[...]. This is
specifically because of the overloaded nature of alpha here. Alpha is
being used as transparecy but (correctly) is mathematiclly treated as
the coverage.
[...]
This is why I suggested earlier the seperation between transparency and
David Necas (Yeti) wrote:
OK, I could use alpha in a wrong sense, it's a matter of
definition, and let's agree on yours (though I wonder how's
called the object alpha==0 pixels are part of, because
I can draw on them, unlike pixels outside layer boundaries,
so they exist and are part of
Simon Budig wrote:
Sorry, but I don't believe that this destinction would make sense.
From my point of view transparency/opacity and coverage are two
models to explain what happens when talking about alpha. I do know that
the original Porter Duff paper based its conclusions on the coverage
model,
35 matches
Mail list logo
