The download page warns of nuclear holocaust, rivers of blood, etc. resulting from the use of the script.  I think the team is just being extremely conservative and cautious, but I believe there is a chance that the script will remove serial number info for Acrobat 8 (meaning you’ll need to re-enter your serial/reactivate).

One specific point: A number of people have asked whether it’s strictly necessary to deactivate the beta prior to uninstalling it and installing the shipping version.  Deactivation is accomplished via the Help menu, so it’s obviously a problem if you’ve already uninstalled the app.  The good news is that although deactivating is a good idea, it doesn’t seem to be necessary prior to installing the shipping version.

All this stuff can be pretty tweaky and system-specific, so please let us know if you run into problems.  Chances are I don’t know the answers myself, but I can route info back to the right people as necessary.

On a similar but independent note, David Biedny points out Wikivid, "an encyclopedia of informative videos."  Check out the wealth of topics on Photoshop.

Er, maybe not–but selecting irregular things like hair certainly is important, and it’s a problem that’s bedeviled both users and computer scientists for many years.  CS3 makes some real progress in this regard (hint: check out that mysterious Radius slider in the new Refine Edge dialog), and last week Jon Fortt of Business 2.0 sat down with Adobe engineer Gregg Wilensky to look at the results.  You can see his notes–along with well-fluffed puppies–here.  [For more on how the technology came to be, see "Male-pattern baldness -> Great Photoshop feature."]

Macworld magazine has posted a video overview of this year’s 11 winners.  Kelly Turner talks about Photoshop at the 4-minute mark ("I love it!"), and Jackie Dove tackles Premiere Pro around 9:30.

Adobe’s Dave Helmly has been demoing some of the new video features at the show and reports "huge crowds & very positive response."  He’ll be back in action today
at 12:15pm and tomorrow at 10:15am.

Adobe does not use spyware, period.
 
Since the inception of the Creative Suite (CS) family, Adobe provided a file collaboration tool with the introduction of Version Cue.  Version Cue is a file management tool that is integrated in Adobe Photoshop, Adobe InDesign, Adobe Acrobat, Adobe Illustrator and other creative applications within the Creative Suite.  It is client/server based.  The clients are integrated into each of the applications and they all communicate with the Version Cue Server.

To make setup and configuration easier, Adobe uses Apple’s Bonjour technology to enable the connectivity to Version Cue servers on a local area network. Bonjour is widely used throughout Mac OS X and Windows in applications like iTunes and popular printers to allow users to set up a network service without any configuration.

From Photoshop or Bridge you can connect to a Version Cue server without having type in a IP address. It does not enable Photoshop or Bridge to do file sharing as this is done by the Version Cue Server. It does not send information over the Internet or to Adobe. When you click on the Version Cue area in the Adobe Dialog, the Bonjour daemon running on the local machine will browse for visible Version Cue servers on your subnet. You can then log in to access the file management capabilities of the Version Cue server.

To request access to the Version Cue beta program, please contact Mike Wallen (mwallen at adobe dot com).  For more info on Bonjour, see also this Apple developer FAQ and the entry on Wikipedia.

[Update 5/11/07: I saw the following info from Timo Naroska of the Version Cue team and thought it would be worth sharing:

Bonjour sends/receives packets to the multicast IP 244.0.0.251. Routers do not forward these packets outside the local network. Furthermore Bonjour pings the local DNS server to check whether it supports service discovery.

No critical information is ever transferred.

The user should usually allow Bonjour to connect the "internet" to seamlessly browse/connect Version Cue Servers in the local network.

If the user decides to block Bonjour internet access, automatic server discovery on the local network and the local machine are hampered. The user will have to connect servers manually by IP/DNS-name.]

We made this decision a couple weeks ago, but I didn’t want to publicize it widely until the staff was back at full strength after the holiday break. Please note that this is a manual process on our side right now, and we appreciate your patience as we handle requests.

Related: If you find that you want to switch an Adobe product license from Mac to Windows or vice versa, please contact Adobe Customer Service.  They’ll walk you through the process.

