[Gimp-developer] GIMP for mobile phones
Friends, I see there was a thread on this topic in May 2008. I'm frustrated by the inability to do some basic transformations of images on my Android smart phone, for example: rotating by just a degree or two, instead of a full 90 degrees; inability to change from RGB to grayscale; and inability to change the format of stored images (and probably others that I've not yet thought of). So, is there any progress on the idea of a GIMP ultra-ultra light for smart phones? ns ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP for mobile phones
On Tue, Sep 6, 2011 at 9:32 PM, Noel Stoutenburg wrote: Friends, I see there was a thread on this topic in May 2008. I'm frustrated by the inability to do some basic transformations of images on my Android smart phone, for example: rotating by just a degree or two, instead of a full 90 degrees; inability to change from RGB to grayscale; and inability to change the format of stored images (and probably others that I've not yet thought of). So, is there any progress on the idea of a GIMP ultra-ultra light for smart phones? In my not so humble opinion there is little to no point making a lighter version of GIMP for mobile devices. Simply put, desktop and mobile platforms rely on too different types of interaction with users. You can't strip stuff from GIMP and make a cool image editor for mobile. The further you go, the more you understand that you need tools that work differently and UI that is completely different. And that kinda kills the whole idea of lighter GIMP. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP for mobile phones
On Tue, Sep 6, 2011 at 1:56 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: So, is there any progress on the idea of a GIMP ultra-ultra light for smart phones? In my not so humble opinion there is little to no point making a lighter version of GIMP for mobile devices. Simply put, desktop and mobile platforms rely on too different types of interaction with users. +1. Having messed around with GIMP on my n900, it would be a nightmare to redesign for a touch interface. Then there's having to pull in GTK or replace it, battery issues, etc - a long list of non-fun :) Now a bare-bones editor based on GEGL/BABL might be interesting. I'm surprised there's not a basic editor for android already available. I'm still on maemo, so I wouldn't know though ;) Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 icon
Thanks a lot for the offer cc5 inator. These icons are very well made. i like them. And i like the idea of a serie of interviews with different artists. I think this could be very interesting for averybody, coders, designers etc. i would suggest some names because i can´t suggest mine (it is not polite, but i am available too if it is required :) ) *Guillermo Espertino.* http://www.ohweb.com.ar/ some videos here. http://www.youtube.com/user/gespertino More known as gez.he is an Expert in color management and integrates blender inkscape and gimp in his workflow. *JesusDA*. http://www.jesusda.com/ he only uses freesoftware. he is web designer and FLOSS consultant.he has made a lot of gimp tutorials and it is a reference here in Spain. *David Revoy* http://www.davidrevoy.com/blog.php freelance Artist from France. Worked in Sintel open source movie and it is involved in lot of projects. *Mozart Couto* http://blogdodesenhador.blogspot.com/ Fine arts and digital Artist. lot of experience with tablets, programs and techniques. the Word Dicas means tutorial. *Voxmortem* http://voxmortem.deviantart.com/ he is from poland and has some really interesting pieces of art. *LJFhutch* http://www.ljfhutch.com/ Specialized in game content creation. 2011/8/23 Tobias Ehni tobias.e...@googlemail.com Hi, thanks a lot for your offer and for providing samples of your work, too. I'm impressed that you did logos for blender and Battle for Wesnoth. I'm sorry that I can't tell you anything about creating the next logo, however there is also another way to contribute to the GIMP community. I'm planning to conduct interviews with graphic / interface / web designers and photographers. The idea is to better understand how users actually work in the field, i.e. what they do and how they do it. The insights from the interviews will be used to improve ease of use / usability of GIMP. Interviews are planned to take place in October, with an interview taking about one hour, via VoIP. I'd be very happy if you decided to help both GIMP team and users by being interviewed about your work. Feel free to contact me if you have any further questions. Kind regards, Tobi 2011/8/22 c55 inator c55ina...@gmail.com: Hello. I'm a graphic designer with experience in creating Application icons [Like this, this, or this] and I was wondering if I could be of service in helping create GIMP's next application icon. I use GIMP on a daily basis in my work and I'd love to contribute something back to the community. Any information regarding ways I could help would be greatly appreciated :) My work, if you're curious: http://dribbble.com/ollin ___ 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 -- ___ Ramón Miranda www.ramonmiranda.com GPS project 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
Re: [Gimp-developer] GIMP 2.8 icon
On 08/23/11 14:22, Tobias Ehni wrote: Thanks for suggesting some names from the artist scene. That's very helpful for me and the entire project. 2011/8/23 Ramón Mirandamirandagrap...@gmail.com: Thanks a lot for the offer cc5 inator. These icons are very well made. i like them. And i like the idea of a serie of interviews with different artists. I think this could be very interesting for averybody, coders, designers etc. i would suggest some names because i can´t suggest mine (it is not polite, but i am available too if it is required :) ) Guillermo Espertino. http://www.ohweb.com.ar/ some videos here. http://www.youtube.com/user/gespertino More known as gez.he is an Expert in color management and integrates blender inkscape and gimp in his workflow. JesusDA. http://www.jesusda.com/ he only uses freesoftware. he is web designer and FLOSS consultant.he has made a lot of gimp tutorials and it is a reference here in Spain. David Revoy http://www.davidrevoy.com/blog.php freelance Artist from France. Worked in Sintel open source movie and it is involved in lot of projects. Mozart Couto http://blogdodesenhador.blogspot.com/ Fine arts and digital Artist. lot of experience with tablets, programs and techniques. the Word Dicas means tutorial. Voxmortem http://voxmortem.deviantart.com/ he is from poland and has some really interesting pieces of art. LJFhutch http://www.ljfhutch.com/ Specialized in game content creation. 2011/8/23 Tobias Ehnitobias.e...@googlemail.com Hi, thanks a lot for your offer and for providing samples of your work, too. I'm impressed that you did logos for blender and Battle for Wesnoth. I'm sorry that I can't tell you anything about creating the next logo, however there is also another way to contribute to the GIMP community. I'm planning to conduct interviews with graphic / interface / web designers and photographers. The idea is to better understand how users actually work in the field, i.e. what they do and how they do it. The insights from the interviews will be used to improve ease of use / usability of GIMP. Interviews are planned to take place in October, with an interview taking about one hour, via VoIP. I'd be very happy if you decided to help both GIMP team and users by being interviewed about your work. Feel free to contact me if you have any further questions. Kind regards, Tobi 2011/8/22 c55 inatorc55ina...@gmail.com: Hello. I'm a graphic designer with experience in creating Application icons [Like this, this, or this] and I was wondering if I could be of service in helping create GIMP's next application icon. I use GIMP on a daily basis in my work and I'd love to contribute something back to the community. Any information regarding ways I could help would be greatly appreciated :) My work, if you're curious: http://dribbble.com/ollin ___ Oh if there is a competent artist offering to provide a decent looking logo/icon for Gimp , please don't refuse the offer. The current wilber annoys me every time I see it. I installed Gimp for my mother (a working artist) and she demanded that I change the icon on her desktop. Sorry if this was the handy work of someone's girlfriend, mother or beloved eight-year-old daughter but it is high time the project had a more credible image. If someone's offering, please ask for some sample designs. /gg/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 icon
@Tobias: Glad you like my work. I'd love to conduct an interview but unfortunately, VoiP is not an option, and it would have to be done via a text-based platform like Google Talk or email. I realize that this is rather inconvenient, so I won't trouble you by insisting on an interview–if you are still willing, I'd love the opportunity to contribute. I'm fine about the icon; I will probably release a replacement eventually, and I understand that you may wish to keep a consistent designer throughout GIMP's development. I look forward to seeing where the icon goes in the next release. An icon is a crucial part of a program, because to the user, it *is* the program–they drag the program around, place the program in their dock or desktop, and click on the program to launch it, all while using the metaphor of the icon. The icons of similar applications, like those of Pixelmatorhttp://jonwhipple.com/blog/wp-content/uploads/2010/10/PixelmatorIcon.png or Acorn http://macin.files.wordpress.com/2010/03/acorn-2-2-2-icon.png, use their icons to communicate the beauty and artistic nature of their respective programs. GIMP is a powerful, wonderful platform, but to many users–from the time they go to the website to the time they launch it–it doesn't seem that way. I trust that GIMP's next icon will have been designed with this in mind. Thanks for hearing my proposal, best of luck in GIMP development. I'd love to help if ever there is an opportunity, and I thank you all for creating such a great product :) On Tue, Aug 23, 2011 at 1:00 AM, Tobias Ehni tobias.e...@googlemail.comwrote: Hi, thanks a lot for your offer and for providing samples of your work, too. I'm impressed that you did logos for blender and Battle for Wesnoth. I'm sorry that I can't tell you anything about creating the next logo, however there is also another way to contribute to the GIMP community. I'm planning to conduct interviews with graphic / interface / web designers and photographers. The idea is to better understand how users actually work in the field, i.e. what they do and how they do it. The insights from the interviews will be used to improve ease of use / usability of GIMP. Interviews are planned to take place in October, with an interview taking about one hour, via VoIP. I'd be very happy if you decided to help both GIMP team and users by being interviewed about your work. Feel free to contact me if you have any further questions. Kind regards, Tobi 2011/8/22 c55 inator c55ina...@gmail.com: Hello. I'm a graphic designer with experience in creating Application icons [Like this, this, or this] and I was wondering if I could be of service in helping create GIMP's next application icon. I use GIMP on a daily basis in my work and I'd love to contribute something back to the community. Any information regarding ways I could help would be greatly appreciated :) My work, if you're curious: http://dribbble.com/ollin ___ 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
Re: [Gimp-developer] GIMP 2.8 icon
@Tobias Ah. The usability guy? I'd love to talk usability, noticed a few usability issues in 2.7.1 [the only one available to me on OSX, don't know how many issues have been fixed] if you're interested, send me an email :) I asked on #gimp and the one person who responded told me to ask the developer mailing list :) that's why I'm here. I could check again, I suppose. No worries, is there someone ultimately responsible for the icon? I suppose the icon is probably not a pressing concern among the devs :/ and I'm not familiar with how the icon got decided the last couple of times. Maybe talking to the previous designer would be a good idea? Thanks for helping, know the icon isn't your responsibility. I'll look forward to the interview, as I said I really appreciate the opportunity–hopefully you can send me more details as the time approaches? Oh, and most of what I said is drawn from the holy grail of ui, the Apple interface guidelineshttp://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/OSXHIGuidelines.pdf, which covers icons, gui, interaction–everything design related in an app. Very handy reference, it explains the standards and, more importantly, the thoughts behind them. Best of luck. On Tue, Aug 23, 2011 at 10:21 AM, Tobias Ehni tobias.e...@googlemail.comwrote: @c55 inator to clarify: I'm just the usability guy on the project, not a developer or maintainer. I'm not entitled to deciding upon the icon of GIMP. To find out who is, maybe checking the irc channel might help (http://www.gimp.org/irc.html). I did not mean to refuse your offer. I just wanted to recruit you for an interview, because your work showed me that you are one of the guys I'm interested in for these interviews... ;-) ...for which we can use a text-based platform (in October, when the interviews will be conducted). And I think you're right about what you're writing about icons. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP 2.8 icon
Hello. I'm a graphic designer with experience in creating Application icons [Like this http://cl.ly/2P0H2k3P1c3X0H3F0L0T/o, thishttp://fc07.deviantart.net/fs71/i/2011/047/b/7/wesnoth_by_c55inator-d39pckd.jpg, or thishttp://fc05.deviantart.net/fs71/i/2011/193/b/2/blender_replacement_by_c55inator-d3nogpb.jpg] and I was wondering if I could be of service in helping create GIMP's next application icon. I use GIMP on a daily basis in my work and I'd love to contribute something back to the community. Any information regarding ways I could help would be greatly appreciated :) My work, if you're curious: http://dribbble.com/ollin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
Hi, Sorry for the late reply. 2011/7/29 Cristian Secară li...@secarica.ro First of all, I think that Gimp should be GIMP in these strings: #: ../app/gegl/gimpoperationcagecoefcalc.c:65 msgid Compute a set of coefficient buffer for the Gimp cage tool #: ../app/gegl/gimpoperationcagetransform.c:104 msgid Convert a set of coefficient buffer to a coordinate buffer for the Gimp cage tool Fixed in git master. Second, I don't know what to do with the GimpCageConfig; is this something that is supposed to be known by a normal user ? It should be not translated ? #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation For now, this string won't go to the UI, but it might happen in the future, when gegl will be integrated, so I keep it marked for translation. Thanks for the report ! -- Michael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
2011/8/2 Michael Muré batolet...@gmail.com: #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation For now, this string won't go to the UI, but it might happen in the future, when gegl will be integrated, so I keep it marked for translation. Hi Michael, I strongly doubt it would make sense to bother our users with names of GObject classes, could you elaborate on why we should do this? Best 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
Re: [Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
I'm afraid I don't have a better answer than pippin told me this. If nobody object in the next few days, I will unmark them for translation. 2011/8/2 Martin Nordholts ense...@gmail.com 2011/8/2 Michael Muré batolet...@gmail.com: #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation For now, this string won't go to the UI, but it might happen in the future, when gegl will be integrated, so I keep it marked for translation. Hi Michael, I strongly doubt it would make sense to bother our users with names of GObject classes, could you elaborate on why we should do this? Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com -- Michael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
First of all, I think that Gimp should be GIMP in these strings: #: ../app/gegl/gimpoperationcagecoefcalc.c:65 msgid Compute a set of coefficient buffer for the Gimp cage tool #: ../app/gegl/gimpoperationcagetransform.c:104 msgid Convert a set of coefficient buffer to a coordinate buffer for the Gimp cage tool Second, I don't know what to do with the GimpCageConfig; is this something that is supposed to be known by a normal user ? It should be not translated ? #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation Cristi -- Cristian Secară http://www.secarica.ro ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP 2.8 schedule update, one month slip
Hi everyone, I just went through our GIMP 2.8 schedule at http://tasktaste.com/projects/Enselic/gimp-2-8 and made some adjustments and about a month was added to the release date estimate because of it. I would like to describe the adjustments I did, check the status of the various tasks, and discuss if we can do anything to get 2.8 out faster, or if there maybe is more work left to do on 2.8 than the schedule reflects. Changes I did: * Removed Bug 647834 - Stop using deprecated API in plug-ins because the problem doesn't exist in stable versions, only in development versions * Lowered size of Bug 631934 - Interaction between Old text parameters and new region specific text attributes from 8 to 5 working days because that seemed to me like a better estimate. mitch? * Added Make window mode switching less destructive, because we (I) need to prevent dock windows from being placed on top of each other when switching from single-window mode to multi-window mode * Added Single-window mode related bugfixing buffer because I expect some single-window mode related bugs to pop up that I need to fix * Added Bug 645120 - Disable color tools overlay dialogs Status of tasks: * I'm going to take care of all single-window mode related tasks + Bug 596410 - gimp-image-get-filename returns NULL for imported files. * Regarding Bug 642728 - Use cairo to draw Gfig, I don't think this blocks 2.8, we can use the old way of drawing in 2.8. Objections to me removing it from the schedule? I know Mikachu has started the porting. If he finishes before 2.8 is released that's great, but not having GFig ported to cairo in 2.8 isn't a blocker IMO. * Regarding Bug 304798 - Painting brush outline is slow, is this still a big problem? I know Alexia and mitch has worked on this. * Regarding our biggest tasks, Bug 612931 - Moving individual layer in layer group not possible with Move Tool and Bug 51112 - clipping groups or masking groups (like in Photoshop files), maybe I have over-estimated these? What do you think mitch? Any other tasks you'd like to discuss? Any tasks you'd like to add to the GIMP 2.8 schedule? Overall the progress on tasks have been good. The reason we have a small slip is only because new things have been added to the schedule that was not originally included. Thanks to everyone that has helped out completing tasks so far! Keep it up. / 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
Re: [Gimp-developer] GIMP 2.8 schedule update, one month slip
On Fri, Jul 15, 2011 at 2:19 PM, Martin Nordholts ense...@gmail.com wrote: * Regarding Bug 304798 - Painting brush outline is slow, is this still a big problem? I know Alexia and mitch has worked on this. Not enough to be a blocker I think. It COULD be optimized more, but as is, its faster than 2.6, that lagged even on 200px brush. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 106, Issue 6
Gabriel: I'm afraid that if you hand-picked the colors using CMYK and not using any other technical background but your experience, then your color system is fundamentally flawed. CMYK is a device dependent space and if you didn't keep that in mind at the beginning of the process, then it's likely that your color system is only good for the print shop where you printed your catalogs. Of course I can be wrong and you already took care of that. I'd like to know more abour your project. By the way, I speak spanish (I'm from Argentina) so feel free to contact me to my personal address if you want to continue the discussion. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 106lomoooool, Issue 2buoom9jiii97
M9i78kutukpouoolhooij8o Lupine jvuv8oi Kijkiouknbooy 9.?9 On Jul 2, 2011 2:00 PM, gimp-developer-requ...@lists.xcf.berkeley.edu wrote: ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Compile on Windows
Hi oupianpian_111 , thanks for your interest in GIMP. On Mon, 13 Jun 2011 21:56:08 +0800 (CST) oupianpian_111 oupianpian_...@126.com wrote: Hi, I have downloaded Gimp 2.6.0 and compiled on windows, but click There is already GIMP-2.6.11 - you should use that instead. the gimp.exe , it displays cannot run and cannot loaded libbabl-0.1.lib . The problem has been bothering me for teo weeks. Libbabl-0.1.lib and libgegl-0.1.lib are compiled in MinGw32 by myself . And I am not sure they are available. I sincerely hope you can help me solve this problem. Ouyang. They should be in your library path. try putting them there: http://www.geom.uiuc.edu/~daeron/docs/javaguide/native/stepbystep/_setlibpath.html Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ The Human Hacking Field Guide - http://shlom.in/hhfg Hacker sees bug. Hacker does not want bug. Hacker fixes bug. Please reply to list if it's a mailing list post - http://shlom.in/reply ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp Compile on Windows
Hi, I have downloaded Gimp 2.6.0 and compiled on windows, but click the gimp.exe , it displays cannot run and cannot loaded libbabl-0.1.lib . The problem has been bothering me for teo weeks. Libbabl-0.1.lib and libgegl-0.1.lib are compiled in MinGw32 by myself . And I am not sure they are available. I sincerely hope you can help me solve this problem. Ouyang.___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Guile 2.0
On Sun, 2011-06-12 at 14:46 +0200, Marco Ciampa wrote: On Sat, Jun 11, 2011 at 09:15:44PM -0400, Julian Graham wrote: Why not: create a (git) branch with this new engine and, one by one, adapt the scritps that does not work now to make them work with the new engine. When most if not all the script works out of the box, merge the branch into the master git branch? For a gimp release, seems to me that people's scripts need to carry on working as much as possible. So it's not a case of editing the scripts, but of editing guile (as Julian suggested I think) until pretty much all scripts either (1) run, or (2) give clear instructions on how to change them. A utility could be provided to change scripts, too. Liam [resent from the right address, sorry if you get this twice] -- 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
Re: [Gimp-developer] GIMP and Guile 2.0
Hi Liam, For a gimp release, seems to me that people's scripts need to carry on working as much as possible. So it's not a case of editing the scripts, but of editing guile (as Julian suggested I think) until pretty much all scripts either (1) run, or (2) give clear instructions on how to change them. A utility could be provided to change scripts, too. Yes, that is what I was suggesting. Given that my existing compatibility work is implemented as a set of syntax transformations, though, I don't think it would be that difficult to provide an external utility that does the same thing. Regards, Julian ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Usability News
Summarizing the changes / additions on http://gui.gimp.org/index.php/Usability: 1. GIMP will be on openusability (already mentioned) 2. Ideas of tasks for a possible intern 3. Recruiting will be based on the product vision (not on existing research) 4. Recruiting participants (interview partners) is highlighted as a crucial factor of succes for planned research 5. First ideas for recruiting I will attend Chaos Communication Camp in August. I'm looking forward to meeting the cross-section of the GIMP team that's going to be there, too. It seems like an opportunity to discuss ideas from the wiki, but as I'm still new to the project, I'm preparing for listening and learning as well. -Tobi 2011/6/11 Alexandre Prokoudine alexandre.prokoud...@gmail.com: On Tue, Jun 7, 2011 at 7:24 PM, Tobias Ehni tobias.e...@googlemail.com wrote: Dear list, I'm happy to announce that GIMP will be a project for http://openusability.org/ This means that there will be additional support by a student volunteering to do work in the area of usability. An appropriate candidate has to be found, yet. This process is administered by OpenUsability. I will post further details as soon as they are available. Thank you! There are also some additions on http://gui.gimp.org/index.php/Usability Could you please summarize them? 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
Re: [Gimp-developer] GIMP Usability News
On Tue, Jun 7, 2011 at 7:24 PM, Tobias Ehni tobias.e...@googlemail.com wrote: Dear list, I'm happy to announce that GIMP will be a project for http://openusability.org/ This means that there will be additional support by a student volunteering to do work in the area of usability. An appropriate candidate has to be found, yet. This process is administered by OpenUsability. I will post further details as soon as they are available. Thank you! There are also some additions on http://gui.gimp.org/index.php/Usability Could you please summarize them? 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] GIMP Usability News
Dear list, I'm happy to announce that GIMP will be a project for http://openusability.org/ This means that there will be additional support by a student volunteering to do work in the area of usability. An appropriate candidate has to be found, yet. This process is administered by OpenUsability. I will post further details as soon as they are available. There are also some additions on http://gui.gimp.org/index.php/Usability Kind regards Tobi ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] Fwd: scriipt-fu or python?
John Culleton wrote: We also have a whole fistful of plug-ins written in a compiler language. Most, if not all, of the compiled plug-ins for GIMP (that ship with it) are written in C. 1. In the script-fu examples: functions or modules or whatever within Gimp itself are called by certain names and fed certain values. Do these identical names work in Python also? I see no centralized list of functions by name. The GIMP procedure names called by plug-ins can be found in the Procedure Browser located under the Help menu. You may need to make some adjustments to the procedure names and constants you see listed based on the language you will be using for your script. There are differences such as whether GIMP_ is used in constants and whether procedure names use - or _. You can determine the differences by looking at the Procedure Browser information and comparing it to example scripts. 2. Does it really matter to Gimp in what language the script or plug-ins are written? You can use any language to create scripts for use with GIMP providing that you have a binding (ie. some routines written to provde the glue) to tie calls made in the language to the appropriate procedures in GIMP. Language bindings exist for Perl, Python, Scheme, and Ruby. But is that registration process also just another call to a module written in C? Yes, the registration process is just a call to one or more procedures within GIMP. There is a register procecedure so your script can be accessed by other plug-ins or scripts and another register procedure that will make your procedure accessible from the menus. If your script needs inputs, the register block allows you to set up the information for the parameters you want people to be able to set before the script beings its real work. Again, you can look at the example scripts and plug-ins on how this is done. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp
i downloaded gimp and wanted to try it out. I ran into two problems right away so I had to uninstall it. First off, i live and work in China. I am an American English teacher over here and believe when I say this, not everyone in China speaks and reads Chinese, just like not everyone who lives in Japan speaks and reads Japanese. I went to your help page on the web and it covers language change but not for windows 7. There has got to be a simpler way to change the language then what is in your help section. most programs i download give me the option of language before downloading. You really need to fix this. jerry ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
On Tue, May 3, 2011 at 2:06 PM, jerry chaney jerry.cha...@gmail.com wrote: You really need to fix this. ITs been fixed in the development version and you will be able to change the language in the preferences starting 2.8. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
thank you On Tue, May 3, 2011 at 20:10, Alexia Death alexiade...@gmail.com wrote: On Tue, May 3, 2011 at 2:06 PM, jerry chaney jerry.cha...@gmail.com wrote: You really need to fix this. ITs been fixed in the development version and you will be able to change the language in the preferences starting 2.8. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
On 03.05.2011 14:10, Alexia Death wrote: On Tue, May 3, 2011 at 2:06 PM, jerry chaney jerry.cha...@gmail.com wrote: You really need to fix this. ITs been fixed in the development version and you will be able to change the language in the preferences starting 2.8. But will you be able to navigate (even to) the preferences if it's all in Chinese? Then again - at least the GIMP 2.6 installer for Windows allows you not to install any translations, which in turn means all you'll ever get from GIMP will be the built-in, i.e. English, messages... -- Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria ...It might be written Mindfuck, but it's spelt L-A-I-N... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
On 5/3/11, jerry chaney wrote: i downloaded gimp and wanted to try it out. I ran into two problems right away so I had to uninstall it. First off, i live and work in China. I am an American English teacher over here and believe when I say this, not everyone in China speaks and reads Chinese, just like not everyone who lives in Japan speaks and reads Japanese. I went to your help page on the web and it covers language change but not for windows 7. There has got to be a simpler way to change the language then what is in your help section. most programs i download give me the option of language before downloading. You really need to fix this. If you don't speak and read Chinese, then why do you have system locale set to it? :) But, as Alexia already noted, the language switch is there in upcoming 2.8. 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] GIMP Developer Meeting
Hello, Due to my very unfortunate series of monday's in which I can't arrange a meeting, and due to the fact that some developers where on vacation, there wasn't any serious developer meeting in the last month except for the one in which GSoC mentors did some stuff regarding that. Since I'm having trouble keeping up with all development to collect topics for a meeting myself (and now I also have a GSoC which eats up more of my free time), and since I want to avoid meetings with no content, I'm emailing the list for a thread to discuss ideas. I will organize a meeting when there are enough ideas / enough time passed with no meeting (enough is a flexible thing). Throwing ideas that should be discussed: - GSoC students - Basic guidance on how to handle branches? When to push, where, etc. More important is getting them all with git access (for me it took 1 month to get, so it should be organized now in order not to stall real work...) - Plans for a new website - I know it was discussed, but I don't remember any decision. Major parts of the site need updating, including the tutorials section. - More? Thanks, LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting
On 5/2/11, LightningIsMyName wrote: Throwing ideas that should be discussed: - GSoC students - Basic guidance on how to handle branches? When to push, where, etc. More important is getting them all with git access (for me it took 1 month to get, so it should be organized now in order not to stall real work...) +1 - Plans for a new website - I know it was discussed, but I don't remember any decision. Major parts of the site need updating, including the tutorials section. +1, the discussion at gimp-web@ so far is a failure - More? Interaction with new usability team? Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting
Interaction with new usability team? Yes, please. ;-) If possible, please kindly consider scheduling the meeting before May 21st or after May 29th. I will be on vacation during that time. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 103, Issue 37
On 4/23/11, Anubhab Ray wrote: i just cant get the source code for gimp, can u please help-?? $ git clone git://git.gnome.org/gimp http://wiki.gimp.org/index.php/Users:Beginner_Developer%27s_FAQ Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 103, Issue 37
i just cant get the source code for gimp, can u please help-?? On 4/22/11, gimp-developer-requ...@lists.xcf.berkeley.edu gimp-developer-requ...@lists.xcf.berkeley.edu wrote: Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to gimp-developer-requ...@lists.xcf.berkeley.edu You can reach the person managing the list at gimp-developer-ow...@lists.xcf.berkeley.edu When replying, please edit your Subject line so it is more specific than Re: Contents of Gimp-developer digest... Today's Topics: 1. Re: GLIB version error while compiling GIMP withMacPorts (Tim Chen) -- Message: 1 Date: Thu, 21 Apr 2011 21:23:37 +0800 From: Tim Chen ht.timc...@gmail.com Subject: Re: [Gimp-developer] GLIB version error while compiling GIMP withMacPorts To: Tim Chen ht.timc...@gmail.com Cc: gimp-developer@lists.xcf.berkeley.edu Message-ID: 13069c72-6451-4e4f-bc03-a809d6ef5...@gmail.com Content-Type: text/plain; charset=us-ascii In the end, I build GIMP successfully with native gtk-osx and jhbuild. As a reference to those who might want to build GIMP on Mac, I wrote down my experience at https://sites.google.com/site/httimchen/2011_imagesvn/build-gimp-on-mac thanks for the help, -Tim On Apr 15, 2011, at 1:40 AM, Tim Chen wrote: woop, sorry for the short reply in last mail. Yes, I did install python gtk via MacPorts. It is actually kind of easy right now, just use port install py-gtk2, then all set :D As to recompiling gtk2, it seems like that the quartz variant on MacPorts introduces less problems. thanks for your reply, -Tim On Fri, Apr 15, 2011 at 1:36 AM, Tim Chen ht.timc...@gmail.com wrote: Yes, On Apr 15, 2011, at 12:52 AM, Akkana Peck wrote: Tim Chen writes: Note that one has to install gtk2 using command below to avoid some weird dependency problems Most Linux people have to recompile gtk2 (and its dependencies) to build GIMP now too. ImportError: could not import pygtk Did you build python-gtk? It's a separate package, with its own dependency set. Last time I watched someone try to build python-gtk from Macports, it turned out to be a lot easier just to download the tarballs and build and install them by hand. Macports wanted to bring in all kinds of crazy dependencies, including recompiling X and three different versions of Perl, all of them built from source. But maybe they've fixed the dependencies since then. ...Akkana ___ 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 End of Gimp-developer Digest, Vol 103, Issue 37 *** ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
On Monday, April 18, 2011 05:05:10 Mukund Sivaraman wrote: Sorry, the scheduled time is not fine for me. I had asked for this to be changed on IRC, but nothing was done for the last meeting's time too. The previous meetings have happened at around 1:30 AM localtime and 2:00 AM localtime. As there's a rather large Pacific ocean, there must certainly be a suitable time for this meeting that doesn't occur during the middle of anyone's sleeping hours. :) CET people can do 3 hours earlyer(17:00 GMT) at most I think, because that would put it at 19:00 - 20:00 CET(with dailight savings) and between 18:00-19:00 a lot of people are moving between their jobs and home. Doing the meeting in the middle of a workday is probably not feasible... For me personally in EET+dailight savings earlier is fine, but its up to CET and GMT people. --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
Hello, Theoretically, it should be possible to move the dev meeting and the gsoc meeting. I took a look at the world clock and the developer map, and it should be possible to move the meeting to 17:00 GMT. The places that will suffer from that decision are Canda and Brazil that will have a meeting starting on the morning, but it seems to be as if indeed most dead hours will be over the ocean. However, since I don't know who should attend the GSoC meeting, I'm not sure if we can move it that quickly. I'm trying to catch people on IRC now (I pinged the relevant people in the last 15 minutes), if anyone can tell me who should attend, I'll try making the arrangements. Regarding the developer meeting, I think that moving it should also be feasible - but again let's try to talk this on IRC in a time in which everyone are awake (such as now!). ~LightningIsMyName On Mon, Apr 18, 2011 at 10:42 AM, Alexia Death alexiade...@gmail.com wrote: On Monday, April 18, 2011 05:05:10 Mukund Sivaraman wrote: Sorry, the scheduled time is not fine for me. I had asked for this to be changed on IRC, but nothing was done for the last meeting's time too. The previous meetings have happened at around 1:30 AM localtime and 2:00 AM localtime. As there's a rather large Pacific ocean, there must certainly be a suitable time for this meeting that doesn't occur during the middle of anyone's sleeping hours. :) CET people can do 3 hours earlyer(17:00 GMT) at most I think, because that would put it at 19:00 - 20:00 CET(with dailight savings) and between 18:00-19:00 a lot of people are moving between their jobs and home. Doing the meeting in the middle of a workday is probably not feasible... For me personally in EET+dailight savings earlier is fine, but its up to CET and GMT people. --Alexia ___ 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
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
LightningIsMyName wrote: and it should be possible to move the meeting to 17:00 GMT. The places that will suffer from that decision are Canda and Brazil that will have a meeting starting on the morning, but it seems to be as if indeed most dead hours will be over the ocean. 1700 GMT is 1pm local time in the eastern time zone of Canada. I'm ok with that unless I wind up having a late lunch (which happens on occasion). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
Hi, During IRC conversation it was decided that moving by 3 hours would run into workday for some key people so the new suggested times would be 18:40GMT for GSoC meeting and 19:00GMT for dev meeting. If there are no major protests on these times, lets consider the meeting moved. http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T18 World clock times for the dev meeting. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
On Mon, Apr 18, 2011 at 7:01 PM, Alexia Death alexiade...@gmail.com wrote: be 18:40GMT for GSoC meeting and 19:00GMT for dev meeting. If there Silly me. 17:40GMT and 18:00 GMT that is. http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T18 World clock times for the dev meeting. This is correct. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting
Hello, The next GIMP Developer Meeting (#4) was scheduled for this week on tuesday, April 19th 2011 on 20:00 UTC. For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T20 As usual, the meeting will take place on #gimp-devel Developers who mentor at GSoC or any other person who has something to do with GSoC administration, should come 20 minutes earlier (a room for that will be announced on #gimp on that time) to finalize the GSoC applications and finish the process of GSoC student application. This is important! The agenda for this meeting isn't yet well defined - basically it's just discussing 2.8. The meeting page can be found on http://wiki.gimp.org/index.php/Hacking:Dev_Meeting_19_Apr_2011 Finally, due to request of some people, there is now a GIMP Developer Calander. For an online view in gmt/utc time, use the following link: https://www.google.com/calendar/embed?src=gj9trunel7ik41rhev111knfao%40group.calendar.google.comctz=Etc%2FGMT The ICS file for the calendar is available at https://www.google.com/calendar/ical/gj9trunel7ik41rhev111knfao%40group.calendar.google.com/public/basic.ics ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
- Forwarded message from Mukund Sivaraman - Date: Mon, 18 Apr 2011 07:28:06 +0530 From: Mukund Sivaraman m...@mukund.org To: LightningIsMyName lightningismyn...@gmail.com Cc: gimp-developer gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting User-Agent: Mutt/1.5.21 (2010-09-15) Hi LightningIsMyName On Sun, Apr 17, 2011 at 11:39:05PM +0300, LightningIsMyName wrote: Hello, The next GIMP Developer Meeting (#4) was scheduled for this week on tuesday, April 19th 2011 on 20:00 UTC. For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T20 As usual, the meeting will take place on #gimp-devel Sorry, the scheduled time is not fine for me. I had asked for this to be changed on IRC, but nothing was done for the last meeting's time too. The previous meetings have happened at around 1:30 AM localtime and 2:00 AM localtime. As there's a rather large Pacific ocean, there must certainly be a suitable time for this meeting that doesn't occur during the middle of anyone's sleeping hours. :) Mukund - End forwarded message - pgpfZzrbQVBQF.pgp Description: PGP signature ___ 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.3 Compile gdk_win32_window_foreign_new_for_display Issues
On 04/16/2011 07:08 AM, Partha Bagchi wrote: Trying to compile gimp 2.7.3. At least on my system (Windows 7, 64 bit), you need gdk_window_foreign_new_for_display instead of gdk_win32_window_foreign_new_for_display to compile. Is this right? Or Any suggestions? It's wrong. Apparently you are trying to build against a too old GTK+ ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule update
On 04/15/2011 09:57 AM, Alexia Death wrote: On Fri, Apr 15, 2011 at 9:08 AM, Martin Nordholtsense...@gmail.com wrote: Hi Two new items on the 2.8 schedule has been added: * Bug 647835 - Handle deprecated GTK+ API * Bug 647834 - Stop using deprecated API in plug-ins And one item has been fixed: * Include UI tests in nightly Jenkins builds Bug 304798 - Painting brush outline is slow Work on this bug has progressed considerably. It now performs very well in most cases. There have been plans to have an alternate simplified brush indicator, but that is not the subject of this bug. As far as I'm concerned this bug can be closed. You and mitch are the paint and brush masters, so if it's good enough for you, it's good enough for 2.8. Can you or mitch close the bug report then or at least move it off the 2.8 milestone please? It's just that when I do 1. new image 2. move around the default brush outline on the canvas then one of my CPUs work 100% in 2.7.2 and about 50% in 2.6.11. That it not necessarily a problem, just wanted to point it out. Regards, 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
[Gimp-developer] GIMP 2.8 schedule update
Hi Two new items on the 2.8 schedule has been added: * Bug 647835 - Handle deprecated GTK+ API * Bug 647834 - Stop using deprecated API in plug-ins And one item has been fixed: * Include UI tests in nightly Jenkins builds The last fixed item means that we run all our tests each night now, including UI tests. The estimated release date is now 2011-11-21. To track development progress and get an up to date release date estimate, simply visit http://tasktaste.com/projects/Enselic/gimp-2-8 . / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule update
On Fri, Apr 15, 2011 at 9:08 AM, Martin Nordholts ense...@gmail.com wrote: Hi Two new items on the 2.8 schedule has been added: * Bug 647835 - Handle deprecated GTK+ API * Bug 647834 - Stop using deprecated API in plug-ins And one item has been fixed: * Include UI tests in nightly Jenkins builds Bug 304798 - Painting brush outline is slow Work on this bug has progressed considerably. It now performs very well in most cases. There have been plans to have an alternate simplified brush indicator, but that is not the subject of this bug. As far as I'm concerned this bug can be closed. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule update
Martin Nordholts wrote: The last fixed item means that we run all our tests each night now, including UI tests. Um... ok... How does a buildbot run UI tests? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule update
2011/4/15 Kevin Cozens ke...@ve3syb.ca: Martin Nordholts wrote: The last fixed item means that we run all our tests each night now, including UI tests. Um... ok... How does a buildbot run UI tests? If the backend is X, you use http://en.wikipedia.org/wiki/Xvfb. Although it is often more convenient to use a common wrapper script called xvfb-run, which is also what our bulidbot uses. xvfb-run is actually used by default always (detected during configure-time), so if you have xvfb-run installed and runs make check, you won't see any GIMP UI while the UI tests are run, they will run in Xvfb. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 2.7.3 Compile gdk_win32_window_foreign_new_for_display Issues
Trying to compile gimp 2.7.3. At least on my system (Windows 7, 64 bit), you need gdk_window_foreign_new_for_display instead of gdk_win32_window_foreign_new_for_display to compile. Is this right? Or Any suggestions? Thanks, Partha ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] How to create a double button image
jamessk wrote: I am trying create a double button image like this www.jkwptest.net/b-login.gif Do you know how I create this in Gimp? It is possible? Is it possible? Yes. There is nothing special about that image. It is just two individual button images placed side by side on a common background. I would start with creating a file to be used as a template for a button (where you can change the label), and use that to create an image for each button separately. The final step is to create a new image using the two other buttons previously created. The template file will have several layers. Start with a transparent layer and fill it with the shape of the button you want and fill it with a gradient. You can use another layer for the outline and highlight around the button or put that on the first layer. Add a text layer on top that will be for the button label. Save this template (ie. as button-template.xcf). Set the text for the button as needed then Save As (or export) as a file for the first button image. Alter the text layer and enter the text needed for the second button. Save this new image. Now you can create a new file that is a bit more than twice the width of each individual button and create new layers using the previously saved pair of button images. Change background as desired. Save as .xcf (just in case), then Save As (or Export) your final image. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #4
Hello, The next GIMP Developer Meeting will probably take place in the GIMP IRC on April 11th 2011, 20:00 UTC (For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110411T20). I'm very busy and have no time to set up a meeting page on the wiki and/or arrange it. If some dev wants to take control of this one, I'll more than appriciate it. I'll try to attend the meeting tomorrow, but I can't promise... Sorry for the short alert :( LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp plugin ported to Gegln : Unable to create an account on BUGZILLA
Hello, I want to attach a patch( Gimp plugin ported to Gegl ) to BUGZILLA but I am unable to create an account on it as I did not receive the confirmation link for it. Where should I attach the patch then?? -- Shivani Maheshwari Under Graduation( BTech.) Indian Institute of Information Technology, Allahabad (Amethi Campus) India ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp plugin ported to Gegln : Unable to create an account on BUGZILLA
Have you looked into your spam folder? Regards, Tobias On Thu, Apr 7, 2011 at 08:52, shivani maheshwari shivani.mah...@gmail.com wrote: Hello, I want to attach a patch( Gimp plugin ported to Gegl ) to BUGZILLA but I am unable to create an account on it as I did not receive the confirmation link for it. Where should I attach the patch then?? -- Shivani Maheshwari Under Graduation( BTech.) Indian Institute of Information Technology, Allahabad (Amethi Campus) India ___ 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
Re: [Gimp-developer] Gimp plugin ported to Gegln : Unable to create an account on BUGZILLA
Ya i did. It was not there also. In addition I sent a mail to bugmas...@gnome.org reporting the problem. But there is no reply from there. I think there is some problem with their server as I tried signing-up with a different email-id also. Kindly help On Thu, Apr 7, 2011 at 12:25 PM, Tobias Jakobs tobias.jak...@googlemail.com wrote: Have you looked into your spam folder? Regards, Tobias On Thu, Apr 7, 2011 at 08:52, shivani maheshwari shivani.mah...@gmail.com wrote: Hello, I want to attach a patch( Gimp plugin ported to Gegl ) to BUGZILLA but I am unable to create an account on it as I did not receive the confirmation link for it. Where should I attach the patch then?? -- Shivani Maheshwari Under Graduation( BTech.) Indian Institute of Information Technology, Allahabad (Amethi Campus) India ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Shivani Maheshwari Under Graduation( BTech.) Indian Institute of Information Technology, Allahabad (Amethi Campus) India ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp Plugin semi-flatten ported to Gegl op.
Hello,
I am Shivani and have ported the gimp plugin 'semi-flatten' to Gegl op. This
is in addition to the task( posted earlier to the list ) - giving the code
review and algorithm description as mentioned in Gsoc
taskshttp://wiki.gimp.org/index.php?title=Hacking:GSoC_2011/Ideas
list.
Kindly review the patch -
diff --git a/semi-flatten.c b/semi-flatten.c
index e69de29..ff18455 100644
--- a/semi-flatten.c
+++ b/semi-flatten.c
@@ -0,0 +1,70 @@
+/* Semi-flatten plugin using gegl op
+ *
+ * Shivani Maheshwari
+ *
+ */
+
+#include config.h
+#include glib/gi18n-lib.h
+
+#ifdef GEGL_CHANT_PROPERTIES
+
+#else
+
+#define GEGL_CHANT_TYPE_POINT_FILTER
+
+#define GEGL_CHANT_C_FILE semi-flatten.c
+
+#include gegl-chant.h
+
+static void prepare (GeglOperation *operation)
+{
+ gegl_operation_set_format (operation, input, babl_format (RGBA
float));
+ gegl_operation_set_format (operation, output, babl_format (RGBA
float));
+}
+
+static gboolean
+process (GeglOperation *op,
+ void*in_buf,
+ void*out_buf,
+ glongn_pixels,
+ const GeglRectangle *roi)
+{
+ GeglChantO *o = GEGL_CHANT_PROPERTIES (operation);
+ gfloat *GEGL_ALIGNED in_pixel;
+ gfloat *GEGL_ALIGNED out_pixel;
+ glong i;
+
+ in_pixel = in_buf;
+ out_pixel = out_buf;
+
+ for (i=0; in_pixels; i++)
+{
+ out_pixel[0] = (in_pixel[0] * in_pixel[3]) / 255 + (in_pixel[0] *
(255-in_pixel[3])) / 255;
+ out_pixel[1] = (in_pixel[1] * in_pixel[3]) / 255 + (in_pixel[1] *
(255-in_pixel[3])) / 255;
+ out_pixel[2] = (in_pixel[2] * in_pixel[3]) / 255 + (in_pixel[2] *
(255-in_pixel[3])) / 255;
+ out_pixel[3] = (in_pixel[3] == 0) ? 0 : inpixel[3];
+ in_pixel += 4;
+ out_pixel += 4;
+}
+ return TRUE;
+}
+
+static void
+gegl_chant_class_init (GeglChantClass *klass)
+{
+ GeglOperationClass*operation_class;
+ GeglOperationPointFilterClass *point_filter_class;
+
+ operation_class= GEGL_OPERATION_CLASS (klass);
+ point_filter_class = GEGL_OPERATION_POINT_FILTER_CLASS (klass);
+
+ operation_class-prepare = prepare;
+ point_filter_class-process = process;
+
+ operation_class-name= gegl:semi-flatten;
+ operation_class-categories = color;
+ operation_class-description = _(Semi flattens the image);
+}
+
+#endif
--
Shivani Maheshwari
Under Graduation( BTech.)
Indian Institute of Information Technology,
Allahabad (Amethi Campus)
India
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] Error on the bash command line
houghi wrote: As these were scripts that were provided by my distro, I assume they are somewhat 'standard' for GIMP. To know there are errors in it, is perhaps more importand to solve then me getting errors. Perhaps a good time to overhaul all the ones that come standard with GIMP. GIMP 2.7 is a development release and it has a large number of changes in the PDB API. It is the biggest PDB change in a while and, with the moving of some procedure parameters to context settings, most scripts are or might be affected. There are a number of outstanding patches I am reviewing for Script-Fu scripts to address a lot of the changes. With a high percentage of the 100 Script-Fu scripts requiring some changes you can expect some issues with Script-Fu scripts for a while. I am planning to have all the scripts updated for the 2.8 release. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] automating tasks
Gergely Buday wrote: I would like to glue a logo and some dozen of pictures automatically, ie. the logo and the picture has the same height and to glue them at the common edge. How can I do that? Should I use script-fu? You could write a script using Script-Fu (or one of the other language bindings). If I'm reading your message correctly, you want to add a logo to a number of pictures. You might find it easier to do what you want using the -coalesce option to the montage program which comes with ImageMagick. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] automating tasks
http://www.imagemagick.org/Usage/anim_basics/#coalesce ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hello, no organized meeting log this time, for various reasons, however I'm attaching below the list of decided actions in the meeting, along with some other off-topic points that were discussed: ** GSoC Student Applications ** Core developers sign up as mentors (for GSoC) schumaml: Write mail about application is open, and required skills, and required code example ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). For UI, porting widgets to GtkBuilder is an option (and then we'll use Glade and UI xml files), but any action on the UI is postponed until we get 3.0 out! ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. ** bringing UI crew to LGM ** Will be discussed with mitch and schumaml on the financial aspect (using gimp funds) when the team is fully assembled (parts of it are already assembled - hurray for guiguru and congrats for the new team memebers!) ** Resource management for 2.8 ** One member of the new UI team (lead by guiguru) will take care of that ** Offtopic ** Seems as if most GIMP team can't attend LGM this year, but there may be a GIMP village in the Chaos Communication Camp (http://events.ccc.de/2010/08/10/chaos-communication-camp-2011/) as most developers want/plan to attend it. UI team members will start hanging on IRC once the team is assembled. Many developers suggested help in setting them up with build environments and every other thing they need. This will happen soon, so be nice to the new guys ;) ~LightningIsMyname ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/29 LightningIsMyName lightningismyn...@gmail.com: ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). Hi, Unfortunately I couldn't attend the meeting and affect the outcome of the discussion, but I still want to comment on it: GObject C boilerplate is a general productivity problem not bound to any specific kind of code, it doesn't make sense to treat core and UI code differently. Regarding code generators: that's basically how we will use Vala, I don't see why e.g. turbine would be better to use for this. Regards, 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
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 2011-03-29 14:09, LightningIsMyName wrote: ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. So you set the quality slider to 95 to ensure files will be big, but set sampling to 2x1 to ensure the image quality will be poor? I don't see the sense in this. Also the JPEG export plug-in has had a stored default for years. What are you trying to add? Note that if the source file is JPEG the plug-in offers similar settings to the originating file by default. You can still click load defaults to override it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/29/2011 02:45 PM, Martin Nordholts wrote: 2011/3/29 LightningIsMyNamelightningismyn...@gmail.com: ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). Hi, Unfortunately I couldn't attend the meeting and affect the outcome of the discussion, but I still want to comment on it: GObject C boilerplate is a general productivity problem not bound to any specific kind of code, it doesn't make sense to treat core and UI code differently. Right, it doesn't make sense to make a difference here. And the summary doesn't quite reflect the result of the discussion. Regarding productivity: I don't know how you measure more productive on a scale from zero to zero. There is simply not much contribution currently, and blaming GObject for that is lame, and attempting a fix where you earlier put the blame is activism. As I said before, let's please work on our public interface, That maybe has the potential of attracting new developers. I already gave the reasons why I think adding another language won't. Regarding code generators: that's basically how we will use Vala, I don't see why e.g. turbine would be better to use for this. Turbine is a comfortable replacement for: - copy existing class with SameNumberOfWords - do s/OldName/NewName/ and s/old_name/new_name/ - remove junk - skeleton done Vala is a programming language and *not* a code generator. You also don't consider gcc a code generator because it has some internal representation in between C and machine code. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 3/29/11, Michael Natterer wrote: As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. The wiki transition seems to be stuck as well. What exactly has to be done? The news is what I already take care of. What else has to be done apart from that? Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/29/2011 06:54 PM, Alexandre Prokoudine wrote: On 3/29/11, Michael Natterer wrote: As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) - Website updates - News - Wiki - Blogs - Maybe we should have a GIMP blog aggregator? - More frequent developer releases (my fault, I know) The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. I think Jimmac is pretty busy, so maybe somebody should pick up the work. Also, I don't think we absolutely need a new website, just a few people who can trigger website updates after something has been pushed to git, at least as long as auto-updates are broken. I'll poke Sven about that. The wiki transition seems to be stuck as well. What exactly has to be done? I'm in contact with Shawn, and the DNS entry should point to Alexia's wiki soon. The news is what I already take care of. That much appreciated :) What else has to be done apart from that? Whatever people are capable and wanting to do :) Everybody involved with the project is invited to join the effort. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 3/29/11, Michael Natterer wrote: On 03/29/2011 06:54 PM, Alexandre Prokoudine wrote: On 3/29/11, Michael Natterer wrote: As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) - Website updates I think I could add recent books, including the one from Packt. - News - Wiki Discussed above and below - Blogs - Maybe we should have a GIMP blog aggregator? We used to have layers.gimp.org exactly for that, but it's gone. I think we can reuse infrastructure from graphicsplanet.org that Mukund and me maintain. Any suggestions on URL? Maybe simply blogs.gimp.org? - More frequent developer releases (my fault, I know) Since you insist :D The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. I think Jimmac is pretty busy, so maybe somebody should pick up the work. Also, I don't think we absolutely need a new website, just a few people who can trigger website updates after something has been pushed to git, at least as long as auto-updates are broken. I'll poke Sven about that. Can't this be automated? The wiki transition seems to be stuck as well. What exactly has to be done? I'm in contact with Shawn, and the DNS entry should point to Alexia's wiki soon. Cool Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 2011-03-29 14:09, LightningIsMyName wrote: ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. So you set the quality slider to 95 to ensure files will be big, but set sampling to 2x1 to ensure the image quality will be poor? I don't see the sense in this. Also the JPEG export plug-in has had a stored default for years. What are you trying to add? Note that if the source file is JPEG the plug-in offers similar settings to the originating file by default. You can still click load defaults to override it. I did a couple of quick tests with an image with photos and design elements (type and areas with solid fill) and I got better results both in overall quality and file size using 1x1 and smaller quality factors than using worse subsampling and higher quality factors. In my test the best relationship between quality and filesize was using quality=92, subsampling=1x1 and floating point for the DCT method. The resulting file was smaller than the ones I exported with quality set in 95 and 2x1 or 2x2 for subsampling. with 1x1 subsampling and quality set in 90 the edge artifacts in type and solid fill areas became visible but the edges were sharp as in the original. The photo didn't show any noticeable compression artifacts. That's completely different with 2x1 and 2x2 subsamplings. All the edges became softer and when the quality factor is high enough to avoid compression artifacts the resulting file is larger than when 1x1 was used. So I'd suggest a different default quality setting for jpg: 92 / 1x1 / floating point. If file size matters (the size gain isn't too significative, but still), a quality factor of 90 will still give considerably better quality than the current defaults. and add a hack to save defaults (using something like the PNG plugin does, or something more elegant) I don't understand what's missing in the current implementation. I could change my defaults and store the new configuration as default through the advanced options of the jpeg export plugin (in 2.6.x) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/27 Michael Natterer mi...@gimp.org: On 03/27/2011 04:45 PM, Martin Nordholts wrote: On 03/27/2011 02:12 PM, Michael Natterer wrote: As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. Just like the people who only know how to write java or #C code. They know how to use all the fancy classes, but they have never implemented a list or anything lowlevel themselves. I don't want people who know vala, but don't had to learn GObject. Absolutely not. Knowing the foundations is an absolute prerequisite for any serious programming. How is it a problem that our code becomes so easy that even dumb programmers can understand and improve it when we are not forced to include patches from such dumb programmers? Why would an open source project have as a goal to keep its code complex in order to limit the set of people that are able to help out, especially a project that wants more people to contribute? Besides, it is not only dumb programmers that uses higher-level languages such as C# and Java. / 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
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On Mon, Mar 28, 2011 at 10:26 AM, Martin Nordholts ense...@gmail.com wrote: How is it a problem that our code becomes so easy that even dumb programmers can understand and improve it when we are not forced to include patches from such dumb programmers? This not how I understood mitch... I understood it as a valid concern that if basics are hidden way another layer new contributors never learn basics at all. And where that leads I have seen on some java developers first hand. It leads to My personal option is sort of split on this. On one hand less there is boilerplate code, less there are chances of making white-space errors, on the other... I looked into to the pdb recently... The perl generator code there was a huge hindrance to understanding and writing the code plus what mitch talked about. For me personally the GObject boilerplate never was an issue. There was plenty of code to copy-paste from even if I did not understand it completely. Besides, you ever write it once per class and if it changes it's a lot of quick and straightforward fixes. What is an issue is UI maintenance. Having to manually stack GTK containers without any preview is absolute pain. Once I used glade to get my structure right and then translated it into code... So whats wrong with finding away to make use of the GTKBuilder more? -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Martin Nordholts (ense...@gmail.com) wrote: 2011/3/27 Michael Natterer mi...@gimp.org: And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. How is it a problem that our code becomes so easy that even dumb programmers can understand and improve it when we are not forced to include patches from such dumb programmers? They're bound to hit problems that out of their scope, leaving them perplexed. My experience with vala is deeply tainted by the (now resolved) bug https://bugzilla.gnome.org/show_bug.cgi?id=587683 Bye, Simon PS: I don't like how you rephrase mitch's argument with offending words. -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hello On Mon, Mar 28, 2011 at 6:27 PM, Kevin Cozens ke...@ve3syb.ca wrote: It's a good thing I asked that we clarify the problem as I was thinking it was something else entirely. Pointers to a couple of files that show the issue of a lot of boilerplate code would be good so we can all see the extent of the problem. If the problem really is with gObject and the need for a lot of boilerplate code there are several options. ... 3. Create template file(s) with all the typical boilerplate code. If people are copying from existing files it might be easier to just create some template files that can be used as the starting point. 4. Write a program to generate the boilerplate code. If template files could not be made to handle the typical use cases, a program could be made where a person could answer questions or set options and have it generate a file with all the required boilerplate code. 5. Use a chanting system similar to what is used in BABL and GEGL. The chanting system in BABL/GEGL seems to work well in that it makes it easy (or easier) to work with things like the GEGL operation files without the need for a deep understanding of gObject. As one of the supporters for the Vala suggestion, I am willing to give up the vala option, for options 4 and 5 (3 is sort of what many of us already do - copy paste). I don't know how easy is option 5 to write, but option 4 does seem more or less possible. also, the fact is that most work with gobject code is writing it in the first time, so I do think that a generate once tool would solve my problem. Again, I'm speaking just for myself. We have a meeting today, and we can *try* and sort this out then. I do agree that introducing another language isn't such a good idea, and what Simon showed doesn't increase my trust in vala (even if I like that language)... ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/27 Kevin Cozens ke...@ve3syb.ca: LightningIsMyName wrote: *** Optional topic: Re-Discussing GIMP's programming language *** Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala into gimp, claiming that it will scare off developers (more than the simple C GObject code). Before talking about which new programming language is needed(?) in GIMP we should make sure the problem is clearly defined as to *why* we need something new. What problem is the new language going to solve? IIRC, it had something to do with creation of GUI stuff (such as dialog boxes?). If that is the case, the language should be irrelavant. There are other tools that can be used to more easily make a GUI. One that comes to mind is a tool like Glade that can generate a file that can be used with with a library (GtkBuilder?) to show the contents of the file. I may be completely off base here because I haven't heard a clear definition of the problem. The problem with using C for everything is that we have to spend time on managing boilerplate GObject C code, like manually initialize vtables for example. We could spend this time doing things that benefits our users instead. When I get time, I will port GimpTag to Vala so we can see how the introduction of Vala affects our codebase, autotools etc. If we bump into a lot of problems, we can drop the idea of using Vala in GIMP, but if it turns out we can become more productive by using Vala, we should start using Vala more. / 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
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/27/2011 11:36 AM, Martin Nordholts wrote: 2011/3/27 Kevin Cozenske...@ve3syb.ca: LightningIsMyName wrote: *** Optional topic: Re-Discussing GIMP's programming language *** Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala into gimp, claiming that it will scare off developers (more than the simple C GObject code). Before talking about which new programming language is needed(?) in GIMP we should make sure the problem is clearly defined as to *why* we need something new. What problem is the new language going to solve? IIRC, it had something to do with creation of GUI stuff (such as dialog boxes?). If that is the case, the language should be irrelavant. There are other tools that can be used to more easily make a GUI. One that comes to mind is a tool like Glade that can generate a file that can be used with with a library (GtkBuilder?) to show the contents of the file. I may be completely off base here because I haven't heard a clear definition of the problem. As I already mentioned before. I am very much against the introduction of another language into the GIMP core. The problem with using C for everything is that we have to spend time on managing boilerplate GObject C code, like manually initialize vtables for example. We could spend this time doing things that benefits our users instead. So when you write code, how much time do you spend writing the boilerplate? 10%? I would say it's much much less, because writing the code is a small fraction of the time actually spent on the code, the rest is debugging, refactoring, reading and reading it over and over again. The percentage of writing the actual boilerplate rapidly drops to a few percent. And what are things that benefit our users we could do instead? Thats a complete non-statement. Programming a complex thing like GIMP is hard, no matter how supposedly easy you make the programming language. The problem is not the programming language, or GObject, it's simply the complexity of GIMP's object system, and that complexity is unfortunately unavoidable, and is not going to decrease by adding another layer to it. And programming in general is *hard* to do right, and whoever is not capable of doing it should rather stay away from it. Yes, there is an entry barrier due to GObject, but as our experience with the last few years of GSoC, and various new contributors has shown, that was never the problem. They all end up writing more-or-less proper GObject code. The problem in their code is simply the lack of understanding for GIMP's object system, and that lack is *completely*normal* and natural given how complex GIMP is. They all get better if they stick with the project, which is also completely normal. I often hear how well the GIMP source is structured, and people point others to GIMP as an example of properly done code. That's a reputation which is not going to improve by adding another fringe language. As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. When I get time, I will port GimpTag to Vala so we can see how the introduction of Vala affects our codebase, autotools etc. If we bump into a lot of problems, we can drop the idea of using Vala in GIMP, but if it turns out we can become more productive by using Vala, we should start using Vala more. Yes we should get more productive, but adding a new language should acheive that? We should rather work on our public interface, which is the web page, the wiki, the devel web page. All that stuff is not really active. If we have a hard time finding people who are willing to do this (and a lot of people are capable of doing web stuff), how is increasing the complexity of the GIMP core going to help us in any way? Introducing development tools like automated tests, or the build system you set up (did I say thanks for that already?) does indeed help a lot. Adding another language to the core in an attack of activism doesn't. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/27/2011 02:12 PM, Michael Natterer wrote: So when you write code, how much time do you spend writing the boilerplate? 10%? I would say it's much much less, because writing the code is a small fraction of the time actually spent on the code, the rest is debugging, refactoring, reading and reading it over and over again. The percentage of writing the actual boilerplate rapidly drops to a few percent. I don't have any exact figures, but it takes enough time to make it annoying. Also don't forget to look at this from the point of view from someone who doesn't know anything about GObject boilerplate code. It is quite an obstacle to climb over, not only to be able to write GObject boiler plate fluently, but also to read it fluently. This becomes especially problematic in the context of temporary contributions such as GSoC, where a substantial amount of the initial time in a project is spent on getting students up to speed on how GObject works. And what are things that benefit our users we could do instead? Thats a complete non-statement. Programming a complex thing like GIMP is hard, no matter how supposedly easy you make the programming language. I meant that instead writing boilerplate, we and others can write code that adds actual functionality. The problem is not the programming language, or GObject, it's simply the complexity of GIMP's object system, and that complexity is unfortunately unavoidable, and is not going to decrease by adding another layer to it. Vala is not another layer, it's just another way to write GObject code where the boiler plate is taken care of by the valac compiler. And I don't see the GIMP object system as very complex, it is what you'd expect for a program like GIMP. I actually often find myself reluctant to add new classes because of all the extra work the boiler plate requires. This isn't a healthy situation; adding new classes should be effortless. I often hear how well the GIMP source is structured, and people point others to GIMP as an example of properly done code. That's a reputation which is not going to improve by adding another fringe language. The GIMP code *is* well structured, but I don't see how that is an argument either way. I don't want to add Vala to bring structure into the code, I want to add Vala to get rid of all the boiler plate code. As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... / 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
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hi, On Sun, Mar 27, 2011 at 3:12 PM, Michael Natterer mi...@gimp.org wrote: So when you write code, how much time do you spend writing the boilerplate? 10%? I would say it's much much less, because writing the code is a small fraction of the time actually spent on the code, the rest is debugging, refactoring, reading and reading it over and over again. The percentage of writing the actual boilerplate rapidly drops to a few percent. Isn't debugging, refactoring and code reading (finding references, going to definition, etc etc -- noone reads code like a book, right?) many times faster in Java or C# IDEs ? AFAIK Vala could be integrated into IDEs (Eclipse, Monodevelop, Valide) in a similar way as Java or C# and provide many benefits that most of the developers use for many years already.. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/27/2011 04:45 PM, Martin Nordholts wrote: On 03/27/2011 02:12 PM, Michael Natterer wrote: As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. Just like the people who only know how to write java or #C code. They know how to use all the fancy classes, but they have never implemented a list or anything lowlevel themselves. I don't want people who know vala, but don't had to learn GObject. Absolutely not. Knowing the foundations is an absolute prerequisite for any serious programming. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/25/2011 02:31 PM, LightningIsMyName wrote: *** Other topics *** Any other suggestions should be suggested by replying to this email, or adding it directly to the wiki (if you have permissions to edit the wiki). Hi, What's the status of making wiki.gimp.org resolve to gimp-wiki.who.ee so e.g. the roadmap URL becomes http://wiki.gimp.org/index.php/GIMP_Roadmap rather than the current http://gimp-wiki.who.ee/index.php/GIMP_Roadmap ? Regards, 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
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
LightningIsMyName wrote: *** Optional topic: Re-Discussing GIMP's programming language *** Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala into gimp, claiming that it will scare off developers (more than the simple C GObject code). Before talking about which new programming language is needed(?) in GIMP we should make sure the problem is clearly defined as to *why* we need something new. What problem is the new language going to solve? IIRC, it had something to do with creation of GUI stuff (such as dialog boxes?). If that is the case, the language should be irrelavant. There are other tools that can be used to more easily make a GUI. One that comes to mind is a tool like Glade that can generate a file that can be used with with a library (GtkBuilder?) to show the contents of the file. I may be completely off base here because I haven't heard a clear definition of the problem. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 3/27/11, Kevin Cozens wrote: Before talking about which new programming language is needed(?) in GIMP we should make sure the problem is clearly defined as to *why* we need something new. What problem is the new language going to solve? IIRC, it had something to do with creation of GUI stuff It has *something* to do with too much gobject boilerplate code. 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] GIMP Developer Meeting #3 - March 28, 2011
Hello, The next GIMP Developer Meeting will take place in the GIMP IRC on March 28th 2011, 10:00 PM CET (For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?month=3day=28year=2011hour=22min=0sec=0p1=48). Thee meeting page is up and running on http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Mar_2011 Our agenda is quite small this time, so unless someone has more topics, it will be really short this time :) *** GSoC Student Applications *** Official GSoC applications should start coming in on march 28 19:00 utc - that's 2 hours before the meeting should begin. Also, we already have student applications on the mailing list. Some suggestions were made on putting minimal student requirements (not sure how practical this is) and some suggested creating some quick start guides for new developers. Do we want to do anything to get students started? BTW, such content should be placed on the developer wiki! Also regarding GSoC, not sure really which rating of ideas should happen, by whom and when, but discussing it should be done or decided on. For obvious reason, the writer of these lines (who applies for GSoC himself) will not participate in that part of the discussion. *** Optional topic: Re-Discussing GIMP's programming language *** Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala into gimp, claiming that it will scare off developers (more than the simple C GObject code). Discuss! *** Other topics *** Any other suggestions should be suggested by replying to this email, or adding it directly to the wiki (if you have permissions to edit the wiki). See you there, LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 2.7.2 Windows 64 bit Compiling Issues plug-ins/file-jpegs
Hi, The latest git (March 13) seems to have broken plug-ins/file-jpeg compiling on my machine. Please note that I am able to compile the March 5 gimp-git-master version. Also, I am able to compile --without-libjpeg. This works: ./configure --prefix=/opt/gimp-2.7.2 --build=x86_64-w64-mingw32 CPPFLAGS=-I/ t/include -I/c/Python27/include LIBS=-L/opt/lib -L/c/Python27/Lib --without-libjpeg This does not: ./configure --prefix=/opt/gimp-2.7.2 --build=x86_64-w64-mingw32 CPPFLAGS=-I/ t/include -I/c/Python27/include LIBS=-L/opt/lib -L/c/Python27/Lib Looks likes the issue is with jpeg-exif.o: In function `jpeg_exif_rotate_query_dialog': and libintl. ___ I am getting the following error: c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg.c:203: undefined reference to `libintl_bindtextdomain' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg.c:203: undefined reference to `libintl_bind_textdomain_codeset' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg.c:203: undefined reference to `libintl_textdomain' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil - Ignored: e-jpeg/jpeg.c:300: undefined reference to `libintl_gettext' jpeg-exif.o: In function `jpeg_exif_rotate_query_dialog': c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg-exif.c:292: undefined reference to `libintl_gettext' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg-exif.c:292: undefined reference to `libintl_gettext' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg-exif.c:350: undefined reference to `libintl_gettext' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg-exif.c:365: undefined reference to `libintl_gettext' jpeg-exif.o:c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\ plug-ins\file-jpeg/jpeg-exif.c:376: more undefined references to `libintl_gettex t' follow collect2: ld returned 1 exit status make[3]: *** [file-jpeg.exe] Error 1 make[3]: Leaving directory `/usr/src/gimp/gimp-2.7.2/nightly-builds/gimp-Mar13-2 .7.2/plug-ins/file-jpeg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/gimp/gimp-2.7.2/nightly-builds/gimp-Mar13-2 .7.2/plug-ins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gimp/gimp-2.7.2/nightly-builds/gimp-Mar13-2 .7.2' make: *** [all] Error 2 _ Windows 7 64-bit using $ gcc -v Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../gcc44-svn/configure --host=x86_64-w64-mingw32 --target=x86_6 4-w64-mingw32 --disable-multilib --enable-checking=release --prefix=/mingw64 --w ith-sysroot=/mingw64 --enable-languages=c,c++,fortran,objc,obj-c++ --enable-libg omp --with-gmp=/mingw64 --with-mpfr=/mingw64 --disable-nls --disable-win32-regis try Thread model: win32 gcc version 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] (GCC) I am using gtk version 2.22 (64 bit) and glib version 2.28 (64 bit). Also, I have gnutext and friends installed and I am not having this problem with other software that I compiled. Any suggestions appreciated. Thanks in advance, Partha www.partha.com - Done. -- Forwarded message -- From: Partha Bagchi parth...@gmail.com To: gimp-developer-requ...@lists.xcf.berkeley.edu Date: Sun, 13 Mar 2011 17:36:56 -0400 Subject: Gimp 2.7.2 Compiling plug-ins/file-jpeg Hi, The latest git (March 13) seems to have broken jpeg compiling on my machine. Please note that I am able to compile March 5 version. Also, I am able to compile --without-libjpeg. This works: ./configure --prefix=/opt/gimp-2.7.2 --build=x86_64-w64-mingw32 CPPFLAGS=-I/ t/include -I/c/Python27/include LIBS=-L/opt/lib -L/c/Python27/Lib --without-libjpeg This does not: ./configure --prefix=/opt/gimp-2.7.2 --build=x86_64-w64-mingw32 CPPFLAGS=-I/ t/include -I/c/Python27/include LIBS=-L/opt/lib -L/c/Python27/Lib ___ I am getting the following error: c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg.c:203: undefined reference to `libintl_bindtextdomain' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg.c:203: undefined reference to `libintl_bind_textdomain_codeset' c:\Users\partha\src\gimp\gimp-2.7.2\nightly-builds\gimp-Mar13-2.7.2\plug-ins\fil e-jpeg/jpeg.c:203: undefined reference to `libintl_textdomain'
Re: [Gimp-developer] GIMP vs Photoshop
These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion. Indeed. I was baffled to see how some GIMP people started to downplay GIMP as not suitable for this particular need. It's a school teacher trying to get kids into the basics of image manipulation, not a high grade training for the print industry! GIMP is absolutely suitable for this task, and it can be used in real world environments too. I use it everyday for my professional design work. I have to work around some edge cases, of course, but for most of my work it is usable (and I send works to different print providers in a daily basis). I don't care much about CMYK since I use intermediate/late binding, but the lack of higher bitdepth is indeed a hurdle when I work with narrow range monochrome gradients or alpha channels. Anyway, I don't see how some gradient banding or the loss of precision with some filters could be a real concern for kids learning the basics of image manipulation, at least to the point of considering to replace GIMP, which is free, with an expensive commercial application. And even in that case, GIMP uses the same principles than Photoshop, so you can use it to learn to work layers, blending modes, masks, filters, selections, levels, curves, color balance, cloning, healing, etc. It's all there. Apart from that, I'm with pippin about the premature CMYK conversion. I came out of the University (where I studied graphic design) with a rather limited knowledge about color management, thinking that early binding was the only way to work for print and that with the right CMYK values I would get perfect Pantone colors :-p When I switched to free software and met GIMP I had to learn some basics again to work without CMYK and the quality of my prints improved a lot, because that time I knew what I was doing. Of course there are cases when the access to CMYK separations is useful, but I would have preferred that they teach me to work with color management properly and learn to tweak CYMK later. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 03/08/2011 08:46 AM, Olivier wrote: 2011/3/8 Michael Grosberg grosberg.mich...@gmail.com mailto:grosberg.mich...@gmail.com Debi Rapson drapson at mansd.org http://mansd.org writes: Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content. Could you explain why retouching photos should be made in CMYK rather than RGB? Could you explain why retouching photos should be made in RGB rather than HSV/HSL :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
or better yet: Lab? ;] Anyway CMYK is neccessary too... W dniu 2011-03-08 10:08 użytkownik Ofnuts ofn...@laposte.net napisał: On 03/08/2011 08:46 AM, Olivier wrote: 2011/3/8 Michael Grosberg grosberg.mich...@gmail.com ... Could you explain why retouching photos should be made in RGB rather than HSV/HSL :) ___ 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
Re: [Gimp-developer] GIMP vs Photoshop
We are not speaking about the same thing. The fact that you want to change some channels in some color model does not mean that the internal representation of images must be based on this color model. You need tools for generating a proper CMYK representation of you image, suited to your printing shop hardware, but that does not mean that the image you handle must use this representation from the beginning. RGB is the internal representation of the images. It's also a color model, not especially suitable for manipulating colors. Thus you need tools that handle the image in more convenient color spaces. When you define a color using the color chooser, I suppose you work in HSV, not RGB? 2011/3/8 Bogdan Szczurek thebod...@gmail.com or better yet: Lab? ;] Anyway CMYK is neccessary too... W dniu 2011-03-08 10:08 użytkownik Ofnuts ofn...@laposte.net napisał: On 03/08/2011 08:46 AM, Olivier wrote: 2011/3/8 Michael Grosberg grosberg.mich...@gmail.com ... Could you explain why retouching photos should be made in RGB rather than HSV/HSL :) ___ 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 -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
Olivier olecarme at gmail.com writes: 2011/3/8 Michael Grosberg grosberg.michael at gmail.com Debi Rapson drapson at mansd.org writes: Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content. Could you explain why retouching photos should be made in CMYK rather than RGB? Photo retouching is usually done by print magazines. It stands to reason that they would use tools that are able to work with CMYK. As for the other things... Modern Photographic work also relies on a higher bit depth. Photoshop is able to process raw camera input as opposed to GIMP which has to first convert it to 8-bit before being able to work on the image. There are also various selection tools, color adjustment tools and retouching tools (such as the healing brush) that work better in Photoshop. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
We are not speaking about the same thing. The fact that you want to change some channels in some color model does not mean that the internal representation of images must be based on this color model. True, it doesn't. You need tools for generating a proper CMYK representation of you image, suited to your printing shop hardware, but that does not mean that the image you handle must use this representation from the beginning. I agree, it doesn't have to, yet it is convenient to use such representation when the image is to be send to print house. RGB is the internal representation of the images. That's untrue. It's also a color model, I'm not sure if it's right to try to set apart internal representation and color model. not especially suitable for manipulating colors. I agree, but also it's easy to use in digital environment. Thus you need tools that handle the image in more convenient color spaces. Meaning: tools that convert image to different color space for the time of their application. Which, by the way, can be quite tricky step. When you define a color using the color chooser, I suppose you work in HSV, not RGB? In fact, most of the time I use CMYK color chooser. Choice of color model often depends on your notion of that model. I prefer to use the same color model in my chooser that is the color model of my image. Using e.g. HSV chooser for RGB image can be deceitful since some color values can be silently changed by CMS. I prefer to use e.g. Lab for color adjustment and after I'm done with my modifications convert image to destination workspace. That way I've got full control over things that happen to my colors during conversion. Anyway, I believe we should be able to use different color models used to represent color samples stored in images not because it's just a nice thing but because there's one silent assumption about every color model: every color model is bound with some workspace not necessarily bijective in regard to other workspaces. Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 3/8/11, Bogdan Szczurek wrote: When you define a color using the color chooser, I suppose you work in HSV, not RGB? In fact, most of the time I use CMYK color chooser. Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 12:28 PM, Michael Grosberg grosberg.mich...@gmail.com wrote: Olivier olecarme at gmail.com writes: 2011/3/8 Michael Grosberg grosberg.michael at gmail.com Debi Rapson drapson at mansd.org writes: Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content. Could you explain why retouching photos should be made in CMYK rather than RGB? Photo retouching is usually done by print magazines. It stands to reason that they would use tools that are able to work with CMYK. If I may interfere :). In my work I use CMYK on daily basis and I think the question why photos should be retouched in CMYK is not the right one to ask. One could do that but it's not the point. CMYK is not needed because it's nice to retouch images but because it provides fine control over cyan, magenta, yellow and black color components in four color professional print. One could only relay on color management in print workflow, but oftentimes it's insufficient. There are (not so rare) cases when CMS doesn't yield expected results—I mean: conversion can be done all right according to theory but in spite of that it's better to manually decide how some colors end up looking like. Sometimes one need to add or remove some paint from reproduction before it's going to be printed. Example: you need to have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K. Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 2:30 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 3/8/11, Bogdan Szczurek wrote: When you define a color using the color chooser, I suppose you work in HSV, not RGB? In fact, most of the time I use CMYK color chooser. Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later. I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no. It just makes keeping color managed workflow somewhat a nightmare. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 3/8/11, Bogdan Szczurek wrote: Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later. I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no. Oh, but you don't have to do it :) GNOME Color Manager already provides D-Bus methods to request stuff like working color space profile. Any D-Bus enabled app (and GIMP is one) can do that. For 2.8, however, simply fixing what's already there would be enough. (Albeit I heard from users who deal with DTP that they actually like advanced cms display filter: http://registry.gimp.org/node/24944) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek thebod...@gmail.com wrote: have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K. There are use cases where direct control over the separated result to CMYK is desired, this is however the corner cases and not the generic sense, it is my impression that a lot of people are editing in CMYK without understanding color management at all, effectively circumventing proper color management to happen. In the few cases where you need to include text or vector elements on top (or embedded within) an image and want to ensure a matching color with the (adjusted) photo,. or do other things to avoid problems with registration problems yes I see this as beneficial. To edit photos in a device specific (or even geography specified least common denominator CMYK profile) by default is however in my opinion not good advice. Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more). This the direction I have encouraged GIMP to move in on the UI level. This distances it from color managed, photo retouching etc. In the foreseeable future I see GEGL as primarily aiming to provide the core to do color manipulation, processing and image processing in colorimetrically managed (RGB) color spaces; with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:23 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 3/8/11, Bogdan Szczurek wrote: Since we got carried away from the topic anyway, I keep hearing users complaining about various bits of GIMP still not color managed, most notoriously -- filter preview and sample points. The latter is sort of critical to those who uses separate+ and/or CMYKTool after editing things in GIMP. That makes one wonder if it will be addressed in 2.8 or later. I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no. Oh, but you don't have to do it :) GNOME Color Manager already provides D-Bus methods to request stuff like working color space profile. Any D-Bus enabled app (and GIMP is one) can do that. For 2.8, however, simply fixing what's already there would be enough. I didn't know that (obviously ;)). It's nice, but I've got a hunch that such thing should be placed lower than DM. My ideal would be even something placed deeper than display manager/X.org. I'd love to e.g. make my X theme using HSV or Lab color tuples. Also, such thing could take color management and color model support entirely of off applications shoulders. (Albeit I heard from users who deal with DTP that they actually like advanced cms display filter: http://registry.gimp.org/node/24944) Hmmm… I'm not sure of the reason of having that. Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:34 PM, Øyvind Kolås pip...@gimp.org wrote: On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek thebod...@gmail.com wrote: have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K. There are use cases where direct control over the separated result to CMYK is desired, this is however the corner cases and not the generic sense, True enough, but I'm living on that edge ;). it is my impression that a lot of people are editing in CMYK without understanding color management at all, effectively circumventing proper color management to happen. I believe, color management is one of the most misunderstood and non-understood subjects out there generally :). In the few cases where you need to include text or vector elements on top (or embedded within) an image and want to ensure a matching color with the (adjusted) photo,. or do other things to avoid problems with registration problems yes I see this as beneficial. To edit photos in a device specific (or even geography specified least common denominator CMYK profile) by default is however in my opinion not good advice. I don't see it different. Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more). I love that notion! I think of it similarly. Yet there's one thing in print specific color models that's notoriously neglected in color managed systems: image isn't magically put on some white (what is white exactly? ;)) universal material. Image goes through CtP (most of the time nowadays), machine and is placed on material of different characteristics. So, what is really needed for good color management is the profile of each of these stages, or at least whole process. Of course there are some standard profiles (e.g. FOGRA) but they all fall short when one is to use for example uncoated, dark red paper. I know, I know… egde case, yet as I said before I'm quite often on such edge :). This the direction I have encouraged GIMP to move in on the UI level. This distances it from color managed, photo retouching etc. In the foreseeable future I see GEGL as primarily aiming to provide the core to do color manipulation, processing and image processing in colorimetrically managed (RGB) color spaces; I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer. True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too). Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek thebod...@gmail.com wrote: Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more). I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Spectral processing is not similar to subtractive models like CMYK models needed for simulating print, mixing aspects, subsurface scattering, ink interactions and more (some of which are better indirectly modeled by ICC transforms backed by actual test-runs). with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer. True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too). All of these, like the simulation of glossiness or reflectiveness of metallic inks are things for the final separation/composite/simulation though - which very well can take into account both substrate and perhaps even an animated illuminant ;) Such soft-proofing would not be a space that GEGL itself would be doing processing in however, even though it might have op(s) to take the individual grey level buffers to create an RGB simulation to be shown on a display,. taking into account the RGB profile. Allowing the user to configure a largeish set of predefinable inks for separation and simulation/softproofing would possibly allow some very nice workflows in GIMP and other softwares using GEGL. Implementing the capabilities of doing such workflows is something that only can happen after GIMP itself has more naive initial support for storing its image data in GeglBuffers of higher bit depths. So if someone wants to play with, research and make prototypes for such a thing it would be a nice and welcome addition. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: Olivier olecarme at gmail.com writes: 2011/3/8 Michael Grosberg grosberg.michael at gmail.com Could you explain why retouching photos should be made in CMYK rather than RGB? Photo retouching is usually done by print magazines. It stands to reason that they would use tools that are able to work with CMYK. Please see my longer response about why doing this _in_ CMYK is usually wrong, premature optimization by using device dependendt color spaces if the result might go to many different printers, profiles etc. As for the other things... Modern Photographic work also relies on a higher bit depth. Photoshop is able to process raw camera input as opposed to GIMP which has to first convert it to 8-bit before being able to work on the image. Some of these are true, and GIMP is working towards lifting some of these limitations by migrating to GEGL. There are also various selection tools, color adjustment tools and retouching tools (such as the healing brush) that work better in Photoshop. These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek thebod...@gmail.com wrote: Considering the use cases where fine grained control over the resulting offset plates/actual ink used for C,M,Y,K to be a subset of the more general cases where individual ink control is desired (spot-colors (including metallic, glossy and other overprints) as well as duo tone and more). I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :). Spectral processing is not similar to subtractive models like CMYK I can't agree more. models needed for simulating print, mixing aspects, subsurface scattering, ink interactions and more (some of which are better indirectly modeled by ICC transforms backed by actual test-runs). Some effects can be modelled that way (maybe even all). Other thing is if they actually are. Getting specific paper profile is most of the time undoable. Maybe something could be done in that matter? For example instead of painfully standard “color settings” dialog in preferences and “assign profile”, “convert to profile” options some new layout would work better? Maybe instead of going to a kind of “image mode” menu, we should go to “color workspace” menu with all available profiles listed there? The truth is that whenever we use color model that is unable to describe whole visible spectrum we are using some cutout of this spectrum, a working space. Giving an option to just convert image to “grayscale” or “CMYK” seems to blur that truth and IMHO tries to bury color management concept. with almost enforced strict working spaces for the algorithms to ensure predictability. The ability to do separation to CMYK, spot colors and more with associated processing on such will most easily be done as abstractions implemented using a planar approach where each ink is represented by a graylevel buffer. True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too). All of these, like the simulation of glossiness or reflectiveness of metallic inks are things for the final separation/composite/simulation though - which very well can take into account both substrate and perhaps even an animated illuminant ;) Tempting… tempting… :) Such soft-proofing would not be a space that GEGL itself would be doing processing in however, even though it might have op(s) to take the individual grey level buffers to create an RGB simulation to be shown on a display,. taking into account the RGB profile. Allowing the user to configure a largeish set of predefinable inks for separation and simulation/softproofing would possibly allow some very nice workflows in GIMP and other softwares using GEGL. Yup! That's what I hope for too. Implementing the capabilities of doing such workflows is something that only can happen after GIMP itself has more naive initial support for storing its image data in GeglBuffers of higher bit depths. So if someone wants to play with, research and make prototypes for such a thing it would be a nice and welcome addition. I don't think that higher bit depths are more important for transformations than for storing color samples. If image is to be displayed, most of the time it'll end up being crammed into 3 8-bit values :). If it's about to be printed most often it'll be pushed into finite (and not so big) number of possible raster point sizes. I think transformations are really the things that are to benefit most from bigger number of possible sample values. Images of course too, but not everytime. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 03/08/2011 07:50 PM, Bogdan Szczurek wrote: On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurekthebod...@gmail.com wrote: I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :). If all you want is a color space that can encode all visible colors, i.e. the entire CIEXYZ color space, RGB is fine. Transforming from CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, where the matrix depends on the primaries and white point chosen. It's just that sometimes the RGB components will be negative and sometimes greater than 1.0, but each color that can be perceived by a human can be encoded in such a boundless RGB color space. If you want a color model that doesn't lose the information about the spectral power distribution of the stimulus, then RGB won't do, but from your reply above it doesn't sound like that is what you meant. / 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
Re: [Gimp-developer] GIMP vs Photoshop
Øyvind Kolås pippin at gimp.org writes: On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg grosberg.michael at gmail.com wrote: Olivier olecarme at gmail.com writes: 2011/3/8 Michael Grosberg grosberg.michael at gmail.com These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion. You are forgetting what the discussion is about, I think :-) The original poster asked, among other things, for examples of GIMP being used for photo-retouching in the real world. I replied that perhaps it was better to look for places that use GIMP for video game art creation, and mentioned some reasons why GIMP isn't, to the best of my knowledge, used by photo retouching professionals. I did not intend to discourage the teaching of GIMP, only to point the OP in a direction where they are more likely to find a real professional who uses GIMP. It is, as you said, completely possible to teach the basic skills using GIMP. But photo retouching isn't the only thing GIMP can do, and I don't see why the need to focus on it. What about web graphics? digital painting? Texture art? I'm sure the artists who worked on Sintel would amaze the students with their Gimping skills. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 3/8/11, Michael Grosberg wrote: But photo retouching isn't the only thing GIMP can do, and I don't see why the need to focus on it. What about web graphics? digital painting? Texture art? I'm sure the artists who worked on Sintel would amaze the students with their Gimping skills. plug mode=shameless There is, in fact, a whole DVD on digital painting by Sintel art director based around tweaked version of GIMP: http://www.blender3d.org/e-shop/product_info_n.php?products_id=122 /plug Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
Who said this could not be done in Gimp? Some examples of Works i created with Gimp that are under CC: Retouching: * http://commons.wikimedia.org/wiki/File:Snow_leopard_portrait.jpg (Original) * http://commons.wikimedia.org/wiki/File:Snow_leopard_portrait-2010-07-09.jpg (Retouched) * http://commons.wikimedia.org/wiki/File:MarineCorpsCompany_F-2-24_KhalidiyahSandstorm_2008.jpg (Original with wrong colors) * http://commons.wikimedia.org/w/index.php?title=File:MarineCorpsCompany_F-2-24_KhalidiyahSandstorm_2008_edit.jpg (Color Corrected version) * http://commons.wikimedia.org/w/index.php?title=File:Rana_esculenta_on_Nymphaea_edit.JPG (Original is linked on page) Drawings (may contain nudity): * http://commons.wikimedia.org/wiki/File:On_the_edge_-_free_world_version.jpg * http://commons.wikimedia.org/w/index.php?title=File:Dojikko.png Am 08.03.2011 20:29, schrieb Michael Grosberg: Øyvind Kolåspippinat gimp.org writes: On Tue, Mar 8, 2011 at 11:28 AM, Michael Grosberg grosberg.michaelat gmail.com wrote: Olivierolecarmeat gmail.com writes: 2011/3/8 Michael Grosberggrosberg.michaelat gmail.com These concepts do transfer to GIMP, and if one is generally empowering students with the ability to do manipulation on images.. teaching them how to do it with GIMP gives them both a skill and an option of a tool they can use without a fee; as well as have the freedom to improve in the other ways free software does. Pointing out that some things work better in Photoshop doesn't seem constructive in this discussion. You are forgetting what the discussion is about, I think :-) The original poster asked, among other things, for examples of GIMP being used for photo-retouching in the real world. I replied that perhaps it was better to look for places that use GIMP for video game art creation, and mentioned some reasons why GIMP isn't, to the best of my knowledge, used by photo retouching professionals. I did not intend to discourage the teaching of GIMP, only to point the OP in a direction where they are more likely to find a real professional who uses GIMP. It is, as you said, completely possible to teach the basic skills using GIMP. But photo retouching isn't the only thing GIMP can do, and I don't see why the need to focus on it. What about web graphics? digital painting? Texture art? I'm sure the artists who worked on Sintel would amaze the students with their Gimping skills. ___ 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
Re: [Gimp-developer] GIMP vs Photoshop
On 03/08/2011 07:50 PM, Bogdan Szczurek wrote: On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurekthebod...@gmail.com wrote: I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :). If all you want is a color space that can encode all visible colors, i.e. the entire CIEXYZ color space, RGB is fine. Transforming from CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, where the matrix depends on the primaries and white point chosen. It's just that sometimes the RGB components will be negative and sometimes greater than 1.0, but each color that can be perceived by a human can be encoded in such a boundless RGB color space. Yes, but why use RGB at all if one can use e.g. XYZ from the start? So wide RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with. If you want a color model that doesn't lose the information about the spectral power distribution of the stimulus, then RGB won't do, but from your reply above it doesn't sound like that is what you meant. No, I didn't, but still I think RGB “could do” since it's able to describe absolute color. Well… I don't know if my longing is good or not, or if that way is better—I'm just thinking aloud :). My best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
