Some time back Adobe announced an interesting new technology for image processing on GPUs called Hydra. That technology has since been renamed to Pixel Bender and components of it are now available for the CS4 products and Flash Player 10.

Pixel Bender is very similar to Apple’s Core Image technology available on MacOS Tiger and later. Both Pixel Bender and Core Image allow developers to create image processing algorithms in a programming language that is abstracted from the hardware the filter will run on. A developer can create their image processing code in a domain-specific language and allow the runtime implementation in Core Image or Pixel Bender to implement the algorithm optimized for the hardware present in the system when the program actually runs. By leveraging the power of the modern Graphics Processing Unit on today’s common laptops and desktops these technologies offload the image processing tasks to specialized hardware, when present, and provide amazing image editing performance for the user. Often real time edits are possible for still images or video.

The two technologies are remarkably similar. Core Image of course requires the MacOS, but otherwise any application on the platform can be developed to incorporate Core Image. Its also possible for users to install Core Image filters so that all Core Image enabled applications can access the filters. Pixel Bender is currently only available in a few core Adobe applications : Photoshop, After Effects, Flash Pro and Flash Player. Having access to Pixel Bender effects in Flash Player does imply though that any application developed on the Flash platform (presumably including AIR and FLEX applications) can take advantage of the technology. The potential advantage here of course is that Flash, and therefore Pixel Bender, are cross-platform including web applications.

At the heart of each is is the concept of a ‘kernel’ which defines the core algorithm. The kernel describes how to produce a pixel of the output image given some portion of the input image. Both Core Image and Pixel Bender use a C-like language to create kernels. Both are based on the OpenGL Shading Language with the kernel an effective parallel to a fragment shader in GLSL. Adobe’s implementation seems on the surface to be a more complete implementation with less restrictions than Core Image. This can really help when trying to implement a particular image processing effect, but there is one potentially big gotcha : Pixel Bender kernels can only use a very restricted set of kernel language features when running in the Flash Player. If your target is a desktop Adobe application this should not be a problem, but if you are looking at a web application this could present problems.

Another interesting component to Pixel Bender is the idea of a processing graph that allows a developer to chain several kernels together into a single operation. This is quite useful because many interesting effects are only effectively realized as combinations of other effects. The chaining is smart in that the runtime performs analysis to make sure only the minimal amount of pixel processing is performed for a given chain. For instance if there is a crop at the end of your chain, none of the upstream filters will bother to compute output pixels that are outside the crop. Pixel Bender adds Graph language to describe and distribute these multi-pass filters (though once again this is not available in the Flash Player). Core Image includes the same concept of chaining filters with efficient execution, but only recently added the ability to persist these chains for reuse in Leopard.

I’m excited to learn more about Pixel Bender going forward. We have used Core Image extensively here at RogueSheep and have found it to be a great solution. Pixel Bender has the potential to open up some of our image processing solutions to the Windows platform or even web-based applications.

If you want to try out Pixel Bender yourself check out the Adobe Lab’s download here. They have a rudimentary IDE that lets you implement and edit a kernel and see the results live. There is also a plug-in for Photoshop CS4 that adds a Pixel Bender gallery filter which can host PB filters in Photoshop.

Also interesting is support for the visual graphics processing package Conduit from the fine minds at Lacquer. Conduit is a visual graphics processing package, similar to Quartz Composer, that can be hosted in a variety of applications. Their beta support for Pixel Bender allows you to create PB filters using their visual processing language, all without having to dirty your hands in the relatively low-level shader language. You can see some cool samples of it in action in your web browser (with the latest Flash Player).

The recently released InDesign CS4 comes packed with a long bullet-list of new features. Here are a few that stand out from a Creative Suite developer’s perspective :

GREP pattern matching for styles

You can now set a style to apply to a range of text that matches a grep-style pattern. For instance you could use a pattern like :

'@/:[:space:]]+>@[a-zA-Z_.]+?.[a-zA-Z]{2,3}'

to automatically apply a specific style to anything that looked like an email address. I’m not sure what the intersection is between page layout designers and grep pattern wizards, but the nerd in me loves the idea.

See Tim Cole’s blog entry for more details.

Links architecture updated

