Re: [Gimp-developer] Asking for a Miracle !?
C R gmail.com> writes: > > If we are assuming "de-throne" means "to replace as what people think of as > a photo editor", then it's more a matter of marketing than anything related > to feature parity. Most people wouldn't know what features were "missing" > in GIMP to compare in the first place. Most of the companies I work with > are still rocking Adobe CS3, and clearly care nothing at all about new > features, for example. Gimp is yet to achieve feature parity with Photoshop 5. not CS5 - just 5. from 1999. And most pro users will not use anything missing features from around CS2. Krita has most or all of them, by the way, and possibly some featues photoshop doesn't even have, I'm not sure. If it's not a photoshop-killer already it's certainly on its way. Gimp *could* re-brand itself as a simpler solution for amateurs, but for that it would have to work on simplicity and even lose some features. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] unified "artistic tools"
Johann gmail.com> writes: > > Hi there, > > unified "artistic tools" > > I make regularly use of following "artistic tools": > brush, airbrush, pencil and ink too. Technically, all these tools could share the same configuration > engine (some options would exclude others to avoid mess) and live instead as -default presets- in the > presets list only. > > regards > > Jo As a user, I believe this is a good idea. Certainly the "pencil" tool should be eliminated and turned to a "anti-aliased" checkbox in the brush tool that can be turned off. The airbrush... maybe call it "cumulative" - again, can be just a setting. As for the ink tool... well - I think all of its functionality has been replicated by the current brush engine. It was useful when the brush engine was primitive but it's very impressive now. Perhaps the ink tool can be simply retired, pending community approval. Now, this is just my feelings, based on my own use patterns. I know I basically only use the brush tool and very occasionally want to use the pencil tool. I NEVER use the airbrush or ink tools. So it would be best to see what other users do with them before deciding. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Move tool
Alexandre Prokoudine gmail.com> writes: > > Hi, > > Recently someone pinged me (again) about a certain inconsistency that > I've seen affecting a considerable amount of users: that the Move tool > doesn't move contents of selections. > > Frankly, I don't understand the logic behind this myself. I'm just a user but I would love to see this change so that the move tool could move a selection content. Another related issue though is moving a selection outside (partly or fully) the layer boundary. currently the selection content simply disappears. It would be nice if this somehow enlarged the boundary. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Make Scale dialog less painful for physical media?
Omari Stephens xsdg.org> writes: > > Howdy, y'all > > I'd like to propose a modification to the Scale dialog. > > To start off with, it seems there are two major usecases for the dialog. > The difference is whether the user cares about the appearance of the > image in the physical world. The problem is that there are two related dialogs, scale image and print size. One only concerns pixel size, the other concerns print size. It is true that sometimes you want to change both at the same time - for example, when you edit pictures for print, you sometime want to scale them to a certain print size AND a certain resolution. The best solution is unifying them to a single dialog, with Pixel size, print size and resolution controls. There should be a lock icon next to each and the three locks should work like a radio button, only one control can be locked at any given time. So, you lock one, modify the second, and the third changes accordingly. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP for iPad
Jon Nordby gmail.com> writes: > > I believe the problem also exists for Google Play store. Then again Firefox for Android is available there, but it could be Google is just to wary of anti-trust to shut it down. /speculation Actually, there's no such problem. Google Play accepts GPL apps. Android itself is licensed under the Apache software license. Not only that but you can also legally distribute apps without going through the app store - the users have to change some default settings, but there's no need to jailbreak the device. That still leaves the problem of diverting valuable developer time into a complex side project, so it's probably best not to even consider it, but livensing and distribution are not the problem. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp UI ... hesitant about compiling a list...
RMMjr gmail.com> writes: > > I caught this e-mail address on someone's signature line in a post... > Well you're certainly a verbose one... I'll be brief though: What you think are UI issues are actually code issues. The boundaries and floating layers are not there by choice exactly. there is an intention to get rid of them, but there are not many developers on this project and things simply take a long time. If you are a developer you might want to join and help. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 prohibitively slow
Aaron Paden gmail.com> writes: > > So I mostly use MyPaint, but I'd like to be able to do some things in > gimp, too. But gimp is way too slow on this computer. Especially trying > to open large images like MyPaint encourages, I'll have to run to > another tty to try and kill the process so I can continue to use my > computer. I've got an old Pentium 4 with only about half a gig of RAM. A > bit behind the times, but especially on Linux it's generally fast enough > to get the job done. > > Is there anything I can do to help improve performance? I don't have > much experience. I doubt I could write anything any faster. But maybe I > can do something to help identify bottlenecks? Anything I can do to > help, I'm game. > You know, when you have a system that's probably 12 years old, it's good form to start by saying that you have one instead of complaining that an application developed in 2012 is "prohibitively slow". For example, you could use the subject line "running Gimp on an old PC". Just saying. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Alexandre Prokoudine gmail.com> writes: > It's a goddamn graph compositing engine. (Sorry, I'm still under > impression from the Oatmeal's Tesla comic). > > You can take a buffer, pass it thorugh a colorspace converter > (rgb2lab), pick a channel and plug it into a specific input of a GEGL > operation, then plug the output into another colorspace converter > (lab2rgb). > > And you expect PSD to store the GEGL graph tree? Really? I knew what GEGL is, but I thought that was just the engine and that you'd put some sort of layer-based facade on it so people could, like, actually use it. But it's your project, do what you feel right. Personally I hate node based compositing, but perhaps you have a target audience for it, somewhere among the 3d shader specialists. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Alexandre Prokoudine gmail.com> writes: > > On Tue, May 22, 2012 at 11:26 AM, Michael Grosberg wrote: > > >> This is defnetly a no-go. Save is exclusively for a format that can > >> save and load ALL gimp features. > > > > It CAN save and load all Gimp features. It doesn't do that in practice, > > but it CAN. > > There is NO need to SHOUT, Michael. writing an single word in uppercase is a way to emulate stressing a word in speech; it's uppercasing an entire sentence that's considered shouting. But I'll use a different convention from now on. is *this* OK? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Alexia Death gmail.com> writes: > > On Tue, May 22, 2012 at 10:26 AM, Michael Grosberg > gmail.com> wrote: > > Alexia Death gmail.com> writes: > > > > > >> This is defnetly a no-go. Save is exclusively for a format that can > >> save and load ALL gimp features. > > > > It CAN save and load all Gimp features. It doesn't do that in practice, > > but it CAN. > > Even in a fully geglified non-destructive GIMP? It may today, but GIMP > changes. > It depends on what features this version will have. Gimp will have to go far to attain the level of non-destructiveness Photoshop currently has. My bet is, whatever feature you can think of in terms of non-destructiveness, Photoshop already has it. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Alexia Death gmail.com> writes: > This is defnetly a no-go. Save is exclusively for a format that can > save and load ALL gimp features. It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Jon Nordby gmail.com> writes: > You say that only task 1 can potentially benefit from saving as xcf. > XCF is the only format that can store what you have done to the image > in a non-destructive way, and allow you to go back and change these > decisions. That reminds me - it would be great if the "save" feature also supported PSD (As opposed to export). I can think of only one showstopper: text layers, which are currently always converted to raster, and a further complication of how to preserve the text data on a text layer that has been modified using another tool. The reason is that some 3D and video editing programs support PSD natively and even allow importing specific layers, so in some workflows, it is not enough to just have a layered formats - it has to be PSD specifically. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Alexia Death gmail.com> writes: > > Hi! > > My 2c on the issue - This change is GOOD not only for the target > audience but to the novice too! Those are good reasons to do something, but I believe the problem is with the selected solution and not with the idea of attempting to solve the problem. Photoshop Has a similar "protect user from destructive saving" system, annoying in its own way, which only lets you save to the original as long as no new layers have been added. Once you add layers, choosing "Save" opens a dialog letting you asve as PSD and you have to manually select JPG/PNG in order to save. There is also a warning inside the dialog that data will be lost. I can see that certain usage patterns will be easier using the new system but perhaps allowances could be made in some cases. For example, if the image is kept as a single layer, it should allow saving to all full-color, non-lossy formats. If an image is saved to a lossy format, it could be decided that the first time you attempt to do this, an alert will explain to you that repeated saving to JPG corrupts the image. A checkbox in the dialog will enable you to prevent it from showing again. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Markus Heiler gmail.com> writes: > > - What other image-editor can I use on Linux? pixlr. It's a web app, not a standalone app. But it's pretty awesome. It may not have ALL the features Gimp has, but it also has some it doesn't, such as layer styles or some basic shape drawing options. You can work with masks, layers, color corrections, all the things you'd expect. www.pixlr.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Jason Simanek gmail.com> writes: > This is getting old. All they gotta do is go use some other FREE > graphics application. Most of these complaints could be addressed by > simply changing their keyboard shortcuts to use the "overwrite" > command instead. I always change about 60% of the Gimp shortcuts > anyway. (need to keep my sanity going back and forth between Photoshop > and Gimp) Not a big deal. Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both. You'll have to assign two shortcuts, and remember to use one shortcut the first time, and the other shortcut the second, third etc. That is indeed a strange behavior - a command that only works once per file. Say what you will about save vs. export but this has to be fixed. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Official 2.8 Windows installer?
Jeremy Morton game-point.net> writes: > > Now that GIMP 2.8 is officially out, shouldn't we (with some urgency) > get an official Windows installer for it near the top of the downloads page: > http://www.gimp.org/downloads/ > > We still have the 2.6.12 installer linked. > And what about making life easier for Linux users? There's a PPA that Ubuntu and Mint users can add: ppa:otto-kesselgulasch/gimp (which I just did). I think it's worth adding it to the download page. It's also worth explicitly adding the "Mint" name there along with Ubuntu - it's become quite popular lately. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] yes, its that time of the year..
Eric Grivel lumenssolutions.com> writes:
> Well, I deleted the message without reading, and I'm not planning to
> click the link until it is accompanied with some relevant information on
> why it would be relevant for me. Because unlike gg I'm not quite that
> bored...
Another doomed effort to convince the team to rename Gimp.
This time there's a concrete suggestion for a new name ("Imagine")
and a stab at a new logo which shows some graphic thinking is at work,
but the style is completely wrong for this type of product and looks like
a fashion/makeover app for teenage girls.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Retinex color operation
I'd like to Discuss Retinex. I decided to do it here before submitting a bug report. In theory the retinex operation is very useful in fixing badly lit images. In practice, I've had little success with it. So I decided to fiddle around with it. My test picture was a Chinese temple on a background of blue sky (I can upload the XCF on request). usually you want to just brighten up some darker areas or bring detail in an area that's too brightly lit, without changing the rest of the image. In my test case, The sky's color was ruined when retinex was applied and most of the well-lit areas lost most of their color. I'll break down what happened: 1. The properties that can be changed by the sliders in the retinex dialog are not clear at all. The documentation doesn't explain the first two in terms understandable to a non-mathematician. Whatever it is they are doing, they are not helping in correcting images. If it is opssible to give them more descriptive names this would be great. 2. The result is too strong. I find I have to do a "fade" every time I use it. My suggestion: add a multiplier slider that would do an internal fade. The default should be about 0.5. 3. The algorithm is indiscriminate: it is used to fix bad lighting but it also works on well-lit areas. I believe it should have less effect on pixels (or areas) whose average luminosity value is closer to 0.5, and more effect on pixels with values closer to 0 or 1. I managed to achieve a selective retinex using the following method: 1. copy the layer 2. paste into quick mask 3. blur the mask using gaussian blur (8.0 radius) 4. invert the colors (only if you want to affect just the darker areas). now your light areas are masked out. 5. use levels to also mask out the mid values: in the input scale, push the black triangle to about midpoint. This part may require a different setting for each image. 6. go back from quick mask to image and perform Retinex. 7. Fade the result The above procedure can probably be turned into an integral part of retinex so that retinex only works on those parts. Perhaps adding another slider that emulates what I did with the levels operation, to choose how much you want to affect midtones in the image. Lastly a comparison to photoshop: Photoshop's "shadow/highlight" operation (basically retinex) has two sliders in its basic settings. One for choosing the strength of the effect on lighter parts of the image, and one for choosing the strength of the effect on darker parts of the image. So basically it's like doing what I did with masks twice, one for dark areas and one for light, and combining the result. There are also dual extended options, one set for dark areas and one for light areas. In it there is a "tonal width" slider which according to the help file does pretty much what I did with the levels operation. Comments? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
