PSD Filesize discrepencies with adjustment / empty layers.

Indeed. I forgot to mention that it was Dave who discovered that bug and demonstrated it clearly with repeatable steps.

And like Dave, I'm still not convinced there's anything wrong this time. Give us a clear procedure to replicate, without Capture One and without intermediate saves to a different format, and we'll look again.

This was the previous issue referred to by @D Fosse  

https://community.adobe.com/t5/photoshop-ecosystem-bugs/p-version-23-has-introduced-file-compression-on-large-files-which-slows-down-saves/idc-p/13149789#M63765

The key element in getting it fixed was that it was simple to demonstrate, and replicate, using Photoshop only.

Dave

@Denyerpro 

OK. But there are too many uncertainties here. For one, you need to take Capture One completely out of this equation. Nobody here knows what Capture One does or why.

Second, something you said earlier bothers me a bit: "if the file is saved with compatibility mode enabled, and then you turn that setting OFF, the file will "remember" that this was set". Yes, of course it will! It's an actual added composite layer in the file, and that doesn't go away. And it doesn't get added if missing. It happens at save time.

Any valid comparison here will have to be PSD saved under these circumstances, versus PSD saved under those circumstances. And then opened under identical circumstances. Opening via TIFF is just contamination of the experiment.

There was a bug in Photoshop's PSD handling a while ago, so it's not that they never make mistakes, I'll grant you that. What happened there was that even when you turned off PSD compression entirely in Preferences, RLE compression would still be applied. This is less effective than "full" PSD compression, so the files were just slightly smaller than they should be. If I recall correctly this was somewhere in the v22 cycle, fixed a couple of releases later.

I may be missing something but your testing as described here does not clearly demonstrate an issue. You talk about PSDs created in Capture One but suggest an issue in Photoshop.

Can you simply demonstrate a Photoshop issue with clear steps that others can try and replicate. So far, my own attempts to replicate an issue showed only expected behaviour.

I tried setting Preferences File Handling Compatibility to 'Never' and opening a file that had been saved previously, from Photoshop, with compatibility on and was 411MB on disk. I made no changes but used Save As and the new version was saved to disk at 238MB. I then turned compatibility back to Always and used Save As again - this time it saved at 411MB.  All expected behaviour.

Dave

It feels like you did not read beyond the first line of my reply, but that's fine, it's the internet and that happens all the time.

Something about the input PSD is triggering the compatibility behaviour, regardless of the setting in the preferences. The tests are quite clear now that this is the case.

Next question, and likely one for Adobe, is why - and if anything can be done to stop it, or if the setting in Preferences should be enforced / is being enforced correctly.

The very fact that two files containing the same data can end up with a delta in filesize of over 150Mb is certainly a point of interest.

And let's keep perspective here. Nobody's bloating file sizes with empty data just for the heck of it. If there's data that needs to be saved, and it needs to comply with file format specifications, compatibility, or other requirements - then that will reflect in file sizes on disk.

From time to time we get these complaints about file sizes. I suspect a lot of the problem is that people are used to jpegs, which really are abnormally small. A jpeg is crunched to within an inch of its life, so to speak.

My own attitude towards this is very simple: file size is what it is. Image files are big, it's just a fact of life. If my disks fill up, I get bigger ones. If you keep worrying about file sizes, you're in the wrong business.

The difference between background and layer 0 is not metadata but the need for a channel to store transparency.

I have no idea how C1 saves to PSD and what options it uses for compression and compatibility. I don't use C1.

All I see is the tests in my earlier post which are as I expected.

Dave

I can't imagine the metadata having *that* much impact on the size of the file, unless it was an enormous edit history (Not the case in this test). Your suggestion of it being channel alpha is a solid one, I think that's probably it and the size checks out. It'd be good for an Adobe engineer to weigh in on this, as it's quite confusing.

Re: RAW converters, I accounted for that by exporting from C1 as both PSD and TIFF. With the exported PSD, I see the filesize bloat. With the TIFF saved to PSD, I do not. Suspect something is causing the compatibility behaviour to be activated automatically with the C1 generated PSD, wheras the TIFF saved to PSD does not.

Note that I am NOT comparing the TIFF. That would be, as you suggest, completely pointless. I save the RAW from C1 to both a PSD and a TIFF. I immediately then "Save As" with the TIFF file to a PSD.

I then compared behaviour with the resulting PSDs, one straight from C1, the other derived from the TIFF file. I thought I'd explained the process but obviously failed to do so clearly, I'll edit the original post.

Hunch is that the C1 PSD is triggering the compatibility behaviour regardless of the state of the setting, and saving the TIFF to a new PSD creates a "New" file. I can't find anything in the metadata to suggest this, I'd have to reverse engineer the file headers in a hex editor to see if there's anything in play and that could take a very long time  - Adobe could clear this up in a minute.

(Snarky comment is thanks to over zealous mods here deleting posts of mine reporting (later verified and accepted) bugs some time ago. I should probably clear that out now, unless they get handsy with this thread too, of course 😉 )

Yes, I'd not noticed it before but it does make sense.

Dave