The underlying architecture for linking to an externally placed image or text file in an InDesign document had really been neglected over the years since InDesign was first released. Almost all interesting workflow systems based on InDesign require implementing custom data link code to enable linking to images and text stored in a content or asset management system. Previously, these custom links were very hard to implement and introduced fragility and complexity to the final solution.

I’m happy to report that with CS4 they have rewritten this component and it appears they have focused on extensibility. It may be the case that many applications of custom links will now only have to provide a URL to the links manager. The new links manager makes no assumptions about a link being file system based making it easier to maintain the linked data in a database or other network resource. Its also now possible for custom links to add UI to the links panel.

The rewrite has also opened the door for some clever new applications for links as evidenced by the SDK example plugins, ExtendedLinks and ExtendedLinks UI. These samples show how to use the new links APIs to link a range of text to a database using an ODBC connection. The obvious application being of course to pull in variable data, such as prices for a catalog, from an external source with automatic updating in the document content when that source data is upated.

Once again, Tim Cole has more info at his blog.

Custom palettes with Flash/FLEX

Creating UI has been on of the consistently painful areas in developing for InDesign. Compared to the ease of development offered by modern UI frameworks such as the Cocoa APIs on the MacOS, InDesign’s widget architecture feels almost as stone age as the old MacOS toolbox or Win32 APIs. This is especially true if you have to develop custom widgets that don’t already exist in the SDK’s catalog of controls.

CS4 brings an interesting new development technique that shows promise of easing the burden. It is now possible to use Flash and FLEX to create UI in a custom palette or dialog box. Not only is this a path to cross-platform UI, it is also possible to use the same UI components across other CS4 applications including Photoshop and Illustrator! Adobe has an excellent example that they demo often (I hope they will open source this soon) that adds Kuler integration in both InDesign and Illustrator using a .swf for all the palette user interface.

Even more relevant is that you can now get your game on, right inside an InDesign palette. Here is an example of running the Amoebas Flash example, an Asteroids clone, in its own custom InDesign palette :

Live Preflight

One of the most high-profile user facing features in CS4 is the new Live Preflight. The premise of this feature is to provide active feedback in the document’s user interface that describes possible problems in the document that a designer would want to correct before sending the file off for print or to another stage in a workflow. The preflight engine runs in the background while the user works and checks for conditions that would indicate an error in the document. This feature can be a boon to catching common problems with transparency and overprint as soon as they happen during the creative process.

Of relevance to developers is that a plugin can provide custom rules to the engine. This will allow us to integrate custom business logic into the preflight feature for clients with complicated and strict output and design policies.

This article from the Adobe interface team on their Inspire web magazine has more info from my ex-colleague Tom McDonald about the design of the UI for this new feature.

IDML

Finally we come to what might be the most interesting new feature in InDesign CS4; IDML. IDML is the third and newest iteration of InDesign file formats that leverage XML. IDML looks to overcome many of the shortcomings of the previous XML document formats in InDesign history.

Way back in the days before the Creative Suite, I and several of my colleagues here at RogueSheep worked on InCopy 2.0, the copy-fitting and editorial companion to InDesign built on the same code base. For this release of InCopy we took the potentially bold step of implementing the file format using XML (called INCD), reasoning that developers building workflow solutions would appreciate an open format that could be modified outside of InDesign or InCopy. We set ourselves a goal to have high performance and marginal readability and mutability when designing the format. While I think the end result had many merits, it did suffer in that it was difficult to extend for both internal and external developers. Later, the InDesign team implemented a separate persistence of InDesign documents using XML. This format, INX, was geared towards backward compatibility. This became the mechanism for saving a document in a format compatible with an older version of the application. INX was much easier to extend than INCD, but suffered from readability and was difficult if not impossible to modify outside of the InDesign family of applications. It sometimes suffered from performance issues as well.

IDML is the first truly extensible file format in the InDesign family that may meet all of a developer’s requirements. Its extensible, readable and easily modified. Its entirely reasonable to create correct and usable InDesign documents and ‘chunks’ of layout in external applications or even by hand for the GUI adverse. The InDesign team apparently strived to equal or better the performance of INX with IDML, so it may be a winner in the performance category as well. One of my favorite parts is that the IDML file is a .zip archive that has several separate XML files for different components of the document.

As always, our Adobe buddy Tim Cole has more on his blog.