The road to 2.0

June 26, 2025 - Jason Hostetter

Back in 2024, when I was a second year resident, I was playing with building a scrollable stack of CT images on a website, inspired by a suggestion by Dr. Jean Jeudy, one of the thoracic radiologists and informaticists at University of Maryland. It was simplistic, used Dropbox for storage, and had no advanced tools, not even window/level adjustment. But it was fun.

Fast forward to today, Pacsbin has been serving millions of full fidelity DICOM images all over the world for almost 10 years. Not much has changed from the user's perspective in that time, aside from some relatively minor updates, which in many ways is a good thing. Too much change causes friction and confusion. However, too little change can lead to stagnation and neglect. Indeed, Pacsbin's lack of outward change has led some to ask whether Pacsbin is dead as a project. I assure you, it is not.

When Pacsbin began, doing any kind of advanced image visualization on the web was a difficult endeavor. Dealing with DICOM made it doubly so. In 2014, I had mostly written off trying to do real, bona-fide DICOM display on a website, even though there were a few examples of it having been attempted. DICOM as a protocol was new to me, and the rabbit hole ran deep and was full of arcana far beyond my understanding (much of it remains so). Then I attended my first SIIM conference in 2014 and saw Chris Hafey's new open source project cornerstoneJS. An amazing gift to the open source community that keeps on giving, cornerstone solved the most complicated parts of DICOM-on-the-web. I used it to build my own basic viewer, built an anonymization pipeline with the help of UMaryland's amazing radiology IT group, and Pacsbin was born.

The mission of Pacsbin then, as it is now, is to provide a fast, easy, medical imaging platform for education and research. The first version (v1), and the one you more or less see today, has been a fairly reliable platform for basic image storage, viewing, and sharing. However, there have been some long-requested features and stubborn limitations I have long wanted to address, and now finally can, thanks to a combination of factors (not the least of which being, my children no longer rob me of sleep on a nightly basis). To solve these issues, though they may seem relatively simple on their face, required not only a complete rewrite of Pacsbin (and much of cornerstone, though not by me), but also required browser technology and the DICOM standard itself to advance from where they were 10 years ago. Here are some of the biggest changes coming.

3D rendering

Pacsbin users regularly ask if they can change the plane of images in 3D space, create oblique reconstructions, MIPs, etc. In 2014, this was largely beyond the capability of browsers if performance was a concern. Today however, web browsers can leverage GPUs baked into everyone's computer, phone, and ipad to render these images really fast. Thankfully for me and anyone doing work with medical imaging on the web, the brilliant folks at OHIF have shepherded cornerstone into the modern age with the release of cornerstone3D, which brings all of cornerstone's core functionality into 3D space, and enables many, many cool features, MIPs and MPRs among them. A new version of Pacsbin's viewer has been built to take advantage of these features.

Image compression

Pacsbin v1 takes a simple and effective approach to image storage and delivery. DICOM images are decompressed to raw pixel values, compressed with general purpose compression (gzip), and then stored and delivered with AWS S3. This method has very few opportunities for failure and is in general quite fast, at least for smaller images like CT and MRI. For larger images (plain films, mammograms, US and XR cine), load times would likely be abysmal, especially for those without fast reliable internet. Furthermore, when groups of trainees got together in one conference room, on sketchy wifi, even trying to load a small study times 50 people simultaneously could saturate bandwidth and bring everything to a halt. These were largely issues that were not directly solvable by me, though we now have some better options.

Just two years ago, the DICOM standards committee approved the addition of a new transfer syntax for images compressed in the High-throughput JPEG2000 (HTJ2K) format. DICOM has supported standard JPEG2000 images for years, but due to it's relatively slow compression/decompression, has not seen widespread adoption. HTJ2K uses an alternative approach to encoding and decoding which is much faster. The most exciting property of JPEG2000 (and HTJ2K) encoded images is support for progressive decoding. This means that, when loading an HTJ2K image over a web connection, as the data arrives to your browser, the image can be reconstructed and displayed almost immediately at lower resolutions, even before all the data arrives. As more data arrives, the image resolution increases.

