Re: [Gimp-developer] Auntie Alias plugin
Hi there! Michael Natterer wrote: yesterday, i stumbled across this mail, and it looks as if this plug-in is doing exactly the right thing to lineart images. I ported it to 2.4 API and codingstylized it a bit: http://mitch.gimp.org/auntiealias.c Since we consider including it, I have some questions: - The licensing would be changed to GPL, would that be ok? It wouldn't be my first choice as I took pains to non-taint it in the first place, but re-licensing to GPL is one of the things implicitly permitted by the existing license so if you must, do so. - Do you have any link to that Scale3X algorithm? I would be nice to include an URL in the help. This was *probably* the page I used as reference: http://scale2x.sourceforge.net/algorithm.html though to be fair that's just a page of pseudocode not especially clearer than the plugin's. :) - Is the behavior on images with alpha intentional? (it only affects opaque areas, but does not antialias between opaque and transparent parts) It refuses to antialias between not-entirely-transparent and entirely-transparent to avoid the possibility of giving some partial opacity to undefined colours. This was intentional but heavyhandedly implemented; there is likely to be a more delicate compromise. - Do you maybe have a newer version around? I'm afraid not; it was a one-day fire-and-forget experiment. Since there's some interest I'll have a quick hack to change the moronic subsambling kernel right now (n.b. that's not related to the alpha thing) and if the results are better I'll submit a patch. Cheers, --adam ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] filter layers
Jacek Góźdź wrote: I call it filter layers. Is it possible in Gimp, and if not, does anyone think about implementing it? It's been discussed for a long time. I had a working prototype several years ago, but it was pretty disgusting to implement in the GIMP 1.x era core. I think the general concensus is that this might suddenly become fairly easy with GEGL so it's better to wait until then. --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lanczos algorithm funnyness?
Steve Stavropoulos wrote: On 11/19/05, Dag Rune Sneeggen wrote: John Leach wrote: Looking at the original, I can see what it's accentuating but it looks bad. Other photos look great, much sharper compared with the cubic algorithm. This seems rather too sharp, in the wrong place. But still, its clearly a faulty algorithm... Quite serious as well(?) Am I the only one who sees the lanczos produced image, as a near perfect resize of the original? Yes, actually looks like a very interesting resize result to me too. Guess it's pretty subjective. --adam ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A Visit to GIMP
Leon Brooks wrote: Overlay a wall in someone's splendid-looking house with a montage of GIMP developers? 'Working on GIMP paid-off my mortgage!' --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [OT] Adobe Developers have a sense of humour
Alan Horkan wrote: Guess what the GIMP developers have been doing (well, perhaps not for ages)... I knew the Toys: GeeZoom, and Gee Slime; were Easter eggs but I've never looked for or accidentally discovered any easter eggs in the GIMP. A quick web search later [1] and I see holding Ctrl+Alt and then choosing Help, About will reveal a special About dialog in the GIMP as well as in photoshop. Most GIMP versions are completely peppered with easter eggs. It's sort of sad that they go so unnoticed despite it being open-source (so much for peer review :)) so I'll 'out' them that much. --adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code - urgent
Dave Neary wrote:
So - the actions (time-sensitive) are:
Add these two bounties to www.gnome.org (module gnomeweb-wml in GNOME
CVS, directory www.gnome.org/bounties edit bounties.xml, run
mono build.exe
for i in *.php; do php $i ${i#php}html; done
Seriously??
--adam
--
Adam D. Moss - [EMAIL PROTECTED]
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] parsing path data from xcf files
Sven Neumann wrote: Actually, it would be nice if GIMP would not reject your corrupt XCF file but warn and load as much of it as possible. Of course that will not be possible in all cases but it might be worth trying. This is the way GIMP used to work (maybe still does?), though in quite a coarse way (any whole layers and other [meta]data up to the first obvious corruption will get loaded, and a warning issued). I might be talking 0.99-ish ancient history here, but I can't see anyone having intentionally removed such a feature. Regards, --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Dave Neary wrote: - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it Photoshop is up to version ten now?? Bloody hell... and I remember when we felt all clever for figuring out some of the new PS4 PSD features... --adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] use of the Space key
Jakub Friedl (lists) wrote: it is a good idea. the descibed behaviour is really handy when editing zoomed in image. however i use the current space function too. would it be possible to use a different key for the temporary move tool? The genius behind the choice of space key is that it can easily be hit (on all keyboard layouts!) without looking away from the screen... --adam ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] who can tell me the type of color quantization algorithm in GIMP?
YG Wang wrote: The color quantization in GIMP is high-quality. Can you tell me which algorithm it is? Thanks a lot! It resembles a common axis-aligned box-cut (I tried many, many alternatives and just kept coming back to an axis-aligned box-cut for simplicity). It has various changes over a median box cut though, in how it chooses which box to cut and then how it actually cuts it. For example the position of the cut is carefully considered, the axis of the cut is very carefully considered, and (most unusually I suspect) it may choose to perform multiple even cuts of the same box along the an axis to keep the error even across the axes of the resulting boxes. Finally (and quite significantly, but not a property of the algorithm as such) the quantization occurs in L*a*b* space instead of the common RGB-alike. --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] use of the Space key
Sven Neumann wrote: Another image manipulation program, which GIMP is frequently being compared to, uses the Space key to offer the functionality that GIMP has bound to the middle mouse button: panning the image display. Since not everyone has a middle mouse button (especially on tablet pens), it might be a good idea to follow that example. If we did that, pressing Space would keep the current tool but the cursor would change to a hand symbol and one could drag the image display (not the content!) using the mouse. Any opinions on that, anyone? I agree that the space key should be reserved for something pretty amazingly common and useful. I suppose it's also likely that panning the image is a slightly more common temporary mode of action than moving a layer, regardless of what The Other program does, though we DO have a super-handy little single-click panning tool on the image window already, so overall I don't think it's a compelling win (or loss). --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Auntie Alias plugin
Hi guys and gals, I recently wrote this plugin for my own amusement; someone else might find a reasonably use for it. It probably does something very similar to the 'antialias' plugin for GIMP 1.2, except this is for GIMP 2.0 (2.X?) and uses a different algorithm (I haven't compared results). http://icculus.org/~aspirin/gimp/auntiealias/ --Adam ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Daniel Egger wrote: Maybe it would be best if someone could come example what supersampling might be useful for in gradient blend code except for slowing down everything... For an A-B linear blend it probably doesn't noticably help much (unless, possibly, it's a long colour range in a small area). But GIMP gradients *can* be fairly arbitrary user-defined 1D designs including near-discontinuities, which benefits from supersampling in the same way that a stroke, line or polygon benefits from antialiasing. --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: optional scaling in the save dialog?
Joao S. O. Bueno Calligaris wrote: - Initially using X memory duplicate image - now using x * 2 memory. That shouldn't be true. The vast majority of the memory used by the duplicate is tile data which GIMP simply copy-on-write shares between the original and the duplicate. (Unless COW stuff got broken since I last checked, but I doubt it.) --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Daniel Egger wrote: I can force it to use both CPUs now, but even with 200% utilization it is 2s slower to run this stupid ubenchmark than on 1 CPU without threads. Just a vague guess, but the multiprocessor GIMP pixel work scheduler might* farm alternating tiles to alternating CPUs. These are reasonably likely to have been allocated together and thus sit close together in memory, causing memory contention between CPUs. --Adam * I haven't looked at it. -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why not allow the name to be configurable? [was [Bug 160890] Change Gimp name (fwd)]
Alan Horkan wrote: Some people have difficulty dealing with the connotations of the term The GIMP. I wont go into details again about why some people have issues with the name, some even finding it offensive. I still find it baffling that people would get upset about something so lighthearted and harmless, but the idea of making the name configurable in the interests of a quiet life vaguely appeals if it can be done non-intrusively. Has anyone thought of (ab)using the i18n system for this? If all occurances of 'GIMP' can be tagged, someone can easily derive a en_US.TriviallyOffended translation from en_US... --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dither patch...
Ah, it's worse than I remembered, since the patch is actually against GIMP 1.2! But I'm compiling up GIMP 2.0.x now and so hope to have time to port this to 2.0 today, and from there hopefully it's only a short hop to 2.1.x (but I can't test that). --Adam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dither patch...
Michael Schumacher wrote: Why can't you test 2.1 (or 2.2pre, rather)? I thought GIMP 2.2 required GTK = 2.4. On a decent distro I'm not on a decent distro. :) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[semi-OT] Re: [Gimp-developer] Why not allow the name to be configurable?
The word itself is inappropriate for software if you're trying to feed it to the unwashed masses. I said this when GIMP was chosen as a name back when it moved from Motif to GTK A correction... GIMP was called GIMP long before the move from Motif to GTK. The first public release (0.53 IIRC) was called GIMP. It's always been GIMP. The only naming change that happened during the time of which you speak is that the 'G' started to stand for 'GNU' instead of 'General'. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dither patch...
Sven Neumann wrote: Please do file your bug report as soon as possible. We might even still sneak it into 2.2 if you are confident that your changes don't introduce any major bugs. Submitted as bug 161113. I've given it the usual selection of tests and I'm confident that it doesn't introduce any major bugs... I'll see if I can move my tree to 2.2pre tonight, though I suspect that the patch in that bug should apply to 2.2 pretty cleanly, since it's all 'deep code' stuff and would probably only collide with any cosmetic code-formatting changes. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Dither patch...
Hi. I've been sitting on a backend patch for probably most of the year, that greatly improves the quality of positional/fixed dither -- against GIMP 2.0.x. I was hoping to find time to get a GIMP 2.1.x build working and forward-port the patch, but that didn't transpire and it's likely too late for 2.2 now... I will attempt to file the 2.0.x patch in Bugzilla some time soon and if anyone cares they can forward-port it (hopefully the dithering back-end didn't suffer many changes during 2.1.x). Thanks, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] open thumbnail and raw files
Joseph Heled wrote: Option b) Go through the file system - write a temporary file and load it via a PDB call. (b) is the probably the simplest, but I am not happy about going to the file system and all the issues it brings. I wouldn't be too shy about it. The jpeg plugin itself (last I saw) does a similar thing when in 'preview' mode. Whatever works! --Adam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory usage [was: comparing gimp speed]
Sven Neumann wrote: You will however notice that GIMP instead needs 8 bytes per pixel. In addition to the 3 bpp for the RGB layer it allocates a projection the size of the image. This projection holds the result of compositing the layer stack. It is always allocated 4 bpp. Additionally a selection mask is allocated which adds another byte per pixel. (As an aside, once upon a time, we did have such a thing as greyscale projections.) So what could be done to improve this? We could for example try to get around the need for a projection for the case where people are working with a single layer only. Instead of displaying from the projection, we could display directly from the layer. I think we used to do this, too. At least, I struggled for a long time making the projection tiles be initialised to a lazy copy-on-write reference to the bottom layer (IIRC the tile hinting system would also preserve these cheap refs even when there were multiple layers where the upper layers were largely transparent). There were some annoying corner cases (duplicating a zoomed-in image) which I now don't remember if we ever got right. :( But it still seems like the elegant way to do this (erk, but it probably did rely on the projection being able to assume the same depth as the image). It might also help to allocate the selection lazily. That is to not allocate the tiles at all until the selection mask is altered. This might actually happen already, I am not sure about it. Not sure. Might be able to do this elegantly (elegance again being in the eye of the beholder) by initialising all of the selection tiles to a COW of the same 'blank' tile (and doing the same in the 'clear selection' operation, etc). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] stroking with gimp
Sven Neumann wrote: My guess is that you used a different brush when creating the stroke with gimp-2.0. The top two look like they were stroked with a square brush, which when applied to a circle is a pretty precise recipe for what transpired... --Adam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Dave Neary wrote: I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? Potentially, yes. :) A GIMP plug-in is a completely different process space than the GIMP core. I don't think that the GPL cares in the slightest about process spaces per se. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. Sure, but I don't think that's relevant, as such. We are basically talking about something very function-oriented like RPC, not something data-oriented like FTP. Putting it another way, we wouldn't expect for example a (non-system) GPL DLL to be licence- safe to link to a closed-source app just because ld.so was under a BSD-like license. Note that if this were not an issue then any app could use GPL code freely as long as it interceded IPC like a simple wire-protocol. (Personally, 'linking' like this would be entirely fine by me, but it's trivial to interpret the GPL as disallowing it, so we explicitly except it for the PDB/gimpwire.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Disobedience is the true foundation of liberty. The obedient must be slaves. --Thoreau ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
David Neary wrote: Are there any people opposed to closer ties with the GNOME Foundation? As long as GIMP wouldn't be in a rush to / obligated to subscribe to their apalling standards of slaphappy dead-end over-engineering and 1991-shareware approach to user interface standards then I think it makes reasonable short-term sense to exploit what GNOME *does* seem to be good at which is the centralization of services, organisational and financial structure... if that's helpful to GIMP (we've enjoyed peripheral use of some of their services such as CVS for a while). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Disobedience is the true foundation of liberty. The obedient must be slaves. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Come on guys and gals!
Let's hear more about actual GIMP development on this list, eh? :) It looks like the response to 2.0 has been positive albeit muted. Congratulations to all, and luck with 2.2... --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] PSD plugin...
I've just checked a small backlog of fixes into GIMP HEAD's PSD loader. Quick testing (i.e. whether it compiles :() from someone with HEAD would be welcome, since I guess we're getting close to GIMP 2.0. I'm also looking for someone who wants to actively maintain the PSD loader, since after six or seven years I'm sick of the sight of the ugly thing, er, I mean I don't have the time/tools any more. :) You'll need a fair corpus of PSD files from various Photoshop versions to check for regressions against (regressions are easy to introduce in some PSD files while 'fixing' others, and that's not good). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 At this point the rocket becomes engorged with astronauts. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dithering
Daniel Egger wrote: On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote: Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2? In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while. Hee hee... it's interesting how things can come full-circle. GIMP 0.5[34] did something very similar to provide a quick-render for interactive operations, re-rendering the results more nicely on the idle thread (undithered vs. dithered rather than aliased vs. interpolated, but for the same reasons). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 At this point the rocket becomes engorged with astronauts. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: However, the layer effects people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity. And that'd be pretty groovy, and it'd work BECAUSE the layer effect is conceptually (and in reality) a separate processing step rather than an attribute of the data it applies to. This is precisely how I see the layer mask versus the alpha channel. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Stephen J Baker wrote: I would rather hide that widget from Joe Public to avoid confusing him than to unnecessarily destroy valuable data. Let me say this one more time: If GIMP produces truly undefined data where Alpha is zero - then GIMP will become utterly useless for painting texture maps for 3D graphic applications. That's DEVASTATING to a large number of your users. Let me be clear, and hopefully just one more time. As far as I'm concerned, we're never going particularly out of our way to willfully smash/destroy/eat/zero data belonging to a value that has that become undefined -- but for any number of reasons (mostly optimizations of some sort) it happens, and will increasingly happen in the future of GIMP as a pixel's VALUE becomes further abstracted from its REPRESENTATION (example: is your favourite 10,0,80 HSV pixel being passed between GEGL stages as HSV, XYZ, L*a*b* or RGB? That will depend, and you will never know). The question is, should we expose non-power-user tools (one tool in particular, in my mind) that give the illusion that a pixel's raw byte representation is precious to the GIMP core? If your alpha channel is really a mask, use a mask. If your alpha channel is really an aux channel (i.e. specular index map), use an aux channel. If you are a power-user and willing to take your chances with alpha and particular power-user tools, know the risk and take your chances. If your favourite file-format plugin does not export and import alpha channels that are spec'd to contain non-destructive transparency data as layer masks, take it up with the author of your favourite file-format plugin. GIMP will always be (utterly) useful for painting texture maps for 3D graphics applications, but if you want and need a TRULY orthogonal (in the colourspace sense) channel in which to put your decal mask (or other attributes) then put it in one of the various supported GIMP data channels which are better suited to this purpose, if you wish your process to be futureproof. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
David Neary wrote: For the moment, unless I am mistaken, you are the only person to have stated that they consider the current behaviour wrt transparency flawed. I'd just like to say that I somewhat agree with Raphaël. Using alpha for 'hiding' and unhiding is conceptually wrong, it's quite equivalent to letting the user take the saturation knob down to zero and then coming back later, turning up the saturation again and wondering where the original colours have gone. I've said it before: an RGBA pixel isn't just an RGB pixel with a handy auxilliary channel. Alpha is the glass you draw upon; it accumulates coverage of a certain colour, but the colour of the glass itself is undefined. BUT, it's not the user's fault that GIMP hasn't really historically given this much thought, and has exposed tools and plugins which more or less pretend that the alpha channel is just another layer mask. The solution to just about all the 'I want my RGB data preserved orthogonally to the alpha in my file!' objections is to load and save the alpha as a layer mask, because that's precisely what people are wanting the alpha channel to be. That layer masks aren't quite as convenient to modify as alpha channels (that is to say, there isn't a tool that implicitly draws onto a layer mask a la eraser) is one of the reasons that people are going to keep abusing alpha. Right now probably isn't a good time to go crazy and change anything to accommodate (I'd still kinda like the deceptive anti-erase to go away, but don't mind stuff such as 'levels' working on the alpha channel on the understanding that it's a relatively power-user thing to do and that power-users understand that the resurrected RGB values of a 0-alpha pixel may not be as expected). (For the record, there have existed in the GIMP core for years some optimizations that skip RGB processing for certain sections of completely-transparent image regions, which can cause -- albeit under conditions in which the user is least likely to care -- regions of transparency in a composited image to 'go undefined'. No-one seems to have noticed or at least cared yet.) Regards, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: WilberWorks
Robin Rowe wrote: Can anyone say with certainty whether that is the same Scott Goehring that founded alt.religion.scientology? In what way is this important? --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 i18n ought to be abbreviated i2n to make it quicker to write!-snout ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
David Neary wrote: Henrik Brix Andersen wrote: According to http://registry.gimp.org/changes?max=15 the last change to a plug-in was done only a couple of days ago - so it seems the registry works at least for some people. Perhaps, but there are several things which should be possible which aren't. First, the majority of the plug-ins in the registry appear to be abandonware - 1.0 plug-ins that have never been updates to 1.2, never mind 1.3/2.0. We need a way to clean out the cruft (or at least hide it away). Second, the registry could do with a ranking system to have the most common and/or popular plug-ins appearing on the top of the lists of plug-ins. The only sorting system I've seen is alphabetically, which severely limits the usefullness of the site. Third, it is not possible to attach patches for existing plug-ins to a plug-in without being a plug-in maintainer. It would be nice if this were easier to do, perhaps with a comment system? Although I guess an inscription system makes some sense... Fourth, there needs to be a way to recover your password or something! My plugins died in the registry because the ability to update them was locked to an account that I'd forgotten the password to. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Manners.
Guys and gals, Would people please simply think a bit about the tone of their emails before posting? It seems that gimp-developer is increasingly perceived as a hostile, rude, or elitist mailing list, and some small effort on the part of posters would help to alleviate this enormously. Making GIMP's development communication environment more friendly is the key first step to winning more developers. (IMO #gimp has largely lost the battle already, and I'd hate to see the mailing list fall.) Conversely, it would help if people were also slower to take offense. :) It's easy to forget that many if not most of the people here are not native English speakers and might not be able to easily gauge how antagonistic their posts consistantly sound (I've met some of the worse offenders and they're generally not at all antagonistic people :)). Kind regards, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Guillermo S. Romero / Familia Romero wrote: To some extent, it reminds me of the Blender format (with the add on that Blender files are 64 or 32 bit, little or big endian, and all the plataforms can load them fine... Adam will love it :] ). I wrote a Blender file reading C library as part of my 'day job'... I wouldn't use the word 'love' exactly. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Adam D. Moss wrote: Okay, in that case I think I must have made a mistake in the forward-port of the 1.2.x fix to 1.3.x, because I can't reproduce this in my 1.2.x tree with the equivilent GIF plugin 4.01.00 fix in it. I'll try to spot what the forward-port does differently. I can't see anything wrong with the forward-port, and still can't reproduce this with the same mod on the 1.2.x branch. Now I can't afford any more time to look into this in the near future. Maybe someone who can reproduce this in 1.3.18 can come up with some ideas. Here's the unpublished 1.2.x gif-save plugin with the same fix that went into 1.3.17 (which I'm ASSUMING is the fix that is at the root of this problem), for comparison: http://icculus.org/~aspirin/gif.c --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Steven P. Ulrick wrote: How do I reproduce the problem -- would I be right in thinking that if I load the GIF above, then re-save it again and re-load the result then the resulting GIF will have a pink background? I answered this question in my response above, but to reiterate, the answer is yes, if you resave the image in Gimp 1.3.18 and reload it in any version of the Gimp, GQview, ImageMagick, whatever, it now has a pink background. Okay, in that case I think I must have made a mistake in the forward-port of the 1.2.x fix to 1.3.x, because I can't reproduce this in my 1.2.x tree with the equivilent GIF plugin 4.01.00 fix in it. I'll try to spot what the forward-port does differently. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Jeff Trefftzs wrote: On Mon, 2003-08-11 at 08:49, Adam D. Moss wrote: Hi. Jeff Trefftzs wrote: Without getting fancy, I just tried this image in gimp-1.3.18 (Linux, RedHat 9). It opened with the pink background Wait, it OPENED with the pink background? You didn't have to save it out again first? Yes indeedy! I downloaded the GIF from the URL you provided. (n.b. I didn't provide a URL, I didn't report the bug) When I opened it in gimp-1.3.17 (yes, 17, not 18, my bad) it showed the pink bg. Both in preview and when I opened it. This duplicates the reported behavior, btw. Okay, that's a pretty vital difference (and the reason I asked for clarification from the original reporter about whether it requires a save-then-reload, which he said it did in contradiction to what you've just reported, hence my general confusion). This means it's a gifload.c bug, not a gif.c bug (my last change to gifload.c was strictly a LZW bugfix so I can't see a potential problem there, but I'll try to look into it :( ). Thanks, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Nathan Carl Summers wrote: On Mon, 11 Aug 2003, Adam D. Moss wrote: IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. That's good to know, it helps me out with some of my own stuff... How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Stephen J Baker wrote: So, I think what is needed to make a reliable file format is to provide a well written library for reading and writing the files that's freely available and properly maintained on every modern platform FROM DAY ONE. I agree with this -- I think it's really important. (That's if we either want or expect the new XCF to become a defacto standard in the first place. Personally I'm not sure either way, but in any case it makes sense to library-ise the XCF load/saver just from a technical abstraction standpoint.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Tom Mraz wrote: If someone who sees the problem can test this fix: http://icculus.org/~aspirin/gifload.c that'd be good. I've tested it and it fixes the bug. Thanks all, the fix is in. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Nick Lamb wrote: On Sun, Aug 10, 2003 at 03:02:41AM +0100, Adam D. Moss wrote: Another data point is that floats are just a bastard to serialise in a portable, precise manner. Personally I'd represent a 32-bit float with a 32-bit integer and 32-bit fixed-point fractional part. Redundant but complete-ish. (Practical better ideas welcomed.) IEEE floats are portable except for the endian issue. 32-bit floating point PCM audio is just IEEE floats prescribed as little (iirc) endian. Where did you get the idea that this was problematic? IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions Whether they're included in the latest major distributions is quite irrelevant unless a developer (or indeed, user) is USING the latest major distributions. I imagine (okay, know) that unix-heads can be pretty shy of re-installing their operating system world just to get a small handful of the latest versions of OMG L33T DEPS!!! apps working properly. As you say, as time approaches infinity the issue tends to zero. Meanwhile... --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Hi. Jeff Trefftzs wrote: Without getting fancy, I just tried this image in gimp-1.3.18 (Linux, RedHat 9). It opened with the pink background Wait, it OPENED with the pink background? You didn't have to save it out again first? -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Tom Mraz wrote: It is probably this checkin: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=contextwhitespace_mode=showfile=gifload.cbranch=root=/cvs/gnomesubdir=/gimp/plug-ins/commoncommand=DIFF_FRAMESETrev1=1.30rev2=1.31 The guchar - gchar change without correcting the code using the buf isn't probably good idea? I think you're right. That bogus change totally sneaked under my radar... (heads will roll! :D :D :D ) If someone who sees the problem can test this fix: http://icculus.org/~aspirin/gifload.c that'd be good. Thanks, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): 7 able to support many color depth and spaces PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other IIRC (did I read the spec wrongly maybe?) the upper limit is RGBA with 16 bit per channel, no arbitrary color spaces or data formats. You would have to use gray PNGs to assemble other color spaces... and never want 32 int or floats, or use a similar trick than with colour spaces, split data. I think PNG does not fit 7 without tricks. Another data point is that floats are just a bastard to serialise in a portable, precise manner. Personally I'd represent a 32-bit float with a 32-bit integer and 32-bit fixed-point fractional part. Redundant but complete-ish. (Practical better ideas welcomed.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 'Fox News and all the other right-wing pundits thrive by assuring their audiences that they are the real unfortunates, oppressed by problems as varied as big government, liberal media, taxes and the bottom-feeders they serve, car-pool lanes, and France.' ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Nathan Carl Summers wrote: On Sat, 26 Jul 2003, Adam D. Moss wrote: 2) It might be argued that the basic dependance and interconnection of a not-GPL-compatible plug-in with the GPL GIMP core via libgimp and the wire protocol is intimate enough that the two cannot be considered independent and separate works. (Yeah, really.) From my reading of the exogen---oh, I don't know how to spell that word--of the GPL, that is mitigated by the fact that there exist (existed?) programs other than gimp that can use gimp plugins. Personally, I agree that this would be a strong argument 'in court'. But there's still no need to have any ambiguity at all. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ...I generally use sea salt but you can get fancy with Celtic or ghetto with table white... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Custom layer mode combination
Joao S. O. Bueno wrote: My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns. How are they recorded in the XCF file? (I may have missed that part of the thread.) So, a set ofrather itneresting formulas would be shipped with the Gimp (or with the patch). Users won't apply patches -- I doubt that more than a couple of percent of users are even actually building from source (especially for 2.0). Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only, Actually, thta already happens. The formulas are simply. The input operands are the letters describing a channel, followed by 1 if the channel belongs to the image bellow, or 2 if it belongs to the actual layer. And letter+D makes the destiantion channel. So something like: RD=R2*R2; GD=G2*G2; BD=B2*B2; will actually square the values of each channel. Since they are treated as normalized (i.e. from 0 to 1), it's akim to using the curves tool to enhance contrast sharply. (Well, contrast enhancement would be more like a sigmoid function -- what you describe here is basically gamma adjustment for a fixed gamma value.) I think that what GSR is really asking for in effect layers is stuff like 'blur layers', 'pixelize layers', etc, which basically is what everyone really wants. :) These require a decorrelation between the positions of pixels of different drawables though -- I made a working prototype of this during 1.1.x and it wasn't pretty. On the technical side - I will need to code in some string manipulation now. Are there API's for string deeply hidden ing gtk/gimplib? Not as such -- but if you're using GTK/gimplib then you're already using glib, which has some great string manipulation functions (go look them up). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
Carol Spears wrote: maybe he doesn't have cvs access That by no means stops anyone from submitting a patch against 1.3. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Adam D. Moss wrote: I agree that it would be wise to point out this explicit exemption for pdb calls into the GIMP LICENSE file. I'll do this soon if I don't get beaten to it. Done, for 1.2 and 1.3. (If anyone disagrees with the specifics, pull it...) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Carol Spears wrote: can someone explain these license problems in perfectly good fuzzy american words, complete with adjectives and interjections; perhaps limited to only 3 conjunctions for me? 1) The GPL doesn't allow a GPL and a not-GPL-compatible code unit to be intimately linked together. 2) It might be argued that the basic dependance and interconnection of a not-GPL-compatible plug-in with the GPL GIMP core via libgimp and the wire protocol is intimate enough that the two cannot be considered independent and separate works. (Yeah, really.) 3) This checkin makes our intention clear, as those imposing the license, that 2) is really not a problem. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Carol Spears wrote: for some reason, i thought that when gnu put the url to the creative commons page on their site and when the creative commons put gpl in the list of options, that all the license problems would go away. Gosh... no. stripping everything from the libgimp package and offereing each piece clearly licensed from one of a dozen or so web sites or people who want to distribute cds individually would this end the problems? No, that wouldn't help at all (least of all because this isn't really a problem of [re]distribution). But don't worry, this problem is solved. It wasn't much of a problem, just an ambiguity. Gone now. Rest easy. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
David Neary wrote: I think there are a few reasons for this. The biggest of them is that setting up a gimp 1.3 compile environment [..] automake, autoconf, libtool, gettext, intltool [..] (png, jpeg, etc) [..] gtk+ with pangoft2, freetype2, fontconfig [..] At least, that's my theory :) It's a good theory, being the mysterious reason why my own patches are made against 1.2.x and then blindly forward-ported to 1.3.x (it's why my commits are usually coupled with a bugzilla comment like 'could someone please check that CVS HEAD now actually compiles' :) ) But I was hoping that the reasons for other developers diffing against 1.2.x are even more mundane and fixable, since everyone except me lives in a fairytale world of supported rpms and debs and magical stuff like that. Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions. I agree. I think we need to do a little more to get developpment gimps built by more people. Exactly what, I don't know. Wait for GNOME2 to take over the world, perhaps? If the hegemonising swarm of sub-mediocrity that is GNOME ever succeeds in taking over the world, then I'm going to move up to the mountains and become a hermit or a kung-fu monk or a hermit kung-fu monk. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Manish Singh wrote: The libraries needed for a GIMP plug-in are licensed under the LGPL. The way the architecture is now, plug-ins don't link against the app directly. Quite so. However, from the GPL FAQ (I presume this is the root of Joao's excitement): http://www.gnu.org/licenses/gpl-faq.html#MereAggregation This implies that it *may* be quite plausible for the GIMP core to be considered as part of a plugin (or vice versa). Considered by whom, though, is another question. As I said, the ones to take umbrage at this binary coupling would be us, the developers, and we clearly don't intend to. But it probably worth making this clear as an explicit exemption in the LICENSE (this isn't an unusual action, for example GCC's libstdc code is GPL-licensed with exemptions for the resulting binary so as not to GPL-infect every C program built with with GCC[1]). --Adam [1] Except for GCC versions circa 3.1 where they forgot to exempt some portions of the code that ends up in the installed libstdc so the aggregate libstdc and hence almost all C programs built with that compiler are *technically* GPL- infected -- but still, their intent is clear, that this was simply an oversight and they have no intention of asserting the GPL on their users. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
[s/libstdc/libgcc/g, sorry.] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Adding ICC support
David Neary wrote: Definitely needs some coding (and some ideas) soon otherwise it's definitely getting bumped. Hi David. Thanks for all the QA work lately. Personally I think that we've got to be really brutal at this point. 2.0 freeze is DAYS away, for one thing (heck, until a few weeks ago 2.0 was going to be RELEASED at Camp). And as maintainers know, a pending freeze should NOT equate to arrghh, quick quick, shovel in the features before the freeze, We'll Fix Them Up Real Good Later. If it even vaguely smells like a feature and there's not already a patch for it (or it just involves tweaking some constants), IMO it must miss the 2.0 train. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: pspi
Tor Lillqvist wrote: Nathan Carl Summers writes: Gimp plugins do not link with the Gimp and thus do not fall under Gimp's licence. Gimp plugins do link with libgimp*, which is licensed under the LGPL. (note that Nathan's analysis is correct but incomplete, I believe) Are there any licensing issues, BTW, with the pspi plug-in? (The GIMP plug-in that interfaces to Photoshop plugins.) It is currently licensed under the GPL. (I am the copyright holder, so I could change its license if necessary.) The Photoshop plugins that it is able to load (as DLLs) are of course in general totally proprietary software. Is there any problem with this? (I don't distribute any Photoshop plugins.) I can't confidently say, myself. Technically in this case it's the end-user that is doing the 'linking' of the GPL and non-GPL code so you are personally not responsible for anything but having somewhat ill-licensed the pspi plugin for its intended use. :) But, my GPL interpretation gets fuzzy here because no-one is then simply redistributing the result of linking pspi and the Photoshop plugin, and the GPL is generally concerned with distribution rights, not private usage. (But then one part of me says 'so why would a non-GPL program depending on a GPL shared lib ever be a problem?' and things spiral down The GNU Ambiguity Vortex again.) But to me, your plugin sounds much more license-comfortable as LGPL (its entire nature, really, being that it links to foreign-licensed code). --Adam (NAL) -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When Gegl?
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... -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: (LONG) Problems with the GIMP
Carol Spears wrote: As much as I hate flash usually on the web, I think gimp needs a flash plugin and some flash demos. For what purpose? Could you elucidate? -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
David Neary wrote: Just to explain, this is about whether applications which use the libgimp API to furnish services to the main GIMP app should be called plug-ins or plugins. Old story - I believe bex insisted on plug-ins, and eventually won people over - carol prefers plugins. 'Plugins' is definitely wrong from a language point of view -- but it also seems to me to be more eye and finger friendly than 'plug-ins', and I think we can take it as de facto in the age of 'email' without being beheaded for treason against the Language of the Empire, or something. omg i mean it dont compare to most of what u see on the net lololol I don't think that the issue is worth holding up any documentation for. :) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: (LONG) Problems with the GIMP
Michael Schumacher wrote: 2) Not enough developers use Bugzilla to find out what bugs need fixing 3) Not enough developers hear user complaints Most bug reports I've read are commented by at least one person who I'd consider to be one of the developers. Personally there's no WAY I have time to trawl bugzilla looking for bugs in 'my' parts of GIMP, and I suspect that most other developers are the same. But when someone who knows CC:s me I try to take an interest. Bugzilla is good, but maybe the bugs aren't reaching the right developer with a good hit rate. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: One thing (to bring this more on-topic again) to note is that vim doesn't handle large (gigabytes) files nice, loading it into memory. The same is probably true for emacs. The only editor I know (I didn't test millions of them though), that nicely handles large files is joe, as it does't load them into memory. QEmacs does this too: http://fabrice.bellard.free.fr/qemacs/ I think it's only for unixoids. Not sure. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient dithering
Sven Neumann wrote: Alastair Robinson [EMAIL PROTECTED] writes: I've created a little patch against GIMP 1.2.5 to allow dithering of gradients, which significantly improves their appearance when printed. If you're interested, you can find out more here: http://www.blackfiveservices.co.uk/dithergrad.shtml How is that different from enabling Adaptive Supersampling in the blend tool options? It looks quite a lot different -- as far as I can tell from reading the patch, it does what it says on the bottle, that is, it (random-)dithers the truncated precision into the lowest bit(s) of the 8-bit precision that we support. Conceptually I like this, and the gotchas are toggleable via the UI. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
new-xcf (was:Re: [Gimp-developer] GIMP GBR format spec)
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
Well, ar's limitations with respect to name length etc. are in practise
not every severe (nobody will have 1 character file names (the ar
limit), and even antique ar implemnentations will support up to 255
characters).
Technically I don't know if that's true. From my ar man page:
GNU ar can maintain archives whose members have names of
any length; however, depending on how ar is configured on
your system, a limit on member-name length may be imposed
(for compatibility with archive formats maintained with
other tools). If it exists, the limit is often 15 charac-
ters (typical of formats related to a.out) or 16 charac-
ters (typical of formats related to coff).
But, that is of no consequence -- we wouldn't need to keep
meaningful names, we just need unique resource ids that the XML
structure can refer to... these could quite simply be numbers
counting up from zero, or hash strings. In either case just
15 characters could be fine.
I am not opposed to uncompressed jar files, but compression is certainly a
bad idea (the jar compression algorithm is rather ineffective)
I like the idea of ar files. Compression then happens by
[un]{b,g}zipping the ar via a compression plugin in the usual
GIMP style.
HOWEVER, this might be a good time to think about whether we'd
prefer a compressed format that we can random-access de/compress
on the fly instead of going via a huge (and with image data we
can easily be talking HUGE) temporary intermediate file. In
this case something like a ZIP (or okay, equivilently, a compressed
jar, whatever you want to call it) is a better (and still
exceedingly standard in its most basic form) choice of
wrapper for the hierarchy-file-plus-linked-resources.
--Adam
--
Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
Nathan Carl Summers wrote: (bah, watching actual real users in usablity tests at work stumble around when using really fairly simple interfaces has caused me to loose all faith in the intelligence of humanity. Then again, our users are actual real users, too.) Yes, quite so. :( Seeing such studies pretty much turned around my ideas on UIs. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What's new in GIMP-1.3 so far
David Neary wrote: By the way, what's the current story with PuPUS? Is it abandoned, or will it get released at some stage post-1.3+? You can look back through the archives for my notes on pupus' state. In summary I had to kill it because of lack of time. An early version was up and running, but today I doubt that even a quite complete implementation would be doing much more interesting stuff than a crossbred gstreamer+gegl (except for some of the interactive-image-processing-specific scheduling niceties, I think). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Responsible parents don't raise kids in West Virginia. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
David Neary wrote: I'll get the ball rolling: 2.0 8.0 (PeerMarketParityTM... sorry for the spam) -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Responsible parents don't raise kids in West Virginia. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: Gimp features]
I got this directed at me so I'm bouncing it to this list (don't ask me for an interpretation, I only work here). --Adam ---BeginMessage--- Hello Adam. I should propose next feature for gimp: Scale for brush. - I have scale brush - zoom in and zoom out.(bird,range,and all other brushes).Too I have propose brush rotation,imho this have sense - may be light in use,when draw image,next rotate hem(too not always this possible - drawing with brush rotate may have uniqe effect!)May be too have sense zoom shablones for brushes?Too very needing more editable (size(zoom),edit in gimp window)menu for brushes and brush shablones. Weeth esteem Alexander Yermakov. ---End Message--- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What's new in GIMP-1.3 so far
Sven Neumann wrote: - New RGB-Indexed quantizer Although this should generally be pretty good and better than the old quantizer, I was hoping to do a nice long tweaking'n'tuning session for this in the 1.3 timeframe, which is where things get sexy. Unfortunately it didn't work out like that because of time matters, so it's pretty much in the untuned state I landed it in. But it's okay. I really hope that I can get back to it at some point. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Responsible parents don't raise kids in West Virginia. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The first official release of the newGimpPreview widget
Ernst Lippe wrote: After an intolerable long wait, I just released the first official version of the new GimpPreview plug-in widget. You can find it at http://refocus.sourceforge.net/preview;. I've given it a cursory scan and it looks pretty good to me (interface and functionalitywise, that is, since any cosmetic details are a minor issue). It's always good to see people writing docs as well as code! I quite look forward to using this at some point. I really suspect that if there are practical flaws in the design then they're more likely to become apparent when authors try to apply the widget to a wide variety of plugins, rather than simply by reading the design docs. Regards, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Responsible parents don't raise kids in West Virginia. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Sven Neumann wrote: are you saying that we'd best remove the Anti-Erase feature from the current development version because it is broken by design and only works by accident (often but not reliably)? That's how I interpret your words but I want to be sure... I think that's the case. From a practical point of view the way things are at the moment you'd have to try fairly hard to get into a situation where you'd see the horizonal line drop-outs from the skipped compositing of transparent rows by the attempted resurrection of undefined colour data, but it's possible. From a more aesthetic 'broken by design' point of view, XachBot's antique logs probably catch me whining about anti-erase a few times. :) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Sven Neumann wrote: which operation (besides the evil anti-erase) wouldn't have such a color information? IIRC the only other tool I found that can be made to resurrect colour information is the Levels tool operating on the Alpha channel (I think that the current selected BG colour is a good choice for filling in the resurrected areas, if we allow the resurrection at all). There might be a few more plugins and such that accidentally cause a similar effect, but by accident (usually undesirable at that) rather than design. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Daniel Rogers wrote: I am missing some context here. Why does a tile get dirty? In gimp parlance, a tile is 'dirtied' whenever its pixel data gets written to (okay, that's a bit ambiguous with the tile ref system -- that could mean either when a write-able reference is added to it or when that reference is removed again upon the write completion). -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
David Necas (Yeti) wrote: I want a yellow opaque circle, with edges blurred to transparent and some fine yellow pixelish haze around. The transition I also don't like continuous, but spotty with varying opacity, so one can see the background better or worse through individual pixels. Layer mask! But thanks for bringing it to our attention that Noisify is one of the broken plugins in this respect. This isn't a new breed of brokenness that popped up when tile-row-hints went in. It's a fundamental problem with how some plugins handle alpha data and it's been evident for as long as GIMP has had alpha support. Create a new transparent image, draw a yellow blob in the middle, then blur the image by 10px. I really hope you'd expect to see a blurry yellow blob rather than blurry blob that's yellow in the middle and black (or worse) towards the edges... but the latter is what you used to get until someone (Raphael?) went around finding and fixing the various places that assumed that RGB and alpha are logically decoupled. They're not. You can't operate on them orthogonally, 'A' is not just another dimension in 'RGBA space' -- it's simply not, but when a tool/plugin makes this mistake it's just asking to fall into the singularity. In someone's mental model color values are inherently premultiplied, and alpha == 0 means R, G, B == 0. In someone's alpha channels is a fourth independent value we attached to each pixel and it doesn't directly interact with R, G, B. This schizm can't be solved because both model are correct in some sense and in some situations. However, Gimp uses separate alpha channel internally thus I see as illogical to force the other mental model. If you wish to have an alpha-adjusting playing-field then a layer masks is conceptually an operation that gets applied to RGBA pixel data as part of the compositing step, and that's super. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Daniel Rogers wrote: There may be some worth in considering including other kinds of information in a pixel besides alpha. In addition to alpha (the measure of coverage) you could also include transparency (which is something a measure of how much light passes through, i.e. the actual transparency of glass, as opposed the the coverage of a screen, this is equivilent to insisting on a layer mask to be included for every layer). It is a little tempting, as it would remove a lot of ambiguity in the overloading of the meaning of the alpha channel. We've (well, GIMP and probably most other transparency-handing packages out there) been equating transparency with alpha for so long now though that I'd hate to have to re-educate users. But it needn't be something that the front-end has to expose. We could also include luminesence, which is a measure of how much light a pixel produces (as opposed to reflectance, which is all we measure how with rgb). There are various per-pixel properties I could think of which might be very exciting (surface normal vector, specular reflection index) especially for natural media rendering. Luminescence wouldn't be the first that'd come to my mind, since I think that any such image elements would by nature be quite isolated and fit very well on their own 'addition' style layer and save a lot of complexity, but perhaps it would be nice to paint with fire after all... -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP Plug-In Template 1.3.0
Raphaël Quinet wrote: I'd suggest dual licensing: 1 - old-style BSD with advertising clause 2 - GPL or LGPL I was in the process of moving the code to the following XFree-style license if that's okay. I don't see the utility in dual-licensing since either of the above can trivially subsume the proposed license (apologies for mozilla deciding to kill the formatting): Copyright (C) 200X XX XXX (the Author). All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is fur- nished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FIT- NESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CON- NECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the Author of the Software shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the Author. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A Free Software project of interest.
David Hodson wrote: Adam D. Moss wrote: unfortunately the back-end is GPL which scuppers any realistic plans of GIMP's own back-end being able to move to it, I think. Eh? This doesn't appear to make sense. The goal (I thought) was to keep the lowest levels (GEGL etc) of GIMP's back-end LGPL. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new xinput device: no movement when button down
Michael Natterer wrote: This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be. Hi Adam, It's just the HEAD version of pango which requires fontconfig, you probably wanted to checkout the pango-1-0 branch. The branches are glib-2-0, pango-1-0, atk HEAD, gtk-2-0. Thanks! Got fontconfig now. The reason I was trying pango HEAD was that pango-1-0 does not compile for me. However, the same problem (below) occurs for me on HEAD too. D'oh. gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DPANGO_ENABLE_ENGINE -DSYSCONFDIR=\/usr/local/etc\ -DLIBDIR=\/usr/local/lib\ -DG_DISABLE_DEPRECATED -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/X11R6/include -I../.. -g -O2 -Wa ll -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -Wp,-MD,.deps/pango-ot-info.pp -c pa ngo-ot-info.c -fPIC -DPIC -o pango-ot-info.o In file included from /usr/local/include/glib-2.0/gobject/gboxed.h:26, from /usr/local/include/glib-2.0/glib-object.h:25, from pango-ot-private.h:27, from pango-ot-info.c:22: /usr/local/include/glib-2.0/gobject/gtype.h:92: syntax error before `typedef' @@gtype.h:91:#if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T @@gtype.h:92:typedef gulong GType; /usr/local/include/glib-2.0/gobject/gtype.h:167: syntax error before `gchar' @@gtype.h:167:G_CONST_RETURN gchar* g_type_name (GType type); /usr/local/include/glib-2.0/gobject/gtype.h:335: syntax error before `gchar' /usr/local/include/glib-2.0/gobject/gtype.h:336: syntax error before `gchar' In file included from /usr/local/include/glib-2.0/glib-object.h:25, from pango-ot-private.h:27, from pango-ot-info.c:22: /usr/local/include/glib-2.0/gobject/gboxed.h:28: parse error before `G_BEGIN_DECLS' /usr/local/include/glib-2.0/gobject/gboxed.h:36: syntax error before `typedef' In file included from /usr/local/include/glib-2.0/glib-object.h:26, from pango-ot-private.h:27, from pango-ot-info.c:22: /usr/local/include/glib-2.0/gobject/genums.h:28: parse error before `G_BEGIN_DECLS' /usr/local/include/glib-2.0/gobject/genums.h:46: syntax error before `typedef' In file included from /usr/local/include/glib-2.0/gobject/gobject.h:27, from /usr/local/include/glib-2.0/glib-object.h:27, from pango-ot-private.h:27, [cut -- lots more like this] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new xinput device: no movement when button down
Philip Brown wrote: BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :( I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the amount of library dependancies. I feel your pain. This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be. Thanks, --Adam -- Adam D. Moss . ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 zing thro===Even when I ch== skin is === === just bare don't = get puls== Still = unusua==fever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Sven Neumann wrote: mct:~ gimp-1.3 gimp-1.3: fatal error: Segmentation fault gimp-1.3 (pid:9613): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x40550924 in g_on_error_stack_trace (prg_name=0xb833 gimp-1.3) #1 0x4055083e in g_on_error_query (prg_name=0xb833 gimp-1.3) #2 0x80816cd in gimp_eek (reason=0x819cea8 fatal error, #3 0x808162e in gimp_fatal_error (fmt=0x40676e90 Segmentation fault) #4 0x8081225 in gimp_sigfatal_handler (sig_num=11) at main.c:501 #5 0x405c7858 in sigaction () from /lib/libc.so.6 #6 0x40564428 in g_main_context_iterate (context=0x8243550, block=0, #7 0x40564635 in g_main_context_pending (context=0x0) at gmain.c:2261 #8 0x40129e8e in gtk_events_pending () at gtkmain.c:863 #9 0x808e980 in user_install_continue_callback (widget=0x825e568, well, naturally I can't reproduce this here. I've removed my ~/.gimp-1.3 directory and was able to finish user installation w/o a problem. I can't see anything wrong with the code either: while (gtk_events_pending ()) gtk_main_iteration (); The crash is actually occurring inside gtk/glib-1.3 (joy!) but I haven't de-toxed enough yet to look deeper. *looks deeper anyway* Ah cool, a glib rebuild from today's HEAD stops me crashing. Thanks, now I almost have a working gimp! (After the current recompile, hopefully!) -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Sven Neumann wrote: Script-Fu is still adding layers while I write this and the count is approaching 4000 layers of 16x16 pixels here. At the moment gimp uses about 330MB of virtual memory (256MB physical RAM). The script has (gimp-displays-flush) after (gimp-image-add-layer ...), so the layers dialog is fighting to keep up with the amount of layers You could try duplicating an existing layer multiple times instead of creating new ones, so the copy-on-write code saves you memory. If your layer is 16x16 though, I imagine that the per-layer thumbs are taking more memory than the layer data! I think it'd still be a fair comparison if you closed the layers dialog -- an image with 1000s of layers is probably not expected to be managable sanely with what amounts to a list paradigm. -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael Quinet wrote: But it needs to be extended with all the names of the EXIF parasites. So I will try to do that this week. Basically, I think that it would be enough to use the name gimp-blah for each blah field of the EXIF data and simply copy the descriptions given in the EXIF standard. Fair enough, though if a parasite is going in the general-purpose gimp-* namespace care should probably be taken not to impose constraints specific to the EXIF form of that metadata upon a more general-purpose gimp-wide version. Some of the fields will have to be discarded (or set read-only or not persistent) because they only make sense for the original file format and are irrelevant once the image is converted to an RGB bitmap. Also fair enough, though I'd consider prefixing these with exif- or similar to avoid polluting gimp-* forever. FWIW I'm in favour of splitting out individual general-purpose parasites rather than a monolithic EXIF parasite. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Sven Neumann wrote: yes, it should compile. As usual the files HACKING and INSTALL mention the build requirements. In particular these are: [snip] Thanks. Well, 6 hours later I have gimp 1.3 built! Yay! Naturally, it crashes on startup. Boo! After trying to 'ok' the second page of the gimp user installation wizard I get this: mct:~ gimp-1.3 gimp-1.3: fatal error: Segmentation fault gimp-1.3 (pid:9613): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x40550924 in g_on_error_stack_trace (prg_name=0xb833 gimp-1.3) #1 0x4055083e in g_on_error_query (prg_name=0xb833 gimp-1.3) #2 0x80816cd in gimp_eek (reason=0x819cea8 fatal error, #3 0x808162e in gimp_fatal_error (fmt=0x40676e90 Segmentation fault) #4 0x8081225 in gimp_sigfatal_handler (sig_num=11) at main.c:501 #5 0x405c7858 in sigaction () from /lib/libc.so.6 #6 0x40564428 in g_main_context_iterate (context=0x8243550, block=0, #7 0x40564635 in g_main_context_pending (context=0x0) at gmain.c:2261 #8 0x40129e8e in gtk_events_pending () at gtkmain.c:863 #9 0x808e980 in user_install_continue_callback (widget=0x825e568, #10 0x405255c6 in g_cclosure_marshal_VOID__VOID (closure=0x825e340, #11 0x4051002e in g_closure_invoke (closure=0x825e340, return_value=0x0, #12 0x405247c0 in signal_emit_unlocked_R (node=0x825b4b0, detail=0, #13 0x40522f6b in g_signal_emit_valist (instance=0x825e568, signal_id=110, #14 0x40167e3e in gtk_signal_emit (object=0x825e568, signal_id=110) #15 0x400ac0b2 in gtk_button_clicked (button=0x825e568) at gtkbutton.c:548 #16 0x400ad259 in gtk_real_button_released (button=0x825e568) #17 0x405255c6 in g_cclosure_marshal_VOID__VOID (closure=0x825d7e0, #18 0x4051041f in g_type_class_meta_marshal (closure=0x825d7e0, #19 0x4051002e in g_closure_invoke (closure=0x825d7e0, return_value=0x0, #20 0x40524262 in signal_emit_unlocked_R (node=0x825d818, detail=0, #21 0x40522f6b in g_signal_emit_valist (instance=0x825e568, signal_id=109, #22 0x40167e3e in gtk_signal_emit (object=0x825e568, signal_id=109) #23 0x400ac012 in gtk_button_released (button=0x825e568) at gtkbutton.c:540 #24 0x400ad07e in gtk_button_button_release (widget=0x825e568, event=0x8321500) #25 0x4012b75c in _gtk_marshal_BOOLEAN__BOXED (closure=0x82521b8, #26 0x4051041f in g_type_class_meta_marshal (closure=0x82521b8, #27 0x4051002e in g_closure_invoke (closure=0x82521b8, #28 0x40524bcd in signal_emit_unlocked_R (node=0x8252200, detail=0, #29 0x40522fd8 in g_signal_emit_valist (instance=0x825e568, signal_id=58, #30 0x40167e3e in gtk_signal_emit (object=0x825e568, signal_id=58) #31 0x401f09d2 in gtk_widget_event_internal (widget=0x825e568, event=0x8321500) #32 0x401f05f1 in gtk_widget_event (widget=0x825e568, event=0x8321500) #33 0x4012b5f0 in gtk_propagate_event (widget=0x825e568, event=0x8321500) #34 0x4012a34e in gtk_main_do_event (event=0x8321500) at gtkmain.c:1069 #35 0x402b6d80 in gdk_event_dispatch (source=0x8243520, callback=0, #36 0x4056333b in g_main_dispatch (context=0x8243550) at gmain.c:1616 #37 0x40564187 in g_main_context_dispatch (context=0x8243550) at gmain.c:2152 #38 0x40564567 in g_main_context_iterate (context=0x8243550, block=1, #39 0x40564c80 in g_main_loop_run (loop=0x8320650) at gmain.c:2453 #40 0x40129c91 in gtk_main () at gtkmain.c:794 #41 0x8080463 in app_init (gimp_argc=0, gimp_argv=0xb6e8) #42 0x80811d3 in main (argc=1, argv=0xb6e4) at main.c:451 And now I'm going to go seek out some beer and friends to commiserate with... --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
(psd plug-in, adam's plug-ins) Re: [Gimp-developer] [Fwd: Gimp PSD plugin - SEGV when opening files]
(CC:ing gimp-developer) Hi Avi! 'Testing' just involves getting a reasonably sized collection of PSD files with a good mix of 'real world' data and more unusual stuff (various aux channels, layer masks, strange layer modes, strange pixel formats) and seeing in what ways the PSD loader barfs. A 'good' patch is one that allows a greater number of these files to be successfully read without breaking the reading of files which were previously readable. I don't have the (time) resources currently to support any of my plugins in terms of testing/applying patches or looking into error reports. The former should go to gimp-developer and the latter into bugzilla. My name should probably be commented-out from the MAINTAINERS file until my time situation improves (which seems unlikely for a while). Regards, --Adam Avi Bercovich wrote: Adam D. Moss wrote: Hi guys and gals, Could someone with a good collection of .psd files please test this against the PSD plugin to make sure it doesn't break anything that was not broken before, and if it checks out okay commit it to 1.2 and 1.3? I'm afraid I don't have the time for GIMPy stuff at the moment to test it myself. Hi Adam, I'd like to help testing anything related to the psd plug-in, because my projectleads are breathing down my neck about 'incompatibility' with the rest of my designer collegues. I generally use the previous state/version of the plug-in that I patch with the 'write psd' patch, as I need to send layered files back to people using Photoshop. Let me know if/how you'd like me to go about testing the plug-in. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: Gimp PSD plugin - SEGV when opening files]
Hi guys and gals,
Could someone with a good collection of .psd files please
test this against the PSD plugin to make sure it doesn't
break anything that was not broken before, and if it
checks out okay commit it to 1.2 and 1.3? I'm afraid I
don't have the time for GIMPy stuff at the moment to test
it myself.
Cheers,
--Adam
--
Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3
all cake everywhere has died
---BeginMessage---
Dear Adam D. Moss (PSD plugin maintainer)
Attached is a set of context diffs for a work-around for an issue with psd.c
(PSD Plugin version 2.0.6) and PSD files generated by PanoTools. The problem
was reported by Marco Nierlich [EMAIL PROTECTED] in the
comp.graphics.apps.gimp newsgroup, and he supplied a sample of a problem image
http://home.nierlich.org/avifile/pano_psd.psd
I think that the possible problems are:
1) no layermask data
2) the resize_mask() function introduces a 1 pixel down-right shift
3) The RGBA channels arrive in an unexpected order
4) some confusion (probably on my part) about 4-layer (RGB + mask) files
and when to add the mask layer
PS: I have not got a full copy Photoshop so I may have broken the opening of
some photoshop files without realising it. I think that having applied the fix,
some files generqated by PhotoShop 6 may get their masks incorrectly set when
loaded into Gimp. It also seems quite possible that PanoTools might be
generating invalid files - but without a full copy of Photoshop I cannot
test this.
--
Regards
Andy Wallis
==
Andy WallisEmail: [EMAIL PROTECTED]
Shillito and Company Web: http://www.shillito.co.uk
==
*** psd.c.STD Thu Jan 17 10:08:58 2002
--- psd.c Thu Jan 17 10:08:55 2002
***
*** 130,135
--- 130,141
/* *** USER DEFINES *** */
+ /* set to TRUE if you want Andy Wallis fixes for reading files from PanoTools, FALSE
+otherwise.
+ * There is probably a better way of fixing the problem. Note that these fixes are
+not tested
+ * against files from Photoshop apart from a few Photoshop 4.0 LE files and may
+cause problems
+ * with files from more recent versions of Photoshop */
+ #define AFW_FIXES TRUE
+
/* set to TRUE if you want debugging, FALSE otherwise */
#define PSD_DEBUG FALSE
***
*** 1068,1073
--- 1074,1090
/* throwchunk(layermaskdatasize, fd, layer mask data throw);
(*offset) += layermaskdatasize;*/
}
+ #if AFW_FIXES
+ /* If no layermask data - set offset and size from layer data */
+ if(!layermaskdatasize) {
+ IFDBG
+ fprintf(stderr, Setting layer mask data layer\n);
+ psd_image.layer[layernum].lm_x = psd_image.layer[layernum].x;
+ psd_image.layer[layernum].lm_y = psd_image.layer[layernum].y;
+ psd_image.layer[layernum].lm_width = psd_image.layer[layernum].width;
+ psd_image.layer[layernum].lm_height = psd_image.layer[layernum].height;
+ }
+ #endif
layerrangesdatasize = getglong(fd, layer ranges data size);
***
*** 1473,1479
printf(NULL channel - eep!);
return NULL;
}
-
rtn = xmalloc(numpix * 3);
for (i=0; inumpix; i++)
--- 1490,1495
***
*** 1693,1700
--- 1709,1722
{
for (x=0; xdest_w; x++)
{
+ #if AFW_FIXES
+ /* Avoid a 1-pixel border top-left */
+ if ((x=src_x) (xsrc_x+src_w)
+ (y=src_y) (ysrc_y+src_h))
+ #else
if ((xsrc_x) (xsrc_x+src_w)
(ysrc_y) (ysrc_y+src_h))
+ #endif
{
dest[dest_w * y + x] =
src[src_w * (y-src_y) + (x-src_x)];
***
*** 1726,1731
--- 1748,1758
gint32 iter;
fpos_t tmpfpos;
+ #if AFW_FIXES
+ gint32 mask_id = -1;/* ie not set */
+ int red_chan, grn_chan, blu_chan, alpha_chan, ichan;
+ #endif
+
IFDBG printf(--- %s -\n,name);
name_buf = g_strdup_printf( _(Loading %s:), name);
***
*** 1848,1853
--- 1875,1911
seek_to_and_unpack_pixeldata(fd, lnum, 1);
seek_to_and_unpack_pixeldata(fd, lnum, 2);
seek_to_and_unpack_pixeldata(fd, lnum, 3);
+ #if AFW_FIXES
+ /* Fix for unexpected layer data order for files from PS files
+created by PanoTools. Rather
+* than assuming an order, we find the actual order.
+*/
+
+ red_chan = grn_chan = blu_chan = alpha_chan = -1;
+
+ for(ichan=0; ichannumc; ichan++) {
+ switch(psd_image.layer[lnum].channel[ichan].type) {
+ case 0: red_chan = ichan; break;
+ case 1: grn_chan = ichan; break
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: Nick Lamb [EMAIL PROTECTED] writes: NB I am not blind and I don't write code in Hebrew I respect your extraordinary tolerance regarding this, so please respect that the people actually working on a project tend to make the decisions. Uh, that's pretty harsh if I read it right. Nick is a seasoned and consistant GIMP contributor. --Adam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: after some hours of torturing it with perl and some manual hacking, i got gimp running on current CVS glib/gtk+. ... (applying it means that if you want to hack or simply use gimp 1.3, you will need glib, pango, atk and gtk+ HEAD from CVS too). I few questions: * What are pango and atk, and why do we suddenly require them (if indeed we do)? * Are there compelling advantages to using CVS-GTK which outweigh the cons of forcing developers and users to upgrade? Is GTK 1.3 not backwardly compatible with the GTK 1.2 API? My concern is that with such a casual-user oriented application as GIMP we can easily lose users by the wayside with each additional stipulation. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? Ta, --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But one of the funny things with very pretty girls is that ... men think they won't have a chance with them, so they don't ask them out. I do ask. And... quite often, they come out with me. Probably out of curiosity, or something. -- Sir Clive Sinclair ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Adam D. Moss wrote: Is GTK 1.3 (or GTK 1.9, or 2.0, or whatever the GTK HEAD is!) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a stable version (which will be in not too distant future). I assumed nothing less. IMHO the pro's outweigh the con's by far, as it's simply not possible without grand hacks to write an internal object model and a nice generic GUI with Gtk 1.2. We had an adequately generic GUI and most users couldn't give a whit about the internal object model, but I can see an attraction to hackers. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? The changes made for 2.0 migration are much less of a structural change than what happens in two weeks of usual HEAD-reorganizing. Not a single file was moved and almost only the object stuff was touched. It was an honest and straightforward question, not a rhetorical one; what is involved? Are the changes largely syntactic, or deeper? What's a no-brainer BTW ? Something that does not require brain. =) After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's bleeding edge version? This is unstable development. No, I *really* don't see the logic there at all. That's bleeding for bleeding's sake. GTK took a life of its own millenia ago and their destinies are no longer entwined. But the deed is done. :) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2.1 crashes on indexed colour conversion
Nick Lamb wrote: On Wed, Jun 06, 2001 at 07:37:23PM +0200, Sven Neumann wrote: Argh, I knew the heavy usage of g_assert() in the convert code would bite us some day. But assuming the assertions aren't invalid we have found a bug that would otherwise be very hard to find? Yes, the assertions caught a real bug (indeed for what other reason would they be there?). However, the bug has been long-dead in my current tree (but possibly replaced with others, of course)! --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 i l1x0r u! 5luRp!Gronda, gronda ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
