Re: [Gimp-developer] Developer Boot Camp?
Boot Camp . . . good idea. Docs . . . good idea. Let the newbie's like me (coming out of boot camp) write some of the Docs. Presently I have everything compiled and running under Ubuntu, and I am just reviewing the code to get some sort of context. It is huge. Incredible, actually. Who wrote all of this? Wow. A few comments: * It seems to work best to put the entire project (all source, and all build product) under a project folder in the Home directory. * If possible, that should include a *copy *of any external dependencies . . . with environment variables (etc) adjusted accordingly * The project ought to be able to exist in a *bubble* . . . so as to avoid confusion . . . regarding copies of dependencies that might exist in the OS. * Multiple different project versions ought to be able to exist on the same machine without stepping over each other. Note: I wrote a minimal bash script that duplicates (automates) the steps I took to get to the present state. Maybe we could expand on that idea. * If we do it right, compiling for Linux vs. Windows vs. OSx ought require no more than the flip of a switch. The Blender folks, and others, are moving in that direction. * Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know. Thanks, Steve Greenwalt (a.k.a. Acumen) 2011/1/27 Łukasz Czerwiński lc277...@students.mimuw.edu.pl Maybe just a good documentation for GIMP source is needed? Once I tried to patch TinyScheme interpreter to make it work faster. In files I was working on was almost no comments. Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Where can I help?
Where can I help? Here's an ultra-short overview of my background: * 18 years overall development experience including software engineering, team leader, and senior IT management. * Expert-level C, C++, C#, etc. knowledge. * Extensive 3D design and development knowledge (texture mapping, 3D scene rendering, lighting, etc). * Decent knowledge of file format specs for most common image file formats, as well as some experience writing apps that make in-memory (on the fly) changes to image data. * Have tried my hand at various self-invented strategies for pattern recognition within image data. * Now working, oddly enough, in unrelated areas dealing with Lean Manufacturing, Quality Systems, etc. * Have been using GIMP for certain things for about 3 years or so. * Have some extra time I could devote . . . but will wait to quantify that until I hear where you need help. * Well, there's more . . . Let me know. Thanks, Steve Greenwalt Layton, Utah ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
Thanks for the info. I have used that filter many times, and I will take a look at what you describe. When light is cast against a 3D mesh, how that light diffuses over the surface can also be affected by whether the ray caster is using vector normals, or face normals, and other things. So, triangle size might just be part of the problem. On Tue, Jan 25, 2011 at 9:56 PM, Bill Skaggs weska...@gmail.com wrote: On Tue, Jan 25, 2011 at 12:35 AM, Stephen Greenwalt stephengreenw...@gmail.com wrote: Where can I help? Here's an ultra-short overview of my background: ... Here's one suggestion that you could probably work on immediately, and would prepare you to work on other things if you are interested. Gimp has a plug-in called Lighting Effects that simulates the results of shining lights on 3D-deformed images. It is pretty fancy and sometimes gives neat results, but the rendering procedure it uses doesn't work as well as it could, because the triangles that it decomposes the surface into are too small -- you get a lot of faceting effects that a better algorithm would avoid. Plug-ins are more or less freestanding code, so it ought to be possible to improve the rendering without a huge investment of time in learning the whole architecture of Gimp -- but you would learn a substantial amount about the architecture as a side-effect of working on it. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Team Organization?
I have been reviewing Gimp / GEGL source code . . . to get familiar with everything . . . so that I have some context to understand where I might help the project. But I am operating in a void because I don't understand: - How the development effort is organized. - Is there a team leader? - What tools, etc. are being used to manage things such as: - Feature requests, bug reports, etc. - Component development. - Testing. - And all the other usual stuff. - What the development priorities are, and where programmer resources are needed. The main Gimp website says that the new priority is expansion of the GEGL engine. But, does that mean that major feature development for main Gimp app is being stopped until the GEGL engine is ready? I, for one, love Gimp but would really like to see one or new features such as: - Support for sub-layers (i.e. nesting of layers in tree-style control). - Ability to delete multiple layers at the same time, rather than one-by-one. - Layer-by-layer history . . . so that you can undo changes within the current layer only. Should I offer help in those areas? Again, I just need some context. Thanks, Steve Greenwalt ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What are the long-term plans (if any) for OS X?
On Jun 23, 2010, at 8:16 AM, Martin Nordholts wrote: I think a good first step would be to port Seashore Mac OS adaptations to upstream GIMP. I'm not quite sure what you mean by porting Seashore adaptations to GIMP. As some background, Seashore has an entirely custom-build Cocoa UI, as well as Cocoa file I/O code. It would only make sense to port these adaptations to GIMP if there was a separate branch that removed the current GTK+ UI and replaced it with a Cocoa one, unless your referring to something else :) -Stephen ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] What are the long-term plans (if any) for OS X?
Hello all- I'm currently working on Seashore, which is a Cocoa app that shares some code with GIMP. The developer that ran the project in the past left so I guess now I'm in charge of the project. I just made my first preview release (you can see it on the webpage http://seashore.sourceforge.net/) However, my understanding is the the original developer of Seashore kind of went off on his own and started this without much involvement of the people actually working on GIMP and that seems like a shame to me. I was wondering if anyone here has long-term plans for supporting the OS X platform. The reason I ask is I don't want to spend any further time on Seashore if there are serious prospects for a native Cocoa GIMP anywhere in the future; I would rather help out with that. If it does not seem like GIMP will ever run natively on OS X, and Seashore is the best we can do in terms of a native Cocoa offering, then I was wondering if anyone here had any tips or advice for working on Seashore (or even if anyone wanted to help out!). Thank you very much, I look forward to hearing from you- Best, Stephen___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC - Free Transform Tool
From: pe...@mmiworks.net To: gimp-developer@lists.XCF.Berkeley.EDU Date: Mon, 29 Mar 2010 15:37:42 +0200 Subject: Re: [Gimp-developer] GSOC - Free Transform Tool what needs sorting out is that after some manipulation the transformation frame can be any kind of shape that can be made out of 4 corners connected by 4 straight lines, including a twisted bow tie type of shape. this general shape is then clipped by the viewport of the image window, which is really a rectangle. This clipped general shape then needs to be manipulated. I still have to investigate what is reasonable for users to be able to do in these situations and how I can make this happen. Yeah, after a perspective change of close to 90deg in any one direction - even if this was actually a mistake - the frame will be rendered unusable because of the low resolution between the different handles. Given that currently you will not be able to undo just part of the overall Free Transform, this will pose a problem (Large shears will exhibit the same behaviour). One possible solution would be that transform frame would only mirror the actual transformation up to a certain threshold. Otherwise the decision could be left to the user to accept (or undo) the current transformation and start a new free transform (and thus new transformation frame). Any update on your thoughts on this? Also, can you please confirm why the transformation tool would only perform the calculation when the user goes and does something else. yeah that passage is not clear. what I mean is that what is manipulated on-screen is just a preview of the real image data: it is just a limited amount of pixels (there are only 1 to 2 Mpix on a monitor) and it will, using all the dirty tricks in the world, 'instantly' reflect the transformation made by users using the handles. even while moving the handles. the real transformation of the real pixels in memory is then done with the aggregate transformation in one pass when users go and do something else. this is the maximum fidelity contract with users. Cool, this will allow us to combine adjacent affine transformations at the end of the tool's usage to reduce the computational expense of the operations. _ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC - Free Transform Tool
From: pe...@mmiworks.net To: gimp-developer@lists.XCF.Berkeley.EDU Date: Sun, 28 Mar 2010 17:01:12 +0200 Subject: Re: [Gimp-developer] GSOC - Free Transform Tool Stephen McKeague wrote: My name is Stephen McKeague and I am very interested in implementing the Free Transform Tool in GIMP for this years Google Summer of Code, originally proposed by Martin Nordholts. The project information page seems to still be offline, so I would like to discuss the bounds of the project. yes, it would give you quite a complete overview of how I see that tool working, I hope the site can be up soon. meanwhile, try this google cache: however, last week I have updated the design of the shear and perspective transform handles and all opcities: looks really good, I love the idea and this of course triggers a big update of the spec. there are also some rough edges in the spec that need to be defined: like when the frame is partially in view, or no edge of the frame is in view. On this note, could you please clarify for me where it says, Only the visible part of the transform frame goes into the size calculations. I know the selection tool would used to define the desired area for transform but what significance would the local zoom level (for example) hold? Surely if all parts of the user selected area were not subject to the same transformation it would seem inconsistent (or did I not understand what you were trying to say)? Also, can you please confirm why the transformation tool would only perform the calculation when the user goes and does something else. I understand the angle of the tool processing an aggregate transformation, but the intro specifies that we try to enable a positive feedback loop where the result of the last transformation input inspires the next few steps. Enhancing the feeling nature of the transformation, I took this to mean that the user should see the result of one stage of the free transform tool (e.g. an initial scale) before applying a further stage (e.g. a further rotate). Am I correct? btw: getting the opacity part working may need some serious grunt work. ask the developers about it. Since the functionality is obviously in place for rotate, scale sheer and perspective separately, they could be combined in a Photoshop like fashion for the Free Transform Tool, presumably using shortcut keys to specify the details of the required transform. The new transform tool is indeed a combined transform tool: move, rotate, scale, shear, perspective. Since the GUI would have to be amended to include the new tool, would it be a good idea to have the icons for both a Free Transform and the existing separate transforms beside each other? This would possibly result in too much feature duplication but I would like to hear your thoughts on the matter along with anything else relating to the project. see my intro in the spec. but the short version is: the combined tool is to supersede the move, scale and shear tools and should be complemented by expert rotate and perspective tools. the flip tool is a goner. I was going to suggest replacing that :-) Thanks a lot for the inputStephen _ Do you have a story that started on Hotmail? Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC - Free Transform Tool
Hello My name is Stephen McKeague and I am very interested in implementing the Free Transform Tool in GIMP for this years Google Summer of Code, originally proposed by Martin Nordholts. The project information page seems to still be offline, so I would like to discuss the bounds of the project. Since the functionality is obviously in place for rotate, scale sheer and perspective separately, they could be combined in a Photoshop like fashion for the Free Transform Tool, presumably using shortcut keys to specify the details of the required transform. Since the GUI would have to be amended to include the new tool, would it be a good idea to have the icons for both a Free Transform and the existing separate transforms beside each other? This would possibly result in too much feature duplication but I would like to hear your thoughts on the matter along with anything else relating to the project. I am starting a Ph.D. in Computer Vision this October at Imperial College London. I feel that I would be able to contribute a lot to this project and would love to use the experience gained through it to continue developing GIMP as a regular contributor. Thank you very much for your time Stephen McKeague _ Do you have a story that started on Hotmail? Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
Ideally, would this be limited to dialog windows or, instead, the entire user interface? PiTiVi uses GtkBuilder to do this everywhere, and then uses python after that. Point being that the heavy lifting is still done by GTK+ and GStreamer. GIMP is a significantly larger program, but I don't think hooking up the widgets is all that time intensive here either. As far as I know switching over to using GtkBuilder everywhere would be a feasible thing to do as the heavy lifting is constructing the widgets not joining them together. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Fri, 2009-10-30 at 13:06 +0200, Alexia Death wrote: Some English speakers discomfort at the name is getting a bit ridiculous IMHO. These words make me squirm. fag - a pile of sticks (secondary meaning, rarely used) nigger - a person from a poor background (secondary meaning, almost unheard of) chink - a chink in a chain (primary meaning) speck - a speck of dust (primary meaning) I am sure you have words in your native language, which in general function to isolate someone for being different or not being 'normal'. Do these become any less uncomfortable because someone says they mean it in a different way? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
On Sat, 2009-10-31 at 01:29 +0100, peter sikking wrote: how many more ways are there? ctrl+shift+a ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, 2009-10-29 at 15:27 -0700, Patrick Horgan wrote: Stephen Griffiths wrote: ... elision by Patrick The name GIMP is not so invaluable that it cannot be changed, also there is a massive number of outsiders who find the name truly unappealing, I do not hear the raw of the people saying they love the name. You can hear my raw here. I love the name. It appeals to me as a geek (I'm sure that you really hate THAT word, so much more fraught with ill-meaning than gimp) You are not making noise without being prompted. I didn't say I hated it (but there are those who do hate it), I just stated that it was not clever. Wordplay has for many years been considered the highest form of humour, it has only become less accepted as such in recent history. I still accept wordplay to be high humour, in this case I think GIMP is not very clever. there ARE no negative connotations. gimp and GIMP. UPPERCASE and lowercase. I doubt you needed that explained to you, but you did seem to play dumb there. We know what we mean Is it wrong that a language be used for communication between more than a small number of people? or eventually become cool Is that what people think when they look this way those guys are cool. 'Cool' is a social system only relevant in high-school. GIMP has panache. (N.B. I don't mean the meaning of panache that signifies a bunch of feathers or a plume on a helmet. I know some people get caught up in the idea that any possible definition of a word must be considered when communicating, but that's way too much trouble, and as someone earlier correctly suggested that I meant to say, silly.) I am glad you found some really sick definition of a word to make your point. My question is why didn't you just choose a simpler and more descriptive word, a word that would not require 4 lines of explanation to avoid confusion. You should attempt to communicate in a simpler manner, because it looks to me like this could have been said as You have a point of view, boo, that is stupid. well, till next time, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
I really mistook the what Patrick was saying here (of which he was kind enough to make me aware of privately), I apologise for reacting so quickly. I think I have already said what I meant to say in the first two posts and will take the time to bow out from any further participation. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Definition #5 is bad, but what about #1-4???
On Wed, 2009-10-28 at 19:41 -0400, Sparr wrote: On Wed, Oct 28, 2009 at 7:35 PM, vabijou2 vabi...@yahoo.com wrote: Lame, crippled, inept, deficient, or sexual deviant . I get that it's an acronym, but that doesn't mean it isn't incredibly strange to want to associate a project that the developers are proud of with any of these interpretations! You are restarting an argument that is already a decade old, and has been fought to conclusion a dozen times over. Fought to conclusion yes, but I can't remember anyone ever agreeing. I think even within the people who develop or contribute to gimp via discussion, people just eventually give up and go along with the joke. The name and the joke is on so many levels not very clever, there is a lot of tautology in the meaning only a little less when general became GNU. There is also the obvious association between gimp in leather, or gimp with a limp, or meanings in other languages (although the relevance of this point is questionable in most circumstances). We as people have more important things to do, whether it is with GIMP or the real world. Hell, I count getting drunk and waking up in a gutter as more important than re-hashing conversations that have little merit. On a more serious note, and to rehash what Sven has said before, if this was ever considered there is a lot of brand association with the name GIMP even for people who tried gimp 5+ years ago, and say GIMP is clunky because of this crazy weird UI (quite literally a gimp ui-wise). If a name change was considered, the only thing other than 'GIMP' that could be associated as GIMP (for me personally) is Wilber or Wilber Image Editor. Which to me sounds cool and funky, it also gets rid of the duality of association between GIMP, gimp and Wilber the gimp, and more importantly me having to read this conversation repeatedly. In conclusion, I think it is a dry joke between people who understand, it is that cliquish understanding which perpetuates the idea that the joke is funny, clever or culturally significant. I propose that GIMP as a project is what we care about, and frankly everyone working on GIMP should be damn proud of what is being achieved. The name on the other hand, only contains value for brand association or for those who find it clever. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Thu, 2009-10-29 at 10:48 +1030, David Gowers wrote: It doesn't really matter that much to the developers *what* it is called, as far as I know. The point is really the branding... changing name will definitively LOSE a lot of users, no matter what the current name is or the intended name is. There may be solutions to this problem (though commercially, rebranding seems to involve a lot of expensive advertising). So far, no-one has proposed one (or demonstrated that the current name is problematic in an actual provable way -- just assertions that it is offensive or not offensive in so-or-so region.). All the above comprise a significant factor in why forks are regarded, at best, as a necessary evil. All forks dilute branding, which introduces user confusion and repels potential users. So I do agree with one thing you said -- If you were to fork the project you would need to do so really well. This would probably involve forking the gimp-docs and gimp-gap similarly (and maybe also FX-Foundry) in order to cover the 'gimp' references in these most commonly installed accessories. It would also be important to make it very clear that it is compatible with GIMP plug-ins, and therefore to search GIMP's global plug-in/resource directories for resources as well as the fork's plugin/resource directories (identifying and ignoring duplicate resources). It would require the mascot to be changed (and therefore also some of the icon set, as they include Wilber), and also some (all?) of the gimp-docs screenshots, as well as some of the example images in gimp-docs which use Wilber. It would require a strategy for dealing with existing .gimp-2.7/ directories. That's my understanding at a glance. Actually doing it well would be more involved than the above, I expect. (for example, we use the phrase 'happy GIMPing!' and similar verb-ing of the GIMP name.. so it would help to have the replacement name be easily verb-able too) If we are going to have this conversation again and we will either until the name changes or the sun burns out, we should argue rationally. Pushing forward the idea that someone should fork the project insinuates that people are unhappy with the current leadership with all the skills it would require to maintain gimp, this is definitely not the case. If a fork did occur, it only requires forking the application, even thought the plug-ins, docs etc are very valuable. If the argument for keeping the name is seriously that the project branding is valuable, why don't we write that in the FAQ? Would we seriously loose a lot of users if the name changed? are users attached to the name or the program? if we do suspect that users would not be able to associate the product with the name are there steps that we could take to mitigate this problem? There is another way this could go, which is that changing the name generates a lot of positive publicity and no doubt it would. Hatred of the name generates negative publicity as it is. The name GIMP is not so invaluable that it cannot be changed, also there is a massive number of outsiders who find the name truly unappealing, I do not hear the raw of the people saying they love the name. Whether or not we are sick to death of this conversation it will keep coming back, because the arguments against the name are valid. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Content distribution system
I started off with a misunderstanding of what a content distribution system means to GIMP, after speaking to Peter Sikking (guiguru) I understand it to be: -a process of packaging, hosting (not us, website/browser based) and then installing, where we aim to make the install, uninstall much easier than it is now. One click install a user clicks on a link within a browser to http://www.x.y/package.gimppackage; for example, it gets downloaded and the normal workflow happens as per browser/platform. For example in firefox it says would you like to have program x automatically handle this file or would you like to just download it. where x is GIMP. I assume other browsers do similar things, yet for some time I have used Firefox almost exclusively. Security I don't think I see the security argument anymore, we are not fundamentally changing the way scripts/plugins/other are installed just automating the process. Any security here was and still would be based on trust, short of having someone with the time/skill to analyse these things. File format The way I see it now is a zip/tar.gz containing package.xml and other files, where package.xml describes the contents of a package. using a custom extension to identify it is a gimp package. -where package.xml describes the name of each package, and files contained version and version of gimp required to use scripts/plugins etc but only what is required for install unistall. regards, Stephen. p.s. currently for me it is exam season, hopefully followed by summer-job season :), so as usual the winds determine the amount of time I have to spend. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Content distribution system
Any technical comments on this solution? I think I will just say scratch that idea, it would work for installing but it was not well thought out otherwise :). Anyhow, I posted on the GHNS mailing list, mostly quoting Alexia Death and asking if anyone has used ghns for dependencies before. The response :) On Mon, 2009-10-05 at 02:05 +0200, Josef Spillner wrote: Packages which are unpacked at installation time and expand to several folders at once are easily possible and are already in use. However, dependencies between GHNS entries are not supported, each entry needs to be usable on its own or describe dependencies in its documentation. It would be nice to know some details about the Gimp use case to see whether something can be done about it and how representative it is of general potential GHNS usage in Gimp. I would like to see GHNS support in there, even if it won't cover all use cases at the beginning. Can anyone provide (a) use case(s)? For me it comes down to our product vision GIMP is user-extendable by one click install of addons (not quite verbatim, gui.gimp.org keeps going down for me) What is the point of that if we have to remove 3-15 things for every addon (mis-clicks could be very painful). If you are allowed break dependencies through the interface then have a script/plugin throw an error message saying brush-x-y-z is missing and I can't work fix-me OR avoid my menu entry (no-doubt this is the way some people would choose to go). That for me is painful, but I am unsure how to phrase this as a use case regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Content distribution system
I would like to work on Bug 306713 - Write a GIMP plug-in and resource distribution system https://bugzilla.gnome.org/show_bug.cgi?id=306713 Martin suggested on bugzilla: If we do this, we should seriously consider http://ghns.freedesktop.org/. I have had a look at the specification and written a little bit of code to test the idea using libxml2 and libcurl. (to understand ghns better and because I have never worked with XML or URL based downloads) In general it seems quite feasible and hopefully challenging for me, so questions for discussion. -did anyone else have plans to do this any time soon? -Are we considering this to be only for individual users or someone download for groups of people, in cases such as --using thin clients? --creating networked images? -instead of providing downloads ourselves, we could make third parties the download providers and just provide say a sample implementation of a download service. -anything you would like to discuss. Regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Content distribution system
On Sun, 2009-10-04 at 18:54 +0300, Alexia Death wrote: On Sun, Oct 4, 2009 at 12:34 PM, Stephen scg...@gmail.com wrote: -anything you would like to discuss. for me, as both distributor(FX foundry) and a user resource distribution means mostly a simple way to package and deploy resources. For example, currently there are some scripts I wont distribute with foundry because they have dependencies in shape of say patterns and it would make installing the whole package very difficult. multi-resource packs should be installable by just dragging the pack on gimp ui. It should also offer ways to uninstall and package them, and provide means for mass taging/untaging and distributing tags. Thanks for this, this wasn't on my radar before. I did some thinking about this, and it ties in with what Martin said before, download types (including versions) are identified by type using a string, such as: stuff category=app/media (the given example) gimp/tags/3.0.0 gimp/pattern/3.4.8 gimp/plugin/tinyscheme/3.2.3 gimp/package/ if we use the same system, but prefix each string using a checksum of the enitre package such as: da0b21c73078882a59430ce68e8860b9/gimp/tags/3.0.0 da0b21c73078882a59430ce68e8860b9/gimp/pattern/3.4.8 da0b21c73078882a59430ce68e8860b9/gimp/plugin/tinyscheme/3.2.3 da0b21c73078882a59430ce68e8860b9/gimp/package/ gimp/package/3.4.8/package.xml, could just be a ghnsdownload identifying everything that is to be installed an un-installed. And the checksum prefix identifies that it was installed as a part of a given package and given a network based install, you just send the package.xml, where the package could be constructed on the fly. Any technical comments on this solution? How would the installed version look? .gimp-x-y/patterns/da0b21c73078882a59430ce68e8860b9/? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] VTF plug-in
There also exists an open library: http://nemesis.thewavelength.net/index.php?p=40 and also a PhotoShop plug-in: http://nemesis.thewavelength.net/index.php?c=154#p154 thewavelength.net resolves nemesis.thewavelength.net doesn't resolve you might want to get some new links. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] making tool re-arrangements cancellable in the preferences dialog
I am looking for some advice on how to make tool re-arrangements
cancelable in the preferences dialog.
(for http://bugzilla.gnome.org/show_bug.cgi?id=500930)
the current code that resets the preferences looks like this (in
prefs-dialog):
if (gimp_dialog_run (GIMP_DIALOG (confirm)) == GTK_RESPONSE_OK)
{
GimpConfig *config_copy;
config_copy = g_object_get_data (G_OBJECT (dialog), config-copy);
gimp_config_reset (config_copy);
}
Can anyone point me to an example of how to attach(?) a GimpContainer
(or something similar) to gimpconfig in order to reset order/visibility?
regards,
Stephen Griffiths.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] formatting patch
I just came across a chunk of code with mixed space/tab indenting and
fixed it. Hopefully posting it to the devel list is fine.
regards,
Stephen.
From 8fe725d87a4709cb0461c6de8348cde449d076b8 Mon Sep 17 00:00:00 2001
From: Stephen Griffiths scg...@hotmail.com
Date: Thu, 28 May 2009 22:52:41 +1000
Subject: [PATCH] app/widget/gimp uimanager.c formatting
---
app/widgets/gimpuimanager.c | 106 ++-
1 files changed, 54 insertions(+), 52 deletions(-)
diff --git a/app/widgets/gimpuimanager.c b/app/widgets/gimpuimanager.c
index 740b6f3..983ee4b 100644
--- a/app/widgets/gimpuimanager.c
+++ b/app/widgets/gimpuimanager.c
@@ -1068,61 +1068,63 @@ struct ChildLocation
static void
child_location_foreach (GtkWidget *child,
- gpointer data)
+gpointer data)
{
gint x, y;
struct ChildLocation *child_loc = data;
/* Ignore invisible widgets */
- if (!GTK_WIDGET_DRAWABLE (child))
+ if (! GTK_WIDGET_DRAWABLE (child))
return;
/* (child_loc-x, child_loc-y) are relative to
* child_loc-container's allocation.
*/
- if (!child_loc-child
+ if (! child_loc-child
gtk_widget_translate_coordinates (child_loc-container, child,
- child_loc-x, child_loc-y,
- x, y))
+child_loc-x, child_loc-y,
+x, y))
{
#ifdef DEBUG_TOOLTIP
g_print (candidate: %s alloc=[(%d,%d) %dx%d] (%d, %d)-(%d, %d)\n,
- gtk_widget_get_name (child),
- child-allocation.x,
- child-allocation.y,
- child-allocation.width,
- child-allocation.height,
- child_loc-x, child_loc-y,
- x, y);
+ gtk_widget_get_name (child),
+ child-allocation.x,
+ child-allocation.y,
+ child-allocation.width,
+ child-allocation.height,
+ child_loc-x, child_loc-y,
+ x, y);
#endif /* DEBUG_TOOLTIP */
/* (x, y) relative to child's allocation. */
if (x = 0 x child-allocation.width
- y = 0 y child-allocation.height)
+ y = 0 y child-allocation.height)
{
- if (GTK_IS_CONTAINER (child))
- {
- struct ChildLocation tmp = { NULL, NULL, 0, 0 };
-
- /* Take (x, y) relative the child's allocation and
- * recurse.
- */
- tmp.x = x;
- tmp.y = y;
- tmp.container = child;
-
- gtk_container_forall (GTK_CONTAINER (child),
-child_location_foreach, tmp);
-
- if (tmp.child)
- child_loc-child = tmp.child;
- else
- child_loc-child = child;
- }
- else
- child_loc-child = child;
- }
+ if (GTK_IS_CONTAINER (child))
+{
+ struct ChildLocation tmp = { NULL, NULL, 0, 0 };
+
+ /* Take (x, y) relative the child's allocation and
+ * recurse.
+ */
+ tmp.x = x;
+ tmp.y = y;
+ tmp.container = child;
+
+ gtk_container_forall (GTK_CONTAINER (child),
+child_location_foreach, tmp);
+
+ if (tmp.child)
+child_loc-child = tmp.child;
+ else
+child_loc-child = child;
+}
+ else
+{
+ child_loc-child = child;
+}
+}
}
}
@@ -1131,13 +1133,13 @@ child_location_foreach (GtkWidget *child,
*/
static void
window_to_alloc (GtkWidget *dest_widget,
- gint src_x,
- gint src_y,
- gint *dest_x,
- gint *dest_y)
+ gint src_x,
+ gint src_y,
+ gint *dest_x,
+ gint *dest_y)
{
/* Translate from window relative to allocation relative */
- if (!GTK_WIDGET_NO_WINDOW (dest_widget) dest_widget-parent)
+ if (! GTK_WIDGET_NO_WINDOW (dest_widget) dest_widget-parent)
{
gint wx, wy;
gdk_window_get_position (gtk_widget_get_window (dest_widget), wx, wy);
@@ -1162,21 +1164,21 @@ window_to_alloc (GtkWidget *dest_widget,
static GtkWidget *
find_widget_under_pointer (GdkWindow *window,
- gint *x,
- gint *y)
+ gint *x,
+ gint *y)
{
GtkWidget *event_widget;
struct ChildLocation child_loc = { NULL, NULL, 0, 0 };
gdk_window_get_user_data (window, (void **)event_widget);
- if (!event_widget)
+ if (! event_widget)
return NULL;
#ifdef DEBUG_TOOLTIP
g_print (event window %p (belonging to %p (%s)) (%d, %d)\n,
- window, event_widget, gtk_widget_get_name (event_widget),
- *x, *y);
+ window, event_widget, gtk_widget_get_name (event_widget),
+ *x, *y);
#endif
/* Coordinates are relative to event window */
@@ -1210,8 +1212,8 @@ find_widget_under_pointer (GdkWindow *window,
* relative coordinates
Re: [Gimp-developer] feature request: clipping mask layer
yahvuu wrote: i wonder, is what you're proposing the same as the 'group layers masks' described in https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-April/022118.html ? Is this already covered by http://bugzilla.gnome.org/show_bug.cgi?id=51112 ? In photoshop it is a single layer that docks to the layer (or multiple layers) beneath it, acting as a mask. In PS it is activated by Ctrl+LMB (from memory) on the edge between two layers. Layer group masks would achieve the same thing, and sounds easier to understand/ use. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient manager
Paul A. wrote: I will link you to this site . There you will find an online image editor which has a gradient manager that I believe would be a great idea to be implemented in gimp. It would be a great improvement for the application and many people would find it very useful. http://raidnet.org/photoshop/ this was the link that was missing. Regards, Stephen. http://raidnet.org/photoshop/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] A Photographers View of Gimp 2.6
Just some thoughts on Gimp in general and 2.6 in particular. Layers: Somebody has misplaced a box. Where has the layers stack window gone? I can’t turn on the pane under either layers, image or view. I can create a new layer but not see what layers are on the image. Save As: I don’t seem to be able to move up a level then down into a new folder on a save as. This is an issue as I’m taking tiff’s from one location, editing them then saving as jpg into a separate folder for ftp upload. Optimally, open (and save) and “save as” would set their default folders independently as the last folder used for that operation. Unsharpen Mask: The GEGL unsharpen mask feature does not use standard terminology. I have no idea how to set this. General Wish List: Locate Center Point: Reviewing a 22MP image a 100% means navigating an image with an equivalent size of several feet. What would be nice is some way to mark the exact center of the image, where the central AF point fell, so that it can be quickly navigated to at 100%. Scale to File Size: Many stock sites require an image to be upsized. For example Alamy requires an uncompressed file size of 48megs from a file saved as a 8bit .JPG. It would be useful to be able to set in an uncompressed file size and have the GIMP resize to be exactly that size. View at Simulated Output, 150, 300 or 500 DPI: Back in the days of film we would have laughed at anybody getting spun up that an image was not sharp when enlarged to multiple feet from a 35mm or smaller frame. When scanned, we edited out images at output size, and used 100% view for retouching. Everybody needs a little reminder that the question how will this look outputted, not how will this look on a theoretical billboard. High Dynamic Range Imaging: Which will require greater then 8bit color. Mathematically putting 3 or more images bracketed on a tripod together for an expanded tonal range. Currently can be done natively in CS3/CS4. Color Palettes: Digital Cameras tend to output in only a couple of color palettes. Alien Skins Exposure 2 plug in can simulate a number of old film palettes. It would be nice to be able to do in the open source world (patents allowing). At least from Kodak, datasheets including gamma curves of every film they’ve ever made are online (RG25 FTW). Noise Reduction: The overexposed look is in for photography lately as dark areas of an image pick up patterning from the digital sensor (i.e. noise). Back in the days of film seeing grain in an image enlarged to several feet would be a “live with it”. Today a number of companies will reject images showing ANY noise at 100%. Plugins such as noise ninja are quite popular. Would be nice to have a specific noise killing enhancement in GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 73, Issue 16
Alexandre
Not to be smarmy but:
operation_class-name= sdv-unsharp-mask;
and leave the standard unsharp mask.
The current unsharp mask uses radius, amount and threashold. The new one uses
scale and standard deviation. The function it is performing an unsharp mask
but it's done the equivalent of going from Farenhight to Kelvin without telling
anyone. This results in somebody using one image editor not being able to spec
actions for somebody using a different editor. This can be a big deal where
multiple photographers are trying to produce a consistent output (for example a
primary and secondary shooter at a wedding).
As for Qtpfsgui, the autoalign doesn't work, even on tripod mounted shots on a
still day.
On Sun, Oct 5, 2008 at 9:28 PM, Stephen DeLear wrote:
Unsharpen Mask: The GEGL unsharpen mask feature does not use standard
terminology. I have no idea how to set this.
Let me give you an idea: edit the source code and send us a patch
('diff -u' is your friend)
You want this file:
http://svn.gnome.org/viewvc/gegl/trunk/operations/common/unsharp-mask.c?revision=2590view=markup
:-)
High Dynamic Range Imaging: Which will require greater then 8bit color.
Mathematically putting 3 or more images bracketed on a tripod together for
an expanded tonal range. Currently can be done natively in CS3/CS4.
Qtpfsgui is your friend :-)
Noise Reduction: The overexposed look is in for photography lately as
dark
areas of an image pick up patterning from the digital sensor (i.e. noise).
Back in the days of film seeing grain in an image enlarged to several feet
would be a live with it. Today a number of companies will
reject images
showing ANY noise at 100%.Plugins such as noise ninja are quite
popular. Would be nice to have a specific noise killing enhancement in
GIMP.
You mean you want all those noise reduction plug-ins and scripts
floating around GIMP in the bundle or some particular one? Could you
probably be more particular about that? :-)
I'm not saying GIMP developers will do what you say (I'm not in
position to make any claims regarding development process), but at
least you could start with review of existing solutions for GIMP
(GREYCstoration, Wavelet Denoise etc.) with samples and
recommendations. That would be a good start. Just telling people
something is missing and not providing enough information is not quite
helpful ;-)
Alexandre
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggested in memory image data structure.
On Mon, 2008-07-07 at 06:41 +0200, Rogier Wolff wrote: On Sun, Jul 06, 2008 at 05:51:24PM -0400, Liam R E Quin wrote: Currently images are commonly stored as an array of rows of pixels. GIMP does in fact use image tiles. But then why, on a machine with 700Mb RAM, does EVERYTHING take so very long? My image is only 50Mpixel. Roger. What size is your tile cache? Stephen ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
that select by color supports the same booleans, feathering, and can be used in conjunction with freehand makes an even more powerful combination. Using select by color to differentiate large regions and then the freehand to cut or add to the selection is real efficient (it is also where the problem with the mode change when you are over a selected region is most evident). I'd reccomend you this workflow for background extraction: I like the methodology that I am using. The enhancement I am requesting would make my methodology much better, but even without the fix, I don't see myself reverting to path based selection for the majority of my work. It is not flexible enough and takes too much time. -Draw a path along the edges of the shape that you want to extract, draw other paths for the holes (if you create them in the same path layer they are automatically combined with the other paths forming holes). -Turn path into selection -Add a mask channel based on that selection. So, imo, the existence of better tools for the same procedure makes this request questionable. If you ask me, I'd love to have the ability to apply boolean operations between different paths before seeing further work on the free selection tool. Like I said originally you and I have very a very different point of view about the “better” tool for selection. If I am alone in my pint of view, then it doesn't make sense to modify the tool. If on the other hand there are a lot of casual users whose approach to the tool is like mine, the modification could server a pretty wide base. It would seem that would determine whether the fix was worth while. I am not sure how the developers go about figuring out whet the users would really like. Addressing you comment on a different use of the effort, I am not sure how much use booleans would serve for paths, since as you mentioned you can cut holes by having paths on the same layer. I haven't played with paths enough to know what you might be able to do with paths on multiple layers, but it seems like the flexibility might already be there. Your other proposal (selection stack) is very interesting, but sounds quite difficult tu implement. I'm not thinking exactly in your examples, but in the possibility to transform different selection levels independently (i.e. you selected 3 circles and you want to adjust the size of the first one). If it is difficult then it is probably a non-starter. I viewed it as a “nice to have” feature and thought that it was worth brining up in case it wasn't too hard to implement. I thought that since the current behavior acts a little like a single layer stack, there was a chance that adding more depth might be doable without a huge effort. - Original Message From: Guillermo Espertino [EMAIL PROTECTED] To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Wednesday, July 25, 2007 12:26:20 PM Subject: Re: [Gimp-developer] Request for Change 0 Free Select Behavior Stephen: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. I'd reccomend you this workflow for background extraction: -Draw a path along the edges of the shape that you want to extract, draw other paths for the holes (if you create them in the same path layer they are automatically combined with the other paths forming holes). -Turn path into selection -Add a mask channel based on that selection. So, imo, the existence of better tools for the same procedure makes this request questionable. If you ask me, I'd love to have the ability to apply boolean operations between different paths before seeing further work on the free selection tool. Your other proposal (selection stack) is very interesting, but sounds quite difficult tu implement. I'm not thinking exactly in your examples, but in the possibility to transform different selection levels independently (i.e. you selected 3 circles and you want to adjust the size of the first one). Oh, btw. I'm experiencing some troubles with SIOX. In some images (I couldn't figure it out exactly when it happens) after the initial coarse selection the mask is displaced to the lower left of the image (with the right shape, but completely misaligned with the image) making it impossible to perform the extraction. Is that a known bug or it's just me? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
David, Thanks for the reply. I am using the Windows version of 2.2.17. In this version the issue that I am having an issue with can be reproduced in any image by selecting the freehand select tool, draw a circle in the image creating a selection, press the subtract from current selection mode button, move the cursor inside the selected region, depress the mouse button to start defining the region you want to subtract, and when you move the mouse you move the selection as a floating section instead of defining what you want to subtract. If there is a fairly stable version of the tool that has a fix for the issue I am having, that would be great. Which version should I be using? Your comment See the Channels dialog -- that's exactly what it is for. for a providing a selection stack capability sounds interesting. Do you have a link or reference that elaborates on this? Thanks Stephen - Original Message From: David Gowers [EMAIL PROTECTED] To: Stephen Kiel [EMAIL PROTECTED] Cc: Guillermo Espertino [EMAIL PROTECTED]; gimp-developer@lists.xcf.berkeley.edu Sent: Thursday, July 26, 2007 5:37:29 PM Subject: Re: [Gimp-developer] Request for Change 0 Free Select Behavior On 7/27/07, Stephen Kiel [EMAIL PROTECTED] wrote: Guillermo, Thanks for taking the time to reply to my request. It appears that you and I have a fundamentally different point of view on how to best select regions in an image. Let me throw out a couple of observations before I address some of your points in the hope that I can avoid starting a religious argument about which technique is better (especially if my side is outnumbered). - In most applications most of the users focus on about 20% of the options and capabilities in a given tool whether it is an office tool, or an engineering Design Automation tool. I suspect this is true of almost any tool that is fairly flexible. This does not mean that the 80% that any one user doesn't normally use aren't valuable as different users solving different problems. - It is important that the work on an image has an intuitive feel. No one methodology or selection method works best across all of the images you might encounter. Users will develop favorite methods based on their own success and failures with features of a tool. Failure with a feature of a tool is not a reflection on the feature, it just points out that a variety of robust features are necessary for a well rounded tool. - The enhancement that I am asking for is for the current mode of operation to perform in a manner that would be expected by a reasonable user. When the user selects a mode of operation using the menu and switches, it seems reasonable for the tool to honor those choices rather than making a unilateral decision to change modes based on cursor location. The fact the behavior is called out in the specification doesn't really change the fact that it is kind of user unfriendly. The 'enhancement' that you describe, in my experience, has been included in the GIMP for at least a year. I cannot reproduce the problem you describe (and for the purposes of getting this changed, you will probably need to come up with some reliable way of reproducing it.) Let me try and address your points: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. If I believed this I would not have bothered to ask for the enhancement in the first place. I think of using the freehand select for precision work as part of my methodology rather than a bad idea. When I started using Gimp I tried the Path / Bezier tool but in practice I really haven't found much use for it. The notion that it is better is subjective and is not in line with my experience. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. This may have been the vision when the tool was put together, if it was I would say the Freehand select exceeded the original expectation. I believe that it is the best selection mode in Gimp for making precise selections. - How fine your control is for defining a selection line is determined by the level of zoom you are at, not whether you are drawing the line or defining it with a series of dots. The freehand select is as precise as the picture and tool will allow. That doesn't even make sense. The freehand tool and path tool have both exactly the same level of precision -- they both render polygons, so they're infinitely-precise; freehand can be faster if you have a steady hand; paths is more precise because it can draw shapes with holes in them in the same step as drawing the outside - freehand select must do such things in two steps, because it makes some assumptions about how the user wants to use it. Freehand select works under the exact same rules as path tool - including eg
[Gimp-developer] Request for Change 0 Free Select Behavior
to layers and merging the layers, but this doesn't work as well as I had hoped for the following reasons: 1) It is real hard to see and control what is going on, the visual feedback is awkward. 2) The merging of layers only gives you and “Add” mode. 3) The Feathering of edges can create unintended voids in the selection. You would almost always want the Feathering to be on the border (perimeter and holes you might cut) of the resultant selection, not within the selection itself. Anyway thanks in advance for considering my request. I understand that you have to weigh these request to create the best usage for the entire user community and even though I feel these changes would make a better and more usable tool, that is really for you to decide. Thanks Stephen Kiel Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] authors.xml, volunteer needed
On Sat, 2005-08-27 at 12:52 +0300, Tor Lillqvist wrote: Stephen Robert Norris I wrote the original Plasma plugin, Displace plugin and... waves? plugin... It's been a while. Stephen signature.asc Description: This is a digitally signed message part
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
[Gimp-developer] Want to concatenate image files
Hi, I would like to concatenate a series of image files. I have a set of small files that I want to join together into one big (gif) file. Can I do this with GIMP? Any help appreciated and please forgive my newbieness... Stephen. attachment: winmail.dat
RE: [Gimp-developer] Want to concatenate image files
sorry - maybe I didn't make myself clear... I've got a series of map images of a town and would like to join them up into one seamless map of the town... is it possible to automate this somehow? thanks.. -Original Message- From: Branko Collin [mailto:collin;xs4all.nl] Sent: 24 October 2002 14:17 To: Stephen Keegan; [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Want to concatenate image files On 24 Oct 2002, at 13:43, Stephen Keegan wrote: I would like to concatenate a series of image files. I have a set of small files that I want to join together into one big (gif) file. Can I do this with GIMP? Any help appreciated and please forgive my newbieness... If you want to make what's generally known as an animated GIF, you can load each image into its own layer, then just save. An export dialog will pop up asking you how you want the image to be saved. --Boundary_(ID_8B0jmRtv3j4JUqfEG3nOCg) Content-type: application/ms-tnef; name=winmail.dat Content-transfer-encoding: BASE64 Content-disposition: attachment; filename=winmail.dat eJ8+IjQMAQaQCAAEAAABAAEAAQeQBgAI5AQAAADoAAEIgAcAGAAA AElQTS5NaWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAgACAAEGgAMADgAA [lots of rubbish snipped] What is this? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Want to concatenate image files
Sven. Montage looks perfect - thanks alot! Stephen. -Original Message- From: Sven Neumann [mailto:neo;bender.convergence.de]On Behalf Of Sven Neumann Sent: 24 October 2002 15:53 To: Stephen Keegan Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Want to concatenate image files Hi, Stephen Keegan [EMAIL PROTECTED] writes: sorry - maybe I didn't make myself clear... I've got a series of map images of a town and would like to join them up into one seamless map of the town... is it possible to automate this somehow? thanks.. what about using montage which comes with ImageMagick? Salut, Sven ___ 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] illusion and perl-fu
Thank you. I upgraded to linux 1.2.3-pre2 and now have my perl-fu running the illusion function properly. On Sat, Feb 02, 2002 at 12:25:06PM +0100, Sven Neumann wrote: Hi, Branko Collin [EMAIL PROTECTED] writes: On 1 Feb 2002, at 18:54, stephen thompson wrote: I have written dozens of perl-fu scripts with success, but now I am stumped. I am trying to make a call to the Illusion plug-in, plug_in_illusion, but it always returns: st_illusion: plug_in_illusion: procedural database execution failed on invalid input arguments I am passing it a Drawable and an integer for the Divisions variable, according to the DB Browser info on the Illusion plug-in. I've even scanned through the illusion.c source code to see what might be up, but I cannot find anything wrong. A note of interest is that the Illusion plug-in also has a Mode toggle, but that is not noted in the DB Browser and attempting to pass the plug-in 3 arguments results in a too many arguments error. Which GIMP version is this? I am using 1.2.3. beta (Windows), which mentions five arguments in the database: INT32 interactive/non-interactive IMAGE input image DRAWABLE input drawable INT32the number of divisions INT32illusion type (0=type1, 1=type2) Hm, the one in GIMP 1.2.0 Windows has 4 arguments (it lacks illusion type). Looks like somebody is growing arguments here. we try not to do this in a stable series, but in this case I felt that correcting the PDB arguments would outweight the risk of breaking scripts: 2001-10-19 Sven Neumann [EMAIL PROTECTED] * plug-ins/FractalExplorer/FractalExplorer.c * plug-ins/common/illusion.c: added missing PDB parameters. Thanks to [EMAIL PROTECTED] for spotting these. Salut, Sven -- ___ __ That's where it ends-- / - \,,, Back there where I coughed. | ](#)#|:::[We'll note here: \___-__/``` Fade at cough. --Bob Dylan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] illusion and perl-fu
Hello. I have written dozens of perl-fu scripts with success, but now I am stumped. I am trying to make a call to the Illusion plug-in, plug_in_illusion, but it always returns: st_illusion: plug_in_illusion: procedural database execution failed on invalid input arguments I am passing it a Drawable and an integer for the Divisions variable, according to the DB Browser info on the Illusion plug-in. I've even scanned through the illusion.c source code to see what might be up, but I cannot find anything wrong. A note of interest is that the Illusion plug-in also has a Mode toggle, but that is not noted in the DB Browser and attempting to pass the plug-in 3 arguments results in a too many arguments error. Can anyone possibly shed some light on this problem for me? I'm not currently on the devel list, so if you could respond to the list and [EMAIL PROTECTED], it would be most appreciated. I'm posting to this list hoping a plug-in developer might have the answer I'm looking for... thanks, Stephen -- ___ __ That's where it ends-- / - \,,, Back there where I coughed. | ](#)#|:::[We'll note here: \___-__/``` Fade at cough. --Bob Dylan ___ 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] Re: patch for gimp/po/fr.po
On Wed, Aug 29, 2001 at 09:38:45PM -0500, Kelly Martin wrote: On Thu, 30 Aug 2001 10:05:15 +1000, Stephen Robert Norris [EMAIL PROTECTED] said: So it's the library's fault if I pass it a bad pointer and it causes a SEGV? Yes. Kelly I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On Wed, Aug 29, 2001 at 11:22:26PM -0500, Kelly Martin wrote: On Thu, 30 Aug 2001 13:42:05 +1000, Stephen Robert Norris [EMAIL PROTECTED] said: I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Sounds like a fundamental problem with the UNIX environment design, then. Kelly It's a fundamental problem with having pointers. If you were restricted to some sort of object references that the OS controlled (something like MONADS had, or MULTICS sort of had) then you can avoid the problem. Otherwise, it's hard to fix. -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On Thu, Aug 30, 2001 at 07:34:57AM +0200, Lourens Veen wrote: Stephen Robert Norris wrote: I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets the mutex, then calls the library with a pointer to some part of the shared memory. Make sure thread 2 checks the mutex before unmapping and there's no problem at all. Thing is, how is the library going to know whether the pointer is valid or not? All the standard C functions that expect pointers will happily write wherever you point them to, even if it causes a segfault. I don't see how this is a problem with the library. If I divide by zero (which is essentially calling the divide function with illegal values) I get an exception as well. Lourens Yes, this is a way the application can avoid the problem; it's not a way the library can. My point was that it's impossible with modern OS's to avoid the possibility of the library crashing. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SMP support
On Tue, Aug 07, 2001 at 10:48:37AM +0200, Sven Neumann wrote: Hi, Michael Soibelman [EMAIL PROTECTED] writes: I just noticed that there no longer seems to be the --with-smp configuration option! Is this an omission or intentional? IIRC, the configuration option to add support for multiple processors has always been --with-mp and it's still there. Also, excuse my ignorance, but can options such as --with-smp be passed to the rpm command rpm's do include prebuilt binary packages, you can't reconfigure them later. I suggest you build from source if you want SMP support. Unless you build from source RPMs, of course. Just install it and edit the spec file to include what options you want and rebuild the RPM. Keeps the dependency tracking nice and orderly. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Quesitons about support for Djvu format and Color selection
On Sun, Jul 15, 2001 at 10:15:28PM +0200, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2001-07-15 at 1042.57 -0700): 1) I was on the lizard tech site a while back, and I stumbled onto this page: http://www.lizardtech.com/products/djvu/referencelibrary/DjVuRefLib_3.0.html I am relatively ignorent of coding, but I have seen Djvu images in action and been quite impressed. It was originally developed by ATT and then sold to these guys. If this site is correct, they have released some fairly interesting software under GPL, including the complete decoder and some more basic encoding abilities for the djvu format. Would this be useful to add to the gimp? Has anyone looked into this before? When coders see the word patent near something, they can get very nervous, even if it says that they grant it. Ask the company, maybe they want to create and maintain it, as PR. BTW, they are messing GPL and Open Source. Hohoho, if FSF people reads the page. GSR A quick skim of the webpage seems to indicate the know what the GPL is. The only thing I can see that's interesting is what happens if they use the GPL'ed code in their commercial products? Given the nature of the GPL, surely that means they'd have to distribute source of the other products too? They certainly would have to if they ever accept contributions from the outside world under the GPL, I believe. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 PGP signature
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
