Dept. of "Why Didn't I Think of That": Getting Average Brightness of an Image 
Using convert, resize the image to 1x1 pixel, and get the image stats (in HSV):
convert original.jpeg -colorspace hsb -resize 1x1 txt:-

Credit goes to this guy: ... brightness

However, the Python PIL package will do this for you, the results are only a teensy bit different and you can get extrema and RMS for each channel:

>>> from PIL import Image
>>> from PIL import ImageStat
>>> im ='/tmp/image.jpg')
>>> stat = ImageStat.Stat(im)
>>> print stat.mean
[92.87710129310345, 94.48407707910751, 82.74996830628804]
>>> print stat.rms
[114.97883849032031, 116.21534866014377, 107.79289136583212]
>>> print stat.extrema
[(0, 255), (0, 255), (0, 255)]


~$ convert /tmp/image.jpg -resize 1x1 txt:-
# ImageMagick pixel enumeration: 1,1,255,srgb
0,0: (91,92,80) #5B5C50 srgb(91,92,80)

Actually I'd go with Python, because all the cool kids use Python and shells are for old people.

[ view entry ] ( 654 views )   |  permalink
Raspbian Wifi Adhoc Mode - It's Easy If .... 
I gave up trying to get adhoc wifi to work solely by editing /etc/network/interfaces. This, and variations thereof, never worked:
iface wlan0 inet static
wireless-channel 11
wireless-essid Pi
wireless-mode ad-hoc

What did work was creating an /etc/rc3.d/adhoc script and calling iwconfig directly. This might save you a lot of time:
ifconfig wlan0 down
iwconfig wlan0 mode ad-hoc
iwconfig wlan0 channel 11
ifconfig wlan0 up
iwconfig wlan0 essid "Pi"
ifconfig wlan0 netmask

WLAN0 does go down every time the other side of the link gets lost due to a reboot, power cycle, or some other problem. I'm working on a way short of a brute-force restart daemon to fix that.

[ view entry ] ( 613 views )   |  permalink
OSX Yosemite Fail 
Tried upgrading to OSX Yosemite. I should have suspected it was all part of the old Apple Planned Obsolescence Conspiracy:

- Memory constraints on 4GB mid-2011 Macbook Air. Yosemite caches IO more aggressively, so you see memory "95% full". Theoretically this should actually help in most circumstances (since cached IO will gove way for the memory apps need to run), but everything seemed slower, especially Firefox, my most-used app.

- Fan ran at 100% all the time, any time an app was open, even when CPU was nowhere near 100%. Was it hogging the GPU? No way to tell. I did notice several "mdworker" (Spotlight indexing) processes running, probably reindexing everything for the first time. I killed them, but to little effect.

- Forcing one to hold down the power button for a few seconds to power off instead of sleep always leaves you wondering whether you did a graceful or forced shutdown. Lame.

- Lack of a real sidebar in iTunes is annoying and makes it harder to copy stuff from device to device. Others have bitterly complained about the new iTunes, although it didn't seem so awful to me.

- A few apps won't be compatible - check first.

- The rest is all eye candy. Hey, My laptop is not an iPhone.

So upgrade on older machines at your own risk. I restored with Command-R and Time Machine with zero trouble. I had some good books to read and laundry to do, so it wasn't a complete waste of time.

[ view entry ] ( 731 views )   |  permalink
Fixing Shellshock / Bashhole on Macs 
Bash updates have been available for Linux for nearly a week, but Apple is dragging their heels, or working on a more permanent bug fix. Despite their not-really-reassuring pronouncement that "only ninjas need to worry about this", you do need to worry about this under certain conditions:

- If you have a web server running on the Mac that uses mod_cgi and any cgi that runs bash or any script that uses the "system" or "exec" call without clearing out its environment. That's been bad programming practice for years. The fix: Disable mod_cgi. For Perl-heads, use "-wT".

- There is a DHCP client proof-of-concept, but my colleague Dr Chase tried it with Mavericks and it didn't work. Older DHCP clients might be vulnerable, but I've seen no proof yet.

Best bet - if you have a compiler installed, whether from Xcode or Ports, just rebuild bash. 4.3 has 26 patches you need to install, but it builds with no problems even on my ancient Darwin G4 running 10.5.8. Rename the existing bash and sh aside in /bin, put the compiled versions in their place, and you're done.

