Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say OK. After which you have to (comparatively) clumsily have to re-adjust it. If the underlying data representation was HLS rather than RGB, doing this would not be ludicrous - it would be expected. OTOH, if the underlying representation WAS HLS then doing something like taking all the green out of the picture - then putting it back without affecting the hue would seem ludicrous. While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people. It's certainly unexpected - but it's useful. I would rather hide that widget from Joe Public to avoid confusing him than to unnecessarily destroy valuable data. Let me say this one more time: If GIMP produces truly undefined data where Alpha is zero - then GIMP will become utterly useless for painting texture maps for 3D graphic applications. That's DEVASTATING to a large number of your users. --- The second law of Frisbee throwing states: Never precede any maneuver by a comment more predictive than Watch this!...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Stephen J Baker wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say OK. After which you have to (comparatively) clumsily have to re-adjust it. If the underlying data representation was HLS rather than RGB, doing this would not be ludicrous - it would be expected. OTOH, if the underlying representation WAS HLS then doing something like taking all the green out of the picture - then putting it back without affecting the hue would seem ludicrous. (Sorry - that should have been ...putting it back without affecting the RED would seem ludicrous.) --- The second law of Frisbee throwing states: Never precede any maneuver by a comment more predictive than Watch this!...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet wrote: On Fri, 12 Dec 2003 14:41:08 -0600, Stephen J Baker [EMAIL PROTECTED] wrote: MIPmapping works by creating successively reduced resolution images - each (typically) half the resolution of the previous one. When a MIPmapped image has alpha, this down-filtering produces semi-translucent pixels in areas of the image that were formerly completely transparent. I don't follow your argument. Even the simplest downsampling techniques (nearest neighbors, no linear or cubic interpolation) work by combining the weighted values of the pixels (all colors are weighted by their opacity). So the relative weight of a fully transparent pixel is zero, which means that if you are filtering four pixels (half resolution) and three of them are transparent, then the result will only have the contribution of the fourth pixel, with a lower opacity (1/4). The fully transparent pixels will not contribute to the downsampled result. 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. If my down-filtering (for MIPmaps) worked as you suggest then pixels with (say) 50% alpha wouldn't carry as much weight as they should. So, no - we cannot do as you suggest. The standard OpenGL MIPmap generator does not do as you suggest it should. If GIMP were to do something like (say) making all the transparent pixels be solidly black, you'd see a dark halo. This is a really common problem and GIMP is the tool that saves you. I don't see how this would happen, except if the downsampling filter would be incorrectly processing the R, G, B and A values independently (without weighting by A), which is obviously incorrect. Well, it's not obviously incorrect unless you assume that RGB's are pre-multiplied by alpha. Whilst I might be pursuaded that pre-multiplied Alpha was a good idea, I (and everyone else who works with realtime hardware) do not have a choice in the matter since that's how the API's are specified - and how the underlying hardware is implemented. There is actually a GOOD reason to use post-multiplied alpha - and that is that pre-multiplying RGB by alpha destroys information that might come in useful later on. If you can choose to postpone the destruction of data - then that's generally a good thing to do. If some other software has the same bugs as some of these plug-ins, I don't think that it is the GIMP's job to make sure that the software works despite its bugs. But it's not a bug to choose to post-multiply alpha - it's a design choice. I would argue that if GIMP were to uniformly support post-multiplied alpha, then any application that required pre-multiplied alpha could trivially fix it. However, for applications (including **ALL** realtime/interactive 3D applications) that absolutely must have post-multiplied alpha, giving us the data in the pre-multiplied form makes GIMP virtually unusable. Please don't do this! Of course we should not break it on purpose if we have no good reason to do it (i.e., if there is no other benefit in clearing the transparent pixels) but we should not be prevented from improving the GIMP even if that triggers some pre-existing bugs in some other software. We can implement specific workarounds if someone thinks that it is worth it, though. I strongly implore you to retain post-multiplied alpha. --- The second law of Frisbee throwing states: Never precede any maneuver by a comment more predictive than Watch this!...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
The value of the RGB of transparent pixels is crucial for applications involving realtime MIPmapped textures...pretty much all 3D games for example. MIPmapping works by creating successively reduced resolution images - each (typically) half the resolution of the previous one. When a MIPmapped image has alpha, this down-filtering produces semi-translucent pixels in areas of the image that were formerly completely transparent. At these locations, the colour you see will be a down-filtered version of the higher resolution image. It it therefore ESSENTIAL that the pixels in the areas outside of the opaque parts of the image can also be painted - and have user controllable RGB values. What GIMP does now is just fine - what might be nicer would be some kind of toggle to temporarily show the entire image as opaque (without actually destroying the value of the alpha buffer). If GIMP were to do something like (say) making all the transparent pixels be solidly black, you'd see a dark halo. This is a really common problem and GIMP is the tool that saves you. --- The second law of Frisbee throwing states: Never precede any maneuver by a comment more predictive than Watch this!...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote: This is what I mean by a standard that people can have confidence in -- people should trust that if their program writes good XCF's that a good program will be able to read it. Right! If a program writes GOOD XCF... As long as a program follows the rules, TIFF is compatible. If you break the rules, all bets are off... The difference is that TIFF is read and written by dozens of ad'hoc software packages. Some use 'libtiff' - but most do not. If you look at a format like PNG, hardly anyone reads and writes it using their own code - almost everyone uses libpng - so there are no problems with PNG compatibility. So, I think what is needed to make a reliable file format is to provide a well written library for reading and writing the files that's freely available and properly maintained on every modern platform FROM DAY ONE. If you then write in the specification document something like: You are strongly encouraged to use the standard file reading/writing library rather than writing your own ...then better still. I don't think it matters very much how the format is specified. The reliability and transportability of the resulting files depends mostly on the quality of the support library. Another problem with TIFF is that it's easy to extend. That sounds like a good idea - there are ways to simply ignore tags that your program doesn't understand - so how bad could that be? Well, if you have programs that invent tags that say things like What follows is a block of pixels in MacPaint format, or If this tag is set, the pixels are stored bottom-to-top instead of top-to-bottom - then ignoring a tag you don't recognise results in a very screwed up image. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-21 at 1016.13 -0400): At 11:42 PM -0700 8/13/03, Manish Singh wrote: Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH added this to filmgimp since they had established this format in their workflow with other tools already. Why would you only use half of a 32bit float?? That reduces your accuracy/precision and makes you incompatible with the rest of the world doing floating point imaging. nVidia graphics hardware uses half-float - it's useful where bandwidth is a premium - such as downloading high dynamic range images into graphics hardware at realtime rates - and in a lot of cases, a half precision float is still very useful. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Austin Donnelly wrote: How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. So it's somehow preferable to come up with our own wierd-ass float format and make life equally hard for everyone? By far the vast proportion of modern machines have IEEE float - so let's make life easy for the majority. The minority need a conversion routine no matter what we do. The last machine I used that didn't have IEEE float (some wierd Hitachi microcontroller) had convenient library functions to interconvert between it's native format and IEEE. The only other alternative is to use a storage mechanism for which there is universal conversion support - but the only format that fits that bill is ASCII - surely we aren't contemplating that for bulk image data? Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
Sven Neumann wrote: I never understood the reasoning for this discussion anyway. IMHO the format that Nathan suggested seems like something from the dark ages of file formats (where TIFF and the like originated from). I haven't heard a single good argument for it except that it can do most of the things that the XML/archive approach can do. There was however nothing mentioned that it can do better. Or did I miss something? I think there are three separate problems to solve here. 1) How to store the compositing tree (and other meta-data) that GEGL needs. 2) How to store bulk texels in a variety of data formats (byte, int, float, etc) and in a variety of colour representations (RGBA, CMYK, etc). 3) How to put together (1) and potentially many (2)'s into a single file. It seems to me that XML was just *made* to do (1) nicely. It's also rather nice that this is human readable and the parsers for it are likely to be easy. XML is nice and modern and there are loads of supporters of it. I don't think this should even be a matter of debate - it's *so* obvious that this is the way to go. (3) Looks a lot like taking an XML file and a bunch of simple images and stuffing them together into an archive. There are lots of choices for the archive format - and it probably doesn't matter which one you choose. I rather like the idea of using 'ar' - but that's a UNIX-centric viewpoint. Something like 'zip' with it's ability to compress *and* archive multiple files into one file would be good. But the obvious OpenSourced candidates (bzip2 and gzip) don't do that. Tar+Gzip would work though. The only argument I heard against it was that tar doesn't allow arbitarily long filenames...that's irrelevent because the XML code at the top of the archive can map long layer names into short sub-image names for the benefit of those who care. Bulk image storage (2) seems a bit more problematic. It would be nice to use a standard file format so that you could unbundle a GIMP 'archive' into an XML file and a bunch of standard images, operate on them individually with other tools that know nothing about GIMP, GEGL, etc - and then put them all back together again with the archiver. So what's needed is a standard (and hopefully rather simple) image file format. However, we don't seem to be finding any nice modern, robust, well-known and portable formats that can do bizarre things like full floating point CMYK. I think you could resolve the issue of how to store bulk image data by not making a decision! Allow any of the file formats that GIMP uses to be used to represent a layer in the total image archive. The XML file can tell us what format each sub-image is stored in...and GIMP already has loaders for gazillions of file formats. That way, we could use (say) PNG for storing run-of-the-mill RGB images, and invent custom formats (or TIFF with tags or whatever) for storing the bizarro stuff. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Carol Spears wrote: However, I read recently about artifacts appearing in compressed pngs, so this might not be the miracle fix I had hoped for. !!! Where did you see that? PNG uses a lossless compression scheme - if there are 'artifacts' in the image that were not there when the image was given to the PNG library then that is an extremely serious bug!! I find this very hard to believe. However, there are people who take an image (eg from a digital camera) in JPEG (which is lossy and has artifacts) and CONVERTING them to PNG and then seeing artifacts. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Leonard Rosenthol wrote: At 8:26 PM -0400 8/13/03, Carol Spears wrote: What about mng? It contains png and has layers and comments. Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.) colorspaces (among other things) out of the box... Has anyone considered going to the PNG maintainers and asking for these things to be included? The GIMP project is not without influence in the OpenSource world. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Alan Horkan wrote: I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all. I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward. I like the 'benevolent dictator' model for OpenSource management - it works well in so many projects - ranging from tiny three man projects right up to the Linux kernel itself. It's really hard to come to a firm decision in a timely manner in an environment where everyone's voice counts equally...doubly so if things get ugly. The art is to find a dictator who actually *is* benevolent. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
Sven Neumann wrote: Excuse me?!?! JAR is used by every Java implementation in existence, and since it is 100% compatible with ZIP, means you have all of those implementations as well. Java is not exactly what I would call well established, but that's not a relevant argument here. One issue we should at least think about with JAR is that since it *is* the JAVA library mechanism, there is perhaps a risk of allowing virus writers to attach bits of JAVA executable in what *appears* to be a GIMP image. This is the kind of thing that email virus writers *love*. Whilst I can't quite see how this would be a problem, it might be better to just avoid the risk. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp icons
On Mon, 13 Jan 2003, Aseem Agarwala wrote: But, I can't seem to find images for these icons in the source distribution. I've found the 'cursors' directory, but these are for the cursors, and the tool buttons themselves have slightly different images. Could someone point me to these images? Take a Screen dump/snapshot? (GIMP will even do that for you!) Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Gimp FAQ: Call for questions
On Thu, 19 Dec 2002, Michael J. Hammel wrote: Thus spoke David Necas (Yeti) IMHO novice mode (if ever implemented) should restrict the things user can do to some sane set (simplifying the interface), and not try to turn the Gimp into Eliza Most of the time that I've heard of problems like this it has been when the wrong layer has been selected or a layer with transparency is in use and the user doesn't understand why you can't draw in a transparent area. Novice mode might be as simple as forcing users to use a single layer that doesn't have transparency enabled by default, allowing them to learn the rest of the programs features without complicating their experience with layers. In my experience, it's most frequently been when some kind of select/cut/paste operation has created an un-anchored extra layer. In that case, the novice (who realises that layers are a complication - and is ignoring them for now) has the implications of layers forced upon them. Just a thought. I'm not convinced that a novice mode is worth it though, for all the same reasons mentioned already (like every novice will think something in novice mode is still to difficult to understand). I dislike the idea of novice mode too. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: alpha vs. transparency / translucency
On Wed, 18 Dec 2002, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2002-12-18 at 1711.13 +0100): I agree with Alan and Raphaël (see the bug report) when it comes to the What/How statement. I can see how the term alpha may be unclear to new users, but I think it would be a pity to replace it all together, as this might cause users who are accustomed with the term to be confused. Another How: My image is RGB, how do I make it RGBA? :] Side effect, will be RGBA be named RGBT everywhere (in user visible interface)? Is not a bit silly to start renaming basic concepts of a field with something else (aka causing differences with reference docs that existed long time ago)? Just wondering. I agree - that it would be better to consistently use the more modern, technical term 'Alpha' - and provide some simple cues to new users that 'Alpha' and 'Transparency' are related. Technically, the meaning of 'Alpha' is completely the opposite of 'Transparency'. An Alpha of 1.0 (Lots of alpha) means 'opaque' and an Alpha of 0.0 (no alpha at all) means totally transparent. Hence, Lots of Transparency and Lots of Alpha have opposite meanings and the terms are NOT completely interchangeable. Perhaps in the couple of places in the higher levels of the GIMP menu where you can access alpha, it would be better to say 'Alpha (Transparency)' - so that newbies would come to understand that the terms are related. Having established that relationship in their minds, you can drop the '(Transparency)' part in deeper menus and dialogs. You could also add a 'Tip of The Day' that explains this. As an alternative, you could talk about 'Opacity' as a synonym for Alpha - but there are definitely contexts where that would be confusing too. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On Fri, 29 Nov 2002, Sam Richards wrote: I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for High Dynamic Range imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images. Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future. I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ 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, 4 Dec 2002, Tino Schwarze wrote: On Tue, Dec 03, 2002 at 06:39:16PM -0800, Jonathan Cohen wrote: We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing. 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. For high dynamic range rendering. The sun is like a billion times brighter than a candle - and a candle is a thousand times brighter than the dimmest thing a human eye can see. Taking a 'true' rendition of the world needs more dynamic range than even a 32 bit integer. However, we don't need to measure the brightness of the sun to the precision of the dimmest thing we can see. So we DON'T need the precision of a 32 bit integer. Hence a 32 bit float is a more reasonable format. It's also the format that modern graphics cards are beginning to support (and will increasingly support in the future). Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Floats (was Re: [Gimp-developer] Dreamworks, etc.)
On 4 Nov 2002, 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. The fragment shaders is a part of the OpenGL extensions for these boxes and are fully documented. For nVidia hardware, you program them in a C-like language called 'Cg'. However, it would probably be wiser to wait for the release of OpenGL 2.0 which will have a portable C-like shader language. 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. That is not a problem in this case...although some of the other issues mentioned earlier might be. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Floats (was Re: [Gimp-developer] Dreamworks, etc.)
On 4 Nov 2002, Sven Neumann wrote: Hi, Steinar H. Gunderson [EMAIL PROTECTED] writes: 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. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dreamworks, Shrek, and the need for 16 Bit
On Fri, 1 Nov 2002, Marc wrote: Just FYI (I have no specific goal with this mail ;): I met some guy from Dreamworks (Shrek) at the LWE in Frankfurt, and he told me that their whole rendering infrastructure is 8 bit, including intermediate results (so the whole of Shrek was done at 8 bits, with a later dynamic adjustment of the results into the necessary range). He also told me that they want to go to 16bits, for 8 bits is only ok for exclusively-rendered movies, that 8 bit intermediate results do hurt a lot, and that they do use gimp, for some unnamed adjustments and especially creating textures, where gimp works extremely well ;) And finally he told me that the need for 16 bit and floating point is there in many but not most cases, so one _can_ get along without it, at leats for rendered scenes. It makes a lot of difference whether those 8 bits are before or after gamma correction. 8 bits pre-gamma is definitely not enough for some things - 8 bits post-gamma should be enough for most applications. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistentlylicensed]
On Wed, 29 May 2002, David Neary wrote: Raphaël Quinet wrote: On Tue, 28 May 2002 14:52:53 -0700, Ben Gertzfield [EMAIL PROTECTED] wrote: Howdy GIMP folks. Here are some points in the licensing of GIMP that need to be addressed. Specifically, there's a lot of code that requires that the authors be mentioned in the documentation, but there is no mention of them anywhere. Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. Why is giving credit to an author incompatible with the GPL? Because GPL gives the end users the free right to modify and redistribute so long as they obey the GPL license. They can't freely modify it if some of the comments or parts of the documentation can't be deleted or changed because they are required as adverts. Admittedly, it's hard to imagine why you'd urgently need to delete such a thing - but GPL doesn't go into reasons, it just grants users blanket rights to modify. For reasons not to start subtly modifying the GPL, read about all of the horrible things that are happening to Wine, WineX and ReWind! If they'd used an unmodified GPL from start to finish, none of that would have happened. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pie Menus
On Sat, 27 Apr 2002, Tino Schwarze wrote: On Fri, Apr 26, 2002 at 04:09:20PM -0600, Nathan C Summers wrote: Hmm, maybe we could as an advanced option make the menu button on the canvas's upper left corner be a pie menu, and make the menu items completely configurable. I guess that could work. Pie menus only make sense if you can access them really fast. Trying to hit a relatively small button is not an option... The whole point is that the menu should pop up right under the mouse pointer. If you have to move the mouse to get to the pie menu then you have already destroyed it's greatest feature. If this is done, it has to be an optional replacement for the standard GIMP right-mouse-button popup menu. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Le mar 09/04/2002 à 15:42, Sven Neumann a écrit : - Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea. I've seen this on a number of graphics packages (Maya for example) and it does work quite well. The idea is that when you Right-click in the image to pop up the menu, instead of having just one honking great list of stuff, you split that menu into a number of catagories (4 or 8 typically) and scatter those catagories as little icons or perhaps text labels in a ring around the mouse pointer. Moving the mouse a short distance in the requisite direction pops up either a new (short) menu - or (more likely), drops you into a new ring of catagories. Releasing the mouse activates whatever thing the mouse is over at the time in the usual way. The idea is that a right-click followed by a short (and easily memorized) gesture gets you to the menu item you want in less time than scrolling down that l-o-n-g menu. It's pretty logical actually. Encoding the function you want as a 1 dimensional list requires EITHER tiny fonts and accurate mouse positioning OR large fonts and huge mouse movements. Neither are good for speedy menu item selection. Using (in essence) a 2 dimensional menu allows for larger, clearer fonts with less distance to travel to get to the entry you want. It also seems that people are somehow able to 'learn' the gestures to get to certain items quickly without even reading the menu's. It's like changing gear on a stick-shift car - you don't even have to think about the actual motion. Right-Click then move up then right then up again seems easier to get into muscle memory than Right-Click, move down 1.3cm then move right then move down 2.6cm. I think the DISADVANTAGE of this scheme is that the beginner doesn't see a clearly presented *list* of options - this is perhaps a problem - but it could be a configuration option to select which style of popup menu you want - and in most packages that use these gesture menu's, there is also a standard menu containing all the options in the usual place at the top of the window. I saw a demo of one of these systems where a joystick was used to select the menu item - with the idea that you could mouse with one hand and pick menu's with joystick with the other. Dunno about that - I like my hotkeys. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
On Fri, 5 Apr 2002, Kelly Martin wrote: The G in GIMP stood, once upon a time, for General. It was changed to GNU at Richard Stallman's insistence (but with the consent of SP, so it's not like it was completely hijacked). See the SP interview at http://www.xach.com/gg/1997/1/profile/1/. Yet another case where Stallman's zealous efforts to push his brand name on people was successful. How long before we have GNUburgers and GNUfries with our GNUlunch? :-) IMHO, we should say something in the first page of the manual and on the front page of the web site like: When we talk about Linux, we are talking about a combination of the Linux kernel and a large collection of tools contributed by a large number of individuals and some significant groups such as GNU, Xfree and BSD. Since we cannot credit everyone in every sentence, and for the sake of brevity, we call this system Linux. ...that should be enough to keep it clear. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
On Sat, 6 Apr 2002, Tomas Ogren wrote: On 06 April, 2002 - Simon Budig sent me these 0,7K bytes: Branko Collin ([EMAIL PROTECTED]) wrote: Should we change these instances to GNU/Linux? We should change it - to Unix. I guess that at most places Linux is simply wrong, because there is not really anything Linux specific in the GIMP. So the whole discussion is kind of pointless. .. and gimp runs on Windows too.. ;) Sure - when you are not referring to Linux *specifically*, you should use whatever more-generic term is applicable. That's not the issue though. The question is when you *are* talking specifically about Linux, what do you say? UNIX is a registered trademark though - you can't legally use it to refer to Linux. You can talk about UNIX-like operating systems - although that's rather a fuzzy term. Microsoft used to claim that WinNT was UNIX-like. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
On 4 Mar 2002, at 4:10, vio wrote: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Wouldn't it make more sense to push Gimp's scripted rendering features into the browser (as a plugin) and send just the script to the user's machine for interpreting? It would presumably be a LOT less bandwidth than sending out an image...particularly if you are doing animations. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Suggestions for Clone tool.
I have a couple of suggestions for options for the Clone tool: 1) At present, the source data for clone is the image as it was before you clicked on the mouse. It would be nice to have an option to take the *current* state of the image instead. When you are erasing some feature from a photo by stealing a bit of background from somewhere nearby, it's frustrating to accidentally pull in a part of the object you already erased. 2) It would be *really* cool if clone could 'mirror' the direction of the brush strokes when picking up colour from the image...so (optionally), as I move the brush to the right, the clone's '+' cursor would move to the left - and vice-versa. An option for an up/down mirror and/or an arbitary rotation of the brush coordinates would be useful too. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Suggestions for Clone tool.
On Mon, 25 Feb 2002, Jim Lokken wrote: I saw a message on the archives list (I wasn't subscribed and went through that procedure but I am not sure I got it right yet - so please don't abuse me) about Suggestions for Clone tool. I then went back to the referenced thread from October. It talked about some clone tool dialogs changes among some other ideas. How about using a shift-click type option to use current new layer versus the previous layer. This type of clicking is used for slightly different results in selections and may fit well here. CTRL-click for setting a point on previous image, SHIFT-click for using the resulting image. I was thinking more in terms of a 'Preferences' option. I can't think of a good reason for wanting it to work the way it does now - but evidently someone does or it wouldn't have been written the way it is. That sounds like a 'Preference' thing I could set once and forget about. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cubic interpolation vs. Genuine Fractals
On Tue, 15 Jan 2002, Tino Schwarze wrote: On Tue, Jan 15, 2002 at 12:43:43AM -0800, [EMAIL PROTECTED] wrote: What does a Windows program like Genuine Fractals do that Gimp cubic interpolation does not do, when I'm upscaling photographs for printing to 8x10 and beyond? What are you expecting by upscaling pictures? Why do you do that? It will definitely not improve quality as there is no gain in information. It might improve quality if you have some kind of printing mechanism that upscales by pixel replication or something. Then upscaling in GIMP with bicubic interpolation might very well improve the quality of the resulting image. Agreed you cannot add useful information - but having a fuzzy image is generally better than having a pixellated image. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request for 1.3
On Mon, 7 Jan 2002 [EMAIL PROTECTED] wrote: The only feature I miss when I use GIMP is that of Photoshop's brush cursors. I'll second that one. It's a pain not knowing where your brush will land - ESPECIALLY because when the image is zoomed in or out, the brush size can be much larger or smaller than you expect. If you say 'gimp *.png' and have a bunch of images - some larger than the screen - some smaller, they can each have a different image resolution - so you tend to pick a brush suitable for a very high res image - then move over to a lower res image and discover that now you are painting with something *much* larger than you expect with very little visual cues as to what's going on. Of course, this isn't necessarily an easy feature to implement. It's not as simple as setting the X cursor to the right thing because when you are zoomed right in and painting with a huge brush, you can end up with a cursor that covers half the screen! What might be interesting would be a 'preview cursor' that shows you what the pixels would look like *if* you clicked the mouse button right then. Thanx for any consideration. Indeed. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF support added to ImageMagick
On Tue, 4 Dec 2001, Raphael Quinet wrote: On Tue, 04 Dec 2001, Marc wrote: ImageMagick has NO license. The only thing we say is: [...] In any case, my version of ImageMagick (older, 5.3.6) does have a license (in Copyright.txt). (and I think it is very much BSD-like). Right. And I was wrong in my previous comment: the license is BSD-like but without the advertising clause. So it is compatible with the GPL and therefore the code could be re-used in the Gimp if necessary. (Although it *does* mean that ImageMagick had better not be using any GIMP code to help out it's decode/display of XCF's or it'll be in breach of GPL) Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 3D painting.
Hi! I asked this question about a year ago - and the answer then was Not Yet...so I'm back again! I'm working with the PrettyPoly team on building a GPL'ed 3D modeller for Linux (and others OS's) - and one thing we are frequently asked is to implement a facility to paint onto texture maps as they are applied to a 3D model. Since we are basically lazy people and *know* how much work it is to write a halfway decent paint program, we'd like to avoid that and build a 'bridge' between GIMP and PrettyPoly so GIMP gets to do all the hard work. I use GIMP a lot bit I have very little knowledge of it's internals - and I've never even written a plugin - so please forgive my ignorance. What I want to do is to write some kind of a plugin for GIMP that interfaces to a PrettyPoly plugin via a shared memory buffer. The idea would be to have the GIMP plugin write the current image into a shared memory area that PrettyPoly reads and downloads into the texture memory of our 3D graphics card...then as the mouse is moved around the 3D image in PrettyPoly, to convert that 3D position into a coordinate relative to the texture map and send that back to the GIMP plugin (also via shared memory). The plugin would then either apply paint at that location - or (preferably) simply convey the image coordinate to GIMP and let it do the painting using whatever tool is currently selected. Hence, as you drag the mouse over the 3D model, you'd cause GIMP to apply paint at the appropriate location in the 2D image - which would then appear a little later on the 3D viewer. You'd also be able to do the simpler thing of painting conventionally onto the GIMP image window and seeing the 3D effect immediately in the PrettyPoly window. Better still would be if ALL mouse input from the 3D tool were to appear to GIMP as non-GUI-directed mouse input - so we could even rubberband selection areas and such in 3D. The latency through that process is of course a concern - but the benefits of 3D painting to our users is large and we can perhaps work to at least minimise the delay. I know GIMP uses small image 'tiles' - so probably only the changed tiles need to be passed from GIMP to PrettyPoly. It seems to me that *if* this is possible, it shouldn't actually be too hard to implement. What I don't know is: * In what form can a plugin access the GIMP image? (eg Are layers pre-composited?) * Can we really drive the mouse coordinate within the GIMP core from inside a plugin? * If not, how hard would it be to make a plugin do basic airbrush/clone/pencil/brush functionality from coordinates stored in shared memory? What is your expert take on this? Is it possible? Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
On 29 Aug 2001, Sven Neumann wrote: and IMO they should look like: ## ## # ## ## # ## ## IMO what they should look like is: # # # # # # # essentally what we do when drawing lines is we move the brush along the line and draw points in equal distances. If the point does not fall exactly on the pixel grid, it gets wider. This is bad and thin lines drawn with the pencil really look akward. A possible solution would be to implement the pencil tool totally different from the paintbrush. Instead of drawing brush pixmaps onto the canvas at equidistant spots along the line as the paintbrush does, the pencil tool could use a real line-drawing algorithm (Bresenham). This would imply that our brushes couldn't be used with the pencil tool any longer since this algorithm would only work for rounded or square pencil tips (or am I wrong here?). The problem with the 'placing overlapping brush pixmaps' approach is only really obvious at very narrow line widths. IMHO, the pencil tool should be left alone for consistancies' sake and there should be a new tool to deal with the very special case of drawing single-pixel-wide hard-edged lines. This hypothetical gadget could use Bresenham's algorithm or something like that because it wouldn't *NEED* to deal with pixmaps and need only hit pixels dead-on. I really like this idea since the old functionality of the pencil tool could be easily implemented in the paintbrush (all we'd have to do is to add a Hard edge option like the Eraser has) and having a real line-drawing tool would be a major benefit. Yes. That would work. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patents and Colormanagement: German Ministry
On Wed, 27 Jun 2001, Branko Collin wrote: On 27 Jun 2001, at 14:47, Simon Budig wrote: I just had contact to Mr. Soquat, a member of the staff from the german Ministry of Economics and Technology [1]. He is very interested in how patents are a problem for free software. Excellent! At the opening of the Linuxtag there is a chance to present the problem to a higher representative of the Ministry (5. 7. 2001, about 13.15 - 13.55). It would be great if we could collect the relevant information and find a person who is willing to present this at that time (about 5 to 7 minutes...). The history of the enforcement of the Unisys patent on LZW(?) compression would be a nice example of how free software can be hindered in something as simple as the production of the predominant graphics format on the web. I realise it is not a good example of 'obvious' things to be patented, but I am sure enough examples of that can be found. The true inequity of the Unisys patent is not 'obviousness'. It's that they waited until every web site on the planet was using GIF before they started to enforce it. That gave them the maximum chance for royalties. The LZW patent is (AFAIK) not an unreasonable one. If they had hit the very first person to use GIF with a lawsuit, we'd all have come up with a different standard and life would have been good. It's not as though GIF (or more accurately LZW) is some kind of rocket-science - it's just a de-facto standard. However, Unisys coldly sat back and waited until a few *billion* web sites were out there (and enough big companies with the money to pay them royalties and be worth suing). By then, we were hopelessly locked into GIF because it was the only appropriate standard really supported by Netscape and Internet Exporer. UniSys only acted when they were sure they could make money off the *PATENT* (as opposed to things made using the patented technology). That's just AWFUL, immoral behaviour IMHO. The law should be that if you don't defend your patent on the first occasion you see it being infringed then you should lose the right to prosecute subsequent infringements. That way, UniSys would either have fought to retain their precious technology before it became a de-facto standard - or they'd have decided to let it lapse into the public domain. That makes the Unisys patent case very different from the equally notorious Amazon One-Click thing because Amazon did the honest thing of suing the first person they found infringing it. The problem with Amazon is that an utterly *trivial* thing was allowed to be patented and only people with money stand a chance to fight the lawsuits to prove it. Non-obviousness and 'prior art' are things that the patent department is supposed to test for before the patent is ever granted - they do a terrible job of doing that. The free software community cannot afford the cost of law suits to defend against infringement suits for patents that are quite simply junk. I don't boycott Amazon because the fault there lies in the US patent office - but I *do* try to get people not to do business with UniSys because they are just immoral. These are two completely separate issues and that point needs to be made. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