For more info, check out Russell Brown’s 4-minute video intro to the Black & White dialog, where he shows off the ability to click and drag on color regions to adjust them, as well as a technique for hand-tinting the results.  Russell produced some great B&W presets for Camera Raw in CS2, so I’m sure he’ll offer more good info, tips, and settings for the much-improved B&W controls in CS3′s Camera Raw 4.0.  I had fun using the new split toning functions, together with Photoshop’s venerable Lighting Effects dialog, to show my wife contemplating a "Portrait of the Governor as a Young Man" on New Year’s Eve. (It was a weird party. ;-))

• Opt/Alt + Shift temporarily shows the clone overlay, plus it lets you drag it around and ‘tack’ it down at the desired location.
• Opt/Alt + Shift + the arrow keys nudges the overlay up, down and side to side.
• Opt/Alt + Shift + [ or ] rotate the source
• Opt/Alt + Shift + < or > scale the source

Also, to adjust rotation, position, or scale, you can also use "scrubby sliders": hover over the label on each field (H, W, etc.), then drag left or right.   As with all scrubby sliders, holding Opt/Alt while dragging will make the values change 10X slower, and holding Shift will make them change 10X faster.

On a related note, retouchers will be happy to learn that it’s now possible to have cloning/healing ignore adjustment layers.  Let’s say in CS2 you had an image on the background layer, then added a layer above it to do some cloning (so as not to affect the original pixels), and above that you put a Hue/Saturation layer.  If you used the clone tool set to sample all layers & didn’t turn off the Hue/Sat layer, the results would be screwy, as Hue/Sat would be double-applied.  Now via a couple of new options (screenshot), you can elect to make cloning/healing ignore adjustment layers, and/or ignore all layers above the current one.  It’s a really tweaky little change, but it’s one that’s been requested for ages.

The Photoshop CS3 beta includes some improvements in the HDR realm.  Some more functions (e.g. Levels) are enabled for 32-bit images, and the Merge to HDR command, although superficially similar to the one in CS2, contains a variety of improvements.  It benefits from the new image alignment code; preserves a more complete set of source data; and uses improved algorithms for merging the data.

Trevor Morris has kindly supplied an HDR photo created with the CS3 beta, as well as the source frames.  He says, "I could never get it to work in CS2, but it worked flawlessly in CS3, and I was quite pleased with the results."  He writes,

This photo was shot inside the Christ Church Cathedral, located in Fredericton, New Brunswick, Canada.
For this particular shot, I used a tripod and remote to capture 12 exposures, from 1/125s to 20s, with a Nikon D70 @ f/16, ISO 200, FL 18mm. I combined the exposures using Merge to HDR, increased the local contrast, and gave the image a slight saturation boost.

Give it a whirl with your bracketed shots, and please let us know whether it works well for you.

• Why can’t you paint directly onto a surface that has a Smart Filter applied?
• Why are you limited to having one filter mask per layer (instead of having one per filter)?
• Why do Smart Filters add file size?

If you’re interested in the story of how and why Smart Filters came to be as they are, read on.  I find the whole topic of how Photoshop is evolving from a simple "a pixel is a pixel" app into a dramatically more powerful editing pipeline fascinating, but I recognize it’s not everyone’s cup of tea. :-)

Around four years ago (while building CS1), we took a crack at enabling non-destructive filtering.  After talking with quite a few customers, we opted to enable "Filter Layers"–just like adjustment layers, except containing filters.  We quickly encountered a number of problems, both technical and conceptual:

1. Performance: It’s one thing to run something well on a screen-resolution document, and quite another to run it well on the huge multi-layer images that Photoshop is often asked to handle. Yes, computers keep getting faster, but cameras and other devices generate ever more data, and our collective patience keeps getting shorter.  There were too many times when performance was lousy–say, whey trying to paint layer 20 out of 50 with a bunch of filter layers applied.  We therefore required filter layers to turn off while editing the layers to which they were applied, after which they would be re-applied.  This made for a pretty lame user experience.
2. File Size: There’s no free lunch: you can either pay as you go (storing both "before" pixels and "after" pixels in a document), or you can pay later (not storing the pixels in the doc, and requiring the filters to be re-applied when opening the doc).  If you don’t store the filtered "after" pixels, then the PSD file can’t be opened by apps that don’t have the same filters installed (bad for backward compatibility, cross-app integration, etc.). We opted to store the after pixels, but because adjustment layers are very small, people were then surprised that something that looked similar would add file size.
3. Editability: This may be the toughest of the three, because it’s conceptual, not technical.  If you apply a transformation that substantially changes the appearance of the underlying pixels (e.g. Polar Coordinates is one extreme; see screenshot), what should happen when you attempt to paint or otherwise edit those pixels? As you drag a straight line to the right, what should you be seeing through the prism of the filter(s)?