So I'm sleeping OK at night.

There are likely to be more patches to bash in the next few weeks as the problem that makes Shellshock possible is deeply entwined in the bash code. You will probably need to rebuild or patch bash, so save your work.

[ view entry ] ( 609 views )   |  permalink
Our Friend kcmshell4: Starting KDE4 Settings from the Command Line  
In my last job, I has a legacy Nvidia video card on one of my boxes, with two displays joined side to side. Occasionally this setup caused KDE4 to drop the side by side view and revert to a mirrored copy of one of the two displays. My stuff was still running, but hidden, and the KDE start menu was usually gone as well.

And, of course, I usually had some unsaved work in the hidden window. Fortunately, it's possible to restart the KDE randr config app from a shell, and this usually causes my display to regain its side by side configuration. You do this with:

kcmshell4 randr

Kcmshell4 can start a variety of apps and widgets. You can get a complete list of what's on your system with "kcmshell4 --list".

[ view entry ] ( 617 views )   |  permalink
There is nothing wrong with your set: Why rsync is slow for large files 
There's a lot of confusion and badly written questions and answers returned when you Google for "rsync incremental file transfer". Most of the babble is related to command-line fail when doing incremental backups of a directory tree. Of course "rsync -a" skips files that are unchanged between the source and destination. But that may not be what you mean by "incremental file transfer". What you might mean is - "why is rsync taking so long to transfer a large file that is unchanged except for a few lines." A good example is a log file that is getting appended to.

For this we have one of the great things about rsync: the "Tridgell Algorithm" ( Unless you specify otherwise, rsync will try to transfer only the parts of existing files that have changed since the last copy.

You might think this would speed up your large file transfer. But in today's world of fast networks and (usually) underpowered virtual hosts, it usually doesn't. The Tridgell Algorithm is CPU intensive, and rsync is single threaded (probably by necessity, since using multiple threads to access a single file sequentially would be rather pointless.)

Example: Times for copying a 4 1/2GB file over a fast network on a slow server:

time rsync -va (etc):
delta-transmission enabled
4763951706 100% 125.50MB/s 0:00:36 (xfer#1, to-check=0/1)
total: matches=69025 hash_hits=103974 false_alarms=0 data=130595
sent 552238 bytes received 406893 bytes 8093.93 bytes/sec
total size is 4763951706 speedup is 4966.95
real 1m58.382s
user 0m38.945s
sys 0m11.891s

time rsync -Wva:
delta-transmission disabled for local transfer or --whole-file
4763965456 100% 56.92MB/s 0:01:19 (xfer#1, to-check=0/1)
total: matches=0 hash_hits=0 false_alarms=0 data=4763965456
sent 30 bytes received 4764547173 bytes 50418488.92 bytes/sec
total size is 4763965456 speedup is 1.00
real 1m33.719s
user 0m46.032s
sys 0m26.128s

There are even inconsequential differences for a small file:

rsync -va:
delta-transmission enabled
1059189 100% 202.02MB/s 0:00:00 (xfer#1, to-check=0/1)
total: matches=1034 hash_hits=1038 false_alarms=0 data=373
sent 6240 bytes received 4679 bytes 7279.33 bytes/sec
total size is 1059189 speedup is 97.00
real 0m0.290s
user 0m0.044s
sys 0m0.013s

rsync -Wva:
delta-transmission disabled for local transfer or --whole-file
1066221 100% 48.42MB/s 0:00:00 (xfer#1, to-check=0/1)
total: matches=0 hash_hits=0 false_alarms=0 data=1066221
sent 30 bytes received 1066517 bytes 711031.33 bytes/sec
total size is 1066221 speedup is 1.00
real 0m0.246s
user 0m0.042s
sys 0m0.022s

So there you go, why you don't see much improvement from rsync's delta-transmission mode. THIS IS THE WAY IT IS SUPPOSED TO WORK. And the man page says as much:

-W, --whole-file
With this option rsync’s delta-transfer algorithm is
not used and the whole file is sent as-is instead.
The transfer may be faster if this option is used when
the bandwidth between the source and destination
machines is higher than the bandwidth to disk (espe-
cially when the “disk” is actually a networked
filesystem). This is the default when both the source
and destination are specified as local paths.

So, we love Tridgell's Algorithm, but is isn't always faster.

[ view entry ] ( 796 views )   |  permalink

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next> Last>>