[Gimp-developer] small typo on wiki
I found a tiny error on wiki 1st page: Whose is it? This wiki is currently maintained by some GIMP developers, so if you have any comments, feel free to contact LightningIsMyName or Alexia_Death via the the GIMP IRC (irc://irc.gimp.org#gimp) ^error the URI is wrong, it will never work, see: http://ftp.ics.uci.edu/pub/ietf/uri/draft-mirashi-url-irc-01.txt An irc URL takes the form: irc:[ //[ host[:port] ]/[target] [,needpass] ] So it should be: irc://irc.gimp.org/#gimp) bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] small typo on wiki
Fixed, thanks On Wed, Aug 29, 2012 at 5:41 PM, Marco Ciampa ciam...@libero.it wrote: I found a tiny error on wiki 1st page: Whose is it? This wiki is currently maintained by some GIMP developers, so if you have any comments, feel free to contact LightningIsMyName or Alexia_Death via the the GIMP IRC (irc://irc.gimp.org#gimp) ^error the URI is wrong, it will never work, see: http://ftp.ics.uci.edu/pub/ietf/uri/draft-mirashi-url-irc-01.txt An irc URL takes the form: irc:[ //[ host[:port] ]/[target] [,needpass] ] So it should be: irc://irc.gimp.org/#gimp) bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list -- Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] small typo on wiki
Done :) On Wed, Aug 29, 2012 at 5:41 PM, Marco Ciampa ciam...@libero.it wrote: I found a tiny error on wiki 1st page: Whose is it? This wiki is currently maintained by some GIMP developers, so if you have any comments, feel free to contact LightningIsMyName or Alexia_Death via the the GIMP IRC (irc://irc.gimp.org#gimp) ^error the URI is wrong, it will never work, see: http://ftp.ics.uci.edu/pub/ietf/uri/draft-mirashi-url-irc-01.txt An irc URL takes the form: irc:[ //[ host[:port] ]/[target] [,needpass] ] So it should be: irc://irc.gimp.org/#gimp) bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list -- Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 29 August 2012 19:03, Elle Stone l.elle.st...@gmail.com wrote: Why does /babl/babl/util.h provide functions that transforms back and forth between linear gamma TRC and the regular sRGB TRC? I'm sure there is a reason, but the reason is not apparent to me. Babl is a pixel format conversion library. It can convert between RGB pixel representations with linear gamma and gamma-corrected, separate alpha channel and premultiplied alpha, or to/from other pixel formats like HSV, HSL, LAB. Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing? That conversion from linear gamma to the sRGB tone response curve and back gets executed literally hundreds of thousands of time, every time you do anything at all using Gimp. Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions. Also, any legacy code paths that are still in place before the GEGLification might cause conversions to sRGB. I don't know exactly which parts those are in the current codebase, but anything that uses the deprecated pixel manipulation functions are likely candidates. I note that the lcms plugin still uses these interfaces, and I suspect that is what is causing the implicit (and unwanted) conversions you are seeing. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] PayPal Transaction 55J11496RA4xxxxxN - THANK YOU!
FYI :-) On Tue, Aug 28, 2012 at 06:29:47PM +0200, Markus wrote: PayPal didn't allow me to enter a message :-( so here is what I wanted to let you know: With that small donation (of $30), I just wanted to show my appreciation for releasing GIMP 2.8.2: Finally a native build for Mac! :-D Thank you very much, so many Mac users have been eagerly waiting for this to finally happen for years! Kindest regards, Markus ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build
Am 28.08.2012 um 10:08 schrieb Michael Natterer mi...@gimp.org: On Mon, 2012-08-27 at 22:02 -0600, Clayton Walker wrote: https://dl.dropbox.com/u/942685/gimp-2.8.2-dmg-1.dmg If someone could just mirror that on the gimp ftp website, or upload it to sourceforge or something, that would be great. Thanks! Great! :) I have uploaded it to ftp.gimp.org and updated the download page on www.gimp.org. Thanks Clayton for the effort to make this happen! Regards, --mitch aha, so I'm kicked out. Why without prior notice, after four years I've maintained the GIMP builds for Mac OS X? Why has nobody asked me why I didn't build a, as you call it, 'native' version? Do you really think I wasn't able to build a version which doesn't depend on X11? It's never been about building, that's quite easy. It's all about having a well working version of GIMP. The now official Mac build still has the usability glitches, which prevented me to release such a version of GIMP: plugin dialogs pop up behind the main windows. Oh, BTW, the color picker doesn't work well, screenshots fail, no support for scanners or digital cameras, the help system doesn't work, even accessing the online manual fails. OTOH, pressure sensitivity for graphic tablets seems to be fixed. (where can I get the source code patches? I can't find them in git.) But, back to the main topic. What's the advantage of a so called 'native' build? The menu bar at the top? Not using X11? From this point of view, even most Linux versions aren't native. Or does a 'native' version magically solve all kind of problems? Is it about toolkits or software layers? Is GTK+ native and XQuartz not? Is the cairo quartz backend a native OS X feature or just another kind of software layer between the application and the OS X graphical libraries and routines? IMO a native version of an application is more than only the use of a specific toolkit or software layer. IMO a native application should use standard native functionality. And yes, the menu bar at the top is one. But does your 'native' version use the native OS X file dialog, the native print functionality and dialogs, or does it use native ColorSync. No. Or new security features like Gatekeeper. No. And even further, having your targeted user audience in mind, the official build lacks functionality Mac users got used to in the past years: a set of plugins offering advanced photo retousching and workflow, locally installable user manuals, support for various OS versions and architectures. Anyway, now that you're providing an official Mac version of GIMP, I'm quite sure that you will give all of these to your Mac users soon, or point them to resources where they can easily get it. Finally, although I'm very disappointed about the current situation, I had a great time being part of the open source community and I'd like to say thanks to all of you for all your lovely mails and your supportive feedback I've received from all over the world in the past few years. Thank you. Now, dear GIMP team, ... so long, and thanks for all the fish. Simone Karin Lehmann http://gimp.lisanet.de smime.p7s Description: S/MIME cryptographic signature ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build
On Thu, Aug 30, 2012 at 12:57 AM, Simone Karin Lehmann wrote: Simone, First of all, you have my word of honor (such as is left of it) that nobody was targeting to kick you out. Most of development talks happen on IRC. It's where we make decisions. It so happened that the new contributor was around on the channel to solve his issues with building a native version, and before we knew he started banging out patches hand over fist. Now, onto the matter. But, back to the main topic. What's the advantage of a so called 'native' build? The menu bar at the top? Not using X11? From this point of view, even most Linux versions aren't native. Or does a 'native' version magically solve all kind of problems? Is it about toolkits or software layers? Is GTK+ native and XQuartz not? Is the cairo quartz backend a native OS X feature or just another kind of software layer between the application and the OS X graphical libraries and routines? IMO a native version of an application is more than only the use of a specific toolkit or software layer. IMO a native application should use standard native functionality. And yes, the menu bar at the top is one. But does your 'native' version use the native OS X file dialog, the native print functionality and dialogs, or does it use native ColorSync. No. Or new security features like Gatekeeper. No. While I agree that more work has to be done to make GIMP more native on OSX, an official no X11 build is a first major step for wider adoption of the application. People have been asking for that for a long, long time, and even refusing to install X11-dependent version. And even further, having your targeted user audience in mind, the official build lacks functionality Mac users got used to in the past years: a set of plugins offering advanced photo retousching and workflow, locally installable user manuals, support for various OS versions and architectures. This is something Clayton was interested to work on. Personally I'd like to see a _team_ of Mac contributors. Seeing one important community member (you) go away because the other happened to be in the right time in the right place sounds like communication breakdown to me. I'd rather avoid that. Whatever your final decision is, I'm thankful for the support you provided to our Mac users. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
Regarding legacy code/deprecated functions: On 8/29/12, Jon Nordby jono...@gmail.com wrote: Also, any legacy code paths that are still in place before the GEGLification might cause conversions to sRGB. I don't know exactly which parts those are in the current codebase, but anything that uses the deprecated pixel manipulation functions are likely candidates. I note that the lcms plugin still uses these interfaces, and I suspect that is what is causing the implicit (and unwanted) conversions you are seeing. On 8/29/12, Simon Budig si...@budig.de wrote: Basically all of the plugins (including your lcms port) use the old pixel-region API for accessing the image data. This also means that they don't specify a proper working format, this even could be the reason for all kind of potentially useless conversions. Earlier to day I found Mitch's blog post: http://gimpfoo.de/2012/04/17/goat-invasion-in-gimp/ - which coheres nicely with what both of you are saying about the old vs new way of accessing pixel data. So it looks like my next step is to replaced the deprecated functions in the lcms plug-in. So I will start doing exactly that. It was the next step anyway, but I was feeling very discouraged about the whole babl/babl/util.h thing. Regarding sRGB and rendering to the screen: On 8/29/12, Jon Nordby jono...@gmail.com wrote: On 29 August 2012 19:03, Elle Stone l.elle.st...@gmail.com wrote: Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing? Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions. Could you explain more about what you mean by rendering to the screen is done using sRGB? What about the actual monitor profile? Back in the day, a decent CRT monitor could easily be calibrated to match the sRGB color space, because sRGB was based on the display characteristics (tone curve, primaries, dial-a-white-point and 0 black point) of the CRT monitor. (See All the Colors, Some of the Colors, the Colors of Daylight: http://ninedegreesbelow.com/photography/all-the-colors.html). Today's LCD monitors are not well-characterized by sRGB. It is not just a matter of the LCD monitor native white point not being D65. The phosphors are different, which means the primaries are different, which means the color gamut is different. And unlike a CRT, with an LCD you can't get (0,0,0) displayed to the screen (the sRGB black point assume zero light can be sent to the screen). Which means you cannot really calibrate your monitor to use the sRGB TRC. (See sRGB — Not So Good for LCD Monitors: http://ninedegreesbelow.com/photography/srgb-bad-monitor-profile.html and Image Display Technology: http://www.marcelpatek.com/LCD.html.) A wide gamut monitor profiled in its native state would be an even worse fit to sRGB, though compared to a regular LCD, a wide gamut LCD monitor can achieve a much closer calibration to sRGB, IF one chooses to give up the extra color gamut. But why would you want to give up all that extra color gamut goodness? My own LCD native state monitor profile covers 93% of the sRGB color space, but the sRGB color space covers only 84% of my monitor profile color gamut. If I calibrated my monitor to match sRGB as closely as possible, I would end up with a monitor profile color gamut that is actually smaller than sRGB, at the additional price of less smooth tonal transitions - a very bad move, it seems to me. So to repeat my question, how does rendering to the screen . . . using sRGB cohere with using an LCD monitor that is not well-described by the sRGB color space profile? Kindest regards, Elle -- http://ninedegreesbelow.com Articles and tutorials on open source digital imaging and photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build
Simone Karin Lehmann, let me first go into some history. I was once looking for an image editor for Mac, with capabilities similar to PS, but without the huge pricetag. I found gimp. Back then, my main OS was Tiger, and there wasn't as much support for free software back then as there is now. I stumbled upon your packages after a bit of Googling, and downloaded them. After getting used to X11, and it's habits, Gimp+X11 became my main image editor of choice. That was over 4 years ago. After years went by, I felt that I wasn't really contributing to the Gimp project. X11 slowly became an annoyance, because I could never get used to the idea of using two programs to run one. It went against the Apple philosophy (which is bullshit, now that I think about it), and it increased startup times. Also I didn't like the fact that it'd just sit there in my Dock all day. So I decided to do some digging. After a few weeks of dinking around, I finally got gtk to build with the quartz variant in MacPorts. That was a neat day. Of course I quickly got bored of it, and continued to use the X11 version. After all, like you had said, this page doesn't look very promising... and provided a link to the quartz integration. But that's changing. And I wanted to be a part of that change. So after John Ralls continued development of gtk-osx, jhbuild and gtk-mac-bunlder, and Jesse had ported gedit running gtk3 over to the mac, I decided it was time to see if the same technology could be applied to gimp. After building a gtk stack from source using jhbuild as a base, I slowly built up a custom module including gimp and all of it's dependencies. (This can be viewed herehttp://git.gnome.org/browse/gimp/plain/build/osx/gimp.modules?h=gimp-2-8 .) 2.8 was released, and I still didn't have a build I wanted to call stable, or even semi-stable for that matter. A few months pass, and suddenly quite a few changes happen. The glitches are ironed out, glib fixes appear, gtk fixes appear, and even changes to gimp itself start to appear. The week before 2.8.2 was released, I had (in my own private repo) a working jhbuild setup with pressure support (thanks Daniel Sabo!) and color management started working again (thanks Kristian Rietveld!), and now we're working on lcms2 (thanks Elle Stone!). Thanks to everyone so far, Gimp has really had a boost in development. So what I'm trying to say is that I'm not trying to demean your work, or to replace your work. I'm trying to provide an alternative to X11, not an alternative to you. Of course we know you could provide a native build (and probably a better one that I could :D), so what I'm trying to do is provide a working gimp environment which doesn't require X11, and I'm doing the best I can. Care to not leave? We could use the help. ;) Yours truly, Clayton Walker On Wed, Aug 29, 2012 at 3:18 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Aug 30, 2012 at 12:57 AM, Simone Karin Lehmann wrote: Simone, First of all, you have my word of honor (such as is left of it) that nobody was targeting to kick you out. Most of development talks happen on IRC. It's where we make decisions. It so happened that the new contributor was around on the channel to solve his issues with building a native version, and before we knew he started banging out patches hand over fist. Now, onto the matter. But, back to the main topic. What's the advantage of a so called 'native' build? The menu bar at the top? Not using X11? From this point of view, even most Linux versions aren't native. Or does a 'native' version magically solve all kind of problems? Is it about toolkits or software layers? Is GTK+ native and XQuartz not? Is the cairo quartz backend a native OS X feature or just another kind of software layer between the application and the OS X graphical libraries and routines? IMO a native version of an application is more than only the use of a specific toolkit or software layer. IMO a native application should use standard native functionality. And yes, the menu bar at the top is one. But does your 'native' version use the native OS X file dialog, the native print functionality and dialogs, or does it use native ColorSync. No. Or new security features like Gatekeeper. No. While I agree that more work has to be done to make GIMP more native on OSX, an official no X11 build is a first major step for wider adoption of the application. People have been asking for that for a long, long time, and even refusing to install X11-dependent version. And even further, having your targeted user audience in mind, the official build lacks functionality Mac users got used to in the past years: a set of plugins offering advanced photo retousching and workflow, locally installable user manuals, support for various OS versions and architectures. This is something Clayton was interested to work on. Personally I'd like to see a _team_ of Mac
[Gimp-developer] Gaussian/Tileable blur: Choice of IIR and RLE still necessary?
Hi, I'm currently working out a GUI brainstorm idea for the Gaussian and Tileable Blur dialogs. Both dialogs let the user choose between the algorithms IIR and RLE. The documentation says, IIR is faster on photographs, RLE faster on drawings. I've never found a difference in computing time between these both algorithms and wondered, whether the choice is still necessary with modern computer environments. What do you think about it? Thank you, Sven ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
