image processing with applescript III

a little while ago we had a look at how to use applescript and sips to scale image files without the hassle of going through photoshop – see image processing with applescript II. open the terminal application, type in “man sips” and you’ll find there’s a whole bunch stuff you can do with images without ever opening photoshop — pretty cool :
screen grab of the sips manual in terminal

… but you can play around with all that another time. today we’re focussing on extending the functionality of the image resize script from that post to make it a little more user friendly. rather than a have script that’s hard-wired to scale images to 500px high, we’ll create one that can accept user input, so that the pixel dimensions can be changed each time the script is run.

to do that we need to first create a dialog. unfortunately the dialog possibilities with standard applescript are pretty crap — particularly when compared to all the options available to applescript dialogs in InDesign – border panels, columns, rows, checkbox controls, dropdowns, enabling groups, event listeners, comboboxes, editboxes, radiobuttons, etc.

here is all you get with standard dialogs :
screen grab of dialog entry in standard additions dictionary

well, although that’s pretty diabolical, it’s still enough for what we need. here’s the first part of the script :

display dialog "enter the pixel ratio you want these scaled to" with title "resize images" default answer "800" buttons {"cancel", "wide", "high"} default button 1
set mgResult to result
set mgText to text returned of mgResult
set mgButton to button returned of mgResult

that’ll give us a dialog something like this :
screen grab of resize images script dialog

… which gives us two pieces of information — the text entered and the button clicked – both captured into variables. if you want to make the script fool-proof, you’ll need to add some error handling to ensure that the text entered is an integer. but in its current form, the script assumes that the user is not an idiot.

the next part of the script creates a subfolder in the finder to save the transformed images into (this script creates duplicates of the original images rather than overwriting the originals with the resized versions) – then creates a reference to that folder for use later in the script :

set mgFolder to (mgText & "px") as string

tell application "Finder"
  set mgItems to selection
  set mgContainer to container of item 1 of mgItems
  set mgContainer to mgContainer as alias
  if (exists folder mgFolder of folder mgContainer) is false then
    make folder at mgContainer with properties {name:mgFolder}
  end if
end tell

set mgFinalFolder to mgContainer & mgFolder & ":" as string

then comes the key to the adaptability of this script — altering the final sips command based on the user’s choices in the dialog. we capture this into a variable called mgScriptString :

if mgButton is "high" then
  set mgScriptString to "sips --resampleHeight '" & mgText & "' "
else
  if mgButton is "wide" then
    set mgScriptString to "sips --resampleWidth '" & mgText & "' "
  end if
end if

the rest of the script is pretty much as per the previous post except that we insert the mgScriptString variable into the do shell script command :

repeat with mgItem in mgItems
  set mgName to name of mgItem
  set mgFinalpath to mgFinalFolder & mgName
  set mgPath to POSIX path of (mgItem as text)
  
  --convert mgFinalpath to POSIX form
  set text item delimiters to ":"
  set mgFinalpath to text items 2 thru -1 of mgFinalpath
  set text item delimiters to "/"
  set mgFinalpath to mgFinalpath as string
  set text item delimiters to ""
  
  set mgFinalpath to quoted form of mgFinalpath
  
  try
    do shell script mgScriptString & quoted form of POSIX path of mgPath & " --out " & mgFinalpath
    do shell script "sips -m '/System/Library/ColorSync/Profiles/sRGB Profile.icc' -i " & mgFinalpath
  end try
end repeat

wrap all that in an open handler (and delete the line “set mgItems to selection”) and you’ll have a script that looks like this :
screen grab of finished script

save that as an application and whack it in your sidebar. drag and drop as many images as you like onto the app — they’ll all be scaled quicker than you could do it through photoshop. don’t worry about accidentally dropping non-image files — these just get skipped.

you can also go here to get the complete image processing script.

have a good one

macgrunt icon

renaming finder items III

renaming finder items introduced a couple of ways to batch-rename files in the finder — using automator or applescript — by replacing characters or removing parts of the file name. renaming finder items II showed how to map a bunch of files to a completely different set of file names.

Applescript Icon this post will show another way to rename files — based on their creation date — using applescript. this workflow came about due to the diabolical way that digital cameras name their files. here’s a screen grab of a typical bunch of images :
screen grab of folder of images with diabolical file names

