And PS only has to store the smart objects new X and Y coordinates as
the object itself does not change. Am I missing something ? Anybody knows
what’s going on ?
No, it doesn’t. In PS’ way of thinking, the rasterization changes, so it’s storing full instances of the layer. This could be considered a flaw in the implementation or at least a design limitation, but it’s actually logical once you come to think of it, e.g. in relation to using blending modes, actions or history states. Without persistent pixel data, these operations would not yield the correct result or fail entirely.
Mylenium
Smart Objects can use a lot of space. Part of that is your history, part of that is extra copies of the rasterized artwork, and part is the size of the original child file.
That’s normal.
Thanks Mylenium. And thanks Chris (it’s nice to see a star-programmer still looking after his users π
Aside from the original child file (which is, I believe a fixed byte-amount and won’t grow by moving the smart object), both of you basically argue that – while moving – smart objects generate increasingly bigger temp files due to the translation to rasterized layers which is required for working with the smart object on-screen, but how come then, that if I take a *real* rasterized layer (which obviously has history states, too), moving the layer does not increase my temp file at all ?
Probably something to do with how the internal data structures are chained together. Chris or Steve G. Will know these things better, but I guess the transform is applied before propagating the pixel buffer for further operations, meaning that for vector smart objects PS has no actual transform info for the buffer, but the vectors’ vertices and lines. Based on that, the intra-layer rasterization for move operations being constant would be an incidental side effect, resulting in this odd behavior. you would however see the difference for rotations and scales, naturally. anyway, as a video-centric user I don’t really use smart objects (because After Effects doesn’t know what to do with them), so I’m not the most qualified person to answer this. Let’s wait for the devs spreading their insights…
Mylenium
thanks mylenium
but I guess the transform is applied […] no actual transform info for the buffer
note, that I did exclude transform/resize operations in my OP and limited my statement to the sole moving of smart objects. But I guess, you were aware of that. I have a very remote idea of how you explain the behaviour, but it’s still very unclear to me and I have a hard time imagining that it has to be that way mathematically. OK, anyway, absent further explanation, I guess I’ll have to accept that for some strange reason, it is that way and that I cannot do anything about it and that it probably won’t change in future releases.
You have to keep in mind that even for something as simple as moving a layer, it will create a state in your history. That state represents an entire instance of your file at that moment, and is what allows you to use a history brush to restore to that state. I haven’t experimented with smart objects effect on temp files, but depending on the edits you make, it’s conceivable that you could make each history state take up as much temp space as if you had saved a copy of the whole file at each point.
[…] but how come then, that if I take a *real* rasterized layer (which
obviously has history states, too), moving the layer does not increase my temp file at all ?
We have optimizations for moving a normal raster layer so that it won’t take up extra memory (we just store the offset).
Smart Objects don’t have as many of those optimizations yet.
Ah, I see. Thanks for the insight, Chris. With good hardware, this isn’t really an issue anyway, especially compared to the benefits of this powerful feature (I can’t even remember what life was before … π ).
Chris, what I was also thinking:
Since the user can right-click>>edit contents, and work on the layer or bunch of layers which had been converted to the smart object beforehand, technically it would be possible to have another right-click context-menu-entry which would allow the user to "back-convert" the smart object into whatever it was before, right in the document. Wouldn’t this be a useful idea? (I know there is a workaround via "export", but it would be easier to get the content back to exactly the same position). Just a thought.
boarder – sometimes it can be converted back without loss, but most of the time there would potentially be loss (color modes, depths, etc.). We’ve talked about adding such a feature. But the most common use case for it was also handled by "undo" :-).
Ok, I see. Undo/step-back-in-history of course only works for the current session, not if you save the file with a smart object and re-open it another day.
The potential loss you mentioned due to color modes and bit depth could be handled with a warning message, like Photoshop already does for some lossy mode changes.
Just my two cents worth … π
Converting Smart objects back to embedded layers would be a very useful addition. "Return to layers" would be a good term for it.
If you are looking for real world examples where this would be useful ChrisΒ
Β to simplify and bring down the file size of a file that has got out of hand with smart Objects. Some sort of global command "embed all Smart objects" in the layer/smart objects menu would also be useful for this purpose.
Β Objects of the same res and profile could then be non-destructively edited by swapping them in and out of smart objects for direct editing within the master document.
Β would be particularly useful when for example you need to detach a single instance of a duplicated SO from the others.
Β There is sometimes a need to return layers, and adjustments back into the master document to directly modify how they interact with their surroundings in terms of color and masking – for compositing. Its useful for simplicity to have them tucked away as SO’s still
Of course data loss due to resampling, bit depth and modes could be greeted with a warning, perhaps the warning could be contextual "this operation will result in data loss, will decrease file size by 75%, change its mode from LAB, and resample the embedded pixels to 120%".
What happens to the smart-filters? if they are there, a choice either to rasterise them or abandon them
