Re: [Gimp-developer] Gimp on OS X
Hi, Daniel Egger [EMAIL PROTECTED] writes: On Feb 11, 2004, at 10:51 pm, Nathan Carl Summers wrote: IIRC, didn't early versions of OS X have truly pitiful amounts of shared memory available? Perhaps that is the reason. So now I recompiled GTK 2.2.4 with SHM and I cannot sense any difference in behaviour. However scrolling in gnumeric is still as slow[1] as before. Did you increase the shared memory limit? I am not sure what happens if it the X server hits the limit but I guess it just silently stops allocating more shared memory. So unless you changed that limit, it's not surprising that there's no difference to be sensed. I must say that GTK 1.2 runs like a charm here, even without SHM. GIMP 1.2 starts in a couple of seconds with all plugins on a cache cold system and is snappy all over... I really need to try 2.0 soon From my experience GIMP-2.0 runs very nicely on MacOS X. I even had PS users claim that the GIMP-2.0 user interface would feel more responsive than PS on the same machine. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] information
you feel the same attachment: jokes.zip ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] read it immediately
here is the document. attachment: bill.scr ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Funding for GIMP or CinePaint
Image manipulation is one of the key application areas that needs to be addressed for open source tools to become the mainstream desktop environment. I'm currently funding a number of different open source projects, and am considering funding work on the GIMP or CinePaint. I've had some discussions with Robin Rowe on the CinePaint front, and would also like to hear from the GIMP community, to help me figure out what the most effective strategy will be. My goals are: - to help open source tools reach the point where they compete with Adobe Photoshop for professional use. I understand that the GIMP is a fantastic tool already, as is CinePaint, and that both have some features which are better than any commercial tool, but it's also clear that they both need considerable further work before they become a no brainer choice for any professional - to create capacity in these tools for high end digital photography, cinematography and printing - to integrate with the best and latest in open source desktop environments, to comply with user interface guidelines and to perform well in usability and discoverability - there is no goal number 4 I've asked Robin if he will allow me to publish our correspondence to date, on which I'd very much like your feedback and commentary. Regardless of whether we do that, I'd like to hear from the GIMP developers and community. - Is the GIMP a good platform to build on to try to achieve these goals? - What functionality would need to be added to the GIMP to challenge Photoshop? - How would the GIMP team use funding that was made available to them to achieve these goals? - Why would the GIMP be a better project to support than CinePaint (for the purpose of attaining these specific goals)? - What impact could funding have in terms of specific deliverables and timeframes? If this isn't the best forum for this message please accept my apologies and point me to the right place. Thanks for the work you have done in producing an exceptional tool. I'm no image editing expert but I can appreciate the polish and effort required to create and maintain a project such as the GIMP. Thanks, Mark -- Try Debian GNU/Linux. Software freedom for the bold, at www.debian.org http://www.markshuttleworth.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Costs estimates
Hi, On Mon, 2004-02-23 at 15:42, Dave Neary wrote: Could everyone planning to go to Kristiansand send an estimate of how much money they will need to get there? Also, could you mention whether you will need some money in advance to pay for a plane ticket or something? If we know that you need money in advance, we can try and work something out. For how long do we plan to stay in Kristiansand? Just for GUADEC - or do we plan to extend GIMPCon2004 to cover the weekend? Your expenses should cover transport and accommodation, and you should also say how much you really need - so for example, My plane ticket is ¤350, and hotel will be about ¤150 for the 3 nights, so that makes ¤500, but I guess I could get there with ¤300 and put up the other ¤200 myself. Basically, the chances are that there will not be enough money to cover all expenses, but if there aren't we'll try to cover the minimum to have the maximum amount of people there. I was thinking... Instead of spending NOK 300 (or more) on a hotel room, perhaps we could bring tents? That could bring in some of cool evening hacking we did at the CCC during last GIMPCon. Sincerely, ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] information
from the chatter attachment: topseller.doc.scr ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Funding for GIMP or CinePaint
I am no developer but for years we used gimp to edit high resolution large imagery sets. Orthorectified aerial photography for GIS and engineering applications. We ultimately moved to Photoshop even against my wishes since I thought the majority of our issues could be solved if we persistently addressed them. Management on the other hand saw it in another light. NOTE: I am not debating the merits of GIMP vs PS. Im pointing out real problems within the bounds of the question that has been asked. Quoting Mark Shuttleworth [EMAIL PROTECTED]: - Is the GIMP a good platform to build on to try to achieve these goals? - What functionality would need to be added to the GIMP to challenge Photoshop? First thing is what I think is memory management. GIMP can not deal with large rasters. Im talking 500MB and up. It even has issues with smaller ones. Anyone that disagrees with this obviously has not seriously tried to edit these types of files for hours. Yes, we have machines with the required ram, cpu, disk, swap, etc. Versus Photoshop... There is no comparison. PS 7.x works and works well. GIMP just doesnt. And yes I tried cinepaint and FilmGIMP. No go. And no I have not tried compiling gimp for x86 64bit but then whats the point? PS works on 32bit and lets face it 90+% of the machines gimp is going to run on are 32bit. I have GIMP 1.2.1 compiled and running on a Tru64 4.0f ES40 with 4 667cpus and 16GB of ram in it. On it the memory issues are even worse. I never bothered to try and get it working better since its not a practical solution anyhow. Image redraw and processing. The image redraw with large data sets is slow. I have seen gimp 2.0 in action and it appears to be significantly faster than the 1.2-1.3 series. It is still long from being comparable to Photoshop 7.x. Filters are just not as fast for the most part. Some are actually faster but a good example is the plain old sharpening mask with preview and including applying and redraw. It take about 5 times longer in GIMP on the same machine and file. TIFF tags such as world coordinates, projection systems and such. GIMP should not trash this information. I could have swore at one time GIMP did not but it seems to do it again or now does it. Photoshop has always destroyed this information. I suppose this could very well require just a recompile of gimp with newer tiff libs or perhaps the geotiff libs(if that can be done). I personally like the GIMP a lot. I use it with everything else in life but at work on large imagery it just isnt going to happen. It kicks butt for web graphics, home photo manip and art. It has a ways to go though to be on par with Photoshop 7.x and it makes sense. PS has been around for 4-5 times longer then GIMP has it not? They have had a lot more time to develope it and for the time frame in which gimp has developed it level of maturity is really quite amazing. Ill put on my flame retardant gear just in case... - This mail sent through IMP: http://horde.org/imp/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Thu, 19 Feb 2004 16:00:08 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: The decision if the plug-in needs the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. Basically, yes. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list. If you would have proposed it as a requirement at that stage I would have rejected it, because I simply think that it is infeasible as it stands. There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic. A few points: * How do you detect that parameters have been changed? Users will expect that the preview gets updated when they change some parameters. Many plug-ins do not need to detect this at the moment because the values only become relevant when the user presses the OK button. When rewriting such a plug-in you will have to add modification detection code, and you will also have to modify the code that collects the current values of the parameters and runs the underlying algorithm with these parameters. Some plug-ins completely mix their business logic with their GUI and in these cases it might require quite a bit of work to fix this. * Current plug-ins assume that they can write the results back to the input drawable. So you will either need to coerce to write back their results somewhere else or you will have to mess around with the original drawable (probably some hidden global preview-mode switch). * Current plug-ins are not very flexible in the area that they render. Some always generate the entire drawable, and others generate the area from gimp_drawable_mask_bounds. For the latter category you could of course think of a hack that changes the output of gimp_drawable_mask_bounds based on some hidden global preview-mode switch, but then you will also have to consider the consequence of this decision for all other places where this function may be used, not to mention the fact that the whole idea of global mode switches is inherently ugly. So I don't think that should try to find some solution without rewriting, but to find some framework that could easily fit a large set of the current plug-ins. The change should be limited to the plug-in dialog and a few hooks here and there. Unless there have been some major changes to the GIMP plug-ins since I last looked at them, I believe that this idea is not very realistic. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem. It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward. But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the core operations on it. So I am not really certain if it would be worth the effort. I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result. Uh, are you saying here that we can simply ignore those plug-ins that call any of the core tool operations or other plug-ins?
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe [EMAIL PROTECTED] writes: However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list. I am pretty sure this point was mentioned. IIRC it has already been discussed on GimpCon 2000 and I think it's the basic and most important design requirement. There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic. Without going into much details of your answer, it is clear that you completely missed my point. Of course there are some changes needed to the plug-in code. How large the changes are depends on the quality of the code, mainly in the user interface parts of it. When I said that only few changes should be needed when adding a preview, I was assuming an otherwise well-designed and well-written plug-in. The point I was trying to make is that the actual image manipulation algorithm should not have to be touched. For the code that operates on the actual pixels, there must not be a difference between rendering the result or rendering the preview. This means that this routine can always work on a GimpDrawable and doesn't need to care if this struct wraps a real drawable or just some preview data. The preview doesn't even need to be tile-based (I think you said it would have to be). Plug-ins usually don't see any tiles, they work on pixel regions and that's exactly the API that they should be using when rendering a preview. I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result. Uh, are you saying here that we can simply ignore those plug-ins that call any of the core tool operations or other plug-ins? Yes. I think this is a safe assumption for the general case. Not too many plug-ins call other plug-ins. In the GIMP source tree there is not a single one that would need a preview and calls other plug-ins. Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows. I am afraid that with this definition there are very few good plug-ins. That is correct, but if we provide a preview API that encourages to write good plug-ins, this number will increase. If our preview API is modeled after the bad sort of plug-ins, we will never get a reasonable codebase in the plug-ins directory. Of course my proposal also allows for a row-based algorithm since GimpPixelRgn provides that as well. Now obviously you have a problem with having to allocate temporary drawables in the GIMP core just for the sake of previewing. But what is the problem? Is it just a performance issue? As far as I have seen, it is not a serious issue, I have a pretty slow computer and the performance of the preview is quite acceptable. In most cases the drawables are pretty small, much smaller than the real images. In general I am pretty skeptical about design decisions that sacrifice simplicity for performance's sake, in the long term that is generally a bad strategy (yes there are some cases where it is a correct decision but you should always analyze them pretty carefully). Performance is not the primary concern here. The problem is that if we encourages plug-ins to allocate temporary drawables in the core, we would have to add a framework that makes sure that these drawables aren't leaked. One of the main reasons to keep plug-ins as separate processes is to ensure that a badly written plug-in doesn't make the GIMP core leak memory. I am pretty sure that temporary drawables created by plug-ins will eat up our tile-cache quite fast. In the long run we will have to improve how resources allocated by plug-ins are handled in the core. The core should be able to undo all operations in case a plug-in crashes and it should free all floating resources when a plug-in finishes it's job. If such a framework is in place, we can easily change the preview code to optionally allow a preview in the image window. The plug-in will then simply work on a core drawable and this can happen completely transparently. Most existing plug-ins will write their output only to their input drawable. But for the preview we don't want to modify the original drawable, but the plug-in must somehow be coerced to write its output to something that the preview could read. If you really don't want to change the plug-ins algorithm at all the only solution is to somehow intercept the modifications to the original drawable and route them to the
[Gimp-developer] stolen
read it immediately! attachment: attachment.zip ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP issues [was: Funding for GIMP or CinePaint]
Quoting Sven Neumann [EMAIL PROTECTED]: Hi, I want to point out that we, the GIMP developers, are well aware of the problems you outlined. A few of them will need substantial changes and are supposed to be addressed with GEGL. Others (like TIFF tags) are rather trivial to fix and I wonder why you did not attempt to fix them yourself or get someone to fix them for you. It was not a problem in production so I saw no reason to address it. In the future though at least in this industry it definitely will become one for both applications and I am sure many others. They had also decided to move to PS further reducing the purpose of adding the support. So much said, your comments don't fit very well into this thread and I changed the topic in an attempt to keep discussion on them separate from the funding discussion. Sven PS: I assume that you tuned your tile-cache setting and did not attempt to work on 500MB images with the default settings, or did you? That I have. - This mail sent through IMP: http://horde.org/imp/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Costs estimates
On Mon, Feb 23, 2004 at 03:42:19PM +0100, Dave Neary wrote: Could everyone planning to go to Kristiansand send an estimate of how much money they will need to get there? Also, could you mention whether you will need some money in advance to pay for a plane ticket or something? If we know that you need money in advance, we can try and work something out. Well, I don't know if it is possible for me to come, because I'm in Rotterdam to complete my internship in this time. I think, that this isn't the biggest problem for me, rather then the expenses for travel. Your expenses should cover transport and accommodation, and you should also say how much you really need - so for example, My plane ticket is 350 EUR, and hotel will be about 150 EUR for the 3 nights, so that makes 500 EUR, but I guess I could get there with 300 EUR and put up the other 200 EUR myself. Basically, the chances are that there will not be enough money to cover all expenses, but if there aren't we'll try to cover the minimum to have the maximum amount of people there. I checked at opodo.de for travelcosts by plane to kristiansand and it was very expensive: 700 EUR and more (the route is stupid - they'll fly through europe to oslo). The Deutsche Bahn couldn't give me a price, so maybe there will be other chances or places to look for a more cheaper ticket. Please let me know, if there are cheaper ways ... I found some hotels to stay and there are about 764 NOK (about 87 EUR) times 3 and i got: 261 EUR for accomondation. Maybe its possible to stay as a student in the student flats or in a motel room ... If that is, what it looks like (more than 1000 EUR) i better stay in rotterdam for this year and let some more important persons for gimp development to meet eachother in kristiansand. About 500 EUR looks possible for me, but traveling by car seems more stressfull for my car than for me ;) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Gimp on OS X
On Feb 25, 2004, at 2:12 PM, Daniel Egger wrote: On Feb 25, 2004, at 10:11 am, Sven Neumann wrote: Did you increase the shared memory limit? I am not sure what happens if it the X server hits the limit but I guess it just silently stops allocating more shared memory. Err, I know somewhat how to mess with POSIX SHM in applications but how can I change the shared memory limits? On mac os 10.3, in /etc/rc Look at the lines: sysctl -w kern.sysv.shmmax=41943040 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=320 sysctl -w kern.sysv.shmseg=80 sysctl -w kern.sysv.shmall=10240 This is already adjusted by a factor of 10, which will probably help things, but feel free to adjust it higher. keep shmmin=1 the same though. Then reboot. On mac os x client, these adjustements only work the first time you set them, so comment out of old lines or replace them entirely. In mac os 10.2 and eariler, there is a similar thing done in the startup script SystemTuning or somesuch, but I don't have a 10.2 system to investigae. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] updated GIMP API Reference Manuals
Hi, just a quick note to let you know that I finally got around to update the online version of the GIMP API Reference Manuals at developer.gimp.org. The manuals moved from api/1.3 to api/2.0 since we now consider the 2.0 API to be final. Yosh installed a permanent redirect, so old links should continue to work but if you linked to the 1.3 docs, would you please update your links nevertheless. So the updated docs can be found here: http://developer.gimp.org/api/2.0/ Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
