Hardware Question - faster processing for batches

[Photoshake]

I have a simple action that does:

1. Fit Image

2. Save (via a simple script to turn PSD into TIFF)

3. Close 

I have used a timer and each image takes about 11 seconds to process the file before opening the next one.

My hardware is:

Ryzen 5 2600 (no OC)

32gb DDR4 Ram

AMD 5700 XT GPU

I know 11 seconds may not sound like a lot, but over 1000s of images it can be and this is for business purposes so I am happy to spend "smart money" if I will see an increase, but if the difference is neglible then I won't invest. Does anyone have experience with seeing a large performance increase in batch processing for say a faster CPU?

I have run a Puget Benchmark and get a score approximately 660 each time, but that doesn't suggest repitive tasks like batch processing.

Would love to hear input from anyone who has had similar experience.

[Lumigraphics]

Put everything on fast SSDs. Or use an alternative like ImageMagick.

[Photoshake]

Thank you, Photoshop and the script is on an SSD as is my scratch disk.

I just did a test moving the images from my spinning HD to an SSD and found the speed results were the same when I ran the batch.

Does ImageMagick allow me to set the parameters of the TIFF file and tell it to remove channels and paths? Is it much faster?

[c.pfaffenbichler]

Have you tried collecting the whole process in one Scripts and using AM-code instead of DOM-code (if any parts are DOM-code, that is). 

[Photoshake]

Afraid I do not know, this is the script so maybe you will be able to tell me:

var doc = app.activeDocument;
var str = doc.name.toString();
var idx = str.indexOf("_");
var sli = str.slice(0, idx + 1);

var tifOptions = new TiffSaveOptions()
with(tifOptions) {

  embedColorProfile = true;
  alphaChannels = false;
  imageCompression = TIFFEncoding.TIFFLZW;
  layers = true;
  layerCompression = LayerCompression.ZIP;
  byteOrder = ByteOrder.IBM;
  transparency = true;

};
doc.pathItems.removeAll();
doc.channels.removeAll();
doc.colorSamplers.removeAll();

doc.saveAs((File(doc.path + "/" + doc.name)), tifOptions, true);

[c.pfaffenbichler]

That’s DOM-code, AM-code usually runs somewhat faster. 

But I meant the WHOLE process, so including the fitting and the selection of the files/folders. 

[Photoshake]

Thank you, how would I create AM-code?

I purchased a book on scripting from Davide Barranca and apart from the forums it was the only useful resource I could find on writing Photoshop JS. 

[c.pfaffenbichler]

AM-code can be recorded with ScriptingListener.plugin 

I don’t think I have that Book but @DavideBarranca is an authority in the field so I trust it provides useful information and plenty of it. 

[Davide_Barranca]

Thanks for mentioning it—afaik Professional Photoshop Scripting is the only resource that extensively tackles the AM learning curve (it should be ~60 pages).

BTW I've recently (i.e. a couple of days ago) a new course, what's the proper way to advertise it in the new forums without breaking The Rules™, @c.pfaffenbichler?

Thanks!

[davescm]

@Davide_Barranca   Davide - IMO (as a moderator) your answer and links, within the context of this question, does not break the rules as it answers the need that had come up in the discussion and questions within the thread.

Dave

[c.pfaffenbichler]

Also the literature probably provides documentation that Adobe does not provide in a practically meaningful and easily usable form themselves. 

[Photoshake]

Hi Davide,

Nice to meet the author, I must say I haven't fully grasped the content yet as I am a scripting novice. I can see the DOM chaapter at page 62 and Action Manager chapter (which I assume is the AM section) at pg140. Do I have an outdated version? I am on EAP2. 

I know that it heavily mentions ESTK, but I know use Atom since ESTK was discontinued and I didn't like VB. Are you planning to make updates to amend for this change by chance?

Having a quick skim in that chapter I think I found the relevant section for saving files in the AM code. I can't see if it is possible to use the current path of the file though, can I use that as a variable in AM to save time?

Another cheeky request: but do you intend to do video guides for idiots like me? 🙂

[Davide_Barranca]

Hi,

you can grab the most up-to-date version from your Gumroad's account (in the file I have the DOM starts at 60 and ActionManager is 121-189).

I think you can use the current file's path, which you can get with `app.activeDocument.path` as a string.

As for additional content, I've invested the last year working on UXP (see here). Things might seem a bit complicated, but the TL;DR version is as follows:

