P: Allow JPEGs to be embedded, to save disk space

OK, I had time to do an A:B:C test and here's some solid numbers.

I saved out three versions of the same base file:

4000x4000px PSD file saved from CC2019
Added one 1334x750px (240kb) JPEG as a smart object 
4x copies of the smart object with varying scale and rotation transformations applied.

A) Saved as-is.
B) Saved with a solid color overlay fx of white applied to each layer (to see if that changed the rasterized save data to be smaller)
C) Saved over the jpeg inside the smart object with solid white (simulating a near total clearing out of image data from the main document's layers)

A: 125mb
B: 97mb
C: 5.51mb

So there is a clear and substantial difference in file size when the rasterized layer data is "removed".

I can't speak to how speedy the file would load if you have to re-raster all the layers but it might be worth the trade-off for people who have to do all their work from a contractor laptop with a single ssd.

Why aren't you saving back out as JPEG? I'm not seeing how there is a problem here.

C'mon y'all, let's be helpful here. If the OP had specified multi-layer smart object compositing from the start, it would have been helpful, and now it sounds more like a different ask... let's see if I can abstract this a bit more...

Basic request sounds like... remove rasterized layer data from smart-object layers on save.

This would have two prominent effects, IMO...
Pro: Smaller file size and faster saves, depending on how many duplicate instances of smart objects you have
Con: Longer delays on file-open because each smart object instance layer has to rebuild the rasterized layer

Which could have a lot of merit and might (I stress might) be relatively simple to implement.

Hey JIM A.  
"Let's say my client sends me a 4Mb JPEG file which needs retouching for a project. I open it in Photoshop, add a couple of simple adjustment layers, and save the image as a psd. The resulting file is now 65Mb."  

JIM,
I cannot see how a JPEG would be 4 megs.  I can see how it would grow to a larger file, but a JPEG file is NEVER that large.  It's usually around 4Kb not megs. 

So really - there's no reason to embed JPEG's because they don't take up a lot of file size.  I don't see a problem with JPEG file sizes.  NO JIM, I don't agree with you on this one.  No embedding needed.  ta ta gotta go.  I am a busy guy!  

PS: masks in Lr/CR do not offer all possibilities, I personally missing mostly HSL in Lr/CR masks. In C1 I have each layer full access to everything.

As long as Lr has no layers like Capture One, you must use Photoshop for this. Or Capture One 12.x of course, which is btw. much faster than Lr (Lr: speed a chemical rockets 21st century, C1: warp drive) and a light years ahead developing engine, specially if it come to de-noise and double specially on Fuji raw files. Have also a look at the "Refine Mask" feature of C1, it is freaking awesome good. But C1 has unfortunately it's own super ugly misconception, you can not export the tweaking you made to am xmp sidecar file like in Lr or Bridge+CameraRaw. Somehow it's a bout time to start a partner Youtube channel to "Camera Conspiracies" named "Image Editor Conspiracies" 😉

Problem:
Let's say my client sends me a 4Mb JPEG file which needs retouching for a project. I open it in Photoshop, add a couple of simple adjustment layers, and save the image as a psd. The resulting file is now 65Mb. This waste of disk space is totally unnecessary, since all I've added to the image is a couple of adjustment layers. And if I'm working on, say, a magazine containing hundreds of photos, the amount of wasted space really stacks up.

This is never a problem for me. If I only need simple adjustment layers, I can do much more parametric editing in Lightroom or ACR as already explained.
(Note: I am using Elements and nearly always use the 'Open in ACR' command for jpegs as well as for raws. Less than 5% of my edits need going to the pixel editor.)

I edit the jpegs in ACR (much faster to edit by batches), select all my edited batch and click 'Done'. All the edits are saved in the metadata header of the jpegs. The thumbnails in the organizer are updated, the catalog also. No creation of new "-edited" resulting files. No new jpeg compression from the orignal, which is still available. The editing 'recipe' is saved and available to apply to new files. Next time the file is opened (either from the editor or the organizer) it opens in ACR and it's easy to compare original and final versions.
Do I need a 'cooked' final version? I click 'Open' and from the editor, I can save in a version set at optimal compression for jpeg. Or, I export from the organizer (by batch) with my output-preferred file formats and parameters. I rarely need to store exported versions since I can reproduce them at will.

So, even if I decide to create a final "cooked" version in a version set, it won't weigh more than the original 4Mb.

This is my answer to the question about edits only by adjustment layers, but what about pictures which need the pixel editor? The initial edit from ACR needs further edits with layers and possibly many smart layers (think about scrapbooking or book pages). The real question now is 'do I need to keep everything, or only a final jpeg/psd/tiff version? I generally only need that for a given period. It's important to 'simplify' the smart layers to avoid gigantic psd/tiff files. Periodically, I review my big projects and I 'flatten' the layers and save as a jpeg. In the organizer I can 'flatten' the version set which keeps only the final version and deletes the intermediate versions.

Champion, It seems to me that you have really hit the nail on the head.  Because jpegs are encoded with a discrete cosine transformation they are not internally compatible with the way that data is stored in a psd file.  Unless the adjustments are saved the way that they are in Lightroom as .xmp files or the equivalent it looks to me like programming transformation nightmare to implement a way to accomplish what Jim A is requesting.  Like you say if it was easy it would have already been done.

Jim, don't you think that if files could be saved this way, it would have long ago been implemented? There's no such thing as saving layered files out as the original jpgs. Once you've ventured outside what the jpg spec is capable of handling, file sizes are going to explode. Nothing can be done about that until Adobe, or someone, develops a completely new way of compressing and saving multilayered images.

And you start off this thread by saying:
- since all I've added to the image is a couple of adjustment layers.
To which people reply that you could solve this by using Lightroom, which can handle saving adjustments via xmp.

And your reply:
- but let's say you bring several JPEGs into a Photoshop document, convert them to smart objects, duplicate, flip, rotate, and warp them? 

You're going way off the original script there. 

What's the actual complaint/request? You're only interested in saving HD space? If you're doing this professionally, then it's a requirement of the job to have an abundance of available disk space for whatever the work demands. I just completed a job which required 200GB of retouched psd! HD space these days is measured in 1000's of GBs, so i don't think saving a little bit here and there is worthy of a request. 
I'd be much more interested in them coming up with a format which allows for saving only the changes to a given file... so that when i have a 10GB psb, but all i've done is added an adjustment  layer, only that is needing to be saved, instead of the entire 10GB.

It will not be me who denies that sometimes Adobe makes strange strokes ... but I would say that some things that you comment are already implemented.

• 2. Change keyboard shortcuts? That can be done.
• 3. Install Photoshop on an SSD disk, the performance is greatly improved. The files in use also in the SSD and then to mechanical disks is RAID.
• 8. Photoshop allows you to change between four tones one of them a very light gray

In options you can also remove the home screen and recover the classic menu to create new documents.