[Gimp-developer] Where all developers are?
Last I mailed it was said that there are not that many GIMP developers. Where are all image processing application developers have gone? Is there some other open source image manipulation software which sucks all the developers? In recent years Siggraph conference proceedings have had more image processing papers. For example: They are now making giga size photos with panoramic techniques. They are using hundreds of tourist photos for making 3D walkthroughs through city. Google earth and competitors are making 3D models from photos. And much more. It looks like today's image processing software needs to be redefined because there are many new applications for photos. You may suggest some other application for specific task as an easy solution but please don't. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Scanner camera
Hello. Found an interesting paper on using scanner as a digital backend in a large format camera. The paper describes the needed image processings in detail. http://www.funet.fi/~kouhia/14160534.pdf Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: More interface rantings
From: Thorsten Wilms [EMAIL PROTECTED] The old crop tools was ok if you have a fixed target size. The dialog always got in the way for the cases where you crop the image to find the right aspect. Your text gives an impression that the old crop tool is not anymore there. Is that the case? The fact is that people have different ways of working and therefore having two (or more) versions of the tools would be perfectly ok. It would be annoying if you are trying to squeeze people to one mold. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Suggestion to simplify user interaction
How about a large toolbar window? When an operation is needed, the toolbar window pops up with a key press. Remember, many software have a quick reference card of one or two pages. One could typeset the card in the toolbar window (possibly multiple pages) and add transparent buttons over it. No patent pending. The toolbar window has always the operations typeset at the same locations if so wanted. That is the second plus over the deep menus which have no fixed layout between the menu windows. BTW, the emacs style command system was also a good idea. E.g., Esc x filters-noise-spread and ctrl-x n s. Emacs also has the command apropos something which helps in finding the suitable commands. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Customizing GIMP windows and behavior
From: Sven Neumann [EMAIL PROTECTED] I don't think such a thing can be implemented without massive changes to the internals. But why would your users want such a behaviour? And what are your users? As I seem to have requested similar functionality, I would like to know what are these internals. Could you point me to the files which has the mentioned internals. For example, I open an image and create a new view (View/New View menu). Then when I use the rectangle selection tool, the solid line is visible only in one view. The selection's non-solid line becomes visible in both views. Why the tool's solid line is not visible in both views? What code file controls it? Why the selection's non-solid line is visible in both views? What code file controls it? Why the path or other objects would not be visible in both views? I had one solution to the problem earlier: I suggested the tool plugins and a vector/geometry layer (perhaps different consept than what got implemented this summer). The example tool was the rectangle tool, where the tool's solid line was added to a temporary vector layer. The solid line would have been visible in both views trivially because the vector layer would had been part of the image itself. I have a perfect solution ;-) too but I would like to check the internals first. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: rectangle select tool specification
From: Sven Neumann [EMAIL PROTECTED] I know at least one professional in user interface design who strongly disagrees with this. When we asked Peter Sikking to have a look at the That was interesting, but he is simply wrong -- I'm sure he would design the tool differently after knowing the problem. After making preselection on 5000x5000 image, if only handles are grabbable and one zooms in to details of the image, then the handles may not be visible. It becomes impossible to do precision selections. The edges are always visible when needed and edge-grabbability works. I'm not UI professional or wanna-be but I had the problem a couple years ago and you suggested to use the guides at meanwhile. It is now good that we have a real solution to the problem. I have no better solution for visual hint on that the edges can be grabbed. If the selection tool on and the edges are solid, then it might be ok to assume the edges can be grabbed and moved. The switch of icon when the pointer is over the edge would confirm the case. That is how it works in audio editors -- users expect the grabbability. But how grabbability is indicated in Blender? Blender indicates the active object by using different color, but how Blender indicates that an object can be selected and activated? With nothing? Can the handles be arrows like this - | - across the edge? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: rectangle select tool specification
If I have multiple views to the same image, is the rectangle tool, the crop tool, etc. visible in each view? For example, I may have one view to the entire 5000x5000 image, and second view of size 500x500 in which I do precision placement of the tools. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: rectangle select tool specification
From: William Skaggs [EMAIL PROTECTED] The (New) Rectangle Select Tool [ ... ] An important different from the old tool is that the rectangle you get is modifiable, as indicated by handles at the corners. You should be able to click on any corner or edge and drag it -- the cursor should change to indicate when dragging is possible. What the handles do in the tool? In some other editor, the rectangle can be modified only by grabbing the 8 handles located at the corners and at the middle of edges. (That is an unnecessary limitation.) The handles may confuse users if really the grabbing can be done by clicking in anywhere on the edge. (That is the preferred way to do it since the first interactive graphics system was written.) The handles should be removed. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: SIGGRAPH BOF - failed
From: G Blair [EMAIL PROTECTED] The Open Source booth was busy demonstrating packages such as gimp, blender, inkscape, and others. The degree of confidence varied. Sample questions such as, How do I remove red-eye? stymied several volunteer gimp operators. Yep, open source people could learn to answer to that kind of questions. The similar happens in pro-audio side as well. One possible answer is to ask what plugin they have used in PhotoShop. They could ask the plugin author to release the GIMP version. Specially if the algorithm has been patented. Second possible answer is to say GIMP cannot do it, perhaps it can be done with plugins, the GIMP sites provide lists of available plugins. Without correct answers the how do I questions could go on and on. Photoshop authors could list all features of their $ plugin set and seriously expect that every feature has an open source equivalent of the same quality. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: SIGGRAPH BOF - failed
From: G Blair [EMAIL PROTECTED] The Open Source booth was busy demonstrating packages such as gimp, blender, inkscape, and others. The degree of confidence varied. Sample questions such as, How do I remove red-eye? stymied several volunteer gimp operators. Yep, open source people could learn to answer to that kind of questions. The similar happens in pro-audio side as well. One possible answer is to ask what plugin they have used in PhotoShop. They could ask the plugin author to release the GIMP version. Specially if the algorithm has been patented. Second possible answer is to say GIMP cannot do it, perhaps it can be done with plugins, the GIMP sites provide lists of available plugins. Without correct answers the how do I questions could go on and on. Photoshop authors could list all features of their $ plugin set and seriously expect that every feature has an open source equivalent of the same quality. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: New microsoft image format
From: Michael Natterer [EMAIL PROTECTED] It's already ambivalent to have GIMP running on windows at all, I'm not interested in taking this any further by supporting these formats, and thereby supporting M$. The free software community doesn't get any support from them either. I have designed speed-up improvements for PDF. There is place for an improved format. But I hope the MS's preference is not in copy control, i.e., that their format would be tied to DRM. Now to the quoted text. In my software, I have already thought of using a license which forbids their use in Windows. I don't know the license details yet; perhaps GPL + restriction. The major point is that domestic computers are sold with Windows preinstalled. I have not seen a domestic computer sold both with Windows and Linux, or with Linux only. This is not entirely about what people want: the Windows typically is ripped-down version which comes with ripped-down, bannered versions of software. The system is barely usable as standalone (not usable if you ask my opinion). If GIMP and other major free software could not be used in Windows, domestic users would perhaps ask for other OS. Having piracy laws and copy control improving, would leave people no option than purchase the products for Windows. Then the free software could be a winner. Then the consept that major free software cannot be used in Windows will work. I have played recently with the idea that what if only preinstalled OS is Linux. How many would buy Windows anymore? How many software companies would develop for Linux because everyone would have Linux? Suse Linux costs $70 and Windows $270 -- people would save money too. I have got replies to above that OEM version of Windows costs less, but I call it price dumping, bribing, breaking trade-laws to sell products cheaper in preinstallation context. The computer manufacturers may not get the discount if they dual preinstall both Windows and Linux. How many GIMP users the world has? How many copies are downloaded yearly? What about Photoshop? OEM/bundled versions excluded? Included? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: How to draw a line?
[ Simon at gimp-user ] What I _want_ is a straight line, constrained to horizontal or vertical, drawn with the caligraphic brush (so it has a chiselled end) and using the fade out option, so it disappears smoothly over a distance. What are the current plans on adding vector drawing to GIMP? If plans at all. I have earlier proposed the vector layer. I actually proposed an arbitrary data layer, display plugins, the tool plugins, in addition to the associated plugins. The vector layer would require several tool plugins for manipulating the vector data. The vector plugins may paint the vector data to an image layer, or, e.g., perform operations between two vector images. Typically the vector layer would be a part of an image having RGB layers. The system would be very general. For example, a rectangle selection tool could be implemented with help of a temporary vector layer. I have explaned such a tool earlier here. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Simple rectangle selection tool
Hello. I would like to know how I could re-use the existing rectangle selection tool codes for my tool: My simple rectangle selection tool would maintain one rectangle (four vertexes joined with edges). User may adjust the selected rectangle by grabbing and dragging the vertexes or the edges. The selection mask is created each time at the release-button event (until the tool is changed to other). Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Tool plugins?
Hello. Can the existing plugin system do the following? A color picker plugin would (1) receive events about the cursor location and (2) set the current color. If not, then we should think about how to change the plugin system. The tools would need to draw graphics. They could simply create a new layer on top and draw the graphics on it. In preview mode, user would see the output image equipped with the tool layer and the original image (input image) would stay intact. The switch of displayed image would be done by the tool. One advantage of using a layer for the tool graphics would be that all views would display the tool graphics. E.g., I would see the selection tool graphics both in a wide view and in a zoomed view. What should all the views display, would require thinkering. If user wants to see the preview image both in the wide view and in the zoomed view, both views should be swapped. But this is actually easy. Each view should have a flag for what it should display (three choises). User could set the flag when he opens a new view. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Improved rect select tool
From: Carol Spears [EMAIL PROTECTED] there is nothing more adjustable than a layer that you make and use as a mask. it is easier on your computer and everything saves with less space being taken in the file. You have misunderstood what about we are writing! We are not writing about the selections (which are masks) but we are writing about the **tools** used to make the selections. Yes, GIMP art are nice, but it does not make the impossible possible. This extra tool makes the impossible possible. The new tool is needed (I have waited for 8 years!!). Regards, Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Improved rect select tool
Hmmm.. people should start working on the tool plugin system so that some of us may have very specialized tools if we want to have them. I don't make art with GIMP and so I have not used to the work flow most artists use. I have tried to use the guides in the selection making but the guides are unconvenient to use. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Improved rect select tool
From: William Skaggs [EMAIL PROTECTED] I have been working on a new rectangle-select tool to meet some of the deficiencies of the existing one Thank you! 1. We may have any number of selection tools. If this selection tool does not fit perfectly to somebody's working habits, then we will write two slightly different variants of this tool. (We also should have configurable tool palettes and menues if we start having large number of specialized tools.) So, please, Sven all, don't overrun somebody's suggestion unless absolutely necessary. 2. If Adjustable is checked, then the shape of the rectangle can be modified after it has been drawn, by moving the corners in the same way that works for the crop tool. Make it also adjustable by moving the edges. Otherwise with large images, it becomes impossible to select areas precisely: in a zoomed view, one may see only the edge of the rectangle. 3. Once it is satisfactory, clicking inside the rectangle converts it into a selection. Clicking outside the rectangle cancels the tool. A while ago I proposed that the selection is created each time the grabdrag is released. When one starts re-adjusting the rectangle, the previously created selection is deleted. That means that quitting the tool can be done by switching to another tool or by applying an effect. And that one does have one-to-one match between the rect and the selection, in realtime. (One could use that kind of interactively realtime selection in future GIMP version.) Only cancel operation must be implemented. 4. If Adjustable is not checked, then the rectangle is converted to a selection as soon as the mouse button is released. (That is, it behaves like the existing rect-select.) That is bad. But also unnecessary if you implement the tool as described above. BTW, who can do selections with non-adjustable tool? In existing rect tool, it is pain to start the selection from scratch if the selection is not good in the first place. Try it also with large images, impossible. 5. If Show dialog is checked, then a dialog closely resembling the crop tool dialog is shown whenever the tool is working, allowing As said, if you want this dialog, an another version can be written for us. Please write the tool you like, and then we have to modify your tool to fit to our needs. One tool for you, another tool for us. OK. It is just one new tool to the set. You write it your own way. We must accept it because it sounds like a good tool already. Whiners can write their own tools. Remember, we accepted the existing braindead rect tool years ago. Nothing can be worse. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: whishes for Gimp
From: Sven Neumann [EMAIL PROTECTED] Adding more tools has the disadvantage of cluttering the toolbox. Just suggestions: Solution 1: everything goes to menu (tree) and each non-default menu item would have toggle which would append it to the toolbox. Solution 2: toolbox (and menues) could be built with a simple builder application. User could build the toolbox, name it, and save to file. Depending of the project, user could choose a suitable toolbox. The second solution would be better because no toolbox nor menues would be cluttered. The builder could be a tree list (perhaps later following the tool plugin directory hierarchy when the tool plugin system has been implemented). Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Right, thats it. I'm off.
From: Carol Spears [EMAIL PROTECTED] the new chix list can be found at: [ ... ] show the respect that you would like to receive. That would have worked here in the first place. Comments such as below does not show any respect to people who write these software. From: miriam clinton (iriXx) [EMAIL PROTECTED] Artists prefer to use the right hand side of the brain, to work intuitively. This is why 1.2 in particular was so difficult to work with - it was obviously written by coders using the left hand side of the brain. It leads absolutely nowhere. Better would be to think why such strong frustation. I think there is no cure for it. Best would be if Miriam and other frustated users would start writing a document on these issues. Mails are forgotten pretty quickly but a document not. Coders then could take a look at the doc whenever they want, nothing would be pushed like in these mails. Hey, we already saw that Jonathan's mails were ok, but Miriam still continues making false claims on them. I'm sure Gimp would benefit most from artists who have team-worker's attitude instead. also, please consider that richard was flirting. it is free software so Stallman? Have you mixed up the names? Richard was only recommending to join the gimp-developer list. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: game development with gimp
From: Steve Siverling If I were to go about creating a Game Master GIMP, I would = focus on automating a number of the more commonly used tasks in the GIMP = that would be used often with producing game art. Like I said in my = example...one thing would be the creation of alpha channels. [ ... ] The other areas would be tiling of textures as well as = creating a few pallete tools to allow for faster creation of character = skins and level textures. I would like to have the example mentioned and more if anyone would like to create them. To save time, very plain list of operations would do fine -- no need to write polished tutorials. We can work out any missing details later. You may refer to existing game design tutorials found on the web if you wish. Are this kind of tools available for PhotoShop and equivalent software? If yes, I would like to read the manuals of the tools. I already know from one of the tutorial at http://www.leveldesigner.com that the environment mapping may require a loop between the game engine and the painting software. GIMP could feed the environment map directly to the GPU texture memory with OpenGL. In the game the change would be seen immediately --- maybe even when the painting is in progress. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: color management
Hello. Several mails in this thread says that the images will be converted between colorspaces, such as monitor colorspace. Does GIMP keep two versions of the same image: one for image processing and saving, and one for displaying? I remember how XV converted images to fit better to the display. If one had 8-bit display (and most had), the image was quantized to 8-bit. Then when the image was enhanged and saved as jpeg, one could see that the jpeg image contained the quantized and dithered 8-bit image! People lost their 24-bit images because they used XV to trim and flip the images!! Please don't make the same mistage with the colorspace issue. Worse is if you force people to convert images in lossy way as you have planned. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Usability test - Results available
From: Sven Neumann [EMAIL PROTECTED] Subject: Re: [Gimp-developer] I get the impression that you did not understand how the key modifiers of the selection tools work. I admit that it's not obvious but it's a very powerful concept that I would hate to loose. Multiple selection tools. There is always room for an alternative way to make selections. There is no need to modify existing tools if they are good. Just copy the code of an existing tool and modify it. Just a reminder: I would need that unirectangle selection tool. If you go to another image the tool is resetted, the dialog is closed and a new dialog is opened so your argument doesn't hold up. That is very annoying because the new dialog window pops up at the pointer. Unless in GIMP 2.0 new dialogs goes automatically to a dock. Sometimes closing the old one and opening a new one is totally not wanted: it would be impossible to compare the color levels of two images if only one level dialog can be open at a time. I'm still using GIMP 1.2.3 but those problems could still be present in GIMP 2.0 -- please verify yourself, I cannot do it. -*- About the path tool: could Shift (or any) be used to cycle between modes? Would that reduce button-modifier-overloading? The modes could sort theirself to the most-recently-used order, in which case cycling starts always at the top mode. Cycling would stop when modes has been selected for, e.g., 2 seconds and would stop when user does something else than press the Shift. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] I don't see how this could be useful in an image manipulation context. If implemented for a program primarily intended for vector stuff (Skencil, Sodipodi) this might be very helpful, but in GIMP the primary goal for now is to create pixel based images - which is notoriously bad for above mentioned technical drawings. OK. The p54-freeman-benson.pdf paper has an example on musical notations (second page). GIMP could have similar plugins providing that kind of editor and renderings. It doesn't need to be limited to musical notations but text could work as well. The constraints system would make it easier to make automatically room for the letters and icons when they are inserted. Note that Cinepaint has added a vector data layer. That layer could be saved within the image file and plugins could use the vector data layer as input. If such layer is implemented in GIMP, it opens many new possibilities: E.g., I could have a constraint based tool for arranging photos on a virtual desktop. The photos on the desk would not overlap. For the photo which I grab and drag, the constraint system would make a room on the desk by moving other images. In this case the vector layer would contain image objects (polygons). Of course, even simplest tool such as unirectangle selection tool would benefit: in the tool, when mouse button is pressed first time, I would create a rectangular polygon with the grabbed vertex constrained to the pointer and all other vertexes constrained to the grabbed vertex. In the crop tool, where the polygon stays active for longer time, grabbing would change the constraints depending on what is grabbed and moved. BTW, the multitrack audio editor Ardour includes Cassowary constraints library. It looks like it is not used at all, but the plans and some tests were done at 2003 Jan/Feb for constraining audio pieces during some editing tasks. The discussions were archived at sourceforge but I could not find them anymore as Ardour moved to ardour.org. I did read the mails from my private archives. I have mentioned Qoca but Cassowary seems to work as well. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] Could you read the sketchpad.pdf and check how it differs from how the path tool is handled? It would be your task to explain to explain to me what you want. As I said earlier I am quite satisfied with the way it works now. No. It is better that some of you too will read about the topic. The provided sketchpad paper has a good framework, and I would like to know if that gives any ideas to anyone of you. My posting was not meant for unwilling persons like you, but for anyone who could read the papers and fit the strong ideas given in the papers to GIMP. Also, the path tool deals with bezier curves, the paper does not. The path tool handles polygonal line segments, the paper does not (only single straight lines). Please don't read too narrow-mindedly. The Sketchpad has been used to construct more complex geometries than a single stright line. Read the whole paper, don't stop to first figure. The framework in Sketchpad is the most important part (not the curves): the constraints and the object oriented data management. It can be used for any new objects, including Bezier curves. Last I ckecked, your framework in Path Tool was not used in the rectangle selection tool nor in crop tool. Can you put your framework to a form in which I may use it to code new unirectangle and new crop tool for us? We need not to check new frameworks if existing ones are good enough; and they are good enough if they can be used to program new tools. For circles a significant different way to handle them has become quite standard for vector applications. And I'd prefer to match the handling in other recent programs than a paper from 1963. Qoca constraints solver papers have been published quite recently (200?). The papers with good intro sections has been published at 199?. What papers you have been reading? Does your framework in Path Tool implement any constraints based manipulations? Just read the papers and check if they raise up any ideas. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] The Link you gave does not work. Try now: ftp://ftp.funet.fi/pub/sci/audio/devel/constraints/ http://ftp.funet.fi/pub/sci/audio/devel/constraints/ In fact there is a vector based infrastructure and I also believe that it is quite flexible. Simply fiddle a bit with the Path tool to get an idea how this works. Could you read the sketchpad.pdf and check how it differs from how the path tool is handled? The constraints directory has other pdf papers of which you could read at least the introductory sections. They give some background and motivation. The qoca subdirectory has some papers related to Qoca constraints library (GPL) -- search the source code from the web. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp usability tests
From: Christopher W. Curtis [EMAIL PROTECTED] Would it be possible to solve this issue by placing transient corners on the image? It perhaps would not be a good idea if the original corner would move when the equivalent transient corner is moved. Also, user would be moving a completely invisible edge. See figure: view -crop/selection region | --|- | | || --o--| | | The mark o would be a transient corner. When it is moved up and down, it would move the lower edge which is completely invisible. But if the transient edge would only move the edge in horizontal direction, then why not grab and drag the edge itself -- it would be easier to implement. Perhaps the whole region could be moved by grabbing inside the region so that no special move corners are required. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp usability tests
From: Roman Joost [EMAIL PROTECTED] Tasks for the first test (all-day-usage; all of the are common tasks for all people, except the one where the indicated group is mentioned): Hello. Could you also make a proper usability test for the rectangular selection? I seem to be forced to use the re-try approach where I start making the rectangular selection from scratch if it goes wrong (and the initial fine-tuning never goes right at first time!). It also seems to be impossible to make precise selections in large images (e.g., 800x800 to 6000x6000). Both large selections and long narrow selections on large images are trouble. If zoom-in is used, even relatively small images becomes large. Test the crop tool too -- it fails for large images as well, or when zoom is used for seeing image details. -*- I'm puzzled: do you people make perfect initial selections or how you scope with the problem? Do you have any problems at all? Why not? (I could gather a couple of examples if you think there are no problems at all.) In audio editors, the selection can be re-adjusted easily by grabbing and dragging the selection edges. I proposed similar rectangular selection tool for GIMP here a few months ago. It solves all the problems the current rectangular selection tool has (for making one simple rectangular selection). If anyone wants implement the unirectangular selection tool and/or improve the crop tool, please don't hesitate ask my improved designs. (No patent pending.) (GIMP does not anymore compile in my Linux -- we should work out the tools together, if at all.) Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp usability tests
From: Sven Neumann [EMAIL PROTECTED] Well, something is wrong with _your_ Linux then. But unless you tell us about your problems, we won't be able to help you. Yes, I don't update my Linux weekly. That is the problem. Does GIMP compile in unpatched RedHat 9? RedHat 9 is already a year old, which is a long time. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
From: Sven Neumann [EMAIL PROTECTED] What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview. Does this mean you continue with the plugins which create their own dialog and all interactive manipulation happens there, like gfig? I wish plugins like gfig would operate on the image/view, not in separate window like now. There are consequences: -Need for multirate images (MIP images) for low resolution preview -Plugin's preview area can be given as a rectangle on the image (just like 3D modellers allows user to define the area which is rendered) -Plugins can make data layers on the image (gfig would make a vector layer) MIP images would mean that large images may be efficiently edited at lower resolution. The operations are reflected to high resolution images later or when the system is idle enough. If a plugin wants a separate preview to its dialog, then that is just a new view to the image, embedded to the dialog. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Path tool problems
Hello. Has anyone else found the path tool hard to use? IMHO, the usability is very low there. If I choose to make first a polyline and then adjust the curve, the curve type seems to be unsuitable. The curve goes easily to serpent. If I choose to make the curve progressively, I have to switch between the new point and edit mode -- and still the curve is hard to control. Here is a list of my foundings: -Points are can be invisible against a scanned pencil drawing (greyscale) -No indication if something can be done to the points when the pointer is near them -No indication what operation is applied when shift or ctrl is held down -When making a closed path, there is no indication when pointer is on the first point -Has to switch to separate edit point mode for moving the earlier points -Has to switch to separate edit point mode for adjusting curvatures of the earlier points -Edit point mode changes to the new point mode even I would like to continue editing -A square anchor point may appear when one closes the path (should it come only after one starts the second path?) -First point of the path is often invisible, making it difficult to place the second point -Placing new points to the path is difficult without accidentally adjusting curvature (making the path becomes slow task); moreover, the curve becomes out as boozer's walk Because the curve type is so difficult, I only make polylines. But as said, the tool is not well suited to that either. My suggestions if I choose to make polyline first: -mb1 places new point -mb1 if near an earlier point, moves the earlier point -shift+mb1 if near the first point closes the polyline -Pointer pixmap indicates when an earlier point is near enough for picking -New point would appear at button release (so that curvature is not adjusted accidentally) As said, there is no point to edit the curvatures after this because the curve type seems to be wrong. Traditional Bezier curve could be better, i.e., the plain polyline would be all what controls the curve. When I choose to make the curve progressively, the problem is that I cannot adjust earlier points without going to the edit mode. -mb1, shift+mb1, ctrl+mb1 if near an earlier point, adjust the earlier point -Pointer pixmap indicates when an earlier point is near enough for adjustment -New point would appear at button release (so that curvature is not adjusted accidentally) Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Alternative zoom algorithm
Hello. More in-between steps in the logaritmic zoom (...,2:1,1:1,1:2, 1:4,...) would be nice, but nothing fancy like more steps around 1:1 is not needed here. There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing. This gives an idea that GIMP could have a tool which computes the scale ratio required for matching the scanned pencil size with the size of the selected pencil. The tool could work this way: (1) select the pencil, (2) start the tool, (3) zoom the image until the selected pencil size matches the scanned pencil size, (4) start scale operation which takes the zoom ratio as scale ratio. That would require that GIMP can draw the outline circle (say) of the pencils. Does not solve the underlying problems of GIMP, but is better than nothing. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] unirectangle selection tool
Hello. The GIMP does not compile in my Linux and thus I cannot fully develop the tool myself: Unirectangle selection tool -- Select one rectangular region I post the design later, but now I would like to know why the crop tool and the Bezier selection tool are not visible in all views of the image? I want my selection tool to be visible in all views. The reason why a selection is visible in all views, is because the selection is a mask. Likewise, I want the tool to be on the image object, not on a view object. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Selection tools
From: Sven Neumann [EMAIL PROTECTED] The point is that you misunderstood what a selection is. A selection is a mask holding a selection value between 0 and 255 for each pixel in the image. What you see on the GIMP canvas is just the selection border OK. I was writing about a tool which is used to make a selection. When the tool is on, it holds the rectangle as vertex/edge data. When user releases the mouse button, the selection mask is created. When user again grabs a vertex or an edge, the selection mask is undoed. The selection will still be a mask. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Friends of GIMP
From: Dave Neary [EMAIL PROTECTED] A couple of people asked this question - I thought I'd explained the idea pretty well, but I guess I missed the mark. Gone with the wind? How about changing the title of the list to retired GIMP coders? Then everyone would know what you really mean. Sooo... who would like to go through the list and ask if they would have time to work with GIMP? Ask their employers if they would sponsor GIMP project by allowing the people work on GIMP a few hours a week? Note the coders in the new title. The list excludes all those who have contributed great ideas to the list, but who have not coded. If you really look for volunteers, then here I am. Anyone coder would like to implement with me an alternative selection tool (as existing tool seems to be practically unusable)? For the start... Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] linux-graphics-dev
Announce: I'm pleased to announce a new mailing list: linux-graphics-dev at http://music.columbia.edu/mailman/listinfo/linux-graphics-dev;. It is a get-together list for open source, free graphics software developers working in Linux. The mailing list is convenietly also available in digested format for those who cannot tolerate individual mails from yet another mailing list and for those who are not exactly Linux developers. Possible topics include: -Making people aware of existing software -What software are yet needed -How projects may benefit from other projects -Are there a need for Linux graphics standards -Guiding new developers to find a project which they can help -What projects would have a need for developers -The Big Picture The discussion may well be quite technical. linux-graphics-dev is a companion list for linux-audio-dev which has been successfully around for a few years. Best regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
