Shallow Thoughts : : Nov

Upheaval Dome: New research confirms impact theory

Kurt Fisher wrote to draw my attention to the latest Lunar Photo Of the Day (LPOD), a lovely shot he made of one of my favorite places anywhere, Upheaval Dome in Utah's Canyonlands National Park.

Upheaval Dome has long been strongly suspected to be a massive, eroded impact crater, but the LPOD highlights a study that finally puts this (non-)controversy to rest, Elmar Buchner and Thomas Kenkmann's Upheaval Dome, Utah, USA: Impact origin confirmed, documenting shocked quartz grains in the Kayenta sandstone of Upheaval's outer ring.

It's about time -- it's been pretty clear for many years that this structure was an impact formation, not a collapsed salt dome (the relative lack of salt in the core might have been a clue) but the park service doesn't seem to have gotten the message, giving equal weight to the salt-dome theory in all its Canyonlands literature and signs. Perhaps the Buchner and Kenkmann paper will finally convince them.

Reading about this gave me the push I needed to update my own Upheaval Dome page, adding links to the latest research and to the excellent Upheaval Dome Bibliography Kurt has put together. My page also badly needed a bigger view of the crater itself, so I stitched together a quick panorama of the view from the rim that I'd shot on a trip several years ago but never assembled.

Tags: geology, astronomy, trails, impact crater
[ 13:15 Nov 29, 2008    More science/geology | permalink to this entry | ]

Software brightness control in X11

I love my new monitor. The colors are great, it's sharp, the angles are good. Only one problem: it's really really bright.

It has the usual baffling "push buttons at random trying to figure out how to navigate the menu system" brightness control -- which dims the monitor's perceived brightness by about .003% if I take it all the way to the bottom of the scale. (This is apparently a bug that some of these Dells have and others don't.)

It has contrast, too -- but the monitor won't change contrast when running through the DVI cable (this is even documented in the monitor's manual). I have no idea why. It makes me wonder whether there's normally a way of changing brightness over a DVI cable; but lots of googling hasn't brought enlightenment on that score.

I tried the VGA cable. The display was very noticeably less sharp, though pressing the monitor's "auto adjust" improved it a lot. Contrast adjustment did work (and helped) using the VGA cable, but it also turned everything green. I was able to improve the color cast a bit with
xgamma -ggamma .75 -bgamma .9
but this was all looking like quite a hassle. I wanted an easier way to change brightness. xgamma wasn't it: it works well for fine-tuning but its brightness curve is way off if you try to depart by much from full brightness.

Enter xbrightness and xbrightness-gui (Mikael Magnusson to the rescue again! He knew about these excellent programs, and perhaps equally important, he had a copy of xbrightness-gui, which seems to have vanished from the web.)

xbrightness is an excellent little command-line program that sets the X gamma curve to appropriate values. Just run xbrightness BRIGHTNESS passing it a value between 0 and 65535. xbrightness-gui is an interactive program that lets you drag curves around for each of the three color curves, or the combined image, with a user interface very similar to GIMP's Curves tool. You can even save and load curves.

xbrightness-gui's coolness notwithstanding, the simple xbrightness was really all I needed. It does a fine job of adjusting the monitor brightness while keeping colors neutral. The version I was using was Mikael's version, to which he'd added the ability to adjust colors too (much like xgamma does, but using more useful curves). It turns out I don't need the color correction, but it's nice to know it's there.

But what I did need was a way to query the current brightness, and, more important, a way to bump the brightness a little bit up and down. So I added those features. Getting the current brightness isn't actually something you can do, since the whole gamma curve for the three channels is what you perceive as brightness. I didn't try to estimate perceived brightness based on the whole curve; I just took the value of the highest value for each color, and their average or maximum.

Then I tied my new increment/decrement into key bindings in Openbox. I bound W-F5 (the Windows key plus F5) to xbrightness -2560, and W-F6 to xbrightness +2560, so I can go up or down in brightness by pressing keys without having to type any five-digit numbers.

I've made available the old xbrightness-gui, since it's no longer available anywhere else; a patch that integrates my changes and Mika's into xbrightness-0.3; and the patched xbrightness tarball. They're all at http://shallowsky.com/software/xbrightness/.

One other fun thing about using X gamma settings to adjust brightness. The first night I used it, I noticed at some point that my cursor looked very different -- it had become blindingly white. It turns out that the cursor is implemented at a lower level and doesn't go through the X gamma system. So turning the brightness down via gamma curves doesn't affect the cursor, which remains always at full brightness. It's quite a nice side effect -- the cursor is much more visible than it normally is.

Tags: linux, monitor, brightness
[ 12:37 Nov 26, 2008    More linux | permalink to this entry | ]

