[Gimp-developer] Alpha-transparency
with regards to the Alpha - Transparency issue... Stick with alpha add a glossary to the help menu to describe the meaning of any terms that the user has not across before. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Status report for GEGL
The www page does not seem to be updated in a while ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Film gimp Vs Gimp....
I think it best that Filmgimp do its own thing for the time being I personally use both... If there where any merging I would suggest the 1.3.x branch than the 1.2.x branch simply because the code in the 1.3 branch is so much easier to work with (I say that as someone who is almost completely unfamiliar with the code). I think that filmgimp want to meet your 16 bit + requirements NOW not when Gimp 1.4 or 2.0 rolls out. Once 1.4 is out and the move comes for 2.0 I would sincerly hope that both projects could merge (at least in back end functionality) as I suspect that Filmgimp will have many industry specific patches incorperated... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Alpha-transparency
On 24 Dec 2002, at 9:11, Danni Coy wrote: with regards to the Alpha - Transparency issue... Stick with alpha add a glossary to the help menu to describe the meaning of any terms that the user has not across before. There _is_ a glossary in the Help menu (well, at least last time I checked). -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] A more flexible last values system for the pdb
Note: this message is crossposted to gimp-developer because several developers interested in libpdb are not subscribed to libpdb-developer. Please do not send followups to gimp-developer. I've been thinking about a better way to implement the RUN_WITH_LAST_VALUES functionality in libpdb. The current method is annoying and kludgy. Depending on the first value passed to a procedure, the number and meaning of the parameters change, and the scheme is not readily generalizable. It is also not possible for other procedures to manipulate the values used, which would be desirable for macro recorders and plug-in adaptors that run on multiple images. I suggest the following: * we add a subfunction field to PdbProc, which is NULL for the main function. The interactive version would use interactive for the subfunction. * to call a plugin interactively, first call its interactive subfunction. The interactive subfunction will return a list of arguments to be used in the call to the main function. What do you think? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A Free Software project of interest.
Date: Mon, 23 Dec 2002 19:52:57 + From: Nick Lamb [EMAIL PROTECTED] Personally I think The GIMP has been exploited (not by any projects with the name 'GIMP' in them, I hasten to add) more than enough as it is. If someone has a proposal that requires more relaxed licensing then let them bring forth the proposal FIRST. So far I'm not very happy with the results of re-licensing and would be loathe to permit any further erosion. As the lead for one of those non-exploitive projects that uses GIMP in the name, I concur. We've never seriously considered relicensing Gimp-print. We've also never gotten any serious pressure to; commercial vendors (in particular, Epson) have no trouble with the GPL license. I'd personally rather not LGPL any of it because even the low level infrastructure could be useful for, say, a printer vendor that wanted to create a proprietary driver. I'd also really rather somebody not write, say, a proprietary dither algorithm and try to sell the package without source. I take a rather dim view of those who believe that there's some kind of inherent right to take communal code, make improvements, and then redistribute the combination in proprietary fashion (Microsoft in particular, but they're not the only ones). I'm rather more sympathetic to those who have something that's truly free source, but incompatible with the GPL for some minor reason, but it's not clear to me how to solve that problem. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Alpha channels
1) How do I create an image with an alpha channel (and set the value of the alpha channel)? This is specifically so I can test alpha channel handling in Gimp-print. Specifically, I want to move the alpha channel handling (and the color map handling, but that's a lot easier) out of libgimpprint and into the plugin. 2) It appears that thumbnail images (via gimp_image_get_thumbnail_data) always contain an alpha channel (unfortunately, this isn't really what I want for (1)). Is there a reason this is the case, or am I missing something? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Alpha channels
On 23-Dec-2002, Robert L Krawitz wrote: 1) How do I create an image with an alpha channel (and set the value of the alpha channel)? This is specifically so I can test alpha channel handling in Gimp-print. Specifically, I want to move the alpha channel handling (and the color map handling, but that's a lot easier) out of libgimpprint and into the plugin. file - new - fill type = transparent. 2) It appears that thumbnail images (via gimp_image_get_thumbnail_data) always contain an alpha channel (unfortunately, this isn't really what I want for (1)). Is there a reason this is the case, or am I missing something? Ever convert an rgb image to rgba? All the alpha for every pixel = 1.0. Its probably the same thing here. -- 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 msg03340/pgp0.pgp Description: PGP signature
