This might be the most interesting comment from the Editing Software post, which came in rather late in the day from Camilo Polymeris. Camilo points out that not having one program do everything would be a-feature-not-a-bug:
I prefer small, light software that does only one thing and does it well, and am perfectly fine with using one program to organize, one to develop, and one to edit photographs. Plus a bunch of smaller tools to do specialized stuff like panoramas, perspective correction, or HDR, if that is your thing.
In fact, that makes most sense to me. In part it might be my UNIX background, where that approach is standard, and in part the conviction that it leads to overall more flexible and powerful environments, by allowing each user to select the tools that fit his or her workflow the best. So, more than one tool to dominate them all, I would love to see more open intercommunication standards, so each of us can chose their own manager, developer and editor and they still would work nicely together.
Of course we have something approaching this with plugins, although many of those are add-ons to what are already supposed to be full-featured programs. (The more successful plugins then seem to be appropriated by the mother software like the Blob smothering its enemies). It might be interesting to see a "program" that was essentially an empty framework for open-source editing apps that anyone could provide, from which each user could then pick and choose. I don't know enough about it to know how viable such an arrangement might be. It sounds more 21st-century, at least.
Photo Ninja (ya see what I did there?)
I've been experimenting with the nifty Photo Ninja (again) and mean to give PhotoLine a try, too.
Mike
Original contents copyright 2013 by Michael C. Johnston and/or the bylined author. All Rights Reserved. Links in this post may be to our affiliates; sales through affiliate links may benefit this site.
(To see all the comments, click on the "Comments" link below.)
Featured Comments from:
Dave: "I wanted to comment on the original post but didn't have the time...I think we can look at electric guitar for an example of where things might head with image editing software. Guitarists have relied on various effects pedals to modify their tone since the dawn of amplified music. With the digital revolution various guitar effects companies came up with all-in-one digital effects pedals. These all-in-one devices were kind of like Photoshop in that they were designed to be a one stop signal processing solution. However, now that the dust has settled from the guitar digital revolution, most guitarists still use multiple pedals. To get a signature sound a guitarist might use a mix of vintage pedals coupled with some newer digital effect. Guitarist have a very diverse set of tools to choose from. I'm hoping that photography is headed in the same direction."
SerrArris: "I am also following the for-each-purpose-one-program approach. That makes my collection of tools kind of large, but I can work very comfortably that way.
- Scanning—Vuescan
- Fast edit and finalizing from 16 bit TIFFs—Fixfoto
- Batch processing—Irfanview (Fixfoto could also do that, but I am used to the Irfanview GUI for that matter)
- RAW Conversion—DxO Labs and Filmpack
- Noise reduction (not used any more)—Noise Ninja
- Printing—Photoline (Cheapest program that can use ICC profiles)
- Multi layer edit, dodging and burning—Gimp
- Panoramas—Hugin
"As said, I am confortable with that approach. In fact, the complete software package did cost me less than $400 (with DxO being the most part of that), spread over years. And all the software runs on my outdated Thinkpad T61! Amazing."
Stmpjmpr: "I agree that separate, focused tools would be ideal, but it in order to maintain one of the main benefits of apps like Lightroom and Aperture, nondestructive editing, some standards would have to emerge that communicated the effects of the application as instructions instead of rendering the image with the effects applied. Given that this is a technologically huge hurdle, and that the vendors wouldn't agree to any presented solution that didn't put them at the center (witness RAW formats), we're probably stuck with applications that are too monolithic."
The 'framework to hold plugins' model does exist, in a manner, with Lightroom and Aperture. Both allow basic controls and allow very nuanced organization, yet work with more focused plugins for advanced manipulation. Now, it would be even better if you could keep everything non-destructive, but the basic model is there.
Posted by: Rob L. | Tuesday, 11 June 2013 at 01:29 PM
Coming from an IT development background I can sympathise with Camilo's standpoint. Many different types of tasks to achieve, with different filetypes and components and the focused software is almost always easier and more productive.
One caveat though - I hope my photo processing doesn't end up like a stream of mini IT projects....
Posted by: Richard Tugwell | Tuesday, 11 June 2013 at 01:47 PM
From what I've seen, standards and plug-ins are almost polar opposites, in that new versions of applications tend to support old standards, while plug-ins tend to need to be updated to work with the new applications.
GIMP has a plug-in architecture and from what I understand, one of the biggest things holding stable GIMP at 8-bit is the upgrading of various add-ons; the core of GIMP has been ready for quite a while. That's if I understand this correctly: http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL
Posted by: Michael Barkowski | Tuesday, 11 June 2013 at 02:39 PM
... and so I wonder if what needs to be done is to separate GIMP 2.10 from its plug-ins so that it can become stable by itself.
Posted by: Michael Barkowski | Tuesday, 11 June 2013 at 02:43 PM
Makes perfect sense and I agree with Camilo. In a sense we have that today, just not in the form people want. You can do your DAM in one of several programs (or just use your operating system). You can do your RAW develop in one of many programs. And you can do your pixel editing in one of many programs.
Example, I can use the file system of my computer with a folder structure as my DAM. I can then use ACR to develop my RAW files. And send the results from ACR to GIMP for pixel editing.
I can at any moment change any of the programs in that pipeline. If I abandon the filesystem as a DAM tool and buy Phase One Media Pro as my new DAM tool, I can still use ACR to develop my RAW files and send the results of that to GIMP for pixel editing.
Or I could stick withe file system and replace ACR with Capture One Pro and I could still send the results from Capture One Pro to GIMP for pixel editing
Or i could stick with the filesystem and ACR and kick out GIMP and start using PhotoShop.
What I can´t do, is to automatically have the work done in ACR carry over to Capture One Pro, or the work done in GIMP carry over to PhotoShop. And this is what most people want, but don´t get. :-)
The DAM software is the closest, I can probably mange to carry over keyword tagging etc. as that informations is for the most part standardized (exif, IPTC etc.). But that level of standardization is probably not going to happen any time soon for RAW development and pixel editing in layers.
Posted by: Ronny A. Nilsen | Tuesday, 11 June 2013 at 02:52 PM
There's also Darktable, I've spent a little time with it and it's well worth a look.
Open Source and free as in beer.
http://www.darktable.org/
Posted by: Gareth | Tuesday, 11 June 2013 at 02:55 PM
One great advantage of such a system would be to free photographers from big, expensive single-program solutions. I like Lightroom, for example, but I worry about it becoming too cumbersome or expensive (like going exclusively to the cloud.
I would love the kind of open framework that might allow me to integrate a collection of small, single-purpose programs into a similar system.
Posted by: Bob Keefer | Tuesday, 11 June 2013 at 03:48 PM
Camilo has a good point. If something fails, you could change a particular piece of software and that wouldn't change your entire workflow.
On the other hand, It feels good to me to have everything togheter.
Every week I walk 25k to and from work, but I refuse to walk 5k day!
Posted by: Gaspar Heurtley | Tuesday, 11 June 2013 at 04:34 PM
Could you have found a cuter face for your illustration?!
Posted by: Michael Steinbach | Tuesday, 11 June 2013 at 04:49 PM
Having used Micrografx Draw and their bitmap editor (forget the name) and Lightzone, what I'd like from software is that the company stay in business long enough for me to learn how to use it properly. I now use Aperture. I figure Apple isn't going anywhere, for a while anyway. There are things that Aperture does not do, I don't care, I just won't do those things.
Posted by: Robert Roaldi | Tuesday, 11 June 2013 at 05:09 PM
The idea of flexible and "open" tool frameworks for software goes back a long way.
UNIX has already been mentioned, as a system it did espouse a design aesthetic that said that one should build small but composable tools which could be used to build larger pieces of functionality via scripting. This is a nice idea, but with all due respect UNIX had it easy because the only "data" that it really operated on was plain text. So sure, if what you wanted to do was build more sophisticated tools that turned one text stream into another text stream, things were great.
This points out the first issue with open tool frameworks: common data representations. If you have them, you are in good shape. If you don't, the entire problem is hopeless.
Starting in the 70s and moving into the 80s the dream of composable tool frameworks got wrapped up in the so called "object oriented" systems. Xerox had Smalltalk and the Xerox Star. Apple tried to do OpenDoc. And there were a few other things like this too. Here the idea was that applications would just be containers for "objects" that defined and built complicated behaviors and had fixed ways to communicate with each other. You could then build a complicated application out of lots of these objects and you were happy.
Probably the best known of these systems was what Microsoft did in the 90s with COM, OLE (Object Linking and Embedding) and later on .NET. What people learned was that it was REALLY COMPLICATED to make "generic" components work together in a coherent way. Anyone who has ever tried to embed an Excel spreadsheet into a Word document can attest to this. Anyway, the ground is littered with the corpses of people who were not Microsoft who tried to build and sell components in these systems in the mass market. They worked OK for IT applications and custom work though.
For applications that most people use it tends to be more cost effective and much less complicated to build single integrated applications that support known workflows effectively. Of course, you lose some flexibility when you do this, but you gain a lot too (consistency, performance, lower integration costs, etc).
Even in the UNIX scripting arena, the small tools from the 70s have often been replaced with larger more monolithic scripting languages for much the same reason.
The lesson, again, is that software design is a never ending maze of tradeoffs, and one of the most obvious ones is flexibility vs. complexity. Generally speaking the more flexible a tool or a set of tools is the more complicated it is to put together and to use. So, would it be nice if you could have Lightroom, but with some magic framework that allowed anyone and everyone to add code into it at will? Maybe. But if you did have it I can guarantee you that the result would be harder to use than what we have now. It might be that some hero makes Open Lightroom do just what you want, but it would come at the cost of overall usability in other areas.
OK. History lesson and semi-rant over.
Posted by: psu | Tuesday, 11 June 2013 at 05:44 PM
Oh, I forgot. The Mozilla web browser (which turned into Firefox) also tried to base itself on a complicated object framework and scripting. But it sort of collapsed under its own weight. So they turned it into a more streamlined thing called Firefox.
Newer browsers like Safari, Chrome, and Opera all use simpler engines that are more streamlined and somewhat less flexible and technically flashy.
The Web is actually a nice case study in the near impossibility of agreeing on standard representations for things, as the constant fights over HTML, CSS, Javascript and whatnot illustrate.
Posted by: psu | Tuesday, 11 June 2013 at 05:50 PM
Most people don't like writing UNIX commands to do file processing. That is why Apple makes so much money selling UNIX disguised as Macs and Iphones and everybody else is selling Andoroid / Chrome built on UNIX.
Microsoft is trying to do something else for which time and space are inadequate to describe here, but there is a Posix compatibility hack that usually works OK for batch processing
Anyway,
Imagemagick can do a lot of what you are talking about in a UNIX like way , IE if you can write a script for it.
CinePaint nee FilmGimp is the 32 bit floating point version of Gimp and is the tool to use if you wanted to "photoshop" every frame of a Lord of the rings or a similar feature film
http://www.cinepaint.org/
Hugin, or more to the point , the bits and pieces that comprise Hugin can do a lot of useful image processing
I've been seeing a lot of image editing applications that run on MatLab , but MatLab makes Photoshop look cheap and simple.
I've been thinking a lot about this and am almost ready to get a used HP Proliant DL160 with 72GB of ram as a dedicated image editing and compositing box running Linux.
The only problem is that I need to run photoshop because
1)It's the only way my printer will work unless I run some goofy Canon software.
2) I run some software that generates photoshop files.Also I have 500,000 or more files in Lightroom
I could run Photoshop and Lightroom under virtual box or wine or most likely just keep them on the current computer which I will probably need to support a pile of external hard drives.
If anyone wants to experiment with this stuff, here are some free and easy ways to try it out.
http://artistx.org/
http://ubuntustudio.org/
Posted by: hugh crawford | Tuesday, 11 June 2013 at 05:52 PM
It occurs to me that someone reading this might be have some relevant experience
Anyone here know of software like photoshop that is optimized for editing large images? By large I'm thinking typically of 70,000 x 10,000 pixel images with 100 16 bit layers and 7 gigabyte file sizes
like say
http://www.gigapan.com/gigapans/118640
or
http://www.gigapan.com/gigapans/128806
or
http://www.gigapan.com/gigapans/117557
only bigger
Also does anyone here have any experience using something like this
http://www.ebay.com/itm/251282753651
or
http://www.ebay.com/itm/251284045612
for photo editing?
Yes I know that in general servers make bad desktop machines, but I'm thinking that being able to keep everything in ram would be the best way of speeding things up.
Think "single purpose device" as Mike would say
Posted by: hugh crawford | Tuesday, 11 June 2013 at 06:33 PM
"I've been experimenting with the nifty Photo Ninja (again) and mean to give PhotoLine a try, too."
I've been using PhotoNinja a lot since it came out. It works at least as well as the current version of ACR for most of my photos and, despite the somewhat awkward interface, I can usually get to the result I want faster than with ACR. It does a much better job of evaluating the most appropriate colour temperature and its detail control is very useful. But its general approach and philosophy is unsuitable for a significant minority of my work, so I need to maintain two converters, which is a bit of a pain. Haven't tried PhotoLine yet, but it sounds like it comes closest to providing what I need in a Photoshop replacement (16-bits, layers and blending modes for decent local contrast control).
Posted by: Kevin Crosado | Tuesday, 11 June 2013 at 07:56 PM
Camilo's certainly comments sounds like someone with a UNIX background.
However, in the grand scheme of things (that is, the real world) this approach impractical and not value-added for folks that need to get real work done, and don't have the time or inclination to have to learn to deal with a UNIX world-based sensibility to light and small apps, each of which only does one or two things. It reminds me of the arguments that PC guys used give as to why they didn't like Macs; it was closed and "monolithic", and they couldn't get down to the shell to make the changes they wanted at some microscopic level of granularity.
As someone who teaches and leads product development teams in "Voice of the Customer" for a living, the fact of the matter is most customers don't care HOW an app (or many small apps that only do one thing) does something. Customers, quite simply, need to do a job, to get real work done, and they want something that is clean and elegant that allows them to that job as effectively, painlessly, and easily as possible.
This is why Lightroom, Aperture, and to a somewhat lesser extent Capture One are the standards they are for working photographers.
Posted by: Stephen Scharf | Tuesday, 11 June 2013 at 09:40 PM
You should try Lightroom, Mike. Then all of these distractions go away. You won't want to think about things that don't play nicely with it. Go ahead, Mike. Take a drink.
Seriously, Stmpjmpr nailed the first thing that came to mind. There's something wonderful about knowing that you have a hard drive full of original raw files and sets of processing instructions that can be ignored or revisited at any time. I don't maintain jpegs. When I need a jpeg for any purpose, I export it, use it, delete it. For those photos where I do some additional processing in Photoshop, I export as a TIF and then end up maintaining that (in Lightroom). But it bothers a little me that if I wanted to reprocess the raw, I have to repeate the PS edits all over again.
Another thing. As photographers, some of us appreciate consistency of interface between models, between generations, even between "types" (like a menu that's the same on a p&s and a DSLR). And we pay attention to interfaces and how easy it is to take the shot we want quickly, repeatedly. Enter software workflow. I don't really want to learn 6 different programs. I don't want to figure out how/whether they interface with my DAM software (no pun intended). I don't want to worry about keeping track of whether Photo Goofball release 7 now does noise reduction better than Photo Samurai version 8.0.7 and evaluating it and switching over and deciding whether I should reprocess any of my files (and how do I do that without repeating all of the updates I made after ?)
Lightroom keeps track of all of my image files. I use LR to import them into a simple file structure based on date taken. I don't worry about using folders to organize them, because I'm assuming that I'll always have LR (or that some software will be able to read my catalog) to find my photos. I'm lousy at utilizing LRs categorizing capabilities. I use collections when I gather pictures for a purpose. But I tend not to use keywords. So I most often search by date, sometimes by metadata. (BTW, I love being able to evaluate collections of photos and see trends in metadata ... how often do I use which lens; how many of my best shots were with what lens; how often do I shoot wide open or at the ends of the zoom range; how often do I shoot my prime lenses at shutter speeds slow enough for IBIS to matter (and how important are those photos). That last one helped me decide I wouldn't miss IBIS too terribly much in switching from Sony to Nikon.
And then you have the editing ... all in place ... batch features, individual files, syncing, applying edits during import, all with a consistent interface. And when Adobe improves the image processing algorithms, next time you export a file, you get the benefit.
I like simplicity. I was using a p&s, a NEX, a DSLR. I picked up an RX100 and am not using the NEX. I dream of a day when I can do most of my photography with something like the RX1. Or an ILC with 2 primes. And I like keeping my workflow as simple as possible. I may not have the best camera for every possible shooting situation or the best software for every possible post-processing situation, but I don't have the skills to make the most out of every situation anyway. And for me, it's just a hobby.
Posted by: Dennis | Tuesday, 11 June 2013 at 09:45 PM
The classic winning strategy in the software business is to turn your products into a platform; and all your competitors products into commodities. Certainly Adobe has prospered at this. The people who write plugins are happy to live on the few crumbs that Adobe allows to fall from the table - I suppose given a $4B revenue stream, even crumbs can be pretty sizable :)
But expecting that you can build an ala carte workflow just goes against the dynamics of the industry.
Posted by: Andy Kowalczyk | Tuesday, 11 June 2013 at 10:09 PM
Mike Johnston wrote:
> It might be interesting to see a "program" that was essentially an
> empty framework for open-source editing apps that anyone could
> provide, from which each user could then pick and choose.
[geekspeak]
Such empty, general-purpose frameworks already exist — they are usually called "Operating Systems" — and popular examples include Linux, Apple OS X, Microsoft Windows etc. Within such frameworks, image editing apps — be they open- or closed-source — implement interoperability by working on data chunks whose semantics follow the TIFF, JPEG and, to a lesser extent, the relevant ICC, DNG, EXIF and XML standards ;-)
[/geekspeak]
Posted by: Bruno Masset | Wednesday, 12 June 2013 at 12:19 AM
For editing 7 gigabyte you need efficient software and a large computer memorywise. Gimp can handle my 2.4 Gigabyte 360 VR mosaics quite simple. So a server like the one you mentioned could verry well do the trick. In principle but that depends on the total hardware package. For instance a large graphics card with a lot of memory is also important in order to speed up screen processing.
In the past I spooled in servers with XP workstation software and vice versa. Nowadays that will be more difficult since you don't get the windows disks anymore. Under Linux a server client architecture in non existent. So a Linux server could verry well be a client and vice versa.
Some other problems also may arrise.....like in Gimp some plug-ins like G'Mic crash when using large files.
But the main question remains why do you want to edit such large files in the first place. I edit the tiles using Gimp and Rawtherapee in batch. and then use Autopano Pro to stitch those edited tiles together.
That works suprissingly well.
Greets, Ed.
Posted by: Ed | Wednesday, 12 June 2013 at 12:38 AM
I am currently reviewing software trying to figure out what to use for a digital workflow that includes managing and processing over 30 years of film and prints. I too don't believe there is one software - though I'd like there to be. I also agree it is frustrating that I can't make edits in one RAW program and take them with me to another - but if you can't get the camera companies to agree to a standard how can you get the software companies to.
@Robert - I too miss Micrografx - i started as a technical drawing professional and I still use Picture Publisher 7 for some tasks.
Posted by: Doribeans | Wednesday, 12 June 2013 at 01:37 AM
Mike,
I just want to thank SerrArris for recommending Hugin and Camilo for starting the ball rolling.
After reading The Ideal Editing Software and its Comments, I downloaded Hugin 2012.0.0 and started stitching right away. After only my second try, I made my first ever stitched panorama out of two pictures I have recently taken.
I did get my images stiched on my first try but it wasn't seamless. Not Hugin's fault though. I didn't batch-process (in Lr) the two images and each had different WB and Exposure settings. After a reset, I tried again and nailed it. I had the finished pano outputted as a jpeg (the default is TIFF) in case it may need more work in Lr. It didn't. Not only did Hugin get the WB and exposure right, it looks sharper, too(!)
I now know that camera angle matters less than exposure. Although the pictures were taken only seconds apart (in aperture priority mode), EV levels had changed between shots, as it should, at dawn with the sun rising fast through a wandering cloud bank. But Hugin was able to "blend" EV seamlessly when I specified just one image as the "anchor" for both position and exposure.
Hugin ("~ is more than just a panorama sticher") is by no means a "single-use" software. It's capable of perspective correction, lens (distortion) and transverse CA correction, HDR, focus stacking and other features of which I'm not conversant. I think most of these were originally developed as pano-tools or plug-ins that has evolved into robust "standalone" tools for non-pano applications. Thanks to its open source architecture. (Hugin's added capabilities look to me like "force multipliers" rather than a case of "mission-creep".)
I didn't expect that TOP would point me to the right tool to add to my modest skills. Thanks! And to TOP readers who may have been Hugin beta users and compilers, may I thank sourceforge.net through you!
Thank you, Mike.
Posted by: Sarge | Wednesday, 12 June 2013 at 03:40 AM
Dunno.
As much as I can somehow see the point, I know for sure I'd never, ever want to have to use a dozen different apps to do a dozen different things.
It's nightmarish enough (as you yourself pointed out) as it is to try and master one application's quirks and crannies, so, really...
And it's not the amount of tools that make an app hard to learn, IMHO. Sure, it doesn't help, but the different menu systems, shortcuts, etc., are the worst bit.
Rather than a gazillion apps, how about one software that would allow users to *add* to the toolbars and menus as they need, from a vast pool of tolls they could want, instead of having it default to daunting palettes and menus?
Posted by: Ludovic | Wednesday, 12 June 2013 at 05:27 PM
We live in an age when software is constantly being improved and users are sometimes overwhelmed with choices. So, whereas it makes no sense to switch from one program to another without a compelling reason, it makes very good sense to consider switching when a new or updated program is clearly superior to what you have been using. Otherwise, one has essentially resigned himself to a "good enough" standard of achievement. (I might add that "superior" in this context can have different meanings, such as quality of output, ease of use, workflow etc.)
This is the attitude that I take towards image editing software. Over the past 7 years, I have used several different raw convertors, each one noticeably better than its immediate predecessor. I have discovered plug-ins that allow me to achieve results that I could never achieve without them. It does require some exertion to learn and test various programs, most of which I delete from my computer after a serious trial finds them lacking. But when I discover a winner, the payoff is that my photos start looking better, while usually requiring less time and effort on my part.
Whereas many photographers place very high value on working exclusively in the raw format, I find this unsatisfactory, because some editing is best done at the pixel level in a program such as Photoshop. There may come at time when this is no longer true, but that time has not yet come. And even when it does, there will always be specialized programs that perform certain tasks better than all-purpose programs. I expect that I will still prefer the best tool for a given task.
Posted by: Rob | Thursday, 13 June 2013 at 12:18 PM
By way of a musical analogy, consider LADSPA audio plugins. These implement zillions of audio-processing algorithms from delay to flangers to multi-band EQ and so on, but because they're plugins the host software taking advantage of them can be anything from Audacity to Ardour to Pd to...
As far as I'm concerned highpass sharpening is just a signal-processing algorithm and I don't mind whether it's implemented in Photivo or Photoshop or darktable. So, is there any such similar plugin project for photographic algorithms?
Posted by: Tim | Friday, 14 June 2013 at 06:27 PM