So, with knowledge in hand but not much else, we pulled the plug on filter layers.  As work progressed on CS1, we thought about ways to build a solution that not only addressed the pain points above, but that solved other Photoshop limitations (scaling and warping non-destructively, integrating with Illustrator and other apps, etc.).  That’s when Smart Objects were born.

Okay, about the name: I technically work in marketing, but I hate cheesy names, and making everything "live" this or "smart" that starts to have a whiff of fromage to it.  Finding a simple, factual name proved difficult for a feature that’s really general–one that enables, among other things:

• Turning one or more layers into something that can be scaled, rotated, or warped losslessly
• Creating multiple instances, all of which update when one is edited
• Preserving complex vector data & re-editing it in Illustrator
• Preserving raw data & re-editing it in Camera Raw
• Potentially enabling linking to external files
• Potentially lots more that I can’t get into here/now

So, we went with a pretty generic name–"Smart Objects." The concept is identical to the Smart Objects feature that’s been in GoLive for several versions: place something the app doesn’t understand natively, and on the fly turn it into a native version, while keeping the source & output linked together. People sometimes get hung up on the one implementation difference (GL links whereas PS embeds), but doing so misses the main point: on-the-fly conversion from {whatever data} to native pixels.

As the basis for Smart Filters, Smart Objects address the three pain points of Filter Layers listed above:

1. For performance, they don’t set the expectation that you can be drawing/painting/moving things while watching the results update on the fly.
2. For file size, they create a visible, new entity, and they require a conscious choice to create it. And it’s the same hit you take for enabling re-editable scaling and warping.
3. For editability, again they don’t set the expectation that you can paint while seeing the results applied.  You simply edit the un-filtered/-warped/-scaled pixels, hit save, and then see the transformed results.

That’s why you can’t paint directly onto a filtered surface, and why you can have only one filter mask per Smart Object (because multiple masks would lead you to expect that filters would update while painting on masks underneath them).

This entry is pretty long already, so I’ll cut myself off, but in the next day or two I plan to post an entry that discusses some of the challenges involved in making Smart Objects easier to use.

What may not be obvious to a non-engineer like me, however, is that not all operations can or should be split among multiple cores, as doing so can actually make them slower.  Because memory bandwidth hasn’t kept pace with CPU speed (see Scott Byer’s 64-bit article for more info), the cost of moving data to and from each CPU can be significant.  To borrow a factory metaphor from Photoshop co-architect Russell Williams, "The workers run out of materials & end up standing around."  The memory bottleneck means that multi-core can’t make everything faster, and we’ll need to think about doing new kinds of processing specifically geared towards heavy computing/low memory usage.

Because Russell has forgotten more than I will ever know about this stuff, I’ve asked him to share some info and insights in the extended entry.  Read on for more.

Intel-based architectures don’t necessarily add memory bandwidth as they add cores. A single CPU on a system with limited memory bandwidth can often
saturate the memory bandwidth if it just moves a big chunk of memory from here to there. It even has time to do several arithmetic operations in between and still saturate the memory. If your system is bandwidth-limited and the operation you want to do involves moving a big chunk of data (bigger than the caches) from here to there while doing a limited number of arithmetic operations on it, adding cores cannot speed it up no matter how clever the software is. Many Photoshop operations are in this category, for instance.

AMD’s architecture adds memory bandwidth as you add CPU chips, but taking advantage of it can be dependent on placement of the data into different areas of physical RAM attached to the different chips. It doesn’t do any good if all your data gets put into one of the memory banks — then you’re right back where you started.  So, the memory system and how it’s used will have a big effect on how many
things speed up when you add more cores to a computer.

