This was posted to reddit a couple weeks back, and I'll repeat the same comment I made there.
"I spend about 90% of my time in Lightroom and only 10% in Photoshop."
This is why he was able to do this. He isn't using the functionality that Photoshop provides, he's using the functionality that Photoshop Essentials provides. Look at his parity instructions - every feature is found in Photoshop Essentials. If that's all you use, then great, by all means switch over to Gimp. The bigger the userbase it has, the better off it will be.
But don't think that it's going to replace Photoshop in the near future. Non-destructive editing is the biggest thing GIMP is missing in my opinion, but supposedly the move to GEGL will allow them to start development on this ( https://mail.gnome.org/archives/gimp-user-list/2013-December... ).
Smart objects are another huge feature it's missing - not only the ability to downscale losslessly, but also the ability to edit all replicates at once. This is huge for designers. If I'm defining a user control for a design mockup, and I need to make a change to that control, in Photoshop all I have to do is edit the singular smart object source. The source edits will propagate to all the copies automatically. In Gimp I have to do this by hand.
There are some minor features too that bug me. The inability to add a mask to layer groups is a big one for me. Layer effects (while often overused and gaudy) can be really helpful for design work - need to change the color of an icon that's raster art? Just drop a color overlay on it. If you have style swatches, it can be really easy to do fast mockups using this. This in conjunction with Layer Comps (also something missing in Gimp right now) can really help in switching between two or more alts.
A great way to see what Gimp is currently missing in comparison to Photoshop is to look at the development roadmap ( http://wiki.gimp.org/index.php/Roadmap ). If some of your heavily used features are on that list, it might not be worth switching over to Gimp. If you don't see yourself as a user of those features though, give it a shot.
> it has a ways to go before it will actually be a competitor. And it doesn't have a few features that I find incredibly invaluable as an Evernote user:
[list of features snipped out]
As an Octave developer, I frequently hear exactly the same things about Octave vs Matlab, and if I listen too closely, I find it disheartening. Why work on something that will forever suck and not be a competitor, and can't implement the full list of features because we don't have the giant budget of our non-free competitor?
But then I remember that people are typically more flexible than they appear to be when they write these lists, and you'll discover that they may do without some of the features that they list, at least in some circumstances. And that there exist many other people with different lists of sine qua nons who will use the free as in freedom alternative you're working on because they have different needs.
So, to the OpenNote developers and to anyone else implementing a FAIF replacement I say this: don't let these giant lists of features and suggestions about how you'll never be competitive grind you down. There are many people out there who will appreciate your work, sometimes even the people who compiled these lists. Look at the lists, see what you can implement, and don't be disheartened by the parts that seem impossible to implement. Who knows, maybe some day someone will come along and help you implement the parts that seem so hopeless to you.
Instead of the GIMP limping along behind PhotoShop, both dragging their decades-old legacy baggage, monolithic architectures, 1990s pricing models, etc., into the foreseeable future, I wish we had something more like Octave, SQLite, or Python: a powerful, faceless dev platform on which to build graphics-processing apps.
Basically, a runtime that holds a GPU-optimal image model (raster layers, vector layers, non-destructive edit management, multi-session undo, etc.), a set of APIs for sending memory-protected commands to the model, and a growing standard library of routines that have proven useful (network comms for offloading some processes or results to "the cloud", input/output codecs, CSS3, whatever). It would have a relatively easy to use scripting language with some built-in data types such as layer, region, vectorPolygon, gradient, font, etc., plus the usual lists, dicts, first-class functions, etc. Scripts that get a lot of use could be reimplemented in C, etc.
Developers could wrap whatever GUIs they wanted around this engine, creating easy consumer apps such as a slideshow or a camera-to-computer file importer with a magnifying glass and a keep/delete shortcut, all the way up to building clones of PhotoShop, Illustrator, resurrecting Fireworks, and so on.
Maybe someone would build a GUI builder for it that let you drag image rectangles and buttons into a window and script the whole thing, so non-programmers could create lens comparison apps, blink comparators for comet hunting....
I'd so much rather have a platform like this, where the hardest part--the image engine--would be done by experts, and the apps themselves, the feature sets, the UIs, could then be built by hordes of amateurs.
> I'd so much rather have a platform like this, where the hardest part--the image engine--would be done by experts, and the apps themselves, the feature sets, the UIs, could then be built by hordes of amateurs.
Yes, they are, but that doesn't preclude building the underlying data model and functionality as a common platform with shared tools. It also doesn't mean that building that platform and implementing a comprehensive range of functionality isn't a much more demanding task than building a UI on top if you've already got a good foundation.
No doubt there is plenty of hard work to go around, but I think the idea of building more software with this kind of strategy has a lot of potential. It could save on the donkey work for everyone, leaving different developers to focus on the interesting/useful/distinctive aspects for different projects, while retaining some degree of compatibility and robust basic functionality.
It will make more sense if you know that, by "amateur", I mean someone who knows something about image processing, but not enough to build an image processor--someone whose expertise is in something else: photography, public presentation, UI design, etc.
I should have worded my final sentence differently, but in the sense that someone who knows enough about database engines to be able to use one but is an "amateur" at creating them can still use SQLite to build an app incorporating a database engine, my "vision" would let developers whose expertise is not in image processing engine implementation to write apps that incorporated a sophisticated image processor.
Please note that I wasn't the person who you replied to before. In fact, part of what I do professionally involves UI work, so clearly I don't regard UI design as merely work for amateurs. On the other hand, I also find that 90% of the skill in building a good UI has very little to do with knowing how to make dialog boxes and toolbars appear. The functionality behind those UI elements, how that functionality is organised, and presenting everything as clearly and ideally as simply as possible is often far more important, IMHO.
I am quite a user of imagemagick, or imagick in php. This is far more useful than Photoshop or Gimp when it comes to cropping images and applying basic filters such as a sharpen on thumbnail images. I also use Gd2.
You would be surprised at what can be done in code. You would also be surprised at how much of the stuff that can be done in code is done the time consuming way by people with expensive Photoshop rigs.
So, to a certain extend a lot of what you desire can already be done with code. However there is not one single 'graphic artist' degree where such possibilities could be entertained, plus programmers are not allowed to touch images under any circumstances whatsoever. There is a rift valley between programmers and graphic artists, a deep cultural one.
Octave is awesome! Keep up the good work.
At university everyone was begging for Matlab instances from the licence server, while I had 6 instances of Octave open :)
Worse, lightroom is an adobe application. I no longer use Photoshop because I use another Adobe tool more often... Makes the switch to GIMP kind of pointless. Not that I should talk, I hardly use Photoshop any more either, but that's because I live in Illustrator.
My problem with open source graphic tools remains the same. I'm in the print world, either it supports Pantone or it's not that useful of a tool.
>He isn't using the functionality that Photoshop provides
And since that is the same for the vast majority of photoshop users, he provided a super helpful guide for them. It does not say "how everyone can switch to gimp".
You have a long road to hoe before you claim so emphatically that that's true for the "vast majority" of Photoshop users. Photoshop is the 90/10 app to end all 90/10 apps.
I do very straightforward digital art and manipulation and I'd put my head in an oven before trying to do it in GIMP, and I am not using anything complex.
I didn't say you would want to switch. I said most people use little photoshop functionality. If you think that is controversial, then I think you are delusional.
"I spend about 90% of my time in Lightroom and only 10% in Photoshop."
This is why he was able to do this. He isn't using the functionality that Photoshop provides, he's using the functionality that Photoshop Essentials provides. Look at his parity instructions - every feature is found in Photoshop Essentials. If that's all you use, then great, by all means switch over to Gimp. The bigger the userbase it has, the better off it will be.
But don't think that it's going to replace Photoshop in the near future. Non-destructive editing is the biggest thing GIMP is missing in my opinion, but supposedly the move to GEGL will allow them to start development on this ( https://mail.gnome.org/archives/gimp-user-list/2013-December... ).
Smart objects are another huge feature it's missing - not only the ability to downscale losslessly, but also the ability to edit all replicates at once. This is huge for designers. If I'm defining a user control for a design mockup, and I need to make a change to that control, in Photoshop all I have to do is edit the singular smart object source. The source edits will propagate to all the copies automatically. In Gimp I have to do this by hand. There are some minor features too that bug me. The inability to add a mask to layer groups is a big one for me. Layer effects (while often overused and gaudy) can be really helpful for design work - need to change the color of an icon that's raster art? Just drop a color overlay on it. If you have style swatches, it can be really easy to do fast mockups using this. This in conjunction with Layer Comps (also something missing in Gimp right now) can really help in switching between two or more alts. A great way to see what Gimp is currently missing in comparison to Photoshop is to look at the development roadmap ( http://wiki.gimp.org/index.php/Roadmap ). If some of your heavily used features are on that list, it might not be worth switching over to Gimp. If you don't see yourself as a user of those features though, give it a shot.