Anatomist / BrainVISA is another major program in neuro image processing and analysis, though specializing in MRI this time.  It is a product of a consortium of French academic institutions and is frequently updated and well supported.  It's true open source and has been built on many operating systems, though prefers Linux.  I've not used this program, it's specialized and not in my particular field.  I will download and test it for a review, though, and I've admired their images, does that count?

RadScaper is a Java applet-based image viewer from Divinev, and the recently released updates feature an attractive redesign along with technical improvements.  There are a couple of these around, but RadScaper is in continuous development and its capabilities have grown considerably.  There are obvious limitations to viewing images in a web browser rather than a stand-alone imaging application, but Radscaper can be run on just about any computer and requires no software installation at all.  The image files are supplied via straight HTML so there should be no issue in accessing the image server through a firewall or other security appliance.  

Osirix has another of its regular updates released.  It's the program I almost love to hate, since it could be argued that it is the only DICOM program you need, which would make my site obsolete!  As a general purpose radiology workstation, or indeed for many specialized purposes, Osirix will do pretty much everything with DICOM files.  I use it all day long for imaging and PACS work, and I recommend it to colleagues.  If they are not currently Macintosh users, this program probably justifies purchasing a Mac.  Of course, it is limited to DICOM and is limited to Macintosh (it utilizes so many advanced Mac core technologies that porting it to another OS would mean redesigning it).  Try this program.

No image file for dcm4che, the comprehensive DICOM Java library and related applications, which has another update out.  This vast toolkit is all command-line business, specializing in PACS operations, networking, getting images from A to B with complete accuracy and great efficiency.  How hard core is it?  The 'che' is actually 'Che' as in Guevara - the developer was "inspired by the revolutionary nature of open source".  Some programs have a special place in my heart, but dcm4che has something even more special, a permanent place in my directory path.  All my machines (from 6 to 60 of them depending on how you count them) have /usr/local/dcm4che/bin hard coded in my path (even Windows machines, since I do most of my work at the Cygwin command line).  For me, a standard step in getting any machine to a minimal functional state is to install Java and then dcm4che.  In fact just today I was installing a WIndows 7 virtual machine (I run Parallels on the Mac), getting Java to install in C:\java, since the default 'Program Files (x86)' directory causes all sorts of issues in the path, what with all those spaces and parentheses.  dcm4che's sibling is dcm4chee (the 'e' is for 'Enterprise'), a powerful PACS server in Java that provides the core of my test lab.

By which of course I mean, it rules the ratings.  Though it could also be said to rule, because it is a really good browser and was the first real alternative to Internet Explorer, back in the days when it was called Mozilla.  I kind of miss the old logo and the spirit of rebelliousness that came with not running Internet Explorer back in those heady days.  Though if we're going to talk old web browsers I could hark back to 1993 and getting NCSA Mosaic for the first time...but I digress.

So, these ratings.  Here at I Do Imaging World HQ we (I) analyze the web logs on a regular schedule - given that I've done it twice,that is hard to disprove.  And when I looked at the web browser statistics I see that some time around July, Firefox because the most popular web browser used to access this site.  Of course, I credit my readers with being high achieving trend setters, so I don't know if this reflects the web use as a whole.  Still, I think it's a significant point in Web history.  Over the last two years, Internet Explorer has gone from almost 60% to just under 40% share, while Firefox has climbed from about 35% to just over 40%.  Safari and Opera have seen modest gains, from about 5% to about 8% each, with Chrome, which of course didn't exist two years ago, now at about the same level.

Any one of these is a perfectly good browser.  In the last year I've been using Internet Explorer occasionally and have found that the latest release is actually really good.  I've been using Firefox for so long that IE has caught up a lot.  I use all five of these on the PC, on the Mac I use Safari, Firefox and Opera, and on Linux I run Firefox and Opera.  I really like Opera, partly for their adherence to standards (though all browsers these days are pretty good about that), but also I like to stick up for the little guy.  And, I can't shake the idea that any software from Scandinavia is just plain cool.