The other issue is Amdahl’s Law, described by computer architect Gene Amdahl in the 1960s. Almost all algorithms that can be parallelized also have some portion that must be done sequentially — setup (deciding how to divide the problem up among multiple cores) or synchronization, or collecting and summarizing the results. At those times each step depends on the step before being completed. As you add processors and speed up the parallel part, the sequential part inevitably takes up a larger percentage of the time. If 10% of the problem is sequential, then even if you add an infinite number of processors and get the other 90% of the problem done in zero time, you can achieve at most a 10X speedup. And some algorithms are just really hard or impossible to parallelize: calculating text layout on a page is a commonly cited example.

These two basic issues are why the giant massively parallel machines have RAM attached to each node and are used to solve only a small set of specially selected, specially coded problems — usually ones where the parallel part of the problem itself has been scaled up to enormous sizes. As the number of cores goes up, the likelihood that a particular problem will hit one of the above limits goes up.

Why does video rendering scale better than Photoshop? Rendering video is typically done by taking some source image material for a frame and performing a stack of adjustments and filters on it. Each frame is only a few hundred thousand pixels (for standard definition) or at most 2 megapixels or 8MB in 8-bit (for HD). Thus, particularly for standard definition images, the cache gives a lot more benefit as a sequence of operations are performed on each frame, and for each frame, you fetch the data, do several operations, and write the final result. Different frames can usually be rendered in parallel – one per processor, and so each processor does a fair chunk of computation for each byte read or written from memory.

By contrast, in Photoshop most time-consuming operations are performed on a single image layer and the problem is the size of that layer — 30MB for an 8-bit image from a 10MP digital camera. 60MB if you keep all the information by converting the raw file to 16 bit. Or if you’ve merged some Canon 1DSMkII images to HDR, that’s over 200MB. And of course the people most concerned with speeding up Photoshop with more cores are the ones with the giant images. When you run a Gaussian Blur on that giant image, the processor has to read all of it from memory, perform a relatively few calculations, and then write the result into newly allocated memory (so you can undo it). You can work on different pieces of the image on different processors, but you’re not doing nearly as much computation on each byte fetched from memory as in the video case. The operations that scale best in Photoshop are those that:

1. Do a lot of computation for each pixel fetched. Shadow/Highlight correction is an example of an operation that has to do a lot of computation on each byte fetched, while normal blending does very little.  A giant-radius blur is an example of the opposite extreme: lots of pixels have to be fetched to do a simple computation and produce one output pixel.
2. Do pixel-based operations that take advantage of Photoshop’s framework for parallel computation. Most filters and adjustments fall into this category. But
   many text tool operations and the solution of partial differential equations
   required for the healing brush are examples of things that don’t fit this
   framework..

To take good advantage of 8- or 16- core machines (for things other than servers), we’ll need machines whose bandwidth increases with the number of cores, and we’ll need problems that depend on doing relatively large amounts of computation for each byte fetched from main memory (yes, re-reading the same data you’ve already fetched into the caches counts). Complex video and audio signal processing are good examples of these kinds of tasks. And we’re always looking for more useful things that Photoshop can do that are more computationally intensive.

– Russell Williams

As of this past summer, Photoshop engineers Jeff Chien and Gregg Wilensky had been cranking away on these tools for a while & had them working well for hard-edge selections.  As luck would have it, Jeff’s mane is a little thin on top, and Gregg is more folliclularly challenged.  So, when Jeff returned from vacation to Taiwan, he was rather unhappy to find that Quick Selection was selecting only his head, missing the wispy bits of hair on top.  As he proclaimed while making a quick whiteboard self portrait, "I need to keep all the hair I’ve got!"

The desire to do a better job with irregular edges like hair got the guys thinking about new solutions, resulting in new algorithms we’ve been calling TrueEdge.  You can see the kind of refinement possible via the Radius & Contrast controls in this screenshot. Pretty cool, eh?  Viva Mother Nature (sorry, guys!). ;-)

*For a video intro to the tools, you can consult Deke McClelland or Dave Cross.