for this workflow, we’d like the order of the filenames to match the date the photo was taken — to make sorting, selecting, archiving, etc. just a little easier. the current naming is made more problematic because files are coming from more than one camera. well, we don’t have to put up with that crap — let’s just rename them.

set mgFolder to choose folder
tell application "Finder"
  set mgFiles to items of mgFolder
end tell
repeat with mgFile in mgFiles
  set mgPath to POSIX path of (mgFile as string)
  set mgCreation to creation date of mgFile
  set mgDate to short date string of mgCreation
  set mgTime to time string of mgCreation
  
  -- rest of script here
end repeat

first we get the user to select a folder of images to process, then we get references to the files in that folder, then we start a repeat loop to process each file in turn. we capture the following information :
mgCreation – for example “Thursday, 4 October 2012 17:13:18 ” – from which we extract :
mgDate – “04/10/12” (that’s dd/mm/yy) and
mgTime – “17:13:18 ” (that’s hh/mm/ss)

if you find that mgDate or mgTime give you the data in a different format, you will need to update the next part of the script accordingly or, if you prefer, change your language and text system preferences :
screen grab showing language and text system preferences window

we’re going to use mgDate and mgTime to create a file name like this “yymmdd_hhmmss” — so, we need to strip out the slashes and colons, reverse the order of the date, and introduce an underscore :

  set text item delimiters of AppleScript to ":"
  set mgTime to text items of mgTime --gives {"17", "13", "18 "}
  set text item delimiters of AppleScript to "/"
  set mgDate to reverse of text items of mgDate --gives {"12", "10", "04"}
  set text item delimiters of AppleScript to ""
  set mgDate to mgDate as string --gives "121004"
  set mgTime to mgTime as string --gives "171318 "
  set mgTime to text items 1 thru 6 of mgTime as string
  
  set mgNewName to mgDate & "_" & mgTime

this uses the handy “reverse of” command — taking a list of items and rearranging them in reverse order. also notice the second last line — we need that because mgTime has a trailing space we need to get rid of. this method works no matter how many trailing spaces there are because we’re saying “just give me the first six characters and ditch the rest”.

now, that’s the bulk of the script done — we also need to capture the extension of the file (mgExtension), create a filepath for the renamed file (mgFinalPath), and then do the renaming with a shell script. the shell script basically says — move this file, without any prompts, from this filepath to that filepath (you could also use this method to move the file to a completely different location — but we’re just renaming the file and leaving it in the same location) :
danger : do not run this next script — it is for demonstration purposes only – you’ve been warned!

set mgFolder to choose folder
tell application "Finder"
  set mgFiles to items of mgFolder
end tell

repeat with mgFile in mgFiles
  set mgPath to POSIX path of (mgFile as string)
  set mgCreation to creation date of mgFile
  set mgDate to short date string of mgCreation
  set mgTime to time string of mgCreation
  
  set text item delimiters of AppleScript to ":"
  set mgTime to text items of mgTime
  set text item delimiters of AppleScript to "/"
  set mgDate to reverse of text items of mgDate
  set text item delimiters of AppleScript to "."
  set mgExtension to text item -1 of (mgFile as string)
  set text item delimiters of AppleScript to ""
  set mgDate to mgDate as string
  set mgTime to mgTime as string
  set mgTime to text items 1 thru 6 of mgTime as string
  
  set mgNewName to mgDate & "_" & mgTime

  set mgFinalPath to mgFolder & mgNewName & "." & mgExtension as string

  do shell script "mv -f " & quoted form of POSIX path of mgPath & space & quoted form of POSIX path of mgFinalPath
end repeat

if we run this script on that original folder of images we’ll get this :
screen grab of file names after processing with first script

well, that looks pretty good at first glance — all the files have been renamed successfully … except … the very observant will notice that this folder has only 81 items, whereas the original folder had 103. wtf?

