Re: [Gimp-developer] MNG support. Was: Intolerance, and development.
David, Instead of spending all this time writing your views of the world, I am sure that all on this list including you would actually think the time would be better spend actually implementing mng support for gimp. I suggest that you go about it in the following steps: 1. Extract the png plug-in file and rename in mng. 2. Change it so that it registers the .mng extension. 3. Make sure that it compiles and that it is may be used to read png files that have been renamed ".mng". 4. Get and compile the libmng library from http://www.libmng.com/ . 5. Get some mng example files. 6. Study the libmng example programs and try to implement the same scenario for getting the data into the mng plugin. At first, decide about some minimal subset of mng that you will support, e.g. one-layer that are not JNG. (This is essentially the same thing as png). 7. After succeeding in reading one-layer non-jng mng images, add support for multi-layer and mng. 8. Release and get the well deserved glory. 9. Add mng write support. 10. Release again and get more glory. 8-) Btw, is there tutorial available for image loader and writer plug-ins? Regards, Dov On Thu, Nov 28, 2002 at 08:50:51PM -0500, David Weeks wrote: > Jeez, > > Guys, perhaps it was wrong for me to do the French/American thing, but I was > drawing on historical examples. All the same, I'd not respect anyone who > didn't respect their own country. I LOVE America, as an American, and I have > MAJOR problems with much of America, just the same. > > Tolerance isn't the lack of criticism, and intolerance isn't the act of > criticism, and beyond that, some things are tolerable, and some things are > not. So let's drop the "troll" "intolerant" "ignorant" crap and deal with > information. These reactions are human nature, and responsible for the > strife in the world; just look at this list. > > Free discusion of ideas means it's all good, even the bad and the ugly, cause > that bad and ugly might be the fact that we're wrong, and someone was rude in > pointing it out. > > My problem of recent days started with a reply to a requested feature: mng > support. The response I got was that I had a lot of nerve asking someone > else to slave for me. I got that from the same who's never even HEARD of > regular expressions, and is now an active partner in the development of gimp? > Red flag folks. I also see a split between Film Gimp and gimp. More flags > of red. And there the fact that very POWERFUL people don't like us. We > don't serve them, we undermind their economic rents. > > So here's the challenge: who thinks that not knowing what regular expressions > are, or thinking that a feature request is wrong, is an indication of knowing > what you're doing as an open source developer in the GNU/Linux community? > > While this on going discussion is not a specific, tactical Q&A on code, it is > a specific discussion of what it is to work on that code, and the expectation > of that code's consumers: the GNU/Linux/Open Source community, and end-users > the world over. I'm "chop chewing" because of what I've found in this > CRITICAL application's development forum. > > Teachers correct, some learn, some cheat, others blame. Fact is, none of us > matter -- except for the users of gimp. If we care about them, then we're > not so different after all. > > David Weeks > > PS -- my deference to the French, and to Microsoft. America would be English, > were it not for aid of France, and computers would be Apple, Unix or IBM, > were it not for the aid of Microsoft. Ask those of us who were there, when a > "pop" of Unix ran $2500 a seat, and Microsoft could be had for $100. I'm > glad Richard Stallman, Linus Torvaldes(sp?), Vinton Cerf and company, and the > internet community furthered the perfection of software technology. The > strongest contribution being Freedom. > -- > You can call me at: 813-236-2009, USA > [EMAIL PROTECTED] > Shop TampaPC.com! > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Film Gimp and GIMP
On 29-Nov-2002, Raphaël Quinet wrote: > On Thu, 28 Nov 2002 14:55:06 -0500, Carol Spears <[EMAIL PROTECTED]> wrote: > > On 2002-11-28 at 1259.18 -0500, Patrick McFarland typed this: > > > Hrm. Side note, They got $1k from Linuxfund to further their project... hrm... > > > > $1k would not be enough to by the beer for the people who develop The > > GIMP (if i can at least add correctly). > > That depends... If you consider those who write GIMP code on a daily > or weekly basis to be the real "developers" and if you consider those > (like me) who submit patches from time to time as "contributors", then > I think that $1K would be more than enough to buy beer for all > developers, unfortunately. I wish there were more developers... > > On the other hand, if you divide $1K among all contributors, then we > would all be very thirsty. ;-) Yeah, but how many _film gimp_ developers are there? Less than a handful? -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989 msg03132/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Film Gimp and GIMP
Wow. Sure is hot in here. Some comments, from a gimp _and_ filmgimp developer: I also regret any duplication of effort between the two. However, I'm not personally convinced that merging them is a good idea. My feeling is that Filmgimp should be a tool specifically (or at least, primarily) for the film industry. It is very likely to develop along lines that are (at best) not useful to, or (quite possibly) totally unwanted by, the more general Gimp community. Remember, a tool that can do everything is seldom the perfect tool for one specific job. I don't think merging Gimp and Filmgimp will necessarily make either set of users happy. Of course, it would be great to build both tools on a single code base. But that's a bigger job than just merging the code, requires a wider range of skills, and (like everything else) is only going to happen if someone wants it badly enough to either do it, or pay someone else to do it. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Film Gimp and GIMP
Hi all, David Hodson wrote: > My feeling is that Filmgimp should be a tool specifically (or > at least, primarily) for the film industry. It is very likely > to develop along lines that are (at best) not useful to, or > (quite possibly) totally unwanted by, the more general Gimp > community. Remember, a tool that can do everything is seldom > the perfect tool for one specific job. I don't think merging > Gimp and Filmgimp will necessarily make either set of users > happy. A smallish delta between gimp 2 and film gimp will probably be inevitable. And given that several filmgimp people seem to be the primary developers on gegl at the moment, I'm sure that there's some idea how big that delta will be right now. But we're not talking about one tool for lots of different jobs, here, so much as narrowing a rift that's developped while film gimp was basically only developped in-house by one company over the last 3 years. Things like getting the front-end looking similar, doing similar separation of core & gui typ[e work to that being done in HEAD right now (mostly by Mitch), and making sure that major structural and design changes at least get discussed wrt the two programs. Does anyone know how big the functionality delta is between the GIMP 1.2 and the film gimp? Are there plans to get filmgimp onto gtk+ 2.0? Is there the possibility of bringing useful functionality back into the main gimp branch from the HOLLYWOOD branch? > Of course, it would be great to build both tools on a single > code base. But that's a bigger job than just merging the code, > requires a wider range of skills, and (like everything else) > is only going to happen if someone wants it badly enough to > either do it, or pay someone else to do it. Of course it's a big job. The point, I think, is that it'll be an even bigger job by the time filmgimp is roughly up to the gimp 1.2 level, and gimp 1.4 is out on the shelves getting heavily debugged :) Of course, by that stage the emphasis will be on gegl, pupus and all the other cool stuff that's planned for 2.0. In brief, though - what does the film gimp have that the main gimp doesn't have, apart from some extra cool and expensive plug-ins and 16 bits per channel? Cheers, Dave. -- David Neary, Marseille, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Film Gimp and GIMP
On Sat, 30 Nov 2002 00:40:52 +1100, David Hodson <[EMAIL PROTECTED]> wrote: > Wow. Sure is hot in here. Ouch! ;-) > Some comments, from a gimp _and_ filmgimp developer: Thanks! I am glad that such a person exists. ;-) And I prefer to have a serious discussion rather than a flame war. > I also regret any duplication of effort between the two. However, > I'm not personally convinced that merging them is a good idea. > > My feeling is that Filmgimp should be a tool specifically (or > at least, primarily) for the film industry. It is very likely > to develop along lines that are (at best) not useful to, or > (quite possibly) totally unwanted by, the more general Gimp > community. Remember, a tool that can do everything is seldom > the perfect tool for one specific job. I don't think merging > Gimp and Filmgimp will necessarily make either set of users > happy. Merging both does not require the removal of features from either tool. The added value of Film Gimp comes primarily from its 16-bits support and its frame manager (and specialized plug-ins). But unfortunately, it is based on an old core, which lacks many features that are present in the current GIMP (not to mention the plug-ins). If GEGL and the frame manager were merged into the current GIMP, then everybody would win because any new feature or bug fix would be immediately available to everybody. Currently, everything since the original HOLLYWOOD fork has to be implemented separately in each tool. Note that merging Film Gimp and GIMP does not mean that everybody would have to use the same user interface. The split between core and UI that occured during the development of GIMP 1.3.x means that it would be much easier now to create a slightly different user interface that is optimised for working with films. Some features could be hidden or accessed in a different way if they are not so useful for a specific version of the user interface. > Of course, it would be great to build both tools on a single > code base. But that's a bigger job than just merging the code, > requires a wider range of skills, and (like everything else) > is only going to happen if someone wants it badly enough to > either do it, or pay someone else to do it. Sure, this is not an easy task. But a large part of it is planned for GIMP 2.0 anyway. The two most requested features for the GIMP are CMYK support and 16-bits support. Other popular feature requests are layer groups, active layers (adjustement layers or styles), EXIF and others, but they come far behind CMYK and 16-bits channels. So we will have to add those features to the GIMP soon, probably by using the GEGL library. Another feature that will be integrated in the GIMP soon is a macro recorder (and playback). This is also on the Film Gimp todo list. Same for the support for Python, which has been added to the current GIMP. Some other features related to the user interface are also requested from time to time. For example, some users would like to have an MDI-style interface or at least have the image menu available on top of the image. Some GIMP developers are against it, but personally I would like to have this (maybe as an option) because this would make the GIMP much easier to use for those who do not have a "decent window manager" (e.g., Windows). Some of these things have been implemented in Film Gimp. I would like to have them in the GIMP as well and I am thinking about implementing them myself. But having two separate code bases implies that any fixes or improvements implemented later would have to be duplicated. It would be much simpler to avoid these efforts by merging the code as soon as possible. So although merging the two codebases is not an easy task, I think that a significant part of the work will have to be done for the GIMP anyway. Working on this convergence as soon as possible would also avoid the duplication of effort that is currently done by trying to bring Film Gimp closer to 1.2.3 (instead of 1.3.x) and porting it to Windows and other systems (which would be much easier if Film Gimp could use the current code). Last, but not least, it would be very nice if the Film Gimp developers would not try to increase the distance with the GIMP. For instance, the following parts of the filmgimp.sourceforge.net web page could be changed: - The "History" part is slightly incorrect in some parts. Among others, it states that "The Gimp committee eventually unanimously voted against Film Gimp." This is of course wrong, since it was only decided that the merge would be done later. There has always been some cooperation between the two teams (until recently, maybe). In addition, there is no such thing as a "GIMP committee" and this conveys an obviously inappropriate feeling of "us versus them". - In "The future of Film Gimp", the first goal is: "1. Keep the Film Gimp Web SourceForge site updated (an unmaintained Web site exists at film.gimp.org) [Done July 4, 20
Re: [Gimp-developer] Film Gimp and GIMP
On 29-Nov-2002, David Neary wrote: > > Hi all, > > David Hodson wrote: > > My feeling is that Filmgimp should be a tool specifically (or > > at least, primarily) for the film industry. It is very likely > > to develop along lines that are (at best) not useful to, or > > (quite possibly) totally unwanted by, the more general Gimp > > community. Remember, a tool that can do everything is seldom > > the perfect tool for one specific job. I don't think merging > > Gimp and Filmgimp will necessarily make either set of users > > happy. > > A smallish delta between gimp 2 and film gimp will probably be > inevitable. And given that several filmgimp people seem to be the > primary developers on gegl at the moment, I'm sure that there's > some idea how big that delta will be right now. > > But we're not talking about one tool for lots of different jobs, > here, so much as narrowing a rift that's developped while film > gimp was basically only developped in-house by one company over > the last 3 years. Things like getting the front-end looking > similar, doing similar separation of core & gui typ[e work to > that being done in HEAD right now (mostly by Mitch), and making > sure that major structural and design changes at least get > discussed wrt the two programs. > > Does anyone know how big the functionality delta is between the > GIMP 1.2 and the film gimp? Are there plans to get filmgimp onto > gtk+ 2.0? Is there the possibility of bringing useful > functionality back into the main gimp branch from the HOLLYWOOD > branch? > > > Of course, it would be great to build both tools on a single > > code base. But that's a bigger job than just merging the code, > > requires a wider range of skills, and (like everything else) > > is only going to happen if someone wants it badly enough to > > either do it, or pay someone else to do it. > > Of course it's a big job. The point, I think, is that it'll be an > even bigger job by the time filmgimp is roughly up to the gimp > 1.2 level, and gimp 1.4 is out on the shelves getting heavily > debugged :) Of course, by that stage the emphasis will be on > gegl, pupus and all the other cool stuff that's planned for 2.0. > > In brief, though - what does the film gimp have that the main > gimp doesn't have, apart from some extra cool and expensive > plug-ins and 16 bits per channel? > To cut this all short, how long will it be until I can do higher precision rendering in any gimp whatsoever? FG's xcf plugin is broke, gegl isnt done yet Btw, why hasnt Gimp gone to linuxfund and get some funding? With $1k you probably could hire someone to push a single precision float rendering pipeline ahead of schedual. Or atleast put a huge dent in it. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989 msg03136/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Film Gimp and GIMP
> Merging both does not require the removal of features from either > tool. The added value of Film Gimp comes primarily from its 16-bits > support and its frame manager (and specialized plug-ins). But > unfortunately, it is based on an old core, which lacks many features > that are present in the current GIMP (not to mention the plug-ins). > If GEGL and the frame manager were merged into the current GIMP, then > everybody would win because any new feature or bug fix would be > immediately available to everybody. Currently, everything since the > original HOLLYWOOD fork has to be implemented separately in each tool. Yeah, really, isnt the point of GEGL and other realted stuff? > > Note that merging Film Gimp and GIMP does not mean that everybody > would have to use the same user interface. The split between core and > UI that occured during the development of GIMP 1.3.x means that it > would be much easier now to create a slightly different user interface > that is optimised for working with films. Some features could be > hidden or accessed in a different way if they are not so useful for a > specific version of the user interface. > Yeah, that would be cool. But really, I would want this in the same app. If Im editing images (normal gimp mode) I want it to look one way, if Im editing movies (film gimp mode) I want it to look another way. > The two most requested features for the GIMP are CMYK support and > 16-bits support. Other popular feature requests are layer groups, > active layers (adjustement layers or styles), EXIF and others, but > they come far behind CMYK and 16-bits channels. So we will have to > add those features to the GIMP soon, probably by using the GEGL > library. Another feature that will be integrated in the GIMP soon is > a macro recorder (and playback). This is also on the Film Gimp todo > list. Same for the support for Python, which has been added to the > current GIMP. Actually, Im going to use my evil weapon of mass destruction here. "Adobe Photoshop does cmyk and layer groups." But Ill be fair here and say its got an ugly renderer like we do. BTW, Im not specifically pushing for Images themselves in 16-bit channel mode, but a renderer that works at a very high precision (once again, single precision floats comes to mind, so we can use gcc 3.2.x's -mfpmath=sse,387 and such) independent of what the image itself is. This especially would be good for film gimp's 16-bit mode because its more than twice the bitdepth (32-bit yes, but its also float.) So doing multiple layers will result in very high quality images no matter what. Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the "virtual" layer, only the layers inside of it are done, no outside layers interact with these except through the final "virtual" layer.) -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989 msg03137/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland <[EMAIL PROTECTED]> wrote: > Btw, has there been a discussion on how layer grouping will work? > I want to be able to both group layers in just a group (aka doesnt change > how rendering works at all) then also be able to group layers together, and > have the output of that act as a layer (aka, for calculating the "virtual" > layer, only the layers inside of it are done, no outside layers interact with > these except through the final "virtual" layer.) There has been some discussion about layer grouping, but I do not think that any concrete implementation proposals have ever been agreed upon. So anyone who could come up with a GUI mock-up is welcome. Code is even more welcome, of course. ;-) However, here is my point of view (which may be different from what some other developers think, so do not take this for granted). There are two kinds of "grouping": - Simple linking of layers so that some operations such as toggling their visibility or moving the whole group of layers can easily be applied to them (bug #86337, bug #86277). These operations would not modify the pixels in the layers. This could probably also be used for implementing the clipping groups (bug #51112). - Grouping of layers in such a way that a merged image of the layers is stored in a virtual layer and some operations can be applied to this merged layer: color adjustments, transformations or even any PDB operation, including the ones done by a plug-in. Whenever a layer in the group is modified, the merged image is rebuilt and the operation associated with it is applied to in order to re-create the updated "active layer". This can be used to implement the Photoshop styles or adjustment layers (bug #79025, bug #98262). In summary, the "active layer" would have a list of layers, a drawable and one PDB function (with its current parameters) associated with it. Whenever something happens to one of the layers in the list, a new (invisible) drawable is allocated, it gets the merged copy of all layers, and then the PDB function is applied to it. When the results are ready, the new drawable replaces the one that was visible. In some cases, it may be better to keep the two drawables (merged view + results) and to apply the PDB function only to the regions that have been modified, but this is only an optimization. So as you mentioned yourself, there are two ways to define "groups": they have different purposes and need to be implemented differently. The first and second kind of groups would probably have to be defined differently in the user interface. So again, some GUI mock-ups would be welcome. Note that it is important to become familiar with all features and their distinct purposes before trying to think about how they could be used, otherwise it is easy to miss some important things. Here are some direct links to the relevant bug reports: - "clipping groups or masking groups (like in Photoshop files)" http://bugzilla.gnome.org/show_bug.cgi?id=51112 - "Add support for Photoshop Styles and adjustment layers" http://bugzilla.gnome.org/show_bug.cgi?id=79025 - "use the linking of layers for more useful action than moving only" http://bugzilla.gnome.org/show_bug.cgi?id=86277 - "add support for layer trees or layer groups" http://bugzilla.gnome.org/show_bug.cgi?id=86337 - "Adjustment Layers (like in Photoshop)" http://bugzilla.gnome.org/show_bug.cgi?id=98262 (marked as dup. of #79025, but contains some useful descriptions) -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
* Raphaël Quinet <[EMAIL PROTECTED]> [021129 18:38]:
> On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland <[EMAIL PROTECTED]> wrote:
> > Btw, has there been a discussion on how layer grouping will work?
> > I want to be able to both group layers in just a group (aka doesnt change
> > how rendering works at all) then also be able to group layers together, and
> > have the output of that act as a layer (aka, for calculating the "virtual"
> > layer, only the layers inside of it are done, no outside layers interact with
> > these except through the final "virtual" layer.)
>
> There has been some discussion about layer grouping, but I do not
> think that any concrete implementation proposals have ever been agreed
> upon. So anyone who could come up with a GUI mock-up is welcome.
> Code is even more welcome, of course. ;-)
>
> So as you mentioned yourself, there are two ways to define "groups":
> they have different purposes and need to be implemented differently.
A little while ago I added another little code project to my todo queue, it's
just a toy project but might end up providing useful ideas for the implementation.
I've been toying with the idea to create a small program that is built entirely
of plug-ins and allows you to build graphs of dataflow between inputs and outputs
of the plug-ins (nodes in the graph). And thus enable the coding of a function that
only blurs the brightness and not the color of an image to be "coded" visually
like this:
RGBA value_blur(RGBA,radius){
.--RGBA--.
| split_RGBA |
`-R--G--B--A-'
| | | |
| | | `---.
.-R--G--B-. \
| rgb2hsv | \
`-H--S--V-' \
| | \ \
| |\ |
| | .---V--. |
| | |blur(radius)|
| | `---V--'/
| | | /
| |/ /
| | / /
.-H--S--V-./
| hsv2rgb | /
`-R--G--B-' /
| | | /
.-R--G--B--A-.
| join_RGBA |
`--RGBA--'
}
At the moment I'm pondering about reference counting to avoid exhausting memory,
It'll take a little while until I have the time to start working on it, this is a much
more general approach, but if I end up with something viable at least the ideas can be
used to implement most kinds of layer grouping etc. since they will be graphs with
special constraints.
http://phpweb.hig.no/~oey_kola/graph.txt <- some more of my ascii ramblings.
I don't want to try to implemnt this in gimp directly since it's mostly playing
with some design ideas I have, but if the ideas work out nicely,. gimp should be
able to benefit from the fact that the problem has been attacked a little outside
gimp.
--
.^.
/V\Øyvind Kolås, Gjøvik University College, Norway
/(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
^ ^
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On Fri, 29 Nov 2002 19:10:20 +0100, [EMAIL PROTECTED] wrote: > * Raphaël Quinet <[EMAIL PROTECTED]> [021129 18:38]: > > There has been some discussion about layer grouping, but I do not > > think that any concrete implementation proposals have ever been agreed > > upon. So anyone who could come up with a GUI mock-up is welcome. > > Code is even more welcome, of course. ;-) [...] > A little while ago I added another little code project to my todo queue, it's > just a toy project but might end up providing useful ideas for the implementation. > I've been toying with the idea to create a small program that is built entirely > of plug-ins and allows you to build graphs of dataflow between inputs and outputs > of the plug-ins (nodes in the graph). And thus enable the coding of a function that > only blurs the brightness and not the color of an image to be "coded" visually > like this: [... nice ASCII graph snipped ...] > It'll take a little while until I have the time to start working on it, this is a >much > more general approach, but if I end up with something viable at least the ideas can >be > used to implement most kinds of layer grouping etc. since they will be graphs with > special constraints. Yes, this is a nice idea, although this is different from the feature that we were talking about. As a matter of fact, the idea that you present here has already been discussed on this mailing list. This is similar to what is done in a program called "Khoros" and its interface "Cantata". If you do a search on your favorite search engine and look for "gimp" and "khoros", you may find some interesting links. This idea has been discussed in January 1997, August 1998 and December 2000. You will find a summary of the last proposal by Adam on the following page (section "4. Pupus Pipeline"): http://kt.zork.net/gimp/gd20001231_25.html It is not easy to find the complete archives of this mailing list before 2001 (except in my private archives), but I found the following pages: August 1998 http://groups.yahoo.com/group/gimp-developer/message/4578 (a quote from my January 1997 message): http://groups.yahoo.com/group/gimp-developer/message/4582 December 2000 (Pupus pipeline: what Adam has been doing, etc. etc.): http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/thrd3.html As far as I know, nobody has ever managed to implement all these nice features... -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] (2002-11-29 at 1833.03 +0100): > - Simple linking of layers so that some operations such as toggling > their visibility or moving the whole group of layers can easily be > applied to them (bug #86337, bug #86277). These operations would > not modify the pixels in the layers. This could probably also be > used for implementing the clipping groups (bug #51112). Clipping sounds more like ATOP operation in other docs, not like simple move or visibility, so I would put it in the other group, or make it some kind of blend mode (hidden) or pre process in blend operations. It "modifies" pixels, by looking at the bg alpha. The traditional document about digital composition is from Siggraph 84, by Porter & Duff, just in case people want to read more this ATOP thing. Scanned copy at http://www.keithp.com/~keithp/porterduff/. > - Grouping of layers in such a way that a merged image of the layers > is stored in a virtual layer and some operations can be applied to [...] > (merged view + results) and to apply the PDB function only to the > regions that have been modified, but this is only an optimization. You say they are the same, which from the one point of view is correct. But from other they have some differences that would make nicer to consider them a bit special. Layer effects would allow external ops, and use two drawables only, "in" and "out", with "in" one being updated rarelly (and thus "out" too). They are more artistic oriented, to say it quickly. Adjustment layers would allow core ops and N inputs, with those N changing a lot, and thus lot of recomputation, like blend modes. What is more, I would see them as blend modes that have some vars to control the formulas, and the RGB channels working as selection does. This also means that, probably, layer effects have a region of interest of multiple pixels for each output pixel, while adjustment layers only get a pixel, operate and put back (use LUTs?). If the system can be done so fast that there is no big differences, I see no problem with making all the same. Otherwise, maybe a forced separation would be better. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] (2002-11-29 at 1937.59 +0100): > Yes, this is a nice idea, although this is different from the feature > that we were talking about. > As a matter of fact, the idea that you present here has already been > discussed on this mailing list. This is similar to what is done in a > program called "Khoros" and its interface "Cantata". If you do a It is like some composition engines work, for example NothingReal's Shake (now Apple's). In the world of 3D shaders, too, like ShaderMan or Maya's system. They just have systems capable of passing streams of data thru the nodes, requiring a timeline interface, so you can see that side of the problem too, the offsets from stream to stream. But if you only allow one image per input, you can work with the tree alone. I do not see why it can not be used for layers, after all, the only limit is what kind of bricks you have avaliable (current layer stack would be a lot of blend:normal, blend:disolve... bricks). Current way: Top layer (soflight) Middle layer (burn) Bottom layer (na) [No Applicable, there is nothing "below"] In tree: IN:TL \ IN:MLB:Softlight - OUT \ / B:Burn / IN:BL Now lets do groups: Layer A (softlight) | Group A,B Layer B (na)| (hardlight) Layer C (burn) | Group C,D Layer D (na) | (color) Layer E (na) And the equivalent: IN:LA \ B:Softlight / \ IN:LB \ \ IN:LC B:Hardlight - OUT \/ B:Burn / / \ / IN:LDB:Color / IN:LE I can go on, with layer effects, adjustements, channel compose and decompose, plugins and so on. Probably I could do bricks for paint tools, if so inclined (paint in multiple places at the same time, undo by disabling bricks...). Making big boxes would allow clearer grouping, simplify paint ops (all strockes become one box), or reducing the undo steps. :] Exposing part or all the tree would confuse people, that is true, but could make some other things nicer. Depends in the target. So are we talking about the engine or the interface or both? And after all this rant... is anybody checking GEGL docs? It would save me doing ascii art. ;] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp is neither an island, nor a windows product.
The gimp community? REALLY? You could ixnay on the inuxlay, but not GNU. I feel for anyone trying to port gimp to windows, but I don't care about their work. To hell with Windows. Why would we care about windows? Windows has Photoshop, as does Apple. I've used gimp on windows, and it doesn't work so well, because the OS just isn't there. If window users are our largest user base, and gimp is going to windows, then gimp is dead. How long will it be before we pickup directX and other stuff controlled by the evil people? gimp is NOT a windows product. Nor should it ever be, nor should we want it to be. Those people can't even render a png in MSIE! What the heck are we doing there? That's my opinion, and GNU/Linux is the company I keep. As this is already too much said on it, I'd like this to be a conclusion to my comments regarding recent conversations. Figure it out. David Weeks -- You can call me at: 813-236-2009, USA [EMAIL PROTECTED] Shop TampaPC.com! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On 29-Nov-2002, Raphaël Quinet wrote: > However, here is my point of view (which may be different from what > some other developers think, so do not take this for granted). There > are two kinds of "grouping": > > - Simple linking of layers so that some operations such as toggling > their visibility or moving the whole group of layers can easily be > applied to them (bug #86337, bug #86277). These operations would > not modify the pixels in the layers. This could probably also be > used for implementing the clipping groups (bug #51112). > > - Grouping of layers in such a way that a merged image of the layers > is stored in a virtual layer and some operations can be applied to > this merged layer: color adjustments, transformations or even any > PDB operation, including the ones done by a plug-in. Whenever a > layer in the group is modified, the merged image is rebuilt and the > operation associated with it is applied to in order to re-create the > updated "active layer". This can be used to implement the Photoshop > styles or adjustment layers (bug #79025, bug #98262). In summary, > the "active layer" would have a list of layers, a drawable and one > PDB function (with its current parameters) associated with it. > Whenever something happens to one of the layers in the list, a new > (invisible) drawable is allocated, it gets the merged copy of all > layers, and then the PDB function is applied to it. When the > results are ready, the new drawable replaces the one that was > visible. In some cases, it may be better to keep the two drawables > (merged view + results) and to apply the PDB function only to the > regions that have been modified, but this is only an optimization. > > So as you mentioned yourself, there are two ways to define "groups": > they have different purposes and need to be implemented differently. > That is a _perfect_ explination of what I want. =) -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989 msg03144/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] wrote: I've been toying with the idea to create a small program that is built entirely of plug-ins and allows you to build graphs of dataflow between inputs and outputs of the plug-ins (nodes in the graph). This is exactly what Gimpeon does. It's a Gimp plugin, lets you build a graph (well, actually a line, since I don't have any multi-input nodes yet) of processing nodes, animate parameters over time, display multiple points in the graph, update them as you adjust parameters, and apply the processing graph (line) to a sequence of images. http://www.ozemail.com.au/~hodsond/gimpeon.html It's crashable, but you should be able to get the idea. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp is neither an island, nor a windowsproduct.
On 29-Nov-2002, David Weeks wrote: > The gimp community? REALLY? You could ixnay on the inuxlay, but not GNU. > > I feel for anyone trying to port gimp to windows, but I don't care about their > work. > > To hell with Windows. Why would we care about windows? > > Windows has Photoshop, as does Apple. I've used gimp on windows, and it > doesn't work so well, because the OS just isn't there. Though this is a troll, and I usually dont respond to them, this one grabbed my intrest. Photoshop sucks. It may be a $500 some product, but it sucks. Not even windows or mac users should ever be forced to use such a shitty product. > If window users are our largest user base, and gimp is going to windows, then > gimp is dead. How long will it be before we pickup directX and other stuff > controlled by the evil people? Actually, I wonder if mac users is our largest user base. More graphic artists are on macs, not windows. > gimp is NOT a windows product. Nor should it ever be, nor should we want it > to be. Those people can't even render a png in MSIE! What the heck are we > doing there? > > That's my opinion, and GNU/Linux is the company I keep. As this is already > too much said on it, I'd like this to be a conclusion to my comments > regarding recent conversations. Figure it out. gimp isnt a _anything_ product. It works on any operating system that has a sane gcc and sane gtk. Blame the people for prorting gcc and gtk to win32. So, um, bite me. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989 msg03146/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
Hi, I am one of the "developers" of filmgimp, although really I am mostly bug-fixing and packaging it at the moment. While I'm not going to comment on accuracies of the web site, thats Robins area, but I would like to address some of the other issues raised... Firstly, like everybody else, I would prefer to avoid the split in code, and cant wait for GEGL to make it into gimp.. However, I feel that filmgimp satifys a short term need which is for a 16 bit and floating point paint package, until the 2.0 release happens. I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for "High Dynamic Range" imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images. The next major reason for developing filmgimp is a time-frame issue, VFX houses are rapidly moving to linux as their primary platform, and one of the many missing apps is a basic paint system (such as matador), the hope is that we can develop filmgimp to that level in a short time frame (6 months). The issues that we are dealing with are: * More recognisable UI - which generally means make it more photoshop like. The issue here is that many of our artists will only need a paint system once in a while, so we need a UI that is familiar to them. * Improved brushes (over current filmgimp version). * Better layer and channel support, in-particular for alpha channels. These have been issues that we have had with gimp for quite a while, and I think its very interesting that RnH (the main filmgimp developers), have been slowly addressing these issues and that their goals are extremely similar to ours. I would like to believe that once 2.0 starts forming, that all of us start migrating over to that new code-base. While there has been much talk about merging the filmgimp version back into gimp (or even the other way around), the difference are extremely large, even more if we talk about 1.3, I also would prefer to see filmgimp as a short term solution and rather than spend quite a bit of time trying a merge, I would personally prefer to spend the time later on 2.0, since most of the work and fixes that we would be doing during the merge would need to be redone for 2.0. I would like to know what the roadmap for gimp is after 1.4? When is the merge for GEGL? Are you planning 16 bit support as a separate thing to GEGL? Are there any design docs for 1.3? How much work was it porting to GTK2.0? Anyway, I have just joined the gimp-developer list, and will try to be more actively envolved, so that hopefully later I can contribute more to 2.0 down the road. Thanks... Sam. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-1.3.10 missing file.
I ran configure with --enable-python and when I ran the build it complained about missing the file: plug-ins/pygimp/plug-ins/gtkcons.py I copied it from CVS, and everything is ok. Sam. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
