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. 🙂
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’
Is there a way to bring a .jpg into PS as a layer, make it a smart object, then if double-clicking that SO, bring up the original .jpg to edit? I’m trying it with script listener and variables, but can only get to the created .pdB file, and not the original.
Jim,
You want to use listener code for File>Open as Smart Object to embed the original file as a Smart Object. Here’s I’m placing a jpeg called “my.jpeg” from my desktop:
var idOpn = charIDToTypeID( “Opn ” );
var desc1 = new ActionDescriptor();
var idnull = charIDToTypeID( “null” );
desc1.putPath( idnull, new File( “/Users/jtranber/Desktop/my.jpg” ) );
var idAs = charIDToTypeID( “As ” );
var desc2 = new ActionDescriptor();
var idEQlt = charIDToTypeID( “EQlt” );
desc2.putInteger( idEQlt, 12 );
var idMttC = charIDToTypeID( “MttC” );
var idMttC = charIDToTypeID( “MttC” );
var idNone = charIDToTypeID( “None” );
desc2.putEnumerated( idMttC, idMttC, idNone );
var idJPEG = charIDToTypeID( “JPEG” );
desc1.putObject( idAs, idJPEG, desc2 );
var idsmartObject = stringIDToTypeID( “smartObject” );
desc1.putBoolean( idsmartObject, true );
executeAction( idOpn, desc1, DialogModes.NO );
To edit the contents of the Smart Object, use the command Layer>Smart Objects>Edit Contents via listener code:
var idplacedLayerEditContents = stringIDToTypeID( “placedLayerEditContents” );
var desc3 = new ActionDescriptor();
executeAction( idplacedLayerEditContents, desc3, DialogModes.NO );
Hope that helps.
You can also get help at: http://www.ps-scripts.com/bb/
Accolades and question:
Very interesting, was about to conclude it was not possible. I appreciate your response.
Question: Do you mean that “use listener code for File>Open as Smart Object to embed…” means to replace that file menu code with the one suggested? If so, where is that script so as to edit it?
Hope I am thinking of this right.
@Jim – yes. that’s just listener code for Place as Smart Object, so just replace that with whatever code you were using before. I sent you an email with more details. Feel free to ping me if you have any other questions.
Jeffrey, can u send me a copy of that e-mail?.
atreyu_03@hotmail.com
Sound interesting, im trying to link a smart object in multiple files, at now i cant do it.
Greetings from Mexico
Hi Jeffery. You mentioned to ping you if I had a question. Thanks for the tip on listerner code. One last thing to do: When double clicking a smart object, read the layer’s metadata that has the location of the original .jpg I brought, and replace the existing image with the original. Do you know hwo to do this?
Jeff Tranberry and I have created a Photoshop panel for linking smart objects that uses the layer’s metadata to store the path to the original file. You can find a copy at http://ps-scripts.com/bb/viewtopic.php?f=27&t=3045
You can also get help with the ExtendScript or Action Manger code needed to write your own version by making a post in that forum.
Thanks, Mike. James, what mike said. PS-Scripts is a great place to get sample code and help with scripting answers.
I do hope that Adobe adds this feature; I can see the complexity for the common use cases in which SOs are manipulated in ways that would be lost when deconstructing them.
My most common use for SOs though is as a replacement for style sheets. For example, in a simple mobile app design, we may have dozens of nab buttons distributed throughout the various screens we are comping. By creating a SO of our current nav button with layer styles, we can later change the appearance of every button in the app quickly and easily by modifying the SO, without having to go touch every instance to apply a new style.
Clearly, real style sheets would be a better solution, and there may be some other better approach than we are taking that I’m unaware of. But in our workflow, the flexibility of being able to deconstruct one instance of an SO to create a new object of a different style class would be great. Today, we have to open the psb, drag the layer set to the parent document, position it properly, etc., which just adds time and potential for positioning errors.
I’m with the first response above – A dialog that said “Are you sure you want to restore this instance of a Smart Object to it’s original layers? All treatments made to the Smart Object will be lost.” would cover people for whom that would be an issue, while letting the rest of us have some much-needed flexibility.