Handling Long URLs in Firefox

I have a new Firefox Tips article up on Linux Planet: The Plague of Ridiculously Long URLs (note I didn't choose the title). It discussees how to handle long URLs broken over several lines, of the sort we so often see in email messages.

Tags: writing, mozilla, firefox
[ 10:43 Nov 20, 2008    More writing | permalink to this entry | ]

Cleaning up the edges of Moonroot's transparent images

I wrote moonroot more to figure out how to do it than to run it myself. But on the new monitor I have so much screen real estate that I've started using it -- but the quality of the images was such an embarrassment that I couldn't stand it. So I took a few minutes and cleaned up the images and made a moonroot 0.6 release.

Turned out there was a trick I'd missed when I originally made the images, years ago. XPM apparently only allows 1-bit transparency. When I was editing the RGB image and removing the outside edge of the circle, some of the pixels ended up semi-transparent, and when I saved the file as .xpm, they ended up looking very different (much darker) from what I had edited.

Here are two ways to solve that in GIMP:

1. Use the "Hard edge" option on the eraser tool (and a hard-edged brush, of course, not a fuzzy one).
2. Convert the image to indexed, in which case GIMP will only allow one bit's worth of transparency. (That doesn't help for full-color images, but for a greyscale image like the moon, there's no loss of color since even RGB images can only have 8 bits per channel.)

Either way, the way to edit a transparent image where you're trying to make the edges look clean is to add a solid-color background layer (I usually use white, but of course it depends on how you're going to use the image) underneath the layer you're trying to edit. (In the layers dialog, click the New button, chose White for the new layer, click the down-arrow button to move it below the original layer, then click on the original layer so your editing will all happen there.)

Once you're editing a circle with sharp edges, you'll probably need to adjust the colors for some of the edge pixels too. Unfortunately the Smudge tool doesn't seem to work on indexed images, so you'll probably spend a lot of time alternating between the Color Picker and the Pencil tool, picking pixel colors then dabbing them onto other pixels. Key bindings are the best way to do that: o activates the Color Picker, N the Pencil, P the Paintbrush. Even if you don't normally use those shortcuts it's worth learning them for the duration of this sort of operation.

Or use the Clone tool, where the only keyboard shortcut you have to remember is Ctrl to pick a new source pixel. (I didn't think of that until I was already finished, but it works fine.)

Tags: programming, astronomy, gimp
[ 15:48 Nov 16, 2008    More gimp | permalink to this entry | ]

Using (or not) an Apple Cinema Display on a non-Apple

Dave and I recently acquired a lovely trinket from a Mac-using friend: an old 20-inch Apple Cinema Display.

I know what you're thinking (if you're not a Mac user): surely Akkana's not lustful of Apple's vastly overpriced monitors when brand-new monitors that size are selling for under $200!

Indeed, I thought that until fairly recently. But there actually is a reason the Apple Cinema displays cost so much more than seemingly equivalent monitors -- and it's not the color and shape of the bezel.

The difference is that Apple cinema displays are a technology called S-IPS, while normal consumer LCD monitors -- those ones you see at Fry's going for around $200 for a 22-inch 1680x1050 -- are a technology called TN. (There's a third technology in between the two called S-PVA, but it's rare.)

