« New Leica? New Leica? | Main | TOP Effect? »

Tuesday, 11 June 2013


Feed You can follow this conversation by subscribing to the comment feed for this post.

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.

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....

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

... 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.

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.

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.


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.

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!

Could you have found a cuter face for your illustration?!

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.

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.

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.

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


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

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.


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
only bigger

Also does anyone here have any experience using something like this
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

"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).

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.

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.

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.

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.

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 ;-)

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.

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.


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.


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?

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.

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?

The comments to this entry are closed.



Blog powered by Typepad
Member since 06/2007