Re: 32-bit images in gimp - Alpha handling wrong?
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?
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
gtk+ 1.3.x
Question. . Will Gimp 1.1.24 work with gtk+ 1.3.0? I am working on Gimp for BeOS and the port of gtk+ that I have is roughly 1.3.0 and there is no port of the 1.2.x branch. Thanks, Daniel Rogers [EMAIL PROTECTED]
Re: 32-bit images in gimp - Alpha handling wrong?
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?
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: GIF Saving Patch
On Tuesday, 18 Jul 2000, [EMAIL PROTECTED] wrote:
> Attached is a patch file for gif.c that fixes a bug that made a dialog pop
> up when running noninteractively, which was messing up my scripts.
>
> It was written against 1.1.23 and 3.0.2 of gif.c in plug-ins/common/.
>
> If someone with the right access could run this patch on the source tree
> it would probably help someone else out someday.
I've put in the following fix into CVS which should get rid of the
dialog in the non-interactive case.
--- plug-ins/common/gif.c~ Thu Jun 8 18:05:27 2000
+++ plug-ins/common/gif.c Tue Jul 18 21:32:07 2000
@@ -805,7 +805,9 @@
/* Image has illegal bounds - ask the user what it wants to do */
- if (badbounds_dialog())
+ /* Do the crop if we can't talk to the user, or if we asked
+ * the user and they said yes. */
+ if ((run_mode == RUN_NONINTERACTIVE) || badbounds_dialog ())
{
gimp_run_procedure("gimp_crop", &nreturn_vals,
PARAM_IMAGE, image_ID,
Austin
Re: 32-bit images in gimp - Alpha handling wrong?
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: please
In regard to: please, [EMAIL PROTECTED] said (at 6:27pm on Jul 17, 2000): >We are trying to port GIMP 1.0.4 to AIX 4.3.3 We have been able to compile >this >without any problems but when we try to execute, we are getting as follows >-- >/porting/subs/gimp-1.0.4/app>./gimp > >./gimp fatal error: sigsegv caught >./gimp (pid:12366): [E]xit, [H]alt, show [S]tack trace or [P]roceed: > > >./gimp (pid:12366): [E]xit, [H]alt, show [S]tack trace or [P]roceed:P >Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject' > >Gtk-CRITICAL **: file gtkobject.c: line 235 (gtk_object_destroy): assertion > `obj >ect != NULL' failed. > >Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject' > >Gtk-CRITICAL **: file gtkobject.c: line 1171 (gtk_object_unref): assertion >`obje >ct != NULL' failed. >Segmentation fault(coredump) > The problems are coming in the gtk library, so you will probably need to debug things there. Your best bet is to recompile glib and gtk+ with debugging, and then disable the signal handlers in the gimp (comment them out, so it doesn't try catch SEGV) and recompile gimp with debugging, and then run the gimp under a debugger (assuming you can find a debugger that works on 4.3.3). Note that recent development versions of the gimp also exhibit gtk+ problems on AIX. Whether that's because of a bug in gtk+ or a bug in AIX is unknown at this point. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
GIF Saving Patch
Attached is a patch file for gif.c that fixes a bug that made a dialog pop
up when running noninteractively, which was messing up my scripts.
It was written against 1.1.23 and 3.0.2 of gif.c in plug-ins/common/.
If someone with the right access could run this patch on the source tree
it would probably help someone else out someday.
Bryan Livingston
-
http://www.cooltext.com - Online Graphics Generator
http://www.solarempire.com - Realtime Web Based Strategy Game
-
805a806,816
> if(run_mode == RUN_NONINTERACTIVE) {
>gimp_run_procedure("gimp_crop", &nreturn_vals,
> PARAM_IMAGE, image_ID,
> PARAM_INT32, gimp_image_width(image_ID),
> PARAM_INT32, gimp_image_height(image_ID),
> PARAM_INT32, 0,
> PARAM_INT32, 0,
> PARAM_END);
>return TRUE;
> }
>
Re: 32-bit images in gimp - Alpha handling wrong?
>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?
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?
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?
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
ANNOUNCE: gimp-print 3.1.9
All users of the GhostScript stp driver should upgrade, due to a critical bug that causes an infinite loop to occur with some combinations of printer choice, compiler used, and possibly other factors. Other users may want to upgrade due to the print quality improvements. One user has reported an apparent crash or corrupt output from the plugin. We have not been able to reproduce this. I am working with that user to try to understand what's happening. If that turns out to be real, 3.1.10 will be released when a fix is available. Print 3.1.9 contains the following improvements over Print 3.1.8: 1) A bug in the GhostScript driver would cause the driver to go into an infinite loop on some systems with some printers, depending upon details of the compiler and so forth. All users of the GhostScript driver should immediately update. 2) Substantial quality improvements across many printers: * Output across printers and resolution modes is much more closely matched (except probably 360 DPI). The saturation may be somewhat less than before, however. * 720 DPI is greatly improved on Epson Stylus Color 860/1160 and Stylus Photo 870/1270. The 750/1200 may not show this improvement. * Artifacts in the adaptive hybrid and adaptive random dithering modes have been eliminated. Please see the README for more information. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
RE: Map to object death
> > Hello. > When i attempt to use "map to object" through > "selection to animage" on > the file > "http://oa-bsa.org/resources/logos/gif250/logo_250.gif" > mapped > to a box, "map_object" dies. here's the stack trace: > > /usr/local/lib/gimp/1.1/plug-ins/MapObject: fatal > error: Segmentation > fault > /usr/local/lib/gimp/1.1/plug-ins/MapObject > (pid:27709): [E]xit, [H]alt, > show [S]tack trace or [P]roceed: s > #0 0x4018bf78 in g_on_error_stack_trace ( > #1 0x4018be8d in g_on_error_query ( > #2 0x4027b1e6 in gimp_plugin_sigfatal_handler > (sig_num=11) at > gimp.c:1210 > #3 0x402b60b8 in sigaction () from /lib/libc.so.6 > #4 0x8053338 in get_ray_color_box (pos=0xb080) at > mapobject_shade.c:897 > [snip] Which version of gimp? What os? Tom
