Crop after Liquify Smart object

[carlc38435057]

I digitally add prints to white garments, and I regularly have to do extensive liquify operations that are applied to a smart object(linked object) containing a print file. This works great. BUT, when i crop afterwords it ruins all my hard work. I NEED the functionality to crop post liquify without ruining my images. Please please please help.  I regularly update hundreds of images to new prints, and convertting the already liquified layers into new smart objects is simply not an option. Any help would be most appreciaited. 

[c.pfaffenbichler]

I see no option to achieve this; and you already seem to know it is impossible at current. 

How intricate is the Liquifying? In some cases Puppet Warp migh provide an alternative. 

[carlc38435057]

Fairly intricate liquifying. I've seen several other threads with people suffering from the same issue. I'm hoping adobe will fix this in an update as its quite time consuming to work around. 

[carlc38435057 · Accepted solution]

Hi! I figured out a somewhat quick work around. Convert the Liquified smart object to yet another smart object. Crop (do not rotate), then right click on the new smart object and "Convert to Layers". Back to normal!

[Bojan Živković]

I can not see your composition but... if your image on Smart Object covers entire canvas then you can use Canvas Size to "crop". Another way can be using layer mask to mask unwanted parts but that all depends on situation you have.

[brunopitiko]

2023 and the problem still happening...

[marco_d]

Unfortunately your workaround isnt working for me. It really is a shame they can't fix this obvious bug

[c.pfaffenbichler]

This is not a bug just because you want it to behave differently. 

If you cannot get the Work-around to provide the intended result please provide the original file and the cropped file for testing. 

[marco_d]

Respectfully I disagree.

Every other smart filter respects crop changes, as far as I'm aware. Even smart filter masks. There's no reason liquify should be different. I can't see any situation where this would be the expected or desired behaviour.

[c.pfaffenbichler]

Your observation appears to be incorrect – the Mosaic Filter for example starts the tiling at Canvas-0/0, so changing the canvas/cropping changes the Filter’s result, doesn’t it? 

But naturally you can post a Feature Request on the issue … 

If you want to trouble-shoot the issue please provide the files (as previously requested). 

[marco_d]

Ah didn't realise that. Thanks for pointing out a second smart filter that doesn't respect crop changes and could do with an update.

Either way, it doesn't alter the fact that smart filter liquify breaks when the crop is changed.

Your observation appears to be incorrect – the Mosaic Filter for example starts the tiling at Canvas-0/0, so changing the canvas/cropping changes the Filter’s result, doesn’t it? 

But naturally you can post a Feature Request on the issue … 

If you want to trouble-shoot the issue please provide the files (as previously requested). 

By @c.pfaffenbichler

[c.pfaffenbichler]

Either way, it doesn't alter the fact that smart filter liquify breaks when the crop is changed.

It does not »break«, the user changed its frame of reference. Similar to if one were to move a Layer with a Liquify Smart Filter applied – at the next refreshing (updating the SO or editing the Smart Filter) one’s lack of planning would catch up with one. 

This may seem like overindulgent »semantics« and is ultimately irrelevant; if you want your displeasure with the current behaviour to register at Adobe please post a Feature Request (or a Bug Report, if you must). 

And I am admittedly not sure if/how this applies to the facial recognition features. 

[marco_d]

It does not »break«, the user changed its frame of reference. Similar to if one were to move a Layer with a Liquify Smart Filter applied – at the next refreshing (updating the SO or editing the Smart Filter) one’s lack of planning would catch up with one. 

And I would consider that a bug also.

Do you really consider the need to move layers and update smart objects as ‘lack of planning’? Why have those features at all then?

I’m not sure in what context you use Photoshop, but those are part and parcel of everyday retouching in my industry, as are extending or cropping for specific media formats.

Regarding facial recognition features, it seems that they DO respect crop changes. It’s not clear to me why there would be a difference if the standard liquify behaviour is correct.

It’s clear we’re not going to agree, but a smart liquify based on the bounds of the smart layer, rather than the whole image canvas, would be useful to me.

Thanks for the discussion and have a great day.

[brunopitiko]

It would be a better user experience that, they change the way this function either a bug or not. 

[c.pfaffenbichler]

It does not »break«, the user changed its frame of reference. Similar to if one were to move a Layer with a Liquify Smart Filter applied – at the next refreshing (updating the SO or editing the Smart Filter) one’s lack of planning would catch up with one. 

And I would consider that a bug also.

Do you really consider the need to move layers and update smart objects as ‘lack of planning’? Why have those features at all then?

I’m not sure in what context you use Photoshop, but those are part and parcel of everyday retouching in my industry, as are extending or cropping for specific media formats.

Regarding facial recognition features, it seems that they DO respect crop changes. It’s not clear to me why there would be a difference if the standard liquify behaviour is correct.

It’s clear we’re not going to agree, but a smart liquify based on the bounds of the smart layer, rather than the whole image canvas, would be useful to me.

Thanks for the discussion and have a great day.

By @marco_d

To me »Planning« in this case means taking into account whether one will need to move a liquified Smart Object, change the Canvas Size, … later on. 

And it seems perfectly legitimate to expect a professional Photoshop user to think that far ahead and, in the case of unforeseen/unforeseeable changes, to be able to implement the work-around already mentioned before. 

[marco_d]

I'm afraid that knowing what changes will be requested on any given image, in a real world agency environment, is somewhat unrealistic. 
As a professional Photoshop user I plan as best I can and currently that plan includes (surprise surprise) not using Smart Liquify at all, since it is unable to accommodate those changes.
But I'd very much like to be able to, it would be a great help.

As for the work-around, unfortunately it didn't work for me, as already mentioned in my first post.

[c.pfaffenbichler]

I'm afraid that knowing what changes will be requested on any given image, in a real world agency environment, is somewhat unrealistic. 
As a professional Photoshop user I plan as best I can and currently that plan includes (surprise surprise) not using Smart Liquify at all, since it is unable to accommodate those changes.
But I'd very much like to be able to, it would be a great help.

As for the work-around, unfortunately it didn't work for me, as already mentioned in my first post.

By @marco_d

And yet you refused help in trouble-shooting the issue. 

[marco_d]

How have I 'refused' to help?

[c.pfaffenbichler]

I have asked you to provide the original (un-cropped) and the resulting (cropped) file and you did not react to that request. 

Edit: You did not refuse »to help«, but refused »help«. 

Though naturally there is no guarantee that the »help« would have been successful. 

[marco_d]

I have asked you to provide the original (un-cropped) and the resulting (cropped) file and you did not react to that request. 

Edit: You did not refuse »to help«, but refused »help«. 

Though naturally there is no guarantee that the »help« would have been successful. 

By @c.pfaffenbichler

I'd hardly call that refusing help. My apologies for not reponding immediately to your request.

The workaround is a series of steps that are not producing the outcome described, it's that simple.

But if you insist, here's an original and re-cropped example.

[c.pfaffenbichler]

You converted the Smart Object to a Smart Object without maintaining the Canvas’ size (by including a copy of the background layer for example). 

[marco_d]

Just tried that, it doesn't appear to make any difference. 

[c.pfaffenbichler]

Sorry, I expressed myself unclearly: 

The new Smart Object needs to contain the copy of the background and the Smart Object with the Liquify applied – that way the new Smart Object has the original Canvas Size and maintains the reference for the Liquify. 

There are possible cases where even this fails, in which case it may be necessary to embedd the image into itself as a new Smart Object (and then merge and hide all the layers in the new Smart Object except the Smart Object with the Liquify applied). 

I sent you a private message with a link to a file. 

[marco_d]

Thanks, I'll take a look