If you are doing art Krita is a fine Photoshop replacement. So I can understand the switch.
But I'm also a little amazed that there still isn't a good Photoshop replacement.
I think that's because a lot of developers think Photoshop is layers and blend modes. But imho the real strength of Photoshop is the interface. Not only the GUI but also the interaction design.
I can do with Gimp what I can do with Photoshop but it will take a lot more time. In-place text editing, attaching effects to layers (drop shadows), non destructive editing, it's all missing from most Photoshop alternatives.
Also check out Natron (mentioned in the article): https://natron.inria.fr/ I never heard of it but it's looking great!
> But I'm also a little amazed that there still isn't a good Photoshop replacement.
As others have noted, Photoshop is vast. It represents a large investment of domain knowledge that's quite hard to replicate. It has a lot of UI features that allow for powerful, efficient workflows (actions, heavily customizable GUI and shortcuts, even scripting, etc.) beyond its core image creation and manipulation functions. And that's not to mention the entire ecosystem of Photoshop plugins.
That said, the best competing apps I've seen out there are really domain specialist apps. They don't try to be better than Photoshop at everything, just better at one niche. Depending on the tool, they often don't even try to displace Photoshop from the workflow, just add on to it. Mischief[1] is a good example of this category of Photoshop competitor.
If there's to be a significant competitor to traditional Photoshop, my bet would be on one of these "worse than Photoshop, but better at one thing" apps that met with initial success and eventually grew to displace Photoshop from a larger arena. I still doubt that we'd get a total Photoshop "replacement", per se. (Note, that "one thing" might well be "runs on mobile" versus any task-centric domain.)
An addendum to my prior post, I suspect a lot of folks here won't be aware of something: in various professional positions heavily dependent on Photoshop use (e.g. pro photo editing / retouching), it's common practice to have speed tests in the interview process. This part of the interview shows that 1) you know the available tools and know how to use them well for job-typical tasks and 2) you are utterly fluent in the UI, keyboard shortcuts, etc. for the task. Not all pros need this kind of workflow efficiency, but those who do are scary fast at what they do.
A fair bit of Photoshop's design over the years has been influenced by the needs of these kinds of high-skill, high-efficiency workflows.
The thing is that Photoshop is HUGE and does a good job at almost any task involving pixels. There have been projects that do a subset better, like art or graphic design or pixel art, but to do everything Photoshop does probably requires dozens of years of development by a skilled team.
The only thing I miss in Photoshop is a command line (Autocad style). This would be a killer feature.
I hate looking for a command in the menus or remember a shortcut, I would prefer to remember an alias derived from the name (like Autocad). This (and probably a huge reduction in price) is the only way to make me change to something else.
AutoCad began with the architectural premise that user interaction would be primarily via a terminal. It was built with the ability to run headless. It was built with the ability to run in batch mode. Like Unix, it was built on a set of single purpose tools. These tools formed the API and the user interacted directly with it in the form of commands.
The graphic display was a side-effect. Events on the graphic display were mapped back to the API, i.e. mapped back to commands. The reason, most likely, is that in the days of MSDOS AutoDesk had to write hardware drivers themselves or convince third party hardware vendors write them. Having a developer friendly architecture helped in both cases.
Post-Macintosh programs such as PhotoShop went down a different architectural path. There was a pre-existing graphics subsystem and no obvious interest in developing up from the terminal. So these applications were developed down from the GUI. In the days of 256k RAM and 10meg disks, there was a lot of need for expediency and GUI code and application code often mixed. The result was a lack of an AutoCad style API.
If a procedure looks at screen layout directly, how do you turn it into a command from the keyboard with sensible parameters? Such a refactoring is hard, messy, and not at on the feature list marketing has developed. Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage.
Going one step further, in the early 1990's AutoDesk massively refactored AutoCad's code. They took the hit in the form of R13. Then they started adding incredible features with each version again for the next twenty years.
You're actually giving an absolutely amazing path on how one could conceivably develop a real photoshop competitor by doing to pixels what autocad did for cad: to start off from a programmable base. Something along the lines of emacs meets pixels.
AutoCad sells for many thousands of dollars a seat as do its commercial competitors. There is no passable open source alternative for professional work in many industries particularly AEC. AutoDesk's business model is based on selling products that are used to manually translate requirements tossed over the transom into designs.
The developer of a $50,000,000 project is going to pay several million dollars in design fees. There's a lot of value proposition in an easy button. However a lot of domain knowledge is necessary to produce something reliable.
Either way - developing a product to compete with PhotoShop or AutoCad - is a big dollar proposition. There's more capital investment that winds up requiring AutoCad than PhotoShop. A lot of what PhotoShop does is a nice-to-have. Building departments require building plans. Paving contractors require road plans. A billion dollars in those industries isn't even news.
I am currently working on the prototype of such an application :)
I had a similar idea after getting frustrated with Photoshop scripting for my last game project[1]. I'm not ready to show anything yet though, very early days...
I like the idea of your PhotoShopNext, but the video at the bottom has been marked private. Also Antigen looks like a fun game. Any plans for an android port?
The youtube vid was an old demonstration of Ivan Sutherland's Sketchpad software. I will try and find another version.
I'm not sure if there will be an android port of Antigen. The mobile gaming scene is not very conducive to indie devs at the moment:) I also didn't write it in a very cross-platform manner. I won't make that mistake again.
Artistic drawings and photo manipulation have large elements of manual tweaking with visual feedback that are hard to put into programming.
In another field, Blender will make you go insane if you try to do any engineering work with it.
On the other hand doing art with OpenSCAD (you type code with primitives) would probably also suck, though it's good for engineering simple objects precisely.
If you could get the best of both worlds, then yes, but I think you run into limits with scripting in Photoshop alternatives quite quickly.
Architects are artists too and plenty of art incorporates computers. Don't underestimate artists. They'll learn any skill required to express themselves.
Let me clarify, then. What I meant by "artists" was people whose thing is "making two-dimensional art". A group which I am included in.
To most artists of that type I know, the idea of just recording a Photoshop macro to automate a repetitive task is getting into the dark arts. Command lines are scary places to them.
And that's discounting the 2D artists who work in physical media because "computer art has no soul".
There are exceptions - I mean, I used to futz around with assembly programming on my c64 and Amiga, there are people whose visual medium is Processing, there are people making games who are comfortable with one foot in the imagery and one foot in the code - but I am pretty sure that "emacs meet pixels" would not find much traction with the people who use Photoshop as a canvas.
I mean, if "Photoshop" to you is "a bunch of image filters", then sure, we already have "emacs meets pixels" in the person of ImageMagic. But to a 2D artist, Photoshop is not "a bunch of image filters"; it's "paintbrush and canvas".
Architecture is by and large a problem solving business. The sorts of problems it solves are by and large the problems of wealthy and powerful organizations. Architects have a reputation for expressing themselves as a proxy for building something for themselves since the ability to self-fund projects is rare.
To put it another way, a piece of software can be the important artefact. The design for a building is rarely the important artefact. By "making the design his own" an architect produces something for himself, but this is not the important [public] artefact. Moreover, making the design an expression of the architect is often in conflict with the objectives of the client. Guild like structures allow architects to express themselves in ways contrary to the interests of their clients.
Yes, there are projects where developers want architects. Much of the construction industry, however, sees architects as a necessary (or unnecessary) drag upon the project's objectives. Regulatory requirements for an architects involvement are the basis of many an architect's business.
Frank Gehrey is the outlier. AutoCAD LT is very common.
A command line (autocad style) doesn't require programming and the average user doesn't even need to use it, once the GUI expose most API.
The command line in Photoshop would be a way of improving productivity. As an example, I don't know any power-user/really productive Autocad user that works with the GUI. It's a waste of time.
> In the days of 256k RAM and 10meg disks, there was a lot of need for expediency and GUI code and application code often mixed. The result was a lack of an AutoCad style API.
You may be right that this is how it happened, but there's not really any reason for it to have happened that way.
E.g. on the Amiga, which had similar hardware constraints to that, a lot of apps did work similarly to the way you describe AutoCad: everything internally mapped to commands, and the commands operated on the data model and updated the view, and while they were not designed to run headless, they were often designed from the beginning for everything to be scriptable.
This was done because everyone expected the API - from about AmigaOS 2.0 onward, if you didn't have an AREXX API it'd be commented on negatively in reviews etc.
I think the difference is the lack of a culture for scripting. Even with AppleScript, there's not the same culture for scripting in the Mac world. Even less so in the Windows world (outside of developers). Unix users expect scripting and components designed for it. Amiga users expected scripting of gui apps too.
The first computer I owned was an A500. In a box somewhere, I think there are all four of the 1.1 Rom Kernel Manuals...the ones sold in bookstores even after Amiga OS2.0 was well established.
Amiga OS was strongly influenced by Unix. That's what allowed all those ports of Unix commands to fill the FredFish disks. In a sense the Amiga was what a company needed to do when buying a Super Bowl launch ad spot isn't on the table. The Amiga 1000 was beautifully engineered but aesthetics were low enough on the priority list that the sidecar made it to market.
One could make a case that all that Rexx integration was a waste of effort: The Amiga died for just about everyone but a few hardcores and software like Photoshop lives on. The ball of mud is the most successful software architecture by volume.
> If a procedure looks at screen layout directly, how do you turn it into a command from the keyboard with sensible parameters? Such a refactoring is hard, messy, and not at on the feature list marketing has developed.
It doesn't seem like one would need to refactor to do something like:
$ filter layer1 blur
With things like lossless editing, Photoshop has to maintain state somewhere to be able to apply all of the layers to get the image. I get that you might not be able to say do something like:
$ selection x1 y1 x2 y2
> Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage.
It seems to me that some of the issues are in the nature of the data. It's a bitmap (or several). The amount of state is equal to the number of pixels. A 1024 x 1024 bitmap has 2^20 bits of state.
Though we can usually compress the representation of that state, what we don't have is a high level semantics for describing it. We don't have a language for chunking bitmaps that works independent of a specific context. We can make a DSL for describing GUI elements. It won't work for photographs. Outside of a few specific domains, we don't have a handle into content. We can't write programs for bitmaps that manipulate babies and cars and pop-up menus easily.
If we deal with the bitmap as a whole, then it's trivial to write a command that transforms the bitmap as a whole. But without facial recognition style recognition for everything we're stuck dealing with pixels a lot of the time.
I imagine that there are a lot of operations that could benefit from a shell-like interface, even if there are certain operations that don't lend themselves to the paradigm. Even just being able to say something like "Create a circular selection 'box' with a radius of 50px" that you can then manually manipulate with the mouse could be useful. More useful than trying to create the same thing via just mouse input.
I don't disagree. My view comes from having switched away from AutoCad about seven years ago to a Cad package originally developed for the Mac. I ranted about the ways in which it's API sucked compared to AutoCad to the point of being banned from the bulletin board...in those days I enjoyed trolling more than today.
Munging the application logic and the display does have some advantages, and there are some aspects of the work-flow provided by the not-Autocad software that are really useful for producing drawings...Solid filling rectangles is not a geometric idea but it allows for placing the rectangle in the foreground of an image.
But unlike AutoCad keyboard entry is always a second class citizen and there's no way not to use the mouse in the middle of trying to complete just about every interaction. Indeed one of my big rants was about some distinction between tools and commands where binding a command to an icon required an extra click in the drawing area in order to run.
There's no reason that a circular selection box couldn't be moved with "$> move 129 -204". Indeed if you're working pixel by pixel, that's exactly the way to get exactly what you mean. Exacting layouts are exacting because we hold that level of detail in our heads.
i understand your point about history but disagree with your conclusion...
at this point its not like Adobe would have to re-architect the system cuz im sure when you click & use a tool it is not going "uhhh photoshop system, man, could you like look into this screen & blur stuff" it is calling a well-defined method with an x/y param. They just need to alias those methods from a simple command shell
Photoshop does have a Javascript scripting system and IDE (ExtendScript Toolkit) that exposes many of its features.
Unfortunately its pretty slow and clunky, and it doesn't let you draw programmatically or anything like that.
I used it to create a texture/sprite atlas maker for game development[1], and to do batch image composition for animation frames in my last game project[2].
I tried to use it to create animated image processing effects, but I ended up having to use Processing, after reimplementing a bunch of Photoshop features in Java.
Alan Kay talks about a text justification bug in MicroSoft Word that's been around for 30 years. [1] PhotoShop is many many millions of lines of code, making an API that covers all of it is unlikely, and at best it is practical to make some subset of its procedures available from a command line.
In contrast, an AutoCad drawing is serializable to a text file of AutoCad commands.
At the core of the software architecture, it's analogous to REST versus SOAP soaked in kerosene with three decades of software evolution piled on top. Nobody loves AutoCad's DXF with deep abiding passion, but nobody would take "DXF is not my favorite file format" [2] rants in the source code seriously.
The point from AutoCad's <Point:> command is the same point that everything else is built on. It's bottom up. So in the end, a full blown command language for Photoshop would need a <Pixel:> command. And everything else, all the way up, would need to rely on calls to <:Pixel>. That's the level of granularity required to implement a command API like AutoCad's.
That's the joy of AutoCad's command line. It's programming with a REPL. Photoshop doesn't have one at its core.
Not what you're looking for, but as a point of interest Photoshop actually has accumulated several layers of internal scripting over the years. The newest and coolest is an embedded Node.js server - you can pull in arbitrary node modules and run them in a context where various PS-related APIs are exposed.
The drawbacks are:
1. Not all features have nice interfaces. For some things you need to go through this ancient, hairy API based on tons of (sparsely documented) magic strings.
2. Most of the APIs are made to support the UI, so it can be hard or easy to do things depending on how the UI works. For things involving settings dialogs, or anything that's a multistep process in the UI, it can be pretty nontrivial.
This is one thing I love about macs. Click help, type in the first word of the command, and it will highlight where that command is in the menu. No more hunting or trying to remember seldom-used shortcuts. Apple has had this feature for years and years. I still can't believe Microsoft hasn't copied it (or perhaps it has with 8? I'm still using 7 on my main editing machine.) I will often fire up PS on my Macbook just to use the search to find a command, rather than poking around the menus for it on my main machine.
To me, the most important quality of photoshop is the UI/UX. This is anecdotal, but I've toyed with a lot of interactive graphical programs and Photoshop often feels natural (the kind of shortcuts sequence you end up trying in other software without thinking about it). Compared to this GIMP feels infinitely bloated.
Photoshop was the first I learned true, but I try to be fair, I guess many people (especially here) learned different paradigms and can abstract over their own history.
For instance I've learned to appreciate and love Vim even though I've learned Emacs first (and is my daily editor). I won't dismiss it because it's superficially different (names, layout, bindings) or because it breaks my habits.
I have some kind UX abstract grid in mind where things could make better sense without being the Emacs/my-preferred way. GIMP had too many wtf in a row for me to keep trying, and ends up making me want to write imagemagick scripts in Emacs instead.
Creative work requires continuous experimentation and refinement. If a tool lets you do this easily and without getting in the way, your brain is free to focus on the piece that you are creating. So, while it is true that one can do the same things using another tool like Gimp, the fact that it takes significantly more time and effort means that it will be much harder to end up creating the same art.
The funny thing is, engineers actually understand this perfectly when talking about text processors, but for some reason they (we) often fail to generalise it to other fields.
Yes, a million times yes. Mostly in engineering-focused teams, it is very common (even when they have designers on the team).
It's a sad state of affairs, but it is pretty common for the designer to just "push pixels" on engineer command - the engineer conceives (horribly) the UI in his head, sketches, and then tells the designer to make it pretty. The designer is merely a decorator. I saw it happen a lot in a telco, but it happens almost anywhere where the engineering skills are considered the core.
Well as a designer, its not realy easy to help on opensource projects. Its hard to join something like that and if you do, the projects themselves usualy need UX design not some pretty colors and some logo. But thats exactly what engeneers mostly want. I dont blame them, they spend lot of effort to make the project and they have their own ideas about how it should work (for them).
But good UX is about objectivity and about efficiency. Its also a process.
Another thing is that there is no tradition in that for designers. Opensource programming free time fun project for programmer is equivalent maybe something like making print posters for designers.
And interaction design schools are hardly helping that, they should make students to help out on opensource projects maybe as part of their assignments/diplomas.
How would i join opensource projects that need designers? I dont know.
I always found this interesting, I get on with and learn more quickly interfaces built by other programmers even when such interfaces are regarded as "badly designed" by none-programmers.
I think it's because as a programmer my mental model more closely matches that of another programmer.
Which is terrifying when I do UX stuff myself because then I worry I'm building stuff for other programmers when I'm aiming at general users.
The problem is that you have much higher understanding of the inner parts of software. You might group functions together by type pf operation you do, by used algorythm... Your mind knows that these are operations that work with memory so you look there.
For example average user has mostly no understanding of things like reading data into memory and that it must be saved aferwards. For him the edit is already on the screen, like when you write on paper.
Also ux quality is imposible to measure. Lot of times its desicions between Ok bot not great vs Ok but not great.
The biggest problem on opensource projects is no consistent unifying philosophy, no aim. Users can learn anything, it just has to be consistent. Lot of times there is one developer wanting to see every posible function on the sceen, second one is making contextualy avare menus and thir one believes in text input search. Three of those together are just a mess.
> Also check out Natron (mentioned in the article): https://natron.inria.fr/ I never heard of it but it's looking great!
Apparently from INRIA, the french national digital research institute. They actually have quite a lot of really good projects that fly a bit under the radar in the US. They're also behind things like Scikit-learn machine learning tools...
I think there isn't a good Photoshop replacement because it tries to do too much. For example, it's used by both photo editors and web designers. The crossover of requirements there is really quite small - so I'm quite happy to see smaller apps hacking away at a subsection of what Photoshop does.
For example, I work almost exclusively on web UI stuff, and I love Sketch. The UI just makes so much more sense to me.
I don't think it does. It offers a massive feature set that is useful to different people in different ways, but there is still a lot of crossover.
Maybe you're pigeon-holing users based on their 'roles'. Web designers/photo editors, when working in Photoshop are both working with layered images at the end of the day. Plus people have different ways of working. You may do web UI stuff, but you may have a completely different workflow to another web UI designer.
I think this points to a bigger difference between engineers and "normal people" - programmers tend to have grown up on the Unix philosophy of "do one thing well," but most everyday users find out that they need to use a different tool for a task and get irritated with that.
The fact that Photoshop can do so many things is a huge appeal to users, because if they need to do some workflow item that maybe isn't part of their normal job, they can still do it within a familiar tool. This is handy and saves learning time.
Compare this to "unix people" who are likely to regard a tool with a lot of functionality they use rarely as bloated.
The big feature of Photoshop is that it's Photoshop. A typical designer has dozens of expensive plugins for Photoshop, their PSDs only work in Photoshop and they only know how to use Photoshop.
Changing would be expensive and risky, and would only be worthwhile if lots of their colleagues and clients were also moving.
So Adobe has intentionally created a lot of barriers to exit, and even if an amazing good open-source package came out today, it would struggle to gain traction.
There is one contender that's been getting some traction with a significant minority iOS designers; Sketch - http://bohemiancoding.com/sketch/
It's nowhere near an entire replacement but it has a very different take on the UI which arguably makes it better suited for app UI design and it appeals to the "cool kids" ... those starting out their design careers with app related projects as best demonstrated by this book / tutorial - https://designcode.io/
And that's probably the only way to unseat Photoshop - with a generational change.
There is also the printer-oriented color management in Photoshop, whereas Gimp appears more screen-oriented. Designs made in sRGB may look radically different when converted to CMYK.
If you go to print, the fact that Adobe's tools understand multiple color models is a HUGE advantage over most other tools, which usually only work in RGB. It's not just open-source competitors, it's smaller teams trying to compete in this space as well.
>>> Changing would be expensive and risky, and would only be worthwhile if lots of their colleagues and clients were also moving.
This is a huge point. Adobe is so entrenched in so many corporations, it's almost like MS Office to a degree. Even in most startups, if you want to hire someone, you're going to go with Adobe products instead of having a training/learning curve to worry about.
>> So Adobe has intentionally created a lot of barriers to exit.
Of course they did. Once you have an entrenched software platform, you want people to continue using your product, regardless of whether they like it or not. It's just smart business. Not really good business, but smart nonetheless.
Maybe that's true when dealing with clients who also use photoshop, but the majority of artists I know love to experiment with new software - and hardware - and flit between them depending on the job at hand. Photoshop is a bloated, expensive piece of software, but Adobe listen hard to the people using it, and it's really good at what it does, and that's why people keep going back.
For me the absolute killer feature for Gimp or Krita would be a way to save the editing history, which is currently lost with all the levels of 'undo' when you save in native format.
Versioning for image editing; I don't know how it would be done but by Jove it would be a time-saver.
I am the main developer of a new painting application called Leonardo ( http://www.getleonardo.com ) which include this feature for our native .LEO file format.
I gave the beta a try and it seems pretty nifty! Great job!
Since I'm an programmer who's an aspiring artist, I have a few questions:
1. Is there a way to turn off additive brush-layering (ie the opacity does not change when you stroke over the same place)[1]? I am used to Krita and Photoshop having an option to toggle this. The only way when the opacity increases is when the pressure increases.
2. Is there a way to create custom brushes? I'd love to be able to create my own. Also, Krita has some nice ways of "scripting" brushes which was nifty. The current ones are more than fine, but I usually make certain "helper" brushes to speed things up a little.
3. Do you plan to open-source certain parts of Leonardo? It'd be great if you open-sourced the specification for .leo and, the brush format, so it's easier to create conversion tools. I'm not a marketing expert, but I imagine having the ability to import brushes from Photoshop would be a huge benefit.
1. Yes, we have one parameter we call "flow" that does what your GIF shows. We also have a parameter called "opacity" that does what you want to do. To create a brush that behaves the way you want do the following: open brush settings panel (located on the upper right of the screen), go to the "flow" tab, change "flow pressure" to 100%, go to the opacity tab and change "opacity pressure" to 0%.
(we need to improve the brush settings)
2. Yes, use the same brush settings as described above. You can click on "tip" (round circle for standard brush) to change brush tip.
3. We might open source the brush format in the future.
4. Maybe in a distant future. The problem with plugins is that you have one more API to keep backward compatible.
Thanks for testing Leonardo! Please feel free to email me if you have any more questions or feedback: henning.tegen 'at' getleonardo.com
The "Ghost Point" and "Isometric" strokes look very useful. While with practice I think I'll develop a steady hand with my Wacom, those features look really helpful when precision is needed.
FYI, you can also add those features (lazy mouse, curved lines, isometric and perspective constraints) to any art app (including Photoshop) with the Lazy Nezumi Pro app.
http://lazynezumi.com
That, in a nutshell, is one of Photoshop's great strengths. It's not that you can save undo data, but that most things don't need to be undone if you take advantage of smart objects (decomposable composites, more or less) and adjustment layers. Even deformation meshes (warps, liquify, etc.) can be stored, changed and re-applied (to multiple things, including masks). I'm not really committed to anything in Ps until I export, and then the PSD is still there if the client wants a change. I know that colour management and bit depth have been at the top of a lot of lists (and rightly so), but if anyone wants to step up and challenge Ps as the professional tool, then non-destructive editing is not optional.
Krita has had filter layers (non-destructive, mask + filter layers right inside the layer stack) since _2005_. Krita has had color management, with icc profiles and cmyk, rgb, lab and xyz since 2005. OpenColorIO based color management since 2012. Krita 2.9 has non-destructive transform masks -- and 2.9 is in beta right now. You can have selections masks local to a layer. There have been group layers for a decade.
So, yeah, non-destructive editing is not optional. It's been around for about ten years, in Krita.
So, only a little behind. I'm not knocking Krita, nor am I saying that Ps is beyond reach and will forever be the standard. I welcome real competition, because frankly there hasn't been anything close enough in far too long. And much of what has gotten pretty close has thrown the third-party ecosystem overboard without replacement -- which may in some cases be necessary, but when you tell people that their "one hour's work in a click" time-savers are going away, they're not going to be impressed with what you've done to their workflow and profitability.
Not really versioning, but Ormr [1] is built around completely non-destructive editing with history baked into each project. Still in beta but worth a look.
I bought affinity designer for Mac, it's a vector software but it has a history slider, I don't think it saves with the file format but it's an amazing take on history display. One 3D program I saw did save the history with it, but I can't recall the name.
Git handles binaries perfectly fine. Your repo is gonna get big fast, and it isn't going to handle merges, but if you just want a linear version history and are used to git, you might as well use it.
He probably means to add the project file to the versioning system and commit regularly so that you can rollback to a previous version. It's way less flexible than Undo though.
The real killer feature of Photoshop is YouTube videos and books. I am learning it right now and it's extremely helpful to watch tutorial videos. There is almost nothing for GIMP so if you don't know exactly what you are looking for, you are out of luck.
I was a long time PS user on Windows. When I switched to linux as my work computer, the only suitable replacement was Gimp. The interface drove me absolutely crazy - window management is from some kind of sadist (floating toolbar panels) and its not possible to "Save as" (only Export).
Since then I have tried Pinta Image Editor - the toolset is far simpler than PS/Gimp, but it is 100x more intuitive. It reminds me of Paint.NET
Gimp used to be better than that like having a "Save as" that worked or "Save" just saving the PNG you loaded and changed, instead of insisting on saving an XCF. I think they we're too close to some Gnome developers and got infected by their way of thinking.
The Gimp has certain, err, noteworthy notions about user interface design.
Nevertheless, single-window mode has been around for years (I think): Select 'Windows'->'Single-Window Mode'.
The distinction between Save and Export is one of those measures to gently remove the user's feet from below the barrel, I imagine (only the native xcf-format stores certain information, like layers).
They should make single-window the default. Many new people do not know about it and quit Gimp before finding out about it.
But more importantly, the worst thing I have to face in GIMP is layer/selection management. I understand how it works, I worked with it for years, but it's annoying as fu... very annoying.
Pinta in Ubuntu (14.04LTS) still lacks beziers and an ability to resize selected bits of an image (you have to resize the whole image at once). Then there is "gnome paint" which is merely a placeholder for a yet-to-be paint application (no functionality).
So does Gnome desktop have a flagship GTK paint application in the vein of paint.net?
> But I'm also a little amazed that there still isn't a good Photoshop replacement.
Photoshop has loads of features, really, most users use like 1% of these,but professionals are required to know Photoshop. Because professionals will share photoshop files.
I mean, you wouldn't use Sublime Text 2 to code in C# right? sure you can do that, but a .net shop requires you to know Visual Studio Pro.
> I can do with Gimp
Gimp is a sad story imho,it feels too much like developpers doing UX-UI and failing at doing it properly. It has great features but feels way to clunky and un-inspiring for artists.Gimp needs to be heavily redesigned.
I wish Fireworks was still developped, it was an amazing tool for drawing,especially for webdesign,2d game design and prototyping.And god it was so easy to write complex plugins with a few lines of Javascript, it was mind blowing. I wish Adobe never bought Macromedia.
I was a fairly light Photoshop user - occasional retouching, compositing, and web UI stuff. Last year I switched to Pixelmator due to cost and found it relatively painless, the UI is similar enough to Photoshop that it's easy to switch and IMO more attractive than Photoshop CS3 which I used to use.
I tried Gimp once a few years ago and had a far worse experience, it slowed me down a lot compared to Photoshop. This may just be because I didn't devote enough time to get used to it.
But I'm also a little amazed that there still isn't a good Photoshop replacement.
It's hard. Inkscape is a good Corel Draw replacement, and the drawing functions in Open/Libre Office aren't bad. In 3D land, there's Blender, which is a good 3D animation program. (It still has the UI from hell, though. 3D UIs are really, really hard to do well.) GIMP started life as a command-line program and had a GUI tacked on later. That never works well.
Pinta Image Editor tries to be Microsoft Paint with some extra Photoshop LE features. It has roughly the right feature set, and a reasonable Photoshop-like UI, but it's so buggy it's useless. Components of the GUI randomly disappear. The drag markers from selection end up in the actual image. Resizing fails for moderately large images. The original developer abandoned it around 2012, and while it's getting some maintenance, it's still not very stable. Putting the current 2014 release into the Ubuntu repository might help.
Gimp is good for basic photo editing and manipulation, but it sucks as a professional-grade tool. Gimp can't handle raw images. It can't handle more than 8 bits per channel, no CMYK support. None of the Photoshop CS5 features (like content-aware spot healing) are there.
Yes, it's better than most Photoshop alternatives, but it would never be a satisfactory replacement for, say, commercial photographers. I mean, I've only casually used Photoshop for random freelance work over the years (for clients who don't want to hire a real designer), and in my limited experience I've done things with Photoshop that Gimp literally doesn't have support for.
Oh my god I think photoshop has a hideous interface. It is accepted due to the massive traction it has and the number of professionals that are used to it.
It's an interface for professionals. It takes awhile to learn, but when you do, you're rewarded with quite efficient access to the tools given how much Photoshop is capable of.
And so what then? You use it because it has traction and because other professionals use it? Or because, as many professionals find, it's the most capable tool for the job at ahnd?
I'm a pretty expert Photoshop user, and I see it as similar to the command-line. It's not intuitive to a brand new user, but once you get it, it's incredibly efficient and productive. I think this is appropriate for a professional tool.
In my opinion, it is all about training. At school I was trained to use Photoshop, so now everything I have to do with this software seems natural. But it wasn't. It is the same feeling for people who switch from MS Office to Open Office. MS and Adobe did a great job of setting standards.
To me, the biggest feature that Photoshop has that others don't is their type support, especially with kerning. I can accomplish most of what I want with other tools until I need to tweak the kerning of a word. Most tools require you to select pixels and move it over and don't support in-place editing.
If you count inkscape as a "photoshop replacement", it does many of the things photoshop/illustrator does, as well as more, and better. Kinda wish someone just merged the concepts of Paint.NET and Inkscape.
Inkscape has free-hand and raster tools, you can do masking and such. The GP mentions "in-place text editing" for which PS presumably uses vector methods. I use Inkscape pre- and/or post- GIMP for things like text layers.
I've long thought that a great graphics package could be achieved if Inkscape and The GIMP (or other primarily raster programmes) could draw to [different layers of] the same canvas. Inkscape lets you link in images which is a small step towards this.
I've been using it on and off since it was Sodiwopi or whatever it was called.
"Inkscape has free-hand and raster tools"
Yes, and Gimp has 'vector tools', so what? GP says "If you count inkscape as a 'photoshop replacement', it does many of the things photoshop/illustrator does" which makes no sense on all levels except the most abstract, like saying a pair of Nikes is like a Mercedes because you can use both to go from point A to point B.
The way the post was phrased with the quotes made it clear that antome felt it was a shaky equivalence. I'd guess they were hooked in with the talk of in-place text editing as being a top differentiator for a _raster_ package (if PS does text manipulation using raster techniques I'll be shocked).
Just consider it to have an implicit "for me" and I'll bet you'll find it hard to find a genuine objection that's worth making.
absolutely agree with huuu. if you're somehow forced to use gimp, there is at least a better gui enhancement/tweak that tries to replicate photoshop's gui:
But I'm also a little amazed that there still isn't a good Photoshop replacement. I think that's because a lot of developers think Photoshop is layers and blend modes. But imho the real strength of Photoshop is the interface. Not only the GUI but also the interaction design.
I can do with Gimp what I can do with Photoshop but it will take a lot more time. In-place text editing, attaching effects to layers (drop shadows), non destructive editing, it's all missing from most Photoshop alternatives.
Also check out Natron (mentioned in the article): https://natron.inria.fr/ I never heard of it but it's looking great!