Plug-in or External Editor?

There has been quite a bit of discussion around the concept of plug-ins for Lightroom. When photographers think of plug-ins it typically brings to mind very unique or specific filters designed to adjust the appearance of an image. Photoshop has a rich history of supporting these image processing plug-ins. The extensibility of Lightroom is different in that we’ve been focused on workflow extensibility that allows developers and photographers to extend the application as a workflow platform that connects to third party services, allows for custom web galleries or custom metadata to adapt to a photographer’s workflow. Photographers would still like to see image processing plug-ins in Lightroom and I agree with them. But for a plug-in to actually behave like a plug-in it can’t break the non-destructive workflow. There has been a little flurry of discussion around the Aperture 2.1 image processing “plug-in” API and the subsequent utilities released behave less like a plug-in and almost exactly like the external editor functionality that has been available since Lightroom 1.0. If a plug-in requires that a derivative TIFF or PSD file be created and block access to prior non-destructive adjustments it’s not really plugged into the application is it? 

However, if external editors are what you need, we’ve got them.  In Lightroom 2 we’ve added the ability to define as many external editors as you want. And you don’t have to wait for software manufactures to create a custom “plug-in” for Lightroom, just utilize the existing standalone application like the one available for Noise Ninja. The optimal implementation of an external edit interface at this point is the use of a smart object workflow with Photoshop CS3. I’ve used it many times with PTLens and I really appreciate the fact that I can go back and adjust raw settings after I’ve applied the PTLens correction.(Then revisit the PTLens settings) This is an incredibly powerful link between the raw and rendered workflow and half measures with marketing spin labeled as “plug-ins” are not the highest priority for the Lightroom team.

