Re: [Gimp-developer] Joining the GNOME Foundation
Kelly Martin wrote: I'd be very surprised if the GNOME Foundation passed along *all* funds untouched donated with a simple earmark for the GIMP to the GIMP people; I would fully expect them to take an administrative fee of between 5% and 50% (maybe even more). You might want to have an agreement in writing on this point before you start using them to fundraise. Dave neary and I talked to Tim Ney about this. There is goign to be a small cut taken by TGF. It is very close to the lower end of your range, but I won't know specifically until the board approves the number (which they are supposed to do soon). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Sven Neumann wrote: It's not that we wouldn't put a lot of effort into making GIMP work well on a GNOME desktop. Adhering to FreeDesktop standards is one of our goals and we are even working towards full GNOME HIG compliance. The only things we really want to avoid is to be forced to do any of this. Above all, everyone should know you are a volunteer. And as long as you are a volunteer, noone can tell you to do anything. If they every forget this fact, you can always politely remind them (or no-so-politely tell them to sod off). And really, the above is kinda the reason I think this is a good plan. We are already moving in the direction they would want us to, thus it is quite easy to join them. Since we aren't a GNOME application, noone can force us into anything and that's a good thing. GNOME still can't force any volunteer to do anything. The worst damage they could do is, do this or we we will withold some funding but even then, you are no better off then you are now. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] more GIMP foundation stuff
Michael Schumacher wrote: Carol Spears wrote: On Sat, Apr 24, 2004 at 09:44:49AM +0200, Marc A. Lehmann wrote: On Fri, Apr 23, 2004 at 08:00:17PM -0700, Daniel Rogers [EMAIL PROTECTED] wrote: I've put it here: http://www.phasevelocity.org/bylaws.doc These bylaws Woaw, the bylaws for a free software organisation, written in a proprietary microsoft format! this summed up my feelings very well. Might be another reason for lack of feedback. Dude. The lawyer gave me doc. Open office read it fine. I didn't think it woudl be a problem. I used open office to make a pdf. It's at http://www.phasevelocity.org/bylaws.pdf did they discuss file formats with you when you discussed this at the gimp convention? Maybe something about this is in the minutes of the last GIMPCon. Anyway, are there any suggestions (or requirements?) for an official format for all TGF documents. PDF seems reasonable. She is just trying to goad me, so I tried to ignore her. It is not an official document yet, but yes, I agree that PDF is reasonable for all TGF documents. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMPCon
Dave Neary wrote: Hi all, In a mail I just sent off, I said we should have some information about what we plan to do at GIMPCon... What do we plan to do at GIMPCon? I'd like to say that, for the record I won't be able to attend GimpCon. I simply don't have the time or money at the moment (and the soonest I would is months and months away). And in case anyone missed my previous PS, I'm quite busy with my real life atm and have found myself quite without much time to put into The GIMP. Both setting up the bounties and the Foundation are things that are consuming all my free time. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] more GIMP foundation stuff
Daniel Rogers wrote: So, I noticed the resounding silence surrounding this thread. Is anyone still interested in a foundation? I went into this foundation thing thinking I had support from the community. I cannot do this all by myself. The Foundation is about getting involved. If noone wishes to get involved, then there is nothing left I can do. Here are the things left to do. Within a week I need to get the parts in red of the draft bylaws fleshed out at at least the majority satisfiaction of the community. In addition to the red parts, the membership section needs to be writtin. The week is gone, obviously, but this still needs to be done. I just lose legal support for a while after a few days, which is ok. I just slows things down a bit. Do these issues interest anyone in particular? I need to appoint an initial board, whose job will be to set up a membership system, start collecting members, and allow those members to vote in a non-interim board (any takers?) To be a little more clear: I need volunteers to be an initial board of directors. I need to send in the corporate paperwork to the IRS (with the filing fee) and wait a few months for the IRS to send some questions answer those questions, and wait a few more months to get our non-profit status approved. Instead of all this though, I've been talking to Tim Ney about having the GNOME Foundation take a more active role in supporting the GIMP. If GNOME was willing to do this, this would probably be a good option for us. Gnome already has the infrastruction and ability to act as a non-profit, as well as plenty of corporate suppport. What do people think of this plan? Again, to be a little more clear. GNOME would like to support us more than just in name. All we (e.g. more than just me) have to do is say yes. It is unclear, at this point, how exactly GNOME would be involved with The GIMP, but those details could be worked out. Does this interest anyone? Is anyone outright opposed (and why)? -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: more GIMP foundation stuff
Michael Schumacher wrote: Daniel Rogers wrote: Daniel Rogers wrote: So, I noticed the resounding silence surrounding this thread. Is anyone still interested in a foundation? I went into this foundation thing thinking I had support from the community. I cannot do this all by myself. The Foundation is about getting involved. If noone wishes to get involved, then there is nothing left I can do. Well, I started to read the bylaws and was overwhelmed a bit. Being totally unfamiliar with stuff like this, I found it a bit too much to read, comprehend and evaluate in one week... maybe this happened to others as well? Ah, well. . .err, um. Fair enough. I forget that I've been stewing in this stuff for month. Most of this is boiler plate and echos the laws that we are required to follow anyway. If anyone is overwhelmed by any bit of it, it is just fine to discuss what you want in normal person terms. I need to appoint an initial board, whose job will be to set up a membership system, start collecting members, and allow those members to vote in a non-interim board (any takers?) To be a little more clear: I need volunteers to be an initial board of directors. Might be an important question: does one have to live in the US to be able to become a director? (and/or president, secreatary, treasurer, ...) No. As I think I mentioned before you don't need to live in the US or even have to be 18 (though you have a hard time entering contracts if you are less then 18 so 18 is a practical requirement). It gets complicated if TGF tries to employ non-us people (though it can be done), however the directors should probably not be compensated anyway. And to clarify: there are two structures that must exist in a corporation. There is the board of the directors, which make general descsions, are voted in by the members, can enter contracts, hire people, and delagate tasks to others. The number of directors as well as the amount of directors that qualify as a quorum and the percentage that qualifies as a majority can all be set in the bylaws. The second structure is the officers. These are the people like the president, tresurer, and secratary. The duties of these officers are set in the bylaws. The president usually is respnosible for hiring and the day to day activities of the corporation. The tresurer is in charge of the finances. The secretary records the minutes of the board meetings. The board members can be officers and are generally appointed by the board. The president or the secretary can not be same person as the tresurer. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] bylaws discussion part 1: objectives
Ok, So I think the best way to approach this is to break the bylaws in to the relevent bits and encourage discussion on a single small topic at a time. So, the first part that needs to be discussed are the objectives. These are, in their way, rather important. The objectives are what define the purpose of TGF as a charitable organization. These is the section that the IRS looks at to determine if we even can be classified as a charitable organization. There are two ways to approach this. One is to determine our objectives and then, when writing to the IRS, explain how the objectives fit into the charitable and educational purposes. This is pretty easy as long as we declare charitable purposes. Phrases like, Support the Free Software product, The GIMP and a charitable service available to the public. Educate the public about the existance and usage of The GIMP. Promote and support projects that support The GIMP. We should use the words, public, charitable, educate, support The IRS likes those words. They should be vague enough to not hinder our ability to do work. In short, what would people like TGF to do for them or for people in general? Remember, in order to be a non-profit, we need to do actions that support the public, not just ourselves, which I can't imagine anyone here having a problem with. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] more GIMP foundation stuff
Hi again, I have almost completed all the paperwork to get The GIMP Foundation up and running. The last slightly compliciated bit left is to get the bylaws finished. I have a draft version of the bylaws that need a few gaps filled in. I've put it here: http://www.phasevelocity.org/bylaws.doc These bylaws get sent with the rest of the paperwork (and the filing fee) to the IRS to get tax-exempt status. This copy of the bylaws is pretty standard stuff, with parts that need filling in, highlighted in red. We are, of course, free to change the bylaws at anytime in the future (within certain limits), but we do need a copy of the bylaws, and a first board meeting held within the rules of those bylaws, where the bylaws are formally approved by the board. Here are the things left to do. Within a week I need to get the parts in red of the draft bylaws fleshed out at at least the majority satisfiaction of the community. In addition to the red parts, the membership section needs to be writtin. I need to appoint an initial board, whose job will be to set up a membership system, start collecting members, and allow those members to vote in a non-interim board (any takers?) I need to send in the corporate paperwork to the IRS (with the filing fee) and wait a few months for the IRS to send some questions answer those questions, and wait a few more months to get our non-profit status approved. Instead of all this though, I've been talking to Tim Ney about having the GNOME Foundation take a more active role in supporting the GIMP. If GNOME was willing to do this, this would probably be a good option for us. Gnome already has the infrastruction and ability to act as a non-profit, as well as plenty of corporate suppport. What do people think of this plan? -- Daniel P.S. Real life is taken over recently. I have a new child on the way, my wife is almost finished with school, I'm looking at grad schools, and I have a practical need to focus my work on the bits that I get paid a regular salery for. This means I have very little time for gimp related stuff recently. In fact, I'm looking to get TGF (or whatever this becomes) handed off to a competent interim board as soon as I can. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The issue of JPEG Patents?
Joao S. O. Bueno wrote: On Friday 23 April 2004 18:39, Alan Horkan wrote: http://www.theregister.co.uk/2004/04/23/forgent_jpeg_suit/ Has the issue of Jpeg Patents been brought up yet? (a quick but not thorough search suggests not) hmmm...What about waiting until october, and THEM start the Gimp Foundation? You can't sue what does not exist Honestly...I got scared for the GIMP when I read about the thou shalt not open scanned-up money images blurbs ... when I read about this JPEG patents, I did not even thought about the GIMP, because it's just too stupid. But..who knows where human greed can take us? Well you could still sue the plugin maintainer. but that is no point. It is greed drivin, thus there is a second, implict rule, thou shall not sue that which has no money. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Raphaël Quinet wrote: On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers [EMAIL PROTECTED] wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. You are bringing very good news here. Congratulations! The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Do you think that it should be on developers.gimp.org, or www.gimp.org? Maybe both? Anyway, I think that it would be nice to mention our sponsors somewhere. Maybe this should be discussed on the gimp-web list? Probably on the gimp-web list yes. I think it should be on www.gimp.org. Sponsers are important and affect everyone. [...] The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) Most of the milestones seem reasonable, but I have some questions about how the GIMP integration would take place, especially regarding the plug-ins. Many of the current plug-ins are making more or less the same assuptions as the core regarding the bit depth of the images, etc. There is a lot of code to be re-written in the plug-ins and I expect them to be broken as soon as the format of the tiles is changed. I also expect that it would be difficult to fix them before some parts of the core become more stable. Well, my plan is to port the plugins to gegl first, then change the tile format. This would mean that, for a time, both old style and new style plugins would work. I also mean a complete review of the plugins, with refactoring of the plugins into a gegl-node + gimp-gui, with a standard set of classes that each plugin is a sub-class of. I suppose that you did not include the plug-ins in your activity planning because that would be too much work for a single programmer (but maybe I am underestimating you? ;-)) So I am wondering how we will be able to coordinate the work and update the plug-ins. Will there be a phase during which there would be a call for volunteers for updating all of the plug-ins once the new interfaces to the core become more mature? Or would it be possible to provide some kind of backwards compatibility so that the transition could be spread over a longer period, with some plug-ins using the new API while some others would still use the old one through a compatibility layer? A transition period is certainly possible. I don't think I will be able to port all the plugins quickly (though I could probably nail 80% of them in a short time, some of them are quite complicated and/or broken). There is also no reason why volunteers can't work on any of this stuff. I am not claiming every piece of this as my territory, only saying I will work on it. That doesn't mean other people can't. And backwards compatability should be possible. There is no reason to make the old plugins stop working (at least for 8 bits per channel, RGB). However the plugins will be more or less broken in that, unless they are ported, they won't work with high bit depths, or different color spaces. What I really meant to say on #4 anyway is that I expect to port most, if not all of the plugins. There is really no other way to do it. I don't believe deep paint will be a useful feature unless at least 95% of our core plugins support it. Let me put a revised #4 4. add deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps (this is equivlent to adding high bit depth to the core and paint). -- b. design a new file format (this has already begun) -- c. convert all the plug ins to have a class structure and use gegl-ops. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Kelly Martin wrote: Dave Neary wrote: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage. Actually, yes. Though GimpDrawable, GimpLayer and GeglImage all need to be touched. I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense. I believe GimpImage is a set of GimpLayers. It might even be able to stay that way. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Dave Neary [EMAIL PROTECTED] writes: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them. What I mean is that everywhere it makes sense to _delegate_ to gegl structures things should be made to do so. I did misspeak about GimpImage, I know it is not similar to a GeglImage (more like a graph or somesuch). GimpImage and GimpLayer just need to be modified to do their image processing work with GeglNodes. -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. Damn it. yes. I meant delagation, not inheritance. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] again: burn function - how does it work?
Thomas Lübking wrote:
Hi.
After checking the i18n files i now know that nachbelichten is supposed to
be burn.
However, the appropriate function in app/coposite-generic.c does not seem to
behave as expected.
afaik the burn function should do nothing if the the upper (the burning) color
is white.
also a black pixel of the lower layer should remain black - whatever the upper
layer is colored.
However, this function:
while (length--)
{
for (b = 0; b alpha; b++)
{
tmp = (255 - src1[b]) 8;
tmp /= src2[b] + 1;
dest[b] = (guchar) CLAMP(255 - tmp, 0, 255);
}
if (has_alpha1 has_alpha2)
dest[alpha] = MIN(src1[alpha], src2[alpha]);
else if (has_alpha2)
dest[alpha] = src2[alpha];
src1 += bytes1;
src2 += bytes2;
dest += bytes2;
}
cannot provide this.
(e.g. upper (src1) is white (255) - tmp = 0 8 = 0; = 0 / ? + 1 = 0;
CLAMP(255 - 0, 0, 255) = 255 = white - so white will flatten anything instead
of leaving it as it is.
as a consequence, black won't remain, as soon as one of the components r,g,b =
255.
i tried to weight the effect (255-0)/255*burn + (1-(255-0)/255)*original...
but the result wasn't like what i expected.
Ok. First off you need to realize that your constants (8, 255, 0, 1)
are all integers (since they don't have a type specification after
them). Also tmp is an int. This means the chars get promoted and are
not doing 8 bit math: we are doing at least 32 bit math. This means
that 255 8 is not 0, but 65280. This also means that a black second
layer stays black and a white first layer leaves the original pixel
untouched.
Second, lets do our math in normalized RGB space so that RGB vary from
(0,0,0) (black) to (1,1,1). Lets convert the above equation to
normalized space.
tmp = (255 - src1) 8 / (src2 + 1).
dest = CLAMP (255 - tmp).
IF you want to convert to normalized form, you divide src1 by 255. Lets
call that src1'. Derive src2', tmp' and dest' in the same way. Then,
turning the bit shift into a multiply, and ignoring the clamp for a moment:
tmp' * 255 = (255 - 255 * src1') * 256 / (src2' * 255 + 1)
dest' * 255 = 255 - tmp' * 255
Factoring out 255 everywhere gives us:
tmp' = (1 - src1') * 256 /((src2' + 1/255) * 255)
dest' = 1 - tmp'
or
tmp' = (1 - src1')/(src2' + 1/255) * (256 / 255).
dest' = 1 - tmp'
I am sure that the original formula assumes 1/255 is aprox. 0 and
256/255 is 1 (since this saves a multiply, and prevents 1/src2 from
being evaluated as zero).
thus, the original formula, in normalized RGB space is:
tmp' = (1 - src1')/(src2')
dest' = 1 - tmp'
or
dest' = 1 - (1-src1')/(src2')
Also, with the condition that if src2' = 0, dest' = 0;
This is much more sane.
Now for the theory of burning.
Burning is a term from photography (the chemical and paper kind). A
burn is when you expose a portion of the paper beyond the normal
exposure time. Let me derive the formula of a real, physical exposure burn.
The aparent change in darkness of a photo as you add more light is of a
is propotional amount of light, exposure (Intensity * time), and the
current darkness of the photo. Lets make a simplification from the
begining. There is an inversion here. Bright light is a dark spot on
the photo, and dim light is a light spot on the photo, so we are going
to reverse our lights levels, so that we are referring to the
corresponding shade the light will produce on the photo. This forces
all discussion to happen in the photo colorspace. Lets call the
original photo brigness p, the new photo brightness p', and the inverted
exposure be I times delta t. The formula for the differential change in
brightness is thus:
- delta p = p * I * delta t;
Which is, once solve in closed form, an exponential decay. Exactly what
I would expect. At the very least, it is obvious that the above
equation qualitatily reflects the properties of an exponential exposure
time, assuming that a single interation represents some fixed (short)
extra exporsure time. I am not sure if this represents an actual
approximation. I don't acutally have any source material for burn,
except for the knowledge of want the process is.
On a related noted, I notice that a brush in burn mode won't burn white,
no matter how hard I try. That doesn't seem correct to me. Shouldn't a
burn darker a white area (it will darken everything up to 255)? Also,
same for dodge and black. Shouldn't a dodge lighten a black area?
--
Daniel
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image processing
[EMAIL PROTECTED] wrote: Hi Gianluca, This question has really nothing to do with Gimp unless you want to use already existing gimp functionality. You may e.g. read an image into memory though the gdk_pixbuf functions, and then access the pixel data through gdk_pixbuf_get_buf(). Working with the gimp API is more complicated as the data may be stored tiled, and your algorithm will need to do special case treatement of the boundries. You might also want to have a look at GEGL that provides a graph paradigm for image processing, and which will be used in future versions of GIMP. Whether someone has written optimized algorithms for it, I don't know. Um, if this person needs a solution now, then GEGL is not for them. IF this person whats to help write a solution, then GEGL might be good for them. Regards, Dov On Thu, Mar 18, 2004 at 10:12:02AM +0100, Mattiroli, Gianluca wrote: Hi to all, I am interested in doing some filtering on an image stored in memory as a Pixmap, with particular attention to the time constraints. Could someone give me some advice about the resources available for this purpose? Thank you. Well, all of our image processing attention is focused on GEGL which, while progressing, is not yet able to actually process images. If you need a solution now, and are not interested in helping write one then you have a few options (these are a bit off topic though, so don't expect any help with these beyond this). If you need open source, then pretty much, your options are: Vigra: http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ Vips http://www.vips.ecs.soton.ac.uk/ Rivl http://www.cs.cornell.edu/zeno/projects/rivl/Rivl-mm95/mm-95.html PDL http://pdl.perl.org/ I know there are a few other small image processing languages. These are all projects with pretty difference focuses. And one or the other may be more suited for you. If you want to try closed source solutions there is: Matlab IDL Java Advanced Imaging SGI Image Vision . . . many others . . . -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The Mark Shuttleworth offer
So, More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. I am pretty sure the offer essentially the software development bounties described here: http://www.markshuttleworth.com/bounty.html. Mark has said Calvin and I should divide 30,000 dollars between each other and the milestones. We (Calvin and I) are paid when the milestones are delievered with the following conditions (from the Mark's bounty page): Once the code is accepted, to the satisfaction of people identified before you started (for example, the project owners if it involves work extended an existing project), we pay the agreed bounty. Calvin and I have already decided how the money will be divided between each other. What I want to do here, is first announce that Mark is funding GEGL (and thus the GIMP) and second to pass my milestones through the list to make sure they are sane and achieveable. Keep in mind that this milestone list is not a list of work for other people (though other people are free to work on it). It is a list of tasks which I am bound to fufill, contractually, and are things that I _will_ do. I am not obligating anyone to do anything. I am simply confirming that my plan is acceptable, before obligating myself to it. The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. First my milestone list, as I sent to Mark Shuttleworth. Please tell me if it is sane. My time for completion estimates are assuming one programmer working full time. They are also only relevent it that I will use them to help divide up the bounties. The bounties themselves don't have a time limit. You may also make suggestions on how I should divide up the bounties. I'll just divide by the time I think I'll need by default. The end result of these milestones is to add features Mark wants, so I can change the way or order I get to them, but the features achieved should not be changed. The order givin is the order I think I should approach things. The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) 1. Finish gegl/image () Goal: gegl/image is the directory that holds the data access libraries. It should contain the abstractions for high-bit-depth and multiple color space manipulations. () Time for completion: about 1-2 months -- a. finish up my nearly completed tile caching code -- b. implement color space classes -- c. write gegl-image can gegl-color 2. clean up nodes () Goal: This will bring gegl all together. Modify the existing node system to handle the new image data types, and get a strong core of basic image processing nodes. Also, build a few image i/o nodes and actually build one or two gegl test programs that actually manipulate image data. One might argue that this step would finish gegl. () Time for completion: 2-3 months -- a. make nodes work with new gegl-image stuff -- b. design processing model that can handle multiple data types and sample models -- c. implement the base set of core filters new filters -- d. implement different bit depth processing functions (prioritizing by what the gimp needs) -- e. make gegl work 3. begin gimp integration () Goal: This puts abstraction in place to actually start handling image high bit depth and color management. () Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor. 4. start adding deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float). 6. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painting
Re: [Gimp-developer] The GIMP Foundation
Nathan Carl Summers wrote: Is this required to be in person, or is conference call/irc/email/etc sufficient? Furthermore, is it possible for board members to be reimbursed for expenses? I can see this being a major obstacle for non-us residents otherwise. Kelly already answered the first part, but yes. If TGF has money, it's board members can be reimbursed for the expenses of attending a meeting (including phone bills, even), without destroying it's non-profit status. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] The GIMP Foundation
On Mar 8, 2004, at 8:25 AM, Kelly Martin wrote: Dave Neary wrote: Daniel Rogers wrote: Avoid self-dealing. What's this? Self-dealing is whenever the people who control the organization command the organization to do business with themselves in their personal capacity. Self-dealing tears the veil and makes the director or officer who engages in it personally liable for the corporation's debt by creating the presumption that the corporation is an alter ego of the individual. In the case of a non-profit, it also violates the rule against private inurement. this is true, but it deals more directly with, as a board member, arranging a deal between The GIMP foundation and a board member. Self-dealing is when, for example, you own some property that you wish to sell to TGF and you are on TGF board. You have to do some full disclousure, follow very specific rules, and making too much money is frowned upon. Really it is not so much about avoidance (but that helps) as much as it is about following the rules. California and the US are very picky about making sure that non-profits are not used as a vehical to profit the board members. It means, inter alia, that the directors of the non-profit cannot also receive money from it except possibly a small stipend and reimbursement of their expenses in attending board meetings and other organization functions. Being a member of the board of a non-profit organization is charity work: you generally cannot expect to get paid. this is not true, actually. 51% of the members have to be disinterested. It means that 51% of the board members cannot themselves or anyone related to them be paid (except the stipend and compensation you mentioned). Related, here, has a very specific definition. It means that if there are four board members, and I am getting paid to hack on gegl by TGF, then none of the other board members can get paid. It also means that if I hire my wife to do some work, then I am interested and no one else (or their relatives) on a four person board can get paid. If you're looking to get a job with the GIMP Foundation, you can't also be a member of its board of directors (except as an ex-officio member, which the Executive Director typically would be). This doesn't mean that the Foundation can't hire staff, just that those staff can't be the ones making the ultimate decisions on how to spend the organization's money. Again, this is _not_ true. More than half must be volunteer though. Staff can recommend, but final approval of at least the general budget has to be by the volunteer board. This bit is true, except that the board must simply be more than half volunteer. To do otherwise risks a finding that the organization inures to the benefit of a private party, which destroys non-profit status. There are of course, other ways to destroy non-profit status, such as getting too much regular funding from a single source. I'm very interested in the idea of a Foundation and would love to be a part of one, but I have no expectation of it turning into a personal revenue stream. Again, if you are a board member, you could get a job with TGF. But seeing how TGF, at this point, is not exactly handing out jobs, I would agree with this sentiment. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The GIMP Foundation
Hello again, It has been awhile since I have done a GIMP Foundation update. There is quite a bit that must be decided on at this point. Also, people need to decide how invovled they would like to be. Summary: My Goals, Benefits of incorporation responsibilites of those invovled things to be decided looking for help What the organization can do MY GOALS First off, let me go over several of my personal goals for The GIMP and then I will try and show now TGF can be used to develop these goals. My goals for The GIMP really boil down to three things. First, I really want to see The GIMP to be a household name for professional image editors. Second, I want to the GIMP as easy as possible for volunteers to contribute to. Third, I want to be able to turn The GIMP into a real, paid, career for a team of people, including myself. As such I have been trying to further these goals by creating TGF, soliciting funding, and trying to come up with ways of using that funding to further these goals. Let me make perfectly clear that my important priority is to make sure that our existing volunteer developers are, in no way, givin any additional responsibilites or risks that he/she did not ask for. I do not want (nor do I think it is possible) to try and control or be in charge of our existing volunteer developers. No one, though my actions or those of The GIMP Foundation, will be required to perform any duties, or have any additional responsibities placed on them without his/her consent. What I want is to create an organization that can handle many of the details that do not interest a casual (or even not-so-casual) volunteer. There are quite a few things that could be done to increase the popularity of The GIMP that could be done easier under the organization of TGF. Marketing, making contacts, hiring employees, solicting donations, etc. are all difficult and valuable activities that could benefit all the developers, including the volunteer ones. I want to put in place means to increase oppurtunites for all of our developers. Increasing our userbase, attracting developers, attracting corporations interested in The GIMP will undoubtably lead to more and better opportunites for existing developers. BENEFITS OF INCORPORATION Presumably, I could handle all of these things myself, without creating a legal entity to do so. However, the existance of The GIMP Foundation has several legal benefits: 1) The GIMP Foundation can enter into contracts and acquire loans and, as long as the Directors act in Good Faith (and follow some fairly simple rules) cannot be held liable for any actions of TGF. This means that if TGF enters into a contract with a corporation (such as accepting a donation to finish a certain feature in The GIMP) and 50% of the way though the feature the corporation decides they want their money back, the individual directors and members hold no personal responsibility to pay back that corporation. 2) TGF can offer tax deductable donations. 3) We become qualified for Federal, state, and private grants. The first provision above is probably the most important. It means that if you follow the rules, there is no risk (other than the time you put into the organization) to running it. It also means that TGF can enter into contracts with people like Mark Shuttleworth and the individual members, directors and officers are not at risk of losing any personal funds. RESPONSIBILITES OF THOSE INVOVLED Non-profits have to have certain organizational structers. There must be a board of directors. The board has the power to enter into major business dealings, decides what to do with assets, and has to the power to hire officers. The officers handle the day to day business of the corporation. However, being invovled with The GIMP Foundation means you will be held to certain responsibilities. If you are a board member you must: Attend board meetings. Vote on specific issues. Avoid conflict of interest. Avoid self-dealing. Be honest. Be careful with the funds of the Foundation. fufill any other specific duties outlined in the bylaws. Board members have the power to: Enter into contracts in the name of TGF. make finantial decisions about the future of The GIMP. hire officers. Officers are empowered to handle the day to day decisions of the board. They are not normally empowered to enter into major business dealings, and the board is responsible for their actions. They must also fufill any responsibilites outlined in the bylaws. In addition, 51% of the board members have to be disinterested. (this means they or anyone related to them cannot be compensated by TGF for other than as a director). I.e. 51% of board members have to be volunteer. Also there are no residency or age requirements on any of these positions. (though the board members should be at least 18 so that they have the ability to enter into contracts). A non-profit may or may not have members. Members (in the legal sense) have specific voting
[Gimp-developer] more gimp foundation stuff
Here is few notes to address a few more concerns I have encountered, I'll pose them retorically. 1. I heard that some people have been asked to be on the board, why weren't the developers consulted? I'm a developer, why wasn't I asked? Who are these board members? In California every corporation that has not applied and achieved tax-exempt status from the IRS has to pay an 800 dollar franchise tax. In order to get tax-exempt status, you must meet certain requirements, write your bylaws, have your first board meeting, and attach the bylaws and the minutes of your first meeting to the tax-exempt form and set it to the IRS (and the state franchise tax board). At some point, I needed to make sure that there would be sufficient interest in being board members to be able to have the first board meeting. Otherwise, seeing how I am the only board member at the moment (every corporation needs one initial board member) I would have to pay the 800 dollar franchise tax fee. I didn't want to do that. I also didn't know if non-US-residents can be on the board, so yosh and I came up with a list of all US contributors and interested people and sent them mail asking about being TGF board members. Yosh, Mat, Nathan, were the ones who expressed interest at the time. This meant I had enough poeple interested that I felt I could contine without undue risk to myself. They are, in fact, not board members, though it seems likely that they will try to become one. I can't elect new board members until the bylaws are written (and, in fact, if the bylaws define a voting membership, I _can't_ elect. That is the members job). Now that I know that there are no residency requirements and and the only age requirement is 18 (so that you can enter contracts) I've asked (in my last mail) more generally, and with greater specificity, who would like to be involved. 2. Will The GIMP Foundation have a steering committee? No, not exactly. The GIMP has always been a contributor driven project, and I see no reason (or even ability) to change that. If TGF has an object called a steering committee it will only be able to be in charge of TGF employees. Noone is going to be telling volunteers what to do (unless of course, they are specific volunteering their time to TGF, but that is another matter entirely). 3. This thing is still vague to me. Aren't you assuming you will have money? What exactly is it supposed to do? Why should I care? Why should I get invovled? Why should I not get invovled. Yes, I am assuming we will have money. Without money, this whole thing is just an exercise is futility. Getting more money will be one of this things TGF will need to focus on. More or less, the purpose of TGF is to provide a public (and scientific) service by ensuring the distrobution, and development of The GIMP. What this boils down to it getting and spending money for the good of The GIMP. You should care because the money will be spend to support your activities (and perhaps even compensate you directly). You should get invovled if you want to have a say in how that money is spent, or want to get invovled with The GIMP in other ways. Undoubtably marketing style stuff will have a place in The GIMP, and I already know that there are more than a few non-technical people interested in contrubting to something like that. The only reason you should not get invovled is if you don't want to spend the time on it. By the nature of a corporation, no one is personally liable, so there is no risk for getting involved (including, but not limited to, protection for lawsuits and bad business deals made in good faith). Please let me know if anyone has and more concerns. I will address them as best I can. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp on OS X
Daniel Egger wrote: On Feb 25, 2004, at 11:27 pm, Daniel Rogers wrote: sysctl -w kern.sysv.shmmax=41943040 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=320 sysctl -w kern.sysv.shmseg=80 sysctl -w kern.sysv.shmall=10240 DUH! How could I possibly forget about sysctl. That doesn't seem to work though: lucy:~ root# sysctl -w kern.sysv.shmmax=41943040 kern.sysv.shmmax: 4194304 - 4194304 lucy:~ root# sysctl -w kern.sysv.shmmin=1 kern.sysv.shmmin: 1 - 1 lucy:~ root# sysctl -w kern.sysv.shmmni=320 kern.sysv.shmmni: 32 - 32 lucy:~ root# sysctl -w kern.sysv.shmseg=80 kern.sysv.shmseg: 8 - 8 lucy:~ root# sysctl -w kern.sysv.shmall=10240 kern.sysv.shmall: 1024 - 1024 Yes, in fact it doesn't. I played around with this quite a bit. The explanation requires understanding how the startup sequence works and mach security modes. The first process run by Mac OS X in the normal boot-up sequence is init, which begins in mach security mode 0, and very shortly moves to mac security mode 1 (I belive man init explains this). In security mode 1, thos sysctl values can only ever be set _once_. Since they are set in /etc/rc, which is the first thing that init runs, you cannot change them after that. This is why you need to edit the rc file and reboot. If you are in single user mode, which explictly is in security mode 0, then you can set these values as many times as you wish. Judging from the way the rc scripts are set up, I am guessing that these values are not so restricted in the server version, though I haven't tested it. This goes back to the question as to why apple would restrict you from changing the values after boot, and why they would set the defaults to low. Who knows? Who cares? but you do need to edit /etc/rc to see any effect. Servus, Daniel -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp on OS X
On Feb 25, 2004, at 2:12 PM, Daniel Egger wrote: On Feb 25, 2004, at 10:11 am, Sven Neumann wrote: Did you increase the shared memory limit? I am not sure what happens if it the X server hits the limit but I guess it just silently stops allocating more shared memory. Err, I know somewhat how to mess with POSIX SHM in applications but how can I change the shared memory limits? On mac os 10.3, in /etc/rc Look at the lines: sysctl -w kern.sysv.shmmax=41943040 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=320 sysctl -w kern.sysv.shmseg=80 sysctl -w kern.sysv.shmall=10240 This is already adjusted by a factor of 10, which will probably help things, but feel free to adjust it higher. keep shmmin=1 the same though. Then reboot. On mac os x client, these adjustements only work the first time you set them, so comment out of old lines or replace them entirely. In mac os 10.2 and eariler, there is a similar thing done in the startup script SystemTuning or somesuch, but I don't have a 10.2 system to investigae. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
There has also been discussion about some MDI type interface, although the main developers seem dead against it, mainly on account of that they feel this is something that should be solved using the window manager, not the application. Please note that GIMP does MDI (multiple document interface) already, it just doesn't folllow the WiW (window in window) approach that some people seem to prefer for obscure reasons. A good window manager makes the window-in-window concept unnecessary. However if someone wanted to develop such an approach for all the poor users that are forced to use a not so advanced window manager, then it should probably be addressed at the toolkit level. What Sven is saying, is that it is basically impossible to get Window in Window support working on linux. You can do it, but is sucks a whole, whole lot. On Windows, the best approach will be to add support for Window-in-Window to gtk+ our gui toolkit, as that kind of feature shouldn't be implemented in the gimp. -- Daniel pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Sven Neumann wrote: All of this would probably be best solved by redoing Script-Fu using a full-featured and actively maintained Scheme implementation. Might I suggest Guile? http://www.gnu.org/software/guile/guile.html It seems almost ready made to be stuck into the gimp. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Simon Budig wrote: Marc Lehmann ([EMAIL PROTECTED]) wrote: On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney [EMAIL PROTECTED] wrote: Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD? As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own. (These are not my arguments, I just repeat what I think was one of the bigger points back then). It was a point that I indeed support very strongly :) IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well). I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him drop this file in that directory and invoke it and I don't have to care whats his platform and what interpreters are installed. This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library. Isn't that what installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle. The problem I see with this argument is: You are turning a packaging problem into a design choice. Suppose, for example, we choose to make siod a seperate dynamically linked library (included in the gimp sources, even). What is the difference between forcing you to install soid, and forcing you to install guile? The not-creating-another-depency argument is an illusion. soid is already a dependency. It is just a dependency we choose to include in the sources. Why did we do this? Is jpeglib included in the gimp source tarball? What about libppm? libpng? These are all dependencies. Should we include those in the tarball as well? It is true enough that you can argue that jpeglib is not as important as siod because you can disable the jpeg plugin on the configure command line. But this can be true for soid as well. While I don't immediatly see a ./configure option to disable script-fu, there is no technical reason why we can't have a configure option that disables script-fu. In fact, because you can disable script-fu, you cannot gaurentee that there exists a script system at all, let alone script-fu. Basically, the only real way to ensure that every single instance of the gimp has a scripting language installed is to package the gimp for every platform ourself. Not moving to something besides siod is *crippling* to our supported, which should be the best, extension language. So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates. Guile is in all ways superior to siod, and is even self contained. We could even include a version of Guile in the tarball, which is what we do now with soid anyway. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gegl query
Jakub Friedl (listy) wrote: it would be nice. btw, how far is the gegl development? when we can expect gegl based release of gimp to be made? 2005? I have been working on the pixel access stuff, some ICC colorspace classes using lcms, and some swap stuff. That should be done in a few weeks. The node stuff (of which there is aready a good chuck of it in CVS) will be done some months after that. It all depends on my (and calvins) free time of course (unless someone wants to pay me ;-)). gegl introduction is slated to begin with the next developers version after 2.0, though we have not set any dates as to when that will lead to new features nor have we decided how this will proceed. Hopefully it won't be that long to a next stable release of gimp. It would be nice to see it in 2004 (albeit late 2004). -- Daniel pgp0.pgp Description: PGP signature
Re: [Gimp-developer] gegl query
Daniel Rogers wrote: Hopefully it won't be that long to a next stable release of gimp. It would be nice to see it in 2004 (albeit late 2004). I have been asked to point out that is is my opinion and noone has made any specific plans. (From talking with other open source projects, 9-12 month release cycles keep interest high). -- Daniel pgp0.pgp Description: PGP signature
Re: [Gimp-developer] after the prerelease
Sven Neumann wrote: Hi, OK, the prerelease is out and the first bugs were found and fixed. After the prerelease is before the prerelease. We still have about 70 bugs on the 2.0 milestone. Our goal should now be to target this list. Not all these bugs need to be fixed before 2.0. A few, especially feature requests, can be postponed to 2.2. At some point we can also move some remaining minor problems on the 2.0.1 milestone. But all these bug reports need to be revisited. So if you have some spare time, please do a query on the 2.0 milestone and check if you can comment on some of these. Some links that are relevent, just to make things a little easier for everyone. The bugzilla query page for the prerelease. There is a bug in the query page, it seems, and the milestone is not properly read from the CGI query string. You will have to input the milestone (2.0) by hand. http://bugzilla.gnome.org/query.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=REOPENEDbug_severity=blockerbug_severity=criticalbug_severity=majorbug_severity=normalbug_severity=minorbug_severity=trivialbug_severity=enhancementtarget_milestone=2.0email1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1changedin=chfieldfrom=chfieldto=Nowchfieldvalue=short_desc=short_desc_type=substringlong_desc=long_desc_type=substringbug_file_loc=bug_file_loc_type=substringstatus_whiteboard=status_whiteboard_type=substringkeywords=keywords_type=anywordsop_sys_details=op_sys_details_type=substringversion_details=version_details_type=substringnamedcmd=gimp+pre-2.0+blockersnewqueryname=gimp+2.0+blockersorder=Reuse+same+sort+as+last+timeform_name=query The bugzilla bug list for pre-2.0 http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=REOPENEDbug_severity=blockerbug_severity=criticalbug_severity=majorbug_severity=normalbug_severity=minorbug_severity=trivialbug_severity=enhancementemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1changedin=chfieldfrom=chfieldto=Nowchfieldvalue=short_desc=short_desc_type=substringlong_desc=long_desc_type=substringbug_file_loc=bug_file_loc_type=substringstatus_whiteboard=status_whiteboard_type=substringkeywords=keywords_type=anywordsop_sys_details=op_sys_details_type=substringversion_details=version_details_type=substringnamedcmd=gimp+2.0+blockerscmdtype=runnamednewqueryname=order=Reuse+same+sort+as+last+timeform_name=query These should both be one one line, so edit accourdingly -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] I don't usually post remove requests to the list...
Michael Graff wrote: But, will the list maintainer PLEASE remove me? I have followed the http links in the headers. I have mailed the email addresses in them. I have mailed [EMAIL PROTECTED] I have gotten no replies, or results. You are forgivin. Our lists have been broken for some time. They were fixed today. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] I don't usually post remove requests to the list...
Daniel Rogers wrote: Michael Graff wrote: But, will the list maintainer PLEASE remove me? I have followed the http links in the headers. I have mailed the email addresses in them. I have mailed [EMAIL PROTECTED] I have gotten no replies, or results. You are forgivin. Our lists have been broken for some time. They were fixed today. I my excitement about our lists being fixed, I forgot to make it explict: you should be able to unsubscribe now. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [gimpwin-users] Re: Gimp 1.3.23 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tor Lillqvist wrote: | Tor Lillqvist writes: | Possibly the lcms.dll in the lcms11.zip file isn't suitable as such | to be used from GIMP, but will have to be rebuilt from source. | | Yes, that seems to be the case. I don't know the technical reasons, | but when I built the lcms DLL from sources (a rather simple | ./configure --disable-static make job), no crash any longer. | | Still, as I really don't understand colour management very well, I'll | leave it to others to say whether it is useful or not. (In fact I am a | bit colourblind, so I have wondered whether it even would make any | sense for me to try to use a colour managed workflow for my digital | photo workflow at all ;-).) There has been some work done to try and use color matching software to do color matching and proofing for color-blind people. This has been mostly done as accessibility research. I think prepress applications can be found as well. This is not the original link I found, but it is pretty good: http://www.internettg.org/newsletter/mar99/accessibility_color_challenged.html This is actually a fairly well researched topic, and I believe the Meyer article was the original source I red on this topic. As for learning about how to apply color management, Real World Color Management by Fraser, Murphy, and Bunting is pretty good, with only a few probably-insignificant for pre-press mistakes. - -- Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/yMBKad4P1+ZAZk0RAoqCAJ0ScDIL3EWQPSYfs1GP0xRwfUXXkwCgpo7b mC8XYN8nkWUxPndQhRjGOSw= =fiso -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] multilayer tiff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai-Uwe Behrmann wrote: | Hi, | | Am 27.11.03, 13:42 +0100 schrieb Sven Neumann: | | |There is no way a GIMP plug-in can support multiple versions and even |a completely different app and at the same time be readable and |maintainable code. In my opinion the version included with GIMP-2.0 |should be a plug-in for GIMP-2.0 and nothing else. I also don't see |why we should not continue to use our working TIFF plug-in. This |plug-in works, is widely tested and has a maintainer. In my opinion |what we should do is to integrate some functionality of your plug-in |into the TIFF plug-in as found in CVS. I would suggest we start by |adding support for multi-page TIFF file and look into color conversion |routines as soon as GIMP-2.0 is released. Sven, I think what he was saying (and please speak up if I misinterpreted your english) that he would like to become the current maintainer of the current tiff plugin. I certainly see no reason why this person can't have responsibility over the current plugin as long as he doesn't revert the improvements made to the gimp-2.0 plugin. Also, the best way of gettting rid of the #if's would be to put some app specific functionality into a seperate file and compile or include only one driver file for the tiffreader plugin. I am all for this. I suspect, though you haven't said, that you are also working on the CinePaint plug-in. It would be good to share as much code as possible between our projects, IMO. At worse, you can put it all in the same file and #if away the block of fuctions specific to a certain app, which is _MUCH_ more readable then having #ifs in the middle of the code. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/xjJkad4P1+ZAZk0RAtx5AJ4tIIAVULBetzp0XY8HeN11Z3GUagCgptEm LS/AmAijpqq/NggerS9q7xs= =jSki -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at GUADEC
David Neary wrote: Hi all, Following up from the mail last week discussing the date and location of GIMPCon, here's the state of play on the various possibilities discussed. 1) GUADEC: The GNOME crowd are delighted to have us, the guadec planning committee are very eager, and are now planning a graphics/multimedia stream for the conference. I am now on the guadec-planning mailing list, and if we go to guadec I'll be co-organising the graphics stream (I wonder why I asked for a volunteer to do this...). cut So the situation as it is is that we should decide pretty quickly where we want to have the conference. Does having it at GUADEC pose any problems for anyone? Personally I think this is the best option available to us, even if it will pose us some fundraising problems. I like the GUADEC idea technically. From a personal, selfish, un-gimp-like, I want to see the world point of view, London, Lyon, and Dublin have been on my list of places to see for quite some time. However, I think GAUDEC, especially since they are excited to have us and are sound willing to accomadate our needs, is better for us as a project. I am not sure if there are going to be fund raising issues, per say. We are probably one of a relativly small set of projects going that don't have any regular funding, so I am willing to wager that the funding will be no more trouble for us that it is normally. Also, as far as volunteers go, obviously I am not the best person to be planning anything happening in Europe (at the very least my sleep schedule couldn't handle it). However, if you have anything you would like or can be delagated to me, please ask. For our part, it would be nice to see 2 or 3 papers presented by GIMP people, and the organisers have asked whether it would be possible to have GIMP demonstrations similar to the one that jimmac did last year. The papers could be quite in-depth and technical, given the nature of GUADEC, or could be more aimed towards users and have a tutorial feel to them. I should really give a presentation on Gegl there. This would encourage me to get off my ass and write technal white papers discussing the huge about of planning I feel I have put into gegl. This would be good for me, too, as writing down ideas always provides a good oppurtunity to improve on them. Also writing down ideas provides a good chance for people to critizie those ideas, which would also be good. So - speak up. What do ye think? Are we going to GUADEC? Should I continue exploring Lyon in case it doesn't work out? Are there other possibilities? What are your feelings here? Do you think there is a chance GAUDEC won't work out? -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai-Uwe Behrmann wrote: | Am 20.11.03, 21:10 -0800 schrieb Daniel Rogers: | | |I am working on an api for this in GEGL. It is probably best to use the |system api's, when available, since there are already methods to plug |lcms into the exisiting system api's (on windows and Mac OS X) as a CMM. | | | This would be fine for unix based systems too. Are there any plans to | create an system interface for X to plug-in an CMM? | Do You know someone allready working on this? yeah, I am working on this. Hopefully, I will be going to talk to the X.org and freedesktop people in December. | |~ There will be an abstraction in GEGL for this. Eventually, I am going |to try an get it moved to the freedesktop.org people (and into gtk). |But that is quite a long term goal. | | | Can You provide more informations about the current state of CMS in GEGL? asking about the CMS in GEGL is really asking about the current state of LCMS. LCMS is a pretty darn complete color management system. And there isn't a lot of solid information. I know what I want to do, I just need to do it. Ok, so I avoided the question. Do you want me to discuss technical details of how I think colormanagement will work in gegl? - -- Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vjLYad4P1+ZAZk0RAlSoAJ99xIpYFjvU/SwLsoM7ycGYnFgksQCffwU/ PGXujXw8vKC9loidpL3+jVM= =t8ym -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Re: Fwd: [GUG] CMYK under Gimp.
GSR - FR wrote: [EMAIL PROTECTED] (2003-11-21 at 0834.36 +0100): This would be fine for unix based systems too. Are there any plans to create an system interface for X to plug-in an CMM? Do You know someone allready working on this? apropos Xcms should give you some man pages, here it does. If one checks the background of X11 (ie, Silicon Graphics machines) it sounds logical to have such thing, I have heard that some people have used custom LUTs to do film work with plain Linux too... so it is all about lack of publicity and docs, I guess. Ah, well I interpreted this slightly differently. While X11 does have color management support, it is not as good as lcms, and doesn't support the concept of CMM, which is what I really thought he was asking about. Pro people like to be able to buy Color Management Modules and plug them into the exsisting system apis. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] COMDEX debrief
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is my defense of carol's arguments. 1. Yosh is pretty darn right about who did what with regard to COMDEX. 2. I don't feel a need to justify my role here in this community to you. ~ Especially since no one else seems to mind my commitment. 3. Everyone starts out with no plan. I worked furiously over the next few days to prepare for COMDEX. I did not arrive there without a plan. 4. AFAIK, no one else spoke up or wanted to go. Many people did offer help, which was invaluable to preparing for this whole thing. I put it out on the list as soon as I knew I was going, and gave everyone else as much oppurtunity to contribute as was possible considering the short time frame. Now, for the real debrief. First, read yosh's email about how ORA sent us to comdex. It is pretty accurate. The setup was a follows: ORA gave each of us a pedestal on which I set up my desktop (I don't have a laptop, and yes, I hauled that thing from my hotel room to the COMDEX floor (they told me no carts) (next time I am buying a laptop)). On the floor, I had net, and a four hour block each day to give demos to passerby and watch the talks that were happening on the big screen nearby. The eclipse, plone, zope, kde and open office people were all quite cool. You may notice with that list that the gimp was the only project there without corporate funding (yay us! :-)) I demoed the text tool, layers, channels, tablet support, the vector tool, dnd stuff, the levels tool, dockables, grey point correction, color map rotation plugin, some general image enhancement, and red eye removal. About half the people that showed up had never heard of the gimp before. The other half were people that had already used the gimp and were really excited by the new features in CVS. I met many people. I met two CEO's who had moved their entire company to linux, including moving their graphic artists to the gimp. I ran into about 6 or 7 pre-press people who liked the gimp, and were intrigued about future CMYK support. So there was a lot of getting the word out, which is good. There were four events that I consider the most significant as far as short term gimp plans go: I met Leon Shiman, of X.org who told me he, really wants the GIMP to be a part of X.org and invited me to go to Cambridge, (Mass? (MIT)??) in December to be a part of their next meeting. He discussed how X.org (no longer the X Consortium) is totally reorganizing, and strongly believes that everyone who depends on the xlib (including major graphics applications) should be at these meetings and be providing input. Aparently, it is really easy and cheap to join X.org now. I mentioned that we are working on colormanagement stuff, and I was looking in particular at the Xlib color management stuff, and that we would really benefit from a standard way to copy image data to the X clipboard (afaik, there isn't a standard way to do it) and he reaffirmed his desire to see the gimp represented at this and future meetings. He told me he started the first graphics course at MIT and that he has a special place in his heart for graphics. He also mentioned that there is funding to help pay for travel to the meeting. (freedeskop and gtk will be there, I believe, as well). I need to talk to Dr. Shiman for more specific information, but I think one of our programmers should be there (I am willing to go, but I am not sure if I am able yet), and it would be worth discussing the sorts of things that would good for use to see extended in XLib (or by extension gtk or freedesktop, who I believe will also be at this meeting). He also mentioned that he had seen Simon give a talk about gimp as declared that Simon gave a really amazing GIMP talk. (go Simon!) I met a CEO who was surprised that The GIMP had no corporate funding. He asked me to talk to him after the gimp foundation was started. This is the closest thing I have gotten to a direct offer of money for the gimp, which is awsome. I talked with Tim O'Reilly (a cool guy, btw) about the Gimp Foundation. ~ He gave me some good advice. He suggested that I avoid trying to spend all my time making money. Things like the EFF (which aparently he has been a part of) spend a lot of time and money on fund-raising, and if that isn't your thing, it can be draining, and not very fun. He also said, though, that if I think there is real interest (which I do) then it could be possible to gather funds without pounding rock. He also suggested attaching ourselves to another non-profit organization, like Apache or Perl and trying to offload some of our administration costs by using them as an umbrella organization and gave me the names of the people I should contact about this. He told me that even though it is a non-profit, that I should be looking at it as a business. I should be trying to figure out who our users are, figure out what they want, and figure out how to get more users, because that is what will
Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai-Uwe Behrmann wrote: | Am 18.11.03, 22:49 +0100 schrieb Sven Neumann: | | |correction filters. If these plug-ins and modules all use lcms and |share ICC profiles by means of gimprc and parasites, you could use | | | Have gimps configure an header check for lcms allready onboard? This | would help plug-ins to easily link against liblcms? I am working on an api for this in GEGL. It is probably best to use the system api's, when available, since there are already methods to plug lcms into the exisiting system api's (on windows and Mac OS X) as a CMM. ~ There will be an abstraction in GEGL for this. Eventually, I am going to try an get it moved to the freedesktop.org people (and into gtk). But that is quite a long term goal. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vZ5gad4P1+ZAZk0RAuVDAKCRS6p+8Vz2BbW3e6D7SxhMJ3iooACfWfvs IW22eyXeFgylASqfV5jWMQk= =fe6n -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP at COMDEX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Evening GIMPers, Gimp is going to COMDEX. I just found out that I would be able to go tonight. Now I am kinda panicing about the kind of things I should present. Here are some quick ideas, before I go to sleep. If anyone has anything in particular they think I should consider discussing, please bring it up. IF anyone has any help they would like to lend, (previous presentation notes, for example) I would greatly appericate any time you could give me. Gimp demos. Show off some of our killer features. Any ideas as to what these might be? (layers, brushes, plugins, script-fu) Tips for working with the gimp in a corporate enviroment. (examples of previous corporate help would be great). Buy a programmer to add features. Strenths of open source, weaknesses of open source. Future gimp plans (gegl, high bit depths, color management). Ok, it is late and I need to sleep for work tomorrow. Cool screenshots, example work, and anything gimp related would be great to send to me. cl0kd already sent me a screenshot of gimp 1.3.x running on macos 10.3! Thanks everyone, - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/sy8Zad4P1+ZAZk0RAh+AAJ4/EyV5QnXMhd6Io/Qp/j2xWGHDZQCgjEZE 2WX2qc9DChtw0M7ZqCYYZ7w= =oMbv -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Major corrections in Curves and Levels dialogs.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Neumann wrote: | Hi, | | Piotr Legiecki [EMAIL PROTECTED] writes: | | |1) Levels dialog - *linear* histogram as in histogram tool. | | | I've done some changes and the histogram scale is now part of the | tool-options of all tools that use a histogram. This means you can | choose between linear and logorithmic in all those tools and the | setting is remembered across sessions. So, as an image processing programmer these linear and logarithmic discussions are confusing me. So, by linear, do you mean a histogram of the raw image data with no transform, and by logarithmic do you mean a histogram of the log of the raw image data? (linear to me usually means linear-light (e.g. intensity from physics), which would be proportional to your log scale here, assuming we are trying to operate in sRGB space, which an inherent gamma factor of 2.2). | What I am unsure about (and that's why I added the user list to the | Cc:) is whether we should change the default histogram scale to | linear. I know that you, Piotr, will vote for this change but I would | like to get a second opinion. This perhaps also depends on what other | apps do and since I don't have much experience with other | applications, I am asking here. To illustrate the question, I made two | screenshots: Well, if I am right about your definitions above the default should be linear. Here is the reason: Linear is perceptually linear I.e. a small change at any point in the histogram is perceived as a uniform change in brightness at every point in the histogram. E.g. 230+5 is percieved as about the same change as 30+5. This property doesn't hold for linear-light (i.e. logarithmic) and thus is more difficult for use human-types. This property is one of the reasons non-linear-light encoding (like sRGB and L*u'v') are such a desirable space to work in. (For you more technically minded, perceptually linear spaces also distribute errors (quantization or otherwise) across the entirtly of the percieved spectrum, rather than letting them seem to all be located near the darkest points). - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/mUVBad4P1+ZAZk0RAuFwAJ46kQ/2KPoc7HOoUAK1oJJPz4RzgACfYA2M HeE7DtfERjoC6Eq3fHMicJk= =CK/G -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Major corrections in Curves and Levels dialogs.
Piotr Legiecki wrote:
Hello Guys,
For a long time we were waiting for GIMP to become a real pro tool for
serious photographers. The scarcity of well designed tools for UNIX is
obvious. What *have to be* changed as soon as possible:
1) Levels dialog - *linear* histogram as in histogram tool.
Grey point should use Gamma settings as follows:
User click on grey surface no matter what lightness it has and Gimp
calculate Gamma using pure Gamma model:
R'Gamma = log(Grey)/log(R') ;
G'Gamma = log(Grey)/log(G') ;
B'Gamma = log(Grey)/log(B') ;
Grey = 0.299*R' + 0.587*G' + 0.114*B' ;
This is good stuff. I have been aware of these problems, and I am incorporating their
solutions into the compositing core that will eventually become a part of gimp (gegl).
What you are essentially describing is the Rec. 601 converstion from nonlinear RGB to
nonlinear video luma, and then calculating the the correction factors on RGB by pulling
out gamma correction on the non-linear RGB.
The actual coefficients there depend on the calibration of your monitor, and the
colorspace in which the image was captured and in most cases what you want is sRGB, not
Rec. 601 (which is fine for video, but not so great for computer monitors). I don't have
the sRGB coordinates off hand, but I did take note of them. But what gimp will do in the
future is request that the color management system convert the luma, which hopefully will
have an ICC calibrated profile to back the transformation.
2) Grey point (and histogram) inside Curves Dialog using Shlick
mapping method:
p = ( Grey*({R'G'B'}-2^bits) )/ ( {R'G'B'}*(1-2^bits) )
{R'G'B'} = p*{R'G'B'} / ( p*{R'G'B'}-{R'G'B'}+2^bits )
I am not familar with this algorithm. Could you please provide a source?
The problem with current tools (mentioned above,) is in their almost
uselessness for photographers. Well, at least in a way to get perfect
results in short time.
I was wondering if people noticed this. Yeah, without these corrections, the RGB-Gray
converstion can get hosed as well.
Please consider a.s.a.p.
They are indeed being considered. Color is a hard topic, and I want to get it right.
Jack
Piotr Legiecki
--
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] The Gimp Foundation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For those of you who were wondering why you couldn't verify my signiture: there you are. I had forgotten this problem existed. Thanks, John, for informing me of this. John Dietsch wrote: | Daniel, Where is your public key? I can't verify your signature | without it. | John Dietsch Well, I had forgotten that gpa doesn't let me export keys. I have now exported my keys to pgp.mit.edu (and thus most other keyservers), manually. Also, here: - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.3 (GNU/Linux) mQGiBD7rUA0RBACN0RpmEXDm5x77aUEUpe6djGHDHAC/iqlTDWnd0HHRQhUW8gWI IPR5e8Z0IcdxD/nt5olB4wbn7YmIfr4+K4gD37gsqoQA3fgMPC+bn4dKBMp86qw+ ZyfoBVmOTUkaHzb481K7S9P6dCwIkldUg6pb4i40BseZq3tDQ7+gfoB73wCgryMT 6CounAKfc5POFJtAYO9xoX8D/A+EHXWVpf+5egZERIqbIODipM8PwAYqywt/cF6e vt/hB2nZ+7cAbfB/8/sq9skDN2c7QeAi8I5mby6mu8RvyDuRouajb19EzqKV/wPA QWtFbOaWJMCUg5pxFYUyOZ0hiL8i9SiWs89nvkTXVXLOZiRWv4bmlFLLdpn/rUeZ lSYVA/9ZUK7QsW3/+QgaP5ITbq1GTP4sfr6duMJ5RL3vP0NPFUycFMFZMmPjLZKD 2gkheNFPKEjgdrNkiJdDbWqyzIuUtpaK1oPjDzH8fb6EfBgM6LE1gU1bA1m/FGZ1 Lcrzd083qhF+XEZZaB3WlFm0kYpLvf6H4yvcwEeR/QfzCpUDJrQvRGFuaWVsIFN0 dWFydCBSb2dlcnMgPGRhbmllbEBwaGFzZXZlbG9jaXR5Lm9yZz6IWwQTEQIAGwUC PutQDQYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBp3g/X5kBmTaXCAJ9k1N4aBP0Q mwPDUJBDhKYWSwHMVQCcCJd7e3GTdO7gJ/L6UCrxhYolGeS5AQ0EPutQDxAEANBb LTvDndp3q27T8L8FlZ+YB69gsmO1urpfCi0Ia3s8ml+RdGM5nzFMqLDzMxXKVOVl 3xqE2PWw8wxT3mKDwP38S6/XLzwv3OJ4FoEc8/tsuj77XGLWMFvp2wcUWqevNp9r cDGrRli+aYQOBlTAcj0BamwUuecNvjQXyhdlUDZbAAMFA/4gfNr50ok0gOLvTWzj zjDYCyxO7fRZhbdgCQ3OzlbvnaBbBBSKqFBjVHy3jcPCVpyXf2KPo7bpbtSYrv+V Ncb9GIyuwJx0IIlGuYH/vtvu65tZPRnDsdcFrPBGWuhh9ukOYkcmC5TyvVJmqpYm iyS/HRd7COdvr7EqXYXfdgzbp4hGBBgRAgAGBQI+61APAAoJEGneD9fmQGZNIt0A oJ4D30sXcYm+ITdjiHYp6kHb3P3QAJ9CMaTIn8zcZkl9o+O8xDpLoXXj5Q== =u0tT - -END PGP PUBLIC KEY BLOCK- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/kcV9ad4P1+ZAZk0RAkStAJ4y1lwLE2HQm2wpCE5Iv4MD3yhZewCeJztk UlSPVBHRQFMViz4Tk6YykrU= =qXCI -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] The Gimp Foundation
Sven Neumann wrote: This sounds a lot more like an attempt to bring WilberWorks Wilber what? I plead ignorant. back to life than what I was imaging from such a foundation. IMO it should be a lot less commercially oriented but maybe I am only getting a wrong impression from looking at this list. I don't think a GIMP foundation should share any interests with companies like for example MacGIMP. IMO a foundation should not sell anything. It should serve as a representant of the GIMP developers and it may accept donations (actually that's one of the major points). And donations would be one of its major points. However having a reliable source of money, like manual and chachka sales can only help TGF be more helpful. Basically, _anything_ TGF does will cost money. The more money it has, the more helpful things it can do. The FSF foundation, for example, collects membership dues (which are tax deductable donations) and sells tshirts, pins, stickers, posters, manuals, cds, has a corporate patronage program, in addition to seeking out private donations. The gnome foundation at least has tshirts, coffee mugs and the like that it gives to big donators, and is making some kind of noise about setting up a store. The mozilla foundation doesn't have these things, but I am willing to bet that they will in the future. Essentially, I can't run this thing forever, for free. There needs to be some way of making enough money to reliably pay for things like filing fees. Besides, people are more willing to donate money if we can give them something for the donation. As for being a representative of the GIMP developers, I think this should be TGF's primary responsibility. However, doing that also costs money. There are phone bills, mailing costs, travel costs, gas costs, my accounting is _almost_ free but will still cost something (and accounting is important to keep our tax-exempt status). It should also help to create contacts between the GIMP community and people that seek for advice or need speakers. But IMHO there should be no t-shirts, no printed manuals, no CDs and most importanyly no ads. If someone wants to do this kind of stuff, feel free to found a company and try your luck. Yes. I hope I haven't mislead people into thinking I am trying to start some kind of commerical venture. Believe me, I am not. However, I am trying to think of as many ways as possible to be as helpful as possible to the gimp community. All of these things require money. Paying for things like the next GimpCon, and making presentations happen are some of the best ways I can come up with to help the Gimp Community. I want to do these things. If I am doing these things, then I feel TGF is being successful. However to be able to do these things we need money. The more money we have, the more successful I feel running TGF. As far as printed manuals go, I think they are important. I really like printed documentation (it is waay better than online documentation) and I think printed manuals go a long ways toward encouraging people to use (and thus donate to!) the gimp. Binary packages are in this same vein, but, I think, less important, since distros (and Tor) will prepare packages for us. -- Dan [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Gimp Foundation
Also, I fear my first email may have been a bit to rambling to be able to actually get my point across. What I am hoping to discover by encourging this conversation is what ways people would like to help with TGF and in what ways people would like to see TGF help them. I would also like to get any questions about TGF role, my role, and anyone elses potential role answered as completely as possible. Sticky legal questions, if posed soon enough will be something I can pass onto my lawyer. I want to get people as excited as I am about the potential that TGF has to help the GIMP. -- Dan [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Gimp Foundation
Carol Spears wrote: When I looked into this sometime back, I watched the gnome foundation elections on the irc. This is probably not the best view of a foundation, however, I really wanted nothing to do with it. We don't need to structure our Foundation (or even have membership) if we don't want to. Further we can have our own rules for determining membership that may or may not have anything to do with democracy. It seems like if there is money available to aid with TheGIMP, the easier it is for the people to contact the person most involved with this area -- then the decision can be made by the person who is to do the task or what have you. I am not following what you mean here. Are you suggesting that the people most invovled in the project decide who or what gets funded? If you develop TheGIMP right now, and you get offered some money, it is difficult to give any of it back. Having a place and an easy interface to deposit money would be nice I think, and good therapy for any who received more than they gave (deep down everyone knows). Everyone knows what? Yea making it easy to provide donations would be cool. I am not certain if I am making sense (again); but no matter what is going on and all the evidence against this belief, I tend to believe more in individuals and their conscience than in organizations. People can get and install gimp on their own. Selling a distribution is sort of like preying on the ignorant. This has happened to me, and I didn't like it. I don't want to pray on the ignorant. Selling cds would be clearly marked as a fundraiser (and probably priced as such). However, is should be possible to inform people of the fact that The Gimp is free and you don't need to buy it. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] The Gimp Foundation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Neumann wrote: | Thanks a lot for organizing this. you're welcome. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/i3VQad4P1+ZAZk0RAoP7AJ9DMaylrJB3h6Snuw3O6SFEM32P0gCfYpMx A8vbP5we4CIVmcEo4YjiRUc= =D2ll -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The Gimp Foundation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am not subscribed to gimp-web, so if you are only replying to that address, I won't get the message As was discussed at Gimp Con 2003 (and before, frankly) I am in the process of incorporating The GIMP Foundation as a non-profit organization devoted to supporting the gimp. As this point, nothing (including the name) is set in stone. I have a legal clinic doing some research to help inform me about how to form the corporation and my (and its) legal responsibilities. This service is free, but limited. I will need to seek the advice of some other attorney (of which I have a list of about two potentially helpful lawyers) to anything TGF needs in the future. What I am working on, though, is what to do with TGF. What I want from everyone else is two things: ideas about what to do with TGF and questions anyone may have about TGF. I want make sure that these things have time get discussed with the lawyer and to try to help keep our community more informed of these matters. So please, if anyone has any questions about how TGF will work and what you would like to see it do, send them to me. I will work on providing answers. Here are some of the ideas I am currently mulling over regarding TGF: Selling t-shirts, coffee cups, lapel pins, posters, etc. Selling printed manuals. Selling GPL complient binary and source disributions on cd. Selling and paying people to go train and give presentations on the GIMP. Public and private grants. (someone (like me) will need to apply for these) Tax deductable donations. buying hardware (computers, tablets, scanners, colorimeters). full color magazine ads free training sessions office space accounting legal expenses staff paying programmers, web designers, tech writers constructing a build farm (this would help both developers and in making a cd distribution). Also, if anyone would like to me more directly involved with TGF, just email me at [EMAIL PROTECTED] and let me know how. I am sure we can find a role you'd be happy with. - -- Dan [EMAIL PROTECTED] PS. TGF will need a webpage. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/iS9xad4P1+ZAZk0RAj5zAKCTAT6PArDh8KXhP5x/niC1hGg4qgCeOt+B Foua9HwhWcGI4kgnxgor9no= =i6OI -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Noise reduction
Steve Crane wrote: Hi, Are there any built-in functions or scripts for the GIMP that can be used to remove or reduce noise in digital photographs? Does anyone have a set of steps to follow to remove noise? There are several stand-alone programs available for Windows that do this but I haven't found any for Linux yet. Anyone know of any? Thanks. It depends on what kind of noise you are looking at. Can you describe the noise more precisely? Is it salt and pepper noise? Gaussian noise? If you can show an example image I can help you pick a filter. If you just want to use a sledgehammer, you can just use a blur filter, which will reduce many kinds of noise, though you can almost always do better. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Kudos to The GIMP Developers!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tino Schwarze wrote: | Hi there, | | I'd just like to say: Well done. I managed to create a A1 poster at 600 | dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). | While GIMP 1.2.4 crashed while rendering the fractal, GIMP 1.3.20 | managed to get it done and even save it as Postscript. Weehee! | | BTW: Is it possible that there is a 3 Gig limit on per-process memory? | The machine has 6 GB, no ulimits and I got a could not allocate x | bytes message when I gave 3 Gig tile cache to GIMP (it took about 500 | Meg for other stuff, so I settled with 2.5 GB tile cache and still got a | 3 Gig swap file plus 3 Gig memory usage). If you are using IA32, on linux, then yes there is a 3 Gig limit on per-process memory. 1 gig for the kernel and 3 gigs for the process. If you are using Opteron, Itanion, Power4, G5, UltraSPARC, or Athalon 64, then you don't have that limit. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/cf4yad4P1+ZAZk0RAhT6AKCWSVCrb8iqNDsBRamHFOyxrkvuqACfVS5t ZYYakwlna9ufenHocYObxYc= =54ge -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Firmed out roadmap
Sven Neumann wrote: Don't get me wrong. I think your schedule is reasonable and we should definitely publish a roadmap but IMO it shouldn't include any dates. what about sufficiently vague date? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Firmed out roadmap
David Neary wrote: You probably see that I had anticipated doing a release tomorrow (as anticipated at camp) as a prelude to a bug week... I just had a look, and make distcheck just failed on me in the po files, so I'm going to need to look more closely at that, and might not have a release until Wednesday or Thursday. I will keep track of the actual dates stuff gets done by as well :) if you are missing .po files, just touch them (eg $ touch po/missing-po-file.po) and you can build without the translations (po files contain translatiosn of text in the gimp). I mentioned this problem on IRC. carol straightened me out. If I felt braver, I would commit those files empty files to the gimp so that other peoples builds would work (though it would propably be better to remove support for that language). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] bugs@gimp.org spam getting a little out of hand
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone else noticed how the [EMAIL PROTECTED] spam is getting a little out of hand? perhaps now would be a good time to change that address. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Qjunad4P1+ZAZk0RAgdFAJ0a9mlxy/947bJOSayuAoj1WwrxcQCglaSS SBUYodfIqr6pPFACax1mQd4= =zbTP -END PGP SIGNATURE- ___ 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 11:42 PM -0700 8/13/03, Manish Singh wrote: GEGL uses XYZ as a native format. Why? Lab is a richer model esp. for handling chromanicity and is also a standard in the print world natively. Why limit to XYZ?? I am not sure what you mean by a richer model. Lab is a one-to-one mapping of XYZ. Every color in Lab is also in XYZ and visa versa. The transforms to/from XYZ from most other colorspaces is faster. Besides, Lab is _defined_ in terms of the XYZ colorspace. (well actually Lab is defined in terms of the xyY colorspace, which in turn is defined by the XYZ color space). And XYZ is not a limit. XYZ is, to the best of the worlds scientific ability, contains every other 3 components human perception colorspace. You can convert from any colorspace to XYZ without a loss of information. And as far as it being gegl's native format, what he really means is that XYZ is used precisly in this fation. As a connection space between different colorspaces (just like most generic ICC color profiles are designed to do). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Second try
hmm...Agreeded. I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy workload week, 5 days could not be enough to make my points, if they need soem expermenting on the codebase), But since the decision was taken, so mote it be - it's not gonna hurt. later it was agreed that 7 would be more reasonable since some people only work on it part of the week. 10 could be made for the same reason. I'll make sure it it brought up. Also, nothing has been set in stone. We are very informal around here, as always. As for the foundation., I'd be happy if it was in Europe. USA is getting more and more of those stuppid laws, including states passing super-DMCAs¨ , that if enforced would stop the Internet alltogether. It could be in both. I still need to talk to a lawyer. As was brought up at the meeting, FSF has two seperate and associated groups. FSF America and FSF Europe. Both with different monies and slightly different goals. The foundation has to care off one other thing I did not see on the summary: most, or all of the codebase must be owned by it. It would legally allow small adjusts in the license, like the recently one that clarified that there could be proprietary plug-ins for the GIMP. (Strictly in terms of the GPL, as currently the copyright holder is each individual author, there would be the need to have express permission from each author for this change). Also, there is the GNU motive - if the need arises to defend GIMP's IP in court, it is easier if the foundation is the owner, and not a lot of people spread over the world. This is a very good point. Off course there must be foolproof safeguards to keep the foundation from doing non-wanted things to the codebase. So, that GIMP should be free software should be specified in the reason of beingof such a foundation. yes, well, in america, when you incorporate as a public-benefit NPO, you can include that concept in the reason of being. Thus any move away from free software would require a dissolving of the corporation. Even if that happened, public-benefit NPO assests must be sold to another public-benefit NPO, so a hostile takeover of an NPO isn't really possible. -- Daniel Rogers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Sven Neumann wrote: Hi, Damien Genet [EMAIL PROTECTED] writes: Why can't you launch a « Gimp Fund » through paypal, like the Blender foundation did ? I think that the Gimp has much more visibility than Blender did, and would have no problems raising money. Actually, it may even help to boost the development. I'm not sure if it would boost development, it might as well hurt it. The problem with money is that we would somehow have to decide how to spend it. Paying developers from such a fund could cause quite some disagreements. If others are paid for their contribution, why would anyone want to contribute unless (s)he's paid as well? I do believe however that a GIMP Foundation of some sort would make sense. It would make it a lot easier to raise fundings for events like developer conferences and would thus allow us to do them more frequently. I hope that we can discuss (or maybe even found) such an organization on the GIMP Developers Conference this summer. Sven I am on it. I'll have a presentation to give on the subject. -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Ernst Lippe wrote: On Tue, 11 Mar 2003 17:12:14 +0100 Raphaël Quinet [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003 09:46:49 + Adam D. Moss [EMAIL PROTECTED] wrote: I think that the user should be able to edit the alpha channel independent from the other channels. I don't think that it is unreasonable that a user initially makes some parts of the layer transparent, then makes some other edits to the layer and finally decides that the transparency boundaries should be slightly different, e.g. slightly more feathered. In most cases this will work fine but when some of the tiles have been scrubbed this will not work for these tiles. I think that it _is_ unreasonable to expect this to work. Why? Normally operations on the alpha don't influence the state of the other color components, so I don't really see why it would be reasonable to assume that changing to full transparency is a priori different. Also it is the simplest way to implement the whole thing. Can anyone tell me what users expect? If an unerase feature exsists in other products then I perhaps in may be worthwhile to observe how they do it, cause that would be how new users expect it to work. (I am not just considering Photoshop here, but Shake and Chalice, both of which are influencing Gegl's design). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Steinar H. Gunderson wrote: On Tue, Mar 11, 2003 at 06:36:47PM +0100, Sven Neumann wrote: which operation (besides the evil anti-erase) wouldn't have such a color information? The only operation I can think of that makes a transparent pixel non-transparent is some sort of painting with one of the paint tools. Such a paint operation always has the color information we need. Blur? /* Steinar */ I don't think Blur counts here. Alpha is a measure of the amount of coverage of the pixel. (e.g. an alpha of .5 means half the pixel is covered). In particular, 0 alpha means that the pixel is not covered at all. This means that the pixel contributes NO color information. I think this should hold for blur as well. And from that point of view, no pixel with alpha zero should ever contribute color information. Another way to look at it is that alpha is as important to the color information as the actual RGB channels. No operation should be performed without considering the alpha channel (except for a color-space conversion, which isn't really an issue in gimp-current, also, please correct me if I am wrong). Thus alpha is an inherent part of the color information. Thus if alpha is zero, our math tells us the color is non-exsistant. Another way to look at it is that alpha is a solution to the aliasing problem when you try to draw lines (say the bounding lines of a polygon) at arbitary angles. Sub-pixel precision tells us that the line doesn't cover an entire pixel, so we use alpha as an approximation to express this partial coverage of edges. But alpha here is an essential part of the edge. It tells us, approximatly how far the edge extends into the pixel. Thus a blur operation that was applied to the edge is incorrect if is doesn't take into account the alpha. A better implementation of anti-erase would try to keep an old version of the tile around, so that it could just read the old color data back when necessary, but at this point, why not just use a mask layer (since you are effectively keeping one around anyway)? Incidentally, gegl premultiplies it's images, so if anyone really really wants to use unerase in gimp 2.0, please voice an opinion so we can consider not pre-multiplying. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Steinar H. Gunderson wrote: On Tue, Mar 11, 2003 at 10:15:51AM -0800, Daniel Rogers wrote: Alpha is a measure of the amount of coverage of the pixel. (e.g. an alpha of .5 means half the pixel is covered). In particular, 0 alpha means that the pixel is not covered at all. This means that the pixel contributes NO color information. I think this should hold for blur as well. And from that point of view, no pixel with alpha zero should ever contribute color information. How do you propose this being implemented, ie. what value would you plug into the IIR filter GIMP's blur is based on, for a pixel with alpha != 255? /* Steinar */ Weight the pixel value by the alpha value, just like you do with any other operation on pixels. This makes sense when alpha is defined to be the coverage. If a pixel is only really half covered, their should half the impulse response on the convolution kernel. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. GSR Or, as I suggested in an earlier email, but I don't think was stated very clearly, implement anti-erase as a layer mask (whether or not the user can actually see the extra layer). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Steinar H. Gunderson wrote: On Tue, Mar 11, 2003 at 11:41:30AM -0800, Daniel Rogers wrote: Weight the pixel value by the alpha value, just like you do with any other operation on pixels. This makes sense when alpha is defined to be the coverage. If a pixel is only really half covered, their should half the impulse response on the convolution kernel. And so, if you're blurring with some transparent area, it's equivalent to blurring with black? Doesn't make sense to me -- or am I missing something? /* Steinar */ Not quite the same. Black is not the same as no information. A little coverage is some information, while no coverage is no information. It is the same problem you have with blurring near the edges of an image. I think the best way to treat to problem is to declare that there is no data, and determine the best way to pad your blur (presumably you would use the same padding stragety you used around the edges of the image). You might even go to the trouble of padding partial pixels (eg, blending the padding pixel with the partially covered pixel). This breaks down though when you start to treat coverage as transparency again. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Adam D. Moss wrote: In addition to alpha (the measure of coverage) you could also include transparency (which is something a measure of how much light passes through, i.e. the actual transparency of glass, as opposed the the coverage of a screen, this is equivilent to insisting on a layer mask to be included for every layer). It is a little tempting, as it would remove a lot of ambiguity in the overloading of the meaning of the alpha channel. We've (well, GIMP and probably most other transparency-handing packages out there) been equating transparency with alpha for so long now though that I'd hate to have to re-educate users. But it needn't be something that the front-end has to expose. I think the best way to go here is to re-educate users, without breaking what they expect alpha to be. I think the best way to deal with this is quoted in a email I just sent: This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. We then explain to the user the benefit of the RGBCT colorspace over the RGBA colorspace. Since A=C*T it should be easy to write drawing functions that handle both cases just as easily. I don't think that since it has always been done this way, there should be a reason to keep doing it that way. I don't know if this is really the best approach, but I think it allows for a better representation of real life. And yeah, even if we use coverage and transparently internally, it doesn't mean we have to tell the front end about it (though abstractions have a way of leaking precisely when you don't want them too). We could also include luminesence, which is a measure of how much light a pixel produces (as opposed to reflectance, which is all we measure how with rgb). There are various per-pixel properties I could think of which might be very exciting (surface normal vector, specular reflection index) especially for natural media rendering. Luminescence wouldn't be the first that'd come to my mind, since I think that any such image elements would by nature be quite isolated and fit very well on their own 'addition' style layer and save a lot of complexity, but perhaps it would be nice to paint with fire after all... Yes, I agree. There is certainly a benefit to keeping the number of numbers used to describe a point in space to a minimum (I sure we could come up with more, with a little effort). And it may be that the distinction between coverage and transparency is better suited to a 3d renderer, where real-life modeling is more important. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Simon Budig wrote: Sorry, this is a step back towards Gimp 0.54 where you had no embedded alpha channel in the images and compositing of two images (that had to have the same size) was done via a third grayscale image (that also had to have the same size). I am not suggesting that alpha is gotten rid of entirly in all cases. Just that in this specific case, where you want the full opacity to be controlled by a layer mask, you should get rid of alpha in the area where you want the layer mask to control your opacity. This is specifically because of the overloaded nature of alpha here. Alpha is being used as transparecy but (correctly) is mathematiclly treated as the coverage. When being forced to use the layer mask for all images where I might decide to increase the opacity later drawing some random strokes on the layer becomes a non-trivial task, because I have to care that these strokes are drawn exactly the same in the layer itself *and* in the layer mask. This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. Also the painting algorithm would have to use two different algorithms for strokes on top of another opaque area in the layer and for strokes in the area in the layer where the layer mask makes it transparent. While Gimp could do this for me it would also include the overhead of accessing two drawables simultaneously which is not really good. I think what I said above addresses this. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Simon Budig wrote: Sorry, this is a step back towards Gimp 0.54 where you had no embedded alpha channel in the images and compositing of two images (that had to have the same size) was done via a third grayscale image (that also had to have the same size). Incidentally, this is precisely what movie compositers have to do when they composite real images. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
David Necas (Yeti) wrote: If you want to implement anti-erase as a layer mask, then for antierase to be available, this layer mask (not shown to user) has to be present all the time (if not, the information needed for anti-erase would be lost). But how this situation differs from separate alpha channel -- except for storing the same data in a much more complex way than necessary? Because alpha is coverage. Zero coverage means there is nothing there. The pixel is not part of the image, there is no information conveyed by the pixel. It means literally that there is no coverage of this point in space. Also this pixel is not a sample of the image. What I mean when I say alpha is coverage is that alpha was modeled and incorparted into the forumlas we use as the amount that the image covers the pixels. This is a very real life, I just took a photo of something concept. The image it not equivilent to the pixels in this context. The pixels represent a digital sampling of the image. The real image has nigh-infinite resolution. To save space, we choose a sample size and fill in the color that is closest to what the image represents. Sometimes, though, especially when compositing, an average color per pixel is not good enough. You need a number that describes how well the pixel is covered. This is alpha as described by computer scientists. Now, alpha means transparency to most graphic artists, so this is how it gets used, and in most cases this is ok. But there is a big real world difference between partially obsuring a pixel with opaque objects and putting a piece of colored glass in front of a pixel, even though the result is usually the same when sampled as RGBA. Although back on the topic of anti-erase, I think that the only way to do anti-erase correctly is with another layer. Once alpha goes to zero, the pixel no larger part of the sampled image. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
David Necas (Yeti) wrote: OK, I could use alpha in a wrong sense, it's a matter of definition, and let's agree on yours (though I wonder how's called the object alpha==0 pixels are part of, because I can draw on them, unlike pixels outside layer boundaries, so they exist and are part of something). You can also extend the boundries of your image (resize it) and draw over way over there. The image program restricts the area you can draw as a convience but that doesn't mean you can't draw out there if you want to. But then I, as a user, don't care about alpha, and what I really care about is transparency. So everything what was said can be repeated, only s/alpha/transparency/. My need for pixels retaining their properties even in invisible state didn't disappear. I think that is an excellent point, and a big vote for using un-premultiplied images (in fact, the only vote for using unpremultiplied images) If this is a need of our users, then it is incorrect for the cache to scrub the color information of transparent pixels. This still leaves the problem about what to with convolutions. Convolutions have a well defined behaviour for specific alpha's. If alpha is zero, it doesn't contribute to the covolution. Consider this chain of events: max the alpha of a triangular area. Blur the image. un-erase the edge of the triangle You will now have a new area revealed that didn't have the blur applied. This may or may not be what you want. This is either another way to mask the operation of a blur (what you wanted), or an annoying bug where now you have to go back six steps to before your blur, un-erase, and go forward again. I think this is why people don't like the un-erase (it's ambigious). Please correct me if I am wrong here. Clearly you (and probably others) have a need to reveal previously transparent areas. Here is a potential solution. Unambigufy the tools. Define precisly when it's ok to discard the color information and when it is not. Instead of erase and un-erase have: erase: this deletes all color information (truly erases the pixel and removes all information in it). veil: this just increases alpha, preserving color information. un-veil: this just decreases alpha, preserving color information (this is the improved un-erase). When a pixel is totally veiled it is not affected by convolutions. I use the name veil to suggest a mask that isn't quite the same as the other masks. What other tools need to be unabigufied, if this were to be implemented. Is the scrubbing done by the cache the only thing that breaks unerase? -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Simon Budig wrote: Sorry, but I don't believe that this destinction would make sense. From my point of view transparency/opacity and coverage are two models to explain what happens when talking about alpha. I do know that the original Porter Duff paper based its conclusions on the coverage model, however, the transparency analogy comes closer to what happens when gimp is building its projection of the image. The distintion is only important when deciding what to do when color information goes to zero. Coverage says it goes away, transparency says it stays. Also, alpha is the model. Transparency and coverage are the real (as in reality) things. Though I suppose that depends on whether you feel art imitates life, or that life imitates art (and I am not poking fun here, it's an iteresting philosophical debate). For proper coverage handling you'd have to store the information *what* part of the pixel has been covered. Better leave that to a vector based implementation. The coverage model also fails to model a flat area of e.g. 50% opacity (a surface with a small hole in each pixel...). Yes indeed. Alpha as a measure of coverage is an approximation. The core blending ops derive directly as an extension of this approximation. Since alpha doesn't declare how a pixel is covered, when two pixels overlap you can describe how they overlap in one of 5 ways, listed in a chart on page 838 of Computer Graphics (2nd ed, Foley, et. al.). But as I said above, I think the difference is only vital when you have to decide what happens at zero. This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. I fail to see what would be the win in this situation. All algorithms would have to be revised and I really doubt that this separation would make the algorithms simpler. E.g. Blur: It is ok, to blur the opacity channel, but blurring the coverage channel does not make sense, because it does not fit in the model of partially covered pixels. What should we do? And how would we present unexpected results to the user? It is only a small change to the algorithms (if anyone wants I can work out what I think are reasonable models, do the math and stick 'em on the list, I have already done some of it anyway). And I would think that blur would apply to a partial pixel and ignore opacity (depending on just how you modeled opacity) The impluse to the blur would be smaller, as discussed earlier. Including the alpha is the correct way to blur. The win in this situation would be greater flexiblity in deciding when it is appropriate to discard color information, also a more complex model would allow for more complex results. AFAIK, this seperation between coverage and transparency has never been modeled before in a real application, so I cannot provide any research or data about how useful it would be. I can only go with what I have mangaged to work out myself, and my gut feeling. My gut feeling tells me this might be useful. And where would be the win for the added memory requirements, more complicated algorithms and users looking blankly at the screen and trying to figure out what is going on? User's will figure it out. Since no one has ever tried to work with this before, it is hard to say what uses people will come up with. (I mean really, what would anyone use a laser for?) Besides, I am suggesting that if they don't want to work in RGBCT they can always work in RGBA. The added memory requirements give way to more complex results. That said I could see some use for additional channels in the image. Normal-Vectors or glossiness are an exciting idea, especially when using them for generating textures. It also would be cool to have spot-color channels in the image so e.g. distort plugins would distort the image+spot color information together and you don't have to apply the same plugin multiple times in the very same manner on multiple drawables. It would be nice if these things were possible. Agreed. I will try to see about incorporating these extra channels into gegl (not necessarlly C and T from above, but the others certainly). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
