Photoshop CS2 HDR

Photoshop CS2 HDR

A couple of years ago I saw an article on how to use Photoshop and exposure bracketing to create composite images that had good detail in both highlights and shadows. The article explained that digital had a smaller dynamic range than film, and that even film didn't have the range to cover some landscape scenes.

By the time I was done reading I had the impression that the author, Michael Reichmann, would be pleased if he didn't have to compress the dynamic range, but instead had a way to combine two images of 8-bit depth into a single image having, say, a 12-bit range.

Sure enough, the new Photoshop release can do it. And the same author has posted an article on how to use it:

http://www.luminous-landscape.com/tutorials/hdr.shtml

Naturally, now the problem is that neither computer monitors nor printers can handle 32-bit image data. And at the end of this article Mr. Reichmann suggests that camera manufacturers need to begin producing cameras that provide better control over exposure increments when producing bracketed shots.

But why stop there? Why not let the camera do its own sampling of light levels across the scene and then automatically produce bracketed shots which cover the scene's entire dynamic range?

Even better, why not perform the bracketing and merge in-camera, producing a final, high-dynamic range image with no effort on the part of the lazy photographer? (Me.) I can think of only three reasons: processing power, battery power and memory :)

Wired News: People Are Human-Bacteria Hybrid

Wired News: People Are Human-Bacteria Hybrid

we are best viewed as walking "superorganisms," highly complex conglomerations of human cells, bacteria, fungi and viruses...we are somewhat outnumbered by the [microbes].

Nicholson's colleague, professor Ian Wilson from Astra Zeneca, believes the "human super-organism" concept "could have a huge impact on how we develop drugs, as individuals can have very different responses to drug metabolism and toxicity."

the human genome does not carry enough information on its own to determine key elements of our own biology.

TortoiseSVN

Some of my co-workers dislike using the command-line to access Subversion repositories. For those running Windows, TortoiseSVN is looking good.

Once it's installed, subversion operations become available from the context menu of Windows Explorer. Checkouts, commits, configuration of TortoiseSVN, it's all right there.

When you're browsing a local checkout of an SVN repository, document icons are decorated with green checkmarks, red exclamation marks, etc. to show whether they are in sync with the repository, whether you have made local modifications, etc.

So far the only problem I've had with TortoiseSVN has been in figuring out how to do a checkout from a read-write repository. There may be better ways of solving the problem, but here's what has worked for me.

First, use svn+ssh to access the repository. In the URL, specify your username on the subversion host. And of course this means you need to use the absolute path to the repository in the URL:

svn+ssh://my_username@my_svn_server/abs_path_to_repository/my_project/trunk

Next, modify the TortoiseSVN settings to enable ssh tunneling. I'm not sure this is really necessary. But I did make the change, via the "Edit" button next to the "Subversion configuration file" label. Once notepad popped up with the contents of the config file, I uncommented the lines for ssh tunneling:

[tunnels]
ssh = $SVN_SSH ssh

svn+ssh: Using Subversion with SSH

I've been trying to learn how to enable secure shell (SSH) access to Subversion, on both the client and server sides. It's kind of a pain.

The whole point of using SSH is to avoid sending your source code in the clear, so maybe the pain is worth it. Or maybe this is such a common-sense usage of Subversion that somebody (like, say, me) should put some effort into making it easier to do. But I digress.

To connect to an svnserve daemon via SSH you use this repository syntax:

$ svn co svn+ssh://.../

This requires some careful preparation. First, you need to have the following lines uncommented in your client-side ~/.subversion/config:

[tunnels]
ssh = $SVN_SSH ssh

Then, on the client, your URL must include the absolute path to the repository, followed by the path of the project you want to check out from the repository.

For example, suppose you ordinarily use this command to check out a project:

$ svn co svn://svn_server/project/trunk local_name

In order to perform the same checkout using an svn+ssh URL, you'd have to use this command:

$ svn co svn+ssh://svn_server/abs_path_to_repository/project/trunk local_name

You also need an account on the SVN server, with the same username as your account on the client machine. Or you need to specify the username when performing your svn checkout, like so:

$ svn co --username bubba ...

Or you need an entry like this in your ~/.ssh/config, to tell ssh as whom it should connect to the server:

Host svnserver
Hostname svnserver.blah.com
User bubba

On the server, you need to ensure that svnserve is in the path of the user account under which you run svnserve.

You also need to ensure that the account under which you run svnserve, as well as your user account on the server and any other userr accounts which need access to the repository, are all members of the same group. (subversion would be a good name for the group.)

You also need to make sure that your umask is set to 002 (group write-able). Otherwise other users of the remote repository might find themselves suddenly unable to change some file that you've added.

Got all of that? Good! Of course, I probably forgot a few steps...