Re: [Gimp-developer] Haze on GIMP 2.4 image - Should this be a bug report?
Mark Lowry skrev: Attached is a link to a screen capture showing the same image opened in Windows Picture and Fax viewer and in GIMP 2.4. As you can see, the GIMP version (no editing performed) has a haze compared to the WPF viewer version. http://vabirdy.tripod.com/images/puppypics/gimp_jpeg_haze.jpg This is very annoying, but I'm not sure which viewer is at fault. Should I submit a bug report for this? Thanks . Mark Hello This is probably a color management issue. I don't think the image viewer in Windows is color managed, so if you also disable display color management in GIMP (File - Preferences - Color Management - set Monitor Profile to None and uncheck Try to use the system monitor profile), does this still happen? Martin My monitor profile was already set to None, but unchecking Try to use the system monitor profile does make the issue go away. Two questions: 1. Shouldn't Try to use be unchecked by default at installation? This would prevent some confusion, at least it would have for me. 2. If Try to use... is left checked, and printing is done through GIMP, should I expect the printed result to be different from the version printed through Windows Picture and Fax Viewer? Also, at some point I've turned off the option to automatically receive post to this board via e-mail, but I can't find a link to get back to my profile to change it. Can someone direct me to the correct place to change this setting, please? Thanks . Mark Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Haze on GIMP 2.4 image - Should this be a bug report?
The reason I asked is that my goal when post-processing is to end up with a print that looks like my screen. When I print from Windows Picture Fax Viewer, it looks like what I see on the screen. I assumed that printing from GIMP would give you a print that looked like the image that is open in GIMP, but I guess that's just silly. Who would want that? . Mark --- Sven Neumann [EMAIL PROTECTED] wrote: 2. If Try to use... is left checked, and printing is done through GIMP, should I expect the printed result to be different from the version printed through Windows Picture and Fax Viewer? What does the monitor profile have to do with printing? Nothing. Sven Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Haze on GIMP 2.4 image - Should this be a bug report?
Attached is a link to a screen capture showing the same image opened in Windows Picture and Fax viewer and in GIMP 2.4. As you can see, the GIMP version (no editing performed) has a haze compared to the WPF viewer version. http://vabirdy.tripod.com/images/puppypics/gimp_jpeg_haze.jpg This is very annoying, but I'm not sure which viewer is at fault. Should I submit a bug report for this? Thanks . Mark Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 2.4.0 won't launch ... See Bug 490010 for details.
Downloaded the binary this evening and ran the setup multiple times, but while the installation appears to work the first launch always aborts. Please see Bugzilla Bug #490010 http://bugzilla.gnome.org/show_bug.cgi?id=490010 for details. Oh, yeah, I'm running Windows XP. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] What happened to FFT forward and backward plugins?
I had 2.2.13 on my PC and it didn't have FiltersGenericFFT Forward or FFT Backward. I have 2.2.14 on my laptop and those filters are there. So I just installed 2.2.15 on my PC and those filters aren't showing up. What gives? Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] That must have been it. Sorry!
I'm not old enough to be forgetting stuff like this yet. I'll just blame it on working on two different machines and losing track of what I've installed where. Thanks for the help! --- Akkana Peck [EMAIL PROTECTED] wrote: Mark Lowry writes: I had 2.2.13 on my PC and it didn't have FiltersGenericFFT Forward or FFT Backward. I have 2.2.14 on my laptop and those filters are there. So I just installed 2.2.15 on my PC and those filters aren't showing up. What gives? Maybe you installed the Fourier plug-in at some point on your laptop? http://registry.gimp.org/plugin?id=2246 (I found that by googling on gimp fft -- it was the first hit.) ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
Joao, Thanks for the help. I figured out that aref works to extract a vector element, while vector-ref does not appear to be supported in GIMP. I ended up using a path consisting of 4 points created before running the script to get my input points and things are working nicely now. It's not the cleanest way, but it seems to be the best I can do with the tools at hand right now. I'll have to take a look at Python ... Thanks again . Mark __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Three point layer distortion mapping feature?
A plug-in that takes three control points on a layer and then distorts the layer (by scaling, translating, rotating, and stretching) so that those points end up on three other identified control points would be very useful. For example, if you wanted to combine two images shot at different exposures to increase the dynamic range and the shots were handheld, you would need to do some or all of these manipulations in order to make the images line up as well as possible. The first three portions of this function, scaling, translating, and rotating, can all be done with existing GIMP plug-ins, and I have written a script-fu to do just that. But the stretching function that is required to help account for variations in lens distortion due to slightly different image centers (from hand-holding) is not possible. Such a plug-in would ideally work with a minimum of two points (in which case the stretching is not performed) and could theoretically work with more than three points to allow for even better control of the mapping. Having live feedback of the manipulation, either through a preview window or on the image window), would greatly assist the user with determining how many points are required to adequately perform the manipulation. Having the ability to place the control points and then tweak their position by dragging them while observing the live feedback would be ideal. What are everyone's thoughts on this? Is it worth initiating an enhancement request in Bugzilla? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Three point layer distortion mapping feature?
--- Chris Mohler [EMAIL PROTECTED] wrote: On 5/2/07, Mark Lowry [EMAIL PROTECTED] wrote: [...] What are everyone's thoughts on this? Is it worth initiating an enhancement request in Bugzilla? IIRC, hugin[1] can align stacks of images. Chris 1 - http://hugin.sourceforge.net/ That's sort of what I'm talking about. The problem with that is that the two images/layers are merged by hugin, meaning there is no chance for any masking or individual treatment of the layers after the mapping has been applied. You may have a passerby in one shot that isn't in the other shot and you want to mask him out, or the lighting might have changed and you want to tweak that ... you get the idea. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
--- Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -- I have thought about doing that and I think that is the way I will have to go. I'm confused with how to extract elements from the vector returned by gimp-path-get-points. I thought I understood that (vector-ref vector k) was the way to pull the k-1 element from the vector, but when I input (vector-ref '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on vector-ref. What do I need to do to be able to extract a value from the result of (gimp-path-get-points image path)? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Pixel coordinates input type for script-fu?
I'm working on a script in which it would be advantageous to use the mouse to click on an image and have the pixel coordinates captured as an input. Right now I have to manually enter the coordinates for four points, which is a tedious process. Is there a way to capture these coordinates as inputs to a script? If not, where is the appropriate place to suggest a feature request for this? Thanks . Mark __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
I don't really see the value in having the loupe possess both the magnified view and the focus view. Several good points have been brought up The handle must be shorter and translucent (why not just eliminate the handle?) ... How will the tool behave at the window limits (with no handle, this becomes trivial)? As long as it is a simple matter to toggle the loupe on and off via keystroke so that you don't have to take your eyes off of the screen area of interest, I think doing so would allow the user to still stay grounded in the macroscopic while working in the microscopic without the need for the handle and focus view. I also had one other thought I'd like to share ... I think it would be very convenient for the Shift+mouse wheel zoom feature to apply to the loupe window when the loupe is visible. This would allow a quick means of changing the loupe magnification without having to look anywhere else on the screen or take your hand off of the mouse. It also makes sense because if shift+mouse wheel does not apply to the loupe, using it may cause the area of interest to move out of the window altogether, requiring the user to pan/scroll the window back. Even if the shift+mouse wheel zoom is centered on the loupe, other areas of interest might be moved out of the window. For example, if adding catch lights to a person's eyes, you might want to be able to see both eyes in the macroscopic view to make sure that the size and position of the lights is the same. If you have already done the left eye and are currently using the loupe on the right eye, a shift+mouse wheel zoom that applies to the entire window or is centered on the loupe might cause the left eye to move out of the macroscopic window. A startup tip should also be written to present instructions for using the loupe. --- peter sikking [EMAIL PROTECTED] wrote: Sven wrote: I am not sure if Sven wants another feature request in bugzilla. If so I will write it. Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the discussion and it might attract a developer who wants to work on this feature. I am not at all opposed to bug reports. just checking, because of: I just doubt that it makes much sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests. then saul wrote: I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Indeed, the handle of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish). my thanks for you and the 'puter, again. Firstly, there is an effective warping of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped). the last point is exactly how it works (also for humans) and means no HIG felonies. Nonetheless, this behavior can be disorienting. It should be noted that the overly-long handle shown in the simulation exaggerates the severity of this problem. the point of my 'must be close, but out of the way' guiding principle. More important is the general nature of the tracking of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port). that is at the user's discretion. I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. excellent point. since the point of the loupe is working precise, the mouse must move at the speed of the zoomed view. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. your solution really got me thinking. there are multiple other alternatives. at the end it is about having the most stable, predictable loupe placement, and technical feasibility. The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly. well, if you want
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
I think that the user should be able to select between a 1:1 mouse resolution scale and one that matches the scaling of the loupe's zoom. This would be good to offer at least on any test version that is developed, until enough user feedback is obtained to eliminate one of the options. --- [EMAIL PROTECTED] wrote: I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. This assumption may be faulty but it would seem that if you are zoomed in at 10X and the mouse inputs are not scaled appropriately then you will experience difficulty with positioning of the tool within single-pixel precision (in the zoomed port). If sub-pixel mouse resolution is high enough than the loupe could track the mouse 1:1 and the image in the zoomed port could track it at 10X the speed (or whatever the zoom factor is set at) -- I don't believe this to be the case. The simulation shows a 4X zoomed version of the image in the larger port. Based on the preceding assumption, the movement of the loupe itself would become 1/4th the movement of the mouse pointer when the loupe is not invoked. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Peter, I'm glad you've become the ambassador for this. Your description of a loupe is basically what I was proposing in my original bugzilla proposal #409802 ( http://bugzilla.gnome.org/show_bug.cgi?id=409802 ). Rather than add another proposal, why not just flesh out the details of your vision on that bug report? I hope enough others agree that this will dramatically change the way work is done in GIMP to make this a reality. . Mark --- peter sikking [EMAIL PROTECTED] wrote: Chris, First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. don't worry, I am also fired up about this one. here is why: people have talked to me a week or more ago on the irc along the line of: what's the big deal, one way or another will do. here is the big deal: for my pov the dockable magnifier is just-another-feature, it will make some people happy in some situations. the pop-up loupe however, has the potential to be a transformational feature. It has the potential (when properly designed) to fully transform the way most people work with GIMP in work-macroscopic/change-microscopic situations, that go way beyond the mentioned setting selections pixel-precise. saul on the irc made this film (thanks): http://flashingtwelve.brickfilms.com/GIMP/Temp/loupe-demo.gif I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change. I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. practically speaking, this will have to wait for cairo, and I see you are already off the mark. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. I am not sure if Sven wants another feature request in bugzilla. If so I will write it. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
I was thinking more like this ... http://pic20.picturetrail.com/VOL66/86790/6669793/233033597.jpg --- peter sikking [EMAIL PROTECTED] wrote: Mark Lowry wrote: It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. like this? http://www.creativepro.com/img/story/20051219_fg5.jpg assigned to a spring-loaded key (push down: magnifier appears, release: disappears). Settings need to be adjustable on the fly, hmmm. magnified area can stay out of the way automatically, without jumpy behaviour, like magic. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
IMO, you definitely need to see the mouse cursor in the magnified view, and you should be able to interact with it. Windows has a magnifier that uses a second window for the magnified display. The good is that the cursor shows up in the enlarged view ... the bad is that the window takes up so much room on your screen and you have to relocate it frequently while you work. You can dock it on the edges of the screen or have it float, however. If you want to see/try the Windows implementation, it is under StartProgramsAccessoriesAccessibilityMagnifier. Here's a screen shot of the Windows version in action. http://pic20.picturetrail.com/VOL66/86790/6669793/233053894.jpg The Windows version is not bad, but improvements could be made and I don't know if other operating systems have such a tool. A version that resides in GIMP and is designed with retouchers in mind would be a very nice feature, I think. --- Sven Neumann [EMAIL PROTECTED] wrote: Hi, how should tool interaction work with this? Would you want to see the mouse cursor in the magnified view? Should you able to interact in it or is it just a view? Sven Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enhancement Proposal: Add a temporary magnifier
I submitted Bug #409802 on Bugzilla, but it was suggested that I post it here for discussion. Here is the initial submittal from the bug. Please review bug #409802 if more clarification is required. Opened by [EMAIL PROTECTED] (reporter, points: 3) 2007-02-19 23:18 UTC [reply] It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. This could be accessed, for example, by pressing SHIFT+Z, upon which a small window would open up and display the area around the cursor. The window that pops up could have some check boxes for the amount of magnification to be used (1x, 2x, 3x, 5x, etc.). This functionality would be very useful when making selections with the pen tool, lasso tool, etc. Another way to implement this would be to have the magnification value in the preferences, and instead of opening up a separate window for the magnified view you enlarge a circular region immediately surrounding the cursor (would look just like you were holding a real magnifying glass over the screen, and would move with the cursor). I tried searching for something similar to this suggestion, but didn't find anything. Sorry if it's a duplicate. Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
