Re: The GIMP at SIGGRAPH
On Wed, Jul 19, 2000 at 08:05:34PM -0700, Caroline Dahllof wrote: > This is just a reminder that there will be a GIMP User and Developer's > meeting at SIGGRAPH. > > Place: Sheraton New Orleans (see map), in room Aurora. > Date: 26 July, Wednesday > Time: 7PM-9PM > > For more information go to http://siggraph.gimp.org. Gah! It overlaps with the Web3D Roundup! What shall I do? Oh wait, the good part of the Web3D Roundup is the afterparty. Nevermind. 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
another good reason to get rid of the %"%&& default signal handler
Since, at the moment, it is very easy to crash the gimp while drawing (at leats it happens all the time to me), I am really annoyed by the signal handler: Gimp keeps a grab on the screen, which means that i have to log-in via the network (unless I am on linux an lucky enough to be able to switch consoles) and kill the gimp, to get rid of the grab. Of course, somebody might say "ah, let's just call XUngrab* (or the gtk equivalent) after the SIGSEGV occured... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 32-bit images in gimp - Alpha handling wrong?
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: gtk+ 1.3.x
Daniel writes: > 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. I would say so, yes, if you by 1.3.0 mean GTK+ as it was some months ago. The Win32 port has been using the gtk+ 1.3.0 version all the time. Currently it uses something that corresponds to a snapshot of GTK+ from late March-ish. I can't say how much actual difference there is between gtk at that point, and gtk from GTK+ 1.2.[678]. Maybe not a lot, as it was only after that point in time that the really heavy changes (no-flicker, Pango, gdk-pixbuf, GLib objects, new text widget, and whatnot) were merged in. --tml
Re: gtk+ 1.3.x
On Tue, Jul 18, 2000 at 06:59:21PM -0700, Daniel wrote: > 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. As far as I can tell, no. There is no port of gimp to gtk 1.3. But if you want to try it to make a branch, I suspect the gtk 1.3 developers wouldnt mind having a large app ported as a test case ;-> Adrian
patterns and brushes !!!
hi to all, i'm using gimp with Xvfb (no-interface mode) and some function doesn't work correctly !!! can you tell me why ? i think, for two probabiltyes : 1- i haven't patterns and brushes whith my Gimp, if this is the raight cause can you tell me how can i verify if all the brushes and patterns are recognised by my Gimp ? 2- Gimp don't recongnised some of his functions, so if is this the real cause, tell me please how to know if my functions existe or not? like: gimp_patterns_get_pattern () or gimp_gradients_set_active () wich generate errors when executing my script. Thank you ! Fethi simply. ___ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
Re: 32-bit images in gimp - Alpha handling wrong?
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?
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?
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: Bug reports
On Wednesday, 19 Jul 2000, Sven Neumann wrote: > > Can someone close the following bugs? I have reported this twice to > > [EMAIL PROTECTED], but no one closed them. > > #12303, #12302, #12298 > > Wouldn't it be easier to close them yourself instead of asking other > people? Especially since closing them is simpler and less work. > You should read http://bugs.gnome.org/server-control.html. But note that the bug tracker seems to be a bit slow currently. The webpages haven't been updated for several days, and yesterday I filed some bug reports that haven't got through yet. Austin
Re: Bug reports
Hi, > Can someone close the following bugs? I have reported this twice to > [EMAIL PROTECTED], but no one closed them. > #12303, #12302, #12298 Wouldn't it be easier to close them yourself instead of asking other people? Especially since closing them is simpler and less work. You should read http://bugs.gnome.org/server-control.html. Salut, Sven
Re: 32-bit images in gimp - Alpha handling wrong?
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
