Re: Value in histogram
On Thu, Feb 08, 2001 at 01:36:10PM +0100, Roel Schroeven wrote: The value in the gimp histogram is calculated as the maximum of the red, green and blue channels now. Wouldn't it be better to use the average of the three color channels? We discussed this when I was fixing the histogram for 1.2.x BRANCH (btw, did that fix go into 1.2.1, or did it just rot? Maybe I should look for myself) and I can't remember what the arguments were for leaving it as it is, but that's what we decided to do in 1.2 at least. Nick.
Re: Gimp 1.3 compile and link dependencies
On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote: The windoze version of gimpwidgefts can't include two symbols for different implementation of the same function. There is only one version of the dll in memory, even if loaded by another process. The code is shared across process boundaries while the data is not. Try making two copies of the DLLs with different filenames, and link plug-ins to one while gimp.exe links the other, that should fix it right? Nick.
Re: problem with gtk+ colorselector
On Sun, Feb 04, 2001 at 04:45:58AM +0100, Sven Neumann wrote: The colorselector has already undergone a major overhaul in the HEAD tree. The color previews as well as all sliders are now global to all color selector notebooks so all selectors should behave identically. Have a look at http://sven.gimp.org/files/color_selector_1_3.png for a screenshot. Yeah, but there's some odd bugs or features with it. Firstly when you're not using the "Gimp" selector (we should find better names) you can still see the radio-buttons which control it - they just don't react. Odd. Secondly the "GTK+" tab resizes oddly the first time you look at it, then it's fine, but too small the next time. If we can't get it working right we should write our own circle+bar selector instead of fudging it. What does the GTK+ selector bring to the party anyway? Nick.
Re: tiled view
On Tue, Jan 23, 2001 at 11:40:30AM +0100, Mirar wrote: Doing tiled images for textures used in 3d worlds, the best method I've found out isn't very good, it's the procedure of: 1) make an image the right size that looks tiled 2) tile it 2x2 2a) did it tile? finished! 3) fix the things that didn't tile 4) crop the center of it to the right size 5) repeat from 2 1. Draw first attempt at tile 2. Image-Transforms-Offset 2a. Hit Offset by x/2 y/2 etc. 3. Fiddle with any edges revealed by this Adding a special mode to Gimp seems like overkill to me, but hey - it's a popular request and all patches will be considered. Nick.
Using two mice
It seems as though it should be possible to use Gimp with two mice (or similar devices) to some advantage, using them to control different tools, using different settings. With AlwaysCore and the Xinput extended devices disabled (probably a common setup) you get what you'd expect - more physical devices sharing the same physical pointer and Gimp tools. Of course, this isn't really using two mice effectively. However with the extended device enabled, Gimp's behaviour (or is this GTK+ / XFree behaviour?) breaks down. Gimp can no longer properly detect the core cursor (you can't draw with it) and the additional mouse seems to always generate mouse down events at the origin, making it quite unusable. I started investigating this before, but didn't have a permanent setup where I could reproduce it. Now I do, so if anyone has any pointers or advice I'd appreciate it. Nick.
Re: problems with windows gimp
On Thu, Jan 18, 2001 at 12:42:23AM +0200, Tor Lillqvist wrote: (No, I don't know why duplicate PDB procedures cause strange errors and not just warnings. Anyway, GIMP seems to handle this situation better in the current gimp-1-2.) It's a long standing bug in Gimp. I would really like to change the name of one of my plug-ins, but this bug prevents that (it would crash Gimp) It's possible, but unlikely that it's actually fixed in 1.2.0, but generally people poke inside the PDB, throw up, tweak something until the crash that annoyed them stops and go home. I don't blame them, and I wouldn't volunteer to re-write its hairy logic, so I've stopped whining about it. (unless this counts :) ) Nick.
Histogram patch
A potential patch for the histogram tool in 1.2.x (assuming we do plan to release e.g. file handle leak fix as a 1.2.1) has been uploaded as gimp-ruth-010109-0.patch.gz This patch addresses several problems I found in the 1.2.0 release tool, Sven and I discussed some of this already, but the following are covered: 1. Don't say "Blue" when you're displaying "Value" etc. 2. Give accurate stats FOR THE SELECTED CHANNEL, not for Value 3. Try to survive stuff changing underneath us 4. # of pixels is a (large) integer = %1.f not %8.1f in display I may have forgotten some minor things. 1.3.x could get a version of this patch (I'll do the work directly in CVS some time) but it would be better if more serious architectural work was accepted IMHO. Please look at this for 1.2.1, yosh seems enthusiastic about this weekend and I'd like this to go in. If anyone finds any problems obviously it will have to wait for 1.2.2 or so, but please bang on it now! Nick.
Re: Bug#35315: Right.
On Fri, Dec 22, 2000 at 12:26:54PM -0600, Federico Mena Quintero wrote: "Adam D. Moss" [EMAIL PROTECTED] writes: Right, this is a bad-data problem, and "WON'T FIX". The source XCF image contains pixels with an index of 34 (the screen on the computer icon) but only declares a palette of 20 colours. Why? You tell me! Had the original image been anywhere near a really old version of GIMP? There was a palette bug from GIMP 0.53.0 - 0.99.low-x which could cause such a problem. The GIMP should not crash on a corrupt image file. Ever. The GIMP should not crash, ever. Period. Gimp is in userspace and running on hardware, so the latter is a bit harsh IMHO. Let's say rather "Gimp should not cause itself to crash" Hmmm. Use a fixed 256 RGB triples in the palette, then change existing code to only overwrite it, never re-allocate. Out-of-bounds index values will not have a defined color, but they won't crash. The "size" of the palette can still be an internal variable, it just won't reflect the _literal_ size of the palette array. This is safe and easy. More "thorough" fixes can be left for another version of Gimp I think. Nick.
divide by 255
General purpose compose operations usually include a division by 255 of a number in the range 0 ... 65025. While fixing up Mozilla's alpha compositor I disturbed a sleeping hacker who has provided a (tested and working) macro which computes this operation much more quickly than any other solution tested, including GCC -On speed-ups using similar but different tricks. Of course, GCC cannot use this FAST_DIVIDE_BY_255 because it is safe only for 0 ... 65025, but I think it might be useful to Gimp, both in the core (which I presume has several alpha compositors) and in plug-ins, where alpha composition is also a popular operation. So, does Gimp already have something like this in core? Or should we consider borrowing this macro from wherever it originated and using it throughout Gimp (after 1.2, naturally) ? Nick.
Re: suggestion for gimp 1.3 and later
On Wed, Dec 13, 2000 at 03:29:41AM +0100, Marc Lehmann wrote: I think the best way would be to make any gtk label/text widget be selectable. I don't know why this has not been done so far, but it might be an interesting experiment. Yes, I've often thought this. And everyone knows that if Marc and I agree about something it must be right (?) or at least it's in no-one's interest to disagree... How do we put something on the GTK+ "TODO" list? Anyone from GTK+ still hang out on gimp-devel, or are the two worlds quite, quite separate these days? Nick.
sliding off-topic Re: [Sven Neumann] Assistance with GUI design
On Mon, Dec 11, 2000 at 10:37:11PM +0900, [EMAIL PROTECTED] wrote: On the side note, one thing that could use serious serious improvement is the preferences dialog. I think, the "Tree" structure of organizing preferences is truly confusing. Reserve tree structures for directory lists and things like that. Someone using the Gimp for the first time would expect preferences dialog to look something similar to a tabbed notebook where each setting is grouped by section, which occupies one tab They would expect that only if they've used Microsoft Windows 95 through to somewhere in the late 1990s. The mechanism used in Gimp is most widely considered to be far superior for potentially complex preferences lists. Tabbed notebooks are rarely the Right Thing unless you have only three or four clearly differentiated item groups. We've got lots more. It's also funny how people add 12 more tabs, and don't consider a re-design -- look at Visual Studio (at least circa 1998) for such nonsense. If you're claiming to be teaching _us_ about GUI design you should know this stuff. This is rapidly getting off topic, and concentrating on your specific wants, rather than general usability everyone will agree on (for example, ESC = Cancel seems pretty reasonable to me) Nick.
Re: [PATCH] improving on i18n
On Tue, Dec 05, 2000 at 07:39:11PM +0100, Marc Lehmann wrote: This patch _fixes_ GIMP translations. Currently it's _impossible_ to And givne that a large amount of similar fixes went into the gimp not too long ago this patch really should be considered. Those fixes made Gimp have more bugs. No more patches like that thanks. Nick.
Re: layer_get_offests(layerId, x, y);
On Thu, Nov 30, 2000 at 01:13:33AM -0500, Maneesh Yadav wrote: No one knows how to get the offsets for a layer from libgimp do they? I see a set_offsets but no get... Shouldn't we put an accessor method in there...I would add it myself, but I don't get that pdb meta code... gimp_drawable_offsets(id, x, y) ?? Nick.
Re: Certain jpg/tiff files cannot be loaded correctly
On Fri, Nov 24, 2000 at 08:35:10AM +0100, Martin Weber wrote: Certain jpg/tiff files cannot be loaded correctly. http://homepages.go.com/~martweb/gimp.zip Sorry that I mail this bug, but the bug report page currently doesn't seem to work. Go.com seem to be a rather Mickey Mouse operation if you'll pardon the pun. When their web site is up I'll check out the contents of that ZIP. If this is a re-report of the problems already described in the Gimp bugtracker I will try to answer them individually as I can. Nick.
TODO for 1.2 release
humour Right, one of the formal things Linus' little toy project does which allows him to ship only a year or two late is to have a list of stuff that needs doing before release. Of course, none of that stuff gets done, but you can document it and move on. Another toy project, named after that monster which was really a guy in a rubber suit, uses a process where they first list "showstopper" bugs, and then slowly whittle them away (with politics, not coding, silly me) and then they all shout "Zarro Boogs". That project is even later than Xunil 4.2 Now, I bet a lot of money that Gimp 1.2 wouldn't be released in 2000 To make me lose, and put a huge grin on Marc's face, we must collect a list of things to do before 1.2.0 can be released. I have never seen a formal list (perhaps Yosh is hiding it) then for extra points we need to fix all of the bugs in order, spelling "BONUS" /humour Enough hilarity. If you know of something which must be done before 1.2.0 please follow on to this mail. If you know of a reason why we should unfreeze Gimp instead, feel free to let loose. 1. VAGUE: Documentation should be "good" (definition anyone?) 2. Critical/ Severe bug reports should be fixed or marked down (bug #s?) 3. VAGUE: Gimp should build out-of-box on lots of systems 99. Find and #ifdef any debug scribble to console 100. Check package files, READMEs, etc. for correctness Of course I'm sure we'd release eventually anyway, but I think a lot of talent lies idle not knowing what needs doing. So what DOES need doing people? Nick.
Re: gradients and pre-multiplied alpha
On Mon, Sep 18, 2000 at 05:24:20PM -0400, Garry R. Osgood wrote: Nick Lamb wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. Perhaps that wasn't your intention, but in any case... Perhaps a later Gimp will know how to consume premultiplied alpha (you'll have to throw some switches) the 1.x Gimps of the next two years or so won't know how to do it. This is exactly what I was worried about -- Gimp already DOES convert premultiplied alpha from the one source I'm sure uses it, TIFF. It is trivial (though perhaps sometimes costly) to convert TIFFs during loading so we (almost) always do. Support _internally_ in Gimp (which you're proposing for 2.0) is orthogonal to loading external data correctly. If someone finds me an MS internal document dictating that BMP uses pre-multiplied alpha I'll add the conversion functions in days -- to the BMP loader. For undisciplined formats a load-time option is not a sensible way to go, we'll probably have to provide a plug-in which does the conversion and include help that explains what it's for / how to use it to handle either case, some heuristics in the plug-in can help. I'm not willing to write such a plug-in not only because I'm already too busy, but because I think the film/ rendering communities brought this on themselves. I've seen too much evidence that says they don't care about standards, or interoperability. Nick.
Re: gradients and pre-multiplied alpha
On Sun, Sep 17, 2000 at 02:12:22PM -0700, Kevin Turner wrote: Then on Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. Perhaps that wasn't your intention, but in any case... Well, yes, that was my intention, actually. The basis for my thinking comes from something Raph sent me when I asked when it is and is not desirable for plug-ins to work in premultiplied alpha space. Kevin, that's a reply to Garry that you're quoting, in a message about file level pre-multiplied alpha, and possible architectural changes in Gimp 2.0. Not particularly relevant to your present concern. Nick.
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 03:38:29PM +0200, Marc Lehmann wrote: Ah! ;) Still gimp would not support uncommon errors by giving the user more freedom. Allowing users to needlessly create bizarre image files that will then cause them trouble in other packages is just _asking_ for trouble. This is windows thinking a lot. Not implementing something because it is costing a lot of time would be understandable, but not offering features because the user might be too dumb is never a good idea (IMHO). Fine, I'll put the "PC vs Mac" option back into Gimp's TIFF filter and mail you all the confused whining from users. :) working image app... I want to have a genuine REASON to add any options like this before I risk confusing users further. Well, we could also always write png's with compression=9, for example, as the resulting image is the same in all cases ;) What an appropriate choice. Check out PS 4.0 and see what the equivalent dialog says there. There sure are a lot more options in the compression section. An Adobe engineer probably spent a few hours on that dialog. Unfortunately what they come down to is that you can choose to make PS4 do a lot worse than Gimp, or nearly as good. Since Gimp is already as good as Gimp, having options to make it worse seems pointless, no? Photoshop 5.0 abandons the unnecessary extra options AFAIK. Still, your point is taken, some behaviour that's not directly visible to the user needs to be reflected in the options. I agree, but it's not universally true that more options is good. Still, a good reason may be forthcoming and if it is I'll happily integrate this patch or one like it. A very good reason _not_ to is that it might be pretty unimportant, so coding these features might be a waste of time... Some options do not appear to buy anything except additional code complexity. I differ with Marc here, I don't mind coding it, but I do object to untested code paths. I'm not going to write a test suite to check the umpty-zillion possible alternatives if we try all the options. So even though this TGA patch is "free", I still don't expect to apply it without a good reason. Nick.
Re: TGA plug-in patch
On Sat, Sep 09, 2000 at 07:45:17PM -0400, Brandon wrote: Below is a patch to add support for saving TGA files upside down. Although it sounds strange to do, it is a supported feature of the file format and OpenGL expects its textures to be upside down. Support already exists for reading such files but it was impossible to save them. The spirit is appreciated, but (a) The TGA filter is being reworked at present and may (in my tree) no longer resemble the original enough to apply the patch and (b) I don't think Gimp should offer too many features that work around uncommon errors in other systems at a cost of confusing users... Did you want this to make a specific application go faster? Or because of a bug in someone else's TGA loader that means you can't load images the right way up? I know that OpenGL's internal store doesn't resemble a TGA very much, but I'd argue that the vertical orientation is the least of your troubles. Nick.
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 01:17:25AM +0200, Marc Lehmann wrote: On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb [EMAIL PROTECTED] wrote: strange to do, it is a supported feature of the file format and OpenGL apply the patch and (b) I don't think Gimp should offer too many features that work around uncommon errors in other systems at a cost of If the abovce is true and the file format indeed supports this (in the spec, if any), then this is not an "error" but "valid but uncommon". Ah no, writing images to TGA with "flip-vertical" flag set is both valid and common, almost universal in fact. But not being willing or able to load top-down images like Gimps would be an uncommon error, I've never yet seen anything that can't cope. The spec, such as it is says to look at the flag and obey it -- no confusion there. The patch is for _writing_ TGA files, and like TIFF there's plenty of wacky things you legally _can_ write to a TGA file, I am offering the opinion that we should generally shield users from the dozens of valid yet unimportant TGA options, and set them for our convenience, as we do with TIFF. I don't think it makes sense to have a dialog like this: [x] Top-left start [ ] Top-right start [ ] Bottom-right start [ ] ... [x] R-G-B [ ] B-R-G [ ] R-B-G [ ] B-R-A-G [ ] Mysteriously allocate but don't use colourmap [ ] Make alternate scanlines inverted for some reason [ ] Write four channels, but then only use three Given that the image will look the same in Gimp either way, have (almost) the same file size, load and look the same in any other working image app... I want to have a genuine REASON to add any options like this before I risk confusing users further. Still, a good reason may be forthcoming and if it is I'll happily integrate this patch or one like it. Nick.
Re: Code cleanup
On Thu, Aug 31, 2000 at 03:48:37PM -0400, Federico Mena Quintero wrote: If p is a null pointer then "free (p)" may (and should!) crash. You are incorrect here. sigh You are completely wrong, see KR's treatment of ANSI C Standard Library, Section B6 void free(void *p) free deallocates the space pointed to by p; it does nothing if p is NULL. p must be a pointer to space previously allocated by calloc, malloc, or realloc. Find me a system that doesn't pretend to implement ANSI C, ISO C or POSIX and I'll show you a system that won't build Gimp. Nick.
Re: UTF-8 vs. current locale charset mess...
On Thu, Aug 10, 2000 at 09:24:42PM +0300, Tor Lillqvist wrote: GTK+ 1.3 (and 2.0) uses UTF-8 internally, while the file system related C runtime calls like stat(), open() and opendir() uses a "current codepage" (the Windows term, on Unix you want to use whatever encoding/charset the user's locale uses). For Linux at least the filesystems speak UTF8. I don't see a problem (well, OK as usual Windows doesn't work, but Tor you're used to hacking around that without needing to consult us) how about *BSD, Solaris etc? Nick.
Re: Docbook (Help files)
DocBook sounds fine to me presuming that the tools are validating (ie users who just type nonsense into their text editor will be rewarded with a screenful of errors) and so we get some decent structured documents, not the hacked-together nonsense you usually get when people write HTML. I don't know DocBook, but presuming all I need is some web tutorial and a bunch of RPMs I am willing to learn it and submit documentation for all file formats maintained by me or unmaintained + a bonus section for all the Gimp newsgroup users who ask.. "There are so many file formats, which should I use?" ... to which the answer is of course always use PNG :) Writing this stuff will take some time, how much time do we have? Nick.
Colour Picker -forbidden- ?
What is the "forbidden" colour picker mouse cursor for? By this I mean the cursor where the picker is joined by a crossed-out circle, the universal symbol for prohibition. There doesn't seem to be any situation in which the picker doesn't work (perhaps you could argue that its not working when the read-outs say N/A but then why have such a reading?) If there is a good reason for this cursor, is it OK to change it so that the picker remains the "hotspot" even when the forbidden icon appears, at the moment the behaviour is (try it) disconcerting. Nick.
Re: 32-bit images in gimp - Alpha handling wrong?
On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson wrote: Can you justify that (all images should be pre-multiplied)? Or is this just your unsupported opinion? Well, that was attempted editorial humour to some extent, but it's also the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff. I'd hardly call it unsupported. Ah, but as others have said, these are people working in a totally different area, and at least Tom Duff is most famous for a speed-up hack easily as ugly as pre-multiplied alpha (Duff's device). Gimp has no support for pre-multiplied alpha, Well, there's my answer. No support. ... and no need for it. With the exception of (IMHO useless) out-of-gamut RGB values, each is equally expressive, plug-ins and tools are free to convert to pre-mult if appropriate but the core uses ordinary RGBA. A hack? I thought it was a mathematically elegant representation of an image layer, which is why I see a reason to support it. I'm trying to find out if anyone else agrees, or if I'm missing something that's already there, or there's something specific about Gimp and the way it's used that makes it unnecessary or not useful. Let's rather say "Not a priority" rather than "not useful", but I do not expect pre-mult alpha to be exposed to the user (as opposed to used in plug-ins or for speed-up hacks) in Gimp any time soon. And even if you consider it a hack, don't people use pre-mult alpha? Am I the first one to notice this and complain? Notice? I don't know. Complain, yes. You'll see why in a minute I think. I have no love at all for the TIFF format. (I was present at the birth of a similarly over-extended format. I should have complained more loudly.) But that's irrelevant - or at least orthogonal - to the use of pre-mult alpha. I'm not aware of any other common interchange format which supports the pre-multiplied alpha representation in storage. If we didn't have to load or save it, pre-mult would not be a problem for Gimp. I've placed a page at: www.ozemail.com.au/~hodsond/alpha.html Images are just inline PNGs, just grab 'em as they appear; but it's not really necessary, if you say that Gimp doesn't handle pre-mult alpha, then that explains the results. sigh No the program which produced your example PNG image is broken. The PNG specification requires straight RGBA, pre-multiplied alpha is prohibited and this is spelled out several times. Gimp can't hope to interpret an invalid image correctly. Please identify the program (name, version, vendor etc.) and I will pass the details on to png-implement. Hopefully we can arrange for them to issue an urgent update to their users and if necessary get publicity so that everyone knows not to use this broken program. Do users have problems with pre- and non-mult alpha? Since they are equivalent I'd guess users remain comfortably unaware. Nick.
Re: License of the XCF loader in Imlib2
On Sat, Jun 24, 2000 at 01:14:02PM +0200, Sven Neumann wrote: yesterday night on #gimp someone pointed out that an XCF loader appeared in the Imlib2 CVS tree. I was curious, checked out the source and had a closer look. It "appeared" courtesy of someone identified only as "cK", hopefully those working on Imlib2 will know that handle (though who knows, it doesn't look like an expertly managed project to me, maybe anyone can get CVS write privs) and remove their write privs. I await Raster's misspelled commentary on this problem, hopefully accompanied by the removal of the offending code from CVS. Nick.
Greyscale crash
Does anyone recognise this? I'm fairly sure it's a brand new "feature" perhaps from recent patches to app/ ? If no-one recognises this I will file it through the normal channels, but since it looks like a fresh regression it seemed easiest to ask first. 1. Create new _greyscale_ image 2. Use a nice colorful pepper brush (you know, the demo color brush) 3. Scribble all over the image, off the edges... [This being a memory scribble bug it might not work first time] 4. Bang. (relevant section of stacktrace -basically its a memory scribble) #4 0x4028ec68 in __restore () #5 0x402c9fba in __libc_free (mem=0x873dd78) at malloc.c:3023 #6 0x4018439d in g_free (mem=0x873dd78) at gmem.c:411 #7 0x814a554 in tile_alloc () #8 0x814a6d0 in tile_detach () #9 0x814aaba in tile_manager_destroy () #10 0x81567d2 in undo_push_image_mod () #11 0x8155a3f in transform_tool_show_grid () #12 0x8155ab0 in transform_tool_show_grid () #13 0x8155b56 in transform_tool_show_grid () #14 0x8156213 in undo_push_group_start () #15 0x81134b7 in paint_core_finish () #16 0x8112477 in paint_core_button_release () #17 0x80aaa57 in gdisplay_canvas_events () Nick.
Re: SWF format...
On Tue, May 23, 2000 at 09:54:34AM -0500, Jon Winters wrote: I'm taking a Macromedia Flash class this week and one of the things I'll want to do afterward is find a way to make flash stuff on Linux. So far I have not been able to find any tools. I'm not sure there are any content creation tools for SWF on Linux. Six months ago I was a bit worried about that... and some other stuff here: http://www.ep.cs.nott.ac.uk/projects/SVG/flash2svg/swfformat.html Having just come back from WWW9 I'm pretty enthusiastic about SVG right now. I can't see the point in continuing to use Flash once there are vendors clambering over each other to produce the best SVG plug-in and (since it's free) it will be built-in on Mozilla eventually. If there's no Flash creation tools at all for Linux, and there are already some steps towards SVG (though not AFAIK animation) it seems like it would be better to just create SVG from go -- but that's maybe not what you want to hear when you're about to do a Flash course. Nick.
Re: List rules (Re: Negligencias medicas)
Guillermo S. Romero / Familia Romero wrote: Cos it is. I though that only suscribed guys could post. If anybody can post, it should be fixed now. I think that is most of readers would like. I like the idea of semi-moderated (non subscribers are moderated) lists but I don't have time to volunteer, so if no-one else likes that idea or XCF can't provide it, put me down for "subscribers only" too. Nick.
Re: EPIPE
On Wed, May 10, 2000 at 07:15:57PM -0500, Tim Mooney wrote: Finding a processor/OS combo where sizeof(pointer) != sizeof(int) is pretty easy, however. How does this change your thinking? Wouldn't atomicity guarantees be a processor feature, and hence tied to word size (probably pointer width if you are taking full advantage of your CPU) rather than whatever CC might think sizeof(int) is ? If I've completely forgotten my architecture course, don't hesitate to write me a long rant, off-list of course... Nick.
Re: EPIPE
On Mon, May 08, 2000 at 02:16:06PM +0100, Austin Donnelly wrote: cleaned up on their unexpected termination at some earlier stage. The whole point of plugins being separate processes is that a plugin should be unable to cause the main gimp app to crash: if they can then this is a fairly critical bug that should be fixed. s/unable to cause/able to prevent/ We don't do nearly enough checks to prevent plug-ins from killing Gimp if they're badly written. A future version could, in theory, but it seems better to assume that plug-in authors have good intentions. However, minor accidents causing a crash in a plug-in should NOT kill Gimp as you said. This is our strength over most PC apps when it comes to integrating 3rd party plug-ins. This has been annoying me, but I presumed that whoever's been tinkering with the signals knew what they were doing...? Nick.
Re: Tiff changes?
On Fri, May 05, 2000 at 06:54:51PM -0600, Michael J. Hammel wrote: /usr2/graphics/gimp/gimp-1.1/gimp-1.1.21/plug-ins/common/tiff.c:1237: undefined reference to `TIFFFindCODEC' Have the libtiff requirements changed recently? 1.1.19 built fine. Yes, there has been a change to my use of libtiff, on the discovery that recent versions have removed support for LZW. Can you tell me which version of libtiff you have, so I can guage what to do next? The problem is that we can't trivially detect at run-time which CODECs are really present, TIFFFindCODEC was better than nothing, but if it causes problems I'll remove it, because it wasn't really The Right Thing (TM) in my opinion anyway. At worst, users will receive a strange, but intelligible message from the library telling them to choose a different CODEC, I think. NB None of this affects loading images, and you should NOT be creating more TIFFs, so hopefully right thinking people are quite unaffected apart from this build problem. Nick.
Re: pnm plugin
On Wed, May 03, 2000 at 02:27:09AM +0200, Marc Lehmann wrote: ppm saving works. But I am unable to create pgm or pbm files with the gimp (pbm is known for some time, but gimp definitely writes a ppm file for greyscale images). Nope, my routine Export tests for Gimp show PPM and PGMs being created as appropriate. You're right that Gimp won't generate PBMs, but I don't think it's an ideal tool for that job anyway. IMHO pnm.c would ideally notice if you said "foo.pgm" for an RGB image, and ask Export to recommend greyscale... but that's a lot of work for a very small gain. So I don't prioritize doing that. However, saving a grayscale image resulted into a ppm file (with a pgm suffix). Doesn't here. If you can't figure out what's wrong, try sending me (private mail is fine) an XCF which you think should produce a PGM, and I'll see what it does here. I think the pnm plug-in should be able to save greyscale as pgm, I don't care for pbm files. Does in my last check out of Gimp, probably a few days old but hardly out-of-date in PNM plug-in terms. Nick.
Re: BMP
On Fri, Apr 28, 2000 at 08:53:08AM +0200, DrMartin.Weber wrote: The BMP plugin cannot read OS/2 2.0 bitmaps (number 64). It crashes! Also it displays false colors with indexed OS/2 1.3 bitmaps (number 12). Qt can read all this pictures. So you can have a look at that code. Alexander, how closely are you maintaining this code? Would you prefer that you be contacted for these bugs and send patches back to the list or ftp.gimp.org, or should I/ someone fix them in CVS and not worry about your tree? Nick.
Re: BUG: gdyntext is dead
On Tue, Apr 18, 2000 at 07:55:41PM +0200, Uwe Koloska wrote: Hey, you are right! By starting gimp with LC_ALL=C gimp-1.1 or more exact LC_NUMERIC=C gimp-1.1 gdyntext works as expected. Maybe this is the same sort of error acrobat reader 4.05 has to fight with (cannot open most embedded font when run with locale other than "C"). I have just confirmed, and fixed (well sent off a patch) a bug in Xsane, an external Gimp plug-in, which has this same problem. It is ESSENTIAL when communicating across the Gimp wire, that a plug-in operates in LC_NUMERIC == "C", I do not think it is wise to change this assumption during the last leg to 1.2.0 and almost ALL existing plug-ins accept this behaviour by (a) Using the normal gimp_main() stuff provided by gimp.h, which magically calls setlocale(LC_NUMERIC, "C"); for itself anyway. and (b) Not manually fiddling with their locale settings If GDyntext doesn't use gimp_main() stuff, or does fiddle with its own locale settings (either generally or LC_NUMERIC in particular) then it needs to be altered to provide working i18n, I suggest removing any private setlocale() stuff or otherwise altering GDyntext not to alter the LC_NUMERIC settings from their defaults. For Gimp 1.3 we might re-think the wire protocol to avoid this mess? Nick.
Re: Feature Request: Layer Export
On Wed, Apr 12, 2000 at 11:16:29PM +0200, Mattias Engdegård wrote: But there seems to be no way to do it from a script. I had to resort to duplicating the entire image and delete the unwanted layers, which seemed slightly wasteful. I don't understand, scripts are supposed to ALWAYS work this way, and you say that there's no way to do it? If you save a layer from a script it should just... save that layer, unless the file format is capable of multiple layers, then you'll get all of them I think. Nick.
Re: Feature Request: Layer Export
On Thu, Apr 13, 2000 at 03:40:49AM +0200, Mattias Engdegård wrote: I won't fix that right away (maybe later, if I have time). No need, like I said, I only recently checked in the change -- days ago in fact, after 1.1.19 was released. Just wait for 1.1.20, or get the current CVS Gimp, or if you really need INDEXED+A PNG right away, contact me and I can mail it to you. Sorry, I didn't mean to whine (I was determined to fix it myself but all sorts of things cropped up). XPM is by definition an indexed image format, though it allows for colormaps large enough for saving RGB images. Doh, I was thinking from the POV of the Gimp loader (it's always loaded as RGB regardless of how it was saved), not from the POV of the Save plug-ins. "saves files in the xpm file format (if you're on a 16 bit display...)", However, a cursory glance revealed nothing supporting this warning. Perhaps it was true in an earlier revision? Then we should change it. Some Gimp plug-ins are derived from various unrelated sources, like the netpbm filters, scraggy bits of code hanging around in CS dumpsters and the like. This probably puts them on shaky legal ground and definitely means they have some weird comments in. XPM could well be one of them. Nick.
Re: Export behaviour for fully transparent backgrounds
On Tue, Apr 11, 2000 at 02:58:38AM +0200, Sven Neumann wrote: Hi, On Mon, Apr 10, 2000 at 05:20:03PM -0700, Kevin Turner wrote: Goal: Make an image with a transparent background for your web-page, clip-art, etc. Issue: PNG file size is bloated by losslessly saving "invisible" data. IMHO, this should be handled completely inside the PNG plug-in. Why? Nick.
Re: JPEG correction (was Re: Gimp Wishes)
On Thu, Apr 06, 2000 at 01:20:50AM +0200, Marc Lehmann wrote: As such, why save an image if you didn't change it? There is no good reason why a PROFESSIONAL graphic designer should be doing it, but lots of us are mere amateurs :) JPEG works one tile at a time. The same behaviour I observe in one image will be true on average for individual tiles, so if I alter only one half of an image (or only touch up one word) and save with the same quality as the original, the untouched tiles will be mostly unharmed. A classic example (which I won't distribute because it's obviously illegal) is a re-touched Matrix JPEG from the movie site, altered to replace Keanu with Windy Miller from the old UK television shows. By fiddling carefully with JPEG settings we can get the "right" setting to make the hacked version look like the original, without additional artifacts in the unaltered portions of the image. Looks great! Given that the problem is unsolvable in theory and almost impossible even to approximate in practise, I believt hat such a automatic detection scheme will fool people into thinking that saving at the same quality wouldn't destroy their image. I don't want that, people shouldn't be using JPEG for works in progress or as a common format moving between packages or ANYTHING like that, and I agree that we don't want to give them false expectations. The problem here is that different encoders have different notions of "quality settings", and in most cases you can only approximate the quality setting of another encoder (quality settings are just a quick way to describe a 8x8 matrix, and setting up that matrix is very much decoder-dependent) I think Marc and I agree on the realities of this situation, I just wanted to make clear that "lossy" re-saving doesn't necessarily cause any damage to the image. But that's NO REASON to be doing it, and no reason for Gimp to encourage it either. That was a public service announcement from the lossy compression posse Nick.
Improved Export behaviour for non-alpha backgrounds
I'd like to propose a change to Export behaviour, or possibly to the Merge Visible Layers feature, depending on what other developers think about the following: 1. Create new image with pink background 2. Add layer, draw picture of bird 3. Save as PNG = Result is an RGBA PNG, 121Kb 4. Flatten, Save again = Result is RGB PNG, 105Kb The trouble is that "Merge Visible Layers", which is currently recommended for any multi-layer image saved to a transparency capable image file format, adds an alpha layer to resulting layer, even if the lowest visible layer was a non-transparent background. I don't think altering Merge Visible Layers is the right thing to do, there would doubtless be a number of surprises waiting if I did it. Instead, I propose to change Export to recommend "Flatten" when it notices that the bottom layer has no alpha channel AND is visible, when it would current recommend "Merge Visible". This will improve compression ratios for PNG, TGA etc., as well as increasing available colors for GIF and colormapped PNG. Comments? Objections? Nick.
Re: Gimp Wishes (i18n and jpeg)
On Wed, Apr 05, 2000 at 04:40:37PM +1000, Ian Boreham wrote: From my understanding of JPEG (which is not expert), I would have thought that although there might be a small loss of quality on subsequent cycles, due to rounding-type errors, there would not be anywhere near the same as the initial loss due to discarding high-order, low-coefficient data. Discarding this data is effectively setting the coefficients to zero, so you would be roughly discarding zero on subsequent cycles. You are correct, but only when the same implementation is being used. It is quite possible that rounding errors will be introduced by varying the algorithm, so although this will often work IN PRACTICE, it is not something to be relied upon. Has anyone tried cycling and differencing to see the effect? Yes. Marc is right only in principle, not in practice. In tests on real photo data (which is the only thing you should be shoving through a JPEG codec anyway) I found that ~1% of tiles were damaged during the second cycle, and much fewer if any were changed by subsequent cycles. This is testing with RH 6.2's libjpeg package, Gimp defaults, 75% quality. I suspect that choosing a non-integer implementation (which might be faster on modern Intel hardware) would increase the damage from subsequent cycles, but I've never tested that. For my purposes it is enough that guessing the Q factor is a win, though not one we can easily automate. I have said all this before, is there a problem with the list? Or is Marc ignoring everything I say? Nick.
Re: Gimp Wishes (i18n and jpeg)
On Wed, Apr 05, 2000 at 12:38:45PM +0100, Nick Lamb wrote: I suspect that choosing a non-integer implementation (which might be faster on modern Intel hardware) would increase the damage from subsequent cycles, but I've never tested that. Have now, it makes no difference, so that's another factor eliminated. In fact, the integer code seems to produce the same image data as the float code, unless Gimp's JPEG UI doesn't work how I think it does. Nick.
English translations (was Re: Gimp Wishes)
On Mon, Apr 03, 2000 at 02:53:42PM -, Karl Heinz Kremer wrote: Why should English be treated differently than any other language? Let's just add an English catalog to the default installation and the user will not see any difference. There is already a catalog (en_GB) for British users of English who prefer to keep the OED spellings, rather than surrender to the alternate (but more common) American US spellings. I don't think any of us take it seriously (I often don't remember to set up i18n for ages after building a new system) because we've come to accept that something very *like* English will eventually be written by everyone, no matter how they spell colour, or what they call petrol and nappies. (*) Anyway, expecting everyone to support translation catalogs just so that you can hack around bizarre grammatical features in some languages is a bit much. Instead try re-writing the code if you can, so that it uses separate phrases in each case. (*) Even in Japan, convergence is happening, although since it's in a foreign alphabet that's not as helpful as it might be. Nick.
Re: User installation
On Sat, Apr 01, 2000 at 02:58:30AM -0800, Manish Singh wrote: Automake's dep tracking doesn't get 100% of cases. The datadir moved into a versioned directory to facilitate version coexistance. It's controlled by a -D on the compile line, so make doesn't really see it. make distclean [doesn't/ didn't for me] work, nor did clobbering everything in sight, but a fresh checkout worked finally. YMMV. BTW in case there's any doubt, I do *like* the new installer, whatever the color scheme might say about us, I just want a stable Gimp soon. Nick.
User installation
* Is the end-user installation stuff broken, or is it just me? On my system, cleaning out all old Gimp installs, installing latest CVS and then trying to install Gimp as a new user (ie to create .gimp-1.1 and all the rest) does not work. This seems to result from the changes to the system data directory... the error is approximately... /usr/local/share/gimp/user_install [or something] does not exist. FLAME The feature freeze has also thawed again. I can't tell if the new trouble I'm seeing is caused by changes to the installer in /app/ but I shouldn't have to, because IT SHOULD NOT BE BEING REPLACED DURING THE FREEZE. /FLAME I apologise for shouting, but AFAICT again all the existing bugs or misfeatures of the old dialog are retained, but now we have new bugs and a prettier interface, pardon me if I'm not impressed, but right now I can't even install Gimp :( Nick. -- Will revert features for food, Too busy to be angry
Re: Suggestion: disabling Perl-Fu installation
FWIW I agree with Raphael, installing "scripts" which actually just blow up when run is pointless, if it can't at least manage to register itself with Gimp's PDB we shouldn't install it. Similarly, even if they did have "sensible defaults" the GUI scripts are not functional enough to be installed by default without Gtk.pm, last time I saw them they mostly defaulted to "do nothing" or only slightly better "do something visible but not very useful". Nick.
Re: the .po filename domain
On Mon, Feb 21, 2000 at 01:37:39PM +0100, Marc Lehmann wrote: I have a question: what standard do the po-filenames follow? [Sleepy misunderstanding deleted] Just in case anyone else is as tired as Marc was when he wrote that, we're using the same convention as everyone else in gettext-land, basically ISO 639 (ISO-639-2?) with necessary extensions to provide for the variants e.g. en_GB is a British variant of en, and if it existed fr_US would be the kind of French spoken in the USA. Most of the alternatives are silly (three letter ISO 639 has some things in it's favour, but I don't think we need Ancient Egyptian or C11 Dutch variants for Gimp) I suppose we should be thankful that at least no-one is checking in code when they're that tired! Nick.
mkbrush.scm
While scripts are in the air, should we remove mkbrush.scm before 1.2? This script takes a bunch of parameters and makes a new brush, almost exactly like the "New" or "Edit" features of the brush dialog, but it's a Script-Fu. Do we need it for anything? Otherwise we should remove it to reduce end-user confusion I think. (Presumably this script inspired the current app unctionality, but isn't somehow called by it) Nick.
Re: Move help menu item to last-on-left not first-on-right?
On Thu, Feb 10, 2000 at 04:47:48AM +0100, Marc Lehmann wrote: a) what does HCI mean? ;) Someone already answered this. To see bad examples, either look at http://www.iarchitect.com/mshame.htm or look in a good bookstore. b) I always see programs do it the way gimp does it, so there must be something about it They give the same reason you do "Uh, everyone else does it", it seems to originate on Windows, but maybe it's the Mac's fault? The only justification I can think of is "Users have good spatial awareness and can always find the top-left of a window". c) you gave _no_ reason why? Ah, that wasn't clear from my diagrams? GTK+ draws space either side of a menu item, so the Help menu can cover over Xtns, making it useless and forcing me to have an otherwise unnecessarily wide toolbox. If the Help menu was in the same SET of menu items as File, Xtns (ie on the left) it would never overwrite them, and therefore use less space. Also if we're going to have casualties from manually shortened toolboxes, Help is much less useful than Xtns, because its key features are duplicated elsewhere. Hmm... I should have written that before. they are there. Comparison with other image editing apps (especially on Unix/Linux) is appreciated, I think that the type of application should not influence the place where the help button menu is placed. Oh, I see. Good point. It just seemed "better" to look at similar apps rather than e.g. Hog Racing 2000 or MS Word. So... I am not against this change, but I also see no reason to do it, especially since that makes gimp different to other apps, and I think there should be a very good reason for this. Well, for me it is helpful (see above) and it looks like all the other apps I run, with the exception of XChat. However I'm aware that most of gimp-devel are using a different set of apps from me, and probably making a lot more use of MS Windows, this may even be *more* true of our ordinary users. It's not a gratuitous change, but I'm not going to defend it to the death if people object. Nick.
Move help menu item to last-on-left not first-on-right?
I'd like to change the Toolbox to do this: .. or .___. or .. | File Xtns Help || File Xtns Help|| File Xtns H| rather than (as now) this: .. or .___. or .. | File Xtns Help || File Xtn Help || File Help | Can people please tell me why (technical or HCI reasons) I shouldn't do this, given that we don't HAVE to use GTK+ features just because they are there. Comparison with other image editing apps (especially on Unix/Linux) is appreciated, flame wars are not. Ideally, of course, GTK+ would do *something* when menus are not given sufficient width allocation, but that's not fixable for Gimp 1.2.0 release. Right now what I have most resembles the left-most bad case above, and it's impossible to choose Xtns(!) PS This is, AFAIK, a one-liner change in some data, and thus very, very unlikely to break anything. Nick.
Re: [bug]tiff file crashes GIMP
On Wed, Feb 09, 2000 at 11:31:16AM -0600, Miles O'Neal wrote: Phillip Hoerter said... | |I hope this is the right place to send this, if not please forgive me. |I have a few .tiff files of clip art I am attempting to work with. They |load just fine on a windows machine. but on mine I get errors wit xv, ee, |and the GIMP, then they all crash. I have this covered (off-list with Phillip) and will apply a fix to CVS as soon as I've figured out what's wrong. Initial resolution is that this TIFF is broken (illegal) but Gimp should not crash, nor should the TIFF loader. The biggest problem with TIFFs is that anyone can add arbitrary extensions, and a lot of folks do. What program/system were these TIFFs generated on? Fortunately even TIFF requires that a baseline decoder should be able to rely on certain facts about the image data, this TIFF seems to have violated the rules in some manner still being investigated. Nick.
Re: Pathtool?
On Sat, Feb 05, 2000 at 01:46:14PM +0100, Sven Neumann wrote: Do you have any idea how much work is needed to integrate it with the Paths dialog? A number of new bugs would certainly be introduced by doing so. That's why I say: It's too late! Agreed. Broken stuff with no-one working on it is doomed. Please do not step forward and say "I'll do it", the time for that was in November or at the latest December, and there was conspicuous silence during my last Triage thread from those named to defend their code. Now is a good time to check-in fixes to code that you left in an untidy state (expect some File plug-in code in that vein) and to file bug reports for mysterious occurences that you've been putting up with during the development cycle. Nick.
Re: Translation inconsistency
On Mon, Jan 31, 2000 at 01:53:47PM +0100, Sven Neumann wrote: In the core the short description and the longer help strings for the PDB functions are not marked for translation. This decision was made since the PDB help strings are considered to be targeted mainly at developers and script-writers. It would be a lot of work to translate them and even more work to get the translations correct and to keep them uptodate. So it was considered not to be worth the effort. Sounds fine to me so far, biased as I might be Any ideas, comments anyone? I'll buy (B) -- we do not translate C keywords, variable names, or any other components visible only to the developer. Nor do we translate internal errors, bug reports or this list. Therefore to contribute effectively as a developer you have to learn English anyway. If you need to tell USERS something important then it should not be in these strings, you should rather write a paragraph for the GUM. (B) don't mark the strings for translation, not in the core, neither in the plug-ins Nick.
Re: feature requests?
On Sat, Jan 29, 2000 at 02:28:47PM -0600, Dean Johnson wrote: Howdy, Is there a feature request database for Gimp? Yes, file a bug as usual, but set your (is it urgency? priority? I don't remember, but I'm pretty sleepy right now) to show that it's a feature request/ request for enhancement. This is with the central Gimp bug database, on bugs.gnome.org, I think Gimp News has a good link directly into the system, but I do not know if you can file RFEs through Gimp News. NB No more features for 1.1.x - Right 'em down, file 'em and remind us about it when we're all partied out from releasing 1.2.0. Nick.
Re: feature requests?
On Sat, Jan 29, 2000 at 04:38:52PM -0500, Kelly Lynn Martin wrote: If by "color table" you mean the indexed color palette, that will require core modifications (I believe) because I don't think palettes are exposed to plug-ins well enough to do operations on them. What do you mean by "well enough to do operations on them" ? All the existing plug-ins that work with palettes (INDEXED images would be even more useless than they already are if no plug-ins could work with them) use calls like: palette= gimp_image_get_cmap(image, entries); /* and */ gimp_image_set_cmap(image, palette, entries); That enough? (remember we're talking about = 768 bytes here) Nick.
Re: feature requests?
On Sun, Jan 30, 2000 at 02:38:07AM +0100, Marc Lehmann wrote: So plug-ins should duplicate the palette file parser, scan all direcrories where gimp looks for palette files to find the palette is looking for, and then restart gimp to take notice of the changed files? "duplicate the palette file parser" rather overstates the problem, if you take a look at the file format you'll wonder what all the fuss is about -- it's not even High School Chemistry, let alone Rocket Science The fabled "Swiss Army Chainsaw" ought to make short work of it. The modern Gimp ships with exactly ONE, count them, directory in the palette search path, so for a quick fix (yes, that's what this is, otherwise I wouldn't have proposed using Perl) we can use an existing PDB lookup to guess the correct directory in 1 line of code. Then you open a dialog which says 'Sorry about this old chap, but I'm afraid you'll have to click "Refresh" in the poorly designed Palette Edit dialog, we promise to make this less evil in a future incarnation of the Gimp'. All done. That's fine. This just means that palettes cannot be managed via plug-ins, just as was said before. I happen to think that the above is better than admitting defeat and saying "We can't do that AT ALL". If a user agrees sooner or later they'll do it themselves (canny wee people users). Anyway, I suppose it's about time that I looked closely at what was originally requested, to figure out who I should suggest this Perl hacking exercise to (you will accept it if they write it Marc, right?) Nick.
Re: some tiff image kills the tiff plug-in
On Mon, Jan 17, 2000 at 11:56:31PM +0100, Marc Lehmann wrote: I've got an 34k tiff file that xv cannot load (many errors), and gimp gives an error message "Falling back to RGBA, image might be inverted" (two times) and then the tiff-plug-in segfaults ... This (the segfault) is now fixed in CVS. Stupid one line thinko. I can't figure out a nice way to avoid "image might be inverted", but it only happens for images we don't really understand (Marc's was a CMYK separation as far as I can tell) and for those we ask libtiff to do all the heavy lifting. If anyone REALLY cares about this they can send me a nice fat cheque and I'll write a few 000 lines more code :) Nick.
Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
On Tue, Jan 11, 2000 at 11:50:28AM +0100, Sven Neumann wrote: As said, I can't reproduce your problem here. As soon as I open the error_console, all errors produced with g_message () appear in that dialog instead of popping up a message window. Oh, I see. Somehow I expected that all my errors would appear in that box, regardless of whether they happened before it was visible. Having played with that part I see what you mean... I'm still not sure quite what I wanted this to do, but it does *do* something useful so strike that from the Triage list. Nick.
Re: Triage! (was Re: [gimpwin-users] PNG blank display bug)
On Tue, Jan 11, 2000 at 06:15:11PM +0100, Raphael Quinet wrote: So maybe what we need is a new option in the gimprc, something like: make-error-console-visible-on-first-g-message-and-leave-it-open If you set that to true, then the error console would do what you were expecting. Or did I misunderstand this discussion? Now if only all errors, debug messages and so on could use g_message() instead of printf() (in some plug-ins), then everything would be perfect... Mmmm, well that was part of my sort of half-thought-through expectations, we should see a lot MORE messages in a thing like the Error Console because we don't have to click "OK" for every single message... e.g. In the PNG plug-in, if I knew I was talking to the console, I would feel happy to report blow-by-blow CRC errors which may occur a few dozen times in a single (corrupted) file. However as a user I don't want twelve OK buttons to hit if I haven't got the console :) As it is, some PNG errors are reported to stderr, which is probably not useful to anyone (but it's default libpng behaviour so I have never gotten around to turning it off) and all fatal errors are reported via one or two general purpose g_message-type calls. Nick.
Triage! (was Re: [gimpwin-users] PNG blank display bug)
On Mon, Jan 10, 2000 at 10:29:29AM +0100, Sven Neumann wrote: Oops, I thought (but should have checked) that image_set_resolution_invoker was calling the gimp_image_set_resolution() in app/gimpimage.c. And probably it should since the core function keeps the undo_stack in sync by calling undo_push_resolution (gimage). On the other hand if called from the PDB, we probably don't want to gdisplays_shrink_wrap (gimage)... Um, yes, that's pretty much the sequence of thoughts that went through my mind. However, doing a good job of removing such redundancy will take a lot of time, and provide no noticeable improvements (save the possibility of stumbling on a bug fix) for our poor users. -- It's the start of a new year, and my mind turns to Spring cleaning already How about some comments for feature triage? There are some features in Gimp 1.1.x which are buggy or unusable, yet stay the same for weeks at a time. Without paid staff to do this work, we must throw away [*] stuff that's not going to make it. On my short list... * Resizable toolbar * Natural airbrush * Error Console (well, here it is, but where are my errors?) * Display Filters * Paths More? Comments from people who started these features? This is your excuse to tell us the long tale of how the perfect 100% bug free version of Fill-in-your-feature was tragically lost to a Volcano during your desperate struggle to save an innocent baby... Nick. [*] Well, put it to one side until 1.3.x, but even then, if no-one will write code for it, how will the feature get finished?
Re: [gimpwin-users] PNG blank display bug
On Sat, Jan 08, 2000 at 11:16:45AM +0200, Tor Lillqvist wrote: The PNG apparently claims to have the display (and print) resolution of 0 pixels/inch... Set it with ImageScale ImagePrint Size Display UnitResolution X and Y and the image appears. The PNG plug-in probably should check for this and use some sensible default if the file claims 0 dpi? Mmmm. Can someone tell me which app or lib is settings pHYs == 0 ? I think png-implement would like to know about anyone stupid enough to actually do that (it's an optional chunk, so if you don't know what to put in it, why write it at all?) If you have a suitably broken PNG which is non-sensitive then I'd also like a copy to add to my collection of test images. Nick.
Re: When will Gimp support JPEG2000
On Sun, Dec 12, 1999 at 11:56:57PM +0100, Eduardo Perez wrote: [...] If it becomes widely used, I'm sure someone will be willing to risk being sued (as I have with TIFF implementation) and provide an ^^ Could you talk a bit more about that, please? Who and why sued you? Perhaps that paragraph doesn't make it clear. I've never been sued by Unisys (or anyone else) but it seems clear from e-mail communication with them that they considered plug-ins like Gimp TIFF to be in violation of their LZW patent, regardless of how LZW is implemented inside the plug-in. In theoretical terms, I do not know what legal precedents exist in the US or in my home country (Great Britain) so I cannot say whether a court would consider the violation mine, libtiff's or both... In practise, as I have said elsewhere off list, it doesn't matter. If they haven't done more than write unfriendly e-mail in the past I see no reason to expect different in the future. Bringing cases to court would only highlight the unfairness of algorithm patents, which is not in their interest. This isn't really on-topic for gimp-devel, so I suggest you take any further discussion off the list. From the graphics point of view, adequate or even better replacements for LZW TIFF already exist. Nick.
Re: When will Gimp support JPEG2000
On Fri, Dec 10, 1999 at 12:17:49AM +0100, Max Moritz Sievers wrote: Hello, is there a plan to support JPEG2000? I don't think so, unless JPEG change their mind about the direction for future imaging standards. cynical IMHO JPEG 2000 is an attempt to fix a mistake made in the original JPEG design which permitted anyone to implement a baseline JPEG codec without implementing any of the patented techniques (most obviously arithmetic coding) which JPEG members hoped to foist on the world. JBIG and JPEG 2000 both mandate use of one or more patented techniques which are owned by companies that take part in JPEG. You will notice that no-one is using JBIG for anything much, and also that no-one is announcing immediate plans for JPEG 2000 either. /cynical I haven't seen any of the results from early JPEG 2000 trials (which were intended to eliminate some techniques from consideration for the final JPEG 2000 codec design) but I can't say that I'm hopeful that usable data will survive the factor of two decrease in size needed to convince users to switch in the absence of other compelling reasons. The extended support for metadata is welcome, but already exists in JNG, which will be standardised earlier than JPEG 2000 and is part of an already succesful format family with no patent burden. Since JNG metadata is interchangeable with the already understood PNG format, and the codec is baseline JPEG, support for it should be forthcoming very soon after the standard is set. I would welcome a standard wavelets codec, and an associated standard format, but I'm not very interested unless they are either free of patents or include a free-of-charge unlimited license. Neither of these seems likely at this time from JPEG 2000, so I intend to ignore it. Hopefully everyone else in the industry has seen the light by now and will also ignore non-free image formats in future. If it becomes widely used, I'm sure someone will be willing to risk being sued (as I have with TIFF implementation) and provide an illegal JPEG 2000 plug-in for Gimp, or otherwise a proprietary software company will make use of the LGPL libgimp and provide working JPEG 2000 support that way, but don't hold your breath :) Nick. PGP signature
Re: File-New-Reset
On Mon, Nov 29, 1999 at 11:03:02PM -0600, Miles O'Neal wrote: Marc Lehmann said... | |I don't know what you feel, but I think the new Reset button is definitely |the worst improvement ever. | |Not that such a button is nice, but putting it at the same place where we |had the OK button is definitely _not_ ok, no? This is on the list of things never, EVER to do. Right there with making "Discard changes" the default action on an exit screen. Revert it. It's a new feature. We are frozen. What more is to be said? Nick.
Re: Tons of useless translations???
On Sat, Nov 27, 1999 at 03:23:02AM +0100, Marc Lehmann wrote: We still need to work the perl plug-in names in. The problem is that gettext does not support this (and I see no way to modify the makerules without re-writing them totally. Just another reason why automake is evil). Doesn't Perl have its own i18n mechanism which GimpPerl could use? It make sense that GimpPerl would be consistent in behaving just like any other Perl component for i18n as much as it does for everything else? If Perl doesn't have any i18n, then (1) That sucks and (2) Gimp can't do much about it. If I missed some stupidly obvious obstacle to this then I apologise, I don't use GimpPerl so I don't know very much about it. Nick.
Re: image map trashes image
On Mon, Nov 22, 1999 at 02:49:50PM +0100, Marc Lehmann wrote: In current gimp you will notice lot's of bnad things happening when more then one oepration (regardless of which) is being done at the same time. It gets much worse when you do it on the same image. Are these "bad things" fatal? For the multiple filters, multiple targets case I can't see that they should be. I remember that context (brushes, gradients, palette settings) is global and that can cause problems for scripts that _change_ them, but shouldn't for most plug-ins. Is there anything else? The multiple plug-ins/ tools with single target case is harder, we could probably lock this in a future version of Gimp, but even this should not cause crashes, and so is not critical for 1.2 Or have I missed something dreadful? Nick.
COW / Tile mess
Mon Nov 22 13:18:40 GMT 1999 Adam D. Moss [EMAIL PROTECTED] * app/channel_ops.c: Disabled the copy-on-write for gimage projection. Duplicate op will now take as much time and memory as GIMP 1.0 in this respect. That sucks, but I'm damned if I can follow the twisted paths which GIMP treads in making this bahave badly. Can you? This is bad, is there anyone on gimp-devel who understands the VM in Gimp, or is this another area like the PDB which is unmaintained? I have looked into both at different times, and I join Adam in being unable to make any progress when following the code in my head. 48Mb of image data resolves into 90Mb of swap and soon swells to 116Mb, while a fresh layer is 60+Mb, all is not well inside the VM code :( Nick.
Re: Tile Cache Size
On Fri, Nov 12, 1999 at 05:32:10PM +0100, Marc Lehmann wrote: You saying that the tile system in Gimp is faster is not useful. ^^^ I didn't. Please don't leap into every discussion just to bait me Marc, it's very annoying and I somehow doubt that others are reading this list just to see whether you can bait me enough for me to really bite. Nick.
Tile cache leaking?
Further to my original observations, here is something more detailed: Gimp is set to ~24M tile cache, on a 64Mb machine with ~64Mb of swap The TIFF is enormous (see previous post for exact dimensions) and as a naive RGB array (3 bytes per pixel) would use ~210Mb of space Stage --- Size of gimpswap Fresh gimp, no images N/A not yet created Begin loading TIFF 10Mb almost immediately 50% loaded 98Mb 99% loaded 196Mb (just as TIFF loader exits) Starts displaying 250Mb 50% complete display 380Mb 100% complete display 508Mb Then, as tigert says, the Gimp continues to trickle data into the swap file for some time, but only a few Mb per minute. The TIFF loader created (by my estimate) 210Mb of tiles. There are now 508Mb of tiles on my disk. What is in the 300Mb of tiles which were NOT created by the TIFF loader? Suggestions of how to find out are welcome, but a fix is preferred :) Nick.
Re: Tile Cache Size
On Thu, Nov 11, 1999 at 01:40:28AM +0100, Uwe Koloska wrote: Nich Lamb wrote on Die, 09 Nov 1999: Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations) result in the creation of a gimpswap which is up to 500Mb in size? Where do you think can the undo information reside??? I would guess that when I actually DO something there will an appropriate number of additional tiles allocated in the swapfile. Experience agrees. Give or take tile leaks, which now tigert has mentioned them, explain this problem very well... Why? Where do YOU think the undo information goes? Nick.
Re: Help System
On Tue, Nov 09, 1999 at 04:57:16PM +0100, Sven Neumann wrote: s/help/perl/ On Wed, Nov 10, 1999 at 03:09:46AM +0100, Marc Lehmann wrote: However, perl works on many _many_ more platforms than the help system, which only works on a very limited number of systems. Well, PERL certainly works on a lot of platforms, but Sven was talking about the supposed GimpPerl included in CVS Gimp. AFAICT Everyone just types ./autogen.sh --disable-perl and hopes that sooner or later it will go away. It won't work on my home machine (Slack upgraded to 2.0) or my old work machine (RH 5.2) or my new work machine (RH 6.1) so I guess it's not working for many people at all. Of course, I know it's not a BUG that GimpPerl won't work out-of-box on any reasonable system, but it's also not a BUG that GimpHelp won't work out-of-box on fairly old systems. /me goes back to fixing bits of Gimp HE thinks are important Nick.
Re: Re: Tile Cache Size
On Tue, Nov 09, 1999 at 01:27:29AM +0100, Ewald R. de Wit wrote: Anyway, today I went over the Gimp sources and noticed how complicated the tile architecture makes things and I couldn't help wondering why the heck it was put in. All it seems to do is to give you an order of magnitude slower speed when dealing with large images. And large images were supposed to be the very reason for a tiling architecture. I have no idea where this came from, Ewald did you actually do any benchmarking, or just a few thought experiments? Computers do not behave in practise as it may seem they should ideally. Here are some practical results from my real Gimp machine, a PII 300MHz with 64Mb of memory and ~64Mb of swap. This is with CVS Gimp. If I configure Gimp to believe that it has as much memory as one might conceivably need, then the results are as follows: Loading a large image (*): Wait 10 mins, get bored, try to kill, but the machine is in a swap death loop, after 5 more minutes, just as I log in as root from a serial console, X experiences resource starvations and so Gimp, Gnome, xterms and everything go into the drink. If I configure Gimp with a large but not improbable tile cache (64Mb): Loading a large image (*): Wait 5 mins, TIFF loader finishes, after a further 10 mins the image has been drawn at 10:1 reduction. Now with the defaults as supplied (12Mb ISTR): Loading a large image (*): Wait about 2 mins, loader finishes and now after a further 2 or 3 mins the image has been drawn. And finally with my preferred settings (20Mb): Loading a large image (*): Wait about 2 mins, loader finishes and now after a further couple of minutes the image is drawn, however later performance is slightly faster than in the default case above. (*) A large image here is one which genuinely WILL NOT fit in memory, by any stretch of the imagination. It is a JPEG tiled TIFF (nasty!) of dimensions 7274x9985 and in full 24-bit colour. Nick.
Re: Re: Tile Cache Size
Further to my last post (and possibly related to Ewald's complaints too) Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations) result in the creation of a gimpswap which is up to 500Mb in size? The performance for such images seems adequate to me (can't compare PotatoShop because it refuses to load any of our larger images at all) but this is wasting a lot of active disk space :( Nick.
FREEZE (was Re: More Inconsistency in eraser, blur and dodge tools)
On Mon, 1 Nov 1999, Carey Bunks wrote: I think that Michael has a good point here. Why is it useful to declare a feature freeze? In my opinion the answer is so people can begin making plans with respect to the upcoming new stable release. If just anything is allowed after a feature freeze why declare one? On Tue, 2 Nov 1999, Olof S Kylander wrote: It depends how you specify feature freeze. Some specify it as a stop to add anything (nearly a code freeze) some one else specify it as a clean up and fix time until we enter code freeze. Me my self specify it as a clean up and fix time (that includes e.g cleaning the UI to be consistent). If no-one else will do it, I hearby offer to REVERT all features added to Gimp. It's quite obvious that some/ most of the people here will continue to rationalise additional features until well into the new millenium (and I don't mean 2000). Nick.