31 Responses to Plug-in or External Editor?

  1. Mike Early says:

    how do I get more than two external editors — that is all my preferences screen seems to allow? must be doing something wrong on my end……[Mike, in the Lightroom 2 External Editor preference dialog, the bottom section is where you designate multiple external editors. Choose the application on your hard drive, set the file format options then pick the preset drop down to save as a new External Editor preset. Then it will always appear as one of your options when you choose “Edit In” from the right click context menu. -TH]

  2. Jose-Miguel says:

    I really don’t get it.You send to CS3 as Smart File, then you apply the Filter (say PTLens), but then you have to save as PSD, TIFF or JPG, but you can’t keep it as RAW (or DNG) file.Am I wrong? If not, I don’t see much of an advance, except the CS3 benefit of smart files. But this is CS3 and not LR.[Yes, you’re correct. Photoshop can’t work with raw data directly, we need to convert to a rendered file even though the smart object contains the raw data. The key benefit is that once you have a PSD file you can always return to the underlying raw settings by opening the smart object. -TH]

  3. To me Lightroom SDK is a Joke!!!Developers want the ability to write real plugins for Lightroom. Like more modules like the print and web.[Module creation is definitely an extensibility goal for the Lightroom team.]Why does Adobe need to add the ability to make books, when a developer could write and sell a plugin to do this. That way the developers can build what the people want and update quickly.[Good point, although high quality book creation(an expectation of Adobe customers) is something that should probably be included as native functionality]The points about the external editor preset being equal to plugins does not make sense. If the sdk does not include the ability to write plugins that can edit the image non-destructively then how can we ever write a plugin that does anything more than make a tiff or jpg that can’t be changed non-destructively after. If you don’t give us the ability then we can’t do it![Yes, you’re missing the point. I said that it’s not a plug-in if it can’t edit the image non-destructively. That’s why we call them external editors. (It’s Apple that’s trying to call them plug-ins even though they have the exact same behavior as Lightroom’s external editors.) ]Take someone like Nik. They should be able to write a plugin that has the controls right in the adjustments in the delvelop module. It may not be true non-destructive editing, but lightroom could apply the settings from the nik plugin after all the other adjustments are made. just do this for the on screen preview and when the image is exported or edited in photoshop. This way you would get the things you want without having to go in and out of different programs which is Killing peoples workflow![I completely agree! Non-destructive imaging pipelines however are complex entities and opening them up to third parties requires a great deal of work in order to make the non-destructive workflow seamless. Frankly, we do have to prioritize our efforts and there were some fundamental image adjustments that had to come first. (See local brush and gradient tools.)]Also the SDK lacks the real ability to obscure your code so it cannot be copied. So in turn the plugins cannot be sold for real money.[We’re definitely open to your suggestions as to how to protect plug-in code. But I know that many folks have made quite a bit of money just selling develop presets. (These are text files) Allen, I appreciate your passionate comments but please don’t refer to the efforts of our development team as a ‘joke.’ These are incredibly passionate and intelligent individuals, not faceless drones in a big corporate office. -TH]

  4. Gio says:

    rr obscuring your code, I thought you could compile Lua.Anyway, Tom, interesting article and important to make sure everyone understands what is is a plug-in and what isn’t. Maybe we need a new term for so-called plug-ins. Can I propose what John Beardsworth has been calling them – “strap ons”. Snappy eh?[No comment. 😉 I’m going to stick with plug-ins if you don’t mind. I just differentiate them by calling them workflow plug-ins vs. image processing plug-ins. -TH]

  5. Erik says:

    HiI try to get a reasonable hdr-workflow for photomatix as is implemented in “Merge to HDR in PS”. But if defined as external editor, Lightroom creates an additional series of images that I don’t need and I have to import the final image from photomatix also manually – not comfortable!Also: I guess there should be some workaround to use the ps-plugin of photomatix instead of the internal hdr-function of ps to get a comfortable solution?thanksErik

  6. Robert Barnett says:

    While external editors have their uses Adobe really does need to get an SDK out for Lightroom that will allow companies like Nik Software, the makers of Noise Ninja and Neat Image and whoever else chooses to to create add-ons for Lightroom that work inside of Lightroom on the raw data in a non-destructive way. Right now I feel this is the single most important thing Adobe needs to do.While I would never consider anything Adobe does as a Joke, this is the weakest part of Lightroom and because for some reason Adobe doesn’t realize that a great number of Lightroom users don’t like the include sharpening and noise reduction, etc. having third party options is pretty much the only way we are going to get what we want.If we have to convert our raw image to bitmap and take it to some other editor to get this then there is very little point in using Lightroom at all.I hope that Adobe will see this and by the time 3.0 comes out that this SDK is done so that third parties can start adding on to existing modules as well as creating new ones. One of the smartest things Adobe has done was allowing plug-ins for Photoshop. Now Adobe needs to do this for add-ons for Lightroom and they need to do it sooner rather than later.[Robert, you believe that high quality sharpening and noise reduction should require a separate purchase from a third party for Lightroom customers? Your examples are areas where Lightroom should shine and be the best solution on the market. As I’ve said before, image processing plug-ins are a goal of the team but I actually want to hear about your issues with our current sharpening or noise reduction technology. -TH]

  7. Sorry about the joke comment. I really do appreciate what you guys are doing. Its just I have had ideas for some plugins from the very first beta of lightroom and have yet seen a way to make them possible.To me Lightroom still needs a list of features added and some maybe could be fixed by 3rd parties with a stronger sdk.[Thanks Allen, we definitely have a long list of things we would like to add to the application, it’s just a matter of prioritization. (That includes SDK features). -TH]

  8. Alexey Danilchenko says:

    Whilst I understand your comments about breaking non-destructive editing in LR, I think s impler solution may be much more adequate for both consumers and LR developers. If you would introduce an ability to pluf in some kind of filtering actions (aka PS filters or equivalent) so it would be possible to add those actions as an image processing steps that happen after image demosaicing (i.e. after Develop) then I guess this would be pretty satisfactory. The similar in concept export actions (from LR 2 SDK) are not quite the same thing though – I can’t apply them to printing, web and slideshows, there is no UI for them (like for PS filters) and no way to store it with the image development settings.

  9. I wish Adobe takes its time and does the “processing plug-in” architecture the right way, instead of bullshitting the customers like Apple did.Please, no “simple adequate” solutions, as asked above.Lightroom 2 with local adjustments is so powerful, that I can already forget about pixel editing. So, if “processing plug-ins” a reveal to the world someday — let it be indeed something useful.

  10. I’m puzzled by the restriction of only two external editors. Why not allow more?[Larry, define as many external editors as you please using the presets. -TH]

  11. Alexey Danilchenko says:

    2Dorin Nicolaescu-Musteaţă:I don’t think “proper” (in your understanding) plugins will ever happen in LR. This is mostly for the following reason(s). Allowing to plug in something that will alter the raw pixels will affect demosaicing. The demosaicing is done by CameraRaw pipeline where certain parts of image development (as recorded by development settings that you alter in LR) are applied/done at certain times as image goes through the pipeline. If you will for example try to do the lens distortion correction before the demosaicing, then you will more likely brake the demosaicing because after modifying the image structure this way you will break the bayer pattern.So the only choices left here are:1) only allow pixel altering (filtering) plugins applied to the raw data before demosaicing (so they won’t affect the image structure) – a bit limited application for those2) allow to plug in somewhere inside the CameraRaw pipeline at various stages – can’t see that happening because Adobe then needs to explain/disclose various stages of CR pipeline and plugging into that can possibly compromise the quality of the pipeline.3) allowing to plug in after the pipeline but before the final image is formed – this is where anything is possible really, even pixel editing (donno who neds it though).I was proposing to do (3) which will be relatively easy and comparing to all other methods will allow to implement even PS plugin support (and this will open an access to vast array of PS plugins to do any imaginary thing there already). I would prefer to have option (2) as well but this would probably require more work on Adobe part and also will be incompatible with any other plugins out there.So instead of making bold demands, please try to understand what you asking for, what is involved and why you need it.

  12. OK, I see how to use presets to define any number of external editors… very nice.However, when using Tom’s example of Noise Ninja standalone app, I define a preset for Noise Ninja and it starts the app but does not start up with the file that Lightroom passed it… this is of no use![Larry, that’s not my experience. Are you using the latest version of Noise Ninja? It works for me on Mac/Win, without a problem. If you have multiple files selected it will currently only deliver the most-selected image. -TH]

  13. clvrmnky says:

    I agree with the sentiment that unless a third-party tool can be inserted into the non-destructive pipeline as a first-class object, it is not worth doing at all.Given that the order of processing is important, I’m wondering if given such an API the ability for a third-party to hint where in the pipeline it belongs might be in order.This, of course, makes the problem of a public processing API a lot more complicated.Such a third-party can’t be allowed to break the workflow, either! We don’t want a third-party to choke because it is incompatible with some (pretty much untestable) combination of pipeline processing steps.

  14. Ian Stickland says:

    Are Noise Ninja type plugins really that difficult? I would have thought the non-destructive edit pipeline makes it relatively easy.Lightroom simply(!) needs a uniform way to store plugin settings in its DB for the selected images, and then a way to call the plugin when it sees fit to apply the filter with those settings to the copy of the data being worked on in memory. That may be a 1:1 preview, or output being generated for print or export. The plugin never needs to see or know about the RAW file.A plugin can be made to perhaps either work on non-converted data or only converted or perhaps both depending on what it is doing.What I’d also like to see, and this may well be much harder, is the ability to use different RAW conversion engines, for example say a Canon or Nikon RAW codec.Now, this use of manufacturer codecs may not allow all the existing develop features, it may also not be as fast, but it would offer a choice, and provide early support for new models as the manufacturers seem to ship the codec with the camera.Adobe can then push their Camera RAW technology based purely on its merits, and if people can see the difference side by side, then that may be easier.Lightroom would then IMO be extremely powerful. Extensible through additional workflow, filter plugins and RAW conversion engines.

  15. joe mullins says:

    I’ve talked a bit with Brian Griffith at Iridient about getting the results of Raw Developer into Lightroom, especially his high detail demosiacing. RD with R-L deconvolution beats LR hands down. I have a quick example here. chance LR would allow for an alternate demosaicing engine as a plugin, or just change the existing engine to allow for less aggressive noise suppression in demosaicing?[Joe, given that the demosaic process is the foundation for all subsequent adjustments I wouldn’t be too hopeful about the ability to swap algorithms in the near future. Does Raw Developer allow you to save the demosaic file as a linear DNG? Then you could bring the file into Lightroom with your preferred demosaic algorithm. -TH]

  16. I’d be a whole lot happier with the existing “External Editor” schema if the result of any external processing could be automatically imported back into Lightroom. Currently the only way to do that is by sending images out to CS3 for HDR, but not if they are sent to Photomatix or any other processor. It may seem like a small thing, but it is still annoying to have to manually resync to get the resultant images bck into LR2.[Sean, Lightroom will automatically add an externally edited file to the Lightroom catalog, stacked with the original if you ask it but it’s limited to single file operations. Multi-file operations do require that you add it back to Lightroom manually unless you’re using them through Photoshop CS3. -TH]

  17. “But for a plug-in to actually behave like a plug-in it can’t break the non-destructive workflow. “AMEN.Great work, Lightroom team. Keep up the purity of the application. I know its hard to explain the difference, but I think the market will move in your favor as it gets better educated. Aperture’s plugin architecture seems like a waste of time — if I’m going to render a 160MB file just to use a “plugin”, i might as well just use Photoshop.You might want to consider letting any smart-filter enabled photoshop plugin register directly inside of LR. For instance, I can’t imagine it would be that technically challenging to let PTLens work non-destructively inside of LR without a trip to the smart-object and photoshop. For certain things (especially lens correction, and Viviza-like color editing), a trip to Photoshop seems unnecessary. Here you ought to be able to leverage the fact that a well-written PS plugin should be able to export its state information in such a way that i could be stored in the LR database.Maybe I’ll queue this topic up for my next Springamp post.

  18. Rob says:

    I would like the Noise Ninja pluging to work just like it does in Bibble 4.9, it comes in just like a built in tool. Bibble excels in the area of plugins.LR sharpening and Noise Reduction are very sub-par for me. Bibble and NX do it much better.Having said that, I still use LR2 and just deal with it.I own Noise Ninja but have not tried it with Lightroom in the manner explained above, but I don’t want to use it as an export, but built right in.I’m sure I don’t understand the complexities here, but wanted to point out Bibble is doing a true plugin with Noise Ninja. [Rob, part of the reason for my post was to validate requests just such as yours. -TH]

  19. Thanks for the followup comment Tom (about single file round tripping). I didn’t realize that and will now have to play with this more!

  20. Robert Barnett says:

    Unfortunately, time and time again the noise reduction on all of Adobe’s image editing applications keep coming up very lacking. They simply do not compare to the third party plug-ins.While color noise is easy to deal with, at least getting rid of the color of the noise. Getting rid of the gritty pixels just doesn’t happen with any thing Adobe has. At best it makes it uglier, but doesn’t come close to reducing it.I am not the only one that feels this way and I am really baffled by Adobe’s claims that its noise reduction is on pare with the third party options. It really makes me wonder if Adobe has done any testing at all.All of this is a moot point. While the develop and library modules saw a lot of updates in LR 2, the rest of the modules are just as weak as they were in 1.41.Either Adobe needs to get the features in place and then start improving them in leaps and bounds or they need to open LR up so that third parties can provide the features we need.Right now I don’t hold out hope for good noise reduction, book printing, being able to create album page layouts for printing with different images. Quality slideshows with multiple music, transitions, titles and capations, animations, etc. The web module is well, pretty basic and while it will do the job it doesn’t do it with style.At to that that stuff still missing like lens correction (far better than the poor implementation done in Photoshop) and LR 2.0 leaves me flat, cold and wondering just what professional photographers LR is really designed for.

  21. The optimal implementation of an external edit interface at this point is the use of a smart object workflow with Photoshop CS3. I’ve used it many times with PTLens and I really appreciate the fact that I can go back and adjust raw settings after I’ve applied the PTLens correction.(Then revisit the PTLens settings)Any chance you could detail this process for those of us that are pretty new to LR and these concepts? The PTLens example would be perfect.[Good idea for a web tutorial. I’ll see what we can do. -TH]

  22. Drazick says:

    Will you let plug ins access the RAW data before the Demosaicing process such as NR, better interpolation algorithms etc…[That’s not currently part of the Lightroom SDK. -TH]

  23. David Terry says:

    I vote for KISS.As much as possible, let Adobe innovate and bring the features directly into Lightroom without the need for plugins.I realize that will take time. I’m okay with that. The Lightroom I have today is light years ahead of what I’ve been using. It already, today, makes me more productive and produces better quality images than I had in the past.New functionality is great. But I don’t want to pay for it by: 1) having a slower pipeline, or 2) having to purchase 3rd party apps.KISS and KIILR. (keep it simple/stupid and keep it in lightroom)

  24. Even Solberg says:

    Is anyone writing a book or something on how to develop Lightroom plugins? Right now there are a lot of unknowns, and I can’t seem to find the answers in the SDK guide. Examples: How do I set default values on my custom metadata? How do I prevent empty custom metadata fields from showing up in the metadata browser as “No Value”? etc etc. More information is definitely needed.[Try posting your questions to the the Lightroom SDK forum: -TH]

  25. Robert Field says:

    I would love to be able to include sending a file automatically to an external editor as part of my import workflow. For example, if a photo being imported is at 3200 ISO, be able to tag it for “Edit in Neat Image” for noise reduction in the import dialog. It would be even better if it were possible in the future to create rules for this- if ISO is greater than 1600, sent to Neat Image prior to completing the import. Ideally, I suppose, this would be through the “Information to Apply”>”Develop Settings” interface. Any chance of this?[You can set any third party application as an external editor. I haven’t tried Neat Image personally but I recommend setting it as an external editor and then filtering by ISO for a quick batch process. -TH]

  26. Igor Levicki says:

    I know this has been discussed many times but I feel that people at Adobe have been missing a few points:1. External applications cannot work with RAW image data prior to demosaicing step.This is especially of interest for noise reduction plugins because best NR can be obtained before demosaicing the image.2. External applications are cumbersome to useThey equal three more steps for each image in the catalog, and often require creating extremely large documents for passing data back and forth wasting resources (disk space) and slowing down the process (disk is the slowest path for data exchange in a computer).3. Some editing steps are inherently “destructive”Once you process the image using some NR application or plugin just touch any develop settings before that step and you will have to redo the NR step. That means launching the external application again, passing the files back and forth, etc. It’s a loss of productive and creative time squared.In my opinion, Adobe should expose a hook for NR plugins in Lightroom as early in the editing process as possible, preferably before demosaicing or just after demosaicing but before exposure/WB/whatever settings get applied.

  27. Nigel Tufnel says:

    @Robert Field, I don’t think Adobe is missing those points. I would think (hope) that by now they’re painfully aware of them. I don’t know what the technical hurdles are exactly, but they need to find a way to solve them ASAP because it’s a huge downside for a lot of Lightroom users who otherwise love the app (me). First version, well OK, I understand you need to get the core stuff working first. But now another major revision has come and gone with no native plugin API, and we should be approaching version 3 soon. If they’re not in there I’m going to be very disappointed, and I assure you if Apple (same deal) solves this issue first, I’m going to take a serious look at switching to Aperture.I hope that Adobe isn’t so in love with their own algorithms that they see no need for third-party native plugins. Because Lightroom’s built-in noise reduction, for starters, gets *destroyed* by any number of external apps (most notably, Noise Ninja, Noiseware, and Dfine). If they think I’m going to wait around until they get their own tool up to par, they’re probably mistaken. Then there’s unique things that the built-in tools just don’t handle at all, like Silver Efex Pro’s B&W grain engine, for one example.

  28. Patrick Studer says:

    Great blog! Quick question for you .. is there a way to remove an external editor? I had Elements initially and then upgraded to CS4. So now I still have both CS4 and Elements listed as external editors. I would like to get rid of the Elements part, but cannot seem to do it since you have to choose another editor (as opposed to just removing the secondary editor). Any ideas?Thanks!

  29. Carl Griffin says:

    I have a problem defining presets for external editors. I use a number of Nik applications. I can set up all the presets and save them while using a specific LR2 catalog, however, if I get out of that catalog and create a new catalog to handle a new set of photos, all but one of my external editor presets are gone. What am I doing wrong?

  30. Heinrich says:

    I am reading all this but I really dont understand how this external editor should possibly work. I have lightroom 2.7 and the latest ptlens version. But I simply do not get it how I can get this working together.
    May be somebody can help?

  31. Aron says:

    Hi there,
    I am a photography loving sound engineer.

    in audio production with tools like avids “protools”, real time plug ins have been working since many years. today you can add up to ten plug ins per track all having impact to each other. sessions growing to 64 tracks and more are very common, even in the native version of the program where only the computers own processors are calculating. there is also a program version powered by additional dedicated dsp’s doing nothing else than processing audio plug ins, track counts there go up to 256. not to mention what else is going on under the hood like automation of every single parameter, real time time stretching and pitch shifting and much much more.
    please dont get me wrong. i am not a programmer and dont want to underestimate what is going on under lightrooms hood, i love lightroom for what i can do with it and appreciate the work of adobe’s engineers a lot.
    making a long story short i want to suggest that it might be worth for adobe engineers to have some sort of knowlege exchange (chat, coffe, lunch…) with avid (or others) about their plug in architecture and 3rd party implementation. why not learn from each other, since they are not in competing markets.