Re: [Gimp-developer] Handling of transparent pixels
On Mon, Dec 15, 2003 at 07:43:39AM -0600, Stephen J Baker wrote: But that assumes that alpha is pre-multiplied into the RGB's - which is not the case for either DirectX or OpenGL's hardware texturing. Both OpenGL and DirectX can handle premultiplied alpha just fine. Just use additive blending and off you go. :-) The problem is of course that you lose a lot of precision when everything has to be stored in 8-bit-per-channel bitmaps after the multiplication. The standard OpenGL MIPmap generator does not do as you suggest it should. There is no standard OpenGL mip-map generator. gluBuild2DMipMaps is a part of the GL Utility kit (GLU), not OpenGL, and it usually does its work in software anyhow (quite slowly, and with mediocre quality). You have an OpenGL extension (GL_SGIS_mipmap_generate IIRC) that does automatic filtering, but the exact filtering method is somewhat undefined. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Displaying image using GTK
On Sun, Dec 14, 2003 at 09:29:07AM -0800, Manish Singh wrote: Yeah, gcc is quite slow at compile time, and I think in newer versions it's gotten slower, not faster. From the gcc3.4 changes.html: * Precompiled headers are now supported. Precompiled headers can dramatically speed up compilation of some projects. There are some restrictions; read the manual for the details. (...) * Substantial improvements in compile time have been made, particularly for non-optimizing compilations. I'm not sure how easy it would be to use pch in The GIMP, but at least the second item should mean that gcc is on the right track again :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Spam bad!
On Sat, Oct 25, 2003 at 03:37:51PM +0200, Branko Collin wrote: Are you sure you are getting spam via the mailing list? Did you only look at the From field, or also at the Received fields? They are definitely sent via the list: 1) They are prepended by [Gimp-developer], which I doubt a virus would do by itself. 2) Received: from lists.XCF.Berkeley.EDU ([128.32.112.242]) by BFLITEMAIL-KR2.bigfoot.com (LiteMail v3.03(BFLITEMAIL-KR2)) with SMTP+id 24Oct2003_BFLITEMAIL-KR2_176922_3827684; Fri, 24 Oct 2003 10:53:27 -0400 EST /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Undo shortcut
On Sun, Sep 21, 2003 at 11:22:46AM +0200, David Neary wrote: Are there any objections to this keymap change? Why not Ctrl-Z, which is faster and which almost everybody knows already? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On Wed, Aug 20, 2003 at 03:52:09AM +0200, Daniel Egger wrote: The IEs had troubles until somewhen (haven't checked for quite some time). Also the smaller homegrown browsers did, probably also the old GIMP helpbrowser. And I'm not sure about lynx and w3c either. Usually one doesn't notice because ASCII is directly representable in the lower 7 bits UTF-8 and what more does a good American citizen need? :) FWIW, I just checked -- the latest version (as of Debian unstable) of lynx can handle the UTF-8 on my page correctly, w3m can't. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XCF
On Fri, Aug 15, 2003 at 01:57:35PM +0200, Raphaël Quinet wrote: There is unfortunately one thing that most of these filesystems have in common: they are designed to store their data in a partition that has a fixed size. If you create such a filesystem in a regular file, you have to pre-allocate the space that you will need for storing your data. Unless, of course, you simply re-use the filesystem, and make the file a folder instead of a file. It has its definite disadvantages (what do you do if somebody messes with the case in the filenames, or 8.3 mangle them?), but I kind of like the idea. :-) (We've discussed this earlier, though. :-) ) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote: asm(movq %0, %%mm1 : : m(rgba8_alpha_mask) : %mm1); breaks on the second %mm1; I don't think there should be a % in the list of clobbered registers. What's worse, I don't even think most versions of gcc know about MMX registers at all (I might be mistaken, though :-) ) and thus you'd need to simply clobber the entire FPU stack (which the MMX registers get aliased upon). /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
On Wed, Jul 09, 2003 at 11:23:57AM +0200, Sven Neumann wrote: The information about the files that are installed in the user directory is about the most important part of this dialog. The installation log may be unneeded in case of success but I don't think we should just drop a number of files in the user directory. Unlike the GNOME developers we don't expect our users to be stupid. We put a lot of effort into writing user-editable configuration files. We try to document what the user can do with her personal gimp directory. The user installation dialog is an important part of this. It shows the user that there are files to manipulate, directories to add to, things to look at it. Hiding this information would not improve anything. What about Welcome to the GIMP! Configuration files has been installed into [wherever they were put]. You may want to take a look there; there are plenty of possibilities for configuration. (or something along those lines). I agree that the first-time installation should be shortened -- most users simply don't need an exact DPI setting for their screen, and having to go out searching for CDs or whatever is perceived as annoying. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
On Thu, Jun 19, 2003 at 09:44:01PM +0200, David Neary wrote: I'll get the ball rolling: 2.0 1.4. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Setting Up Wilber
On Tue, Jun 17, 2003 at 02:48:17PM +0200, Raphaël Quinet wrote: Also, the compatibility with Netscape 4.x is a big showstopper from my point of view: there is still a significant number of people visiting www.gimp.org who are using NS4 and who may not be able to switch to another browser (this last point is quite important IMHO). Are there any real numbers on this? Last time I checked the sites I'm administrating, the NS4 share was down to _0.25%_. Is really gimp.org that much higher up? (BTW, is the site viewable in NS4 with CSS support turned off?) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Setting Up Wilber
On Tue, Jun 17, 2003 at 10:24:51PM +0200, Raphaël Quinet wrote: I hope that the number of Netscape 4 users has decreased since then, but it is likely that there are still more than a couple of them visiting www.gimp.org. I had a quick look at the logs without making a full analyzis and I only saw 15 unique IP addresses using Netscape 4 yesterday (excluding my own requests when I took the screenshots). But this seems to vary very much from day to day. Then, is it really worth it to keep kludging backwards compatibility for a five year old, not-at-all standards compliant, fading browser? Given that it can even be made to work with CSS turned off? :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
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 color information. I think this should hold for blur as well. And from that point of view, no pixel with alpha zero should ever contribute color information. How do you propose this being implemented, ie. what value would you plug into the IIR filter GIMP's blur is based on, for a pixel with alpha != 255? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
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 impulse response on the convolution kernel. And so, if you're blurring with some transparent area, it's equivalent to blurring with black? Doesn't make sense to me -- or am I missing something? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Image Size Limits
On Fri, Jan 10, 2003 at 05:13:31AM -0600, Kevin Myers wrote: Yes, some of these images exceed 200ft in length. You may be wondering what they could be: images of well logs for oil and gas wells. These are essentially strip chart (graphical) recordings of various physical properties taken over the length of the borehole. Are you sure you want to use GIMP to work with this sort of things anyhow? What really do you want to do to them -- are you sure ImageMagick wouldn't be a better choice for most operations? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu - Batch Mode Problem
On Thu, Dec 19, 2002 at 10:57:19PM -, [EMAIL PROTECTED] wrote: I have already gone down that path and the image quality of the scaled images is not up to the quality that client wants. However, I can make a better, smaller image using Gimpnow I just need to make it completely automated. If you can't make an image in ImageMagick that is at least as good as what you get from The GIMP, you're doing something wrong. Have you tried specifying what kind of filter you want to use? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu - Batch Mode Problem
On Thu, Dec 19, 2002 at 11:29:08PM -, [EMAIL PROTECTED] wrote: That's what I thought as well...but the scaling with imagemagick was causing pixelation. Scaling up or down? With which filter? (You're sure you resampled and not did a simple quick rescale, right?) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: floating point (was: Re: [Gimp-developer] RH on Film Gimp andGIMP)
On Wed, Dec 04, 2002 at 10:49:05AM +0100, Tino Schwarze wrote: I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady. The point is probably to be allowed to go below 0 or over 1 -- you might not always want to work in a clamped range, like fixed point does. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Floats (was Re: [Gimp-developer] Dreamworks, etc.)
On Mon, Nov 04, 2002 at 07:52:05AM -0600, Stephen J Baker wrote: It might be interesting to consider doing some of the work of compositing in the graphics card - where the hardware supports it. The latest generations of nVidia and ATI cards have support for full floating point pixel operations and floating point frame buffers. If you stored each layer as a texture and wrote a 'fragment shader' to implement the GIMP's layer combiners, you'd have something that would be *FAR* faster than anything you could do in the CPU. Note that you still have: - Texture upload issues (a lot of data have to go to the card every time you change a layer, think previewing here) - Texture _size_ issues (most cards support `only' up to 2048x2048) - Fragment shader length issues (okay, the NV30 and Radeon9700 both will support a lot longer shaders than you have today) - Limitations on the number of textures (Radeon9700 has maximum 8 texture coordinate sets, and 16 textures... for GIMP use, one would probably be limited to those 8, though). - Some of GIMPs layer effects would probably be quite hard to implement in a fragment shader (simple blends etc. would be okay, though) - Problems with internal GIMP tiling vs. card's internal swizzling (if one settles for OpenGL, which would be quite natural given that GIMP is most common on *nix-based systems, one would have to `detile' the image into a linear framebuffer, _then_ upload to OpenGL). Now, none of these are probably _real_ show-stoppers -- but I still think implementing this would be quite difficult. I'm not really sure how well GIMPs internal display architecture would work with this either. That being said, it could be an interesting project :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Floats (was Re: [Gimp-developer] Dreamworks, etc.)
On Mon, Nov 04, 2002 at 04:34:26PM +0100, Sven Neumann wrote: well, if you could come up with the detailed specs of these sexy new graphics cards we could certainly consider to use these features. However judging from my experience as a DirectFB developer I'd say there's not much chance that the hardware vendors will give away these details unless you sign a pile of ugly contracts that effectively forbid to use the knowledge in an open source project. Umm... Both ATI and nVidia document their OpenGL extensions quite well. You'd definitely implement a system like this using OpenGL (or D3D if you wanted to do something Windows-only, but most likely you don't :-) ). Hopefully, there will be a unified fragment shader extension quite soon, too -- ATM you'll have to write one backend per card. :-( /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Floats (was Re: [Gimp-developer] Dreamworks, etc.)
On Mon, Nov 04, 2002 at 04:51:01PM +0100, Sven Neumann wrote: Hopefully, there will be a unified fragment shader extension quite soon, too -- ATM you'll have to write one backend per card. :-( a unified extension to what? To OpenGL. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] linux-graphics-dev
On Sat, Nov 02, 2002 at 06:28:11AM +, Tor Lillqvist wrote: Does GIMP use the X clipboard at all, BTW? I think the Windows version uses its internal clipboard, at least (which is quite annoying :-) For text or images? Annoying that it does, or doesn't? It uses the Windows clipboard for text when you use the normal Control-C, V and X keys. Would you prefer it not to? For images. It's very annoying at times that it doesn't... (The problem is a lot bigger under Windows than on Linux, since I don't normally cut-and-paste image data into other programs on Linux.) Images have to be copied to/from the clipboard using the Edit:Copy to Clipboard and Paste from Clipboard menu entries. (Which you can of course bind to keyboard shotcuts if you like.) Hmm, very useful. Thanks. I was only aware of the Import - From clipboard menu entry. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] linux-graphics-dev
On Fri, Nov 01, 2002 at 05:11:42AM +, Nick Lamb wrote: * Image formats for X clipboard [User hits 'Edit/Cut' in Gimp and then 'Edit/Paste' in kWord] Does GIMP use the X clipboard at all, BTW? I think the Windows version uses its internal clipboard, at least (which is quite annoying :-) ). /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Recording a GIMP Script
On Wed, Oct 16, 2002 at 06:56:35PM -0500, Kevin Myers wrote: Has anyone given any consideration to implementing a feature in GIMP that would allow a user to create a script by recording their interactive actions? Something like that would go a long way towards helping folks get off the ground with the development of new scripts much more quickly, by providing some initial boilerplate that is close to what they need and could be much more easily modified to produce the desired result than by starting to write a script completely from scratch. It was discussed here some while ago -- somebody suggested that the best thing to do would be a `reverse PDB' of some sort, where one could interface to different back-ends (ie. for Perl-Fu, Script-Fu, some XML language etc.). As far as I know, no work has been done on it after the discussion died at that time. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Format of GIMP gradient files
On Thu, May 30, 2002 at 02:25:04PM +0200, David Neary wrote: Really? In 1.2, it appears to be this... fprintf (file, %d\n, num_segments); for (seg = grad-segments; seg; seg = seg-next) fprintf (file, %f %f %f %f %f %f %f %f %f %f %f %d %d\n, seg-left, seg-middle, seg-right, seg-r0, seg-g0, seg-b0, seg-a0, seg-r1, seg-g1, seg-b1, seg-a1, (int) seg-type, (int) seg-color); Why the huge change? That's hardly a huge change from the original, is it? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xtns?
On Tue, Mar 12, 2002 at 01:07:47AM +0100, Branko Collin wrote: So, if you have not answered this before, why is Xtns called Xtns? Shorthand of extensions? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Menus, keybinding et al, first draft
On Fri, Feb 22, 2002 at 03:22:58PM +0100, Guillermo S. Romero / Familia Romero wrote: I have been moving menu things around, and proposed some extra keys, but did not get into tools keys (make circle for ellipse select and such). Maybe they should get a config area too? While we're at it, could somebody make sure keyboard shortcuts are better _documented_ in Gimp 1.3 than it was in 1.2? All tools, for instance, should list the appropriate keyboard shortcut (if any) in the tool tip. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug selection (swatters ready!)
On Fri, Nov 30, 2001 at 05:27:26PM +, Dave Neary wrote: 12582 http://bugzilla.gnome.org/show_bug.cgi?id=12582 NEW jpeg preview makes gimp's open layers dialog segfault This is a fairly long-running jpeg-based bug. Is this a libjpeg issue, or is there something we can do about it? libjpeg -- when we first discovered the bug, I was able to reproduce exactly the same bug with cjpeg. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.3.0
(Should perhaps take this off the list?) On Tue, Nov 13, 2001 at 07:28:05PM +0100, Michael Natterer wrote: loading files (in any format) works absolutely fine here. what kind of errors do you get? I open a file (tested PNG, JPEG and BMP), and get the error Image resolution is out of bounds, using the default resolution instead. Then, a window that appears to be properly-sized (given the resolution in the image file) pops up, but instead of containing the image data it's just empty. Oh, I just found out what's going on -- the only layer in the picture suddenly has an opacity of 2%. If I open the Layers dialog and increase the opacity, the image appears to work as usual. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 06:06:19PM +0200, Guillermo S. Romero / Familia Romero wrote: Maybe next version should have Wilberpy as helper. The concept image was nice: I see you want to draw a straight line. Or rather: I see you erase. Let me erase the rest of the image for you, then save. *g* /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On Thu, Jun 21, 2001 at 12:28:30PM +0300, Tuomas Kuosmanen wrote: I am more concerned about the all other options on the JPEG dialog, I never use anything else than the compression slider. Of course this is partly because the plugin used to crash if I moved the other ones .. :) I forwarded a received patch for making the dialog tabbed once (and in general cleaning it up), but it never got accepted. I personally have no clue what Restart markers or DCT method of Fast integer means in practice. So maybe someone who knows can look into this, and try to think what options are really necessary, and if there is really a point in showing some of them to the user, how to label it so you dont need to be a member of the Join Photographic Experts Group to know how to use the save dialog :-) Good point -- now personally, I think I use everything except Restart markers nearly _every_ time I use the JPEG filter, but then I added this crap ;-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On Thu, Jun 21, 2001 at 10:48:16AM +0100, Roel Schroeven wrote: What about a button Advanced options, which toggles the visibility of the advanced options? The initial state can then be specified in gimprc. That might work too, but the tabbed approach has the advantage that it also makes the dialog box look and work better on smaller screens. /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On Wed, Jun 20, 2001 at 12:21:57PM +0200, Branko Collin wrote: What would be nice though, and I hope I am not asking for something that already exists, is a web export filter that shows previews and file sizes of the same image in different formats. I've seen shareware programs for such things, and I considered implementing it in GIMP once, but I wrote the JPEG previewing functionality instead, which I find quite a lot cleaner and simpler to use (now, the _code_ sucks, but... ;-) ). :-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
