Re: [Gimp-developer] Donation
On 01-Jul-2004, David Neary wrote: Hi all, I got home today, and was surprised and happy to see a large donation to the project from distrowatch.com. They apparrently have a policy of contributing regularly to various open-source projects, and this month it was us. A big thank you goes out to the DistroWatch guys, sizeable unsolicited donations are always great news, and bring a smile to people's faces :) Distrowatch rocks; though, um, wouldnt you think they would donate to a distro instead? -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On 17-Dec-2003, [EMAIL PROTECTED] wrote: Conceptually, I agree that alpha = 0 means that the RGB value of the pixel is undefined. Alpha = coverage; coverage = 0 means no pixel is there. Gone. Inexistent. On the other hand, mask = 0 does NOT mean that the corresponding pixel is inexistent, as we already agree (I think). Its only inexistant to the calculations. The RGB data doesnt go away, which is what I think you mean. However both alpha and mask accomplish the same goal, i.e. opacity/transparency of individual pixels. Personally, the first time I saw it I found confusing and irritating to have two different elements for the same functionality. Well, some image editors have alpha as a transparency mask, which is what would be better imho. Its better to visualize stuff this way. Being the things as they currently are, the problem that I see is that you can use alpha to do things that you can't do with mask, and vice versa. I would really like them to be just one, the Alpha Channel, treated just as any other channel, but that's nearly impossible for a number of reasons. As they are currently implemented, the only way to be able to get the advantages of both is to implement some mechanism for converting one into the other and vice versa. There was already one direction, accomplished with Apply Mask. The only missing one was the reverse, which is what bug #127930 addresses. I think that all the alpha and transparency mask operations should be folded in to just doing transparency mask, and then alpha on load be converted to transparency masks. Now that I can convert from one to another and the other way around, I can take full advantage of both. I'm aware that this operation might expose undefined data, and I agree that there's some problem with that. Indeed I proposed an alternative implementation of #127930 in an earlier message that you haven't commented on, though now I doubt it's even useful. My current idea is rather to try to solve it by defining the guidelines for zero-alpha pixel handling as was mentioned earlier in this thread. In my previous message I suggested to specify them as undefined, but maybe it's not a good idea after all as you seem to defend. I tried PS to see how it handles Alpha. I became quite frustrated. Once I deleted a part of the image and saved and reloaded it, I found *no* way of increasing the opacity of partially transparent pixels, not to mention totally transparent ones, except by painting. All adjustment tools had RGB but no A. Maybe it's just that I'm missing something because I'm not experienced with it but now I think that PS is not my kind of program. GIMP is exactly the same way. I have no way of doing alpha only operations, except when hacking up the transparency mask. My suggestion above would fix this. Colors are RGB, and Alpha is altered through the transparency mask. But I have sometimes found myself needing to do alpha editing. Here's an example. I drew a closed figure in a layer and as an approximation I put a grayscale copy of it as a mask then I applied the mask (i.e. converted it to alpha) to continue work on it. I went on drawing; when working on the background I suddenly realized that there were small spots within the figure that were partially transparent and I wanted them fully opaque. The figure was complex; if I used the anti-erase I could neglect to opacize the whole figure. My alpha-to-mask script became very handy in that situation. With the threshold preview I could identify the spots that were not fully opaque and remove them. As a final note, I've run into the same request from Gimp users for such a mechanism as the one implemented in Bug #127930 several times already. Having to use anti-erase is a pita. In addition to this, it should be possible to copy a transparency mask to a RGB layer, something GIMP doesnt support afaik. (Which, then, it would appear as a greyscale image) -- 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 signature.asc Description: Digital signature
Re: [Gimp-developer] Spam bad!
On 24-Oct-2003, Patrick McFarland wrote: Nuclear weapons good! Am I the only one getting spam via the mailing list? -- 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 signature.asc Description: Digital signature
Re: [Gimp-developer] Spam bad! OOOPS!
On 25-Oct-2003, Steven P. Ulrick wrote: The way I typed it made it sound like I was saying that Patrick was using Sven and Branko's e-mail addresses to spam the list. This was not my intention, and I want to publicly apologize to Patrick. I truly regret any embaressment or confusion that I may have caused. Whats the best way of disposing of a body? Wood chipper? My intention was to say that someone, (NOT Sven or Branko. Probably an Outlook based virus) was using the exact e-mail addresses that Sven and Branko use to send messages to the list. If you didnt notice, those are faked from headers. Its quite easy to do, and all the outlook viruses out there do it now. What should be done is that the list moderator attempt to ban the email addresses that actually sent the mail from the list. -- 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 signature.asc Description: Digital signature
Re: [Gimp-developer] Spam bad!
On 25-Oct-2003, Steinar H. Gunderson wrote: On Sat, Oct 25, 2003 at 03:37:51PM +0200, Branko Collin wrote: Are you sure you are getting spam via the mailing list? Did you only look at the From field, or also at the Received fields? They are definitely sent via the list: 1) They are prepended by [Gimp-developer], which I doubt a virus would do by itself. 2) Received: from lists.XCF.Berkeley.EDU ([128.32.112.242]) by BFLITEMAIL-KR2.bigfoot.com (LiteMail v3.03(BFLITEMAIL-KR2)) with SMTP+id 24Oct2003_BFLITEMAIL-KR2_176922_3827684; Fri, 24 Oct 2003 10:53:27 -0400 EST Yeah, what he said. I dont have any of the spams anymore, but did the real from header manage to get passed on? (ie, what isp should I have the list moderator add to the shitlist?) -- 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 signature.asc Description: Digital signature
[Gimp-developer] Spam bad!
Nuclear weapons good! -- 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 signature.asc Description: Digital signature
Re: [Gimp-developer] 1.3.x milestone bugs
On 21-Oct-2003, David Neary wrote: 118547Convert Text Layer To Pixels / Render Text Layer Wow, my bug is so important, its listed. -- 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 signature.asc Description: Digital signature
Re: [Gimp-developer] Kudos to The GIMP Developers!
On 24-Sep-2003, Tino Schwarze wrote: 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). Its up to how your os and processor arch works. Like, x86 has a limit of 4 gigs per process, and Linux is defaultly setup for something like 3 gigs for the process, 1 for the kernel. You could be hitting that. -- 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 signature.asc Description: Digital signature
Re: [Gimp-developer] A fresh pair of eyes.
dOn 01-Aug-2003, Kevin Myers wrote: Helps if you have a 4D ball mouse (like I do), instead of only a 3D wheel mouse. :-) Seriously though, mainly responding because I want to make sure the Gimp developers know that there ARE mice out there with built-in miniature track balls (2D) on top instead of having only single dimensional wheels on the top. These are known as 4D mice. I wouldn't want any changes made in response to this thread that might prevent the scroll ball on these 4D mice from working properly with the Gimp. Thanks, I used to have a similar trackball. It was a trackball, three real buttons, and then two wheels. Most apps I could scroll up and down with the first, and left and right with the second. (Including most gtk1 apps.) It was pretty nice. Alas, the thing died, and radio shack, who I bought it from, no longer was selling them. So, Im now stuck with a llama compaq branded balless mouse. *sigh* I hate comapq. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
On 29-Jul-2003, Sven Neumann wrote: I don't want to discourage you and it's certainly a nice expert/geek feature but I doubt that the casual GIMP user wants to type in any formulas. No, but I doubt the casual GIMP user cares about a feature they arnt smart enough to use yet. AFAIK this isnt a replace ment for all modes, just an additional mode. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 29-Jul-2003, Sven Neumann wrote: Yes, we should probably have Convert to Pixels for text layers. Since internally we wouldn't really convert, should we perhaps even stick a Convert to Text Layer menu entry to any ex-text-layer so it can be converted back if necessary? Actually, you probably should really convert. Convert to Pixels would infact destroy the text object, and make it a real image. And of course, while destroying the text object, you can no longer edit the text. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 29-Jul-2003, Sven Neumann wrote: I wouldn't mind if you or someone else filed bug-reports for these two issues... The Convert To Pixels bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=118547 -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 27-Jul-2003, Branko Collin wrote: On 26 Jul 2003, at 18:19, Patrick McFarland wrote: Wrong, Im an artist, and I prefer 1.3 over 1.2. Did you prefer 1.3 in January 2001? Did 1.3 exist in january 2001? -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 26-Jul-2003, Daniel Egger wrote: I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally. Wrong, Im an artist, and I prefer 1.3 over 1.2. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 27-Jul-2003, Daniel Egger wrote: Good for you. I know at least 6 persons who do not. :) However I'm quite interested in your reasons, would you please elaborate so I can get some feeling what to tell people when they ask me reasons for using 1.3. Well, the tabbed dialog boxes, docks, are very nice. They save a lot of desktop room (which is needed when you are editing large images, and arnt willing to zoom out a lot.) Also, the fact that it has a sane text plugin is nice. (I switched over to a pango based font system, so all my truetype fonts cant (read as: Im not willing to add them back to X.) be seen by gtk1 apps.) Also, the additional layer blending modes are nice. Ive used both Grain modes already in some images, and they are nice additions to plain Addition and Subtraction. And with all of this, the image scaling dialog box has linear/cubic right there, so I dont have to go the whole way into preferences to change which scaling mode I want. (Which was a big fucking pain in the ass.) And in addition to that, having editable font boxen is very nice. (Though, Id like a way to force it to be a rendered layer, because when you change the layer, and accidently edit the layer's text, it erases everything you did.) People who are photoshop fanatics will like the menubar (which I hate since I already use the right click menu.) The only thing I _dont_ like is there is no gimp-perl packaged for 1.3 in debin sid. (Is it not available for 1.3, or are ari and che not willing to package 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When Gegl?
On 21-Jul-2003, Joao S. O. Bueno wrote: On Monday 21 July 2003 4:47 pm, Adam D. Moss wrote: Patrick McFarland wrote: So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? gegl isn't a panacea... Perfectly said. Actually, I've skimmed trhough some docs on the GEGL, and I wonder, what are its actual uses for the final user? I can see it provides the grounds for easier hacking in the GIMP, and will facilitate the implemanetation of internal CMYK and FLoating point images, and such. But for GEGL alone, what does the artist takes? Ive been having a long discussion with Robin Rowe about stuff he possibly wants to do with CinePaint. I am, in this context, an artist. Stuff like CMYK is obvious how thats useful. (Desktop - printer stuff, etc) Floating point, however, is harder to wrap your mind around. The short answer is that quantiziation of data is bad, and more precision is better. To continue on this line of thinking, integers are limited to 0.0 and 1.0 (In 8bit per channel images, this is 0 through 255). Once its goes above 1.0, or below 0.0, data is lost. Floating point values are not clipped, so data is not lost. In addition, gegl would have been able to internally calculate using higher precision values, which allows it to unresrect itself from the accumulating error. (Basic programming concept, google for it.) So, you may have 8 bits per channel, but over the course of a dozen layers, you have tons of data. (More than can be represented in 8 bits at all times.) To avoid the accumulating error from snowballing, you use a much higher precision to calculate it. Floating point math comes in handy here too. So, with floating point, we've avoided clipping, and we've avoided premature quantization and accumulating of errors. Of course, most of what I said above applies to what you call layer combining. To apply floating point goodness to individual layers, take the common arguments for 8 bit per channel vs 16 bit per channel, and replace 8 bit with the word integer, and 16 bit with the phrase floating point. _In addition_ to the higher precision (called a larger dynamic range in film talk), you also can ignore clipping, because floating point doesnt have it. As an artist, the high precision layer combining is a godsend, and as a very gimp-abusive artist, high precision and no clipping all around is a godsend. So, this is why Im disapointed that it never came into being. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] When Gegl?
So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
On 18-Jul-2003, Christopher Curtis wrote: The 1.9.x Building GIMP 2.0 branch o GEGL -- Gimp 'E' Graphical Library o GCim -- The convergence integrated media object and utility library. I am one of these active users that have been lead to believe that gimp 2.0 will use GEGL. So, all the developers out that think 2.0 is yet another small gimp release, or something else (imho) stupid, can just go away or something. Im actually kind of sick of listening all of you bicker back and forth. From my outsider point of view, 2.0 is set in stone, and what it will include will be set in stone. Also, from my outsider pov, stuff like gegl is a very cool idea. Anything that allows gimp to be more powerful is always a good thing. I also see gegl as a major feature, something that would produce a 2.0. However, the more you all bicker, the less work is actually getting done. I hate to have to be the one saying this, but you should just be coding, because in the end, whoever codes gimp 2.0 is the one who gets to say what happens, or _nothing happens at all._ Gegl is basically the end all be all gimp graphics rendering engine. It will be able to do what no popular graphics manipulation program has done before. (I think.) 16-bit per channel graphics is good, and internal floating point based calculations independent of the actual image's bitdepth is good as well (due to the fact multi-layered images often go above 1.0 and below 0.0, and clipping severely damages the output.) Also, while Im on the pro gimp 2.0 kick, I read the xcf2 threads. I agree, something like gimp2 will need a better file format. Internally, I dont care whats in it. Im not a gimp developer, Im a user, so I should have to care. _However_, it needs to be able to be very extendable. I want to be able to store all future gegl supported bitdepth and color space types with it, I want to be able to depend on it to be stable the same way the professional people depend on psd being a half way decent format, and I want it to someday exist, the same way I want gimp2 to someday exist. A lot of users out there are depending on the gimp development team to get gimp2 done sometime in their lifetimes, and from what I see on here, this may never happen. And Im going to be severely disappointed if this happens. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient dithering
On 19-Jul-2003, Sven Neumann wrote: We might do another 1.2 release but I doubt that this will happen and it would surely be just be a bug-fix release with no new feature whatsoever. GIMP-1.3 is close to being released as 2.0 and support for 1.2 will be dropped then. Releasing the stable from 1.3 is a bad idea, and I think everyone knows it. I wrote an email a few minutes before this one, and I suggest you read it. 1.3 should become 1.4. It doesnt use gegl, and it isnt 2.0 material. Releasing 1.3 as 2.0 is possibly the worse thing any of you could ever do. You know those slashdot trolls who keep saying apple and bsd are dead? They'll say gimp is dead, and I will believe them. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile cache default
On 22-Jun-2003, Sven Neumann wrote: I'd say we go for 64MB. Yes, I agree. If it changes at all, it should be 64. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] version numbers
I say we just use 2.0 for the first stable tree using GEGL. This entire argument sucks, imho. The first stable tree using GEGL has been called 2.0 for so long, why call it anything else now? It isnt about GTK2, or about Gnome2, or about any thing else. Its just what someone started calling it, and it stuck. And yes, maybe its useless version number bloat, but who cares? Gimp has been 1.x for so long now, and GEGL is a huge step in gimp's development. When you change this much in a product, you up the major version number. On 19-Jun-2003, Owen wrote: On Wed, 18 Jun 2003 11:41:20 -0400 Carol Spears [EMAIL PROTECTED] wrote: maybe we can jump it up to 2 simply because everyone seems to be involved again :) Follow Mr Knuth's technique Call this one 1.4 which would be followed by 1.41 then 1.414 ... 1.4142136 ad infinitum This has the advantages of a. being the square root of 2, the number so many want b. The next version number will always be known.. And when GEGL comes along, this will be an exponential jump, so the numbers will begin at 2.7 (which will the version of GTK+ at the time) 2.71 ... 2.7182818 It's a cold, foggy grey miserable day...not much else to do :-) owen -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] MAXPATHLEN bug on GNU
On 03-Apr-2003, Sven Neumann wrote: well, actually this is just an initialization and MAXPATHLEN is a rather bad choice anyway. I'll just change it to some sane fixed value instead. So _what is_ a good sane fixed value? -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some feedback on Gimp 1.3.x
On 19-Mar-2003, Sven Neumann wrote: Hi, MArk Finlay [EMAIL PROTECTED] writes: 1. Everyone loves a good splash screen, but now Gnome has startup-notification which kinda makes them superflous. Startup notification lets you know that your applications is starting but it is not as intrusive as a splash. I have edited my Gimp Launcher to add the line 'StartupNotify=true' and to change it to run 'gimp-1.3 -s'. To me this feels much snappier than before. And eventually when nautilus has integrated support for startup notification it would make sense to do the same for the gnome mime-type. huh? I doubt that most of our users use Nautilus or even GNOME. The current CVS version of The GIMP now properly supports startup notification and there's a command-line option to disable the splash. What more could you possibly ask for? I use openbox by itself, with no desktop environment at all. I guess I represent the majority? -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] sourceforge cvs issue
Tor, sf.net wont remove the wingimp project until you, or any other qualified gimp developer tells them to. The project is already breaking atleast one rule, the one about only developers for a project can start a sf.net project about the said project. Please take care of this before it gets out of hand. Go here and fill a support request: https://sourceforge.net/tracker/?func=addgroup_id=1atid=21 -- 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 msg03461/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Just managed to build HEAD GIMP with autotoolson Win32...
So this means that, when gimp stable uses gtk2, no more win32 port of Gimp? (In this context, if an app compiles cleanly on an os with no code modification, then it isnt a port) On 26-Dec-2002, Tor Lillqvist wrote: I finally had time to try again, and after some head scratching and Makefile.am munging, succeeded. I built all the libraries that get built as shared libraries on Unix as DLLs, while Hans's MSVC Makefiles build many (most?) as static libraries. Any accidental breakage of Unix builds should be relatively easy to fix. The gimp.sym file seemed to have obsolete contents. I replaced it with the functions used by libgimptool and libgimpwidgets. I had to add a glue file for libgimptool, to enable the dynamic linking to the main executable, either gimp.exe or tool-safe-mode.exe (?). Building the plug-ins, and a closer inspection of what works and what is broken will have to wait until next week. I'm leaving for a short vacation tomorrow. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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 msg03400/pgp0.pgp Description: PGP signature
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
Re: [Gimp-developer] Script-Fu - Batch Mode Problem
On 20-Dec-2002, Steinar H. Gunderson wrote: On Thu, Dec 19, 2002 at 11:29:08PM -, [EMAIL PROTECTED] wrote: That's what I thought as well...but the scaling with imagemagick was causing pixelation. Scaling up or down? With which filter? (You're sure you resampled and not did a simple quick rescale, right?) If your're scaling down in gimp, go into preferences, and change scaling mode to linear. Cubic sucks for scaling down, and Im not sure why Gimp even allows users to make a choice (bicubic and such are always used for scaling up, bilinear and such are always used for scaling down.) -- 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 msg03313/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] alpha vs. transparency / translucency
On 18-Dec-2002, Sven Neumann wrote: suggests to replace the term Alpha in the GIMP user interface by the terms Transparency and/or Translucency. This could need some discussion here, that's why I'd like to point the fellowship of gimp-developer to this report. Please keep the discussion on the list. Once we've settled on a strategy for this, we might need a volunteer to go through the source and do the changes. Sounds like a good opportunity to browse the GIMP source and contribute, don't you think? I say leave it alone. Alpha is the correct term here, transparency isnt. -- 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 msg03292/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Re: Which Gimp
On 14-Dec-2002, Tor Lillqvist wrote: I agree that with Sven that it's wrong to call GIMP for Windows a separate project. The distribution for Windows has its own webpage, but if something about it should be called a project, it involves just the building and packaging of a distribution. I.e. not really much more than the building and packaging of a Debian, Red Hat or Solaris GIMP package, for instance. Well, from what I heard, it can load photoshop filters too. Something I wish the *nix version could do with wine =/ -- 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 msg03275/pgp0.pgp Description: PGP signature
[Gimp-developer] Photoshop Plugin Support
Hey all, its me again. First I would like to say Im not trying to start a flamewar here... but will the win32 Gimp target ever support Photoshop plugins, and will the *nix x86 Gimp target ever support Photoshop plugins via Wine? -- 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 msg03393/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On 10-Dec-2002, Sven Neumann wrote: the plan is not to have 16 bit or 32 bit or floats but to offer a framework that allows to handle image data more or less independently of its representation. GEGL is the framework and it already supports floating point, 8bit and 16bit integer. Adding more data formats shouldn't a the major problem. This is why I want film gimp to use gegl at its core, instead of the old gimp engine. Gimp and Film Gimp cant be limited in any way in the core of the program, so being able to support any bitdepth is extreamly important. Though, what needs to happen is that the internal rendering core, and all plugins need to support _atleast_ one major format, and that would be RGB/RGBA 32-bit float (aka spfp) per channel. Preferably, gegl would choose the best format (RGBA spfp for RGB, CYMK spfp for CYMK, and maybe a YUV spfp format? That could be useful for film gimp) for rendering and data transmission between modules/plugins. (It would choose the highest bitdepth option for the colorspace.) -- 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 msg03256/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On 09-Dec-2002, Stephen J Baker wrote: On Fri, 29 Nov 2002, Sam Richards wrote: I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for High Dynamic Range imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images. Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future. I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once. Erm, thats kinda cool, but unless we can access that framebuffer, it wont be useful to us. We'll still be stuck writing to the 8bit per channel 2D framebuffer. (Now, of course, we could chop the final display image into GL texturers, and display that, but that requires a spfp per channel GL texture mode.) Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white ( 1.0) and below pure black ( 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.) This also helps with HDR too. HDR is a spfp per channel storage mode, used by several high end industry apps. Those included is Lightwave, the famous 3D modeling/rendering application. With HDR enabled (and saving in a HDR format), you can alter the final image to bring out more detail from shadows and such by just altering the gama ramp, Due to the huge ammount of data, you wouldnt notice the difference the fixed copy, and the entire image rerendered with new lighting settings to correct the mistake: the least significant bit of data is still below even 16-bit per channel display modes. -- 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 msg03243/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On 09-Dec-2002, Stephen J Baker wrote: I'm not suggesting that this would be useful to GIMP - but that other developers who are working in 3D using modern rendering hardware will soon need support for 32 bit floating point texture maps. So, I was pointing out that floating point imagery is soon going to be important to many other user communities outside of the film industry and it follows that floating point images ought to be loadable, editable and save-able from within mainstream GIMP. IMHO, that's a better route to take than going to 16 bit or even integer 32 bit. Im not saying Gimp3D here: Im just saying using GL as an advanced framebuffer. Unless X (or win32) itself supports the spfp bitdepths, then our only recourse would be to use GL textures as a framebuffer to display the image. Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white ( 1.0) and below pure black ( 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.) You could use a modern graphics pipeline for that too - but it's a lot less friendly to code for - and it won't port to all graphics cards - so it's probably not likely to be a thing that GIMP would want to make use of. On something like an ATI Radeon 9700 or the upcoming nVidia GeForceFX, you can create floating point texture maps - and use the incredibly fast 'fragment shader' processor to composite, scale, rotate, perspect, tile or otherwise process them into the floating point frame buffer, then read that back into the CPU at the end. Whether that's faster than doing it in the CPU alone depends on the complexity of the per-pixel processing - for complex per-pixel operations, I'd expect the graphics card to be able to beat the CPU - but for simple operations the data transfer overheads into and out of the graphics card would kill you. The nVidia card also supports a 16 bit 'half float' format which would be interesting for HDR. All of thats basically worthless to us _except_ for non-real preview modes where it doesnt matter if the image looks perfect, because its just an approximation. We cant use it for real rendering, because an xcf has to look the same on _all_ machines that view it. That means no matter what video card I have, it has to look the same on someone else's box, no matter what video card he/she has. The half float mode might be slightly useful for imitating a 16-bit per channel display. But that goes back to using gl textures as a framebuffer. There were a bunch of papers at SigGraph last year about rendering HDR images on a standard display without losing important visual information. All interesting stuff. That wouldnt make alot of sense. HDR isnt ment for displaying. Its ment for holding extra data that otherwise would be lost. For a final end target (eg png, jpg, dvd) the extra HDR data is thrown out because it is no longer needed. -- 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 msg03246/pgp0.pgp Description: PGP signature
Re: floating point (was: Re: [Gimp-developer] RH on Film Gimp andGIMP)
On 04-Dec-2002, Steinar H. Gunderson wrote: On Wed, Dec 04, 2002 at 10:49:05AM +0100, Tino Schwarze wrote: I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady. The point is probably to be allowed to go below 0 or over 1 -- you might not always want to work in a clamped range, like fixed point does. Yes, that would be very nice. -- 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 msg03195/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] bug hunting -- squashing windows bugs
On 02-Dec-2002, Lourens Veen wrote: And guess what, it fixes all GIMP bugs too!. After all, GIMP is part of GNOME, so if you don't install GNOME, there won't be GIMP, so there won't be any GIMP bugs! Yay! Erm, maybe this is a stupid redhat thing, but I thought GIMP just used GTK, (ala, it works on all desktops, including my anti-desktop environment desktop) Oh, and go debian! -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Film Gimp and GIMP
On 01-Dec-2002, Michael J. Hammel wrote: Maybe not. Consider that having competing branches can push the advancement of both. This is true of any research or commercial development. In this case, the discussion on 16bit support has been nudged yet again - perhaps enough to make real progress in the mainline. Who knows? I asked Santa for 16bit and/or sp fp rendering support in Gimp, and he said it was easier for me to ask for a Buzz Lightyear doll. =/ -- 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 msg03161/pgp0.pgp Description: PGP signature
[Gimp-developer] You would think this would be a faq
Why doesnt gimp have a webcvs setup? -- 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 msg03149/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Layer groups
On 30-Nov-2002, Tino Schwarze wrote: Apart from that, one often needs a copy of a layer to create some effect. Combined with effect or active layers, one would only need to alter the source layer and everything else would change by itself. That is the coolest thing ever. Santa, I want _that_ for christmas! -- 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 msg03152/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Re: Film Gimp and GIMP
On 30-Nov-2002, Robin Rowe wrote: A lot of text about how film gimp is trying to be its own thing. Well, first I would like to say film gimp should be moving to a GEGL target. Not because film gimp is gegl, but because gegl is so damn useful. (Well, will be useful if/when it gets done.) And gegl would be the perfect place for film gimp and gimp to share all the difficult base code (like, dare I say it, single precision fp layer rendering code.) Speaking of that, has anyone seen fg's xcf loader plugin? I heard he was sick... Maybe someone should send him some chicken soup? -- 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 msg03154/pgp0.pgp Description: PGP signature
[Gimp-developer] I am a newbie, yes its true
I want to develop stand alone 24bit - 8bit converter function, and also a bicubic resizer. Now, I noticed gimp has really high quality versions would it be possible to convert gimps functions to do: (with the converter) take an int 24bitimage[width][height] and return a char 8bitimage[width][height] and a int palette[256], those 256 entries being the 256 most used colors and all colors that dont match are set to the closest palette entry that matches. (with the bicubic resizer) take an int 24bitimage[width][height], and int newheight, newwidth, and return int 24bitimage[newwidth][newheight] I probably shouldnt ask this on here, but a) this is the only place that people familiar with the gimp source go, and b) I cant find what the functions are even called, nor what file they would be in. -- 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 msg03155/pgp0.pgp Description: PGP signature
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
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 insert stock rant here 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] 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: [Gimp-developer] Film Gimp and GIMP
On 28-Nov-2002, Sven Neumann wrote: the point is that the new film-gimp maintainer or any of the people working on film-gimp don't communicate with us at all. The project somehow came back to life without any notification on this mailing-list. We had to hear about it in the news. Among these news that appeared on the internet is a lot of wrong information. To me it looks as if the film-gimp people try to actively spread FUD about the gimp project. Hrm. Side note, They got $1k from Linuxfund to further their project... hrm... this is exactly the wrong information I referred to above. The film-gimp web-site makes you think that the film-gimp people expressed an interest to merge and the gimp people refused to take this into account. This is just plain wrong. oh. heh. It has always been the goal of the GIMP developers to merge the features needed for film-editing into the main GIMP. This has been a major subject on the GIMP developers conference. We were happy to have Caroline and Calvin at the conference who explained the concepts of GEGL as well as the needs of the film industry to us and I'm glad to see that they are still actively developing the GEGL library. I also liked the idea of the new film-gimp project to make the HOLLYWOOD branch available to a larger audience. Building a reasonably functional tarball that everyone can build was a good thing to do. Now people have something to play with and can start improving the gimp core and GEGL so that the main gimp can have these features as well. The direction the film-gimp project is taking at the moment seems like a wasted effort to me. That is my personal opinion and I have strong arguments for it but so far none of the film-gimp developers have asked for it and I will thus keep my arguments for me. Yeah, this is what I was trying to get at. Gimp 2.x is where all of us (gimp, and film gimp developers) should be going. -- 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 msg03126/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Film Gimp and GIMP
On 27-Nov-2002, Raphaël Quinet wrote: I have the feeling that the gap between GIMP and Film Gimp is widening more and more, instead of shrinking until the two versions can be merged in the same codebase. I understand that the development on the HOLLYWOOD branch has different constraints than the main branch and it would not be easy to attempt a merge for the moment (without GEGL), but I am a bit worried about the fact that Film Gimp seems to be diverging more and more. One of the goals of Film Gimp is to Bring the codebase up from 1.0.4 to rendezvous with Gimp 1.2.3. I think that it would have been better to aim for 1.3.x instead of 1.2.3. When GIMP 1.4 is released, the old stable branch (1.2.x) will not be maintained anymore (like 1.0.x now) so there is a risk that a version of Film Gimp aligned with 1.2.3 would be obsolete before its first release. Also, the next goal for Film Gimp is to add Windows and native Macintosh support. I see on the mailing list that some progress has already been made and it is close to completion. But I think that a part of this work could have been avoided by choosing GIMP 1.3.x as a target, since it is based on GTK+ 2 and has native support for Windows. Also, reading the web page and documentation of FilmGimp gives the (wrong) impression that GIMP developers are not interested in any future convergence of the two projects. While it is true that the HOLLYWOOD branch could not be integrated into 1.2.x, it has always been stated (or at least that's how I understood it) that GIMP 2.0 would be the end of the fork because the usage of the GEGL library would allow all Film Gimp features to be integrated into the main branch. This is not mentioned on the Film Gimp page, nor on the GIMP homepage, nor in the various articles that were recently published about these programs. That's a pity. With Film Gimp gaining more momentum in the last months, I am a bit concerned about the duplication of efforts and the gap growing wider. On the one hand, the increase in activity around Film Gimp shows that the main GIMP is not addressing some of the users' needs adequately and maybe the developers (us) should pay more attention to that. On the other hand, it would be nice if the Film Gimp documentation was mentioning a future convergence with GIMP 2.0 (assuming that this is still a valid goal for Film Gimp). I dont agree with the gimp and film gimp development groups. Film Gimp should be eventually folded into Gimp 2.0. Having two branches like this sucks bad. Film Gimp is slowly turning into something that isnt gimp at all, and I see alot of reinventing of wheels, or even parrallel development of the same code, because the development teams dont communicate enough. I agree with a lot of what you said, but in the end, its silly to have two branches like this. From what I heard, Gimp originally declined a merge with the hollywood branch, which I see as a serious mistake. Gimp isnt photoshop, and it isnt any other program that people compare it to. Gimp is more than all of them. And thanks to FG, Gimp can become much more than it is now. But I dont see this happening unless people realize having multiple (uncompatible) programs like this is extremly bad. I personally just want a Gimp that can load normal xcf files, and have an internal rendering path of more than 8 bits per channel as it has now. (Maybe single precision floats per channel? We could use GCC 3.2's experimental feature to use both the fpu and sse at the same time to do sp fp math extremely fast.) I tried Film Gimp, but as everyone as heard, the xcf plugin has... issues. And a GEGL enabled Gimp is so far off, it will be years before I see it done. As a heavy user and supporter of Gimp, I deserve the occational feature request, and my request is that higher precision rendering is added asap. /rant -- 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 msg03116/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Re: Return of 16-bit Per Channel Rendering
On 15-Nov-2002, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2002-11-14 at 2317.54 -0500): Cool, but I was talking about more overt development. What about gimp-film or gegl lists? GIMP devel is always done via lists, IRC, CVS and bugzilla. Check https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-film/ and http://www.gegl.org/. Thanks. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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 msg03083/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] GIMP Segfaults on startup
Well, three things could be causing this. GTK's interaction with X (or whatever target you built GTK for). It can be Gimp's interaction with GTK. (Probably not unless you have a really old GTK, or a really old Gimp.) Lastly, It can be your incredably outdated kernel and/or libc. On 23-Nov-2002, [EMAIL PROTECTED] wrote: Fine, fine, I'll subscribe already. *sigh* Moderator, please delete the similar post that has been sitting in the approve queue for over a week. Gimp Segfaults on Startup = Hi, After spending a whole day downloading, compiling and installing gimp 1.2.3 and its various dependencies, I was unpleasantly surprised to find the text Segmentation Fault as its only output. I searched the gimp and gtk lists for segmentation, sigsegv and other variations, but nothing useful turned up. Let the debugging begin. Tried running gimp with various combinations of options, in particular with any type of shared memory disabled. Conclusion: the only way to avoid the SIGSEGV is to run with --no-interface. Secondly, built and ran all examples supplied with GTK; all seem to work fine. However, the last trace (see below) suggests that it might be a GTK problem anyway. Since I'm really not sure, I decided to submit my problem to the gimp list first. I am very short on time at the moment, and can't be sure when I will have enough time to dive into the code. I am also completely new to the GIMP source, and with all due respect, wish to learn as little as possible about it. Now, before I dive in, does anyone have any hints, tips, suggestions or pointers to speed up my quest? Could it even be that this problem is already known? OS: Linux 2.0.39 Distribution : Custom/Homebrew GTK : gtk+-1.2.10 GCC : 2.95.3 libc : libc.so.5.4.38 Machine : P166MMX w/32 MB RAM Other info: ask Summary of debug attempts: === ((Full session transcripts are available on request. Same goes for my gimp and gtk build scripts.)) == laptop:~$ gdb gimp GDB is free software and you are welcome to distribute copies of it under certain conditions; type show copying to see the conditions. There is absolutely no warranty for GDB; type show warranty for details. GDB 4.14 (i486-slackware-linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)... (gdb) run Starting program: /usr/bin/X11/gimp Program received signal SIGSEGV, Segmentation fault. 0x402b2f97 in non_gui_paint_core () (gdb) bt #0 0x402b2f97 in non_gui_paint_core () #1 0x40187118 in non_gui_paint_core () #2 0x40176b0f in non_gui_paint_core () #3 0x40176bc9 in non_gui_paint_core () [*snip*] #74 0x400c997f in non_gui_paint_core () #75 0x400c7af7 in non_gui_paint_core () #76 0x400fc00d in non_gui_paint_core () #77 0x8164bfa in user_install_verify () #78 0x8163650 in user_install_verify () #79 0x8109364 in main () #80 0x8069f7e in _start () (gdb) == Hmmm... That looks suspicious. Time to build a debug version. Multiple nightly rebuilds were necessary to get a debug-enabled version. Had to free up extra diskspace to make it fit. G. Second GDB session summary: == laptop:~/src/gimp-1.2.3/app/gimp-1.2$ ( export MALLOC_CHECK_=2 gdb gimp-1.2 ) [*snip*] Breakpoint 2, gimp_pixmap_new (xpm_data=0x826fc80) at gimppixmap.c:108 [*snip*] (gdb) s 0x81db1c0 93 } (gdb) bt #0 0x81db1c0 in gimp_pixmap_get_type () at gimppixmap.c:93 #1 0x81db1da in gimp_pixmap_new (xpm_data=0x826fc80) at gimppixmap.c:108 #2 0x81bea97 in user_install_dialog_create (callback=0x8142138 init) at user_install.c:673 #3 0x81bde21 in user_install_verify (user_install_callback=0x8142138 init) at user_install.c:114 #4 0x8142112 in main (argc=1, argv=0xbd34) at main.c:399 #5 0x806a05e in _start () (gdb) s Program received signal SIGABRT, Aborted. 0x40250665 in non_gui_paint_core () (gdb) bt #0 0x40250665 in non_gui_paint_core () #1 0x402c4368 in non_gui_paint_core () [*snip*] #54 0x400c7af7 in non_gui_paint_core () #55 0x400fc00d in non_gui_paint_core () #56 0x81bf9e2 in user_install_dialog_create (callback=0x8142138 init) at user_install.c:934 #57 0x81bde21 in user_install_verify (user_install_callback=0x8142138 init) at user_install.c:114 #58 0x8142112 in main (argc=1, argv=0xbd34) at main.c:399 #59 0x806a05e in _start () #59 0x806a05e in _start () (gdb) == Still suspicious, but got the exact instruction where the error was caught. (Not necessarily very useful.) Note that libc's internal malloc debugger is enabled during the above session. (As per MALLOC_CHECK_.) Let's try a full trace. Third session summary: == (gdb) run Starting program: /home/zovier/src/gimp-1.2.3/app/gimp-1.2 Breakpoint 1, main (argc=1, argv=0xbd34) at main.c:121
Re: [Gimp-developer] Re: Return of 16-bit Per Channel Rendering
I was thinking about using film gimp originally, but the XCF loader is broken, I dont know how to fix it, and the developers for film gimp have no interest in fixing it. On 15-Nov-2002, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2002-11-14 at 2317.54 -0500): Cool, but I was talking about more overt development. What about gimp-film or gegl lists? GIMP devel is always done via lists, IRC, CVS and bugzilla. Check https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-film/ and http://www.gegl.org/. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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 msg03054/pgp0.pgp Description: PGP signature
[Gimp-developer] Return of 16-bit Per Channel Rendering
Has any work actually started on GEGL? From what I understand, no, none has. Even though GEGL is for gimp 2.0, there is no reason why we cant start developing this now. It might take awhile to get a good model started. -- 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 msg03049/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Return of 16-bit Per Channel Rendering
Cool, but I was talking about more overt development. On 14-Nov-2002, Branko Collin wrote: On 14 Nov 2002, at 5:22, Patrick McFarland wrote: Has any work actually started on GEGL? From what I understand, no, none has. Even though GEGL is for gimp 2.0, there is no reason why we cant start developing this now. It might take awhile to get a good model started. As you can see from http://cvs.gnome.org/bonsai/cvsblame.cgi?file=gegl/ChangeLogrev=roo t=/cvs/gnome, the last commit was yesterday. -- branko collin [EMAIL PROTECTED] -- 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 msg03051/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Return of 16-bit Per Channel Rendering
I would, but the xcf loader plguin is mad broken on x86. If you could figure out whats wrong with it and fix it, I would be very appreciative. On 14-Nov-2002, Joseph A Nagy Jr wrote: Patrick McFarland wrote: Has any work actually started on GEGL? From what I understand, no, none has. Even though GEGL is for gimp 2.0, there is no reason why we cant start developing this now. It might take awhile to get a good model started. if you are interested in 16-bit color, FilmGimp (http://filmgimp.sourceforge.net) is 16-bit capable. -- Joseph A Nagy Jr Purgatory is where Windows users go when they Founder and CEO die so they can figure out Linux and ascend into Joseph A Nagy Jr Enterprises whatever higher plane one belives in. http://jan-jr-ent.netfirms.com Linux - The Choice of Every Generation -- 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 msg03052/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Hey
Erm, dunno why this didnt reply to the list. To those who missed stuff, I asked Is it easy to add 16-bit per channel support to gimp? the answer was No it isnt. But yeah, Film Gimp has issues. The xcf loader plugin doesnt work at all on x86 (known bug) so thats why I turned back to Gimp to see if I could get it here. (I do all my graphics artwork in Gimp.) This might sound a little dumbassish on my part, but why wasnt 16-bit support added earlier? As far as I know, even Photoshop 6 doesnt have this (and when in native 16-bit mode, I cant get it to do layers at all.) And, yes, its hard to do now, but it wouldnt have been as hard in gimp 1.1 when it was in heavy development mode. Now of course, this would force all gimp 1.0 plugins to break (assuming the majority didnt already.) Though, my method wouldnt break any plugins, however. Any plugin accessing the data would get back 8bit values because the layers are still in 8bit mode, its only a higher precision rendering engine that would be added. 8 bit goes in, 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ layers, all doing things other than Normal mode, and sometimes bringing the darkest color below 0,0,0, and the lightest color above 255,255,255, it comes in handy.) On 11-Nov-2002, Raphaël Quinet wrote: On Mon, 11 Nov 2002 05:44:52 -0500, Patrick McFarland [EMAIL PROTECTED] wrote: Hmm, that todo is pretty cool. But Is there any way to push 16-bit rendering earlier? Or is there any other sane way to do this? The easiest way to push the 16-bit rendering earlier is to write the code and submit it to the developers. Alternatively, if you cannot program yourself, you could try sponsoring someone. If you are only interested in getting 16-bit support but you do not care about all plug-ins and new tools that were introduced since GIMP-1.0, then you can try http://film.gimp.org/ or http://filmgimp.sourceforge.net/. This will give you the 16-bit rendering that you are looking for, but this version of the GIMP has slightly older tools and less plug-ins than the ones you get in the current stable version of the GIMP. I dont know how the rendering pipeline works, but wouldnt it be relitivly easy to switch all the 8 bit variables with 16 bit ones, and just cut the final down to 8 bit for display, plugin data reading, and layer flattening? No, it is not so easy. There is a lot more to be done than that: with 8 bits per channel, the RGBA pixels (R, G, B + Alpha) can be stored in a 32-bits integer (int or long in C) and this is done in many places in the core of the GIMP as well as in the plug-ins. With 16 bits per channel, this would require a 64-bit integer, which is not available natively on many platforms. So a lot of code has to be re-designed. In addition, many parts of the code for calculating pixel coordinates and other things (mapping the coordinates to the position of the data in memory) would have to be changed. Even if the changes are not always big, there are still several thousands of lines of code that have to be changed. -Raphaël P.S.: You sent your reply directly to me. You could have sent it to the list as well, because I assume that some other people could be interested. -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hey
Hmm, mutt doesnt seem to like me today, because yet again I have replied to someone, and it replied to them and not the list. =| What I replied is as follows: Hrm, well, whatever works, you know? I thought 16-bit per channel would have been enough, but if you wanna do 32-bit per channel, go ahead. (It should render beutiful images up high like that) All we need is someone that would want to add it. On 11-Nov-2002, [EMAIL PROTECTED] wrote: The right way to support 8-bit is having 16-bit support for interim calculations, and the right way to support 16-bit is having 32-bit for interim calculations. Of course, when you're talking about workflow with complex transformations and multiple steps, interim is meaningless -- you need full support for the higher bit calculations. If an effort to support 16-bit is underway and is serious, there should be IMHO support for 32-bit. For example, to sharpen in the luminance channel of LAB mode, one would want to take a 16-bit image, decompose into 32-bit channels, apply the sharpening to the LAB channel, and recompose, at which point you would transform back into 16-bit. Such a procedure makes the channel transformation lossless. Without 32-bit interim support, it's lossy. (The same phenomenon renders all sorts of 8-bit transformations in complex workflows very poor in the current generation of gimp). My 2 cents. On Mon, Nov 11, 2002 at 08:13:53AM -0500, Patrick McFarland wrote: Though, my method wouldnt break any plugins, however. Any plugin accessing the data would get back 8bit values because the layers are still in 8bit mode, its only a higher precision rendering engine that would be added. 8 bit goes in, 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ layers, all doing things other than Normal mode, and sometimes bringing the darkest color below 0,0,0, and the lightest color above 255,255,255, it comes in handy.) -- 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 msg03047/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Hey
Yep, mutt is going to die. Yet again it refused to reply to the list and instead replied to just the person. Reply is as follows: On 11-Nov-2002, Sven Neumann wrote: Hi, Patrick McFarland [EMAIL PROTECTED] writes: Erm, dunno why this didnt reply to the list. To those who missed stuff, I asked Is it easy to add 16-bit per channel support to gimp? the answer was No it isnt. But yeah, Film Gimp has issues. The xcf loader plugin doesnt work at all on x86 (known bug) so thats why I turned back to Gimp to see if I could get it here. (I do all my graphics artwork in Gimp.) This might sound a little dumbassish on my part, but why wasnt 16-bit support added earlier? As far as I know, even Photoshop 6 doesnt have this (and when in native 16-bit mode, I cant get it to do layers at all.) And, yes, its hard to do now, but it wouldnt have been as hard in gimp 1.1 when it was in heavy development mode. Now of course, this would force all gimp 1.0 plugins to break (assuming the majority didnt already.) it does indeed sound dumbassish. It also this sounds like you are volunteering to contribute. Why haven't you done that when 1.1 was in heavy development mode? Why don't you do it now? The real reason? My C code isnt exactly the worlds best. (Aka you dont want to run it in a production app, ever.) And I dont have much time anymore. Im trying to find a job, which is eating up alot of my resources, and also with my current computer, it really kills my productivity rating. But yeah, if I could get those out of the way, I wouldnt mind helping. Though, my method wouldnt break any plugins, however. Any plugin accessing the data would get back 8bit values because the layers are still in 8bit mode, its only a higher precision rendering engine that would be added. 8 bit goes in, 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ layers, all doing things other than Normal mode, and sometimes bringing the darkest color below 0,0,0, and the lightest color above 255,255,255, it comes in handy.) we don't really care about the plug-ins and there will probably always be such an 8bit compatibility mode like the one you suggested here. The hard part is to do the necessary changes to the GIMP core. Since there are effectively only a handful of developers working on The GIMP and the code base is huge and used to be chaotic and fragile, this is not a trivial job. It will be addressed as soon a 1.4 is out. Well, actually someone could start to work on the 2.0 core based on GEGL right now while we are busy to finish 1.4. Salut, Sven -- 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Hey
Just checking if this works... Testing 1 2 3 -- 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 msg03043/pgp0.pgp Description: PGP signature