1. UXP is going to be "the" way to build plugins ("plugin" now is a general term that replaces "panels", "extensions", etc)
2. UXP uses a modern JS engine (Google's V8) and not the ExtendScript engine
3. Alongside with UXP, a brand new Photoshop API is being built (i.e. a new, backward non-compatible DOM)
4. This new Scripting API (based on the modern V8 JS engine) is accessible only within UXP plugins at the moment—it will be available to standalone scripts too, in the future 
5. Outside of the context of UXP plugins, you can still rely on good old ExtendScript, for a number of years.
6.  In this new Photoshop API (which to me is a synonym for Scripting API) the DOM is still a work-in-progress, not yet complete (if you ask me, it won't be for a year or two at least). What do we do when the DOM isn't available in Photoshop? We use ActionManager.
7.  Alas, ActionManager in UXP is now called BatchPlay, and it has a new, JSON-based syntax. Although the structure is the same, and most of the times (i.e. ~90% of the cases) it is possible to transpile ActionManager to BatchPlay with some remarkable exceptions (e.g. when doing stuff like saving files)

Given 1-8, I've decided to allocate most of my time looking forward, to UXP and the new PS API. As a matter of fact, ExtendScript is not going anywhere for a number X of years (where X is known only by Adobe, and maybe still TBD), and the ActionManager chapter in the Pro PS Scripting book still is the only available source of information, quite useful to UXP/BatchPlay devs.

If you want to catch up with the current state of affairs with UXP, the new PS API etc. there's a free video series that I've published on youtube. I plan to write a Pro PS Scripting 2ED (which will be a complete re-write, given the nature of the content), but it won't appear until 2023 I'd say—mostly because the API are still evolving at a fast pace and shooting a moving target is frustrating.

As a side note, I assume you're on Windows, because on recent macOS versions ESTK is bricked, and we can only use VSCode 🙂

Cheers,

—Davide

[Photoshake]

DM'd you with Gumroad screenshot. I only have access to version 1. 

I will check out your YT videos for UXP though, cheers.

[JJMack]

You PSD file may require some tine to process. If the contains many layer when Fit Image resizes the to fit. All layers that contribute pixels to the composite.  Shape layer via transform Paths, Text layer via Photoshop text processing  Smart Object layer, layer's transform scaling need to be updated and rendered, Pixels layers need to be transformed and rendered. and the output Tiff needs to be saved you 11 second  processed 2 file the input PSD and the Output Tiff. Is the Tiff being saved as a layered tiff. Resizing a layered image files is quite complex.  If You are saving flat Tiff file  before you use Fit Image try Flatting the opened PSD document see if that speeds up processing. Also use Save As to save the Tiff you do not need to add a second script after the fit image script. When you process 1000 PSD you are also creating 1000 Tiff files you process 2000 files.

1. Flatten
2. Fit Image (Its an file Automate Script)
3. Save AS Tiff (No script needed)
3. Close No save

Fit Image is a Plug-in script is is required to be recorded in the action. When you record it. During the recording Fit Image will record the setting you use in its dialog into the Action step.  Whet the Action is played Fit Image will be passed those settings by the action manager and  Fit Image will bypass displaying its dialog and use the passed settings.

[Photoshake]

Hi JJ, 

Unfortunately flattening is not an option as it is a requirement for the client so their designers can take the elements from the layers.

There are no text layers or smart objects in the files for this client, but I do expect vectored files and smart objects to take longer due to Photoshop translating the vectors to pixels when it saves.

Cheers,

Dale

[JJMack]

Each none adjustment layer need to scaled via interpolation or via vector scaling and all vector layers need to be rendered so that document composite image can be save. All layer need to be rendered with adjusted layers, layer mask and layer style applied before the documents composite can be blended. You are process both the original opened PSD File and you are encoding a Layered Tiff File.  The Script Code in Fit Image is required for an Action can not calculate what percentage a constrained Image Size would be need for each file  image to fit within some canvas size requirement. An none constrained Image Size to the canvas size requirement would distort images with aspect ration  different than the canvas size requirement. All the Fit Image does is make that calculation to do the  constrained Image Size using the calculated percentage require for each image. The single calulation does not take a long time to make.

Are you using Data Compression in your PSD and TIFF.  It may run faster if  you do not decompression and compression require processing  time. How much SSD storage do you have....

[davescm]

Just a thouht:

Have you checked whether the bottleneck is the opening of the PSD files. If PSDs are stored using compression then they are smaller but take longer to open. That is why I, and many others, disable compression on PSDs. Disk space is cheap, time is not.

Dave

[JJMack]

No Compressing would work best if all is on SSD File closing requires that all output is committed. SSD also improve spooling performance.  The Problem is Layered files tends to be large how much SSD storage do they have....

Compression may work better on disk for there will be less data spooling to and from disk. Output write behind spooling need to be commited before closet can end.

[Photoshake]

Hi Dave,

I am having an issue seeing a difference. I opened the original TIFF file I received from the client then ran an action that does:

1. Duplicate layer twice

2. Save as PSD

3. Close

Then I moved the PSDs to a folder and called it "compressed".

Then checked the do not compress option for PSD's and PSB's and restarted Photoshop.

Ran the same action on the same TIFF files. Put them in a folder called uncompressed, but saw no difference in file size or processing speed.

Have I done something wrong? I would expect the files to at least be larger and I restarted PS multiple times to try and get the files to save larger.

[davescm]

That surprises me as I do see a difference here. It may depend on the file content and therefore the amount of compression.

Dave

[J453]

Try hitting tab to hide all the panels. The panels redrawing takes up some cycles.

[c.pfaffenbichler]

Good one! 

[JJMack]

Indeed I use that in script that process many files and script that loops to perform many Photoshop  steps  I do that and also suspend recording history state which are expensive and also wipe the users steps in the history palette.