Re: [Gimp-developer] Isn't this behaviour unintuative?
No, Im telling you that for photographic workflows, desire to overwrite is rather rare this is true, can be an unrecoverable mistake, even for one unique picture but sometime overwriting is convenient and desired Probably the best way is to have this choice in Preferences Also from an Usability point of view - probably for the first use of Ctrl+E in a work session - it's ok to present him in pop-up the choices he have - then the user will choose what he want also he will choose his option for the whole session. So if the user choose Overwrite without confirmation - then all that session Ctrl+E will act this way If he will choose Bring me the save window every time - then he will see all export options If user will choose Export a Copy - then for the whole session the file can be saved using incremental sufix Also as a new option probably is ok to have Save using Preset - that mean a place where user can make reusable patterns with rules for saving files. Example of a preset for a mass save scenario: 1) preserve the original anyway 2) make an incremental file with PNG extension and the same filename in the folder /home/web/X (with all compression options ..etc) 3) make an image with sdfasdfasdfasd name and JPG extension in folder /media/hdd4/Y (with compression options etc). 4) and so ... 2011/6/30 Alexia Death alexiade...@gmail.com: On Thu, Jun 30, 2011 at 2:08 PM, Jeremy Morton ad...@game-point.net wrote: So you're assuming that the user is going to 'accidentally' press ctrl-E, then 'accidentally' click on overwrite even though it's not the default selected button? No, Im telling you that for photographic workflows, desire to overwrite is rather rare. However, users will assume export shortcut to behave analogously to save shortcut, that being, dalog on first evocation, silent save on rest. I know I do. Hence the annoyance with nothing happening. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, 2011/6/28 Martin Nordholts ense...@gmail.com: 2011/6/26 Jeremy Morton ad...@game-point.net: When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens. This is because what I actually have to do is select File | Overwrite (filename.png). Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format? Yes it would be more intuitive, and that was also the initial design. The reason it works the way it works today is to avoid data-loss. In GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View - Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In other words, this sequence of events is harmless in GIMP 2.6: 1. File - Open file-I-dont-want-to-lose.jpg 2. Make some significant changes 3. Press Ctrl+E while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we made Ctrl+E invoke Overwrite by default and a user, quite reasonable, expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing users to manually assign Ctrl+E to Overwrite, they would confirm that ok I know Ctrl+E will potentially destory my originals. That file-overwrite and file-export can't have the same keyboard shortcut is a bug, that is meant to work. Quite an oversight that it doesn't... Once people have learned that Ctrl+E is export and not Shrink Wrap, we can make Ctrl+E be the default keyboard shortcut for both Overwrite and Export. Until then, I just made a commit so that you can use Alt+F, W instead at least: commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e Author: Martin Nordholts mart...@src.gnome.org Date: Tue Jun 28 08:53:45 2011 +0200 Make 'w' a mnemonic for File - Overwrite ... See [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
this is why I am insisting that it is not going to change, in the future. don't get me wrong - as is right now - is very convenient for me and probably for many others, but seems to disturb a part of designers who comes with various backgrounds. to be clear ..when I see for first time that Ctrl + E just overwrite without confirmation, in the very next second in my mind come that Ctrl + Shift + E should do the job I've asked for. It was true ..and logic. Can't be other - so I can say it's quite intuitive as is. Btw. I rarely use File entry on menu bar. Now I've just discovered there text helpers (Ctrl + E and Shift + Ctrl + E) which indicate the keyboard shortcuts for mentioned functions ;) - funny. 2011/6/28 peter sikking pe...@mmiworks.net: On Jun 28, 2011, at 11:35, SorinN wrote: But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co). also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format). this is why I am insisting that it is not going to change, in the future. since the GIMP team (and I as interaction architect particularly) have the duty not to encourage overwriting/destructing the original file by accident, there is no shortcut on overwrite by default. Users can set it by hand, it is their call on the convinience vs. danger balance. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Isn't this behaviour unintuative?
He's right here = I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. He doesn't know that Ctrl + Shift + E bring to you the Export Dialog where you can choose your different filename AND / OR different extension. 2011/6/26 Jeremy Morton ad...@game-point.net: The way I think of the workflow, I'm importing a file, editing it, and exporting it. Overwriting the file on disk is a mere side-effect of that workflow, and GIMP will prompt me in any case just in case I don't want to overwrite the file. The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. -- Best regards, Jeremy Morton (Jez) On 26/06/2011 15:14, Alexandre Prokoudine wrote: On Sun, Jun 26, 2011 at 6:00 PM, Jeremy Morton wrote: As far as I can tell the usage pattern has already changed heavily from 2.6. In 2.6 there was only one save option; now there's a save and export. You've already changed that significantly. Yes, and there should be a better reason for going half the way back and introducing a crossbreed of 2.6 and 2.8 than just it should be possible. I wouldn't really want to rely on arguments like it doesn't make any sense, but in truth it's exactly what I think. Overwrite says exactly what it does. You can assign a shortcut to it. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: Re: Isn't this behaviour unintuative?
mr. Morton point seems to be correct BUT I don't feel that Ctrl+E should do the same thing as Ctrl + Shift + E. we have 2 different situations : 1) the designer want to overwrite something without the confirmation dialog 2) the same designer want to change the file name or extension 2011/6/26 Jason Simanek jsima...@gmail.com: On 06/26/2011 09:31 AM, SorinN wrote: He doesn't know that Ctrl + Shift + E bring to you the Export Dialog where you can choose your different filename AND / OR different extension. I have to admit, I'm constantly getting tripped-up by that. Is there any reason that the FIRST time you hit Ctrl + E couldn't do the same thing as Ctrl + Shift + E rather than _nothing_? Or at least bring up a dialog asking the user if that is what they'd like to do? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
Jacek - you don't need CMYK for photos [I need CMYK support for photo retouch, to create better colors]. CMYK eventually will kill some nuances - being dependent on the paper (or other support) color. RGB colors on screen make use of luminance of the screen pixels - you can have many nuances of a base color because you can control the pixel luminosity. CMYK is made for help transferring as much color as possible from screen (other color spaces) to paper - the only white (read light) come from the printing support (paper, plastic, etc). True, there are some special colors with fluorescent additives - but they can't go everywhere. That's why CMYK is not so equal with other screen based color spaces. On short, CMYK can not reproduce the same number of colors. The assumption that 4 channels is better than 3 is wrong on this case. You can only make sense working in pure CMYK when you want to have a very precise reproduction - but for this goal you need to know exactly the paper they use (printers) and color profiles they use for the offset. The best is to send them your work in RGB [16 bits / channel - for smoothest gradients ] and your monitor profile, then they will know how to get it right. Think that for RGB to CMYK you loose something anyway. 2011/3/22 Jacek Poplawski jacekpoplaw...@gmail.com: On Tue, Mar 22, 2011 at 4:52 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 3/22/11, Jacek Poplawski wrote: I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3. Right, all colorspaces are equal, but some are more equal than others :-) The willingness to go from a wider gamut to a narrower gamut for editing what will then go to a different color space once again is, er, equally amazing :) I just mean that they should be treated similarly :) For photography? I very much doubt that. When it comes to all things related to photography, the point is to preserve as many colors as possible. Which is how all those ProPhotoRGB and the like were introduced all those years ago. Jumping between wide and narrow gamuts effectively kills useful information. Hardly better colors, sorry. I was influenced by Dan Margulis. I try to follow his ideas in Gimp, instead Photoshop. He generally assumes that photography is made from 10 channels: R, G, B, L*, A*, B*, C, M, Y, K and you can use any subset of them to generate good quality image with good colours. (http://en.wikipedia.org/wiki/Dan_Margulis) And everything works as expected, with the exception of realtime preview. I just decompose image to LAB or CMYK then use these layers for increasing contrast, masking, etc... but using curves in LAB or CMYK is very hard without preview, because you have to imagine colors. The good thing is that GMIC has support for these colorspaces now, and RawTherapee is developing fast. PS. sorry for offtopic ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
No it isn't, because unless you go through a lot of extra work to avoid it, colors in the image that the used CMYK color space is unable to represent will get lost. True. Lot of work in studio then offset hardware will trow out different things ..because : paper quality, paper type ( coated / uncoated ) which affect reflection of white light (color nuances) ..hardware color profile ..etc. 2011/3/22 Martin Nordholts ense...@gmail.com: 2011/3/22 Jacek Poplawski jacekpoplaw...@gmail.com: CMYK is also best colorspace for skin color retouch by numbers, No it isn't, because unless you go through a lot of extra work to avoid it, colors in the image that the used CMYK color space is unable to represent will get lost. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Changing Features that I'm looking for...
..sure - better you can use Darktable - is a work in a fast progress - and has a lot of PRO features - is almost the same like Lightroom from Adobe for just basic photographic work Darktable is OK - you can use GIMP for compositions AFTER you do the your primary color processing in Darktable. It's up to you - I use Darktable only for pure photo color correction. Mostly, I use GMIC in GIMP because is integrated with a lot of other powerful features and I make compositions 90% of time. More about Darktable here: http://darktable.sourceforge.net/features.shtml About LabCurves - if you use Linux - saturation curve will not work if you not compile and install lcms 2 first (lcms 2 is not default in most distributions). 2010/8/19 Alexandre Prokoudine alexandre.prokoud...@gmail.com: On 8/18/10, oliver wrote: sorry it is a german text, but looking at the pictures might say enough: http://eye.de/tip_labstaerken.shtml Theese feature of changing color tones is, what I'm looking for since a while. Just use LabCurves http://www.mm-log.com/blog/2010-07-09/adaptive-saturation-curve-labcurves Or do everything in darktable It's necessary to have Lab-mode, which seems to be nonsense to some developers This is simply not true Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Changing Features that I'm looking for...
You should try : http://gmic.sourceforge.net/gimp.shtml I make a screenshot for you here : www.anioninternational.com/images/GMIC-for-GIMP.png OR you can try LAB Curves for GIMP : http://www.mm-log.com/lab-curves-gimp Sourceforge here : http://sourceforge.net/projects/mmfilters/files/ 2010/8/18 oli...@first.in-berlin.de: Hello, sorry it is a german text, but looking at the pictures might say enough: http://eye.de/tip_labstaerken.shtml Theese feature of changing color tones is, what I'm looking for since a while. It's necessary to have Lab-mode, which seems to be nonsense to some developers, but the results show me: it makes sense to use that mode. Maybe not as underlying representation, but available to users it should be. Maybe a conversion filter that makes RGB-Lab and Lab-RGB, available for users (and their scripts) would be helpful. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
probably he compile the a devel version - my previous compilation reported itself as 2.7.3 but the newest is 2.7.2 ;) 2010/8/11 Jernej Simončič jer...@ena.si: On Tuesday, August 10, 2010, 21:47:08, Dave wrote: I only use the brush tool, mostly with hard round brushes any size typically up to about 25 pixel radius, spacing 10. opacity on. no other brush dynamics set. Smaller the brush the better the performance is. Can you please fix your e-mail client so that it: - doesn't remove the References and In-Reply-To headers to enable proper threading of your messages - quotes the message you're replying to - doesn't send HTML when it's completely unnecessary (also, where did you find GIMP 2.7.3? The latest 2.7 release is 2.7.1) -- Jernej Simončič http://eternallybored.org/ Problems worthy of attack prove their worth by hitting back. -- Hein's Law ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Finally I get the GIMP Pro
...and seems to be real check please this link : http://www.photo-editor-pro.com/ -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] raw therapee open source ...
an interesting article about the movement of Raw Therapee to GPL. http://www.rawtherapee.com/?mitem=1artid=46 -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] raw therapee open source ...
sure - first I told you all some peoples sell GIMP giving impression of a Pro piece of software ( that mean money - which mean support and all related things ). Well if you allow this is ok is not my problem. the second spam is about Raw Therapee which move to GPL I was thinking someone on this list will be interested at least for the open source words inside the announce. I can not finish my message without my appreciation for you're kindly notice about the spam that I was in danger to create - who know maybe in the morning my spam length could have some kilometers - well, this way I will go to bed now and the planet is saved. Thanks again for your kindly words and empathy. 2010/1/8 Sven Neumann s...@gimp.org: Hi, can you please stop spamming this mailing-list with your links? Thanks, Sven -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer folders: layer masks?
sure I need the file ..you can send this file attaches at nemes.so...@gmail.com 2009/10/19 Brett for...@gimpusers.com: I don't know if the developers planned it or decided to take it out. but in the earlier dev versions of gimp before the single widow mode XD, when layer folders was first introduced their was the ability to add a layer mask to that folder.. .. I know probably that it was unplanned feature because gimp treated the folder like a layer. but in the recent builds of gimp the ability to add a layer mask to the folder has been taken out taken out. *heart attack* however loading the saved gimp file of a drawing that i coloured in gimp using the layer masks on folder loaded flawlessly and not only that i could still edit the mask... so it's not like um asking for a new feature but enabling something that's already there just probably not thought of using in that way. I think that it's a must have feature, and one that I'll dearly miss if it never comes back in. so i was wandering what people had to say on this. i might try and get in contact with the devs to see whats going on. Here's a screenshot with layer folders with layer masks in action. http://dl.getdropbox.com/u/1682366/Screenshots/gimp_folderlayermasks.png I can upload the gimp file if any ones interested. thanks for your time. -- Brett (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A new
But probably - if we can try to identify some generic use cases and then to identify a sum of possible techniques / technologies to solve those different cases, we can put a base for a future meta tool. GIMP has already some useful tools such as color to alpha, and color erase (for brushes), also Gmic has color replace. Maybe if we can have the posibility to pick (with a picker) which color is important to remain and then to pick which color (or range of colors) can go to aplha (probably with a color tolerance control [based on luminance, or other factors]), we can have a better precision for this (meta)tool, and saving a lot of time. This can go well in SIOUX tool. The same tool as is now but with some [+] color and [-] color selectors / pickers - which will manually refine the alghorithm after the initial selection is done (as is now in SIOUX). When the color selection manually refined is ready, our SIOUX based tool will know much better (if not exactly) about our intention, about which color is important and which is not. 2009/9/19 Gerald Friedland frac...@gmail.com: Hi Alex, Background extraction IS indeed tricky. First, different pictures require different tools. Everything where the foreground color is essentially one color, such as drawings will work best with a tool like Magic Wand. The foreground extraction Jenny was improving is intended to be used on photographs and works best when the fotograph features a clearly distinctive foreground but the foreground can easily contain millions of colors and as of now, the foreground can also have very fine structure. There is virtually no tool that can deal with transparencies, reflections, and other nasty stuff. When extracting objects with these issues you have to be lucky. Second, the way to think of these semi-automatic extraction tools is to compare them with a dish washer. Very often, the dish washer will do a good job and clean your dishes. So it'll save you work and it'll be cleaner than if you'd done it manually in the same time. However, for some pieces, the dish washer just doesn't work. Often these are the pieces that are particularly difficult, sometimes though you ask yourself: Why is this glass still dirty -- it's like all the other glasses? So there are people who do not want a dish washer because they want to be in absolute control of the cleaning process. However, would you stop producing, selling, using, and improving dish washers in general, just because they don't work always? The answer is of course: No because in sum they are useful. Same with automatic foreground extraction methods: For some images they save a lot of work, for others they might cause trouble. Some people will never use the tools because they want to be in complete control of the segmentation process. In sum they are useful though. Gerald On Thu, Sep 17, 2009 at 10:57 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Fri, Sep 18, 2009 at 2:34 AM, SorinN wrote: Well, every background extraction is tricky - I tried PhotoshopCS 4 tools - they seems to be trivial to use and seem to be easy - but for a complex task which need a lot of pixel precision you have to do a lot of manually corrections too so the final feelig is a kind of frustration - (with gimp magic wand progresive selection feature [drag over layer left / right], I can do the same thing quicker). Are you talking about http://help.adobe.com/en_US/Photoshop/11.0/WSFD9BA8C5-31BA-4fec-81F3-CF04EE5295FCa.html ? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A new
Well, every background extraction is tricky - I tried PhotoshopCS 4 tools - they seems to be trivial to use and seem to be easy - but for a complex task which need a lot of pixel precision you have to do a lot of manually corrections too so the final feelig is a kind of frustration - (with gimp magic wand progresive selection feature [drag over layer left / right], I can do the same thing quicker). In comparison with Photoshop - Jenny demos look perfect especially the tree. I hope the final tool will extract selection / selected colors direct (not just select pixels). 2009/9/15 Gerald Friedland frac...@gmail.com: Hi Martin, Conceptually, these pictures should work very well with SIOX -- also with the version that is already productively included in GIMP. Of course, individual cases might sometimes be more tricky. What Jenny added is the capability of a soft segmentation. This means segmenting regions where background and foreground might fall into the same pixel because of texture complexity or blurring of the picture. Gerald -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org -- On Mon, Sep 14, 2009 at 9:37 PM, Martin Nordholts ense...@gmail.com wrote: On 09/15/2009 03:50 AM, Jenny wrote: Hi all, In this Google Summer of Code season, a new detail refinement brush was done. This page is a demo: http://sites.google.com/site/gsoc2009/result-demo There might still be some bug. I'd love to get any feedback from you. Hi Jenny, Thanks for making that page. Would it be possible to also get a sample how the new SIOX performs for green screens? A zoom in at the edge of the extracted object to show how it handles alpha would also be interesting. These are the kind of pictures I mean: http://images.google.com/images?q=green+screen BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
The single big problem with the MDI was when the toolbox and / or other boxes remain on top of other opened windows when you minimize the canvas window. Now with GIMP 2.7 things are changed so MDI will not be such a problem. But indeed a single window app. was a necessary step. Will be super OK if we can revert to MDI ( for designers with 2 or 3 monitors will be OK too ). At least users will have choices... 2009/9/6 Ramón Miranda mirandagrap...@gmail.com: I like modular structures becouse they allows more custom changes. So this way you can change your layout of panels. But if all it would be in a single window , ithink lot of users would thanks that. becouse i hear a lot... Gimp is nice , but his gui is ugly and uncomfortable.i don´t like to see a lot of panels flying through my desktop Lets give it a try to a single window mode 2009/9/5 Martin Nordholts ense...@gmail.com On 09/05/2009 06:22 PM, Richard Nespithal wrote: A single-window mode would also turn 2.8 into a remarkable release is it possible, to switch back to multi-window mode in 2.8? That is not really relevant to this thread. (But yes of course it will be possible.) / Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- ___ Ramon Miranda http://ramonmirandavisualart.blogspot.com http://code.google.com/p/gps-gimp-paint-studio/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.7.0 Text Tool Crashes (built using MinGW/windows)
I can confirm that With the previous 2.7 build for windows text tool work ok 2009/8/25 BugByteMan bugbyte...@yahoo.com: Hello, Has anybody tried the text tool in Gimp 2.7.0 on windows? The program crashes with the following error: Pango:ERROR:pangowin32.c:###:pango_win32_font_finalize: assertion failed: (win32font-fontmap != NULL) Steps to reproduce: 1. Run gimp-2.7.0 2. Create new image (Ctrl+N) 3. Select Text Tool (T) 4. Click on canvas Thanks, BugByteMan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] question
On the main GIMP website they had a statement regarding your concerns : The terms of usage and rules about copying are clearly listed in the GNU General Public License. And here is the document : http://www.gimp.org/about/COPYING ..so good luck with the book - feel free to ask for here and there, tips and tricks - I have experiance in DTP / Web design - where I use GIMP + Inkscape for all my works now ( I know also very well Photoshop, Photopaint because I've coming from $MS world ). [ The only reason because I don't do myself a book about GIMP in romanian language is the lack of time ] Also, for tips / tricks ( Inkscape + GIMP ) in romanian language - you can try http://nicubunu.ro/ or search in Google for 'Nicu Buculei gimp'. Alte resurse utile ( probabil ;) ) pentru bibliografie : http://blog-de-webdesign.blogspot.com/2007/10/tutorial-gimp-pentru-ibunatatirea.html http://www.zona-foto.com/tutoriale-gipm/ http://tutoriale.sapte.ro/ probabil ar fi utile cateva randuri in carte despre licentele Creative Commons, acum disponibile in Romania ( artistii vor avea nevoie de ele ) : http://creativecommons.org/international/ro/ Mult succes !. 2009/1/8 Irina Rotariu rotariuirinastef...@gmail.com: hi i work in education and, during my activities with the kids, they ask me questions about working with images in GIMP. so, my idea is writing a book which helps them use the program. this book would be only for educational purposes, because there are not many students here in Romania who can afford some more expensive alternatives to GIMP, but their talent and possibilities in obtaining excellent results in image manipulation are questionless. i know that GIMP is a GNU program, but i have some questions about using the GIMP trademark (including name of the program, names of menus or different procedures etc). i am concerned about the copyright and about the possible fees which i might owe to the GIMP team and developpers. i hope you can give me more info about this, or about the legal procedures to be followed in my situation. hope to hear from you soon. best regards, irina ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] some minor nits
New Layer from Clipboard, New Layer from Screenshoot ( to be explicit and correct and to be online with the Usability rules ), anyway AS IS NOW is pretty OK. 2008/9/19 Liam R E Quin [EMAIL PROTECTED] On Fri, 2008-09-19 at 12:46 +0200, peter sikking wrote: the structure is good: 'New...' _must_ remain a first level menu item, agreed with that part... the rest is OK to have in a sub-menu. and with this... My solution is to rename the 'New' sub-menu to 'Create' so I think this is a good idea. Might be difficult to preserve the (artificial) distinction between New and Create. How about Get From or Make From? Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal new default layout starting 2.6
IN RESPONSE to Photoshop like idea : ... it should not look like Photoshop - SHOULD NEVER LOOK LIKE Photoshop - because Photoshop even with the new UI additions on CS3 look horrible - GUI for *Smurfs*. I see noone talk here about Corel Draw or Corel Photopaint GUI. For a new user, from the second 2 or 3 - it become clear who, why, when, where and how ( ...the last is a joke - how become clear after some mounts ot years depend on client material ;) ). In fact Corel GUI should give the base idea not PhotoShop ( in case if someone should give an ideea ) - I remember my first days on Corel, I was able to create my workspaces - with my floating or docked toolbars - with my prefered buttons - with my icons ( yep you can edit icons for buttons ), and to customize 500% more options than Photoshop. Then I ask myself ( for the first time - what is so great about Photoshop ?? [v.5 I think...]). Enfin, Ek kian - GIMP had a GUI Team now. Professionals. They work on GUI specs for the new GIMP and finally, I think the GIMP GUI will be OK anyway - with or without our opinions. If you go to http://gimp-brainstorm.blogspot.com/ you will see - before you - some 1000 other guys think / talk about exactly the same things. Ro be clean - exactly the same things. But their list is open and is never complete... THERE on brainstorm.org this discussion should take place - not HERE. Therefore I am designer too ( with some GUI Design knowledge - I won my money from such kind of things) - so I have 1507 or 1509 ideas right now - just try to imagine I'll post all 1507 or 1509 mails to THIS mailing list. The list wil become the SorinN's list ( they will do a sucesfull movie after few years [ 50 to be precise and ...damn I like that dream.. ] ). And GIMP will become ...maybe a simple text editor, even without syntax checker because the mailing list go in Abstract, unified with The Force... and all peoples, actors, singers, developers, detectives, criminals, etc - will loose any interest on GIMP development ( because of my GUI novels with much more eyeappeal than the boring if / else / while / for statements ). I hope you got the point - because I have to go to work. See ya later - on brainstorm.org. 2008/8/27 Ek kian [EMAIL PROTECTED] I agree with you, Alexia. maybe we can also look at Macromedia user interface, such as: Flash, Fireworks or Dreamweaver UI, their UI is different from Photoshop but still easy to learn, simple to manage, and extensible. Even i think Macromedia have better UI than Adobe. this is my suggestions for new GIMP default layout, i don't go to specific layout but i only have few things that imo need to give more attentions: - Big Workspace Graphics artist need a Big Workspace, just imagine our monitor as the canvas then users will want it all screen area is available as work area if possible so imo toolbox should be as small as possible and tool options should be able to hide and show using one-click or one-shortcut. - Workspace layout dialog Workspace layout with keyboards shortcut also can be saved and load with simple dialog with some presets (ready to use layout or default layout), so artist only need to setup the workspace and shortcuts that he comfortable and can bring that settings to other computer easily. Default layout is useful for education process which need consistent UI that will make easier to remember for the first time learner and if accidentally changed by user, we can easily put it back to the default layout. - Workflows. This is one thing that almost invisible on the programs UI, but if we carefully look at programs with great UI that surely for every aspect of the UI is tweaked to produce faster step to be done for all common workflows for every users. Common workflows only can be asked to the users that using the programs a lot and this users usually use it for their daily professional jobs, for example: photographer, they have photo post-processing or raw workflow, web designer, they have web layouting and slicing workflow, design graphic, they have color preparation and color separation workflow, and many more others. So every single UI elements such as icon, menu, shortcuts, etc is tweaked to improve how faster the workflows can be done, for example: if user doing selection then usually there is couple operation that follow that selection process so after the selection finish the mouse cursor change to move mode and right-click menu will show operation such as: cut, copy, delete or move. This need context menu feature, menu that can be changed based on activated tool. regards, ek kian On Sun, Aug 24, 2008 at 3:00 AM, Alexia Death [EMAIL PROTECTED]wrote: On Saturday 23 August 2008 22:51:51 [EMAIL PROTECTED] wrote: that's the second time you propose familiarity for a first time user. How can a first time user be familiar with anything? Or is this another Gimp should look and behave like Photoshop proposal? No it
Re: [Gimp-developer] 2.4 release date
That's why we need a Gimp PRO, Inkscape PRO, Scribus PRO - someone, a Firm / Govern / Foundation / Linux Distro / Billionaire ...or a mixture of them must hire core developers of all 3 projects - put them into a big WEB / DTP Core Linux project and manage development and releases. This will bring us - a single, unified 2D HQ rendering / printing core. Same advanced vector tools and similar vector manipulation methods on all 3 applications ( which need to work as a unit ) . Same live effects for vectors and rasters imagine how easy you can move Objects, Layers, Groups between applications just using drag-and-drop. Finally, the same HQ quality for print, the same PDF export engine. As separate projects - on Open Source World - this process can take long time from now. Manny years. So, for all 3 teams we need - 1. to accept Ideea ( to work on the same core for something PRO and new ); 2. to find or to found a crazy legal creature that can fund all development, 3. a good market policy - Joe, if U make free plugins with our toolkit - U don't need to pay for tools - for commercial plugins U have to pay for toolkit / libraries, etc. 4. At this step - If all OK - we all are OK that mean : Free and PRO versions, free and paid plug-ins / add-ons, free source, a nice toolkit with the best libs for developers, time (paid time) for developers - a continuous, sane, development / future for Open Source Suite, a good way to turn to Linux a bunch of programmers, a good way to prepare the future - giving best tools and practices for IT Universities, ...finally helping Linux to grow faster, helping world to be free. A bit strange maybe all that I'm saying here but... so quick ( movement on this direction ), so good. From 2008 MS will leave XP. All new computers will sell Vista. Before the big moment a lot of users / enterprises will search around for solutions. THAT will be for Linux The Day. If Linux will loose momentum, ...hmm, the progress will be damaged. but ..keeping a happy note ( as always ) for the final let the GEGL be with us ;) Sorin. P.S. Sorry Engel for my response - U ask for something and I told you crazy things. well - go on and don't give up with this crazy - because sooner or later will be real. and you won't miss the dance. 2007/4/15, [EMAIL PROTECTED] [EMAIL PROTECTED]: On Sat, 14 Apr 2007 19:19:06 +0200, Hal V. Engel [EMAIL PROTECTED] wrote: On Saturday 14 April 2007 08:04, Chris Puttick wrote: Hi Forgive me if I have missed this information, but can someone give an estimate for the release of 2.4? We are trying to move to open source throughout the organisation, but the graphics team are solidly stuck to Adobe Photoshop and Gimp 2.4 seems the most likely candidate to replace it. Unless the list thinks that 2.4 would not be a candidate to replace Photoshop? Thanks for your help. Regards Chris Release dates don't really exist for Gimp. I asked this same question last September and got the same polite silence. Due to the nature of Gimp development the new release happens when the work is done, rather than setting a target date and trying to get it out of the door on time. Development cycles tend to be rather long in general so you should probably follow Hal's comments and determine what you need and what can or can't be done with Gimp. One key thing to bear in mind when doing this is that Gimp does not aim to be a free clone of Photoshop. Some things are done differently and while the basic tasks are often similar the feature sets are different and things are often done differently. There are some things you can do with PS that you can't do with Gimp and vice versa. As he said you really need one of your graphics team to determine any important tasks that you cant manage to do with gimp and ask. It may simply be that you have not discovered how to do the task or it may add impetus to finish a feature in development. HTH. gg Chris, There is not nearly enough information in your post to answer that question. It depends entirely on the requirements of your graphics team. For example, if they work only with 8 bit/channel images then gimp 2.4 might be a good candidate to replace Photoshop. But if they work with 16 bit/channel images then it is not. But there are lots of other things that need to be considered and your note does not have any information on any if these variables. I would think that the best thing to do would be to find someone on your graphics team who is open minded enough to not get hung up on the differences in the UI who will actually evaluate the available functionality and give an assessment of what things your shop requires and how close current GIMP development is to meeting your needs. However it might be difficult to find someone who will be able to look past the UI differences. If at that point you find that there are features that your graphics
