How best to implement MPR in PHP?
So, while the decision to write up in PHP was made some time ago (and hasn’t 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 (that’s in the future, BTW) is MPR and that poses a challenge.
MPR (AFAIK) necessarily requires two stages:
- Build the 3D model from the original data.
- 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 doesn’t 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 that’s 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, it’s 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 I’m working on is database neutrality so the ‘smart DB optimisations’ may not work out although I’ll cross that bridge when I come to it.
Storage: SSD and Tape News
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 isn’t a formal schedule, past generation lifecycles suggest Gen 8 may be with us in 2017.
Latest from the Blog:
Categories
- DCM4CHEE
- Development
- High Availability
- IHE
- Infrastructure
- Lessons learned
- News
- Open Source
- PACS General
- Project matters
Recent Comments:
- Martin P on Window/Levelling in a browser – CANVAS or server-trips?
- Martin P on 3D can be a dangerous game
- Juan Jose Cermeno on 3D can be a dangerous game
- A.J on Window/Levelling in a browser – CANVAS or server-trips?
- Suresh on Window/Levelling in a browser – CANVAS or server-trips?

Posted by Martin P in