Sun, 25 Sep 2011

Photoshop scripting with Javascript

— SjG @ 6:41 pm

I’ve played with the Javascript interface to Photoshop for a couple of years. Conceptually, it’s great — a simple, powerful, interpreted language like Javascript, with an API to interface to one of the best image-processing packages available. In practice, it’s not as good as it is in concept, but it’s still pretty good. The API doesn’t include all of Photoshop’s functionality directly, and there are a lot of things you need to execute as fairly obscure event actions. These event actions aren’t documented, but can be determined by activating a plug-in which logs everything that you do using the Photoshop GUI — you can then read through these logs, and copy the actions you need.

Still, there are some real advantages to using this Javascript interface, as opposed to something designed for the purpose like, say, Processing. You can use the Photoshop UI for controlling inputs to your script (set foreground colors, select portions of the image, select specific layers, etc.), and output your manipulations directly into Photoshop layers.

I’ll be posting here shortly a library I’ve created for easily building dialog panels for setting script options. I find that most manipulations I want to do have a set of variables, and I’d rather not tweak the code each time I want to change them.

This library was originally written under Photoshop 10 (aka CS3). Under version 11 (aka CS4), it was less stable. Sometimes it would crash out at odd places complaining that I was referencing properties of undefined objects. Because there have been memory leaks and other issues with the Javascript interpreter, these seemingly random failures were annoying but not too surprising. When it came to version 12 (aka CS5), I was rarely able to run my scripts at all. What made it frustrating was the apparent randomness of the crashes. I could print a variable to the console, and the very next line would crash out with an “undefined object” error when referencing that variable.
To make a long story short, I was able to track down the issue. It turns out that in iterations, declaring variables matters. That is to say:
for (i in someCollection)

will cause random crashes, but
for (var i in someCollection)

runs beautifully. Now, I “knew” that the var keyword is optional and used for specifying scope, but I never had any idea that there could be an issue within the scope of a simple loop. Obviously, Javascript didn’t know that I intended i to be a variable on each iteration — perhaps it thinks I meant for i to be a 1957 Chevy Belair on some iterations.

In any case, having cracked the code as it were, I have proceeded to enhance and add to my library. After a little more testing, I’ll be posting it here or on GitHub.

Sat, 24 Sep 2011

Ffun ffmpeg ffunctionality

— SjG @ 2:59 pm

I’ve been processing a collection of product videos which came to me in a huge variety of sizes, aspect ratios, and qualities. I need to re-encode them to work in HTML 5, but, more importantly, I need to make them fit into a common player space on the web page.

It turns out that newer versions of ffmpeg support not only cropping, but also padding, and you can even do both operations at once!

For example, I had a source video that was originally 16:9, but had been letterboxed to 4:3, and then had two different sets of labels added. I needed to crop out the letterboxed portion and the top set of labels, and make the result fit nicely into 16:9. So I used VLC, a screen capture utility, and Photoshop to get the measurements. Then I used ffmpeg to crop the relevant section and pad it out to fit into my space (in this case, I’m left aligning the video in the padded output):

ffmpeg -i original/converted.wmv -vf crop=394:295:6:0,pad=524:295:0:0:0xFFFF00 -sameq

That’s cropping a 394 x 295 piece out of the original video (with the origin at 6 pixels from the left, and 0 pixels from the top), and then padding it out to 524 x 295 filling the padded area with bright yellow. The 524 x 295 is really close to 16:9 — and in a later process, it gets resized to the more standard 480 x 2721.

You can string together the padding and cropping in either order, depending on the effect you’re trying to achieve.

1I’m sure some educated person out there could tell me why video standards are so confused/confusing, down to the non-square pixels. While a true 16:9 would dictate 480 x 270 pixels, everybody seems to use 480 x 272. Why? The only thing I can figure out is that 272 is evenly divisible by a power of 2, which probably made display hardware cheaper to manufacture. As you can see, my resizing adds a bit of distortion, but at these resolutions, it doesn’t really matter.

Thu, 4 Aug 2011

Mac OS Automator for the Win!

— SjG @ 3:59 pm

I’m accustomed to having a hot-key in my text editor for inserting a time-stamp. Now I have a plain-text note-taking application that I want to use for managing my time, but it has no bells or whistles. It doesn’t allow the creation of macros and it doesn’t have a time-stamp function.

All is not lost! Using Automator, I created a service which calls a shell script to generate a nicely formatted time-stamp. I haven’t found a way to assign the service to a hot-key, but in many text input areas, a contextual services menu can be brought up with a simple right-click of the mouse.

Simple, nice, and convenient.

Here’s how to do it:
Fire up the Automator application. Create a new “Service” workflow:
(click to enlarge)

For the operation, double-click on “Run Shell Script” and set it up as shown in the image below:
(click to enlarge)

You’re done! Now you can insert 2011-08-04 16:58:06 time-stamps 2011-08-04 16:58:13 everywhere 2011-08-04 16:58:20.

Note: this is under Snow Leopard / Mac OS X 10.6.8. It probably will work under anything from Leopard onward.

Thu, 17 Sep 2009

MacBook Pro Screen Issues, cont.

— SjG @ 10:17 am

Well, the screen issues continue, but at least the missing pixel columns are in designer colors:

Resetting the graphics subsystem sometimes cures it, sometimes just changes the color. Thus far, it’s always cured itself eventually.

Wed, 9 Sep 2009

MacBookPro Screen Issue

— SjG @ 1:20 pm

So, in the middle of working on something, the balance of luminiferous ether in the universe must have come unhinged, because every other column of pixels on my screen went black:

View at full resolution to see detail

View at full resolution to see detail

I tried the usual tricks, to no avail. I figured it was a hardware connector issue, so got an appointment at the Apple store. However, to my annoyance and chagrin, the problem has proved intermittent. It “cures itself” and then recurs. This supported my theory that it was a connector issue, or so I thought.

The Apple Genius, however, taught me a trick to reset the graphics subsystem: shift + control + eject

The last time the problem arose, this trick *did* cure it.

So the question is – is my graphics card going south? Is this some bug in recently installed software (Snow Leopard, the new version of iStat Menus, or Final Cut Express)? Could it be entirely due to my attitude? Or was the reset cure also a coincidence? Only time will tell.