Legal
The views expressed in this blog are my own and do not necessarily reflect the views of Adobe Systems Incorporated.
Search
February 7, 2009
Expanding Smart Objects
Thanks for all the great feedback regarding ways to manage complex documents. I should probably toss in the inevitable disclaimer that we're just gathering feedback, none of this is a promise/hint about future work, void where prohibited, blah blah.
A couple of people have mentioned the idea of expanding Smart Objects back into the layers that formed them initially. That is, you'd be able to select multiple layers, turn them into an SO, do various things to the SO, and then explode the layers back out into the main layer stack. It's a great idea, and of course (you knew this was coming) it's really hard to make work, which is why it's not supported today. In case you're interested, let me explain why.
Smart Objects let you apply a variety of transformations to the selected object. You can scale, skew, perspective-transform, warp, and filter them. The trick is, how would you turn the transformed content back into layers while preserving its appearance?
In some cases the job would be easy. Let's say you put four layers into an SO, then scale it up & want to expand the layers back out. That seems pretty straightforward: apply the same scale factor to each layer, then move it so that the positions match. The same might go for skewing & distorting, though I may be overlooking some cases. But what about warping and filtering? It gets tough, if not impossible, quickly. I've made a little illustration (read it left to right) that may help illuminate the challenges.
The upshot is that expanding Smart Objects back to layers could be made to work some times and not others. Addressing at least the simpler cases would be a worthwhile effort, though that task would have to jockey for position relative to other SO-related enhancements.
For instance, if PS offered an option not to save the composite data of an SO in a file, the SO wouldn't add file size above and beyond the layers it contains. That would in turn open the door to PS creating SOs automatically when transforming layers, which is essential to getting more people using this feature. The consequence would be more time spent opening files, however, as SO composites would have to be rendered on the fly. That in turn adds new requirements to other PSD-reading apps--e.g. that they be able to run filters on the fly in order to preserve appearance. The whole thing becomes a quasi-religious argument about format compatibility and trading one kind of performance for another. There are many cans of worms here.
If you've read this far, my fellow geek, you may be interested in previous entries about The Secret Life of Smart Filters and the closely related Simplicty vs. Power in Photoshop. Nobody ever said progress was gonna be easy. :-)
Comments
Don't forget that the content in the Smart Object can be a different color mode, bit depth, color profile, etc. from the parent document. Bringing the child document layers back into the parent document will most likely change the appearance in those cases.
[Yes, and it's also possible that the contents of the SO are vector layers from Illustrator, or raw data, or--eventually--just about anything. --J.]
Also, the result of a filter applied to the composite of many layers, is not the same thing as the composite of the filter applied to each layer. (filtering and compositing are not distributive)
[I was trying to find a way to say that. --J.]
Yeah, not a trivial problem. Not impossible, but not trivial.
[So, let me know when you're going to agree to an option to let SOs not store composite data. ;-) --J.]
Well, traditionally Photoshop has offered features that are similar to expanding smart objects in combination with a warning that the appearance may not be maintained perfectly, like expanding layer styles into individual layers or the good old question whether to flatten the image on a color space transform or not. I think this is a good way to go about such things.
[Yes--that's how I'd expect to handle it. --J.]
As for non-raster data inside an SO, you could just disable the expansion commnand for those. That said, being able to expand SOs is not a priority for me personally as of now.
Having SOs not store composite data is pretty much the same problem as whether or not to store the composite for the entire image, which is currently controlled by the "Maximize Compatibility" switch.
[It's more complex, actually. Without composite data for SOs, Photoshop would have to create it on the fly. That means it would need to use Camera Raw to reprocess raw data, the Illustrator library to re-rasterize vectors, and--most crucially--various filters to reprocess any filtered data.
All of this means that any app that reads PSD layer data would need to be able to call these various libraries to build the layers on the fly. That in turn puts more requirements on the library that the Photoshop team supplies to other apps (Flash, AE, etc.). It's all doable, but getting there takes time. --J.]
Third party PSD reader that cannot deal with layers properly (like Lightroom and to a degree InDesign) won't be able to read the Image without it, and holding a modifier key when opening the file in Photoshop to quickly open the file in flattened mode won't work. So you are basically already doing a very similar thing. Why not use the "Maximize Compatibility" switch for SO composites as well? That way the user can choose what is most appropriate for his/her workflow. Or you could just change that dialog to say "Save full-resolution composite" and "Save composite data for Smart Objects" with a warning "Not saving composite data will reduce file sice but may break compatibility with older versions of Photoshop and third party applications." that appears if you disable any of the check boxes.
If you enable external linking for SOs, you'll have to expand the PSD export UI anyway since you'd probably want to add an option to quickly embed all linked SOs when the user does a "Save as" in "as a copy" mode.
[Yep, this all makes sense. Now we just need to find bodies to code and test it all. :-) --J.]
The one problem with "Maximize Compatibility" right now is that there is only a choice the first time the user savs the file. If (s)he changes his or her mind, (s)he has to do a "Save as …" and delete to original, which is probably not the most elegant workflow possible.
Concerning the color space differences Chris mentioned, I'd love to have LAB adjustment layers in RGB anyway, which would basically do the conversion to and from LAB on the fly. Now that layers can have their own XMP metadata, why not let every layer have its own color space or profile as well? That would eliminate that problem. "One less thing to worry about", as Forrest Gump says.
Indeed. Though, coming from After Effects and 3D programs that treat image processing and transforms non-destructively, one would argue that actually this is the core failure in PS (and also in AE): You do not treat a layer as an geometric entity but rather as a container full of pixels. If e.g. all distortion filters worked based on imaginary geometric grids, this would be no problem at all - the result of an transformation would merely be the difference of vertex positions or a vertex map to the original and could be reset any time...
[It's hard to offer both direct pixel manipulation *and* non-destructive transformation. See the simplicity-vs-power post linked above. --J.]
i'm bit not sure what 'expanding' SO should actually do- basically i can imagine only one possibility/solution and that can be achievable already nowadays: you duplicate SO in parent document as many times as there are layers _inside_ SO, then make only one layer visible inside each SO - so that doesn't change the look in parent document (well- if SO has non-normal blending mode - put all SO duplicates in regular layer group and change blending to the group). then- just flatten each SO into regular non SO layer. at the end- you get combined SO transformations applied to each original layer you've made SO from. yes- that's destructive but you could even have that warped and filtered example possible and still have four separate layers at the end.
more interesting for me is SOs not storing composite data. pleaase- make it possible! i don't see any serious issues there: you add new 'links' panel (as standard in indesign or illustrator) and for file>place allow to select 'link' or 'embed' the file (same how illustrator does). for linked SOs - i could replace, re-link, etc. however for those SOs user creates by selecting layer and "create smart object" command - these would be 'embedded' by default (and with composite data stored just as it's now). you could then open SO, save that new file and using 'links' panel replace embedded SO to saved file if you want linked workflow. or- add shortcut that if users holds shift on "create smart object" - you allow to select filename to save to and make SO linked immediately ;)
yes- external SOs would slowdown file opening however >95% SOs at least in my workflow doesn't use filters - mostly transforms and being able link/updates files similar to illustrator "links" would be huge plus. i'd upgrade just for that reason :)
The layers have to all be in the same mode and profile - otherwise compositing won't work, or you'll spend weeks waiting for composites to finish.
The big issue with not storing composite data is that old versions of Photoshop and other apps that read PSD files will choke without the composite data. I guess I could put a big, ugly "you didn't save composite data, now you get what you paid for" message in each layer.....
Could composite data be calculated only when expanding Smart Objects back to layers?
One would have a pixel layer that matches the rendering, on top of the layers that constitued the SO (sort of a Command+Shift+Option+E)
I guess that similar questions arised when layers became a reality in PS3.
You could still just pop in a solid color with a warning text or something, keeping the legacy composite chunk around without actually rendering any of the data contained in the file, could you not?
"The upshot is that expanding Smart Objects back to layers could be made to work some times and not others. Addressing at least the simpler cases would be a worthwhile effort" - yes I agree with this. Expandable Smart Objects (offering a warning that resampling has been done and Smart filters have been dumped) would be a great addition. Its not necessary to rasterise the Smart filters, just dump them. They are easy to reapply destructively if that's what you want.
Its good that Chris Cox the man who put Smart Objects, a very complex concept together so well ( I use them in my work every day), is saying 'you ain't seen nothing yet'