The combination of good data compression and progressive loading means that I can now store full US and XR cine, tomosynthesis, and other large imaging studies, while still keeping initial load times fast. Hopefully this will also let me tweak settings to improve the experience in low-bandwidth environments, such as the crowded conference room.

Dicomweb

In addition to adding HTJ2K, the DICOM standard has also, for quite some time now, supported a web-native image query and transfer protocol, called DICOMweb. While not perfect, DICOMweb unlocks some very exciting possibilities. Firstly, I was able to vastly simplify the Pacsbin image processing pipeline by converting what had for years been an unholy server based pipeline hot-potatoing images between different stages of retrieval, conversion, anonymization, and upload, which might fail for any number of opaque, un-debuggable reasons requiring the whole thing to be restarted, into an entirely web-based application, letting each user individually process their images on their own computer, in the secure browser sandbox, where any failures need not affect any other user. DICOMweb let that browser application directly query and retrieve images from a hospital's image archive (assuming the vendor supported DICOMweb, which remains a bad assumption to make), and securely process images locally without getting Pacsbin's servers involved. This was actually deployed several years ago, and has been a huge maintenance improvement, and hopefully a huge usability improvement for Pacsbin users.

Storage layer

In order to support some of these new capabilities, in particular HTJ2K compression and progressive loading of multiframe images, the storage layer had to be rethought. Bare S3 object storage could have been shoehorned into the new cornerstone image loading methods, but a better fit was to build on DICOMweb directly. There are lots of options out there, open source servers like Orthanc, and proprietary solutions like Amazon Health Imaging (though DICOMweb support remains limited).

But given that Pacsbin started as, and remains, primarily a project that lets me learn and explore, I decided to try and build my own DICOMweb server, native to the cloud. Out of this came Litevna, a DICOMweb compatible archive built on Cloudflare workers. Building my own server lets me more fully understand the whole stack, and tune how it works to best support the goals of Pacsbin. For example, Litevna stores all images in HTJ2K format, supports byte-range requests, supports storing duplicate studies independently in the same archive (important for Pacsbin's multi-user nature, but not a concept native to DICOMweb), and by default globally cached via Cloudflare's CDN.

An added benefit of basing the Pacsbin storage layer on DICOMweb is the potential of enabling 3rd party viewers to load studies directly from Pacsbin, for example the amazing OHIF viewer. This could let users do more specialized tasks with their software of choice, things like segmentation or advanced rendering modes that are not the primary aim of Pacsbin to enable.

UI Updates

Lastly, there have been quite a few nagging UI limitations that I can now address, thanks mainly to improvements in UI frameworks over the past 10 years (Pacsbin v1 still uses jQuery quite liberally and some very early React), as well as changes to the underlying database schema.

Some examples:

• Reordering cases in a collection (to be renamed Playlist) arbitrarily
• Better mobile experience for viewing your case list and Playlists
• Better case sharing
• Ability to remove Public links (or have them expire)
• More tools (i.e. rotation, localization/crosshairs)
• Setting study defaults (layout, window/level, etc)
• Support for separate Organizations and Projects to better organize cases

These changes have been many years in the making, and are getting tantalizingly close to primetime. In the spirit of not changing things for the sake of change, I have tried to keep as much of the Pacsbin UI and functionality similar or the same, while adding new capabilities.

The process of rolling out v2 will certainly have some problems, disruptions, and bugs, but I do believe the end result will be much much better, and provide for another 10 years of service and beyond. I am eternally grateful to everyone who has used Pacsbin over the years, for all the feedback and support of this project. I'm also looking out for some better ways to handle feedback and community discussion, so that I can hopefully write fewer emails that start with "Sorry for the delay, ..."

With gratitude,
Jason Hostetter