4 ms·

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 graph

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.

galfarragem 12y ago
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.
- brudgers 12y ago
  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.
  - fat0wl 12y ago
    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
    - brudgers 12y ago
      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. [1]: https://www.youtube.com/watch?v=ubaX1Smg6pY&= https://www.youtube.com/watch?v=ubaX1Smg6pY&= [2]: https://code.google.com/p/xee/source/browse/XeePhotoshopLoader.m?r=f16763d221dfca6253983824b470adf553a19e06 https://code.google.com/p/xee/source/browse/XeePhotoshopLoad...
    - richardjdare 12y ago
      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. [1] http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-texture-atlases-in-photoshop/ http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-tex... [2] http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-techniques/ http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-t...
- fenomas 12y ago
  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.
- liber8 12y ago
  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.
agumonkey 12y ago
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.
- lsaferite 12y ago
  Out of curiosity, is it natural because you learned Photoshop first or it's just super intuitive for you? I've touched it a few times but never spent enough time getting comfortable so to me it's all still very unintuitive.
  - agumonkey 12y ago
    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.
mmf 12y ago
Looking at how software has evolved in the last 30 year I will make the following statement: nothing that exists today requires 12 years of coding. :)

galfarragem 12y ago

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.

brudgers 12y ago
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.
- fat0wl 12y ago
  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
  - brudgers 12y ago
    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. [1]: https://www.youtube.com/watch?v=ubaX1Smg6pY&= https://www.youtube.com/watch?v=ubaX1Smg6pY&= [2]: https://code.google.com/p/xee/source/browse/XeePhotoshopLoader.m?r=f16763d221dfca6253983824b470adf553a19e06 https://code.google.com/p/xee/source/browse/XeePhotoshopLoad...
  - richardjdare 12y ago
    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. [1] http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-texture-atlases-in-photoshop/ http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-tex... [2] http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-techniques/ http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-t...
fenomas 12y ago
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.
liber8 12y ago
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.

agumonkey 12y ago

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.

lsaferite 12y ago
Out of curiosity, is it natural because you learned Photoshop first or it's just super intuitive for you? I've touched it a few times but never spent enough time getting comfortable so to me it's all still very unintuitive.
- agumonkey 12y ago
  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.

mmf 12y ago

Looking at how software has evolved in the last 30 year I will make the following statement: nothing that exists today requires 12 years of coding. :)