On the operating system side, things are a little less dramatic.  Most people still run Windows, though in two years this share has fallen from almost 90% to just over 80%.  The Mac has seen a steady rise, growing 50% in share from about 8% to about 12%.  Linux trucks along on the desktops of about 7% or so of the desktops of my readers.  For years and years I was among those hard-core souls, using a Solaris or Fedora machine as my primary workstation, but recently I've found little reason to use any machine other than my Mac Pro.  I still use it as a Unix workstation at the command line, but as far as my web stats are concerned, hello, I'm a Mac.

My 10.6 / Snow Leopard Mac installations went smoothly though I've heard of friends who had issues during the installation.  I did a reformat and fresh install as I do every time I install a new OS, not that it's necessary but it's good to know where you stand.  Plus, it's an opportunity to look at what I have on the machine and how it's organized, and think about a better way to arrange things.  I reinstall all the applications either from the DVD or download.

The major issues I had with 10.6 were with Java incompatibilities.  I can't connect to our VPN at work, though this is partly due to the VPN server software not being upgraded.  Still, one would hope that changing versions of a language didn't break anything.  I had another problem with a commercial Java-based imaging application, though the latest update fixed this.  

Overall the changes in 10.6 have been minor.  The machine does boot faster though I don't often do this; the workstation stays on and the laptop goes to sleep between uses.  Programs perhaps load a bit faster.  I don't like the new Expose arrangement where all the mini windows are scaled to the same size, and arranged in a grid rather than in their approximate positions as used to be the case.  I've always thought that people remember sizes and locations well - such as looking back through a newspaper for an article you've read, and remembering about where on the page it was.  The new Expose behavior removes these visual cues.  Hopefully they'll make it an option to turn off the new look.

