Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-19 Thread Marc Lehmann

On Wed, Jul 19, 2000 at 11:53:30PM +1000, David Hodson <[EMAIL PROTECTED]> wrote:
> > No:
> 
> No? If I render an object, and the edge of that object only covers
> half of a pixel, why does it need more than half the colour range?

I was talking about precision and not resolution.

> is that I could load an image file containing pre-multiplied alpha
> without being asked if the alpha should be un-multiplied. (Although
> I still think there's a useful distinction between pre-mult alpha
> and non-mult masks, and I would like to load an rgba image into
> Gimp and then add a mask layer.)

Pre-mulitplied alpha is a data representation which contains as much or less
information than the un-multiplied version.

The only reason to use pre-multiplied alpha is for speed, or ease-of-use.
(unless you argue that out-of-gamut values make sense). Since pre-multiplying
rgba images looses information (maybe a lot) there should be very good
reasons to switch the representation used to store the data.

As opposed to pre-multiplying image data to speed up display.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-19 Thread David Hodson

Marc Lehmann wrote:
> 
> On Wed, Jul 19, 2000 at 11:18:27PM +1000, David Hodson <[EMAIL PROTECTED]> 
>wrote:
> > It's arguable that the information isn't there to start with.
> 
> No:

No? If I render an object, and the edge of that object only covers
half of a pixel, why does it need more than half the colour range?
(This is getting a little off-topic, really.)


> 1. image loading and saving
> 2. internal data storage
> 3. composition algorithms

> It seems to me that we could agree on 1. being an interface issue and 2.
> being opaque to the user.

OK then, if I bow to the prevailing wisdom, what it boils down to
is that I could load an image file containing pre-multiplied alpha
without being asked if the alpha should be un-multiplied. (Although
I still think there's a useful distinction between pre-mult alpha
and non-mult masks, and I would like to load an rgba image into
Gimp and then add a mask layer.)

A quick glance at the targa file spec reveals nothing about the 
intended meaning of the rgba data.


-- 
David Hodson  --  [EMAIL PROTECTED]  --  this night wounds time



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-19 Thread Marc Lehmann

On Wed, Jul 19, 2000 at 11:18:27PM +1000, David Hodson <[EMAIL PROTECTED]> wrote:
> It's arguable that the information isn't there to start with.

No:

> A pixel with an alpha value of 0.5 will only contribute to half the
> colour of the pixel, so it only needs half the colour information.

Since computers cannot store real numbers, there is inevitably loss of data
associated with premultiplying.

It seems to me that the disucssion should really be split into three
areas, as people are talking about different areas:

1. image loading and saving
2. internal data storage
3. composition algorithms

It seems to me that we could agree on 1. being an interface issue and 2.
being opaque to the user.

So the question is not wether gimp can handle premulitplied alpha (it
can ;) but wether the combination modes allow for the behaviour you want
(which has nothing to do with internal presentation).

I might be wrong, of course... ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-19 Thread David Hodson

Thanks to everyone for the responses. A few comments:


Jay Cox wrote:
> 
> David Hodson wrote:
> > the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff.
> 
> All three of whom come from a 3d rendered graphics background.

As do I.

> For compositing and image warping pre multiplied alpha is great.  for
> color correction pre-multiplied alpha just gets in the way.

Agreed. I'm kind of interested in compositing and image warping, though,
and I'd like to see Gimp as widely useful as it can be. When I find
something that it can't do, I try to fix it, subject to the prevailing
design philosophies.


Nick Lamb wrote:

> I'm not aware of any other common interchange format which supports the
> pre-multiplied alpha representation in storage.

I suspect many image formats don't actually specify how rgba data is
defined, though it's not something I've looked at for a while.

>  No the program which produced your example PNG image is broken.

That would be Gimp  :-)
The original image was loaded from TGA and directly saved to PNG.
Since Gimp didn't know that the targa was pre-multiplied, it left
it alone.


"Garry R. Osgood" wrote:
> 
> [...] How would the unerase
> tool deal with full transparent premultiplied alpha [A*R = A*G= A*B = A = 0]?

This comes back to the distinction I was trying to make between masks
and alpha. Gimp uses (what I refer to as) masks (not alpha) to combine
layers. An rgba image has nothing to unerase where alpha = 0 - the image
doesn't exist there. An rgba layer in Gimp would have a separate mask
channel added, and unerase would still work where the layer had been
erased.

> Premultiplication buys its efficiency
> by removing information content from the layer.

It's arguable that the information isn't there to start with. A pixel
with an alpha value of 0.5 will only contribute to half the colour of
the pixel, so it only needs half the colour information.


-- 
David Hodson  --  [EMAIL PROTECTED]  --  this night wounds time



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-19 Thread Garry R. Osgood

Calvin Williamson wrote:



> Eg He shows that if you want to downsample and then composite an image over
> a background, thats different from compositing first and then downsampling
> if you are using un-premultiplied images (you get different results that is).
> But with pre-multiplied images you get the same answer with either order.



> So it depends on how you work with your images. You might not be
> using the "compositing engine" part of the paint program at all.
> You might need to edit/paint the RGBs and Alpha for a layer more
> or less independently. In this case Alpha=0  and  Color!=0
> channels might be fine. Maybe the correct Alpha channel isnt even there
> yet. Or maybe you are going to paint the alpha channel yourself.

Layer trees saw some play at GimpCon (http://www.gimp.org/gimpcon)
where the unidirectional layer stack differentiates into something with
branches.  Users could composite/paint on one branch without disturbing
others - I think the metaphor to make dependency trees was made. Anyhow,
branches can distinguish themselves from others by having different compositional
rules.  Users with compositional aims may wish to work with a pre multiplied
layer branch, knowing that certain tools are just not appropriate for that milieu.
Conversely users with painterly aims, who think in terms of alpha masking,
would find an unmultiplied layer branch to their liking - and mask-oriented tools
like unerase become readily functional.

To my mind, there is no absolute "rightness" to premultiplied layers,
they are "right" only when they help users achieve particular aims.  If Gimp (2.0)
aims at being a general paint and compositing program, then its core needs to
support both approaches to using alpha, and make the distinction of different kinds
of layers visible in the user interface (becoming another beast in a layer menagerie
that includes Gimp classic layers, text layers, structured vector graphic layers...)

Be good, be well

Garry






Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Calvin Williamson

On Tue, Jul 18, 2000 at 09:41:49PM -0400, Garry R. Osgood wrote:
> David Hodson wrote:
> 
> > "Steinar H. Gunderson" wrote:
> >
> > > GIMP already does this (32-bit = RGBA, the `extra' 8 bits is an alpha channel,
> > > used for transparency information), and has done for a long time now.
> 
> Calvin Williamson recommended "Image Composition
> Fundamentals" by Alvy Ray Smith, for a review
> and advantages of the technique.
> http://www.alvyray.com/Memos/default.htm.

Another great reference is Blinns two chapters on Compositing
in his "Dirty Pixels" book. 

He gives some other arguments (aside from elegance and efficiency) as to why
compositing and filtering with premultiplied alphas is better.

Eg He shows that if you want to downsample and then composite an image over
a background, thats different from compositing first and then downsampling
if you are using un-premultiplied images (you get different results that is). 
But with pre-multiplied images you get the same answer with either order.  

So aside from efficiency there are some arguments for "correctness"
when doing filtering operations and compositing. 

But of course pre-multiplied squashes out any color information
that might like to hang around in the color channels temporarily on
the way to a composite. 

So it depends on how you work with your images. You might not be
using the "compositing engine" part of the paint program at all. 
You might need to edit/paint the RGBs and Alpha for a layer more
or less independently. In this case Alpha=0  and  Color!=0
channels might be fine. Maybe the correct Alpha channel isnt even there
yet. Or maybe you are going to paint the alpha channel yourself.

Compositing programs tend to use premultiplied, but for painting programs
un-premultiplied is pretty common. Some paint programs do use premultiplied 
though.

Calvin  



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Tom Rathborne

On Tue, Jul 18, 2000 at 09:41:49PM -0400, Garry R. Osgood wrote:
> David Hodson wrote:
> > Example: render an rgba image. (I was using some PovRay output; I
> > presume it does a reasonable job.) Now create a flat colour
> > background in the Gimp, lay the rgba image on top, and try to get
> > a clean composite without black fringing. I don't think it can be
> > done,
> 
> It can't be done, in my opinion. What we surmise to be [R*A, G*A,
> B*A, A] Gimp assumes to be [R, G, B, A] and reads the color
> components as near black for near transparent regions.  That makes
> black fringing unavoidable.

The way I got around this was to regenerate my own "Alpha" channel by
re-rendering my PovRay scene in black-on-white. That is, white
background with all objects solid black. If I recall correctly, it was
just a matter of setting the "colour" of each object to black and
rendering with a very low quality setting. (erm, or maybe I did it in
white-on-black and inverted it ... in any case the same result)

This process gave me a white mask (b) for the background which could
then be multiplied with whatever image (i) I wanted "behind" the
PovRay scene. Adding this (b*i) to the premultiplied alpha image from
PovRay gave the correct visual result. Actually, come to think of it,
I didn't render the high-quality scene with any alpha at all. The
addition did it.

Cheers,

Tom

-- 
--   Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/
--  "We promise according to our hopes, and perform according to our fears."
-- -- Francois, Duc de la Rochefoucauld



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Garry R. Osgood

David Hodson wrote:

> "Steinar H. Gunderson" wrote:
>
> > GIMP already does this (32-bit = RGBA, the `extra' 8 bits is an alpha channel,
> > used for transparency information), and has done for a long time now.

Calvin Williamson recommended "Image Composition
Fundamentals" by Alvy Ray Smith, for a review
and advantages of the technique.
http://www.alvyray.com/Memos/default.htm.

> At the moment, as far as I can tell, the Gimp cannot handle
> pre-multiplied rgba images.

Yes. In fact, in generating the projection images (app/paint_func.c) Gimp
pretty much does the "unmultiplied case" in the above
cite, including the "second composition" step to recover an unmultiplied
layer from a premultiplied intermediary result. From the premultiplied
viewpoint, that's a lot of unnecesary multiply and divides.

> Example: render an rgba image. (I was using
> some PovRay output; I presume it does a reasonable job.) Now create a
> flat colour background in the Gimp, lay the rgba image on top, and try
> to get a clean composite without black fringing. I don't think it can
> be done,

It can't be done, in my opinion. What we surmise to be [R*A, G*A, B*A, A]
Gimp assumes to be [R, G, B, A] and reads the color components as
near black for near transparent regions.  That makes black fringing unavoidable.

> though I'd love to be proven wrong. (There could be issues
> here with different gamma handling between PovRay and the Gimp, but I
> suspect the problem is simply a failure to handle rgba properly.)

If all we had to care about was an efficient pipeline, premultiplied is the
way to go - but there's more to Gimp than its rendering pipeline. There
are tools that are relatively simple to code with unmultiplied layers, but are
difficult or impossible to do with premultiplied ones. How would the unerase
tool deal with full transparent premultiplied alpha [A*R = A*G= A*B = A = 0]?
Look for some back door on an undo stack?  Premultiplication buys its efficiency
by removing information content from the layer.

The performance arguments advanced by Smith are compelling, and his pipeline
is computationally cleaner, but the last time I did any serious
performance measurement on the pipeline was a low-teens Gimp, and compositing
to the projection was not a big comsumer compared to building buffered writes
to the X server (this was, I recall, not built with threads enabled).

My two U. S. cents

Garry Osgood





Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Nick Lamb

On Tue, Jul 18, 2000 at 10:39:26PM +0100, I wrote:
>  No the program which produced your example PNG image is broken.
> The PNG specification requires straight RGBA, pre-multiplied alpha is
> prohibited and this is spelled out several times. Gimp can't hope to
> interpret an invalid image correctly.

On further examination it looks to me as though the test image on your
web page is in fact a _picture_ of an image file which you feel didn't
load correctly.
If I'm right, please provide the _original_ file, if you can't see
the difference never mind, I assure you I know what I'm doing.
If in fact that image file is the original image file, my previous
recommendation remains, we must alert png-implement about this broken
software or process immediately.

Since you mentioned PovRay I looked at their code, I found it to be a
tangled mess, but didn't see anything strikingly wrong with it. I would
be most suprised if the PNG on your web page was produced by that code
though.

Nick.



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Nick Lamb

On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson wrote:
> > Can you justify that (all images should be pre-multiplied)?
> > Or is this just your unsupported opinion?
> 
> Well, that was attempted editorial humour to some extent, but it's also
> the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff.
> I'd hardly call it unsupported.

Ah, but as others have said, these are people working in a totally
different area, and at least Tom Duff is most famous for a speed-up hack
easily as ugly as pre-multiplied alpha (Duff's device).

> > Gimp has no support for pre-multiplied alpha,
> 
> Well, there's my answer. No support.

... and no need for it. With the exception of (IMHO useless) out-of-gamut
RGB values, each is equally expressive, plug-ins and tools are free to
convert to pre-mult if appropriate but the core uses ordinary RGBA.

> A hack? I thought it was a mathematically elegant representation of
> an image layer, which is why I see a reason to support it. I'm trying
> to find out if anyone else agrees, or if I'm missing something that's
> already there, or there's something specific about Gimp and the way
> it's used that makes it unnecessary or not useful.

Let's rather say "Not a priority" rather than "not useful", but I do
not expect pre-mult alpha to be exposed to the user (as opposed to
used in plug-ins or for speed-up hacks) in Gimp any time soon.

> And even if you consider it a hack, don't people use pre-mult alpha?
> Am I the first one to notice this and complain?

Notice? I don't know. Complain, yes. You'll see why in a minute I think.

> I have no love at all for the TIFF format. (I was present at the birth
> of a similarly over-extended format. I should have complained more loudly.)
> But that's irrelevant - or at least orthogonal - to the use of pre-mult
> alpha.

I'm not aware of any other common interchange format which supports the
pre-multiplied alpha representation in storage. If we didn't have to load
or save it, pre-mult would not be a problem for Gimp.

> I've placed a page at:
> 
> www.ozemail.com.au/~hodsond/alpha.html
> 
> Images are just inline PNGs, just grab 'em as they appear; but it's not
> really necessary, if you say that Gimp doesn't handle pre-mult alpha,
> then that explains the results.

 No the program which produced your example PNG image is broken.
The PNG specification requires straight RGBA, pre-multiplied alpha is
prohibited and this is spelled out several times. Gimp can't hope to
interpret an invalid image correctly.

Please identify the program (name, version, vendor etc.) and I will pass
the details on to png-implement. Hopefully we can arrange for them to
issue an urgent update to their users and if necessary get publicity so
that everyone knows not to use this broken program.

> Do users have problems with pre- and non-mult alpha?

Since they are equivalent I'd guess users remain comfortably unaware.

Nick.



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Guillermo S. Romero / Familia Romero

>It depends on what you are doing weather pre multiplied alpha is useful
>or not.  For compositing and image warping pre multiplied alpha is great.  for
>color correction pre-multiplied alpha just gets in the way.  Since
>pre-multiplying the alpha does throw away a few bits of information my
>preference is for non-pre-multiplied alpha.

I know 3D software that outputs pre or non-pre, user selectable, but read
only pre. The manual says all that, and recommends non-pre for "drawing
programs".

What I do not understand, is why I would like pre for compositing? If I have
an image with pre, when I composite with another image, I will get damaged
borders, instead of true composition based in the alpha, no? If software
knows it, it can be fixed... but after lossing precission, no?

GSR
 




Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Jay Cox

David Hodson wrote:
> 
> Nick Lamb wrote:
> >
> > On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote:
> > > OK, this has been bugging me for some time. I'm convinced that Gimp's
> > > alpha handling is wrong, in more than a few places.
> >
> > OK, but please provide some concrete examples...
> 
> > > To start with, there should be a clear distinction between alpha, which
> > > is a transparency channel in an image and should always scale the pixel
> > > colour values; and masks, which serve to select areas of an existing
> > > image. (Yes, I know not all rgba images are pre-multiplied. They should
> > > be.)
> >
> > Can you justify that (all images should be pre-multiplied)?
> > Or is this just your unsupported opinion?
> 
> Well, that was attempted editorial humour to some extent, but it's also
> the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff.
> I'd hardly call it unsupported.

All three of whom come from a 3d rendered graphics background.  In the photo
manipulation/retouching realm it is very uncommon (and inconvenient) to have
a pre-multiplied alpha channel.

> > > At the moment, as far as I can tell, the Gimp cannot handle
> > > pre-multiplied rgba images.
> >
> > Gimp has no support for pre-multiplied alpha,
> 
> Well, there's my answer. No support.

It really shouldn't matter to the end user weather we use pre-multiplied alpha
internally or not as long as we do the proper conversions on load/save (and
of course do the image manipulation properly WRT. alpha)

> > and I don't see any reason
> > to change this because it's just a hack.
> 
> A hack? I thought it was a mathematically elegant representation of
> an image layer, which is why I see a reason to support it. I'm trying
> to find out if anyone else agrees, or if I'm missing something that's
> already there, or there's something specific about Gimp and the way
> it's used that makes it unnecessary or not useful.

It depends on what you are doing weather pre multiplied alpha is useful
or not.  For compositing and image warping pre multiplied alpha is great.  for
color correction pre-multiplied alpha just gets in the way.  Since
pre-multiplying the alpha does throw away a few bits of information my
preference is for non-pre-multiplied alpha.

> And even if you consider it a hack, don't people use pre-mult alpha?
> Am I the first one to notice this and complain?

I do quite a lot of graphics work and almost never use images
stored with pre multiplied alpha.  

I think it is quite likely that gimp 2.0 will have some support internally for
pre multiplied images if only for optimization reasons.

Jay Cox
[EMAIL PROTECTED]



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Marc Lehmann

On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson <[EMAIL PROTECTED]> wrote:
> A hack? I thought it was a mathematically elegant representation of
> an image layer, which is why I see a reason to support it. I'm trying

AFAICS premultiplied alpha is a speed hakc and nothing more, for cases where
sacrificing precision for speed makes sense.

> And even if you consider it a hack, don't people use pre-mult alpha?

Gimp tries to convert pre-multiplied alpha back to normal alpha, as Nick
said, so it is supported (or should be). This really sounds like a load
(and maybe save) issue (most image formats do not support pre-multiplied
alpha).

Can you state any reason why premultiplied alpha should be directly
supported as data representation?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread David Hodson

Nick Lamb wrote:
> 
> On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote:
> > OK, this has been bugging me for some time. I'm convinced that Gimp's
> > alpha handling is wrong, in more than a few places.
> 
> OK, but please provide some concrete examples...

> > To start with, there should be a clear distinction between alpha, which
> > is a transparency channel in an image and should always scale the pixel
> > colour values; and masks, which serve to select areas of an existing
> > image. (Yes, I know not all rgba images are pre-multiplied. They should
> > be.)
> 
> Can you justify that (all images should be pre-multiplied)?
> Or is this just your unsupported opinion?

Well, that was attempted editorial humour to some extent, but it's also
the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff.
I'd hardly call it unsupported.

> > At the moment, as far as I can tell, the Gimp cannot handle
> > pre-multiplied rgba images.
> 
> Gimp has no support for pre-multiplied alpha,

Well, there's my answer. No support.

> and I don't see any reason
> to change this because it's just a hack.

A hack? I thought it was a mathematically elegant representation of
an image layer, which is why I see a reason to support it. I'm trying
to find out if anyone else agrees, or if I'm missing something that's
already there, or there's something specific about Gimp and the way
it's used that makes it unnecessary or not useful.

And even if you consider it a hack, don't people use pre-mult alpha?
Am I the first one to notice this and complain?

> The Gimp TIFF loader tries its
> best to convert pre-multiplied alpha images, but loading TIFFs is an
> unending struggle. The format should be put out of its misery ASAP (but
> see all previous Gimp discussions on TIFF for reasons why it stills
> stalks the earth).

I have no love at all for the TIFF format. (I was present at the birth
of
a similarly over-extended format. I should have complained more loudly.)
But that's irrelevant - or at least orthogonal - to the use of pre-mult
alpha.

> [...] Maybe you could send me some sample images off-list and I
> will look at them.

I've placed a page at:

www.ozemail.com.au/~hodsond/alpha.html

Images are just inline PNGs, just grab 'em as they appear; but it's not
really necessary, if you say that Gimp doesn't handle pre-mult alpha,
then that explains the results.


> > At the same time, much of the code for handling alpha data seems to
> > unscale and rescale the colour channels. [...]

OK, just had a look at the transform code and realised what it does -
the
"unscale and scale" is actually converting the non-premultiplied alpha
to
pre-multiplied alpha to do the transform! Hmmm...


Do users have problems with pre- and non-mult alpha?


-- 
David Hodson  --  [EMAIL PROTECTED]  --  this night wounds time



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-17 Thread Nick Lamb

On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote:
> OK, this has been bugging me for some time. I'm convinced that Gimp's
> alpha handling is wrong, in more than a few places.

OK, but please provide some concrete examples...

> (Minor disclaimer - I don't have the code in front of me right now, so
> I'm not going back to check details. And I'm not an expert on the Gimp,
> but I do know a fair amount about image processing.)
> 
> To start with, there should be a clear distinction between alpha, which
> is a transparency channel in an image and should always scale the pixel
> colour values; and masks, which serve to select areas of an existing
> image. (Yes, I know not all rgba images are pre-multiplied. They should
> be.)

Can you justify that (all images should be pre-multiplied)?
Or is this just your unsupported opinion?

> At the moment, as far as I can tell, the Gimp cannot handle
> pre-multiplied rgba images. Example: render an rgba image. (I was using
> some PovRay output; I presume it does a reasonable job.)

Gimp has no support for pre-multiplied alpha, and I don't see any reason
to change this because it's just a hack. The Gimp TIFF loader tries its
best to convert pre-multiplied alpha images, but loading TIFFs is an
unending struggle. The format should be put out of its misery ASAP (but
see all previous Gimp discussions on TIFF for reasons why it stills
stalks the earth).

> Now create a flat colour background in the Gimp, lay the rgba image on
> top, and try
> to get a clean composite without black fringing. I don't think it can
> be done, though I'd love to be proven wrong. (There could be issues
> here with different gamma handling between PovRay and the Gimp, but I
> suspect the problem is simply a failure to handle rgba properly.)

