Dear GIMP lovers,
for the first time after update to Fedora 17, I've needed to do some simple edits to a few photos.
Now I feel it is time to say goodbye to GIMP and start saving for Photoshop ...
There is no point for me in reporting bugs - this is some fundamental difference between my and the GIMP developers' thinking ("it is not a bug, it is a feature").
The first thing was that GIMP had asked me if I want the photos rotated according to EXIF. Hell yes, I can hardly remember any single case where I wouldn't want this. - There was just a little problem that I simply don't know which orientation is "standard". So I was really not sure what to answer, will the photo get rotated according to EXIF or will it be rotated from EXIF orientation to the physical orientation of the JPEG data in the file? And that's where I got the suspicion ...
I wouldn't mind that "resize" got renamed to "scale".
What do I mind is that "Save as" no longer works as before. I still have the possibility to choose the file extension, however trying to use "jpg" tells me that it won't save the file as JPEG and that I have to "export" the file. That sounds very "logical" when I've opened somefile.jpg and I just want to save it as someothername.jpg not to overwrite original; I do not want to "export" to any other format than what was the original.
Ok, so I went to "export", did all the "advanced" settings and saved the file. Then the same for the rest of files I had altered. Oh, the JPEG settings dialogue doesn't remember the settings over the editing session as it always did? The only possibility not to spent half an hour clicking the same twenty times in a row is to save the settings as default. But I don't want these exact settings to be the default ...
Cool, so I've spent half an hour "exporting" the files. So I'm finished, let's close GIMP. Hey, but what's that dialogue asking me to save unsaved changes of a file that I have just saved? Every single file that just got saved is treated as unsaved just because I was so bold not to use the one and only holy XCF format for reprocessed JPEGs? Okay, just enough for me ...
Next time I'll rather spend my time studying ImageMagick usage to script the task even for less than ten images, rather than doing monkey work.
So, feel free to join me with the moment of silence for the good old GIMP that is just getting buried.
K.
I agree. The save vs. export thing in the new version of gimp is mind-numbingly stupid.
Sent from my iPhone
On Apr 29, 2012, at 9:25 AM, Karel Volný kvolny@redhat.com wrote:
Dear GIMP lovers,
for the first time after update to Fedora 17, I've needed to do some simple edits to a few photos.
Now I feel it is time to say goodbye to GIMP and start saving for Photoshop ...
There is no point for me in reporting bugs - this is some fundamental difference between my and the GIMP developers' thinking ("it is not a bug, it is a feature").
The first thing was that GIMP had asked me if I want the photos rotated according to EXIF. Hell yes, I can hardly remember any single case where I wouldn't want this. - There was just a little problem that I simply don't know which orientation is "standard". So I was really not sure what to answer, will the photo get rotated according to EXIF or will it be rotated from EXIF orientation to the physical orientation of the JPEG data in the file? And that's where I got the suspicion ...
I wouldn't mind that "resize" got renamed to "scale".
What do I mind is that "Save as" no longer works as before. I still have the possibility to choose the file extension, however trying to use "jpg" tells me that it won't save the file as JPEG and that I have to "export" the file. That sounds very "logical" when I've opened somefile.jpg and I just want to save it as someothername.jpg not to overwrite original; I do not want to "export" to any other format than what was the original.
Ok, so I went to "export", did all the "advanced" settings and saved the file. Then the same for the rest of files I had altered. Oh, the JPEG settings dialogue doesn't remember the settings over the editing session as it always did? The only possibility not to spent half an hour clicking the same twenty times in a row is to save the settings as default. But I don't want these exact settings to be the default ...
Cool, so I've spent half an hour "exporting" the files. So I'm finished, let's close GIMP. Hey, but what's that dialogue asking me to save unsaved changes of a file that I have just saved? Every single file that just got saved is treated as unsaved just because I was so bold not to use the one and only holy XCF format for reprocessed JPEGs? Okay, just enough for me ...
Next time I'll rather spend my time studying ImageMagick usage to script the task even for less than ten images, rather than doing monkey work.
So, feel free to join me with the moment of silence for the good old GIMP that is just getting buried.
K.
-- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol@jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity." -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On 04/29/2012 09:48 PM, Jonathan Kamens wrote:
I agree. The save vs. export thing in the new version of gimp is mind-numbingly stupid.
Have you used Lightbox and Photoshop from Adobe? Some of their dialog stuff can be equally complex and counter-intuitive...especially Lightbox. Nothing like paying money to be frustrated. :-)
On Sun, 2012-04-29 at 09:48 -0400, Jonathan Kamens wrote:
I agree. The save vs. export thing in the new version of gimp is mind-numbingly stupid.
Makes perfect sense to me. It's the same logic used in Audacity. You are always losing information when 'saving' to an image format - the record of your edits to the file. You're exporting for production, you're not saving your work.
BTW, CCing Red Hat internal lists and public lists on the same mail is very bad form, Karel.
On 05/02/2012 05:36 PM, Adam Williamson wrote:
On Sun, 2012-04-29 at 09:48 -0400, Jonathan Kamens wrote:
I agree. The save vs. export thing in the new version of gimp is mind-numbingly stupid.
Makes perfect sense to me. It's the same logic used in Audacity. You are always losing information when 'saving' to an image format - the record of your edits to the file. You're exporting for production, you're not saving your work.
It doesn't make sense for most people, because most people don't give a flying fig about "lost information," they just want to edit an image and be done with it. Optimizing an interface for the minority of people who use it is not wise, especially when the people who /do/ care about it are knowledgeable enough to know how to make the program do what they want even without changing the interface.
You could argue that it might make sense for those people when they're starting something new from scratch, but when loading an image of a particular format into GIMP, it should save in that same format by default.
In any case, changing the behavior without making it configurable by the user, was just totally gratuitous and stupid.
The /smart/ way to accomplish what they were trying to accomplish would have been to add a File | Import... command, and a corresponding "--import" command-line option, and a corresponding "Import into GIMP" context menu item, which takes an image in whatever format is being imported but then defaults to saving in XCF format.
jik
Another option would have been the LibreOffice approach... Warn the user about saving in a non-native format but allow it (and allow the warning to be turned off).
Another option would have been for the save dialog to default to FCC but allow the user to change it to any other format. Instead, it's an entirely separate command to save the image to the file it was loaded from. Ridiculous.
Jik
On Wed, 2012-05-02 at 17:45 -0400, Jonathan Kamens wrote:
On 05/02/2012 05:36 PM, Adam Williamson wrote:
On Sun, 2012-04-29 at 09:48 -0400, Jonathan Kamens wrote:
I agree. The save vs. export thing in the new version of gimp is mind-numbingly stupid.
Makes perfect sense to me. It's the same logic used in Audacity. You are always losing information when 'saving' to an image format - the record of your edits to the file. You're exporting for production, you're not saving your work.
It doesn't make sense for most people, because most people don't give a flying fig about "lost information," they just want to edit an image and be done with it. Optimizing an interface for the minority of people who use it is not wise, especially when the people who do care about it are knowledgeable enough to know how to make the program do what they want even without changing the interface.
GIMP is a professional image editing suite, just like Photoshop. It's not a basic touch-up tool. It doesn't really make sense to criticise it on the basis that you want to use it for something it's not really designed to do.
In any case, changing the behavior without making it configurable by the user, was just totally gratuitous and stupid.
Don't get me started, but I'll give you the short version: it's very easy to say "well just give me an option to make it do whatever it is I wanted!", but it's very often not a very good idea for the developers to actually do so. This is the cause of featuritis, which is in turn the cause of impossible-to-use interfaces and almost all bugs (which are, at root, usually the result of code complexity). When your app has a hundred interface configuration options and consequently, say, a few billion codepaths, it's almost impossible to anticipate all the consequences of _any_ code change. Keeping the number of codepaths to the minimum possible is vitally important to producing stable and reliable code; implementing any old UI option anyone asks for is a great way to wind up with an excessive amount of codepaths.
The smart way to accomplish what they were trying to accomplish would have been to add a File | Import... command, and a corresponding "--import" command-line option, and a corresponding "Import into GIMP" context menu item, which takes an image in whatever format is being imported but then defaults to saving in XCF format.
Did you check and see if they considered it and saw some drawbacks to it, perhaps? Did you try simply suggesting this, to the GIMP authors rather than the Fedora test list (I'm still not sure why this thread is here), without the disapproving editorial? As someone else replied to this thread, it's vital to present criticism with an attitude that makes the person you're giving it to want to act on it, rather than get defensive. Saying what they are doing is 'ridiculous', implying that it's dumb (by saying another way would be 'the smart way'), making unsubstantiated assertions about 'most people' (have you done a scientifically supportable poll?), and calling their software 'mind-numbingly stupid' are all excellent ways to make developers more inclined to be defensive and less inclined to believe that you have something constructive and useful to suggest.
Dude, the only reason I continued the discussion here is because you did. :-) You're right, this is not the place. I'll take it up with the GIMP folks.
Jik
Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a):
GIMP is a professional image editing suite, just like Photoshop. It's not a basic touch-up tool. It doesn't really make sense to criticise it on the basis that you want to use it for something it's not really designed to do.
and which tool are we supposed to use?
so far, Shotwell and Digikam were proposed
but these aren't "basic touch-up tools" either: Shotwell - A photo organizer for the GNOME desktop digiKam - A digital camera accessing & photo management application
K.
On Thu, 2012-05-03 at 12:31 +0200, Karel Volný wrote:
Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a):
GIMP is a professional image editing suite, just like Photoshop. It's not a basic touch-up tool. It doesn't really make sense to criticise it on the basis that you want to use it for something it's not really designed to do.
and which tool are we supposed to use?
Even if the answer were 'there isn't one', that's not GIMP's fault. The GIMP authors want to write a professional photo editor. If no-one wants to write a simple touch-up tool, that's hardly the GIMP authors' fault, is it?
so far, Shotwell and Digikam were proposed
but these aren't "basic touch-up tools" either: Shotwell - A photo organizer for the GNOME desktop digiKam - A digital camera accessing & photo management application
And we all know summary lines are always kept carefully up to date and fully accurate and contain a complete description of all the app's functionality in their 80 characters or less! (email really needs a :rolleyes: emoticon).
It's really not difficult to actually _run_ either app and have a look at what it can do. Shotwell has some pretty basic editing tools - more 'enhancement' than editing - but Digikam has some pretty advanced functionality these days. See http://docs.kde.org/development/en/extragear-graphics/digikam/image-editor.h... , for a quick indication of what it can do.
So, I took my concerns over to the gimp-user mailing list, where apparently this issue has been argued over a number of times.
According to the developer who designed and implemented this change, GIMP has a "vision" for what it wants to be and a "target audience" of intended users, and people like me who find the new interface to be awful "are probably not a targeted GIMP user."
The purpose of the new change was explained during the thread. Several alternative methods of accomplishing the same purpose without breaking any existing use cases were described. To every one of them, the developer responded that those methods either weren't in accord with the "vision" of the application or would interfere with unspecified functionality to be implemented later.
The developer in question is perfectly happy with the idea that by remaining true to its "vision," GIMP is going to drive away many users.
As for alternatives, krita (the RPM is "calligra-krita") and pinta, both of which are available in Fedora, were suggested for people who just aren't professional enough to grok the One True GIMP Way.
jik
On Thu, 03 May 2012 07:49:28 -0400 Jonathan Kamens wrote:
The developer in question is perfectly happy with the idea that by remaining true to its "vision," GIMP is going to drive away many users.
Just another example of the Vogon Effect...
Dne Čt 3. května 2012 07:49:28, Jonathan Kamens napsal(a):
So, I took my concerns over to the gimp-user mailing list, where apparently this issue has been argued over a number of times.
thanks a lot; also for sumarising here
As for alternatives, krita (the RPM is "calligra-krita") and pinta, both of which are available in Fedora, were suggested for people who just aren't professional enough to grok the One True GIMP Way.
krita is more a painting tool than photo manipulating
pinta is a mono bloat - and it doesn't work for me:
[kvolny@kvolny ~]$ pinta
Unhandled Exception: System.ArgumentException: 'gtk-close' is not a valid resource name of assembly 'Pinta.Resources, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null'. at Gdk.PixbufLoader.InitFromAssemblyResource (System.Reflection.Assembly assembly, System.String resource) [0x00000] in <filename unknown>:0 at Gdk.PixbufLoader..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in <filename unknown>:0 at Gdk.Pixbuf..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in <filename unknown>:0 at Gdk.Pixbuf.LoadFromResource (System.String resource) [0x00000] in <filename unknown>:0 at Pinta.Resources.ResourceLoader.GetIcon (System.String name, Int32 size) [0x00000] in <filename unknown>:0 at Pinta.ResourceManager.GetIcon (System.String name, Int32 size) [0x00000] in <filename unknown>:0 at Pinta.ResourceManager.GetIcon (System.String name) [0x00000] in <filename unknown>:0 at Pinta.Gui.Widgets.OpenImagesListWidget..ctor () [0x00000] in <filename unknown>:0 at Pinta.OpenImagesPad.Initialize (MonoDevelop.Components.Docking.DockFrame workspace, Gtk.Menu padMenu) [0x00000] in <filename unknown>:0 at Pinta.MainWindow.CreateDockAndPads (Gtk.HBox container) [0x00000] in <filename unknown>:0 at Pinta.MainWindow.CreatePanels (Pinta.WindowShell shell) [0x00000] in <filename unknown>:0 at Pinta.MainWindow.CreateWindow () [0x00000] in <filename unknown>:0 at Pinta.MainWindow..ctor () [0x00000] in <filename unknown>:0 at Pinta.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: 'gtk-close' is not a valid resource name of assembly 'Pinta.Resources, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null'. at Gdk.PixbufLoader.InitFromAssemblyResource (System.Reflection.Assembly assembly, System.String resource) [0x00000] in <filename unknown>:0 at Gdk.PixbufLoader..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in <filename unknown>:0 at Gdk.Pixbuf..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in <filename unknown>:0 at Gdk.Pixbuf.LoadFromResource (System.String resource) [0x00000] in <filename unknown>:0 at Pinta.Resources.ResourceLoader.GetIcon (System.String name, Int32 size) [0x00000] in <filename unknown>:0 at Pinta.ResourceManager.GetIcon (System.String name, Int32 size) [0x00000] in <filename unknown>:0 at Pinta.ResourceManager.GetIcon (System.String name) [0x00000] in <filename unknown>:0 at Pinta.Gui.Widgets.OpenImagesListWidget..ctor () [0x00000] in <filename unknown>:0 at Pinta.OpenImagesPad.Initialize (MonoDevelop.Components.Docking.DockFrame workspace, Gtk.Menu padMenu) [0x00000] in <filename unknown>:0 at Pinta.MainWindow.CreateDockAndPads (Gtk.HBox container) [0x00000] in <filename unknown>:0 at Pinta.MainWindow.CreatePanels (Pinta.WindowShell shell) [0x00000] in <filename unknown>:0 at Pinta.MainWindow.CreateWindow () [0x00000] in <filename unknown>:0 at Pinta.MainWindow..ctor () [0x00000] in <filename unknown>:0 at Pinta.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0
/me is going to file a bug
thanks for the suggestions anyway
K.
pinta is a mono bloat - and it doesn't work for me:
....
/me is going to file a bug
https://bugzilla.redhat.com/show_bug.cgi?id=821398
Dne Čt 3. května 2012 12:18:46, Adam Williamson napsal(a):
On Thu, 2012-05-03 at 12:31 +0200, Karel Volný wrote:
Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a):
GIMP is a professional image editing suite, just like Photoshop. It's not a basic touch-up tool. It doesn't really make sense to criticise it on the basis that you want to use it for something it's not really designed to do.
and which tool are we supposed to use?
Even if the answer were 'there isn't one', that's not GIMP's fault. The GIMP authors want to write a professional photo editor. If no-one wants to write a simple touch-up tool, that's hardly the GIMP authors' fault, is it?
I don't blame anyone for not writing an alternative - unfortunately, the thing is that until recent version, I was able to use the "professional" tool for my "amateur" tasks without much problems
now it breaks my workflow
I like examples so another one:
I'm no professional lumberjack
I'm perfectly happy to prepare some wood for our garden fireplace using some cheap electric chainsaw from the nearest hobbymarket - the "amateur tool"
now if someone would give me a "professional tool", some heavy duty chainsaw like Husqvarna 595 XP, I bet I would have no problem to use it for my task
why this doesn't work for (some) software? - do really all the professionals scratch their right ear with left hand?
so far, Shotwell and Digikam were proposed
but these aren't "basic touch-up tools" either: Shotwell - A photo organizer for the GNOME desktop digiKam - A digital camera accessing & photo management application
And we all know summary lines are always kept carefully up to date and fully accurate and contain a complete description of all the app's functionality in their 80 characters or less! (email really needs a :rolleyes: emoticon).
okay, so you say the sole purpose of these are to be "basic touch up tools"?
It's really not difficult to actually _run_ either app and have a look at what it can do.
yep, I've actually run Digikam
the startup takes longer than for GIMP
it trashes my system with useless databases and steals the control over my files
and manipulating images eats more memory than in GIMP
Shotwell has some pretty basic editing tools - more 'enhancement' than editing - but Digikam has some pretty advanced functionality these days. See http://docs.kde.org/development/en/extragear-graphics/digikam/i mage-editor.html , for a quick indication of what it can do.
that doc doesn't say (or I don't see it) how to start just the editor, without all the bloat of "collection management"
K.
On Mon, 2012-05-14 at 12:04 +0200, Karel Volný wrote:
I like examples so another one:
I'm no professional lumberjack
I'm perfectly happy to prepare some wood for our garden fireplace using some cheap electric chainsaw from the nearest hobbymarket - the "amateur tool"
now if someone would give me a "professional tool", some heavy duty chainsaw like Husqvarna 595 XP, I bet I would have no problem to use it for my task
why this doesn't work for (some) software? - do really all the professionals scratch their right ear with left hand?
That's not a very good analogy. Chainsaws are designed to do precisely one thing: cut through certain types of material very quickly. A 'professional' chainsaw is only one that can cut even faster and, probably, with higher reliability when used frequently. The professional chainsaw user may cut down more trees more often than the amateur, but they're both fundamentally _just cutting down trees_.
This is not very comparable with the situation under discussion here, where the amateur user is likely to be, say, adjusting the brightness of a photo or rotating it 90 degrees, while the professional user is likely to be designing the graphics for an entire website from scratch, or something like that. You see the difference in complexity.
On Mon, May 14, 2012 at 11:02:36AM -0700, Adam Williamson wrote:
This is not very comparable with the situation under discussion here, where the amateur user is likely to be, say, adjusting the brightness of a photo or rotating it 90 degrees,
If you think that "amateur" photo editing is limited to that then indeed gthumb, or such over overwrought concotion like digikam, will be good enough. The reality is somewhat different from your limited view.
while the professional user
Anybody involved professionally or "semi-professionally" with _photography_ will not touch GIMP with a ten foot pole for that simple reason that GIMP is using 8-bit colour. Nothing particular about vagaries of a user interface. This is not a snobbery. For a serious manipulation of photographs, especially raw files, 8 bits is definitely not enough. Even if GIMP will eventually get a deeper colour I am afraid that this damage is already done and not likely reversible.
is likely to be designing the graphics for an entire website from scratch
Websites can be filled with impunity with all kind of graphics junk. I am not sure what this has to do with complaints from Karel but apparently some like it one way and some other. Still GIMP is supposed to be scriptable. Gratituous changes likely to break an untold number of accumulated scripts do not sound like a sane idea.
Michal
On Sun, Apr 29, 2012 at 10:25, Karel Volný kvolny@redhat.com wrote:
So, feel free to join me with the moment of silence for the good old GIMP that is just getting buried.
I share your pain. I've given up on Linux image editors.
For simple stuff (circling text on screenshots, writing text over them) I just install WINE and use good old Paint Shop PRO 5.0. It's from the age of Windows 98 yet works wonders for my needs.
Google "PSP501ev.exe". It's damn small too.
Another option is Java Image Editor. http://www.jhlabs.com/ie/index.html
But sadly it bombs with OpenJDK, it worked fine with JRE. I keep forgetting to report the bug, I might do it now... FC
Dne Ne 29. dubna 2012 11:40:49, Fernando Cassia napsal(a):
On Sun, Apr 29, 2012 at 10:25, Karel Volný kvolny@redhat.com
wrote:
So, feel free to join me with the moment of silence for the good old GIMP that is just getting buried.
I share your pain. I've given up on Linux image editors.
For simple stuff (circling text on screenshots, writing text over them) I just install WINE and use good old Paint Shop PRO 5.0. It's from the age of Windows 98 yet works wonders for my needs.
Google "PSP501ev.exe". It's damn small too.
which reminds me ... I want my pmail.exe back ... and irfanview ... oh, those early win95 days ... where is all the free software that was able to do exactly what I needed to do (about the same I need now) with hundreds times less resources?
many years of development passed, and kmail is still unable to join divided messages ... and recently it has lost the search ability, all I get now is the message:
'The Nepomuk semantic search service is not available. Searching is not possible without it. You can enable it in "System Settings".'
wohoo, back to trees, is pine still in repos?
Another option is Java Image Editor. http://www.jhlabs.com/ie/index.html
But sadly it bombs with OpenJDK, it worked fine with JRE. I keep forgetting to report the bug, I might do it now... FC
yes, please do that, report the bug if you like the software, contribute to the development ... it's just that I don't like GIMP any more ;-)
K.