Windows 7 was a bit harder to install.  Though I've had a Mac since 1985 I don't knock Windows, it's a good operating system.  Neither do I disparage Vista which I've been running since it came out, with no problems, and find it better in every way to XP.  I did have problems installing Windows 7 though.  I did a fresh install, which I consider essential when upgrading Windows.  In fact, once a year I reformat and reinstall, just to get rid of the detritus that has accumulated in the interim and is bogging the system down (this is one aspect of Windows I don't defend).  

In this case I had trouble getting the installation to start at all, the installer kept quitting.  Once I got the install running, it would proceed to the final stage then freeze at "Completing Installation".  I'd leave it there for an hour and nothing would happen.  This seems to be a common problem as there were lots of accounts of it in Google.  There were various suggestions to work around this problem:

I use powers of 2 to encode values such as file formats into a single numerical field in MySQL (which briefly was SunSQL and is now OracleSQL?).  So I have code that looks like:

So the news sites have the obligatory stories on IE's declining browser market share.  I came across this gem of misinformation on Wired, from Reuters: 

The software design aspect was something that has bitten me before, and I haven't learned. 

 In my haste to get the screen captures feature implemented, I made 'screencap' a field of the 'program' table in the database.  This is easy: it only requires adding one field to the database and then remembering to extract the name of the screen capture image file when I retrieve the program's name, URL and so forth.  Of course, the limitation here is that there is only one field for a screen capture file so it doesn't scale nicely,  or at all.

So I went back in recently and as usual improving the design took no time at all.  I made a new database table called 'image', which will be used to store the details of all images.  There's a field in the table that links back to the 'program' table, so with one more MySQL call I can get all the screen captures that relate to a program.  I should have done it this way to start with.

Of course, once I started with the database table for the image files, new improvements suggested themselves.  The biggest gain is that I can now quickly pull up the exact size of an image and include this as part of the img tag in the HTML.  This should help the pages load faster as the browser now knows exact image sizes in advance, instead of having to load the images to determine their size.

The other improvement was to pre-calculate reduced size versions of each image capture file.  I use three sizes: full sized, for the popup screen captures, 320 pixel width for the pages of just screen caps, and 200 pixel width for the screen cap tooltip popup.  I have to admit that previously I'd been loading the entire image file even when it was just displayed at 320 pixel width.  With the reduced image files, the 320-width version can be 10 times smaller than the full size.  Needless to say I used PerlMagick, the Perl API to ImageMagick, as I have hundreds of image files to process and am not fond of doing things by hand (I characterize this as Actual Work whereas programming is more along the lines of recreation).  The image-creating program got a bit involved, as it has to check for database duplicates, come up with unique image file names and so forth.  But the gist of the work is done in just a few lines:

The name of the icon group is systematic so I can create it in the CGI programs, the image files are named like plat_win_mac_linux.png for all 3 platforms as above, or plat__mac_.png for just Macintosh.   I put them into groups of 3 to avoid lots of little sub-tables, or tables with dozens of columns, and yet still get them nicely aligned horizontally.  They seem to load pretty quickly despite the front page having 68 of the platform and interface icons.  They're only about 2 kB each (ImageMagick is frugal with bytes) and the browser will cache them, so they each should only need to be loaded once. 

The tip text Javascript comes from Dynamic Web Coding's 'Tooltip' library.  This is a really nicely designed and implemented library with all sorts of features.  I felt guilty for not learning Javascript and doing it myself, but this passed in about 10 seconds.  This is a good library and I'm fine with licensing someone else's code.  I next want to incorporate their 'Scrolling Divs' library for the screen capture images.

PixelMed Java DICOM Toolkit is another advanced project, providing an extremely comprehensive implementation of DICOM tools.  It comes from David Clunie, a name familiar to everyone who has done any work at all in the field of DICOM programming.  This toolkit will provide more functionality than most people can utilize and comes from the foremost authority.  It is updated extremely frequently, such that version numbers are not used.  It's difficult to convey on my site how frequently it is released, as almost all other projects release versions on a monthly to annual basis.  This software is revised almost weekly.  Perhaps I should make it a 'sticky' at the top of the 'New Releases' list.

Another very comprehensive library, in C++ this time, is Imebra from Paolo Brandoli, of PuntoExe software.  Here is another true open source program, where the free version is identical to the commercial, and source code is provided in both cases.  This project has recently gained its own website (imebra.com), and related projects based on the library are at the Puntoexe website.

DP Tools, from Denis Ducreux, is another active program.  It specializes in the field of functional MRI and MR Diffusion.  I know nothing about this field but have seen an increasing amount of excellent software emerging.  It's written in Delphi, in common with some of Chris Rorden's very widely used imaging software.  I am also profoundly ignorant of Delphi, I seem to be exposing my weaknesses here.

ITK-SNAP is another specialized neuro program, this time for segmenting brain images.  It incorporates elements of the NLM Insight Segmentation and Registration Toolkit, hence the name.  Formerly developed at UNC-Chapel Hill and now at Penn, this project provides automatic and manual brain segmentation methods.  It's cross-platform.

TomoVision is a little program that displays DICOM images and doesn't do much else.  And, the free version is limited to 5 images.

MedImaView has a new version out.  It's another small DICOM viewer, when I tried it just now I could only open multiple files via drag and drop, and when I dropped a 192-frame MRI sequence I got: 192 windows.  Hmmm.

I want to add Google Analytics code to my sister's website, which she's writing using iWeb.  Analytics is enabled by including in your HTML a javascript snippet that Google gives you.  iWeb does a really nice job, but you have to do things their way, and that means no javascript.  Fair enough, I guess, Apple want to be ensure that websites produced using their software will always work, and introducing a programming language pretty much ensures that things frequently won't work.

The website is hosted on a Linux server, not an Apple account, so to publish the site we export its contents to a directory, then FTP the directory contents to the server.  Initially we used Filezilla but it does not have incremental directory synchronization, so we switched to the awesome Cyberduck.

So my first thought was, well perhaps we can modify the HTML files before they leave her Mac.  There are a couple of approaches available, one is an iWeb add-on which looked more complex than needed, and you have to buy it.  Another was an Automator action you can download that will insert the Google javascript into the HTML files.  That sounded good but was one more action to perform, and I've never used Automator.

So I thought, I'll knock up a little script that the web server can run as an hourly cron job, and edit any HTML files that don't contain the Google code.  Ha!  Little script though it is, it took a while.  I got a lot of help from Bruce Barnett's sed guide, as I don't have a good shell book with me right now.  I should buy O'Reilly's 'Sed & Awk' book, a classic if ever there was one, and I believe may even have been their first ever book published. I remember it in print in the early 90's, and they even had a T shirt of the cover, which I dearly wish I'd bought.

The tricky part was, the Google code is supposed to be included immediately before the </body> tag in each HTML page.  Two problems: I couldn't be sure that the </body> tag would be on a line by itself, and sed file inclusion acts after the matched pattern, not before.

Problem 1 was addressed using a simple substitution with newlines:

OK I wouldn't have thought of that one.  As he explains,

 

He goes on to cover more general cases.  There is also another approach described in the same forum which employs use of the hold command, h, and the swap operator, x.

Having tested the code that does the file insertion, I put it into a shell script that finds all *.html files, checks to see if they have the GA code in them already (you're only allowed to put it in once), and if not, performs the insertion.

Next problem...the ISP's server doesn't offer cron!  I need this to run the sed script on the HTML files without having to ssh in to run it.  Aargh.  Neither can I execute an arbitrary command on the server using my FTP client.  I might try making a passwordless ssh script (using id_rsa.pub keys) and then see if I can get Cyberduck (FTP client) to run that after it performs the transfer.

That's enough for one day, though.  I learned a lot about sed, and a lot about how much I don't know.

Today's entry, that all-time classic, confusing power with energy.  There's an article in Wired today about a device that burns waste restaurant oil (though the writer incorrectly calls it 'grease').  

Only, a gallon of oil is a measure of energy, but a kilowatt is a measure of power.  Energy is measured in joules (or any other energy unit, calories, BTUs, whatever).  A joule is a watt-seconds, watts times seconds.  Watts (power) are joules per second, the amount of work done per time, or the rate of energy conversion.  The key being, energy is a scalar, power is a rate.

So does this thing produce 5 kilowatts for the full 168 hours of the week, or some lesser period?    The writer doesn't say and probably doesn't know.  Assuming it produces the 5 kW continuously, it would then do 5 x 168 = 840 kilowatt-hours (kWh) of work per week.  840kWh is worth about $126, with power costing about 15c per kWh.  So 80 gallons is supposed to generate $126 worth of electricity, say $1.50 per gallon.

The writer goes on: 

So now he's saying a gallon of waste oil generates 25 kWh of electricity, or $2.50 worth of electricity per gallon.  Wait, didn't he just say $1.50 per gallon?

OK so they're claiming $1,000 a month, or 10,000 kWh of electricity, or about 14 kW continuous (hey it might be a 24 hour restaurant...).   Depending on which of his numbers you go with ($2.50 or $1.50 of electricity per gallon of oil), that's between 400 and 660 gallons of oil a month.  The only number he gives though is 80 gallons a week or about 330 a month.  These numbers are not astonishingly out, only a factor of 2, not bad for general writing.

I just saw this article on the Watt in Wikipedia which has a section 'Confusion of watts and watt-hours'.  "Power and energy are frequently confused in the media", it says.  No kidding.

Perl hashes are seductive, it's so easy to add elements and things tend to just work.  So my derived DICOM element class ends up having 13 elements in its hash, of which 10 are in the base class ('name', 'parent', 'length', 'offset' and so on) and three are added in the derived class ('code', 'group', 'element') as being DICOM-specific.

As mentioned, I never claim Perl is svelte (or fast) but today I was sorting about 2,000 DICOM files.  I like to keep them all in memory, for convenience and sorting, before writing or moving to disk.  Heck we're only talking about a few thousand things here and computers work in the billions...all too easy to forget about memory usage.

I was unpleasantly surprised to find that each time I read in a DICOM file of just over 32 kB (PET scans are small, 128 x 128 x 2 bytes), I was consuming over 300 kB of memory.  So my full dataset of only 70 MB was using up almost a GB of RAM.  And that was for only 2,100 files, whereas I have one scanner that generates over 6,500 DICOM files per study.  I have the RAM to handle it, but my inner CS grad has a problem with a tenfold usage of memory.

I used the Perl module Devel::Size to measure the size of hashes and the answers aren't pretty: on my 64-bit Linux workstation each hash element is consuming 64 bytes in overhead.  Crikey!  So 64 bytes, times 13 fields per DICOM element, times 200-odd DICOM elements per object, that's over 200 kB per DICOM object before I even put any data into it.

On my 64-bit Mac with perl 5.8.8 it's not much better at 39 bytes per minimal element.  I compared it with an array, which turned out to use 16 bytes per minimal element.

The average visit is 4 pages in about 4 minutes.  An ad gets clicked on 2% of the time it's shown, so roughly 8% or one visitor in 12 clicks on an ad, which indicates they're pretty well targeted.  Just under half the people (46%) leave in under 10 seconds, but some of these might very well be people who immediately clicked on the site they were looking for.  So I'm going to count some of them as satisfied customers (Google rather disparagingly calls this the 'Bounce Rate').  

Hopefully this indicates I'm on the right track.

So 920 is the new width, though using the awesome 'Inspect Element' tag in Google Chrome, I can see that some pages appear to spill over a little.

(In the course of this, I read how to simulate the missing 'delayed capture' feature in the otherwise great Vista 'Snipping Tool'.  Open Snipping Tool, press Esc, compose your picture, press Ctrl-PrintScreen to freeze as-is, drag over the now-frozen screen to capture).

Now that I have additional width, I immediately filled half the new space with icons.  I've resisted using them to now, partly to get more information in per line, and partly because I think that a textual interface is more efficient.  But I have to admit that well-designed sites that use icons well, do look better (and now I'm half-way there, in that I use icons.  Now I just have to get a good design).  I used the beautiful 'Silk' icons from Mark James's famfamfam.com, a lovely set of exactly 1,000 icons in 16x16 pixel PNG format.  They are, as he says, "strokably soft".

Not every idea I wanted to convey had an exactly-matching icon, so I chose those I thought best fitting.  So for program interfaces now I have  for 'GUI',  for 'Command Line', and  for 'API/Programming'.  Hopefully they get the idea across, and I added tool tips for clarification.  They are very pretty, but do take up some of my precious horizontal width.  

The other icons I use are  for 'Link to site',  for 'Site link down' (though it still will link through),  for 'Add monitor' (email notification), and  for 'Unable to add monitor'.  The last is for websites where there is no revision number or release date listed, so I'm unable to provide update information.  This affects about 20% of the projects, though usually the less-active one. 

I like to get the program interface icons to line up nicely in columns ('column up'?  Is there a verb meaning 'align in columns'?).  I used to do this with an internal HTML table within the TD cell for each entry.  This is pretty wasteful and slow - the browser has to set up a table for each line, calculate its width, and so on.  So I made up composite icons of the eight permutations of the three individual icons each in their 'on' and 'off' states.  For this as with most of my graphical editing needs I use the amazing ImageMagick command line tools.  The 'montage' command allows you to combine multiple pictures into one, in a definable grid geometry, and furthermore can create blank spacing elements, and a transparent background.  Simple.

I want to add icons to denote the platform or operating system of each program, which would be very useful though using up still more width.  The problem has been finding the icons for Mac, Windows, and Linux in a suitable size (16x16).  You'd think the Web would be swimming in them, and you'd be wrong.  Probably due to copyright, none of the dozens of icon collections I squinted through had them.  The hunt continues.

I run everything from Perl, so I made a little test program and included a call to his Javascript libraries: