Friday, April 23, 2010

How best to implement MPR in PHP?

Posted in For my own notes, PACS General at 8:56 pm by Martin P

So, while the decision to write up in PHP was made some time ago (and hasnt changed), the actual development of a browser-based PACS viewer has (hurray!) made some progress.  Focus for now is on the simple stuff - CR first, then a means for viewing CT/MR.  But on the roadmap (thats in the future, BTW) is MPR and that poses a challenge.

MPR (AFAIK) necessarily requires  two stages:

1. Build the 3D model from the original data.
2. For each coordinate change, generate a projection against the 3D model.

Now while PHP can happily manage most of the requirements, in this case it suffers a limitation that doesnt apply to platforms like J2EE.  Each interaction is a discrete, non-persistent entity.  At the simplest level, that means that every time a change to the XYZ coordinate is made, the 3D model has to be rebuilt.  Well thats not going to work.

So, (and this is largely for my own notes), there are ways to address the issue:

• When a client initiates MPR, exec off a seperate PHP process to build the 3D model, and remain persistent (in a big loopy thing).  Subsequent requests for changes in XYZ then communicate with this detached process (say, ActiveMQ) to retrieve projections.  That would work, but without the infrastructure provided by something like J2EE, its little better than a hack.
• Have the initiation build the 3D model, but dump a representation of that onto a RAM-based storage area for subsequent XYZ requests.
• Taking that even further, maintaining the model in a database table that itself is maintained in RAM.  This raises the potential for some smart SQL/DB optimisations, which in itself, makes it my (currently) preferred option.  Hell that may change.

Addendum:  One of the principles Im working on is database neutrality so the smart DB optimisations may not work out although Ill cross that bridge when I come to it.

Permalink Comments

Thursday, April 15, 2010

Storage: SSD and Tape News

Posted in Hardware at 12:59 pm by Martin P

We have news that 1TB SSDs are available (at a premium price, mind).  SSDs have particular advantages for medical archives:

• Faster
• More reliable (no moving parts)

but however reliable they are backups are still necessary.  Disk space is so cheap nowadays that disk-to-disk backup is viable but many still prefer tape backup.  The future of LTO tape had been somewhat uncertain but we see now the LTO consortium announcing the plans (PDF) for LTO up to generation 8 (currently LTO is at Gen 5).

Generation 8 is set to allow up to 32TB per tape (compressed). Although there isnt a formal schedule, past generation lifecycles suggest Gen 8 may be with us in 2017.

Permalink Comments

Saturday, April 3, 2010

Hacked (again) but back

Posted in Uncategorized at 12:58 pm by Martin P

The last couple of days this site was unavailable from some entry points (not all).  Seems at some point in the past the main index page was set up for some nefarious process on remote activation.  The activation occurred sometime Thursday.

The lesson (as if I havent learned it before!): Keep your site up to date with security patches and MIND IT.  It is not a set-and-forget process.  There are, and will continue to be, buggers out there who will trample all over any site that offers a free ride.

Having said that, no thanks whatsoever to my host (who has still not responded to this incident or, indeed the one in September 2008).  Time to move I think.

Permalink Comments

Thursday, March 25, 2010

So Dell gets into the PACS Archive market. Who next?

Posted in PACS General at 5:44 pm by Martin P

Dell has announced their entry into the medical imaging archive market.  As if we didnt have enough vendors.

Im going to pick some holes in this.

Because, Coffin points out, IT budgets are not increasing at the rate of storage needs for the industry.

nope.  But they dont need to.  The cost of storage is plumetting at an increasing rate.  What organisations paid for 1TB 2 years ago will get them 10TB (or indeed a great deal more) if they are smart and not go for the easy option.

Moreover, he says, with these vendor-neutral archives, it doesnt matter who the PACs vendor is.

Look.  There is no such thing as a vendor-neutral archive.  There is only vendor-different archives.  Storage is still storage.  Database schemas are still schemas.  So-called vendor neutral archives are simply open transparent instances of those technologies (if youre lucky).  The fact that a distinction needs to be made is a disgrace.  Vendors should NEVER have been allowed to hide those behind opaque barriers (as, indeed some vendors get way with to this day).

The article doesnt go into any detail on the level to which this new product will support the necessary IHE profiles to make this truely safe and usable.  Then again, my experience of horizontal vendors trying to make inroads into vertical markets, suggests that IHE, HL7 and the like are at best afterthoughts.  I recall Digital (then still a thriving company) trying to dig into the GIS market (then, my field of expertise) and making a dogs dinner of the whole thing.

