P: A real plugin architecture to make TIFF files unnecessary

Well, I hope Adobe can do something about this, preferably sooner than later, whether its cut-n-dried or not...

+1 vote - better develop-mode caching.

Over-n-out,
Rob

Smart Objects are not the same Rob. Once you create a pixel layer on top of one, it makes no difference what you do to the smart object, the effect is hidden.
I know what you're getting at, but every change after using a plugin will have to reference both the prior Lightroom settings and whatever interaction was done via plugin. I simply don't believe it's as cut and dried as you make out.

I do agree that more use could be made of the Camera Raw Cache though.
E.g. store the most recent develop preview. Do a check that it's still current, use the recent preview, if not use the original info to create a current one.

Note: If you use Photoshop/plugins, with smart objects from Lightroom, there is no compensation that ripples across plugin boundaries, when altering the position of bits by tweaking lens correction in camera raw (as example), or if warpage is done by plugin... - so you have all the same issues there now that I'm suggesting would be acceptable in Lightroom too. And, there is no reason there couldn't be the capability to define multiple freeze points - so instead of a camera raw cache that caches the rgb image at first birth only, it could be cached later on in the pipeline, at multiple points, so if you aren't trying to back up too far, then its fast, and if you try to go back to ground zero, then it may take a while to re-render through a bunch of plugins... I mean if the ACR cache maintained cached versions such that rendering can be done incrementally when there is a cache hit, then it could be the key in a multi-stage pipeline that includes imaging plugins, such that re-rendering from scratch would not normally need to be done.

Well, I suppose it suffices at this point just to say: "I hope they dont wait too long before engineering a smaller smoother seam between existing editing capabilities in Lightroom and the big separate tif.

R

You'll see them when it's right Rob, as Lee Jay has said. And your own reasoning is exactly why. It's part of the Mark Hamburg ethic of giving more than you asked for.
You talk about the RGBout/in line, but there are 2 aspects to the process pipeline: Settings applied to on a preview, and then those settings on the Raw to create the export. With export it's a matter of apply the sum of the settings and off we go. Working with Develop previews it's a tad trickier.. So we have Plugin X that does something. We do a bit in Lightroom, then use plugin X, then back to normal settings, then we need to tweak X again.. etc, etc. Each time we go between the normal pipeline and the plugin, we have to make sure Lightroom understands the plugins effect on the file and interact with it correctly, passing back and forth between LR and the plugin. Now throw in 5 or six plugins that interact, as well as Lightroom's own processing, and you've potential for the computer grinding to a halt trying to keep up.. like with mixing a lot of spotting with Lens Correction.

I certainly would love plugins internal to the pipeline, but I want it to be right.

Rory said: "I imagine the plugin point(s) in the pipeline would have to be constrained, and also the type of edits allowed."

I'm not sure why the edits couldn't be anywhere downstream of raw conversion, and any edit types allowed.

You make some good points Lee Jay. But I'd say: screw the warping. Do all your warping before you feed the data to your other plugins. Or if you re-warp, then redo your downstream plugins if necessary... I mean, Adobe went all out allowing us to add dust spot removal to our photos, then follow up with lens corrections that maintains the positions of the dust spots. While very ambitious and impressive, it was also a lot of work, and a source of problems, and you have people recommending workflows to avoid the extra performance penalty. Dont get me wrong - this was a really cool thing they did, and is one reason so many other things did not get done in Lr3.

On the other hand, cropping definitely needs to be handled. But that's easy enough to do by simply supplying the crop position and dimension to the plugin so the control point coordinates can be adjusted. By this, control points stay in position despite recropping.

Summary: Your point is well taken: plugins with position-sensitive settings will be wonky if previous pipeline stages warp the image. Cropping compensation however is childs play.

And, one could extend this argument to other things. Plugins that are designed to transform the hue of purple would be wonky if preceding stages already transformed the hue of purple... And tone...

But, I mean that's just how things are: If you crank up the fill-light, then you may need to increase the black-point too...

So if you do things that adversely affect a downstream plugin, you may have to go tweak the downstream plugin - thats life in the photo biz...

Bottom line: If Adobe is determined to "do it right", where "do it right" means tight integration and interaction control, we may not see imaging plugins for a long, long time.

Personally, I'd prefer they throw us a bone in the mean time... woof-woof.

R

Okay, now my head is hurting too. I imagine the plugin point(s) in the pipeline would have to be constrained, and also the type of edits allowed. Your earlier point about the LR team's thoroughness is very well taken.

What if the plug-in has something like control points, and those control points are based on the X-Y location of where they are selected. So you select one. Now, LR warps the image and/or crops the image so that that X-Y location is in a totally different X-Y location on exit from the pipeline? Wouldn't the control-point plugin need to know that? Of course it would. Okay, so you need to put it in the pipeline before any warping or cropping. Now isn't it in the pipeline itself? Okay, maybe there could be some sort of two-way and the plug-in could pass its X-Y location to the pipeline and LR could pass back something about that point pre-warp. But that would only work for a single point. What about a path? What about a complex path? Wouldn't that really, really need to be in the pipeline before warping? And what if the plug-in wants to do more complex stuff like maybe white-balance gradients or doing its own warping or something else? Wouldn't that need to be possibly in another place in the pipeline? Frankly, it makes my head hurt, and I wouldn't be surprised if the Camera Raw engineers are in some similar pain, but I'm not sure of a way around this that gets us more power than we have now with external editors without giving some sort of access inside the raw imaging pipeline.

I mean, what is a raw pipeline anyway?

Lightroom first has to convert raw data to rgb, and I don't imagine any plugins ever getting involved in this. Maybe I misunderstand. Assuming I'm correct, when one says "raw pipeline" they really mean "rgb pipeline", where the distinction is in the type of data flowing at this point. And presently, Lightrooms algorithm is an optimized thing that consolidates the various settings to minimize re-rendering. This is the reason Lightroom is faster than NX2 at rendering photos from scratch that have a multitude of adjustments applied (NX2 re-renders for every stage instead of consolidating settings across stages).

So, are people really expecting plugins whose settings can be consolidated with pre-existing Lightroom settings, or other plugins, or post-existing settings? - I dont think so, or at least I would not attempt this. If this is what Adobe has in mind, then I bow to the masters, and will watch with awe from the sidelines...

But, I personally cant imagine anything other than rgb-in/rgb-out for plugins, at least not in this decade. I assume thats how Photoshop plugins work, although I have no experience with them under the hood. i.e. Camera raw transforms raw to rgb, and Photoshop(proper) & plugins take it from there...

?