Speeding Up Image Composition w/ XMPie

142 views
Skip to first unread message

Jason Frankiewicz-Palchak

unread,
Nov 30, 2017, 4:35:22 PM11/30/17
to XMPie Interest Group
The Problem

I have a job that's run weekly from InDesign using the uPrint function in XMPie.

This job has 1000-5000 records and utilized .dpkgs to perform image composition. The ordering of composing a record is:

 1. Pull FIRST NAME from data and check if file exists in X:\Art_Directory\Image_1
 2. If it does, use that file and move onto the next record
 - If not create image using Photoshop action, save to X:\Art_Directory\Image_1

Now the Issue is this job has been running for 6 years now and I've been at my company for about 9 months and there's ~65k total images for  7+ of these image actions.

I'm looking for a way to optimize the searching of the images in the main Art_Directory. Would some form of indexing be needed?

So far I'm at 2.5 hours for a 1587 record job and it's still going. This job also only has 2 of the images that require name composition the other are just static images.

Things I've Tried


 - Lumping each Image "Type" into it's own folder
 - Simplifying the actions used to create images that don't have a name already.


Important Notes

- The language for XMPie is called qLingo which is their wonky version of "Javascript" with it's own quirks.
- I'm not a programmer and I have limited knowledge of optimization techniques.
- Simply rebuilding how the file deals with .dpkgs and composing isn't an option due to the complexity and time requirements.
- The images are being composed locally on my PC but the .dpkgs and images are on our server

ROBERT HOPFNER

unread,
Nov 30, 2017, 5:18:32 PM11/30/17
to Jason Frankiewicz-Palchak, xmpie...@googlegroups.com

Hi Jason,


I ran a similar job and I ran a modified uPlan to JUST create the images. Average month was 30-35K images so it took awhile (6-24hrs), but the output on the server was quick because all the images existed. 


My proof set was about 1500 records and I just ran that locally. Even generating images for that took less that 2.5hrs. The production run was about 325K records and took about 3-4hrs to run on the server (16 cores), maybe less.


Are the images local to the uProduce server? On a file server and not just on your machine, that would slow it down. They don't have to be ON the uProduce server, although that does help a bit. I don't load them into uProduce, just have a images resource URL.


I've never used an XMPie dpkg for uImage directly, they tend to be huge. I always resize everything appropriately for the art. That will save you a ton of time. Even if you have to resize them afterward will help with the production times even if image creation is dragging.


I always make sure the actions flatten the output file. I usually ran .psd vs. jpg. 


Sorting the images won't help, the more folders it has to look through the longer it takes. 


I am no programmer either but am pretty good with Qlingo. 


You might pick up some speed if your data source is in SQL...


That's all I can think of, not sure what kind of hardware you are on of course and version of XMPie. 


I can look at files with you if you think it might help.


cheers,

Bob


--
You received this message because you are subscribed to the Google Groups "XMPie Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xmpie-users...@googlegroups.com.
To post to this group, send email to xmpie...@googlegroups.com.
Visit this group at https://groups.google.com/group/xmpie-users.
For more options, visit https://groups.google.com/d/optout.

couch

unread,
Dec 3, 2017, 12:42:11 AM12/3/17
to XMPie Interest Group
You mention that your order of processing includes checking for an existing image. - uImage has its own optimization and will not generate an image if one already exists for a particular recipient. Perhaps removing the duplicate checking of the file system will improve some time.

The #1 issue with uImage performance is not having the photoshop image optimized:
* resize the image so that there is no scaling required in the print production
* down sample the image resolution so there is no more resolution than required for print production
* flatten the image so the photoshop does not have lots of unnecessary layers
* check any photoshop actions for performance - in many cases some time consuming filters can be replaced with faster options to achieve the same result.
* if the variable part of the image is 50% or less of the entire image, consider using optimization techniques to only create the personalized section as an overlay.

You mention that your production is across a network. Consider doing the production locally - the searching for existing images, and opening and saving of new images will be faster and save time.

There are video tutorials for uImage optimization in http://campus.xmpie.com
Reply all
Reply to author
Forward
0 new messages