Still.  I may be pleasantly surprised.

Permalink Comments

Is Computing and Data Visualisation on the verge of a revolution?

Posted in Browser matters, CCOW, PACS General at 5:26 pm by Martin P

Im a fan of the notion of punctuated equilibrium in evolutionary theory.  From Wikipedia:

When evolution occurs, it is localized in rare, rapid events of branching speciation

most of the time, things just truck along doing what needs to be done, and then over a short (relatively, in the case of evolution) period of time, some big stuff happens.  That kind of feels where the computing and technology world is sitting right now.

In the course of innovation within the computing and data visualisation fields - particularly as applied within medical imaging, there has for many years been steady but linear progress pretty much corresponding to Moores Law.  Lets take a look at a few technology sectors:

• Smartphones.  Clearly, these were languishing in the doldrums until Apple gave the industry a smart kick up the rear.  It took a little while for competitors to figure out how to follow, but follow they have and the next year or so will see some intense competition and major advances as a result.
• Browsers.  There is at last widespread adoption (at least in product roadmaps) for HTML 5, even by Microsoft.  This is important.  Two elements in particular - Web Sockets will enable the development of server push for CCOW implementations (an issue till now).  The Canvas element allows for in-place editing of images and image properties in the browser with Javascript.  Watch this space for a little experimental implementation of Window/Leveling using the Canvas element.  As well as HTML5, many browsers are working on WebGL - a means to allow browsers to take advantage of hardware acceleration when rendering 3D.  3D was not too long ago a luxury item in Radiology but nowadays its a necessity.
• Speaking of 3D.  Developments are arriving thick and fast.  From Avatar in a cinematic context, augmented reality, 3D on every conceivable device, and while this 3D print of a vein is intended for replacement body parts, 3D printing of objects is mainstream and may well turn out to be a valuable surgical preparation tool.

There is a common thread to many of these - the involvement of Google.  While the big G is by no means responsible for all advances, I think maybe its energy has a beneficial effect on innovation generally.  Googles blunderbuss approach to innovation sometimes leaves me lukewarm.  As an example, consider Googles many patents (for one and another) for scanning the pages of bound books.  innovative, perhaps, but it leaves me thinking - why not just guillotine to binding?  For 99% of books - thats ok surely?  But in general, Google is setting the pace - and many of the other big players in technology have woken up and contributing.

The rest of us can only benefit.

Permalink Comments

Monday, March 22, 2010

New release for DCM4CHEE: 2.14.8

Posted in DCM4CHEE at 10:33 am by Martin P

So we now see the release of DCM4CHEE 2.14.8.  While in terms of version number it is a minor update from 2.14.7, in many ways it contains some major feature additions.  As one might expect, there are a number of bug fixes and background changes, but there are a good handful of changes that may well have positive impact on installations:

• DCMEE-1343   Improvement of tolerance of illegally/inappropriately encoded DICOM datasets (yes, even today, it still happens!).
• DCMEE-1292   Improved timer handling for periodic taks.
• DCMEE-1340   Sync the filesystem before sending C-STORE-RSP.  A success response is not sent until the filesystem actually writes to disk to mitigate against a server crash while data is in filesystem cache.
• DCMEE-1373   Improved performancee in XSLT processing.

But along with these are two very significant elements:

• DCMEE-1356   Storage of lossy compressed images on a different FS group to the original image.  This is significant in two ways - firstly, while DCM4CHEE has to date supported lossy compression on previously compressed images, it has not actually compressed images itself.  Secondly, and more importantly, is how this could potentially be used.  I havent played with this myself just yet (I will), but for the moment I read this as follows.  Browser-based delivery of images has proved to be tough in one important respect - Window/Levelling.  Just about any scheme for getting a browser based application to window/level images requires some aspect of server-side processing - and image resizing is an important element of that.  It is of course possible for images to be resized from the full quality image each time, but for browser delivery - that is a massive waste of server resources, and makes performance a real issue.  Having a lossy compressed version of the image available makes this scenarion so much more viable.  More on this after I have had a chance to work through the new feature.
• DCMEE-1358   Migrate from JBOSS MQ to JBOSS Messaging.  This is an important upgrade.  JBOSS MQ was deprecated in favour of Messaging some years ago, and ongoing development discontinued not long after, as a result of which, MQ is severly limited in many ways - including message instance management.  The DCM4CHEE forums have a number of threads around monitoring and management of (for instance) the Forwarding Message Queue.  MQ has never had the capability to do this with any great effectiveness and the move the Messging can only improve the situation.  Again, more of this later.

Permalink Comments