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
mod
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 something).
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
* 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 r
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
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 cha
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 movie
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 r
Adam D. Moss wrote:
The idea isn't that the layer mask usurps image alpha, but
that traditional paint/fill tools are generally used to increase
opacity and define colour simultaneously (they do), while layer
masks are extremely handy ways to safely experiment with eroding
opacity away again as a lo
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 b
On Tue, Mar 11, 2003 at 07:05:03PM +0100, Raphaël Quinet wrote:
> It works that way because the GIMP uses post-multiplied alpha and you
> know it. If we were having this discussion about a program that uses
> pre-multiplied alpha (this is common in game editors, for example),
> then things would b
Hi,
Greg Yasko <[EMAIL PROTECTED]> writes:
> 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.
the current development version comes with python bindings. It is not
yet decided
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 sh
On Tue, Mar 11, 2003 at 10:14:50PM +0100, 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 cove
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 lay
Simon Budig wrote:
Be careful: A layer mask can *not* do everything you could do with
manipulating the alpha channel directly. Especially it is impossible to
increase the opacity of the layer with a layer mask.
True! I was in mind of style of assembling/creating images where
you start with somethi
On Tue, 11 Mar 2003 20:05:39 +0100, "Steinar H. Gunderson" <[EMAIL PROTECTED]> 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
Simon Budig wrote:
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 channe
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 impuls
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 antierase.
One weak reservation I have (I mention it in
[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 e
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 transpare
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 clearly
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
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! B
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]
http://lists.xcf.
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 p
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 ref
[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...
W
On Tue, Mar 11, 2003 at 08:05:39PM +0100, 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
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 transparency of glass, as oppo
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 caref
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
On Tue, Mar 11, 2003 at 07:15:16PM +0100, Raphaël Quinet wrote:
> On Tue, 11 Mar 2003 18:55:33 +0100, "David Necas (Yeti)" <[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
> correc
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
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 experimen
Raphaël Quinet wrote:
> The one to blame is the one who has used a feature that was
not supposed to be used.
Well, to be fair I wouldn't blame the user, I'd blame the specific
tool that was ill-conceived or ill-implemented. And even
then we've never had an explicit policy on programmatic alpha
han
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)
> >
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
Adam D. Moss wrote:
It's a reasonable direction, I think, but I have two comments:
* It probably makes sense to detect whether a whole tile is
transparent/solid/etc just-in-time when you're about to consider
swapping it out (or dropping it down to a colder cache) instead
of every time it gets dirt
On Tue, 11 Mar 2003 17:53:58 +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote:
> 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 t
Hi,
"David Necas (Yeti)" <[EMAIL PROTECTED]> writes:
> This is essentially my example from the Noisify plug-in
> discussion mentioned earlier (one can figure out other ways
> how to achieve the desired effect, but I do not consider
> them natural).
>
> I want a yellow opaque circle, with edges b
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
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 (try to tell me that this is a desirable feature in the
> blur plugins, for exa
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
choic
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 practi
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 paint tools. Such a p
Hi,
Ernst Lippe <[EMAIL PROTECTED]> writes:
> But how do you handle the case when a user would try to make a transparent
> pixel non-transparent. This pixel should then get a color, but which
> one? White and black are possible choices, and in most cases the user
> will want neither of them. Perh
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
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)
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
Nick Lamb wrote:
On Tue, Mar 11, 2003 at 04:38:13PM +0100, Ernst Lippe wrote:
I think that the user should be able to edit the alpha channel independent
from the other channels.
Agreed.
Then don't be shy of layer masks, they're a lot more flexible
than operating directly on the pixels' alpha data.
On Tue, Mar 11, 2003 at 04:38:13PM +0100, Ernst Lippe wrote:
> I think that the user should be able to edit the alpha channel independent
> from the other channels.
Agreed. I did some work on making this really true, but I'm not sure how
much of it landed in CVS.
Nick.
___
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 channel independent
> from the other channels. I don't think that it is unreasonable t
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 row-hin
Hi,
Owen <[EMAIL PROTECTED]> writes:
> keybindings.txt has been rewritten. See
> http://www.webone.com.au/~oc/gimp/kb.html The txt, tex and pdf
> versions are referenced there for download. The txt version looks
> awful,varies with editor...see pdf version
>
> Some comments are;
>
> Conflict
On Tue, Mar 11, 2003 at 01:07:21PM +0100, Raphaël 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
> > t
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
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
__
Hi,
"Patrice W." <[EMAIL PROTECTED]> writes:
> Line spacing option for the text tool seems to change the text area's
> dimensions (and crop the text when using negative values for line
> spacing) in place of changing the space between two lines...
(1) You should use Bugzilla to report such probl
(soz if you get this multiple times, it hasn't turned up after ~24h)
Sven Neumann wrote:
looks very sane overall and I couldn't find any obvious design
mistakes. There is one thing that is already halfway implemented in
*cough* - completely implemented IIRC in respect to what it was
originally inte
Hi,
Line spacing option for the text tool seems to change the text area's
dimensions (and crop the text when using negative values for line
spacing) in place of changing the space between two lines...
This option work correctly under gimp 1.2 with dynamic text.
Cheers,
Patrice Weber.
_
62 matches
Mail list logo