The main differences are color range and viewing angle. The TN monitors can't display full color: they're only 6 bits per channel. They simulate colors outside that range by cycling very rapidly between two similar colors (this is called "dithering" but it's not the usual use of the term). Modern TN monitors are astoundingly fast, so they can do this dithering faster than the eye can follow, but many people say they can still see the color difference. S-IPS monitors show a true 8 bits per color channel.

The viewing angle difference is much easier to see. The published numbers are similar, something like 160 degrees for TN monitors versus 180 degrees for S-IPS, but that doesn't begin to tell the story. Align yourself in front of a TN monitor, so the colors look right. Now stand up, if you're sitting down, or squat down if you're standing. See how the image suddenly goes all inverse-video, like a photographic negative only worse? Try that with an S-IPS monitor, and no matter where you stand, all that happens is that the image gets a little less bright.

(For those wanting more background, read TN Film, MVA, PVA and IPS – Which one's for you?, the articles on TFT Central, and the wikipedia article on LCD technology.)

Now, the comparison isn't entirely one-sided. TN monitors have their advantages too. They're outrageously inexpensive. They're blindingly fast -- gamers like them because they don't leave "ghosts" behind fast-moving images. And they're very power efficient (S-IPS monitors, are only a little better than a CRT). But clearly, if you spend a lot of time editing photos and an S-IPS monitor falls into your possession, it's worth at least trying out.

But how? The old Apple Cinema display has a nonstandard connector, called ADC, which provides video, power and USB1 all at once. It turns out the only adaptor from a PC video card with DVI output (forget about using an older card that supports only VGA) to an ADC monitor is the $99 adaptor from the Apple store. It comes with a power brick and USB plug.

Okay, that's a lot for an adaptor, but it's the only game in town, so off I went to the Apple store, and a very short time later I had the monitor plugged in to my machine and showing an image. (On Ubuntu Hardy, simply removing xorg.conf was all I needed, and X automatically detected the correct resolution. But eventually I put back one section from my old xorg.conf, the keyboard section that specifies "XkbOptions" to be "ctrl:nocaps".)

And oh, the image was beautiful. So sharp, clear, bright and colorful. And I got it working so easily!

Of course, things weren't as good as they seemed (they never are, with computers, are they?) Over the next few days I collected a list of things that weren't working quite right:

• The Apple display had no brightness/contrast controls; I got a pretty bad headache the first day sitting in front of that full-brightness screen.
• Suspend didn't work. And here when I'd made so much progress getting suspend to work on my desktop machine!
• While X worked great, the text console didn't.

The brightness problem was the easiest. A little web searching led me to acdcontrol, a commandline program to control brightness on Apple monitors. It turns out that it works via the USB plug of the ADC connector, which I initially hadn't connected (having not much use for another USB 1.1 hub). Naturally, Ubuntu's udev/hal setup created the device in a nonstandard place and with permissions that only worked for root, so I had to figure out that I needed to edit /etc/udev/rules.d/20-names.rules and change the hiddev line to read:

KERNEL=="hiddev[0-9]*", NAME="usb/%k", GROUP="video", MODE="0660"

That did the trick, and after that acdcontrol worked beautifully.

On the second problem, I never did figure out why suspending with the Apple monitor always locked up the machine, either during suspend or resume. I guess I could live without suspend on a desktop, though I sure like having it.

The third problem was the killer. Big deal, who needs text consoles, right? Well, I use them for debugging, but what was more important, also broken were the grub screen (I could no longer choose kernels or boot options) and the BIOS screen (not something I need very often, but when you need it you really need it).

In fact, the text console itself wasn't a problem. It turns out the problem is that the Apple display won't take a 640x480 signal. I tried building a kernel with framebuffer enabled, and indeed, that gave me back my boot messages and text consoles (at 1280x1024), but still no grub or BIOS screens. It might be possible to hack a grub that could display at 1280x1024. But never being able to change BIOS parameters would be a drag.

The problems were mounting up. Some had solutions; some required further hacking; some didn't have solutions at all. Was this monitor worth the hassle? But the display was so beautiful ...

That was when Dave discovered TFT Central's search page -- and we learned that the Dell 2005FPW uses the exact same Philips tube as the Apple, and there are lots of them for sale used,. That sealed it -- Dave took the Apple monitor (he has a Mac, though he'll need a solution for his Linux box too) and I bought a Dell. Its image is just as beautiful as the Apple (and the bezel is nicer) and it works with DVI or VGA, works at resolutions down to 640x480 and even has a powered speaker bar attached.

Maybe it's possible to make an old Apple Cinema display work on a Mac. But it's way too much work. On a PC, the Dell is a much better bet.

Tags: linux, tech, photo, graphics, monitor, S-IPS, TN, ADC, DVI
[ 21:57 Nov 15, 2008    More tech | permalink to this entry | ]

Great Advertising

Usually I just delete spam after seeing the subject line. But I couldn't resist one that arrived this morning:

Subject: You'll be saying WOW every time with ShamWow

Wondering whether the seller was familiar with the meaning of the word "sham", I just had to take a look.

I couldn't tell anything from the text -- it was all just random verbiage to try to fool Baysian filters. But the mail also attached two images, img001.png and img002.png. The first was a big grey starburst thing; the second, at 348Kb, was the actual ad (click on it to get the full-sized version; the thumbnail here doesn't do it justice).

There are just so many things to love about this ad, starting with the name "ShamWow" itself. I love the mixture of fonts and bright colors, with the slightly lopsided hourglass shape of the ShamWow! logo. I love the "AS SEEN ON TV" bug -- a charming image that hasn't changed a whit since the 60's, maybe even the 50's. I love the unidentifiable grey and yellow flat things with unreadable text on them -- they look like file folders and folded papers, but they're probably two different colors and sizes of ShamWow -- covered with a square announcing "10 Year [unreadable]", which made me wonder if they were selling auto loans or securities. But if you magnify it you find that the third word is probably "Warranty". I love the presumption that you'll think that 20x the weight of a small cloth object is a lot of water (is it? I have no idea, let me grab a paper towel and a gram scale). I love the blurry red and white "CLICK FOR DETAILS" button.

