On Mon, Sep 18, 2000 at 05:24:20PM -0400, "Garry R. Osgood" <gosgood@xxxxxxx> wrote:
> Gimp should do premultiplied alpha. Not because it cures acne or
> extends human life expectancy by an astounding 3000 precent, but
> be helpful to that crowd if the dear little creature would
> only eat pre-multiplied alpha and composite with it.
One must realise, however, that this only gives a speed improvement
(possibly), and that the visual result is identical (except for rounding
errors, which are only problematic in premultiplied alpha).
Everything that currently results in visible artefacts with
non-preemultiplied alpha will do the same with pre-multiplied alpha, and
would need to be fixed anyway (or is a misconception of the user).
> a slot for an alpha premultiplied flag. And premultiplied pixels are
> otherwise indistinguishable from unmultiplied ones. So it is doubtful
> to me that any paint program any time soon can automagically determine
One could argue that a file format that has no way of specifying wether alpha
is premultiplied or not is hardwired to one alternative - if people use it in
a wrong way (like in the png case) they have incorrect files. For files that
*are* commonly used in both types and cannot distinguish between them (e.g.
raw bytes!) a switch might be helpful.
This, however, is a just an import issue. Gimp happily reads indexed
images with 500 colours, but of course cnanot store them in that way.
In this dicussion, we should draw an exact line between import/export
issues (where premultiplied alpha is a file format feature, and incorrect
handling would be a bug somewhere) and using pre-multiplied alpha for the
internal representatioin (which is *just* a speed hack, if implemented in
a fast way ;).
If Gimp would create different results (modulo rounding errors) when
working in pre-multiplied space this would be a bug.
> a clear statement that Gimp is an unmultiplied compositor (though
> certain tools and plug-ins necessarily have to internally play the
> premultiplied game - blur comes to mind) and (c) If you care about
While this might be interesting from a technical perspectibve, since
both compositors must result in the same image, this is not really a
priority. The only thing one could mention is that gimp's result will be
more correct with unmultiplied alpha.
> Perhaps a later Gimp will know how to consume premultiplied alpha
> (you'll have to throw some switches) the 1.x Gimps of the next
> two years or so won't know how to do it.
But it is probably just a single line in the file load/save functions, so
it should be easy to implement.
If you mean that gimp should have another set of compositing modes,
very much like the dissolve mode which does a kind of "incorrect" alpha
composing (namely dithering) but adds a useful visual effect, then this
might be a worthhwhile addition. However, changing gimp's behaviour in RGB
mode depending on file format features is like saying: well, format xy
saves pixels in the wrong order, so you have to turn your monitor 180", as
gimp is a top-down-compositor.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