If I use an image with real alpha data it works. For your Povray image?
Who knows. Maybe you could send me some sample images off-list and I
will look at them. Povray may be broken, the file output for your
chosen format in Povray may be broken, Gimp's file loader may be
broken, and finally most unlikely you may have a broken Gimp version.

For best results, as always, send me a test image (or two) and another
image in a well-understood format like JPEG which shows approximately
what's intended, as well as any text description.

> At the same time, much of the code for handling alpha data seems to
> unscale and rescale the colour channels. This may be necessary for
> colour manipulations on pre-scaled rgba images, but for anything else
> (transforms, blurs etc.) it is unnecessary for either alpha or masks.
> Example: take the example above, but rotate the rgba image first. The
> result is fairly ugly.

Haven't looked at this, perhaps someone who owns the transforms can
comment.

Nick.



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-16 Thread David Hodson

"Steinar H. Gunderson" wrote:

> GIMP already does this (32-bit = RGBA, the `extra' 8 bits is an alpha channel,
> used for transparency information), and has done for a long time now.

OK, this has been bugging me for some time. I'm convinced that Gimp's
alpha handling is wrong, in more than a few places.

(Minor disclaimer - I don't have the code in front of me right now, so
I'm not going back to check details. And I'm not an expert on the Gimp,
but I do know a fair amount about image processing.)

To start with, there should be a clear distinction between alpha, which
is a transparency channel in an image and should always scale the pixel
colour values; and masks, which serve to select areas of an existing
image. (Yes, I know not all rgba images are pre-multiplied. They should
be.) At the moment, as far as I can tell, the Gimp cannot handle
pre-multiplied rgba images. Example: render an rgba image. (I was using
some PovRay output; I presume it does a reasonable job.) Now create a
flat colour background in the Gimp, lay the rgba image on top, and try
to get a clean composite without black fringing. I don't think it can
be done, though I'd love to be proven wrong. (There could be issues
here with different gamma handling between PovRay and the Gimp, but I
suspect the problem is simply a failure to handle rgba properly.)

At the same time, much of the code for handling alpha data seems to
unscale and rescale the colour channels. This may be necessary for
colour manipulations on pre-scaled rgba images, but for anything else
(transforms, blurs etc.) it is unnecessary for either alpha or masks.
Example: take the example above, but rotate the rgba image first. The
result is fairly ugly.


Any comments?


-- 
David Hodson  --  [EMAIL PROTECTED]  --  this night wounds time