the problem is that it’s quite possible to have more than one file with a creation date of “04/10/12 17:13:18” — digital cameras can flick off quite a few images in a second. the script in its current form will simply write over a file with a duplicate filename. so we need to build in some method to check if a file with a particular name already exists and, if so, create a different name. here’s one way :

  set mgFinalPath to mgFolder & mgNewName & "_1" & "." & mgExtension as string
  tell application "Finder"
    set x to 2
    repeat
      set mgExists to exists file mgFinalPath
      if mgExists is true then
        set mgFinalPath to mgFolder & mgNewName & "_" & x & "." & mgExtension as string
        set x to x + 1
      else
        exit repeat
      end if
    end repeat
  end tell

this time we’re appending “_1” to each filename. then the script enters a repeat loop to check if a file with that name already exists. if so, it will change the end to “_2” and then check that, incrementing by one on each pass through the loop. once it reaches a name that has not already been used it exits the repeat loop. this way we don’t lose any files :
screen grab of filenames using final script

this is the final form of the script. it’s always a good idea to test new scripts on duplicate files before implementing them into your workflow — just to make sure they do what you expect (and don’t do what you don’t expect) — you’ve been warned again :

set mgFolder to choose folder
tell application "Finder"
  set mgFiles to items of mgFolder
end tell

repeat with mgFile in mgFiles
  set mgPath to POSIX path of (mgFile as string)
  set mgCreation to creation date of mgFile
  set mgDate to short date string of mgCreation
  set mgTime to time string of mgCreation
  
  set text item delimiters of AppleScript to ":"
  set mgTime to text items of mgTime
  set text item delimiters of AppleScript to "/"
  set mgDate to reverse of text items of mgDate
  set text item delimiters of AppleScript to "."
  set mgExtension to text item -1 of (mgFile as string)
  set text item delimiters of AppleScript to ""
  set mgDate to mgDate as string
  set mgTime to mgTime as string
  set mgTime to text items 1 thru 6 of mgTime as string
  set mgNewName to mgDate & "_" & mgTime
  
  set mgFinalPath to mgFolder & mgNewName & "_1" & "." & mgExtension as string
  tell application "Finder"
    set x to 2
    repeat
      set mgExists to exists file mgFinalPath
      if mgExists is true then
        set mgFinalPath to mgFolder & mgNewName & "_" & x & "." & mgExtension as string
        set x to x + 1
      else
        exit repeat
      end if
    end repeat
  end tell
  
  do shell script "mv -f " & quoted form of POSIX path of mgPath & space & quoted form of POSIX path of mgFinalPath
end repeat

now, of course, you can run this script for any kind of file, not just images. but in its current form it has no error handling for if it encounters a folder. we’ve fixed it so it won’t have a hassle with duplicate files, but if it hits a folder you’ll get something like this :
screen grab of error message if script encounters a folder

dammit you say. but the fix is actually very simple — just change the line “set mgFiles to items of mgFolder” to “set mgFiles to files of mgFolder” and the folders will be skipped — no drama.

but that’s not all …
just to be safe, or because your workflow calls for it — you could change the script so that it makes a copy of the file — giving the new name to the copy and leaving the original untouched.

and again, the solution is very simple — change the shell script from move (mv) to copy (cp) :

do shell script "cp -f " & quoted form of POSIX path of mgPath & space & quoted form of POSIX path of mgFinalPath

you can get a copy of the RenameByDate app here

keep grunting


• related post : renaming finder items : renaming using automator or applescript.
• related post : renaming finder items II : renaming by list.
• related post : renaming finder items IV : easy renaming.

macgrunt icon

adobe cs — colour #03

adobe cs — colour #01 and colour #02 started an explication of the excruciating world of colour management. excruciating, not because it is immeasurably difficult, but because so many seem to avoid it altogether — this is unnecessary.

colour management can be extraordinarily complex if you get into the nitty gritty — but most of us don’t need to delve that deep. so, do yourself a favour and get a basic working knowledge of colour management to give your files the best chance once they hit the press.

unfortunately, there’s no definitive solution to the problem. no one can say “here are the settings to set and the buttons to push” because, well, it depends. let’s see why — here’s a pretty standard choice for colour settings in InDesign (under edit > color settings…):
screen grab of  North America General Purpose colour settings

now that’s probably fine if you’re a general purpose kind of person working in north america. but if you’re a prepress kind of person in australia it’s pretty shitty. one of the key rules of colour management is give yourself the widest practicable colour gamut as your starting point. hover your mouse over where it says “sRGB…” and you’ll see this description pop up at the bottom of the window :
screen grab of description for sRGB color space