But what I like best about this image is that it's a PNG but it's full of JPG artifacts. Now, I'm not very picky about jpeg artifacts. (You'd think I would be, as a de-facto GIMP expert, but I'm really not.) I shoot DSLR photos in jpeg rather than raw mode because most of the time the difference just isn't enough for me to care about. I use jpeg for most of the icons on my web site if they don't need transparency, and I lower the jpeg quality level to make them load faster. I'm not a PNG snob (actually, I'm more likely to use GIF than PNG for web icons). But really -- this ad image is a wonderful example of jpeg artifacts and why you can't just turn the quality down arbitrarily far.

I could even understand using extreme jpeg compression because they were sending out a hundred quotillion spam messages and wanted to reduce bandwidth. But they're not sending a jpeg -- they've converted the low-quality JPG back to a 348Kb PNG before sending the spam.

All I can figure is that someone designed the ad and saved it as JPG, making it really small. And then someone in the business saw lbrandy's great cartoon on JPG vs. PNG -- and said "Oh, no! We'd better use PNG instead! And loaded up the JPG and saved it as a PNG with default settings.

(For further reading on PNG vs. JPEG and image file size optimization, you can get an overview of formats at my Image Formats for the Web and some detailed tutorials at the Bandwidth Conservation Society; or chapters 2 and 8 in my GIMP book, soon to be out in its second edition.)

Tags: humor, advertising, gimp
[ 11:54 Nov 14, 2008    More humor | permalink to this entry | ]

Spamassassin false positives: obsolete rules on Etch

I checked my Spam Assassin "probably" folder for the first time in too long, and discovered that I was getting tons of false positives, perfectly legitimate messages that were being filed as spam.

A little analysis of the X-Spam-Status: headers showed that all of the misfiled messages (and lots of messages that didn't quite make it over the threshold) were hitting a rule called DNS_FROM_SECURITYSAGE.

It turned out that this rule is obsolete and has been removed from Spam Assassin, but it hasn't yet been removed from Debian, at least not from Etch.

So I filed a Debian bug. Or at least I think I did -- I got an email acknowledgement from submit@bugs.debian.org but it didn't include a bug number and Debian's HyperEstraier based search engine linked off the bug page doesn't find it (I used reportbug).

Anyway, if you're getting lots of SECURITYSAGE false hits, edit /usr/share/spamassassin/20_dnsbl_tests.cf and comment out the lines for DNS_FROM_SECURITYSAGE and, while you're at it, the lines for RCVD_IN_DSBL, which is also obsolete. Just to be safe, you might also want to add
score DNS_FROM_SECURITYSAGE 0
in your .spamassassin/user_prefs (or equivalent systemwide file) as well.

Now if only I could figure out why it was setting FORGED_RCVD_HELO and UNPARSEABLE_RELAY on messages from what seems to be perfectly legitimate senders ...

Tags: linux, spam, bugs
[ 22:54 Nov 12, 2008    More linux | permalink to this entry | ]

Pho 0.9.6 finally released!

Pho 0.9.6-pre3 has been working great for me for about a month, and I've been trying to find the time to do a release. I finally managed it this weekend, after making a final tweak to change the default PHO_REMOTE command from gimp-remote to gimp since gimp-remote is obsolete and is no longer built by default.

The big changes from 0.9.5 are Keywords mode, slideshow mode, the new PHO_REMOTE environment variable, swapping -f and -F, and a bunch of performance work and minor bug fixing.

I built deb packages for Ubuntu (Hardy, but they should work on Intrepid too) and Debian (Etch), as well as the usual source tarball, and they're available at the usual place:

http://shallowsky.com/software/pho.

Tags: programming, pho, image viewer
[ 18:11 Nov 09, 2008    More programming | permalink to this entry | ]

Linux Planet: Why Firefox Rocks on Linux

My latest Linux Planet article, Why Firefox Rocks on Linux, discusses Linux-specific Firefox shortcuts involving the middle mouse button, the URLbar and the scrollbar. It's getting good Diggs, too, and comments from people who found the tips helpful, which is great. A lot of people don't know about some of these great Linux time-savers, but these are the sort of things that make me love Linux and stick with it even when it gets frustrating. I hate to think of people missing out just because there's no obvious way to discover some of the shortcuts!

Tags: writing, mozilla, firefox, linux
[ 21:44 Nov 06, 2008    More writing | permalink to this entry | ]

A word count bookmarklet

This posting ended up being published as a Linux Planet Quick Tip. You can read about my nifty word counting bookmarklet there: Quick Firefox Tip: Word Count Bookmarklet.

Tags: firefox, mozilla, bookmarklets, writing, programming
[ 23:41 Nov 03, 2008    More tech/web | permalink to this entry | ]