Stephan Paukner :: syslog

Besides the fact that it was a pain to find out how ImageMagick’s -average option is to be used, it turned out to operate wrongly. The switch calculates the mean of an image sequence, i.e. the mean color values for every pixel. Say, if you have a bunch of images with file names like img*.jpg and want the average saved into avg.jpg, the command line is:

Pretty intuitive. The problem is that you define the mean image Ī[n] of n images I[k] as

while ImageMagick does it recursively as

(with Ĩ[1]=I[1]),

giving you wrong weights ¹⁄_2^n−k+1 like e.g. for n=8

instead of the intended weights ¹⁄_n like

.

This misbehaviour can be proven e.g. by taking this sequence of a plain blue, green and red image:

and averaging it with the above command. The result is too reddish:

The solution I found was to call convert recursively like this:

By this, the average of the above example images correctly becomes gray:

There might be similar problems with the other image sequence operators, but I haven’t examined them. Maybe I should file a bug.

The usenet originally only consisted of text messages, but it soon became a way of exchanging binary files as well. As posts are usually restricted to only a few MB, larger archives have to be split up into several parts, each attached to its own newsgroup posting. But if some parts of these posts aren’t transferred correctly to other usenet hosts, the archive parts are broken.

Not necessarily if the poster created PAR2 archives in addition to the actual data archive parts. In a RAID-like manner, parity information is placed redundantly into the additional files. Thus, it is possible to recover the complete archive if some parts of it are incomplete.

As I downloaded some image archives (No, they were not p’rn) containing pictures in the PCD format that encapsulates six different resolutions of an image, I also had to find out how to explicitly extract the large (3072×2048) resolution out of it. All in all, I created the following (simple) script that

1. checks the PAR2 files, and if some of the data archive parts are incomplete, it
2. tries to recover them, and
3. if check (or recovery) were successful, the PCD images are extracted and converted to JPEG.

I did it this way:

Sometimes I take AVI videos with my Canon PowerShot, and I process some of them with a video editor and export them as MPEG. However, those video formats can’t be streamed, and so I like to convert them to FLV to enable a YouTube-like streaming in web galleries by a flash video player.

For convenience, I wanted to use a context menu entry for Nautilus, where I could right-click on a video file and select “Convert video to FLV”. Luckily, Nautilus supports to execute arbitrary scripts from the context menu if you simply place them into ~/.gnome2/nautilus-scripts/. The only disadvantage is that it doesn’t check the file type in advance, thus also showing the video conversion entry for non-video files. However, you can include that logic into the script itself.

The script is a little more complicated, as I didn’t know how to better parse the file names. Probably I should have used Perl. Here is my ~/.gnome2/nautilus-scripts/Convert\ video\ to\ FLV:

It’s a really good tip to use the -x flag to debug bash scripts. I had a problem that GDM wasn’t starting anymore after the regular aptitude upgrade. I didn’t find a hint in the log files and had a look at its init-script /etc/init.d/gdm, which appeared quite complex to me: It sources various config files and calls macros that are defined in there. How the heck should I trace the problem down? The best way was to change the initial line to

what starts the debug mode when the script is invoked. Here’s what it does: It prints every single command that is executed line by line in a fully expanded form, no matter if macros were defined or several other shell scripts are invoked from within. The lines are indented by a sequence of plus symbols to represent the invocation depth of the other scripts. By this, I saw that the last calls referred to splashy, a bootsplash package that I had installed for test purposes but never had configured. The solution was to simply remove that package.

Another tip: Don’t do experiments on a system that is supposed to work! This also means to not install the complete Debian ‘testing’ version on it. If you need a selected number of some more recent software, upgrade it individually, but keep the basic packages ‘stable’. On the other hand, you wouldn’t learn much if you weren’t forced to fix things once in a while.

For the usage of a local backup host, I defined the following scenario, which could also be used for a printer server or any other type of host, which shouldn’t run 24/7, but:

• The host should be able to be woken up manually by a special signal on the LAN, i.e., it should be capable of WOL. (This is only a hardware issue)
• If it is woken up, it should run at least for 30 minutes before trying to shutdown again.
• It shouldn’t shut down while certain processes are running, such as a backup, i.e., it should be capable of a shutdown-lock. If the lock is removed, it might shutdown.
• The host shouldn’t shut down as long as a certain client, e.g. a backup client, is (still) up and running (pingable)
• If the criteria above aren’t hurt, the host should finally shut down.

And here’s the shell-script which implements the above. It’s enough to have it run every five minutes. The “echoes” are only interesting for debugging purposes.

If RCS is used separately from CVS (e.g. for system configuration management), I sometimes want to know whether there are any uncommitted changes pending. Here’s my bash alias to get an overview:

Maybe you want rcsdiff to be an alias for a home-made rcscolordiff, which itself simply calls

rcsdiff $@ | colordiff --no-banner.