see how InDesign gives you clues about what settings to use — “not recommended for prepress work (because of its limited color gamut)“. if you change to the north america prepess settings you’ll see the rgb profile change to adobe rgb (1998) — a better choice for prepress work, because it has a wider gamut which also, conveniently, more closely resembles the cmyk gamut — as its description explains :
screen grab of north america prepress colour settings

but for aussie prepress dudes, we’re still not there. swop stands for “Specifications for Web Offset Publications” (for those who don’t realise, “web” is the term for printing from a paper roll). in australia, most commercial printing (apart from newspapers, magazines and catalogues) is done through sheet offset.

in adobe cs — colour #01 we saw that swop restricts the total ink coverage to 300% with a maximum black of 90%. but sheet offset can tolerate more ink and this is exactly why aussies are often disappointed by flat images when their shit hits the press — they are restricting their images to an unnecessarily narrow gamut by using swop — which they do either because it’s the default or because it’s what is recommended on all the (mostly north american) forums.

a decent sheet offset press/operator under good conditions can handle a tic (or tac if you prefer) of about 350% so let’s look at some colour spaces whose descriptions match that :
screen grab of US sheetfed offset descriptionscreen grab of fogra27 descriptionscreen grab of fogra39 description

judging by the descriptions, these should all give similar results but, unfortunately, although InDesign did a good job of pointing us at a good rgb profile, it’s not quite so helpful when it comes to cmyk. remember, the image from colour #01 and colour #02 had a black background of r0g0b0. here’s how those three cmyk profiles will render that colour :
screen grab of separations preview panel from each of the three profiles

u.s.sc and fogra27 do indeed give us a tic of 350% — but look at the difference in the separations. that 85% total black is diabolical. you’re just about guaranteed to get shitty detail in your shadow areas using u.s.sc because it’s relying so heavily on all four plates to create the dark colours — whereas fogra27 loads as much achromatic data as possible onto the black plate which will almost certainly result in a crisper result.

looking at the data for fogra39 we can see that the description was incorrect — it only allows for a tic of 330% (not 350%) but we can probably put this down to a typo — it’s very likely the fogra39 description was just copied from fogra27, which has been with us for longer.

so, is fogra27 better than fogra39? again, it depends. as mentioned above, 350% tic is easily achievable under ideal conditions but very much of our printing is done in a subideal reality. if you’re a prepress dude in australia sending high quality work to an excellent printer who has plenty of time (and budget) to do a high quality job, fogra27 is a good choice. if you’re sending stuff to a decent printer who’s been screwed down on the delivery deadline, then fogra39 will give you and them less grief.

having said all that … in an ideal world we would always get to speak directly with the printer’s production dude for explicit instructions on the best protocol to use for each job — but this isn’t always possible or practical — so we have to get better at best-guess scenarios.


• related post : InDesign tip : #24 : checking the black plate in separations preview.
• related post : adobe cs — colour #01 : you don’t need to convert images to cmyk.
• related post : adobe cs — colour #02 : you really need to get your shit together.

macgrunt icon

adobe cs — colour #02

adobe cs — colour #01 started looking at colour management in adobe creative suite — specifically, how images no longer need to be converted to cmyk in photoshop. this post continues the indoctrination — colour management can be left to InDesign.

HOWEVER, you really need to get (and keep) your shit together.

let’s continue by following two documents converted to two different common colour profiles — fogra 27 and web swop. again, we are using the exact same rgb psd file in those two documents :
screen grab of two documents showing different breakdowns for red and black
the separations preview panels show the breakdowns for the red text and the black background for both documents (as indicated by the white circles).

now, when you export to PDF you get a few different options for colour conversion — no colour conversion, convert to destination, and convert to destination (preserve numbers) :
screen grab of export PDF dialog showing colour conversion options

if you choose no colour conversion for either of those documents you’ll get exactly the same numbers in the PDFs as are shown in the separations preview panels above. what does this mean? it means that if you want to control your output you need to make a decision about which profile to use for your InDesign files. because images will produce significantly different results under different export conditions and unless you take control, you’ve got no idea what’s going to happen to your imported images once it’s time to export for print.

