RE: [Gimp-developer] file chooser performance
> a few people have claimed that opening the file chooser dialog would > take a considerable amount of time if it is opened in a directory with > lots of files. Also check when opening the file chooser dialog on an NFS or other remote filesystem isn't too bad, even with small number of files. In my experience things that go fast on local filesystems can go unexpectedly lots slower on remote filesystems. Austin ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Scissors tool
> -Original Message- > From: [EMAIL PROTECTED] [mailto:gimp- > [EMAIL PROTECTED] On Behalf Of William Skaggs > Sent: 06 December 2004 19:05 > To: [EMAIL PROTECTED]; Joao S. O. Bueno Calligaris > Subject: Re: [Gimp-developer] Scissors tool > [...] > > I looked at the code not too long ago, and my impression was that > it reads like it was written by somebody who started with a > complex and incomprehensible algorithm and then added kludges > onto it in an attempt to get it to work. The best approach might > be to clear it out and start fresh. It shouldn't be horribly > difficult, since the problem of connecting two points with a > curve that tries to hug edges is not really all that hard. > (Finding a solution quickly when the points are far apart > might be challenging, though.) I think I was probably the last person to do any major work on the scissors tool, and that was in 1999 to port it to the (then new) tile-based world. The code when I took it on was a "software Vietnam"; a complete mess. I had to read the SIGGRAPH paper it was attempting to implement before I could fix it, and believe me it left my hands much cleaner than I got it! There are two areas where it could do with improvement: - it doesn't handle tile-boundaries (it treats them as edges) - the point editing interface sucks; I merely made the existing one work but it might be interesting to see if it could use the same code from the Path tool (that was always the plan) Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: 2.2 splash screen competition
My favourite so far is the colourful paint pots by Metin Amiroff: http://www.gimp.org/contest/gallery.cgi?display=image&name=20041202090612748 6 Or maybe the paint tubes by Andreas Nilsson, I can't decide: http://www.gimp.org/contest/gallery.cgi?display=image&name=20041202090610747 8 I think ones featuring the traditional artist's tools are some of the best, although some of the bold flower-based ones are good too, eg: Brandon King's chrysanthemum against a desaturated background: http://www.gimp.org/contest/gallery.cgi?display=image&name=20041202094328970 6 Or Becky Cierpich's flower & digital background: http://www.gimp.org/contest/gallery.cgi?display=image&name=20041202094428993 6 The standard of entries is (by and large) very high; I'm impressed. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] first impressions of GIMP 2.0
[Adding a layer mask] > >> Huh? Go to the Layers menu, choose "Add Layer Mask". Also available > >> from the right-click menu in the Layers dialog. > > > I couldnt actually access this - it was greyed out completely. > > You can't add a layer mask to a layer that doesn't have an alpha > channel. Hmm - perhaps the best interface here would be to always have the "Add Layer Mask" menu option available, but if there's no alpha channel then popup a dialog saying something like "Adding a layer mask requires the image to have an alpha channel. Would you like me to add one? Yes: / No" (default yes, tickbox (unchecked) for "don't ask me again"). This is similar in spirit to the file export dialogs that automatically convert your image into something the file save plugin can handle (ie flatten etc). It's the DWIM (Do What I Mean) school of UI design, where you try and guess what the user is actually trying to do :) Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] difference between canvas_draw anddraw_tool_draw functions
> the drawtool always paints using GIMP_CANVAS_STYLE_XOR, correct? I'm > creating a patch to add an option to the crop tool to blind the region > outside the crop area, so you can see how the image will look after > cropping. I've not decided yet if XOR is good, or if the area should > become > black. Anybody a preference? I'd vote for greying/dimming the image outside the crop area, much like the QuickMask feature turns stuff red. In fact, you could look at the quickmask code to see how that does it. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] new file-new dialog
> "Austin Donnelly" <[EMAIL PROTECTED]> writes: > > > > - Add an easy way to change the image's unit. It's quite well hidden > > > in the Image Scale dialog right now. With the changes proposed > > > above, changing the image unit could become a more frequent task, so > > > it should be easily accessible. > > > > I'd suggest taking a double-click in the rulers should bring up a > "change > > units" dialog box. It should allow people to change to pixels, since > the > > most immediately visible effect of changing the image's units is to the > > rulers. > > That's not very intuitive IMHO. If we display the unit in the > statusbar, then it would probably be best to allow it to be changed > where it is displayed (and, of course, in the menu as well). I see > that the rulers do also display the unit in one way or another. > However a double-click on the rulers is something that only few users > will ever try. I also guess that only few users ever find out that you > can create guides by dragging them from the rulers. I like the idea of a pop-up in the statusbar - and I expect that's what most users will use to change the units. But if a user does double-click a ruler, how should Gimp interpret that? Perhaps it should popup a dialog saying: Ruler configuration --- Show rulers: [X] _ Image units: |- Inches | - Tip: you can create a guide by dragging from a ruler into the image I know all this functionality is available elsewhere, but it makes Gimp friendlier. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] new file-new dialog
> - Add an easy way to change the image's unit. It's quite well hidden > in the Image Scale dialog right now. With the changes proposed > above, changing the image unit could become a more frequent task, so > it should be easily accessible. I'd suggest taking a double-click in the rulers should bring up a "change units" dialog box. It should allow people to change to pixels, since the most immediately visible effect of changing the image's units is to the rulers. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Dithering
That's because the screen display code doesn't smooth the image when it scales it, for speed reasons. Dedicated viewing programs can afford to do a better job showing the image because they won't be re-drawing it quite so often (imaging panning around the image while editing it - you'd like that to be fast, right?) Austin > -Original Message- > From: [EMAIL PROTECTED] [mailto:gimp- > [EMAIL PROTECTED] On Behalf Of David Gómez > Sent: 07 January 2004 22:04 > To: Sven Neumann > Cc: Gimp-devel > Subject: Re: [Gimp-developer] Dithering > > Hi Sven ;), > > > The GIMP display canvas uses the dithering routines from GdkRGB which > > is probably what you are refering to. > > Yes i was referring to GdkRGB dithering, but it seems that was not > the cause of the problem, as i said in my previous mail, and i was > wrong thinking that was caused by gimp dithering implementation. > > Thanks, > > -- > David Gómez > > "The question of whether computers can think is just like the question of > whether submarines can swim." -- Edsger W. Dijkstra > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] jobs for the boys: RIP coders wanted
Hi GIMPers, I know this is a little off-topic, but it's definitely interesting to anyone looking for a job in the pre-press software industry. Ben Hobbs (from Idealpeople, a recruitment firm) is looking for people with experience of RIPs, and other pre-press issues. I've put a message from him below. Thanks, Austin --- Hi Austin, I have been enjoying your explanations on FM Screening and dithering, They have helped me understand one of our specs a great deal more, Thanks. We have recently set up a division (me) to focus exclusively on recruitment for the pre-press/print technology industry and are finding it hard to come by candidates. We are currently after: * RIP Coder with experience of Colour Management (ICC Profiles etc...) - Australia Permanent position with full help in re-location, work permit and immigration issues. * Screening Consultant for a RIP company in Europe * RIP Coders for a UK based company (London) Do you know anyone who would be interested in any of these positions, If so then please let me know! Basically we are interested in all coders with experience of RIP's, PCL and digital print technologies overall. This is really very appreciated, its actually been very refreshing for me trying to source these vacancies. The help people have given me I have not seen in any other area of software development, Oh and we are particularly interested in Linux guys for the Australian role. Regards, Ben Hobbs Idealpeople ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: Portable XCF
> Yes, try it with dd and cp (GNU version only?): > > dd if=/dev/zero of=/tmp/zero-test count=1000 > cp --sparse=always /tmp/zero-test /tmp/zero-sparse > ls -l /tmp/zero-test /tmp/zero-sparse > du -cs /tmp/zero-test /tmp/zero-sparse > [...] > What I do not know is how many fs support it, and if they can do on > the fly or a forced copy is needed It is the copy which makes the sparse file. You can't make a hole in a file merely by writing a bunch of zeros to it. You can only do it by seeking past the (current) end of the file, then writing non-zero data. The bytes you seeked over are the hole, and will be read as if zeros. GNU cp uses a bunch of heuristics to discover runs of zeros in the input file and seek over them in the output file, rather than just writing zeros. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Portable XCF
Tor wrote: > [filesystem within a file] It's a nice idea in theory, but makes it quite hard to write a parser for. MS Word files (until recently) were basically FAT filesystems, which makes it easy to handle under Windows but harder to parse when you don't have a convenient DLL to do it lying around. The FlashPix format (now little used?) is also a FAT filesystem; it was this fact that persuaded me that writing a Gimp FlashPix loader wouldn't be particularly easy. So sure, consider the idea, but bear in mind it might be hard to pull off. When this discussion started, I didn't like the idea of XML with binary data portions. I liked the current binary, tagged, format we have, and thought that it should just be extended. However, after the recent discussion I've come around to quite liking an ar-style archive with a XML catalog, XML metadata, and texels as separate members. I think this is roughly what Leonard was suggesting; we should listen to the voice of experience. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] PS vs. PDF
> >Are you sure it hasn't been updated for so long? Take a look at the > >PostScript 3 reference manual. > > OK, 5 years instead of 6 (1998). But in today's world, > that's a HUGE time... What you're looking at is a mature standard. Surely that's a good thing! If it ain't broke, don't fix it. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: GimpCon RFC: Portable XCF
> > How is the serialization done then, just a raw 32-bit IEEE float > > dump with a predefined endianness? 64-bit doubles just as easy? > > Yup. The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] A fresh pair of eyes.
> > GIMP zooms on Shift-wheel since some early 1.1 version. > > Can the gimp be made to zoom in/out on the cursor instead of on the > centre of the image. We have a bug open on this: http://bugzilla.gnome.org/show_bug.cgi?id=79384 Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Startup Notification support...
So is the current 1.3.x build environment documented in the HACKING file (or elsewhere)? I'm guessing that the file is probably out of date, or lacking things. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Gradient dithering
> Conceptually I like this, and the gotchas are toggleable > via the UI. I like the idea too. It should be checked in and turned on by default. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] useless plead for honest evrsion numbers :)
> (Yes, > I like the text tool, I etxremely like the undo history.. but that is all > nothing major). But the undo history is not a new 1.3 feature, it was introduced by me in one of the 1.1 testing series and has thus been in all the 1.2 versions. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Tool API [LONG!]
> [...] "the_gimp" should not be > accessed directly, and tile_manager is probably too ugly for tool > developers with weak stomachs. Not clear; iscissors uses a custom tile manager which supplies tiles containing gradient/direction information. This way, the expensive calculation of this info is delayed until it is actually needed by the selection-boundary walking code (we don't know ahead of time where the boundary is, but we can guess that it's not going to include every tile in the image). Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Why modules interface?
> I want to add some features (changeing the gamma of the display ...) to > filmgimp. There already is a module called "cdisplay-gamma" which can do this. You don't need to write any code, just use this pre-existing module. However, I'll still answer the rest of your questions: > I liked to implement this as removeable plug-ins but they are > (as far as I expect) not selfcalling. The application I'm planning needs > to start instandly with filmgimp. By "selfcalling", I assume you mean that it starts automatically. > 1. Is the modules interface the best way for this? Yes, because changing the gamma of the display requires tight integration with the display code. > 2. What are all the differences between plug-ins and modules? Plugins run in their own process, so if there is a bug in a plugin, it should not crash the gimp. Modules run in the same process as the main gimp, so a bug in the module can crash the entire thing. The only reason you should use a module is if your code needs to be called so frequently that the overhead of being in a separate process is too much. Or, if you need to share state with the main gimp application (eg because you are extending the main UI directly, like the colour selectors do). Hope this helps, Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] FW: Patch for wishlist entry 75558
Can someone please look into this patch I've been submitted?
Ta,
Austin
--- Begin Message ---
Title: Patch for wishlist entry 75558
Hi,
I wrote a patch for the bugzilla entry 75558, curve tool does not remember old
values.
I wrote a patch for this a while ago, but it seems to be removed in the newer
gimp versions because of some problems.
So I made the change again and hope that you can commit it to cvs.
This time I tested it with RGB and grayscale pictures. No problems whatever.
(patch is appended)
Thanks,
Ralf
--
Ralf Engels
Software design engineer
www.rengels.de
--- gimpcurvestool.c.old Fri Jan 10 12:30:05 2003
+++ gimpcurvestool.c Fri Jan 10 12:38:57 2003
@@ -289,17 +289,17 @@
if (!curves_dialog)
{
curves_dialog = curves_dialog_new ();
-}
-
- /* Initialize the values */
- curves_dialog->channel = GIMP_HISTOGRAM_VALUE;
- for (i = 0; i < 5; i++)
-for (j = 0; j < 256; j++)
- curves_dialog->curve[i][j] = j;
-
- for (i = 0; i < 5; i++)
-{
- curves_channel_reset (i);
+
+ /* Initialize the values */
+ curves_dialog->channel = GIMP_HISTOGRAM_VALUE;
+ for (i = 0; i < 5; i++)
+for (j = 0; j < 256; j++)
+ curves_dialog->curve[i][j] = j;
+
+ for (i = 0; i < 5; i++)
+{
+ curves_channel_reset (i);
+}
}
curves_dialog->drawable = gimp_image_active_drawable (gdisp->gimage);
@@ -333,6 +333,9 @@
gtk_widget_show (curves_dialog->shell);
curves_update (curves_dialog, GRAPH | DRAW);
+
+ if (curves_dialog->preview)
+curves_preview (curves_dialog);
}
static void
--- End Message ---
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] List of changes for the future 1.2.4 release
> Saving .xcf on full filesystem hangs GIMP > http://bugzilla.gnome.org/show_bug.cgi?id=101340 > > doesn't seem overly complicated since there's only one call to fwrite() > in app/xcf.c which needs to have its return_value to be checked. The > larger part of the problem is to propate the error up from > xcf_write_int8(). Note that just checking write() or fwrite() return values may not be enough: some filesystems delay the error indictation until close() is called on the fd. So this bug may well be influenced by the filesystem GIMP is writing to at the time. Just a detail to bear in mind... Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] how does undo currently work
I wrote some docs about the undo system's operation; try looking around in the doc/ subdirectory. I can't vouch for how accurate they are now, but I don't think the system has changed much since I added the "undo history" feature. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] 16 bit gray images not handled properly
I wrote a patch which added a warning, but subsequently it was decide that not enough people would understand or care what was going on. Austin > -Original Message- > From: [EMAIL PROTECTED] [mailto:gimp-developer- > [EMAIL PROTECTED]] On Behalf Of Roland Roberts > Sent: 14 October 2002 17:38 > To: gimp devel > Subject: Re: [Gimp-developer] 16 bit gray images not handled properly > > > "Sven" == Sven Neumann <[EMAIL PROTECTED]> writes: > > Sven> Import plug-ins that handle 16bit by converting to 8bit > Sven> shouldn't do this silently but inform the user what > Sven> happens. If they don't, that's a bug and should be reported > Sven> thru bugzilla. > > I've added this bug for 16-bit/color TIFF images which are imported > correctly by GIMP 1.2.1 but with no warning. > > roland > -- > PGP Key ID: 66 BC 3B CD > Roland B. Roberts, PhD RL Enterprises > [EMAIL PROTECTED] 76-15 113th Street, Apt 3B > [EMAIL PROTECTED] Forest Hills, NY 11375 > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Vector prog.
On Sunday, 7 Jul 2002, Simon Budig wrote: > Uhm - xfig? :-) Actually, if you want to use something like xfig, consider instead using tgif - in the same way as emacs uses lisp internally, tgif is a vector graphics editor which uses prolog internally. It's very powerful, but a lot of people don't know about it, which is a shame. http://bourbon.usc.edu:8001/tgif/ (The GIF in the name has nothing to do with the patent-encumbered raster graphics format). Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What to do when zooming in? (bug #79384)
On , 23 Apr 2002, Sven Neumann wrote: > ack. Who writes the patch? Sorry, not me - lack of time :( Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What to do when zooming in? (bug #79384)
On Tuesday, 23 Apr 2002, Raphaël Quinet wrote: > - Behave as if the zoom tool had been used temporarily: if the mouse > pointer is inside the image window when the shortcut key is used, then > zoom in on that point. If not, then zoom in on the center of the window. This has pissed me off for some time too. All Apple Mac applications I know of zoom centred on the current pointer location. Expert users can use this to zoom+scroll quite naturally, and novice users just think it's zooming centred on the image but not quite right. If the mouse isn't in the image window, then doing a normal "zoom centred" is probably best. Trying to guess that the selection is up to is a recipe for disaster, as noted in the many special cases in the bug report. I can't remember the Mac behaviour on zoom out. I don't suppose it matters too much there, though. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] amp photoshop curves
On Friday, 29 Mar 2002, regis rampnoux wrote: > You can load the files with the plug-ins amp4gimp which is in the > registery. (I found yesterday a bug but you can use it ...) > There is no save option at this moment. If the amp format is simple enough, why don't we just make it the default format for Gimp curves too? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Size entry widgets..
On Wednesday, 27 Mar 2002, Øyvind Kolås wrote: > * My workflow for posters that will be printed on a laser printer is: > - make a new grayscale image with the same size ratio as A4/A3 > - fullfil the design > - scale the image up to the full res of the 'printable area' > - manually newsprintifying, dithering etc. the image down to > 1bit Warning: the newsprint plugin does nothing to avoid moire artefacts other than offer an antialias option. It doesn't use supercells to reduce rounding errors. Therefore, if you're using it to produce 1-bit output (and hence can't use antialiasing) then you should expect poor quality output. The newsprint plugin is suitable for producing (eg) silk-screens for t-shirt designs, or special effects, but not for printed flyers, in my opinion. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] valgrind memory debugger
On , 22 Mar 2002, Sven Neumann wrote: > yes, it's kinda cool. It didn't like the MMX check in gimp-1.3 and > mumbled something like "Insane instruction". It works fine however > with the latest gimp from CVS when passing --no-mmx on the gimp-1.3 > command-line. I'm not sure if I prefer it over memprof but it's > definitely helpful. I don't know much about memprof, but there's some cutting edge research in valgrind: the author was giving a talk on it at our lab this afternoon. One of his stated aims was to reduce the number of false positives, so that (as far as possible) every warning it issues is a real bug. > We are getting a decent amount of warnings about > "Use of uninitialised CPU condition code" This indicates that program control flow is non-deterministic: ie you've done a "switch" or "if" on a variable which contains junk. The actually loading of junk from memory into the variable may happen earlier than the test, so you'll need to look back at the program logic a bit. > I'm not certain if we can trust valgrind here, but it would > definitely be a good idea to investigate this to make sure. I would trust valgrind :) Of course, it may have found a bug in glib, gtk, or the X libraries. Apparently the author found a number of libc bugs, and gcc code generation errors(!) Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] valgrind memory debugger
On Thursday, 21 Mar 2002, Nick Lamb wrote: > It has a KDE bias, but I'm sure some loving from the right people will help > it learn about glib 1.2 and 2.0 objects, memory allocators etc. to give > more helpful diagnostics when you scribble all over a MemChunk :) I didn't see any particular KDE bias. Certainly, it doesn't need any of the KDE libs to run, and uses just a text console interface. > > I've given it a quick spin on gimp-1.2.2, and it picked up a couple of > > bugs. It's really quite a good tool! > > I didn't see any problems with 1.2 CVS when I tried it a few weeks ago, > except for shared mem stuff at startup (which I put down to Valgrind > not knowing about shared mem at that point). Maybe I didn't try the > right tools/ features/ whatever ? Perhaps they're bugs in GTK then. I got one message for the yellow tool-tips popping up from the toolbox. And I got another at startup - perhaps that's the one your talking about. Using the ink tool showed some problems in the blob code too. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] valgrind memory debugger
I've just heard about Valgrind, a memory debugger much like Purify, but which works on Linux. I've given it a quick spin on gimp-1.2.2, and it picked up a couple of bugs. It's really quite a good tool! For more information about it, see: http://developer.kde.org/~sewardj/ Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image-title-format etc
On , 22 Feb 2002, Sven Neumann wrote: > > > get your hands on GIMP-1.3.3 and add %L to the image-title-format > > > or image-status-format strings. There you go. > > > > Since we now have a number of these *-format strings, has someone > > taken the time to generalise my code for image-title-format? > > please excuse my ignorance, what code are you talking about ? gdisplay.c: gdisplay_format_title() (It may have moved in 1.3.x) It's a large switch statement, with hard-coded characters and their expansions. If different expansions are needed, perhaps its time to write a function (eg expand_format()) which takes a format string, an environment, and a table of format chars and their expansions. I didn't do it this way originally because it was more complicated and at the time there was really only one set of format chars. If now we're expansing different format strings, then perhaps the time has come to generalise the code. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Menus, keybinding et al, first draft
On , 17 Feb 2002, Rebecca J. Walter wrote: > As any looked into how all this will work with different window > managers? What window managers grab what keys and can the window > managers easily be configured to use alt if gimp isn't using it? > > It is important to check this since we will otherwise end up with lots > of whiny users who can't figure out why thiings aren't happening like > expected. I'd like to whine: I use ALT+mouse1 *inside* a window to quickly move it somewhere else on the desktop, therefore any ALT clicking is going to annoy me severly. Could someone post a summary of the differences between the current setup and the proposed new setup? Austin (Sorry to dig up old emails, but I've only just got back from a week's holiday without Internet access - joy!) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugin icons in menus
On Sunday, 17 Feb 2002, Maurits Rijk wrote: > Will it be possible for plug-ins in 1.3.x/1.4 to put their own neat > little icons in front of their menu entry? I guess this would mean some > minor enhancements to the plugin API :) While technically this is possible, I don't think its a good idea from a UI point of view. Not all plugins will have icons, and it will look very messy and confusing. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] image-title-format etc
> get your hands on GIMP-1.3.3 and add %L to the image-title-format > or image-status-format strings. There you go. Since we now have a number of these *-format strings, has someone taken the time to generalise my code for image-title-format? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop brushes
On Wednesday, 13 Feb 2002, Maurits Rijk wrote: > I noticed that it's pretty easy to write a plug-in to import Photoshop > brushes. There seem to be lots of those freely around on the net. First > question: is this plug-in already available (couldn't find it in the > registry) and secondly: if not, would there be any interest in such a > plugin? I don't think such a plugin exists already. By all means, go ahead and code it up - it sounds useful! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On , 7 Feb 2002, Sven Neumann wrote: > exactly. If there's a need to improve the current parasites, let's do > that now. I could imagine that a more hierachical structure might > help, but I'd like to see a real usage case before we consider doing > such a change. Is the EXIF data such a usage case? Uh - it already *is* hierarchical: that's exactly what: gimp-* gimp-exif-* etc are! It's hierarchical by convention, and this isn't checked, sure. But it's quick and easy. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] calculations in background?
On Tuesday, 15 Jan 2002, Martin Waitz wrote: > is there already a way in gimp to do background calculations? > i.e. perform some lengthly calculations while user interaction > is still possible? Have a look at how the gradient fill tool does it. Its a horrible hack at the moment, and there's no locking (as of 1.2.2) Do we have locking in 1.3.x? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] intelligent scissors
On , 15 Jan 2002, Michael Natterer wrote:
> I stripped out the USE_LAPLACIAN part not because it was unused
> but because my impression was that it could not work:
>
> gimp-1-2/app/iscissors.c has the following piece of code:
>
> #ifdef USE_LAPLACIAN
> static gint laplacian [9] =
> {
> -1, -1, -1,
> -1, 8, -1,
> -1, -1, -1,
> };
> #endif
>
> but then "USE_LAPLACIAN" never appears below and the "laplacian"
> matrix is never used, which made me think it's b0rken, so I removed
> it when porting it to GimpTool...
Ah ok - it was a long time since I last looked at the code. You're
right, it wouldn't work. I mis-remembered there being a bit more to
it than that.
> I can put the stuff back so people don't need to compare code
> they have not restructured themselves, please let me know.
Nah: It's not worth the hassle, but thanks for offering.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] intelligent scissors
1.2.2 definitely has the USE_LAPLACIAN code in, but it is not enabled. The current developer head in CVS doesn't. I'm assuming that as part of porting iscissors.c to the new tool model someone (Mitch/Sven?) took the opportunity to strip out unused code. This is a perfectly reasonable thing to do. However, if Martin wants to compare the performance of the full Laplacian versus the basic gradient convolutions we do at present, he'll need to use the 1.2.2 code. Or port that code to the current developer version. In any case, anyone willing to work on iscissors is more than welcome to it! I agree with Sven that work should use the latest developer CVS though. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] intelligent scissors
On Tuesday, 15 Jan 2002, Martin Waitz wrote: > On Tue, Jan 15, 2002 at 11:08:28AM +0000, Austin Donnelly wrote: > > I did test-implement it. #define USE_LAPLACIAN and recompile to see > > if it makes much difference. I couldn't see a visual different, only > > it was a bit slower. > well, then your implementation was not committed to cvs It most certainly was. I think someone stripped out that code when 1.2.2 was re-arranged into the current developer version in CVS. Try looking at 1.2.2 app/iscissors.c instead. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] intelligent scissors
On Tuesday, 15 Jan 2002, Martin Waitz wrote: > On Mon, Jan 14, 2002 at 10:37:13PM +0000, Austin Donnelly wrote: > > I think I was the last person to substantially modify the iscissors > > code. I read the paper you reference above, and indeed it was quite > > helpful. However, note that their algorithm is substantially more > > computationally expensive than what iscissors.c currently does. This > > is deliberate. > yes, but i guess one has to test-implement it to be able to > judge if it's worth it... I did test-implement it. #define USE_LAPLACIAN and recompile to see if it makes much difference. I couldn't see a visual different, only it was a bit slower. I haven't looked at the current developer version, so I've no idea about the path cooling stuff someone else has implemented in the meantime. > although i must admit i don't yet understand everything of > gimpiscissortool.c) I don't think anyone does! Good luck! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] intelligent scissors
On Monday, 14 Jan 2002, Martin Waitz wrote: > anyone working at the iscissor tool at the moment? > > i would like to implement some of the features described in > http://www.cs.orst.edu/~enm/publications/GMIP_98/seg_scissors.html > as a work for an university course. I think I was the last person to substantially modify the iscissors code. I read the paper you reference above, and indeed it was quite helpful. However, note that their algorithm is substantially more computationally expensive than what iscissors.c currently does. This is deliberate. Also, the "live wire" feature mentionned in the paper would be fairly tough to do in gimp (from a UI point of view). Can you be more specific about what features described in the paper you wanted to add to iscissors? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF support added to ImageMagick
On , 16 Dec 2001, Sven Neumann wrote: > my whole point was that we should try to come up with a reasonable > interchange format for multi-layered images instead of using XCF > which isn't really well-suited for this task. Introducing XCF support > into various other apps will make that even more difficult. Perhaps > I'm thinking too idealistic here... What's so bad about XCF anyway? It's got a version identifier, and it's a tagged format so old loaders can skip sections they don't understand. The only problem is the fixed tile size, yes? If we need to make the tile size variable we just bump the version number and introduce a new tagged section for the tiles. Representing the same information in XML or whatever the sexy standard is this month doesn't buy us anything over what we have now. Especially since the code used in loading and saving XCF is by now fairly mature and (hopefully!) bug-free. Re-coding it is only going to introduce new bugs. See the recent article linked off Slashdot about why throwing your code away and starting again is a bad idea, using Netscape and MS Word as examples of large projects which tried to re-code from scratch and failed: Netscape went bust, and MS quietly canned the Word re-write project. We should learn from the mistakes of others :) Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF support added to ImageMagick
On Tuesday, 4 Dec 2001, Seth Burgess wrote: > I think if you make sure to check the version of the XCF, this will be > exceptionally useful to users of ImageMagick. Its not at all an uncommon > request on gimp-user or the gimp newsgroup. Batch conversion is still best > handled via the commandline, and having the ability to use gimp's working > format is a big bonus. > > It makes us bump the version number when we upgrade the image format, but we > try to do that anyway. > > Now, I don't expect it to be easy to implement (involving > significant chunks of the core, as Sven mentioned), but if you've > got that covered please do add it! Me too! I think being able to convert XCFs with ImageMagick would be a very useful tool. Just make it clear to users that the rendering they see may not be pixel-for-pixel the same as the gimp version (eg because of slightly different rounding of values combined in layers, etc). Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug selection (swatters ready!)
On Friday, 30 Nov 2001, Dave Neary wrote: > 63411 http://bugzilla.gnome.org/show_bug.cgi?id=63411 NEW > Eraser Tool behaves wrongly when toggling. >Seems pretty accessible... > > 35489 http://bugzilla.gnome.org/show_bug.cgi?id=35489 NEW > crop tool doesn't always change canvas size >An odd one, this - another intermittent bug. Actually, >it's every second time. And only on big images. Go figure. >(I mean it, go figure :) These two might be related. See Raphael and my recent comments in Bug#35489. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Tuesday, 27 Nov 2001, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: > Anyways, I had some conversation with two graphics designers about CMYK > problems and the Gimp at the Systems, and I think it might be worthwhile > to read the following "sometimes true" observations. Remember, they are > hearsay ;) [observations snipped] Wow! Marc Lehmann has written an email that's actually useful and well-thought out! His "60% CMYK" makes sense to me. Now all I need is the time to implement it. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Grain Erase plug-in
On Wednesday, 24 Oct 2001, Jerome Dumonteil wrote: > I've released a plug-in for gimp (main goal is to remove black isolated > pixels on dirty scanned document). > Any comment welcome. > (However I don't think it has enough interest to be in the main gimp > release, so don't consider its name and menu position as important > features ;-) > > sample of use : > http://raymond.ostertag.free.fr/html/greffon/test_1.html > > plugin, doc, samples : > http://perso.linuxfr.org/jdumont/gimp I like it! Pretty cool! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] [BUG] gtk_font_selector vs non scalable fonts
On , 22 Sep 2001, Thierry Vignaud wrote: > we've patched gimp so that it looks only for scalable font (aka > postscript and ttf) and everything just operates smoothly. Why do you need to patch the gimp to do this? If you click on the "Filter" pane of the text tool, you can de-select the Font Types "Bitmap" and "Scaled Bitmap", leaving only "Scalable" selected. This should then show you only scalable fonts. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fix for the gif plugin.
On Sunday, 9 Sep 2001, David Odin wrote: > I've two question about this plugin: >- why gifload and gif are kept separated, when, for most image > formats, the loader and the saver is in the same plugin? Patent reasons: you need a Unisys LZW compression patent licence in order to use the gif save plugin, whereas gifloader doesn't need you to have a patent licence. Since most people don't have an LZW compression licence they aren't allowed to use the saver but everyone is allowed to use the loader. Hence they are separate plugins so you can choose to install both if you possess a licence, but only the loader if you don't. Of course, we can't stop you using the saver gif plugin illegally (ie without a licence), but then that's your own problem, not ours. >- the code of gif.c looks unmaintained, and rather dirty (lots of > code commented out, define for "FACEHUGGERS", no real copyright > notice, etc.) Who is the current maintainer? It is maintained (and fairly regularly), by Adam Moss. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Auto save?
On Tuesday, 7 Aug 2001, Michael Soibelman wrote: > Well, one of those plug in crashes and it's all gone. ??? Please let us know which plugin crashing causes the entire GIMP to crash. This is a very serious bug. The whole point of plugins is exactly to isolate the main GIMP program from crashing plugins. If a plugin crashes and takes out the main program then we may as well not have bothered. I repeat: if a plugin crashes and kills the main gimp program, *please* file a bug report! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
On Tuesday, 7 Aug 2001, Raphael Quinet wrote: > 4) Feedback > > Any comments? Seems plausible. I say go for it. Another alternative would be for file plugins to offer two APIs - the traditional one and for plugins that can deal with multiple internal files (eg FlashPix, multi-page TIFF, + all your examples) the new API could be offered as well. No too sure of the details here; more thought required. The problem might be with existing file loader plugins that no-one feels like modifying, or that are binary-only. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
On , 27 Jul 2001, Sven Neumann wrote: > ftp://ftp.gimp.org/pub/gimp/v1.2/v1.2.2/ > > This release fixes a large bunch of bugs, adds a couple of > new translations and features a complete rewrite of the > help pages. Oops. It doesn't build out of the box. D'oh!!! [...] creating libcolorsel_water.la (cd .libs && rm -f libcolorsel_water.la && ln -s ../libcolorsel_water.la libcolorsel_water.la) make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/modules' Making all in po make[2]: Entering directory `/local/scratch/and1000/gimp/gimp-1.2.2/po' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po' Making all in po-libgimp make[2]: Entering directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-libgimp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-libgimp' Making all in po-plug-ins make[2]: Entering directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-plug-ins' file=./`echo lt | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH -o $file lt.po /bin/sh: -o: command not found make[2]: *** [lt.gmo] Error 127 make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-plug-ins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2' make: *** [all-recursive-am] Error 2 It looks like something involved in making po files isn't present on my system and the makefiles or configure etc isn't coping. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lines of code in the Gimp
On Thursday, 21 Jun 2001, Raphael Quinet wrote: > It is also interesting to see that the number of lines of code has > doubled from 1.0.4 to 1.2.1. I think 1.2.1 comes with many more plugins as standard. It would be interesting to see where all these new lines of code come from! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] handling of image comments (was 1.2 Bug Hunting)
On Wednesday, 20 Jun 2001, Raphael Quinet wrote: > On Wed, 20 Jun 2001, Sven Neumann wrote: > > If we'd fix this by making gimp_image_new() attach a default comment > > parasite (just like it sets the default resolution), all images touched > > by The GIMP would get the default comment unless they already have a > > comment and the respective load plug-in takes care of setting it as a > > parasite. I originally held this view. However Raphael makes a persuasive argument why this is a bad idea and I now agree with him. Only images actually generated by the Gimp should have the default comment added. I agree the image properties editor plugin is badly needed. > The best way to solve this would > be the following: > - the image comment is never set when creating or loading an image, >except if one was already present in the file > - in all save plug-ins, add an option "replace current comment with >default comment" (this assumes that the plug-ins get it from gimprc). Yes. Although I'm not entirely happy about cluttering every save plugin with an extra comment-related box, I can't think of a better way of doing it. > It would also be nice to add the following multiple choice in the > preferences dialog, on the same page as the one in which you set the > default comment: >[ ] do not modify or add image comments >[x] add the default comment to the images that have no comment yet >[ ] always replace the existing comment with the default one Yes. > [Should New, Screenshot, Paste as New get comments be default? Quinet > says no, only add comment at save time.] I think they should get the comment added when the image is created. I know this means if the user changes the preferences before saving then its not entirely obvious what happens, but I think this should be a rare occurence. All this discussion means that I don't think anything should be done to 1.2 Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On Wednesday, 20 Jun 2001, Iccii wrote: > I'm using the GIMP to creat image files for my web site. > So, I want to know how much time is necessary for loading > the images which is saved by jpeg or other file type. > It's useful to show loading time in jpeg saving dialog. > See attachment file if you interested in it. Its a nice patch. I think it should get into the development CVS tree (but probably not the 1.2 stable branch, since this is definitely a new feature). Just one thing: 14.4Kbps means 14.4 * 1000 bits per second, not 14.4 * 1024. Similarly, 10Mbps is 10 * 1000 * 1000 bits per second, not 10 * 1024 * 1024. 1024 is only involved when addresses are, ie for sizes of buffers, memory, files. Never when talking about bandwidth. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
On Wednesday, 20 Jun 2001, Dave Neary wrote: > The default "Made with the GIMP" comment is hard coded into > plug-ins/common/xbm.c - and presumably into the others too. It seems to > me that the easiest solution would be to include gtkrc in the relevant > plug-ins, and do a read on the gimprc when loading the plug-ins. No. These plugins are sufficiently old that they pre-date parasites. The correct thing to do is ensure that images have the right "gimp-comment" parasite, and make all the plugins looks at it. In the same way as freshly created images are defaulted to 72 dpi, maybe they should also have a "gimp-comment" parasite added. File load plugins would then just override the parasite if the file format includes a more specific parasite. I believe current file load plugins than know about parasites wouldn't need modification. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Big Fat Piggy Gimp
Layer deletes are a little funky: they don't get deleted when they are removed from the layer list, since they get pushed on the undo stack. They get deleted when the undo information is freed, ie when it expires or when it is on the redo stack and an new action is pushed on the undo stack, thus blowing the redo stack. Messing with reference counts might be an attempt to achieve this; I don't know. It's worth checking, if only to discount it. I also think such messing is really ugly, and as we're discovering, totally unmaintainable. Fixing a leak of this magnitude is definitely cause for another stable release, I think. It goes without saying that it should be widely and thoroughly tested, possibly by a 1.2.2alpha pre-release snapshot or something. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
On Friday, 8 Jun 2001, David Monniaux wrote: > On Fri, 8 Jun 2001, Austin Donnelly wrote: > > > But, we're talking about *paper* here. A4 for me is the same size as > > A4 for another user, surely? There are only a limited number of paper > > sizes in existence, and they should all be available system-wide. > > That's not true. Users have things like "that fancy letter paper that I > buy at Flammarion", which have weird sizes. They have stickers, envelopes, > and other things on which they want to draw logos. Ok, fair enough. But even these fancy letter papers are standard sizes, otherwise they wouldn't fit on standard sized envelopes. > The paradigm could also encompass screen dimensions, like "16x16 icon" or > "advertisement bar at top of MyStartup.com". Good idea. Note that banner ads are also standard sizes, though. > Why then do we have a per-user unitrc? I'm not sure unitrc is a good example. Again, it's something that could easily be system-wide, not per user. Gimp already has quite a bit of infrastructure for per-user settings, so its easier to do things this way. Maybe a sensible set of system defaults and allowing users to override them on the (very) rare occasions they need to. Robert's point about printable area differing from printer to printer is interesting; I hadn't considered that. It depends what you want to use the paper size for, I suppose. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
On Friday, 8 Jun 2001, David Monniaux wrote: > I've been trying to contact libpaper's author, but to no avail so far. > > libpaper is old (1996) and does not offer per-user paper formats. > Furthermore it does not allow interactive modifications. But, we're talking about *paper* here. A4 for me is the same size as A4 for another user, surely? There are only a limited number of paper sizes in existence, and they should all be available system-wide. Maybe I don't really understand what you're trying to do. The PostScript Red Book has a section on media selection which describes how a PostScript interpreter picks the paper size/color/headed to print on. It might be useful. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] adding a tool
On , 7 Jun 2001, Sven Neumann wrote: > Jonas Geduldig <[EMAIL PROTECTED]> writes: > > I'm interested in adding a tool for detecting and > > cutting out contour regions. > > Intelligent Scissors ?! Yup, this sounds a lot like intelligent scissors. Read the comments at the top of app/iscissors.c I think I was the last person to go in there. There are still a few things that could be tidied up, eg getting the convolutions to work correctly near tile boundaries. Austin ___ 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
On , 6 Jun 2001, Sven Neumann wrote: > Avi Bercovich <[EMAIL PROTECTED]> writes: > > > As ever I;m not quite sure where I go to post bug reports, so I;m > > posting to the list. > > http://bugzilla.gnome.org/ is the right place. Your bug-report has > been entered into the database and I have forwarded your mail to > Adam asking him to have a look. > > Argh, I knew the heavy usage of g_assert() in the convert code would > bite us some day. ??? Its doing exactly the job its meant to do! Would you rather the code continued, using some invalid assumption, to either crash bizarrely later or come out with artifacts in the image? You can argue that maybe it should have been a g_return_if_fail() or similar, but knowing about bugs early is useful. Besides, aren't stable releases built with assertions and g_return_if_fail compiled out? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shrunk display
On Friday, 1 Jun 2001, David Monniaux wrote: > I would like to know the precise functions that handle the shrinking of > the image for display. I would like to code them in MMX. What leads you to suspect that scaling the image for display is a bottleneck? Last time I looked, it was much higher-level stuff that was making the Gimp slow. Eg, repainting the canvas several times when once would have been enough. The next culprit was the functions involved in applying paint strokes, merging in the existing paint with the new paint. But these have already been tuned quite a bit (by Jay Cox, if I remember correctly?) So, rewriting the display code in MMX is pretty pointless if you're looking to speed up the Gimp. If you're doing it to educate yourself about MMX it might be interesting, I grant you. An MMX rewrite also has numerous disadvantages. You'd still need to keep a C version lying around so that non-Intel platforms can work. So that means you now have two pieces of code floating around which should do the same thing, and need to be kept in step with each other. This is a maintenance nightmare. Now instead of needing to know just C, maintainers need to know both C and Intel MMX assembly. This instantly reduces the number of people who can help fix bugs. Also, bug reports are complicated by the fact that now display-related bugs need to say which architecture it was on. Given the typically low quality of bug reports (eg "it shows me a garbled image") even just finding out the architecture is quite hard. Re-writing the C to use a better algorithm, or tuning it to place variable in better locations on the stack, would be a much preferable solution. That way the algorithm is still just C. For example, the algorithm currently uses an integer fixed-point approximation to keep track of the render error. Originally I coded it up using floating point, but it was slightly slower in the subsequent testing I did, so I re-coded it in fixed point. I tested on a Pentium 133 and an Alpha 21064, and both came ahead using the integer fixed-point algorithm. Maybe that trade off is different with today's common CPUs, I haven't looked into it recently. I suggest you read "The Practice of Programming" by Brian W. Kernighan, Rob Pike. Addison-Wesley, 1999 ISBN: 020161586X. In particular, I'm thinking of the chapter on performance tuning. In summary: find out where the bottleneck actually is (by profiling) before jumping in and micro-optimising the wrong thing. To answer your original question, the display code is in app/image_render.c Note that not all the render functions were reachable last time I looked at the code in detail. This is in 1.2.1. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Convolution in the Gimp core
On Sunday, 8 Apr 2001, Ernst Lippe wrote: > Austin Donnelly wrote: > > Actually, the core could do with a tile convolution, since currently > > it copies data into a tempbuf before convolving it. This makes some > > tools more effificient (or incorrect) eg iscissors. > > I'd love to see convolution in the Gimp core. We already have convolution code in the core. However, it uses the copying technique, and doesn't deal with tile boundaries at all (much less image boundaries). I do think a proper tile-based convolver is needed, and I think the developers would support such a move. Unfortunately, I don't have the time to co-ordinate this :( > I am willing to do a large part of the coding, but only when there is > enough support for this issue from the "core" Gimp developers. I think there is support. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...
On Friday, 6 Apr 2001, Ernst Lippe wrote: > Sometime ago I wrote a piece of code that can handle neighborhoods > without fetching tiles twice. I needed this because I was applying > convolutions where I needed a neighborhood of say 20x20. Basically what > my code does is maintain a buffer that holds two rows of tiles plus some > extra for the vertical neighborhood. It handles those nasty details like > adding borders and fetching tiles. It works for my plugin but it must > still be documented and some missing features must still be implemented. > There are several filters where it could potentially be used, so if > anyone is interested I could try to clean it up. Actually, the core could do with a tile convolution, since currently it copies data into a tempbuf before convolving it. This makes some tools more effificient (or incorrect) eg iscissors. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...
Oops - I missed out some vital pixel region initialisation.
On Friday, 6 Apr 2001, Austin Donnelly wrote:
> gimp_drawable_mask_bounds (drawable->id, &x1, &y1, &x2, &y2);
>
> for (y = y1; y < y2; y += tile_width - (y % tile_width))
> {
> for (x = x1; x < x2; x += tile_width - (x % tile_width))
> {
/* set up the source and dest regions */
gimp_pixel_rgn_init (&src_rgn, drawable, x, y, x_step, y_step,
FALSE/*dirty*/, FALSE/*shadow*/);
gimp_pixel_rgn_init (&dest_rgn, drawable, x, y, x_step, y_step,
TRUE/*dirty*/, TRUE/*shadow*/);
> /* process the image in tile-sized regions */
> for (pr = gimp_pixel_rgns_register (2, &src_rgn, &dest_rgn);
>pr != NULL;
>pr = gimp_pixel_rgns_process (pr))
> {
> src_row = src_rgn.data;
> dest_row = dest_rgn.data;
>
> for (row = 0; row < src_rgn.h; row++)
> {
> src = src_row;
> dest = dest_row;
>
> for (col = 0; col < src_rgn.w; col++)
> {
>
> /* do stuff with src[0..bpp] and dest[0..bpp] */
>
> src += src_rgn.bpp;
> dest += dest_rgn.bpp;
> }
>
> src_row += src_rgn.rowstride;
> dest_row += dest_rgn.rowstride;
> }
> }
> }
> }
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...
On Thursday, 5 Apr 2001, Georg Acher wrote:
> I just looked into bumpmap.c and tried to figure out if it can profit from
> blocking and played a bit with the code. It seems that there is some major
> (performance) problem with the gimp_pixel_rgn_get/set_row-calls in Gimp
> 1.2.1.
>
> The original bumpmap took for my 1400*1400 image about 30s, when I commented
> out one of the gimp_pixel_rgn_get/set_row() that access the source or the
> destination image, the whole stuff took only about 2.4s, while the
> calculations were still done!
>
> I experimented a bit, and found out, that apparently the "switch" between
> get and set seems to be the problem. I changed the code to get 32 rows,
> calculate them and the write the 32 back. It took only 3s overall, the
> resulting image is the same as with the 30s boiling time.
Have a look at the gimp_pixel_rgns_register() and
gimp_pixel_rgns_process() functions. They do similar blocking on a
per-tile basis.
Most plugins should be using them, but ones with more complex access
patterns (eg accessing pixels across tile boundaries) probably won't.'
Typical use is something like this:
gimp_drawable_mask_bounds (drawable->id, &x1, &y1, &x2, &y2);
for (y = y1; y < y2; y += tile_width - (y % tile_width))
{
for (x = x1; x < x2; x += tile_width - (x % tile_width))
{
/* process the image in tile-sized regions */
for (pr = gimp_pixel_rgns_register (2, &src_rgn, &dest_rgn);
pr != NULL;
pr = gimp_pixel_rgns_process (pr))
{
src_row = src_rgn.data;
dest_row = dest_rgn.data;
for (row = 0; row < src_rgn.h; row++)
{
src = src_row;
dest = dest_row;
for (col = 0; col < src_rgn.w; col++)
{
/* do stuff with src[0..bpp] and dest[0..bpp] */
src += src_rgn.bpp;
dest += dest_rgn.bpp;
}
src_row += src_rgn.rowstride;
dest_row += dest_rgn.rowstride;
}
}
}
}
Of course this precise form will only work where there's a one-to-one
correspondence between input and output pixels. I suspect whirl-pinch
has more complex access patterns, in which case you'll need to be more
creative with the loop structure.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scaling of work images in late gimp's.
On , 2 Apr 2001, Gene Heskett wrote: > out is that the work screens default render is now set to a 50% > scaledown. > > For what little work I do, this isn't desirable. Loading the same pix > into gimp and scaling it back to to 100%, then compareing the same pix > loaded into EE makes gimp look pretty bad. I don't really understand what your saying here. There are two issues you mention, which aren't terribly related: 1) the default scale factor This is automatically decided so as to ensure the image fits on the screen. If you load a big file, then it will be < 100%. If you load a small file, it will be 100%. Is this not happening for you? 2) rendering faithfulness Gimp used GdkRGB to reproduce colours, and I've always been very happy with the results. In what way does EE make gimp look "bad"? Are there jaggy edges? Pixelation? Colour casts? Scaling artefacts? What do you mean by "bad"? Maybe you could post a (small!) screen shot showing us both gimp and EE viewing the same image, for comparison purposes? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: couple possible TODO items
On Friday, 30 Mar 2001, Nick Lamb wrote: > On Fri, Mar 30, 2001 at 10:56:32AM +0100, Austin Donnelly wrote: > > I really don't see what's wrong with using a ruler. The CD idea is > > cute, I have to agree. > > There is a tiny problem. I can hold the ruler _near_ my screen but I > cannot use it to measure the screen because it is too big and won't > touch the surface. > > So now I have to look for _another_ ruler. We could mandate that all > Gimp users buy 19" monitors? My original "stretchable" ruler idea gets around this, because you the user chooses how much to measure and line up. Possibly as little as 1" if you want. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: couple possible TODO items
On Friday, 30 Mar 2001, Zachary Beane wrote: > However, even if the consensus is "just get a ruler", I think the > current measurement dialog could be improved with a user interface of > "stretch the virtual to fit the physical," rather than the current > setup. Yes: that was always my original idea. Only, I never had the time to code it up. Thanks are due to Mitch and Sven who actually got their hands dirty and did something, otherwise we would have nothing. And what we have is definitely better than nothing. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: couple possible TODO items
On Thursday, 29 Mar 2001, Jason Maskell wrote: > I don't own a ruler. I don't know many people who are not in school who do. > Tape measure maybe.. Ruler, what for? Surely anyone doing graphics work to fit a specific size will need a ruler to check any printed drafts etc, though? I really don't see what's wrong with using a ruler. The CD idea is cute, I have to agree. While there is a standard size from credit cards, some id/membership cards that claim to be the standard size aren't. I've discovered this by attempting to stuff them into a card wallet, and them not fitting. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SIOD error codes
On Tuesday, 27 Mar 2001, Simon Budig wrote: > Jason Maskell ([EMAIL PROTECTED]) wrote: > > ERROR: wta to car (errorobj 123324) - Ok, the 123324 is one of my arguments, > > but is the error message supposed to be in English? > > I am not sure, what exactly "wta" stands for, but at a first glance > I'd say, that you try to do something like (car 123324), but car > is only possible on lists and cons. At a guess, wta means "wrong type for argument" I agree the message is pretty useless: you need to know what it means before you can understand it :) Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What to do if gimp should run some other commands before and/or after launching a plugin like xsane??
On Friday, 23 Mar 2001, Christoph =?ISO-8859-1?Q?Hinterm=FCller?= wrote: > I do have a question about running or better lounching plugins: > > how can i get gimp to run some extra commands before and/or > after launching a plugin like xsane. > eg: a command which tries to activate scanner on scsi bus before > calling xsane > and > a command deactivating it again after xsane was closed again > But is schould not happen when gimps starts, as it is not > necessaryliy that > eg the scanner is turend on at that time. > And eg the scanner might be turned off again before gimp finishes :( I would rename xsane to xsane.real and replace it with a shell script wrapper which does something like: #!/bin/sh set -e /usr/local/lib/xsane/xsane-startup xsane.real "$@" /usr/local/lib/xsane/xsane-shutdown No gimp hackery required. The two scripts xsane-startup and xsane-shutdown can contain whatever commands are needed to initialise and turn off your scanner etc. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug in Sobel edge detect?
On Saturday, 10 Mar 2001, Lourens Veen wrote:
> When running the Sobel edge detect on an image without a selection, the
> topmost scanline of the output is random garbage. From a very quick
> glance at the source it seems that the previous row array isn't
> initialised
Thanks for the good bug report.
It is initialised, but by passing the bogus argument -1 as a y-coord
to the pixel region function, so there's garbage returned.
Here's a patch that fixes this, relative to the sobel.c that's in
1.2.1. Can someone stick this in stable CVS and also merge it with the
current development head. Thanks!
Austin
--- sobel.c~Tue Aug 22 02:26:56 2000
+++ sobel.c Sun Mar 11 14:08:36 2001
@@ -312,10 +312,10 @@
{
gint b;
- if (y == 0)
-gimp_pixel_rgn_get_row (pixel_rgn, data, x, (y + 1), w);
- else if (y == pixel_rgn->h)
-gimp_pixel_rgn_get_row (pixel_rgn, data, x, (y - 1), w);
+ if (y < 0)
+gimp_pixel_rgn_get_row (pixel_rgn, data, x, 0, w);
+ else if (y >= pixel_rgn->h)
+gimp_pixel_rgn_get_row (pixel_rgn, data, x, pixel_rgn->h - 1, w);
else
gimp_pixel_rgn_get_row (pixel_rgn, data, x, y, w);
@@ -384,6 +384,7 @@
sobel_prepare_row (&srcPR, pr, x1, y1 - 1, (x2 - x1));
sobel_prepare_row (&srcPR, cr, x1, y1, (x2 - x1));
+
counter =0;
/* loop through the rows, applying the sobel convolution */
for (row = y1; row < y2; row++)
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Not happens gimp color pictures !!!
On Sunday, 4 Mar 2001, Raimo Leppanen wrote: > gimp-1.125-1 Please upgrade to gimp-1.2.1 and see if the problem still happens. Are you loading a JPEG file? Do other programs display the file correctly? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Friday, 23 Feb 2001, Nick Lamb wrote: > If we can get back COW during 1.3 this overhead is zero (all new > channels / layers etc. can be created as COW tiles with the > apppropriate contents -- huge speedup). > > I believe COW was lost because there were problems making it stable > with all the spaghetti in 1.1.x, but presumably as we wipe out the > worst of the spaghetti we should be able to bring it back, no? I thought 1.2.x shipped with COW still enabled? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [gimp-devel] [Gimp-developer] preview icons
On , 22 Feb 2001, Sven Neumann wrote: > But most (all?) window managers scale them down to a tiny 16x16. Not mine: fvwm 1.24r > IMO the whole thing should go away, but if people like it, please make a > preferences option to enable it. I think it's a good idea. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-print-devel] Re: [Gimp-developer] What's going on in gimp-print land
On Wednesday, 21 Feb 2001, Roger Leigh wrote: > [sensible things] That sounds pretty sane. I expect that Debian (and other distributions) will ship a copy of the print plugin and the relevant shared library as separate packages, with appropriate dependencies between them. This means that the only people who will have a statically linked print plugin will be those who build and install from source - ie those on weird architectures, or testing non-standard stuff. This seems to cover the cases correctly, in my view. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What's going on in gimp-print land
On Tuesday, 20 Feb 2001, Robert L Krawitz wrote: >Date: Tue, 20 Feb 2001 10:30:56 + >From: Austin Donnelly <[EMAIL PROTECTED]> > >I think the easiest thing is to have the version in CVS (and gimp >snapshots) to include the code for the shared library, and an >integrated build system. I'd even go so far to say that the plugin >should be statically linked against the library, to avoid version >skew if the user installs a different version of the shlib later. > > This sounds like you're suggesting that we split out libgimpprint and > the clients into separate packages. Yes. > This would total four (libgimpprint and associated tests, the > plugin, the CUPS driver, and the Ghostscript driver), plus possibly > other packages for things like Debian and RPM packaging. Well, maybe just 3: libgimpprint print plugin (both of these manually imported to gimp cvs) CPUS + Ghostscript drivers Does the Debian maintainer have any comments how he/she would like to see it packaged? > I presume you'd want to pick up libgimpprint and the plugin, without > the CUPS and Ghostscript drivers. Yup. > We're working library version skew issues (Roger has architected and > done an initial implementation), although there is something to be > said for building it statically within the Gimp context. Well, one less shared library for users to forget to install properly, so yes :) Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What's going on in gimp-print land
On Saturday, 17 Feb 2001, Robert L Krawitz wrote: > This raises questions of how to package it with the > Gimp. The Gimp could certainly distribute the whole package with it, > but it's quite large. It could also be treated like JPEG and only > built if the underlying libgimpprint exists on the system. > Suggestions? I'm not convinced that treating it like JPEG is a good idea, because the library is not (yet) as widely spread as libjpeg is. Even today, I sometimes have to fight quite hard to get jpeg or tiff plugins to build for strange architectures. Doing the same for the print plugin would mean that fewer people build and install it, which would be a shame, since it provides some very useful functionality. I think the easiest thing is to have the version in CVS (and gimp snapshots) to include the code for the shared library, and an integrated build system. I'd even go so far to say that the plugin should be statically linked against the library, to avoid version skew if the user installs a different version of the shlib later. Also, the shared library should be available (on sourceforge?) separately packaged for the CUPS, ghostview etc people. Distributions like Debian etc can then put the library in its own package and do their own dependency thing, but we don't have that luxury, I'm afraid. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimptool fix (reposted)
On Monday, 19 Feb 2001, Roger Leigh wrote: > I mailed this patch to the list a few weeks ago, but it was ignored. Your patch sounds useful, and I think it should probably be applied. However, it seems that everyone is busy right now. Thanks for persisting! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
