Copy link to clipboard
Copied
When saving for web using Applescript (or Javascript) I've found that when trying to control the progressive (interlaced) functionality, it will only work if it's already set in the 'Save for web' panel. If I tick the 'progressive' box when saving a JPEG, and hit Save, it doesn't matter what scripts I throw at it afterwards, it will always export the JPEG as progressive.
In pure Applescript, the progressive option below (shown as 'interlaced') doesn't impact the outcome:
tell application "adobe photsohop 2022"
set exportPath to "/Users/blah.blah/Desktop/test"
set exportJPEGOptions to {class:save for web export options, interlaced:false, optimized size:true, quality:100, transparency:false, web format:JPEG, png eight:false, with profile:true}
export current document in (exportPath & ".jpg" as string) as save for web with options exportJPEGOptions
delay 0.1
end tell
When running Javascript via Applescript the 'interlaced' option below also doesn't impact the outcome:
tell application "Adobe Photoshop 2022"
do javascript "var sfwOptions = new ExportOptionsSaveForWeb();
sfwOptions.format = SaveDocumentType.JPEG;
sfwOptions.includeProfile = true;
sfwOptions.interlaced = false;
sfwOptions.optimized = true;
sfwOptions.quality = 100;
var saveFile = new File( '/Users/blah.blah/Desktop/test.jpg' );
activeDocument.exportDocument( saveFile, ExportType.SAVEFORWEB, sfwOptions );"
end tell
Every other option seems to impact the outcome of the JPEG apart from the 'interlaced' setting, which makes no difference at all. For some reason, whatever 'progressive' choice is made in the 'Save for Web' panel, it sticks, and doesnt' budge until selected (or unselected) again.
I want to ensure all of the JPEGs are saved down as optimized baseline JPEGs, no matter what it's been saved as in the 'Save for Web' panel.
Copy link to clipboard
Copied
@SpaghettiSam – how are you testing/confirming the actual output?
I manually used S4W with optimised both on and off including all metadata. I then looked with ExifTool and couldn't find any difference in the metadata – so the value must get stripped as part of the export process... The only difference I could find was a small file-size difference, around 13kb for this test image.
The bad news is, that I can confirm your findings in v2021, even using ScriptingListener output the recorded values appear to be overridden by the last GUI selection option. I haven't tested in v2022 however I expect that the result would be the same. This is old code that is rarely (if ever) updated or fixed. You could raise a bug report or ask a moderator to convert this topic into a bug report.
The good news is that this is honoured with the standard Save As a Copy command via scripting. One can remove many metadata entries in order to bring the file size closer to what Save for Web produces.
Copy link to clipboard
Copied
Hi Stephen_A_Marsh, thanks for the response! I use a website called https://www.metadata2go.com/ which quickly allows me to see the details of the file output... By scrolling down to 'Encoding Process' it will return either 'Baseline DCT, Huffman coding' or 'Progressive DCT, Huffman coding'. The format of the JPEGs I run out must always be 'Baseline', hence why I'm stuck as to why the 'interlaced' functionality doesn't seem to affect the output. I've started looking into 'Presets', and working out a way to copy over a save down preset into a local folder, and triggering it, but seems like such an over the top workaround... Anyway, I'll make sure to pop back once I've found a workaround!
Copy link to clipboard
Copied
Just as with ExifTool, this website reports the same for both files (I'd guess this site uses ExifTool behind the scenes):
Encoding Process: Baseline DCT, Huffman coding
But they are different file sizes, but no mention of progressive or optimised in metadata.
However, Save As does correctly write standard or optimised in scripting and it is not stripped from the metadata.
Copy link to clipboard
Copied
You mention in your original response; optimized being turned on or off... The issue I'm having with my script is not with the optimized functionality, but the baseline/progressive functionality. It will only run out what has been set in the S4W panel, no matter what I set it to in my script. I currently have a workaround which uses GUI scripting (not the preferred method) which will open the S4W panel and always set the progressive tickbox to unticked, to ensure only baseline JPEGs are run.
Copy link to clipboard
Copied
Sorry, I became distracted with optimised on not showing any metadata difference to optimised off.
Sadly what you report appears to happen with any setting, whether none, progressive or optimised.
A file can have the Save for Web settings saved into it, when Save for Web is run the next time, these settings are remembered over the last used settings to populate the interface.
You are correct that the last used settings selected in the GUI are remembered for a new file that has not been through Save for Web before. You are also correct that these last used GUI settings override what is in the script, whether AppleScript, standard object model JS or ScriptingListener JS.
I also updated ExifTool and compared it to the metadata2go website:
ALL OPTIONS OFF:
ExifTool
EncodingProcess: Baseline DCT, Huffman coding
metadata2go
Encoding Process: Baseline DCT, Huffman coding
OPTIMISED:
ExifTool
EncodingProcess: Baseline DCT, Huffman coding
metadata2go
Encoding Process: Baseline DCT, Huffman coding
PROGRESSIVE:
ExifTool
EncodingProcess: Progressive DCT, Huffman coding
metadata2go
Encoding Process: Progressive DCT, Huffman coding
All settings off are shown as Baseline.
Optimised is also shown as Baseline, however, the file size is smaller.
Progressive is flagged as Progressive.
Personally, I'd just use Save As a Copy which does not have this bug as found in Save for Web.
Copy link to clipboard
Copied
Thanks for the feedback! I can confirm that the Save as a Copy option definitely does as it's told, saving as either progressive or baseline. However, the reason I've always chosen the S4W option over the Saving as a copy option is mainly because the filesize is much smaller, even though the quality is the same. Checking the metadata of the Save as a Copy file shows the compression as 'JPEG (Old style)' and although the encoding process is 'Baseline DCT, Huffman coding', there is still a Progressive Scans tab showing '3 Scans', which technically is still progressive, right?