if you take either of those documents and export it to the opposite profile using convert to destination (preserve numbers). you’ll get exactly the numbers of the opposite profile. that is, if you take the fogra document and export it to swop using “preserve numbers” you’ll get the swop numbers in your pdf. however, if you use convert to destination without the preserve numbers option you’ll get a different set of numbers entirely — neither the swop nor the fogra ones.

what does THAT mean? it means, again, the choices you make (or fail to make) have an impact on your final output — both your indesign profiles and your export protocol will affect the finished product and if they don’t match, the effect is going to be unpredictable. or, more simply, if you don’t take control of your workflow you’re going to get unexpected results.

so, you have to get your shit together when it comes to colour management — don’t get pushed around by the software — you have to be the one doing the pushing.

ok, so that’s a demonstration of the problem. next up we’ll start looking at the solution.


• related post : InDesign tip : #24 : checking the black plate in separations preview.
• related post : adobe cs — colour #01 : you don’t need to convert images to cmyk.
• related post : adobe cs — colour #03 : what’s the best colour profile?.

macgrunt icon

adobe cs — colour #01

colour management has come a long way in the last few years. there are still a lot of the old guard who are yet to update their knowledge, and a lot of young guns who are yet to gain it. here’s the first of a couple of posts about colour management in adobe creative suite.

in the olden days (about ten years or so ago) the recommended practice for dealing with colour images was to save at least three copies of a photographic image : one rgb for onscreen, one cmyk corrected for sheet offset, and one cmyk corrected for press (newsprint). the most pedantic operators saved a different correction/conversion for every output scenario their image was destined for (eg. three different papers might have three different output profiles). so, many copies of each image — a wailing and gnashing of teeth — madness reigned.

this was also the time when raster images destined for print were always saved as tifs, unless they had spot colours or clipping paths, then they were saved as eps because it was the only importable file type that could retain such information. but now, of course, you save all your print ready rasters in psd format (you DO, don’t you? … no? then you should).

but back to colour management … de rigueur nowadays is to save raster images in rgb and allow InDesign to do any colour management on the fly. what? blasphemy and anathema to the old guard! page layout programs are for page layout and imaging programs are for images and that’s that. but such contentions are now piffle. there are good reasons why the adobe software is now called creative suite — it’s no longer a bunch of separate programs — it’s now an integrated set with many things in common, including colour conversion algorithms.

so, here’s a little demonstration for the non-believers (click to enlarge) :
screen grab of four versions of one image in InDesign

that’s a screen grab of the same rgb psd placed in four separate InDesign files. each InDesign file is assigned a separate colour profile as indicated by the labels. these are the same four colour profiles that could be assigned permanently through photoshop but, by being assigned to the InDesign files, they DO NOT change the image file (psd) in any way — just the way it is interpreted by InDesign.

assigning a colour profile in InDesign is as simple as choosing convert to profile from your edit menu and choosing the appropriate profile from the relevant dropdown :
screen grab showing convert to profile menu and window with dropdown options

the difference between the four InDesign files is more obvious when we turn on separations preview (windows > output > ) and have a look at some of the numbers. here are the same four files with only the black plates showing (again, click to enlarge) :
screen grab of four versions of one image in InDesign — black plates only

the readings in the separations preview panel come from the black background — which is r0g0b0 in the psd. you can see that fogra 27 allows for a total ink limit (also known as total ink coverage or total area coverage) of 350% and a solid black, whereas swop only allows 300% with 90% black, and poor old newsprint is restricted to 220% and has to pull the black back to 71%. NOTE: these are the exact same numbers you’d get if you did a cmyk conversion of the psd in photoshop.

what does all this mean?
it means that a single image can be sent to multiple output types by simply changing the InDesign profile. you do not need a separate image file for each destination.

now, converting the file to an output profile is not strictly necessary if your final output is pdf — because the conversion can be done at export. but, as the first screen grab shows, doing the conversion gives you a better idea on screen of what your final output is likely to look like.

we’ll have a nice little chat about this topic some more in a future post.

til then, keep grunting.


• related post : InDesign tip : #24 : checking the black plate in separations preview.
• related post : adobe cs — colour #02 : you really need to get your shit together.
• related post : adobe cs — colour #03 : what’s the best colour profile?.

macgrunt icon